[perldocjp-cvs 1478] CVS update: docs/perl/5.10.1

Zurück zum Archiv-Index

argra****@users***** argra****@users*****
2012年 7月 3日 (火) 03:47:00 JST


Index: docs/perl/5.10.1/perlfilter.pod
diff -u docs/perl/5.10.1/perlfilter.pod:1.2 docs/perl/5.10.1/perlfilter.pod:1.3
--- docs/perl/5.10.1/perlfilter.pod:1.2	Tue Feb 14 02:33:19 2012
+++ docs/perl/5.10.1/perlfilter.pod	Tue Jul  3 03:47:00 2012
@@ -77,14 +77,13 @@
 
 =end original
 
-Now think of each logical connection between the Perl parser and an
-individual file as a I<source stream>. A source stream is created when
-the Perl parser opens a file, it continues to exist as the source code
-is read into memory, and it is destroyed when Perl is finished parsing
-the file. If the parser encounters a C<require> or C<use> statement in
-a source stream, a new and distinct stream is created just for that
-file.
-(TBT)
+ここで、Perl パーサと個々のファイルとの論理的な接続を I<ソースストリーム>
+(source stream) として考えます。
+ソースストリームは Perl パーサがファイルを開いたときに作成され、
+ソースコードがメモリに読み込まれている間存在し、Perl がファイルを
+パースし終えたときに破壊されます。
+パーサがソースストリーム中に C<require> 文や C<use> 文に出会うと、
+新しく異なったストリームがそのファイルのために作成されます。
 
 =begin original
 
@@ -94,10 +93,9 @@
 
 =end original
 
-The diagram below represents a single source stream, with the flow of
-source from a Perl script file on the left into the Perl parser on the
-right. This is how Perl normally operates.
-(TBT)
+以下の図は単一のソースストリームを表現していて、左側の Perl スクリプト
+ファイルから右側の Perl パーサへのソースの流れです。
+これは Perl が普通処理する方法です。
 
     file -------> parser
 
@@ -121,7 +119,7 @@
 =end original
 
 同時に任意の数のソースストリームが存在できますが、一つだけが
-アクティブとなります。
+有効となります。
 
 =item 2.
 
@@ -201,10 +199,10 @@
 
 =end original
 
-So how do you use a source filter in a Perl script? Above, I said that
-a source filter is just a special kind of module. Like all Perl
-modules, a source filter is invoked with a use statement.
-(TBT)
+それで、どうやって Perl スクリプトでソースフィルタを使うのでしょう?
+先に、ソースフィルタは単に特別な種類のモジュールであると言いました。
+その他全ての Perl モジュールと同様、ソースフィルタは use 文で
+起動されます。
 
 =begin original
 
@@ -215,11 +213,11 @@
 
 =end original
 
-Say you want to pass your Perl source through the C preprocessor before
-execution. You could use the existing C<-P> command line option to do
-this, but as it happens, the source filters distribution comes with a C
-preprocessor filter module called Filter::cpp. Let's use that instead.
-(TBT)
+Perl のソースを実行前に C のプリプロセッサを通したいとします。
+これをするには既にある C<-P> コマンドラインオプションを使えますが、
+たまたまソースフィルタ配布には Filter::cpp と呼ばれる C プリプロセッサ
+フィルタモジュールが含まれています。
+代わりにこれを使ってみましょう。
 
 =begin original
 
@@ -229,10 +227,8 @@
 
 =end original
 
-Below is an example program, C<cpp_test>, which makes use of this filter.
-Line numbers have been added to allow specific lines to be referenced
-easily.
-(TBT)
+以下は、このフィルタを使うためのサンプルプログラムである C<cpp_test> です。
+行番号は、特定の行を参照しやすくするために追加されています。
 
     1: use Filter::cpp;
     2: #define TRUE 1
@@ -247,10 +243,10 @@
 
 =end original
 
-When you execute this script, Perl creates a source stream for the
-file. Before the parser processes any of the lines from the file, the
-source stream looks like this:
-(TBT)
+このスクリプトを実行すると、Perl はこのファイルのためのソースストリームを
+作成します。
+パーサがファイルから行を処理する前、ソースストリームは以下のように
+なります:
 
     cpp_test ---------> parser
 
@@ -264,12 +260,12 @@
 
 =end original
 
-Line 1, C<use Filter::cpp>, includes and installs the C<cpp> filter
-module. All source filters work this way. The use statement is compiled
-and executed at compile time, before any more of the file is read, and
-it attaches the cpp filter to the source stream behind the scenes. Now
-the data flow looks like this:
-(TBT)
+1 行目の C<use Filter::cpp> で、C<cpp> モジュールをインクルードして
+インストールします。
+全てのソースフィルタはこのようにして動作します。
+use 文はコンパイルされてコンパイル時に、ファイルの残りの部分が読み込まれる
+前に実行され、背後でソースフィルタに cpp フィルタをくっつけます。
+ここでデータフローは以下のようになります:
 
     cpp_test ----> cpp filter ----> parser
 
@@ -283,12 +279,11 @@
 
 =end original
 
-As the parser reads the second and subsequent lines from the source
-stream, it feeds those lines through the C<cpp> source filter before
-processing them. The C<cpp> filter simply passes each line through the
-real C preprocessor. The output from the C preprocessor is then
-inserted back into the source stream by the filter.
-(TBT)
+パーサがソースストリームから 2 行目以降を読むにつれて、処理する前に
+C<cpp> ソースフィルタを通して行が供給されます。
+C<cpp> フィルタは単に各行を実際の C プリプロセッサに通します。
+C プリプロセッサからの出力はそれからフィルタによってソースストリームに
+再挿入されます。
 
                   .-> cpp --.
                   |         |
@@ -334,12 +329,13 @@
 
 =end original
 
-The C<cpp> filter does not apply to the text of the Fred module, only
-to the text of the file that used it (C<cpp_test>). Although the use
-statement on line 3 will pass through the cpp filter, the module that
-gets included (C<Fred>) will not. The source streams look like this
-after line 3 has been parsed and before line 4 is parsed:
-(TBT)
+C<cpp> フィルタは Fred モジュールのテキストには適用されず、
+フィルタが使われているファイル (C<cpp_test>) のテキストにのみ
+適用されます。
+3 行目の use 文は cpp フィルタに渡されますが、インクルードされる
+モジュール (C<Fred>) は渡されません。
+3 行目がパースされ、4 行目がパースされる前のソースストリームは
+以下のようになります:
 
     cpp_test ---> cpp filter ---> parser (INACTIVE)
 
@@ -357,14 +353,15 @@
 
 =end original
 
-As you can see, a new stream has been created for reading the source
-from C<Fred.pm>. This stream will remain active until all of C<Fred.pm>
-has been parsed. The source stream for C<cpp_test> will still exist,
-but is inactive. Once the parser has finished reading Fred.pm, the
-source stream associated with it will be destroyed. The source stream
-for C<cpp_test> then becomes active again and the parser reads line 4
-and subsequent lines from C<cpp_test>.
-(TBT)
+見て分かるように、C<Fred.pm> からソースを読み込むための新しいストリームが
+作成されます。
+このストリームは C<Fred.pm> を全て読み込むまで有効のままです。
+C<cpp_test> のためのソースストリームは存在したままですが、無効に
+なっています。
+パーサが Fred.pm からの読み込みを終了すると、これに関連づけられた
+ソースストリームは破壊されます。
+それから C<cpp_test> のためのソースストリームが再び有効になり、
+パーサは C<cpp_test> から 4 行目以降を読み込みます。
 
 =begin original
 
@@ -373,9 +370,9 @@
 
 =end original
 
-You can use more than one source filter on a single file. Similarly,
-you can reuse the same filter in as many files as you like.
-(TBT)
+一つのファイルに複数のソースフィルタを使うことができます。
+同様に、好きなだけ多くのファイルに対して同じフィルタを
+再使用することができます。
 
 =begin original
 
@@ -385,10 +382,9 @@
 
 =end original
 
-For example, if you have a uuencoded and compressed source file, it is
-possible to stack a uudecode filter and an uncompression filter like
-this:
-(TBT)
+例えば、uuencode されて圧縮されているソースファイルがある場合、
+次のようにして uudecode フィルタと uncompress フィルタを
+スタックさせることができます:
 
     use Filter::uudecode; use Filter::uncompress;
     M'XL(".H<US4''V9I;F%L')Q;>7/;1I;_>_I3=&E=%:F*I"T?22Q/
@@ -414,10 +410,9 @@
 
 =end original
 
-Data flows through filters in the same order they appear in the source
-file. The uudecode filter appeared before the uncompress filter, so the
-source file will be uudecoded before it's uncompressed.
-(TBT)
+データはソースファイルに現れたのと同じ順でフィルタを流れます。
+uudecode フィルタは uncompress フィルタの前に現れるので、ソースファイルは
+展開される前に uudecode されます。
 
 =head1 WRITING A SOURCE FILTER
 
@@ -433,12 +428,12 @@
 
 =end original
 
-There are three ways to write your own source filter. You can write it
-in C, use an external program as a filter, or write the filter in Perl.
-I won't cover the first two in any great detail, so I'll get them out
-of the way first. Writing the filter in Perl is most convenient, so
-I'll devote the most space to it.
-(TBT)
+独自のソースフィルタを書くには三つの方法があります。
+C で書くか、フィルタとして外部プログラムを使うか、Perl でフィルタを
+書くかです。
+最初の二つについてはあまり詳しくは記述しないので、先にこれらについて
+触れます。
+Perl でフィルタを書くのが一番便利なので、これに最大のスペースを割きます。
 
 =head1 WRITING A SOURCE FILTER IN C
 
@@ -452,10 +447,10 @@
 
 =end original
 
-The first of the three available techniques is to write the filter
-completely in C. The external module you create interfaces directly
-with the source filter hooks provided by Perl.
-(TBT)
+利用可能な三つのテクニックのうちの一つ目は、フィルタを完全に C で
+書くことです。
+作成した外部モジュールは Perl によって提供されるソースフィルタフックと
+直接接続されます。
 
 =begin original
 
@@ -471,22 +466,21 @@
 
 =end original
 
-The advantage of this technique is that you have complete control over
-the implementation of your filter. The big disadvantage is the
-increased complexity required to write the filter - not only do you
-need to understand the source filter hooks, but you also need a
-reasonable knowledge of Perl guts. One of the few times it is worth
-going to this trouble is when writing a source scrambler. The
-C<decrypt> filter (which unscrambles the source before Perl parses it)
-included with the source filter distribution is an example of a C
-source filter (see Decryption Filters, below).
-(TBT)
-
+このテクニックの利点は、フィルタの実装を完全に制御できることです。
+大きな弱点は、フィルタを書くために必要な複雑性が増すことです -
+ソースフィルタフックについて理解するだけでなく、Perl の内部に関する
+ある程度の知識も必要です。
+この困難に向かう価値のある数回に一回はソースのスクランブル化を
+書くときです。
+(Perl がパースする前にソースのスクランブルを解除する) C<decrypt> フィルタは
+C ソースフィルタの例です (以下の Decryption Filters を参照してください)。
 
 =over 5
 
 =item B<Decryption Filters>
 
+(B<復号フィルタ>)
+
 =begin original
 
 All decryption filters work on the principle of "security through
@@ -591,8 +585,7 @@
 
 =end original
 
-Here is an example script that uses C<Filter::sh>:
-(TBT)
+以下は C<Filter::sh> を使ったスクリプトの例です:
 
     use Filter::sh 'tr XYZ PQR';
     $a = 1;
@@ -639,10 +632,10 @@
 
 =end original
 
-The easiest and most portable option available for creating your own
-source filter is to write it completely in Perl. To distinguish this
-from the previous two techniques, I'll call it a Perl source filter.
-(TBT)
+独自のソースフィルタを作成するためのもっとも簡単でもっとも移植性のある
+選択肢は、完全に Perl で書くことです。
+これを前述の二つのテクニックと区別するために、ここではこれを
+Perl ソースフィルタと呼びます。
 
 =begin original
 
@@ -655,14 +648,13 @@
 
 =end original
 
-To help understand how to write a Perl source filter we need an example
-to study. Here is a complete source filter that performs rot13
-decoding. (Rot13 is a very simple encryption scheme used in Usenet
-postings to hide the contents of offensive posts. It moves every letter
-forward thirteen places, so that A becomes N, B becomes O, and Z
-becomes M.)
-(TBT)
-
+Perl ソースフィルタの書き方を理解するのを助けるために、学習するための
+例が必要です。
+以下は rot13 復号を行う完全なソースフィルタです。
+(rot13 は、攻撃的な投稿を隠すために Usenet 投稿で使われたとても簡単な
+暗号スキームです。
+これはそれぞれの英文字を 13 ずらします; 従って A は N に、B は O に、
+Z は M になります。)
 
    package Rot13;
 
@@ -692,9 +684,8 @@
 
 =end original
 
-All Perl source filters are implemented as Perl classes and have the
-same basic structure as the example above.
-(TBT)
+全ての Perl ソースフィルタは Perl クラスとして実装され、上述の例と
+同じ基本構造を持ちます。
 
 =begin original
 
@@ -705,11 +696,10 @@
 
 =end original
 
-First, we include the C<Filter::Util::Call> module, which exports a
-number of functions into your filter's namespace. The filter shown
-above uses two of these functions, C<filter_add()> and
-C<filter_read()>.
-(TBT)
+まず、C<Filter::Util::Call> をインクルードして、多くの関数をフィルタの
+名前空間にエクスポートします。
+上述のフィルタはこれらの関数の内 C<filter_add()> と C<filter_read()> の
+二つの関数を使います。
 
 =begin original
 
@@ -721,12 +711,13 @@
 
 =end original
 
-Next, we create the filter object and associate it with the source
-stream by defining the C<import> function. If you know Perl well
-enough, you know that C<import> is called automatically every time a
-module is included with a use statement. This makes C<import> the ideal
-place to both create and install a filter object.
-(TBT)
+次に、フィルタオブジェクトを作って、C<import> 関数を定義することによって
+これをソースストリームと結びつけます。
+Perl のことを十分知っているなら、
+C<import> は use 文でモジュールがインクルードされる旅に自動的に
+呼び出されることを知っているでしょう。
+これにより、C<import> はフィルタオブジェクトの作成とインストールに
+最適の場所と言えます。
 
 =begin original
 
@@ -738,12 +729,12 @@
 
 =end original
 
-In the example filter, the object (C<$ref>) is blessed just like any
-other Perl object. Our example uses an anonymous array, but this isn't
-a requirement. Because this example doesn't need to store any context
-information, we could have used a scalar or hash reference just as
-well. The next section demonstrates context data.
-(TBT)
+例のフィルタでは、オブジェクト (C<$ref>) はその他の Perl オブジェクトと
+同じように bless されます。
+この例では無名配列を使っていますが、これは必須ではありません。
+この例では内容の情報を補完する必要がないので、スカラリファレンスや
+ハッシュリファレンスでを使うこともできます。
+次の節ではコンテキストデータを図示します。
 
 =begin original
 
@@ -753,10 +744,10 @@
 
 =end original
 
-The association between the filter object and the source stream is made
-with the C<filter_add()> function. This takes a filter object as a
-parameter (C<$ref> in this case) and installs it in the source stream.
-(TBT)
+フィルタオブジェクトとソースストリームの関連付けは C<filter_add()> 関数で
+行われます。
+これはフィルタオブジェクト (今回の場合では C<$ref>) を引数に取って、
+これをソースストリームに取り付けます。
 
 =begin original
 
@@ -770,14 +761,15 @@
 
 =end original
 
-Finally, there is the code that actually does the filtering. For this
-type of Perl source filter, all the filtering is done in a method
-called C<filter()>. (It is also possible to write a Perl source filter
-using a closure. See the C<Filter::Util::Call> manual page for more
-details.) It's called every time the Perl parser needs another line of
-source to process. The C<filter()> method, in turn, reads lines from
-the source stream using the C<filter_read()> function.
-(TBT)
+最後に、実際にフィルタリングを行うコードがあります。
+この種の Perl ソースフィルタのために、フィルタリングの全ては
+C<filter()> と呼ばれるメソッドで行われます。
+(クロージャを使って Perl ソースフィルタを書くことも可能です。
+さらなる詳細については C<Filter::Util::Call> マニュアルページを
+参照してください。)
+これは Perl パーサが処理するソースの行が必要になる度に毎回呼び出されます。
+C<filter()> メソッドは、C<filter_read()> 関数を使ってソースストリームから
+順番に行を読み込みます。
 
 =begin original
 
@@ -791,14 +783,15 @@
 
 =end original
 
-If a line was available from the source stream, C<filter_read()>
-returns a status value greater than zero and appends the line to C<$_>.
-A status value of zero indicates end-of-file, less than zero means an
-error. The filter function itself is expected to return its status in
-the same way, and put the filtered line it wants written to the source
-stream in C<$_>. The use of C<$_> accounts for the brevity of most Perl
-source filters.
-(TBT)
+ソースストリームから 1 行が利用可能になったら、C<filter_read()> は
+0 より大きいステータス値を返して、C<$_> に行を追加します。
+ステータス値が 0 の場合はファイル末尾を示し、0 より小さい場合は
+エラーを意味します。
+filter 関数自身はステータスを同じ方法で返し、ソースストリームに
+書き込みたいフィルタリングされた行を C<$_> に入れることを
+想定されています。
+C<$_> の使い方はほとんどの Perl ソースフィルタの簡潔さを考慮に
+入れています。
 
 =begin original
 
@@ -808,10 +801,9 @@
 
 =end original
 
-In order to make use of the rot13 filter we need some way of encoding
-the source file in rot13 format. The script below, C<mkrot13>, does
-just that.
-(TBT)
+rot13 フィルタを使うには、ソースファイルを rot13 形式で符号化する
+方法が必要です。
+以下のスクリプト C<mkrot13> はそれを行います。
 
     die "usage mkrot13 filename\n" unless @ARGV;
     my $in = $ARGV[0];
@@ -872,9 +864,8 @@
 
 =end original
 
-The rot13 example was a trivial example. Here's another demonstration
-that shows off a few more features.
-(TBT)
+rot13 の例はつまらない例でした。
+以下は、もういくつかの機能を見せるための例です。
 
 =begin original
 
@@ -901,8 +892,7 @@
 
 =end original
 
-Two special marker lines will bracket debugging code, like this:
-(TBT)
+次のように、二つの特殊なマーカー行でデバッグするコードを囲みます:
 
     ## DEBUG_BEGIN
     if ($year > 1999) {
@@ -1022,16 +1012,15 @@
 
 =end original
 
-The big difference between this filter and the previous example is the
-use of context data in the filter object. The filter object is based on
-a hash reference, and is used to keep various pieces of context
-information between calls to the filter function. All but two of the
-hash fields are used for error reporting. The first of those two,
-Enabled, is used by the filter to determine whether the debugging code
-should be given to the Perl parser. The second, InTraceBlock, is true
-when the filter has encountered a C<DEBUG_BEGIN> line, but has not yet
-encountered the following C<DEBUG_END> line.
-(TBT)
+このフィルタと以前の例との大きな違いは、フィルタオブジェクトの
+コンテキストデータの使用です。
+フィルタオブジェクトはハッシュリファレンスを基礎としていて、フィルタ関数の
+呼び出し間のコンテキスト情報の様々な断片を保持するために使われます。
+二つを除いた全てのハッシュフィールドはエラー報告のために使われます。
+二つの内一番目である Enabled は、デバッグコードが Perl パーサに
+与えられるべきかどうかを決定するために使われます。
+二番目である InTraceBlock は、フィルタが C<DEBUG_BEGIN> に遭遇したけれども
+まだ引き続く C<DEBUG_END> 行に出会っていないときに真となります。
 
 =begin original
 
@@ -1040,9 +1029,8 @@
 
 =end original
 
-If you ignore all the error checking that most of the code does, the
-essence of the filter is as follows:
-(TBT)
+コードのほとんどが行っているエラーチェックの全てを無視すると、フィルタの
+本質は以下のようになります:
 
     sub filter {
        my ($self) = @_;
@@ -1086,9 +1074,8 @@
 
 =end original
 
-Such things aside, you can see that a lot can be achieved with a modest
-amount of code.
-(TBT)
+そのようなことを置いておいても、それほどでもない量のコードで多くのことが
+達成できるのが分かります。
 
 =head1 CONCLUSION
 
@@ -1166,8 +1153,7 @@
 
 =end original
 
-into this:
-(TBT)
+次のように変更します:
 
     sub MySub($$@) {
        my ($first) = shift;
@@ -1201,6 +1187,8 @@
 
 =item Some Filters Clobber the C<DATA> Handle
 
+(一部のフィルタは C<DATA> ハンドルを上書きします)
+
 =begin original
 
 Some source filters use the C<DATA> handle to read the calling program.
@@ -1211,12 +1199,12 @@
 
 =end original
 
-Some source filters use the C<DATA> handle to read the calling program.
-When using these source filters you cannot rely on this handle, nor expect
-any particular kind of behavior when operating on it.  Filters based on
-Filter::Util::Call (and therefore Filter::Simple) do not alter the C<DATA>
-filehandle.
-(TBT)
+一部のソースフィルタは、呼び出したプログラムを読み込むために
+C<DATA> ハンドルを使います。
+これらのソースフィルタを使うときには、このハンドルに依存したり、これを
+操作したときに何らかの特定の振る舞いを想定できません。
+Filter::Util::Call (従って Filter::Simple) を基礎としたフィルタは
+C<DATA> ファイルハンドルを変更しません。
 
 =back
 
@@ -1243,11 +1231,10 @@
 
 =end original
 
-Starting from Perl 5.8 Filter::Util::Call (the core part of the
-Source Filters distribution) is part of the standard Perl distribution.
-Also included is a friendlier interface called Filter::Simple, by
-Damian Conway.
-(TBT)
+Perl 5.8 から、Filter::Util::Call (ソースフィルタ配布のコアの部分) は
+標準 Perl 配布の一部です。
+また、Damian Conway によるより親しみやすいインターフェースである
+Filter::Simple も含まれています。
 
 =head1 AUTHOR
 
Index: docs/perl/5.10.1/perlperf.pod
diff -u docs/perl/5.10.1/perlperf.pod:1.3 docs/perl/5.10.1/perlperf.pod:1.4
--- docs/perl/5.10.1/perlperf.pod:1.3	Sun May 27 22:41:31 2012
+++ docs/perl/5.10.1/perlperf.pod	Tue Jul  3 03:47:00 2012
@@ -91,12 +91,11 @@
 
 まず、既にあるコードの基準になる時間を決定する必要があります; ここで
 時間は信頼性があって再現可能であるものです。
-You'll probably want to use the
-C<Benchmark> or C<Devel::DProf> modules, or something similar, for this step,
-or perhaps the unix system C<time> utility, whichever is appropriate.  See the
-base of this document for a longer list of benchmarking and profiling modules,
-and recommended further reading.
-(TBT)
+おそらく C<Benchmark> または C<Devel::DProf> モジュールやあるいは
+似たようなものか、またはおそらく Unix システムの
+C<time> ユーティリティのような、適切なものを使いたいでしょう。
+ベンチマークとプロファイルのモジュールのより長い一覧および、さらに読むための
+お勧めについてはこの文書の末尾を見てください。
 
 =head2 ONE STEP FORWARD
 
@@ -972,11 +971,9 @@
 =end original
 
 C<Devel::FastProf> はもう一つの Perl 行プロファイラです。
-This was written with a view
-to getting a faster line profiler, than is possible with for example
-C<Devel::SmallProf>, because it's written in C<C>.  To use C<Devel::FastProf>,
-supply the C<-d> argument to Perl:
-(TBT)
+これは、例えば C<Devel::SmallProf> などよりも速い行プロファイラとして
+C<C> で書かれました。
+C<Devel::FastProf> を使うには、 Perl に C<-d> オプションを指定します:
 
     $> perl -d:FastProf wordmatch -f perl5db.pl
 
@@ -1065,16 +1062,17 @@
 
 C<Devel::NYTProf> は B<新世代> Perl コードプロファイラで、他のツールの
 多くの欠点を修正し、多くのクールな機能を実装しています。
-First of all it
-can be used as either a I<line> profiler, a I<block> or a I<subroutine>
-profiler, all at once.  It can also use sub-microsecond (100ns) resolution on
-systems which provide C<clock_gettime()>.  It can be started and stopped even
-by the program being profiled.  It's a one-line entry to profile C<mod_perl>
-applications.  It's written in C<c> and is probably the fastest profiler
-available for Perl.  The list of coolness just goes on.  Enough of that, let's
-see how to it works - just use the familiar C<-d> switch to plug it in and run
-the code.
-(TBT)
+まず、これは I<行> プロファイラと I<ブロック> または
+I<サブルーチン> プロファイラとして一度に使えます。
+また、C<clock_gettime()> を提供しているシステムではマイクロ秒未満 (100ns) の
+解像度を使えます。
+プログラムがプロファイルからでも開始終了できます。
+これは C<mod_perl> アプリケーションをプロファイルする一行エントリです。
+これは C<c> で書かれていて、おそらく Perl で利用可能な最速の
+プロファイラです。
+素晴らしさの一覧はまだ続きます。
+これで十分でしょうから、どのように動作するかを見てみましょう - 単に
+親しんだ C<-d> スイッチを使って、コードを実行します。
 
     $> perl -d:NYTProf wordmatch -f perl5db.pl
 
@@ -1301,9 +1299,10 @@
 
 =end original
 
-Perl modules are not the only tools a performance analyst has at their
-disposal, system tools like C<time> should not be overlooked as the next
-example shows, where we take a quick look at sorting.  Many books, theses and
+Perl モジュールは性能分析者が持っている唯一の道具というわけではなく、
+ソートについて軽く見てみる次の例のように、C<time> のようなシステムツールも
+見落とすべきではありません。
+Many books, theses and
 articles, have been written about efficient sorting algorithms, and this is not
 the place to repeat such work, there's several good sorting modules which
 deserve taking a look at too: C<Sort::Maker>, C<Sort::Key> spring to mind.
@@ -1380,11 +1379,10 @@
 
 =end original
 
-The specific task here is to sort the 286,525 lines of this file by Response
-Code, Query, Browser, Referring Url, and lastly Date.  One solution might be to
-use the following code, which iterates over the files given on the
-command-line.
-(TBT)
+ここでのタスクは Response Code, Query, Browser, Referring Url,
+lastly Date からなる 286,525 行のファイルをソートすることです。
+一つの解決法は、以下のコードのようにコマンドラインで指定されたファイルを
+反復する方法かもしれません。
 
 =begin original
 
@@ -1537,10 +1535,10 @@
 
 =end original
 
-Running this same process as a C<Schwarzian Transform> it is possible to
-eliminate the input and output arrays for storing all the data, and work on the
-input directly as it arrives too.  Otherwise, the code looks fairly similar:
-(TBT)
+同じ処理を C<シュワルツ変換> (Schwarzian Transform) として実行すると、
+全てのデータを補完するための配列の入出力を除去することができ、
+入力を直接届いてすぐに処理します。
+さもなければ、コードはほぼ似て見えます:
 
 =begin original
 
@@ -1548,7 +1546,7 @@
 
 =end original
 
-# apache のログを schwarzian ソート
+# apache のログをシュワルツ変換ソート
 
     #!/usr/bin/perl -n
 
@@ -1611,10 +1609,9 @@
 
 =end original
 
-The time has been cut in half, which is a respectable speed improvement by any
-standard.  Naturally, it is important to check the output is consistent with
-the first program run, this is where the unix system C<cksum> utility comes in.
-(TBT)
+時間は半分になりました; これはあらゆる面で立派な速度改善です。
+当然ながら、出力が最初のプログラムの実行と一貫性があることをチェックするのは
+重要です; ここは Unix システム C<cksum> ユーティリティの出番です。
 
     $> cksum out-sort out-schwarz
     3044173777 52029194 out-sort
@@ -1629,11 +1626,11 @@
 
 =end original
 
-BTW. Beware too of pressure from managers who see you speed a program up by 50%
-of the runtime once, only to get a request one month later to do the same again
-(true story) - you'll just have to point out your only human, even if you are a
-Perl programmer, and you'll see what you can do...
-(TBT)
+ところで。
+あなたが一度実行時間を 50% 高速化したのを見た管理者が喜びすぎて、
+一ヶ月後にもう一度同じことを要求してくることに注意してください(実話) -
+例えあなたが Perl プログラマでもあなたがただの人間であることを
+指摘する必要があり、何ができるかを見てみましょう…
 
 =head1 LOGGING
 
@@ -1649,12 +1646,11 @@
 
 =end original
 
-An essential part of any good development process is appropriate error handling
-with appropriately informative messages, however there exists a school of
-thought which suggests that log files should be I<chatty>, as if the chain of
-unbroken output somehow ensures the survival of the program.  If speed is in
-any way an issue, this approach is wrong.
-(TBT)
+良い開発プロセスの本質的な部分は、適切に情報があるメッセージによる
+適切なエラー処理ですが、プログラムの生存を確実にするための壊れない
+出力のチェーンのように、ログファイルは I<おしゃべり> であるべきという
+考え方があります。
+速度が問題なら、この手法は間違っています。
 
 =begin original
 
@@ -1696,9 +1692,9 @@
 
 =end original
 
-This effect can be demonstrated by setting up a test script with both forms,
-including a C<debug()> subroutine to emulate typical C<logger()> functionality.
-(TBT)
+この効果は、両方の形式で設定したテストスクリプトで図示します;
+これには典型的な C<logger()> 機能をエミュレートするための
+C<debug()> サブルーチンです。
 
 =begin original
 
@@ -1785,7 +1781,7 @@
 
 =end original
 
-# ifdebug-constant
+# ifdebug-定数
 
     #!/usr/bin/perl
 
@@ -1903,13 +1899,12 @@
 
 =end original
 
-As a final thought, remember that it's not (at the time of writing) possible to
-produce a useful program which will run in zero or negative time and this basic
-principle can be written as: I<useful programs are slow> by their very
-definition.
+最後の考慮点として、(これを書いている時点では) ゼロまたは負の時間で
+実行できる有用なプログラムを作成することは不可能であることを
+忘れないでください; そしてこの基本原則は次のように書けます:
+定義により、I<有用なプログラムは遅い>。
 もちろんほぼ瞬間的に動作するプログラムを書くことは可能ですが、とても
 多くのことをすることは出来ません; 以下はとても効率的なものです:
-(TBT)
 
     $> perl -e 0
 



perldocjp-cvs メーリングリストの案内
Zurück zum Archiv-Index