32468-33485

32267-32679 subjects 32556-36099

Iconv.list patch for NetBSD/Citrus
32468 [naruse@ai em] NetBSD の Citrus iconv で対応エンコーディングのリストを得るパッチです。
32469 [nobu@ru y- a] __で始まっているあたりが、消えたりしないかちょっと不安な気もしま
32470 [naruse@ai em] r14115 にてコミットしました。

about to_path and to_open
32473 [mame@ts .n .] くだらないことで恐縮ですが、require 0 の例外メッセージが変です。
+ 32474 [nobu@ru y- a] to_openは最近入ったものなので、pathname.rbが未対応ですね。
| + 32477 [mame@ts .n .] あれ、でも to_open で検索すると [ruby-dev:23479] がひっかかります。
| | 32478 [nobu@ru y- a] いや、すいません。勘違いでした。しばらく前にruby-coreのほうで
| + 32479 [akr@fs j. rg] 現状、これがないと open に Pathname が使えないのでコミットし
|   32481 [mame@ts .n .] ご説明ありがとうございました。
|   32483 [matz@ru y- a] 「直接ファイルに結びついていないなにかを(Stringでないオブジェ
|   32486 [mame@ts .n .] うーん、やっぱりそうですか。ありがとうございます。
+ 32480 [nobu@ru y- a] String以外では常にto_openを呼ぶようになっていますが、Stringに対
  32482 [matz@ru y- a] コミットしてください。

ext/tk/sample/tkextlib/vu/canvSticker2.rb
32475 [akr@fs j. rg] ext/tk/sample/tkextlib/vu/canvSticker2.rb
32476 [nagai@ai ky ] え〜っと,何なんでしょうね?(^_^;

self-calling method dumps core
32485 [shiba@ma l2 ] 自分自身の評価結果を返すメソッドを呼ぶとcoreを吐くようです。
32490 [nobu@ru y- a] 無限再帰ですから、スタックオーバーフローです。
32492 [ko1@at ot ne]  この例だけで言えば,Ruby レベルでの再帰ですので,スタックオーバー

Regexp#names, MatchData#names, MatchData#regexp
32493 [akr@fs j. rg] named capture まわりをそろえていて、やはり名前のリストを得る
32494 [akr@fs j. rg] うぅむ。MatchData#pretty_print で名前も出そうと思ったら
32496 [matz@ru y- a] named captureは手つかずだったので助かります。

\xHH
32495 [akr@fs j. rg] String#inspect だけじゃなくて、片っ端から変えるとこんなとこ
+ 32497 [matz@ru y- a] これもコミットしてください。
+ 32511 [duerst@it ao] 田中さん、こんにちは。

Re: [ruby-cvs:21399] Ruby:r14162 (trunk): * parse.y (expr): redefinable not (!) operator.
32498 [ko1@at ot ne]  この修正の後, test-all が動かなくなりました.
+ 32499 [matz@ru y- a] 遅くなったのは申し訳ないですが、このタイミングを逃すと何年も
| 32501 [ko1@at ot ne]  性能面は,頑張ればなんとかなるような気もします.仕様的には議論は煮
| + 32505 [matz@ru y- a] 自分の中では。見落としがあるといけませんが。
| | 32508 [ko1@at ot ne]  ちなみに,どんな場合に便利なんでしょうか.
| | 32510 [matz@ru y- a] Ambitiousのように受け取ったメソッドを記録して再生するような
| + 32507 [nobu@ru y- a] x != y は !(x == y) と等価なので、!の再定義とは直接関係はないと
+ 32548 [mame@ts .n .] この変更で、! の中で範囲式が使えなくなっています。
  32549 [matz@ru y- a] これもそろそろやめたい仕様ではあるのですが(あまりにPerlish)、

:!@.inspect
32502 [zn@mb .n ft ] % ruby-trunk -vde 'p :!@'
32504 [matz@ru y- a] これは仕様です。:"!@"は:"!"の別名です。同じようなものとして

ruby-core:13961での問題(Error while bulding Ruby 1.9 from snapshot 2007/12/09)
32509 [kimura.koich] で、ptyの拡張ライブラリが絡んでビルドができないという報告が出てますが、

Re: [ruby-cvs:21409] Ruby:r14172 (trunk): * transcode.c: new file to provide encoding conversion features.
32512 [nobu@ru y- a] 変換テーブルを自前で持つようにするんでしょうか。メンテナンスを考
+ 32513 [matz@ru y- a] これはICUからコピーしてきたものだそうです。テーブルそのものは
| 32516 [duerst@it ao] ちょっとだけ違います。ICU のではなく、cygwin の iconv です。
+ 32517 [duerst@it ao] 中田さん、こんにちは。
| + 32545 [naruse@ai em] 日本語ですと、最重要なのが Shift_JIS と EUC-JP で、ISO-2022-JP と CP932
| | 32594 [duerst@it ao] 成瀬さん、こんにちは。
| | 32602 [naruse@ai em] まず、iconv といっても主要なところで glibc iconv、GNU libiconv、Citrus
| + 32546 [naruse@ai em] statefullなエンコーディングにもいろいろありますが、ISO-2022-JP に限って
+ 32520 [duerst@it ao] 中田さん、こんにちは。
  + 32523 [matz@ru y- a] パッチをください。私が当てます。Martinさんにはコミット権をあ
  + 32527 [nobu@ru y- a] 直しました。一緒に、登録していないEncodingに変換した場合は、変換
    + 32532 [duerst@it ao] ありがとうございました。大変助かりました。
    | 32555 [duerst@it ao] 松本さん、中田さん、こんにちは。
    | 32562 [nobu@ru y- a] たしかに。逆に、encodeを先にするとforce_encodingのほうもセットさ
    | + 32573 [duerst@it ao] そうですね。Encoding ようの String などのフラグも含め、
    | + 32579 [matz@ru y- a] この「必要なencodingは単にreplicateだけするライブラリ」という
    | | 32580 [nobu@ru y- a] 今Init_Encoding()でやっているようなことを抜き出して
    | + 32591 [duerst@it ao] 中田さん、こんにちは。
    + 32535 [matz@ru y- a] 知らないエンコーディングについてはascii-8bitのままでいいので
      32537 [duerst@it ao] これは「知らないエンコーディングは ascii-8bit のではなく、
      32538 [matz@ru y- a] そういう手もあると思いますが、上で考えていたのは
      32539 [nobu@ru y- a] 全部unknown-8bitになってしまうと、たとえばiso-8859-1と
      + 32540 [matz@ru y- a] そーかあ、それで十分かなあ。
      + 32541 [duerst@it ao] そうですね。後は例えば marshall したら、将来に例えば iso-8859-1

typo in lib/uri/common.rb
32514 [s-ueda@li ed] URIの正規表現用文字列にtypoがあります。
32515 [matz@ru y- a] 1.9, 1.8ともに取り込みました。

bug in Array#slice!
32518 [snakagawa@in] [ruby-dev:31761] で一度レポートしたのですが、Array の基
32519 [knu@iD em ns]  これは [ruby-dev:31671] ですかね。見落とされている…。
+ 32521 [snakagawa@in] すみません。その通りでした。
+ 32522 [matz@ru y- a] そうみたいです。ごめんなさい。
  32524 [knu@iD em ns]  僕もです。1.8 も該当するし、 Array#slice! という名前を提案した
  32528 [knu@iD em ns]  先の修正だけだと Range を渡した場合に rb_range_beg_len() に
  32529 [matz@ru y- a] お手数かけました。ありがとうございます。

eigenmethod definition for BasicObjects dumps core
32531 [shiba@ma l2 ] BasicObjectの特異メソッドを定義すると、coreを吐くようです。
32534 [matz@ru y- a] BasicObjectの未定義メソッドを呼ぶだけで落ちてました。

timezone 関数が cygwin  で見つかりません
32536 [duerst@it ao] ルビ開発者の皆さん、
32577 [nobu@ru y- a] わたなべさんによると、最近は頻繁に変更が入っているので、今は手を
+ 32578 [matz@ru y- a] では、コミットしてください。
+ 32593 [duerst@it ao] 中田さん、こんにちは。

Ruby の知らない encoding、あれ以外の encoding
32542 [naruse@ai em] [ruby-dev:32456] を蒸し返すと、
32543 [fumiyas@os t] CP932 と Shift_JIS は別物なんですが、同一扱いにして
+ 32544 [naruse@ai em] CP932 も Shift_JIS も、文字が
+ 32574 [duerst@it ao] iconv では CP932 の1バイト文字は完全に ASCII として扱われ、
  32582 [naruse@ai em] えぇ、それがいいと思います。Perl/Encode テーブルもそうなっていました。
  32600 [paptimusx@gm] 途中から読んだので話の流れがよくわからないのですが、Perlの文字変換の
  32601 [naruse@ai em] Shift_JIS には丸付き文字や波ダッシュ等は含まれていませんから、当然の挙動
  32621 [paptimusx@gm] まさかとはおもいつつもShift_JISとcp932を一緒にしてしまえ、という話かと

Binary String
32550 [nagai@ai ky ] encoding についての話です.間違っていれば訂正ください.
32551 [matz@ru y- a] default_externalが設定されていれば、そのエンコーディングであ
32552 [nagai@ai ky ] 「そのエンコーディングであると分かっている」というのが曲者です.
32553 [matz@ru y- a] あー、すいません。そこはまだ実装されていないのです。ので、現
+ 32554 [duerst@it ao] 確認ですが、
+ 32560 [nagai@ai ky ] あ,そういうことですか.
  + 32561 [nobu@ru y- a] LANGがセットされていなかったり、対応していないエンコーディングが
  | + 32584 [nagai@ai ky ] binary data 用 encoding が導入されることに期待します.
  | + 33018 [nagai@ai ky ] これに期待しているのですが,導入はダメなのでしょうか?
  |   + 33019 [akr@fs j. rg] なんで ASCII-8BIT だと役に立たないのか理解できないんですが、
  |   | 33024 [nagai@ai ky ] 前提条件の記述が足りませんでしたね.ごめんなさい.
  |   | 33027 [akr@fs j. rg] 基本方針として、ASCII でない文字列を ASCII-8BIT で扱うのは例
  |   | + 33028 [matz@ru y- a] ただ、default_externalがASCII-8BITになってしまうケースがどう
  |   | | + 33031 [naruse@ai em] むしろ default_external の問題だと捉えるべきなのですかね。ASCII-8BIT で
  |   | | | 33032 [matz@ru y- a] その方向で対応できるなら、そちらが理想だと思います。ところで
  |   | | | + 33034 [naruse@ai em] ううん、どうなんだろうと迷ってSUSv3を見たところ、“The tables in Locale
  |   | | | + 33037 [akr@fs j. rg] LANG=C locale charmap で ANSI_X3.4-1968 が帰ってくるような実
  |   | | |   + 33038 [naruse@ai em] わたしは“For other characters, the behavior is unspecified.”をどう解釈す
  |   | | |   | 33039 [akr@fs j. rg] そういえば、LANG=C で Encoding.locale_charmap が "US-ASCII"
  |   | | |   + 33040 [matz@ru y- a] いえ、違うようにしたいわけじゃないんです。永井さんの立場で考
  |   | | + 33042 [nagai@ai ky ] そうですね.
  |   | + 33041 [nagai@ai ky ] であるなら,byte sequence ではない String には
  |   |   + 33046 [matz@ru y- a] まず、私はBINARYの導入に反対しているわけではありません、と明
  |   |   + 33047 [akr@fs j. rg] 私は、不適切なものが充分に少なければいいだろうと思っています。
  |   |     + 33051 [matz@ru y- a] 相手がUTF-8のようなASCIIの上位互換のエンコーディングが処理対
  |   |     + 33055 [nagai@ai ky ] デフォルトではそれもありという気はしますが,
  |   |     | + 33062 [duerst@it ao] そうですね。どうしてもルビそのものや鬼車ではサポートしてないが
  |   |     | | 33066 [nagai@ai ky ] encoding 名は例ですが,
  |   |     | + 33080 [akr@fs j. rg] そういうときはやはり具体的な問題に立ち帰るのがいいんじゃない
  |   |     |   33104 [nagai@ai ky ] 以下は「推測」とは別の話なので
  |   |     |   + 33108 [naruse@ai em] で、本当に binary が識別可能じゃないとだめなの?ってのが疑問ですね。
  |   |     |   | + 33109 [yu_raku_an@y] あの、前にも出してスルーされちゃった話で恐縮ですが…
  |   |     |   | | + 33110 [naruse@ai em] [ruby-dev:33027] や [ruby-dev:33029] [ruby-dev:33035] あたりで言われてい
  |   |     |   | | | 33115 [yu_raku_an@y] なるほど、そうでしたか。「ASCII-8BIT」という名前から
  |   |     |   | | + 33120 [duerst@it ao] そうですよね。
  |   |     |   | + 33121 [nagai@ai ky ] ダメだと思います.
  |   |     |   |   33123 [naruse@ai em] あぁ、tk_call_without_enc は変換しないんですね。それでは、バイナリデータ
  |   |     |   |   33127 [nagai@ai ky ] それを呼ぶ前段階で変換が必要ですから,解決しません.
  |   |     |   |   33138 [naruse@ai em] ふーむ、まぁラッパーだとそうなってしまうのですかねぇ。
  |   |     |   |   + 33140 [usa@ga ba ec] というか、1.9で動かす時にmagic commentかそれに類する指定が必
  |   |     |   |   | 33148 [nagai@ai ky ] いえ,スクリプトには日本語が入っていないけれども,
  |   |     |   |   | 33149 [zn@mb .n ft ] バイナリに「バイナリだよ」と印をつけられるタイミングが
  |   |     |   |   | 33150 [nagai@ai ky ] あ,この「印をつける」というのは Tk → Ruby の際に
  |   |     |   |   + 33147 [nagai@ai ky ] まぁ,別の世界との間での擦り合わせの問題だとは思いますが,
  |   |     |   |     33152 [naruse@ai em] 変換についての文脈では、ASCII only の文字列が ASCII-8BIT で返ってきても
  |   |     |   |     33153 [yu_raku_an@y] どんな文脈でもASCII onlyの文字列が「ASCII-8BIT」じゃまずいですよ。
  |   |     |   |     33154 [naruse@ai em] ASCII only はエンコーディングに関わらず結合・比較等において特別扱いなの
  |   |     |   |     + 33157 [matz@ru y- a] 私はEUC-JPになるべきだと思います。現状そうなっているのは7bit
  |   |     |   |     | + 33158 [akr@fs j. rg] [ruby-dev:32046] に書いたあたりですかね。
  |   |     |   |     | | 33184 [naruse@ai em] えーっと、改めて見直してみました。
  |   |     |   |     | | 33194 [akr@fs j. rg] そういえば、人間の都合ではなく実装の都合ですが、性能の話もあ
  |   |     |   |     | | 33201 [naruse@ai em] えぇ、それは理解してます。しかし、その確認にかかるコストは以下の通りです
  |   |     |   |     | | 33203 [akr@fs j. rg] それで済めばとても幸せなんですが、残念なことに文字列は変更さ
  |   |     |   |     | | 33227 [naruse@ai em] これも変更をきちんと追って行けば、究極的にはgsub等で8bitな文字が抜けて、
  |   |     |   |     | + 33330 [naruse@ai em] というわけで、[ruby-dev:33203] だと難しいようですので、とりあえず
  |   |     |   |     |   + 33332 [matz@ru y- a] どうぞ。
  |   |     |   |     |   + 33336 [akr@fs j. rg] このあたりの影響で、テストの失敗が増えているようです。
  |   |     |   |     |     + 33337 [matz@ru y- a] とりあえず、\x80以上のエスケープシーケンスを含む場合には
  |   |     |   |     |     | 33346 [usa@ga ba ec] ということは、エラーにするかASCII-8BITにするかだと思うんです
  |   |     |   |     |     | 33348 [matz@ru y- a] ASCII-8BITを押します。
  |   |     |   |     |     | 33352 [usa@ga ba ec] 文字列リテラルに関してはそれがいいと思うんですが、正規表現リ
  |   |     |   |     |     | 33353 [matz@ru y- a] 正規表現でもASCII-8BITがいいんじゃないかと思います。1.8での
  |   |     |   |     |     | 33355 [usa@ga ba ec] しかしそこまでやるとscript encodingをASCII-8BITにした場合と
  |   |     |   |     |     | 33356 [matz@ru y- a] いや、だって\xA2とか入ってるんですよ。US-ASCIIではありえんじゃ
  |   |     |   |     |     | 33357 [zn@mb .n ft ] script encodingがUS-ASCIIということは1.9対応を考慮して書かれた
  |   |     |   |     |     | 33358 [matz@ru y- a] 今はデフォルトがUS-ASCIIなんでscript encodingがUS-ASCIIだか
  |   |     |   |     |     | + 33360 [akr@fs j. rg] えーと、食い違ってはいない可能性もありますが、とりあえず、エ
  |   |     |   |     |     | | 33361 [matz@ru y- a] あ、そうか。エスケープされたbyte(後者)のことです。
  |   |     |   |     |     | | 33378 [zn@mb .n ft ] [ruby-dev:33357]の時点ではRegexp#sourceがUS-ASCIIの範囲内の
  |   |     |   |     |     | + 33365 [usa@ga ba ec] え、デフォルトはASCII-8BITじゃなかったでしたっけ?
  |   |     |   |     |     |   + 33366 [usa@ga ba ec] 記憶喪失だったようです。これも確認済みでしたね。
  |   |     |   |     |     |   + 33369 [naruse@ai em] これはたぶん、locale_charmap が空の時の default_external と混同なさって
  |   |     |   |     |     |     33370 [usa@ga ba ec] あれ、でも、現実がそうなってませんよ?
  |   |     |   |     |     |     33371 [naruse@ai em] いや、そこの意味でなく、えーっと、
  |   |     |   |     |     |     33372 [usa@ga ba ec] ひょっとして、「混同なさっている」の主語は私じゃない?
  |   |     |   |     |     |     33373 [naruse@ai em] あああ、[ruby-dev:33358] のまつもとさんですね。
  |   |     |   |     |     + 33339 [naruse@ai em] とりあえず、テストを修正するべきものを直しました。
  |   |     |   |     |       33344 [usa@ga ba ec] こうですかね。
  |   |     |   |     |       33349 [matz@ru y- a] コミットしてください。
  |   |     |   |     + 33161 [nagai@ai ky ] え? この状況は,単にまだ対応できていない/対応が確定していないという
  |   |     |   |       33162 [naruse@ai em] いえ、[ruby-dev:32046] で一度出ているのですよ。当時と状況が若干異なって
  |   |     |   + 33122 [akr@fs j. rg] 具体的な問題の例はありませんか?
  |   |     |     33126 [nagai@ai ky ] すみません.現在手持ちのサンプルがありません.
  |   |     |     + 33128 [nagai@ai ky ] 昔の話なので,記憶違いがあるかもしれません.
  |   |     |     + 33151 [akr@fs j. rg] [ruby-dev:33121] で述べられている 1.8 との互換性に関する話は、
  |   |     |       33160 [nagai@ai ky ] う〜ん.結果としては問題ないのかもしれませんが,
  |   |     |       33165 [akr@fs j. rg] 用途によるんじゃないでしょうか。
  |   |     |       + 33178 [gimite@gm il] 横からすいません。
  |   |     |       | 33179 [naruse@ai em] Tcl/Tk の文脈では、ASCII-8BIT ならば変換しない、なので「問題がない」と思
  |   |     |       | 33180 [gimite@gm il] なるほど。僕は一応このTkのケースでも区別できたほうがいいと考えています。というのは、区別できない場合は
  |   |     |       | 33181 [naruse@ai em] それって、一見 strict でいい感じに見えますけれど、実装は ASCII-8BIT が来
  |   |     |       | 33182 [gimite@gm il] 「基本方針として、ASCII でない文字列を ASCII-8BIT
  |   |     |       | 33183 [naruse@ai em] 文字列は多くの場合生成した時点で encoding がついていると思うのですが、バ
  |   |     |       | 33190 [gimite@gm il] それはそうですね。ただ、それは1.8のRuby/Tkでも必要だったこと(バイナリデータは特別な文字列クラスを使う必要があった)ですし、大した手間ではないと思います。永井さんもBINARYエンコーディングについては
  |   |     |       | 33198 [naruse@ai em] なんとなく、バイナリと明示したい時にだけ明示しておいて、よくわからない場
  |   |     |       | 33208 [gimite@gm il] すいません、Tkを使ったことがないので分からないのですが、文字列ではなくバイナリデータを渡す場面というのはそんなに多いのでしょうか?画像データを渡すときぐらいしか思いつかなかったのですが…。バイナリだと明示し忘れた場合は例外が飛ぶので、その例外を見てforce_encodingを足せばいいだけですし。
  |   |     |       + 33188 [nagai@ai ky ] センター試験の試験監督をしながらつらつら考えていたのですが,
  |   |     |         33193 [matz@ru y- a] 「一番すっきり」という基準がよくわからないのですが、私の主観
  |   |     |         33202 [nagai@ai ky ] わからないものとわかる or わかるとしていいものとの両方に
  |   |     |         + 33205 [nobu@ru y- a] 引数じゃなくてdumpの入力データのエンコーディングにするとか。
  |   |     |         + 33223 [nagai@ai ky ] 先のメールに少し補足します.
  |   |     |         | 33228 [naruse@ai em] 結局感情としてここに帰着しているのだろうなぁとは思っていたのですが、
  |   |     |         | 33235 [nagai@ai ky ] う〜む.
  |   |     |         | 33237 [naruse@ai em] あ、若干勘違いしていたようです。
  |   |     |         + 33230 [matz@ru y- a] 「一切無くなる」ことを事前に証明することは不可能ですし、証明
  |   |     |           33236 [nagai@ai ky ] わかりました.
  |   |     |           + 33238 [ko1@at ot ne]  プログラミング言語において、「感情的」というのは大事な要素だと思い
  |   |     |           | 33241 [naruse@ai em] 「感情的」だと語弊があるかもしれません。なんというか、ASCII-8BIT 以外の
  |   |     |           | 33278 [yu_raku_an@y] ありゃ、やっぱり「ASCII互換」という仮定は入ってしまうのですか。
  |   |     |           | + 33283 [usa@ga ba ec] いやいや、force_encodingは「普通は使わないメソッド」という話
  |   |     |           | + 33284 [naruse@ai em] みんなが持っているバイナリデータのイメージには実は ASCII 互換が入ってい
  |   |     |           |   33288 [matz@ru y- a] 私もそう思います。
  |   |     |           |   33289 [naruse@ai em] 一年以上前に思いついてから昨日まで忘れてたんですよね、これ。
  |   |     |           |   + 33290 [matz@ru y- a] 取り出した情報(コードポイント)がエンコーディング情報を持たな
  |   |     |           |   | + 33292 [akr@fs j. rg] あと、combining character ですかねぇ。
  |   |     |           |   | | 33299 [naruse@ai em] 「文字」の定義は様々であるところ、Unicode Glossary を引くと、
  |   |     |           |   | | 33302 [akr@fs j. rg] あきらめるのであれば、そうしてもいいでしょうね。
  |   |     |           |   | | 33306 [naruse@ai em] Ruby 1.9 や 2.0 では諦めた方がいいんじゃないですか。それを入れるのでした
  |   |     |           |   | + 33300 [naruse@ai em] 確かにそれはごもっとも。文字オブジェクトは導入してませんしねぇ
  |   |     |           |   | + 33309 [duerst@it ao] 個人的には
  |   |     |           |   | | 33313 [naruse@ai em] う、うーん、ちょっと冗長なような。
  |   |     |           |   | + 33428 [akr@fs j. rg] String#byte と String#set_byte ならこんなですかね。
  |   |     |           |   + 33307 [duerst@it ao] 確かにそういうやり方もありますが、全てのルビプログラムをみて、
  |   |     |           + 33248 [matz@ru y- a] 「感情的」という表現で永井さんが傷ついたのでしたらごめんなさ
  |   |     |             33281 [nagai@ai ky ] ちょっと誤解されているような気がするので,念のためですが,
  |   |     |             + 33285 [naruse@ai em] ごもっともな指摘だと思います。
  |   |     |             | 33318 [nagai@ai ky ] あ,ごめんなさい.ここで Marshal のケースは不適切でした.
  |   |     |             | 33321 [naruse@ai em] うーん、$KCODE に依存していたらー、どうだろう。$KCODE を自分で定義したら
  |   |     |             | + 33322 [kou@co mi ng] Perlのことはよく知らないので教えてほしいのですが、Perlの
  |   |     |             | | 33323 [naruse@ai em] Perl の場合は decode しない限りバイト列のままなので、既存のバイト列はバ
  |   |     |             | | 33326 [kou@co mi ng] そのPerlのuse utf8;相当のものが1.9のmagic commentというものに
  |   |     |             | | 33329 [naruse@ai em] str[] あたりの挙動が変わっているというのと、端から端まで ASCII-8BIT で統
  |   |     |             | + 33324 [yu_raku_an@y] え?!ま、半分冗談で言ってらっしゃるのでしょうけど、もし本当にそうなるなら
  |   |     |             | | + 33327 [naruse@ai em] メインプレイヤーではなくなっていますよね。str[] も奪われていますし。
  |   |     |             | | + 33331 [akr@fs j. rg] 具体的にはどう困るんでしょう?
  |   |     |             | |   33335 [yu_raku_an@y] 計算がすっきり書けません。
  |   |     |             | |   + 33338 [matz@ru y- a] 「そんなことする人はいない」なんて言うつもりはありませんが、
  |   |     |             | |   + 33429 [akr@fs j. rg] なるほど。
  |   |     |             | + 33381 [nagai@ai ky ] # 研究室のサーバがいきなり完全にご臨終となり,
  |   |     |             |   33402 [naruse@ai em] そこまでしなくても、-Ke を指定すれば 1.9 のメソッドは対応しますから。
  |   |     |             |   33479 [nagai@ai ky ] あぁ,なるほど.そういう意味ですか.了解です.
  |   |     |             |   33483 [naruse@ai em] コンテナにつめて返すことにして、コンテナ側でエンコーディング情報を持って
  |   |     |             |   33485 [nagai@ai ky ] ということは,そうしたケースはライブラリ側でどうにかしてやらない限りは
  |   |     |             + 33333 [matz@ru y- a] ふーむ。
  |   |     |               + 33334 [matz@ru y- a] いや、もしかしたらCマクロを駆使するとできたりするのかな。拡張
  |   |     |               + 33382 [nagai@ai ky ] そうですね.
  |   |     + 33063 [duerst@it ao] これからの増加については全く同意ですが、過去の話だと全然違います。
  |   |       + 33064 [yu_raku_an@y] なんか、国際規格とかすごい話までいっちゃってますが、
  |   |       + 33083 [akr@fs j. rg] そういえばたしかに企業は多いですね。sjis とか。
  |   |         33093 [duerst@it ao] 具体的に分かっているものではありませんが、例えばグルジアとか
  |   + 33020 [naruse@ai em] 拡張ライブラリで独自エンコーディングの定義は可能ですが、多くの場合そうし
  |     33025 [nagai@ai ky ] 非対応 locale だったりした場合には default_external は ASCII-8BIT に
  |     33029 [naruse@ai em] 現在は非対応 locale だらけですが、一般の使用に供せる頃にはほぼ問題なく
  |     + 33033 [yu_raku_an@y] 横から口を挟んで申し訳ないのですが、
  |     | + 33035 [naruse@ai em] えぇ、永井さんの問題は BINARY を ASCII-8BIT の alias でなく、replica に
  |     | | 33045 [nagai@ai ky ] はい.その案が [ruby-dev:33018] ですよね
  |     | | 33048 [naruse@ai em] これの解釈は2種類あるだろうということ以上は言っていません。Rubyが実際に
  |     | + 33036 [akr@fs j. rg] encoding を正しく設定するというのは文字を文字として扱う基礎
  |     |   33044 [nagai@ai ky ] 私としては,
  |     + 33043 [nagai@ai ky ] では,それまでの間はどうすればいいのでしょう?(^_^;
  |       33049 [naruse@ai em] Ruby 1.9.1 がキャンセルされて 1.9.0 になっている状況なんですから、未実装
  |       33050 [matz@ru y- a] そうですね。あまり問題は発生しないように思います。あと、引数
  |       33052 [naruse@ai em] こんな感じですかね。
  |       + 33053 [matz@ru y- a] コミットしてみてください。しばらく使って様子を見ましょう。
  |       + 33054 [usa@ga ba ec] -eおよび標準入力からのスクリプトがlocale encodingになるのはい
  |         33056 [matz@ru y- a] あちゃあ、それは(私は)意図してませんでした。
  + 32564 [matz@ru y- a] 外部から入力されたデータのうち、binaryではないと明らかなもの
    32583 [nagai@ai ky ] 結局のところ,binary であることが明確である場合であっても,
    32586 [matz@ru y- a] 現状ではそうですね。
    + 32589 [nagai@ai ky ] [ruby-dev:31999] で書かせていただいた通り,
    + 32598 [duerst@it ao] まつもとさん、こんにちは。
      32599 [akr@fs j. rg] そういう binary なエンコーディングについては以前考えて
threads.html
top