[#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:42516] 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 14:38:15 UTC
List:
ruby-dev #42516
須藤です。
In <4CD01373.9030500@airemix.jp>
"[ruby-dev:42515] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv" on Tue, 2 Nov 2010 22:34:53 +0900,
"NARUSE, Yui" <naruse@airemix.jp> wrote:
>>> この変更では、Ruby M17N の encoding system を使うようにしていますが、
>>> 導入した非互換変更には反対です。
>>
>> その意見はわからなくもわからなくもないです。
>> 私も迷いました。
>>
>> ただ、反対の理由として以下は弱いと感じます。
>> 非推奨とかいつなくなるとかが確定しているくらい必要だと感じます。
>
> わざわざ非互換を入れるようなライブラリではないという趣旨です。
確定していない現段階ではそのような対象ではないということを主
張しています。
> 必然性のある物ならばしょうがないですが、これは違うと思います。
Ruby 1.9ではEncodingまわりの機能と統合されるのは必然の流れだ
と考えています。
>>> 総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは
>>> 合意がとれていると思われるところ、この状況下で非互換変更をするのは
>>> 避けるべきだと思います。
>>
>> 個人的には標準添付されているXMLパーサはRubyのみで書かれたも
>> のの方がいいと思っています。Nokogiriとかはgemでいいと思って
>> います。
>
> Nokogiri を添付すべきだとは言っていません。
合意がとれているわけではないこと(少なくとも反対意見があると
いうこと)主張しています。
>> 意図していることを理解できている自信がないのですが、エンコー
>> ディングを表すのにEncodingオブジェクトを使うのはよくない、と
>> いうことですか?
>
> はい。
> それぞれのエンコーディングの実際上の射程範囲は文脈によって代わります。
> そして、HTTP や HTML、XML などのエンコーディングと、Ruby M17N の
> エンコーディングは一部射程範囲が異なります。
今はXMLだけ考えています。
具体的にはどこが異なるのでしょうか。
私の認識は以下の通りです。
* XMLのエンコーディングはIANAに登録されているchaset名をベース
にしている。x-はじまりのものなども使えまるが、REXMLでは
サポート対象外。
* RubyのEncodingもIANAをベースにしている。
なので、REXMLで使う範囲では十分カバーしていると認識していま
す。
>>> 直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、
>>> BOM 付きの UTF-16 が欲しいときに困ります。
>>> (なお、UTF-16 は ASCII incompatible なので色々バグってる気がする)
>>
>> もともとREXMLは出力時にBOMをつけないのですが、BOM付きの
>> UTF-16が必要になるのはどういう場面を想定していますか?
>
> BOM をつけないのは UTF-8 の話ではありませんか。
> たとえば、1.9.2 までは以下で BOM 付き big endian な UTF-16 で出力しますね。
>
> require 'rexml/document'
> doc = REXML::Document.new
> doc << REXML::XMLDecl.new('1.0', 'UTF-16')
> doc.write(s="")
> => "\xFE\xFF\x00<\x00?\x00x\x00m\x00l\xFE\xFF\x00 \x00v\x00e\x00r\x00s\x00i\x00o\x00n\x00=\x00'\x00"
たしかにそうですね。(big endianではなくlittle endianですが。)
失礼しました。
ただ、これはiconvを利用している場合でiconvがない場合はBOMな
しになっていたはずです。
# 今のままでもBOMをつけるくらい簡単なので、必要であればつけて
# しまってもいいとは思っています。
> これの結果は、現在以下の通りになってしまっています。
> => "<?xml version='1.0' encoding='UTF-16'?>"
このように表示されるのは適切にencodingが設定するようになった
からだと思っています。trunkだとちゃんとUTF-16BEが設定されてい
て(なので\xXXにならないで表示される)、以前は(UTF-16なの
に)UTF-8が設定されていたと思います。
> これによって、少なくとも XMLDecl#encoding の戻り値の意味は、
> XML 宣言の encoding 属性で用いられる値であって、内容の Ruby の文脈における
> encoding とは異なる物であるといえるのではないでしょうか。
すみません、「内容の Ruby の文脈における encoding」が何を指し
ているのかが分かりませんでした。テキストのencodingとか、そう
いう意味ですか?そうだとして、異なる場合はどうした方がよいと
いうことでしょうか。
ちなみに、「XMLDecl#encoding の戻り値の意味は、」XMLとして文
字列化したときに使われるencodingでもあります。まとめると、今
はこうなっていると思っています。
* REXMLのオブジェクトを作るときのencodingはXML宣言で指定
* REXMLのオブジェクトを操作するときの入出力はUTF-8
* REXMLのオブジェクトをXMLとして出力する時はXMLDecl#encoding
> そもそも、UTF-16 の場合 UTF-8 に変換して扱うし。
UTF-16以外の場合でもREXML内部では常にUTF-8で扱っています。
>> ここも意図を理解している自信がないのですが、RubyのEncodingは
>> まだIconvの代わりには使えないということですか?
>
> まず、文字列のエンコーディングを扱う部分と、変換を司る transcode を
> 分けて考える必要があります。
> で、iconv の代わりになる物は transcode であって Encoding は別の話です。
えーと、もともとiconvの代わりにEncodingをという話から始まって
いたのでEncodingを使っていたのですが、使い分けた方がよいので
しょうか?
使い分けたとして、transcodeがiconvの代替として使うにはまだ早
いということであれば今回の変更は時期尚早だった気がします。
>>> というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを
>>> 返すメソッドを新設した方がよいのではないかと思います。
>>
>> encodingよりもEncodingオブジェクトを返すのに適切な名前を思い
>> つけないので、そういうAPIにはしない方がよいと思っています。
>
> Encoding オブジェクトバージョンの名前をどうするか、というのは、
> それはそれで難しいのですが、上述の理由からそうせざるをえないと思います。
> 私案では string の encoding なので str_encoding かなぁ。
うーん、上述の理由を受け入れられないのは別としても、その名前
は受け入れられないです。適切でない場所にはみ出してしまった感
じがします。