[#35719] Windows-31J <-> UTF-8 roundtrip — Tanaka Akira <akr@...>
以下のように Windows-31J と UTF-8 が roundtrip するかどうか
成瀬です。
In article <48932335.7010209@airemix.jp>,
成瀬です。
In article <48935EBD.3010603@airemix.jp>,
成瀬です。
[#35724] $SAFE=4の場合のReadline::HISTORY.each — Takao Kouji <kouji@...7.net>
knu さんへ
[#35726] "\x01\x00\x00\x00\x00\x00\x00\x21".encode("utf-8", "utf-32be", :invalid=>:replace) — Tanaka Akira <akr@...>
UTF-32BE で、文字として正しくない 4バイトと、文字として正し
[#35733] Re: [ruby-core:18078] We'll release 1.8.6/1.8.7 this Friday, #2 — Urabe Shyouhei <shyouhei@...>
というわけでそろそろリリースしようと思います。予定日は8月8日です。問題点
[#35745] [Bug:1.9] default_external depends on the order of -K and -E — sheepman <sh@...>
こんにちは sheepman です。
成瀬です。
Yuguiです。
[#35763] 文字コードがシンボルでないのは何故? — take_tk <ggb03124@...>
たけ(tk)です。
なかだです。
たけ(tk)です
[#35789] [Ruby 1.9 - Bug #407] (Open) String#<< — Shyouhei Urabe <redmine@...>
チケット #407 が報告されました。 (by Shyouhei Urabe)
まつもと ゆきひろです
Yukihiro Matsumoto さんは書きました:
まつもと ゆきひろです
成瀬です。
At 08:00 08/09/20, NARUSE, Yui wrote:
まつもと ゆきひろです
[#35811] fail to build extension libraries that includes some ruby header files — "Yusuke ENDOH" <mame@...>
遠藤です。
[#35834] 「サポートレベル」の定義、1.9.1のサポート予定プラットフォーム、メンテナ募集 — "Yugui (Yuki Sonoda)" <yugui@...>
Yuguiです。
[#35845] [Bug #437] test_strftime(TestTime) fails on Solaris — Shugo Maeda <redmine@...>
Bug #437: test_strftime(TestTime) fails on Solaris
前田です。
さとうふみやす @ OSS テクノロジです。
まつもと ゆきひろです
前田です。
まつもと ゆきひろです
前田です。
前田です。
まつもと ゆきひろです
前田です。
[#35851] [Feature:1.9] name referencing in sprintf — "Yusuke ENDOH" <mame@...>
遠藤です。
[#35863] Refactoring of enumerating prime numbers — "Yugui (Yuki Sonoda)" <yugui@...>
Yuguiです。
けいじゅ@いしつかです.
Yuguiです。
けいじゅ@いしつかです.
なかだです。
けいじゅ@いしつかです.
なかだです。
けいじゅ@いしつかです.
Yuguiです。
けいじゅ@いしつかです.
[#35899] [Bug #466] test_str_crypt(TestM17NComb) failed — Kazuhiro NISHIYAMA <redmine@...>
Bug #466: test_str_crypt(TestM17NComb) failed
[#35904] [Feature:1.9] pack format 'm' based on RFC 4648 — "Yusuke ENDOH" <mame@...>
遠藤です。
チケット #471 が更新されました。 (by Yuki Sonoda)
遠藤です。
In article <e0b1e5700809220338g5f3b5627p95e94744d5c10505@mail.gmail.com>,
遠藤です。
In article <e0b1e5700809231144n376fd4eencfe06c49ed66665e@mail.gmail.com>,
遠藤です。
[#35906] %N for Time#strftime — "Shugo Maeda" <shugo@...>
前田です。
In article <704d5db90808210811p7f3aef73h97913ade156323f3@mail.gmail.com>,
なかだです。
まつもと ゆきひろです
[#35922] [Bug #475] cgi.rbにNKFに依存したコードが入っている — Takeyuki Fujioka <redmine@...>
Bug #475: cgi.rbにNKFに依存したコードが入っている
[#35945] Re: [ruby-list:45386] Re: [ANN] REXMLのDoS脆弱性 — "Shugo Maeda" <shugo@...>
前田です。
前田です。
In message <704d5db90809010656k2042969bx3d8a4abdafeeea8e@mail.gmail.com>
[#35954] Re: [ruby-cvs:26052] Ruby:r18834 (trunk): * compile.c (defined_expr): should handle NODE_{AND,OR} as — SASADA Koichi <ko1@...>
ささだです.
まつもと ゆきひろです
ささだです.
まつもと ゆきひろです
ささだです.
まつもと ゆきひろです
[#35977] block parameter for Delagator — keiju@... (Keiju ISHITSUKA)
けいじゅ@いしつかです.
[#35986] 1.9と1.8で、delegateのインスタンスのクラス名の違う — Fujioka <fuj@...>
xibbarこと藤岡です。
まつもと ゆきひろです
けいじゅ@いしつかです.
藤岡です。
けいじゅ@いしつかです.
こんにちは、なかむら(う)です。
[#36008] [Bug #505] 1.upto 2 {|i| p i } — Shyouhei Urabe <redmine@...>
Bug #505: 1.upto 2 {|i| p i }
[#36028] [Bug #513] Tempfile yields [BUG] Stack consistency error — Shyouhei Urabe <redmine@...>
Bug #513: Tempfile yields [BUG] Stack consistency error
[#36033] [Bug #515] String#rindexが期待通りに動かない — Takeyuki Fujioka <redmine@...>
Bug #515: String#rindexが期待通りに動かない
[#36048] TypeError from Encoding.compatible? (r18920) — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#36066] Numeric#scalar? — Tadayoshi Funaba <tadf@...>
1.9 の Numeric#scalar? について、適当でないのでは (real? などのほうがい
原です。
> やはり、scalar? はずれているんじゃないかな。real? の方がいい
原です。
> ここで、scalar? を疑問視する理由を復習すると、たとえば、「複
1.9.1 までに時間がないので scalar? だけ何とかしたいと思っていましたが、
前田です。
原です。
[ruby-dev:36056] Re: TypeError from Encoding.compatible? (r18920)
成瀬です。 Yukihiro Matsumoto wrote: > |このような誤解を招く動作をするよりは、 > |潔く例外を出してくれた方がいいと考えました。 > |# Encoding.compatible? が encoding を取れるようにするべき、 > |# という案については現在思案中 > > っていうか、その「思案」が終わってから変更してもよかったんじゃ > ないんですかね。 1.9.1 仕様の fix が迫ってきたので、とりあえず今のままじゃまずいだろうと。 あと、encoding の場合はその encoding が何を意図しているのか難しいので。 > |まつもとさんの仰る仕様ならば一貫性があるのでよいと思うのですが、 > |現行の仕様では compatible な時に enc を返す以上、 > |false と nil で区別という方法が使いづらいのがネックでしょうか。 > |enc / false / nil でもいいのかなぁ・・・。 > > やっぱり enc / false / nil はおかしい気がしますね。うーん。 > true / false / nil にして、最少公倍数なエンコーディングを求 > めるメソッドは別に持つとか...。 Encoding.compatible? は enc / nil にして、 C レベルで言う enc_capable 的なものを用意するのもありかも、とかは。 この場合 obj#encoding の有無で判断とかになるんでしょうが、 一方で IO#encoding はなかったりするわけです。 > |r18920 の意図は Encoding.compatible? が対応しているオブジェクトと、 > |対応していないオブジェクトをはっきりわけることだったので、 > |例外を出すことにこだわりはないのですが・・・。 > > Encoding.compatible?がなにをとるかを明確にする必要があると思 > います。 > > たとえば将来IOとかStringIOとか「文字列のように振る舞うなにか」 > を引数にとるような可能性を考えると、今のようなチェック(文字列 > か正規表現のみ)はあまり良くないような気がします。 IO 系のことは考えたんですが、今の Encoding.compatible? とは そぐわないように感じました。 そもそも、IO は入力と出力で話が違うわけで、 たとえば、「US-ASCII の IO 出力」と「UTF-8 の文字列」は×です。 しかし、「US-ASCII の IO 入力」と「UTF-8 の文字列」は○で、 encoding を返すならば UTF-8 でしょう。 また、Encoding.compatible? は中身の ASCII ONLY まで見るわけですが、 これを IO に適用することは困難です。 つまり、IO を仮に引数とする場合、 その encoding を持ち CODERANGE_VALID な string とみなす、 ということになるかと思うのですが、果たしてこれが、 Encoding.compatible?(io, str) と書いた場合の期待通りかというと、 なかなかあやしい所なんじゃないかなぁと。 encoding の場合も同様で、その encoding がどこの encoding かによって、 "compatible" の意味が変わってきます。 一方で、regexp に関しては文字列と絡む部分がマッチのみなので、 もう一方のなにかの encoding を文字列の encoding とみなし、 当該 regexp のマッチ可能かで判断するということで決められました。 という具合に話はなかなか難しいわけです。 -- NARUSE, Yui <naruse@airemix.jp>