[perldocjp-cvs 382] CVS update: docs/perl/5.8.8

Zurück zum Archiv-Index

argra****@users***** argra****@users*****
2009年 1月 20日 (火) 01:17:32 JST


Index: docs/perl/5.8.8/perlpacktut.pod
diff -u docs/perl/5.8.8/perlpacktut.pod:1.9 docs/perl/5.8.8/perlpacktut.pod:1.10
--- docs/perl/5.8.8/perlpacktut.pod:1.9	Mon Jan  5 04:18:26 2009
+++ docs/perl/5.8.8/perlpacktut.pod	Tue Jan 20 01:17:32 2009
@@ -159,13 +159,13 @@
 仮定できます; その他は ASCII テーブルを持って 1 年生の感覚を思い出す
 必要があります。
 これをどのようにして読むかについてはあまり気にしないことにして、
-we note that C<unpack> with the template code C<H> converts the contents
-of a sequence of bytes into the customary hexadecimal notation. Since
-"a sequence of" is a pretty vague indication of quantity,
+we note that 
+C<unpack> のテンプレートコード C<H> はバイト列の内容をいつもの 16 進表記に
+変換することに注目します。
+「列」というのは量についてあいまいなので、
 C<H> は、引き続いて繰り返し回数がない場合は単に 1 つの 16 進数を
 変換するように定義されています。
 繰り返し数でのアスタリスクは、残っているもの全てを使うことを意味します。
-(TBT)
 
 =begin original
 
@@ -789,15 +789,14 @@
 
 =end original
 
-16 bits won't get you too far with integers, but there is C<l> and C<L>
-for signed and unsigned 32-bit integers. And if this is not enough and
-your system supports 64 bit integers you can push the limits much closer
-to infinity with pack codes C<q> and C<Q>. A notable exception is provided
-by pack codes C<i> and C<I> for signed and unsigned integers of the 
-"local custom" variety: Such an integer will take up as many bytes as
-a local C compiler returns for C<sizeof(int)>, but it'll use I<at least>
-32 bits.
-(TBT)
+16 ビットは整数に十分とは言えませんが、符号付きと符号なしの 32 ビット
+整数のための C<l> と C<L> もあります。
+そして、これで十分ではなく、システムが 64 ビット整数に対応しているなら、
+pack コード C<q> と C<Q> を使って限界をほぼ無限にまで押しやることができます。
+注目すべき例外は pack コード C<i> と C<I> で、「ローカルに特化した」
+符号付きと符号なしの整数を提供します: このような整数は C<sizeof(int)> と
+したときにローカルな C コンパイラが返す値と同じバイト数ですが、
+I<少なくとも> 32 ビットを使います。 
 
 =begin original
 
@@ -918,11 +917,11 @@
 
 =end original
 
-It would be nice if we could do this in one fell swoop: unpack a short,
-back up a little, and then unpack 2 bytes. Since Perl I<is> nice, it
-proffers the template code C<X> to back up one byte. Putting this all
-together, we may now write:
-(TBT)
+これを 1 回で行えたら素敵でしょう: short を unpack して、少し戻って、
+それから 2 バイト unpack します。
+Perl は I<素敵> なので、1 バイト戻るテンプレートコード C<X> を
+提供しています。
+これら全てを一緒にすると、以下のように書けます:
 
    my( $ip, $cs,
        $flags,$fl,$fh,
@@ -948,12 +947,12 @@
 
 =end original
 
-We've taken some pains to construct the template so that it matches
-the contents of our frame buffer. Otherwise we'd either get undefined values,
-or C<unpack> could not unpack all. If C<pack> runs out of items, it will
-supply null strings (which are coerced into zeroes whenever the pack code
-says so).
-(TBT)
+テンプレートを構築するのに少し苦労したのは、フレームバッファの内容に
+一致させるためです。
+さもなければ未定義値を受け取ることになるか、あるいは
+C<unpack> は何も unpack できなくなります。
+もし C<pack> で要素がなくなったら、空文字列を補います
+(pack コードがそうするように言っていれば、ゼロに強制されます)。
 
 =head2 How to Eat an Egg on a Net
 
@@ -981,13 +980,14 @@
 if you know that your data comes from a compliant architecture, but,
 surprisingly enough, you should also use these pack codes if you
 exchange binary data, across the network, with some system that you
-know next to nothing about. The simple reason is that this
-order has been chosen as the I<network order>, and all standard-fearing
-programs ought to follow this convention. (This is, of course, a stern
+know next to nothing about.
+理由は単純で、この順序が I<ネットワーク順序> として選ばれていて、標準を
+恐れる全てのプログラムがこの慣例に従っているはずだからです。
+(This is, of course, a stern
 backing for one of the Lilliputian parties and may well influence the
-political development there.) So, if the protocol expects you to send
-a message by sending the length first, followed by just so many bytes,
-you could write:
+political development there.)
+それで、もし何バイトあるかの長さを先に送ることでメッセージを送ることを
+プロトコルが想定しているなら、以下のように書けます:
 (TBT)
 
    my $buf = pack( 'N', length( $msg ) ) . $msg;
@@ -1011,11 +1011,11 @@
 
 =end original
 
-and pass C<$buf> to your send routine. Some protocols demand that the
-count should include the length of the count itself: then just add 4
-to the data length. (But make sure to read L<"Lengths and Widths"> before
-you really code this!)
-(TBT)
+そして C<$buf> を送信ルーチンに渡します。
+カウントに、カウント自身の長さも含むことを要求しているプロトコルも
+あります: その時は単にデータ長に 4 を足してください。
+(しかし、実際にこれをコーディングする前に L<"Lengths and Widths"> を
+読んでください!)
 
 =head2 Floating point Numbers
 
@@ -1063,15 +1063,14 @@
 
 =end original
 
-Bits are the atoms in the memory world. Access to individual bits may
-have to be used either as a last resort or because it is the most
-convenient way to handle your data. Bit string (un)packing converts
-between strings containing a series of C<0> and C<1> characters and
-a sequence of bytes each containing a group of 8 bits. This is almost
-as simple as it sounds, except that there are two ways the contents of
-a byte may be written as a bit string. Let's have a look at an annotated
-byte:
-(TBT)
+ビットはメモリの世界の原子です。
+個々のビットへのアクセスは、最後の手段として行われるか、それがデータを
+扱うのに最も便利な方法であるときに行われます。
+(un)pack したビット文字列は、C<0> と C<1> の文字からなる文字列と、
+それぞれ 8 ビットを含むバイト列とを変換します。
+バイトの内容をビット文字列として書くには 2 つの方法があるということを除けば、
+これはほとんど見たままの単純さです。
+以下の注釈付きのバイトを見てみましょう:
 
      7 6 5 4 3 2 1 0
    +-----------------+
@@ -1088,11 +1087,11 @@
 
 =end original
 
-It's egg-eating all over again: Some think that as a bit string this should
-be written "10001100" i.e. beginning with the most significant bit, others
-insist on "00110001". Well, Perl isn't biased, so that's why we have two bit
-string codes:
-(TBT)
+卵の食べ方の繰り返しです: これは "10001100" というビット文字列になるべき、
+つまり最上位ビットから始めるべき、と考える人もいますし、
+"00110001" と主張する人もいます。
+ええ、Perl は偏向していないので、これが 2 つのビット文字列コードがある
+理由です:
 
    $byte = pack( 'B8', '10001100' ); # start with MSB
    $byte = pack( 'b8', '00110001' ); # start with LSB
@@ -1142,13 +1141,12 @@
 
 =end original
 
-Converting these two bytes to a string can be done with the unpack 
-template C<'b16'>. To obtain the individual bit values from the bit
-string we use C<split> with the "empty" separator pattern which dissects
-into individual characters. Bit values from the "reserved" positions are
-simply assigned to C<undef>, a convenient notation for "I don't care where
-this goes".
-(TBT)
+これら 2 バイトから文字列への変換は unpack テンプレート C<'b16'> によって
+行われます。
+ビット文字列から個々のビット値を得るには、C<split> を「空」セパレータで
+使うことで個々の文字に切り刻みます。
+「予約された」位置からのビット値は単に C<undef> に代入しておきます;
+これは「この値がどこに行こうが気にしない」ことを示す便利な記法です。
 
    ($carry, undef, $parity, undef, $auxcarry, undef, $zero, $sign,
     $trace, $interrupt, $direction, $overflow) =
@@ -1186,16 +1184,16 @@
 テンプレートの中のもう一つの半端者は C<u> で、「uuencode された文字列」を
 pack します。
 ("uu" は Unix-to-Unix を縮めたものです。)
-Chances are that
-you won't ever need this encoding technique which was invented to overcome
-the shortcomings of old-fashioned transmission mediums that do not support
-other than simple ASCII data. The essential recipe is simple: Take three 
-bytes, or 24 bits. Split them into 4 six-packs, adding a space (0x20) to 
-each. Repeat until all of the data is blended. Fold groups of 4 bytes into 
-lines no longer than 60 and garnish them in front with the original byte count 
-(incremented by 0x20) and a C<"\n"> at the end. - The C<pack> chef will
-prepare this for you, a la minute, when you select pack code C<u> on the menu:
-(TBT)
+あなたには、単純な ASCII データしか対応していない旧式の通信メディアの欠点を
+克服するために開発されたこのエンコーディング技術が必要になる機会は
+なかったかもしれません。
+本質的なレシピは単純です: 3 バイト、または 24 ビットを取ります。
+これを 4 つの 6 ビットに分け、それぞれに空白 (0x20) を加えます。
+全てのデータが混ぜられるまで繰り返します。
+4 バイトの組を 60 文字を超えない行に折り畳み、元のバイト数(0x20 を
+加えたもの)を先頭に置いて、末尾に C<"\n"> を置きます。
+- あなたがメニューから pack コード C<u> を選ぶと、C<pack> シェフは
+即席で、下ごしらえをしてくれます:
 
    my $uubuf = pack( 'u', $bindat );
 
@@ -1390,15 +1388,14 @@
 
 =end original
 
-The pack code C<w> has been added to support a portable binary data
-encoding scheme that goes way beyond simple integers.
+pack コード C<w> は、単純な整数を遠くへ追いやるような、移植性のある
+バイナリデータエンコーディングスキームに対応するために追加されました。
 (詳細については Scarab プロジェクト L<Casbah.org> にあります。)
 BER (Binary Encoded Representation) 圧縮符号なし整数は 128 を基数として、
 最上位ビットを最初にして、可能な限り少ない桁になるように保管します。
 ビット 8 (最上位ビット) は、最後以外のバイトでセットされます。
 BER エンコーディングにはサイズ制限がありませんが、Perl は極端なことは
 しません。
-(TBT)
 
    my $berbuf = pack( 'w*', 1, 128, 128+1, 128*128+127 );
 
@@ -1444,7 +1441,7 @@
 =end original
 
 この機能についてもうすこしだけ探求してみましょう。
-等価な以下のものから始めます:
+以下と等価なものから始めます:
 
    join( '', map( substr( $_, 0, 1 ), @str ) )
 
@@ -1479,8 +1476,8 @@
 
 =end original
 
-(テンプレートは C<A*> 完全な長さでのみ C<$str[0]> を pack することに
-注意してください。)
+(テンプレートは C<A*> は C<$str[0]> を 完全な長さで pack するだけという
+ことに注意してください。)
 
 =begin original
 
@@ -1552,8 +1549,9 @@
 
 =end original
 
-In the previous section we've seen a network message that was constructed
-by prefixing the binary message length to the actual message. You'll find
+前の章で、実際のメッセージの前にメッセージの長さをバイナリで前置することで
+構成されたネットワークメッセージを見ました。
+You'll find
 that packing a length followed by so many bytes of data is a 
 frequently used recipe since appending a null byte won't work
 if a null byte may be part of the data. Here is an example where both
@@ -2105,10 +2103,9 @@
 =end original
 
 どこに罠があるのでしょう?
-Padding is neither required before the first field C<count>,
-nor between this and the next field C<glyph>, so why can't we simply pack
-like this:
-(TBT)
+最初のフィールド C<count> の前や、これと次のフィールド C<glyph> の間に
+パッディングは不要です; それならなぜ以下のように簡単に
+pack できないのでしょう:
 
    # something goes wrong here:
    pack( 's!a' x @buffer,
@@ -2124,12 +2121,12 @@
 
 =end original
 
-This packs C<3*@buffer> bytes, but it turns out that the size of 
-C<buffer_t> is four times C<BUFLEN>! The moral of the story is that
-the required alignment of a structure or array is propagated to the
-next higher level where we have to consider padding I<at the end>
-of each component as well. Thus the correct template is:
-(TBT)
+これは C<3*@buffer> バイトに pack しますが、C<buffer_t> のサイズは
+C<BUFLEN> の 4 倍になるのです!
+このお話の教訓は、構造体や配列で必要なアライメントは、それぞれの要素の
+I<最後に> パッディングを考慮する必要がある場所で、より高いレベルに
+伝播するということです。
+従って、正しいテンプレートは:
 
    pack( 's!ax' x @buffer,
          map{ ( $_->{count}, $_->{glyph} ) } @buffer );
@@ -2163,7 +2160,7 @@
 構造のアライメント制約は、それぞれの要素よりも大きいかもしれません。
 [そしてもしこれが一般的には何も影響を与えないと考えているなら、
 次に見た携帯電話を分解してみてください。
-多くは ARM コアを使っていて、ARM ストラクチャルールでは
+多くは ARM コアを使っていて、ARM 構造体ルールでは
 C<sizeof (foo_t)> == 4 となります]
 
 =head2 Pointers for How to Use Them
Index: docs/perl/5.8.8/perlxstut.pod
diff -u docs/perl/5.8.8/perlxstut.pod:1.10 docs/perl/5.8.8/perlxstut.pod:1.11
--- docs/perl/5.8.8/perlxstut.pod:1.10	Fri Jan 16 04:56:10 2009
+++ docs/perl/5.8.8/perlxstut.pod	Tue Jan 20 01:17:32 2009
@@ -580,6 +580,8 @@
 
 =head2 What has gone on?
 
+(何をしたの?)
+
 =begin original
 
 The program h2xs is the starting point for creating extensions.  In later
@@ -589,8 +591,8 @@
 =end original
 
 プログラム h2xs はエクステンションを作成する出発点となります。
-後の例では、h2xs をヘッダーファイルを読み込んで C のルーチンに対する
-接点のテンプレートを生成するのにどのように使うかを示します。
+後の例では、ヘッダファイルを読み込んで C のルーチンに対する
+接点のテンプレートを生成するのに h2xs をどのように使うかを示します。
 
 =begin original
 
@@ -613,7 +615,7 @@
 
 =end original
 
-.pm と .xs といったファイルはエクステンションの要点からなります。
+.pm と .xs といったファイルはエクステンションの本体を含みます。
 .xs ファイルにはエクステンションを作るための C のルーチンがあります。
 .pm ファイルには Perl がどのようにあなたの作ったエクステンションを
 ロードするかを指示するルーチンがあります。
@@ -647,17 +649,17 @@
 
 =end original
 
-“C<make test>”経由でテストスクリプトを実行することによって、非常に重要な
+"C<make test>" 経由でテストスクリプトを実行することによって、非常に重要な
 幾つかのことを行います。
 これは perl に C<-I> 引数を付けて起動し、これによりエクステンションの
 一部である様々なファイルを見つけることができるようにします。
-エクステンションをテストするのに “make test”を使うのは I<非常に>
+エクステンションをテストするのに "make test" を使うのは I<非常に>
 重要です。
 もし、テストスクリプトをそのまま実行してしまったら、致命的なエラーが
 発生するでしょう。
-テストスクリプトを実行するのに“C<make test>”を使うもう一つの重大な
+テストスクリプトを実行するのに "C<make test>" を使うもう一つの重大な
 理由は、既にあるエクステンションをアップグレードしたものを
-テストしようとしたときに、“C<make test>”を使っていれば、既に
+テストしようとしたときに、"C<make test>" を使っていれば、既に
 あるものではなく、新しいものをテストすることが保証されるためです。
 
 =begin original
@@ -766,7 +768,7 @@
 
 =head2 Writing good test scripts
 
-(よいテストスクリプトを書く)
+(良いテストスクリプトを書く)
 
 =begin original
 
@@ -778,7 +780,7 @@
 =end original
 
 良いテストスクリプトを書くことの重要性は、いくら強調しても足りません。
-Perl 自身が使っている“ok/not ok”の形式を忠実に守り、テストケースで
+Perl 自身が使っている "ok/not ok" の形式を忠実に守り、テストケースで
 どうなったかを簡単に、曖昧なことなくわかるようにします。
 バグを発見して修正したら、テストケースにそれを追加しましょう。
 
@@ -796,7 +798,7 @@
 適切なバージョンのエクステンションを使うことが保証されます。
 たくさんのテストケースがあるのなら、Perl のテストの形式を
 真似たくなるかもしれません。
-エクステンションのディレクトリに“t”という名前のディレクトリを作成して、
+エクステンションのディレクトリに "t" という名前のディレクトリを作成して、
 テストのためのファイルの名前に ".t" の拡張子をつけます。
 "C<make test>" を実行すると、これらのテストファイル全てが実行されます。
 
@@ -855,7 +857,7 @@
 =end original
 
 Makefile を生成してから make を実行します。
-test.pl の BEGIN ブロックで“1..9”を出力するように変更し、さらに以下の
+test.pl の BEGIN ブロックで "1..9" を出力するように変更し、さらに以下の
 行を追加します。
 
 	$i = -1.5; &Mytest::round($i); print $i == -2.0 ? "ok 5" : "not ok 5", "\n";
@@ -870,7 +872,7 @@
 
 =end original
 
-“C<make test>”を実行します。
+"C<make test>" を実行します。
 ここで、九つのテストすべてで ok と出力されるはずです。
 
 =begin original
@@ -1961,11 +1963,10 @@
 =end original
 
 引数スタックの実際の値は渡された値へのポインタです。
-引数が OUTPUT の値として挙げられている場合、its corresponding
-value on the stack (i.e., ST(0) if it was the first argument) is changed.
-You can verify this by looking at the C code generated for Example 3.
-The code for the round() XSUB routine contains lines that look like this:
-(TBT)
+引数が OUTPUT の値として挙げられている場合、スタック上の対応する値
+(例えば、最初の引数なら ST(0)) が変更されます。
+例 3 で生成された C コードを見ることでこれを検証できます。
+round() XSUB ルーチンのコードは以下のように見える行を含んでいます:
 
 	double  arg = (double)SvNV(ST(0));
 	/* Round the contents of the variable arg */
@@ -2005,13 +2006,15 @@
 
 =end original
 
-XSUBs are also allowed to avoid automatic conversion of Perl function arguments
-to C function arguments.  See L<perlxs> for details.  Some people prefer
-manual conversion by inspecting C<ST(i)> even in the cases when automatic
-conversion will do, arguing that this makes the logic of an XSUB call clearer.
-Compare with L<"Getting the fat out of XSUBs"> for a similar tradeoff of
-a complete separation of "Perl glue" and "workhorse" parts of an XSUB.
-(TBT)
+XSUB はまた、Perl 関数引数から C 関数引数への自動変換を回避することも
+できます。
+詳しくは L<perlxs> を参照してください。
+自動変換が行われる場合でも C<ST(i)> を検査することでの手動変換を好む
+人々もいて、これにより XSUB 呼び出しのロジックがよりきれいになると
+主張しています。
+XSUB における「Perl の糊」と「実働部隊」の完全な分離に関する似たような
+トレードオフに関して、L<"Getting the fat out of XSUBs"> と
+比較してください。
 
 =begin original
 
@@ -2023,12 +2026,12 @@
 
 =end original
 
-While experts may argue about these idioms, a novice to Perl guts may
-prefer a way which is as little Perl-guts-specific as possible, meaning
-automatic conversion and automatic call generation, as in
-L<"Getting the fat out of XSUBs">.  This approach has the additional
-benefit of protecting the XSUB writer from future changes to the Perl API.
-(TBT)
+専門家はこれらの慣用法について主張する一方、Perl の内部に関する初心者は
+Perl 内部に固有のものを可能な限り小さくする方法を好みます; これはつまり
+L<"Getting the fat out of XSUBs"> のような、自動変換と自動呼び出し
+生成です。
+この手法には、XSUB 作者を Perl API の将来の変更から守るという追加の利点も
+あります。
 
 =head2 Extending your Extension
 
@@ -2074,10 +2077,9 @@
 あなたは何の言い訳もできません。
 ドキュメントは .pm ファイルに属します。
 このファイルは pod2man に送り込まれ、埋め込まれたドキュメントが
-マニュアルページフォーマットに変換されます。
-その後で blib ディレクトリに置かれます。
+man ページフォーマットに変換され、それから blib ディレクトリに置かれます。
 このドキュメントは、エクステンションがインストールされるときに Perl の
-マニュアルページディレクトリにもコピーされます。
+man ページディレクトリにもコピーされます。
 
 =begin original
 
@@ -2115,7 +2117,7 @@
 
 あなたの作ったエクステンションが完成し、かつすべてのテストに合格すれば、
 それを実に単純なやりかたでインストールします。
-ただ単に“make install”と実行するだけです。
+ただ単に "make install" と実行するだけです。
 Perl がインストールされたディレクトリに対する書き込み権限が持っている
 必要がありますが、あるいは、あなたのシステム管理者にあなたの make を
 実行するようお願いする必要があるでしょう。
@@ -2131,13 +2133,14 @@
 
 =end original
 
-Alternately, you can specify the exact directory to place the extension's
-files by placing a "PREFIX=/destination/directory" after the make install.
-(or in between the make and install if you have a brain-dead version of make).
-This can be very useful if you are building an extension that will eventually
-be distributed to multiple systems.  You can then just archive the files in
-the destination directory and distribute them to your destination systems.
-(TBT)
+別の方法として、"make install" の後ろに (あるいはおかしな make を使っている
+場合は "make" と "install" の間に)"PREFIX=/destination/directory" と
+書くことで、エクステンションのファイルを置く正確なディレクトリを
+指定できます。
+これは、最終的に複数のシステムに配布されるエクステンションをビルドしている
+場合にとても有用です。
+その後単に出力先のディレクトリのファイルをアーカイブして、目的のシステムに
+配布します。
 
 =head2 EXAMPLE 5
 
@@ -2414,10 +2417,9 @@
 
 =end original
 
-In this example, we will accept a reference to an array as an input
-parameter, and return a reference to an array of hashes.  This will
-demonstrate manipulation of complex Perl data types from an XSUB.
-(TBT)
+この例では、入力パラメータとして配列へのリファレンスを受け付け、ハッシュの
+配列へのリファレンスを返します。
+ここでは、複雑な Perl データ型を XSUB から操作する方法を示します。
 
 =begin original
 
@@ -2429,12 +2431,11 @@
 
 =end original
 
-This extension is somewhat contrived.  It is based on the code in
-the previous example.  It calls the statfs function multiple times,
-accepting a reference to an array of filenames as input, and returning
-a reference to an array of hashes containing the data for each of the
-filesystems.
-(TBT)
+このエクステンションはやや不自然です。
+これは以前の例のコードを基礎にしています。
+これは statfs 関数を複数呼び出し、入力としてファイル名の配列への
+リファレンスを受け付けて、それぞれのファイルシステムのデータを含む
+ハッシュの配列へのリファレンスを返します。
 
 =begin original
 
@@ -2762,13 +2763,13 @@
 
 =end original
 
-The standard typemap offers three variants of PerlIO *:
-C<InputStream> (T_IN), C<InOutStream> (T_INOUT) and C<OutputStream>
-(T_OUT). A bare C<PerlIO *> is considered a T_INOUT. If it matters
-in your code (see below for why it might) #define or typedef
-one of the specific names and use that as the argument or result
-type in your XS file.
-(TBT)
+標準 typemap は 3 種類の PerlIO * を提供します:
+C<InputStream> (T_IN), C<InOutStream> (T_INOUT),
+C<OutputStream> (T_OUT) です。
+生の C<PerlIO *> は T_INOUT として扱われます。
+コード中でこれが問題になる場合(なぜそうなり得るかは以下を
+参照してください)、特定の名前の一つを #define や typedef して、
+それを XS ファイルで引数や結果の型として使ってください。
 
 =begin original
 
@@ -2778,10 +2779,10 @@
 
 =end original
 
-The standard typemap does not contain PerlIO * before perl 5.7,
-but it has the three stream variants. Using a PerlIO * directly
-is not backwards compatible unless you provide your own typemap.
-(TBT)
+perl 5.7 以前の標準 typemap には PerlIO * は含まれていませんが、
+3 種類のストリームの種類があります。
+PerlIO * を直接使うと、独自の typemap を提供しない限り、
+後方互換ではありません。
 
 =begin original
 
@@ -2791,10 +2792,9 @@
 
 =end original
 
-For streams coming I<from> perl the main difference is that
-C<OutputStream> will get the output PerlIO * - which may make
-a difference on a socket. Like in our example...
-(TBT)
+perl I<から> 来るストリームについて、主な違いは C<OutputStream> が
+出力 PerlIO * を得るということです - これはソケットの場合に違いとなります。
+私たちの例と同様に…
 
 =begin original
 
@@ -2807,13 +2807,14 @@
 
 =end original
 
-For streams being handed I<to> perl a new file handle is created
-(i.e. a reference to a new glob) and associated with the PerlIO *
-provided. If the read/write state of the PerlIO * is not correct then you
-may get errors or warnings from when the file handle is used.
-So if you opened the PerlIO * as "w" it should really be an
-C<OutputStream> if open as "r" it should be an C<InputStream>.
-(TBT)
+perl I<に> 渡されるストリームについて、新しいファイルハンドル
+(つまり、新しいグロブへのリファレンス)が作成され、提供された PerlIO * と
+結び付けられます。
+もし PerlIO * の読み込み/書き込み状態が正しくない場合、ファイルハンドルが
+使われたときにエラーや警告を受けることになります。
+従って、もし PerlIO * を "w" としてオープンしたなら実際には 
+C<OutputStream> であるべきですし、"r" としてオープンしたなら
+C<InputStream> であるべきです。
 
 =begin original
 
@@ -2904,14 +2905,15 @@
 
 =end original
 
-Note: C<PerlIO_findFILE()> will search the layers for a stdio
-layer. If it can't find one, it will call C<PerlIO_exportFILE()> to
-generate a new stdio C<FILE>. Please only call C<PerlIO_exportFILE()> if
-you want a I<new> C<FILE>. It will generate one on each call and push a
-new stdio layer. So don't call it repeatedly on the same
-file. C<PerlIO()>_findFILE will retrieve the stdio layer once it has been
-generated by C<PerlIO_exportFILE()>.
-(TBT)
+注意: C<PerlIO_findFILE()> は stdio 層の層を検索します。
+もしそれが見つからなければ、新しい stdio C<FILE> を生成するために
+C<PerlIO_exportFILE()> を呼び出します。
+I<新しい> C<FILE> が必要な場合にのみ C<PerlIO_exportFILE()> を
+呼び出すようにしてください。
+これは呼び出し毎に新しいものを生成して新しい stdio 層にプッシュします。
+従って、同じファイルに対して繰り返し呼び出さないでください。
+C<PerlIO()>_findFILE は、一度 C<PerlIO_exportFILE()> で生成された stdio 層を
+取り出します。
 
 =begin original
 


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