[#42508] [Ruby 1.9-Bug#4013][Open] rake/test_tasks.rb fails if ENV assined test value — Akio Tajima <redmine@...>
Bug #4013: rake/test_tasks.rb fails if ENV assined test value
7 messages
2010/11/01
[#42520] GC issues — SASADA Koichi <ko1@...>
ささだです。
6 messages
2010/11/03
[#42551] [Ruby 1.9-Bug#4034][Open] format() の %a 指定子での丸めが常に零方向になっている — tadayoshi funaba <redmine@...>
Bug #4034: format() の %a 指定子での丸めが常に零方向になっている
5 messages
2010/11/07
[#42564] [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案 — Makoto Kishimoto <redmine@...>
Feature #4043: =E3=82=B0=E3=83=AD=E3=83=BC=E3=83=90=E3=83=AB=E9=96=A2=E6=95=
15 messages
2010/11/11
[#42774] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案
— Yukihiro Matsumoto <matz@...>
2010/12/16
まつもと ゆきひろです
[#42834] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案
— "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
2010/12/21
きしもとです
[#42835] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案
— Yukihiro Matsumoto <matz@...>
2010/12/21
まつもと ゆきひろです
[#42838] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案
— "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
2010/12/21
きしもとです
[#42845] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案
— Yukihiro Matsumoto <matz@...>
2010/12/21
まつもと ゆきひろです
[#42849] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案
— "U.Nakamura" <usa@...>
2010/12/22
こんにちは、なかむら(う)です。
[#42577] Rubyのバグレポートのガイドライン — "Shota Fukumori (sora_h)" <sorah@...>
sora_hです。
11 messages
2010/11/15
[#42588] Re: Rubyのバグレポートのガイドライン
— Yugui <yugui@...>
2010/11/18
2010/11/15 Shota Fukumori (sora_h) <sorah@tubusu.net>:
[#42589] Re: Rubyのバグレポートのガイドライン
— "Shota Fukumori (sora_h)" <sorah@...>
2010/11/18
元を書いてくれたmame3の様子をみてドラフトを外してみようかと思います。
[#42601] [Ruby 1.9-Bug#4072][Open] dRubyで作成したサーバプログラムがsleepしていてもexitしてしまう — 三村 益隆 <redmine@...>
Bug #4072: dRubyで作成したサーバプログラムがsleepしていてもexitしてしまう
7 messages
2010/11/19
[#42625] [Ruby 1.9-Feature#4089][Open] Add addr2line for C level backtrace — Yui NARUSE <redmine@...>
Feature #4089: Add addr2line for C level backtrace
6 messages
2010/11/26
[#42638] Enumerable#categorize — Tanaka Akira <akr@...>
enumerable から hash を生成するメソッドとして
25 messages
2010/11/27
[#42639] Re: Enumerable#categorize
— Urabe Shyouhei <shyouhei@...>
2010/11/27
(2010/11/27 18:45), Tanaka Akira wrote:
[#42643] Re: Enumerable#categorize
— Yukihiro Matsumoto <matz@...>
2010/11/27
まつもと ゆきひろです
[#42644] Re: Enumerable#categorize
— Tanaka Akira <akr@...>
2010/11/27
2010年11月27日23:19 Yukihiro Matsumoto <matz@ruby-lang.org>:
[#42645] Re: Enumerable#categorize
— Yukihiro Matsumoto <matz@...>
2010/11/27
まつもと ゆきひろです
[#42646] Re: Enumerable#categorize
— Tanaka Akira <akr@...>
2010/11/27
2010年11月27日23:51 Yukihiro Matsumoto <matz@ruby-lang.org>:
[#42656] [Request for Comment] avoid timer thread — SASADA Koichi <ko1@...>
Hi,
1 message
2010/11/29
[ruby-dev:42514] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv
From:
Kouhei Sutou <kou@...>
Date:
2010-11-02 12:50:01 UTC
List:
ruby-dev #42514
須藤です。 In <4CCF03C6.3090504@airemix.jp> "[ruby-dev:42510] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 2 Nov 2010 03:15:40 +0900, "NARUSE, Yui" <naruse@airemix.jp> wrote: > この変更では、Ruby M17N の encoding system を使うようにしていますが、 > 導入した非互換変更には反対です。 その意見はわからなくもわからなくもないです。 私も迷いました。 ただ、反対の理由として以下は弱いと感じます。 非推奨とかいつなくなるとかが確定しているくらい必要だと感じま す。 > 総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは > 合意がとれていると思われるところ、この状況下で非互換変更をするのは > 避けるべきだと思います。 個人的には標準添付されているXMLパーサはRubyのみで書かれたも のの方がいいと思っています。Nokogiriとかはgemでいいと思って います。 > また、今回の REXML::Document#encoding, REXML::XMLdecl#encoding, > REXML::Output#encoding and REXML::Source#encoding は、 > ドキュメントが自称しているエンコーディングと、Ruby が解釈し使っている > エンコーディングは分離するべきでしょう。 意図していることを理解できている自信がないのですが、エンコー ディングを表すのにEncodingオブジェクトを使うのはよくない、と いうことですか? > 直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、 > BOM 付きの UTF-16 が欲しいときに困ります。 > (なお、UTF-16 は ASCII incompatible なので色々バグってる気がする) もともとREXMLは出力時にBOMをつけないのですが、BOM付きの UTF-16が必要になるのはどういう場面を想定していますか? ここも意図を理解している自信がないのですが、RubyのEncodingは まだIconvの代わりには使えないということですか? > というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを > 返すメソッドを新設した方がよいのではないかと思います。 encodingよりもEncodingオブジェクトを返すのに適切な名前を思い つけないので、そういうAPIにはしない方がよいと思っています。