Kentaro Shirakata
argra****@users*****
2006年 8月 9日 (水) 04:15:36 JST
Index: docs/perl/5.8.4/perl58delta.pod
diff -u docs/perl/5.8.4/perl58delta.pod:1.9 docs/perl/5.8.4/perl58delta.pod:1.10
--- docs/perl/5.8.4/perl58delta.pod:1.9 Tue Apr 25 04:14:09 2006
+++ docs/perl/5.8.4/perl58delta.pod Wed Aug 9 04:15:36 2006
@@ -647,16 +647,16 @@
=end original
-Previous versions of perl and some readings of some sections of Camel
-III implied that the C<:raw> "discipline" was the inverse of C<:crlf>.
-Turning off "clrfness" is no longer enough to make a stream truly
-binary. So the PerlIO C<:raw> layer (or "discipline", to use the Camel
-book's older terminology) is now formally defined as being equivalent
-to binmode(FH) - which is in turn defined as doing whatever is
-necessary to pass each byte as-is without any translation. In
-particular binmode(FH) - and hence C<:raw> - will now turn off both
-CRLF and UTF-8 translation and remove other layers (e.g. :encoding())
-which would modify byte stream.
+以前のバージョンの perl や、ラクダ本 III では
+C<:raw> "discipline" は C<:crlf> の逆であることを暗示しています。
+もはや完全にバイナリにするには "crlf 化" をオフにするだけでは不十分です。
+PerlIO C<:raw> 層 (あるいはラクダ本の古い用語では "discipline") が
+公式に binmode(FH) と等価となりました - これは全てのバイトを
+一切の変換なしにそのまま通過させるために必要なことをするものとして
+定義されました。
+特に、binmode(FH) - そして C<:raw> も - はバイトストリームを
+変更する CRLF と UTF-8 変換やその他の層 (つまり :encoding()) を
+オフにします。
=item *
@@ -2024,9 +2024,9 @@
=end original
-C<Cwd> now has a split personality: if possible, an XS extension is
-used, (this will hopefully be faster, more secure, and more robust)
-but if not possible, the familiar Perl implementation is used.
+C<Cwd> は分離した性格を持つようになりました; 可能であれば XS 拡張
+が使われ(これはより高速で、より安全で、より頑強であることが期待できます)、
+不可能であれば、慣れ親しんだ Perl の実装が使われます。
=item *
@@ -3559,15 +3559,15 @@
=end original
-C<h2xs> uses the new L<ExtUtils::Constant|ExtUtils::Constant> module
-which will affect newly created extensions that define constants.
-Since the new code is more correct (if you have two constants where the
-first one is a prefix of the second one, the first constant B<never>
-got defined), less lossy (it uses integers for integer constant,
-as opposed to the old code that used floating point numbers even for
-integer constants), and slightly faster, you might want to consider
-regenerating your extension code (the new scheme makes regenerating
-easy). L<h2xs> now also supports C trigraphs.
+C<h2xs> は新しい L<ExtUtils::Constant|ExtUtils::Constant> モジュールを
+使うようになったので、定数を定義する新しく作成された拡張に影響を与えます。
+新しいコードはより正しく(ある定数がもう一つの定数の接頭辞となっているような
+二つの定数がある場合、一つ目の定数は B<決して> 定義されません)、
+誤差が少なく(古いコードは整数定数にも浮動小数点数を使っていましたが、
+整数定数には整数を使うようになりました)、
+少し速くなりましたので、すでにある拡張コードを再生成することを考慮するべき
+かもしれません(新しいスキーマは簡単に再生成できます)。
+L<h2xs> は C トライグラフにも対応しました。
=item *
@@ -4093,7 +4093,8 @@
また、十分に多い数の円周率の場合は、Perl 5.8 のクイックソート
アルゴリズムは、同じ入力のソートを再実行した場合でも
同じ結果にはなりません。
-TBT
+これの正当化は、クイックソートの最悪の場合の振る舞いと
+共に残ります。
以下を実行すると:
sort { $a <=> $b } ( 1 .. $N , 1 .. $N );
@@ -4171,13 +4172,13 @@
示します: (1..$N, 1..$N) のソートは O(N) 時間です。
しかしクイックソートは、ある種の入力とプラットフォームでは
マージソートより速いという理由で最後の瞬間に救出されました。
-For example, if you really I<don't> care about the order of even
-and odd digits, quicksort will run in O(N) time; it's very good
-at sorting many repetitions of a small number of distinct elements.
-The quicksort divide and conquer strategy works well on platforms
-with relatively small, very fast, caches. Eventually, the problem gets
-whittled down to one that fits in the cache, from which point it
-benefits from the increased memory speed.
+例えば、偶数と奇数の順番を I<気にしない> のであれば、
+クイックソートは O(N) 時間で実行されます;
+これは異なった少しの要素を何回もソートするにはよいものです。
+クイックソートの分割統治戦略は比較的小さいがとても早いキャッシュをもつ
+プラットフォームでよく動きます。
+最終的に問題はキャッシュに収まるサイズに分割され、
+それによりメモリ速度工場の恩恵を受けられます。
=begin original
@@ -4191,13 +4192,15 @@
=end original
-Quicksort was rescued by implementing a sort pragma to control aspects
-of the sort. The B<stable> subpragma forces stable behaviour,
-regardless of algorithm. The B<_quicksort> and B<_mergesort>
-subpragmas are heavy-handed ways to select the underlying implementation.
-The leading C<_> is a reminder that these subpragmas may not survive
-beyond 5.8. More appropriate mechanisms for selecting the implementation
-exist, but they wouldn't have arrived in time to save quicksort.
+クイックソートは、ソートの様相を制御する sort プラグマの実装によって
+救出されました。 B<stable> 副プラグマはアルゴリズムに関わらず
+安定した振る舞いを強制します。
+B<_quicksort> と B<_mergesort> 副プラグマは内在する実装を
+選択する荒っぽい方法です。
+先頭の C<_> は、この副プラグマが 5.8 以降まで生き残らないかもしれない
+ことを示しています。
+実装を選択するためのより適切な機構がありますが、
+クイックソートの救出には間に合いませんでした。
=item *
@@ -7490,11 +7493,13 @@
=end original
-Some extensions like mod_perl are known to have issues with
-`largefiles', a change brought by Perl 5.6.0 in which file offsets
-default to 64 bits wide, where supported. Modules may fail to compile
-at all, or they may compile and work incorrectly. Currently, there
-is no good solution for the problem, but Configure now provides
+mod_perl のような拡張は `largefiles' として知られ、
+Perl 5.6.0 から、ファイルオフセットをデフォルト 64 bit 長にする
+変更が対応しました。
+モジュールが全くコンパイルできなかったり、コンパイルできても
+動作しなかったりします。
+現在のところ、この問題のよい解決法はありませんが、
+but Configure now provides
appropriate non-largefile ccflags, ldflags, libswanted, and libs
in the %Config hash (e.g., $Config{ccflags_nolargefiles}) so the
extensions that are having problems can try configuring themselves
@@ -8335,11 +8340,12 @@
=end original
-For tests 129 and 130, the failing platforms do not comply with
-the ANSI C Standard: lines 19ff on page 134 of ANSI X3.159 1989, to
-be exact. (They produce something other than "1" and "-1" when
-formatting 0.6 and -0.6 using the printf format "%.0f"; most often,
-they produce "0" and "-0".)
+テスト 129 と 130 について、失敗するプラットフォームは
+ANSI C 標準 (正確に言うと ANSI X3.159 1989 の 134 ページ の
+ライン 19ff) に従っていません。
+(これは printf フォーマット "%.0f" を使って 0.6 と -0.6 を
+フォーマットしたときに "1" と "-1" 以外の何かを生成しています;
+もっとも良くある場合は、"0" と "-0" を生成しています。)
=head2 SCO
@@ -8576,9 +8582,9 @@
=end original
-z/OS has rather many test failures but the situation is actually much
-better than it was in 5.6.0; it's just that so many new modules and
-tests have been added.
+z/OS では多くのテストで失敗しますが、実際のところ状況は 5.6.0 より
+大きく改善しています; これは単に多くのモジュールとテストが
+追加されたからです。
Failed Test Stat Wstat Total Fail Failed List of Failed
---------------------------------------------------------------------------
@@ -8618,6 +8624,8 @@
=head2 Unicode Support on EBCDIC Still Spotty
+(EBCDIC での Unicode 対応はまだむらがあります)
+
=begin original
Though mostly working, Unicode support still has problem spots on
@@ -8627,10 +8635,12 @@
=end original
-Though mostly working, Unicode support still has problem spots on
-EBCDIC platforms. One such known spot are the C<\p{}> and C<\P{}>
-regular expression constructs for code points less than 256: the
-C<pP> are testing for Unicode code points, not knowing about EBCDIC.
+EBCDIC プラットフォームでの Unicode 対応は、ほとんどは動作しますが、
+まだ問題点があります。
+このような問題点の一つは、コードポイント 256 未満の
+C<\p{}> と C<\P{}> 正規表現定数です;
+C<pP> は Unicode コードポイントについてテストされ、
+EBCDIC については知りません。
=head2 Seen In Perl 5.7 But Gone Now