[#41134] [Bug:trunk] ext/tk on cygwin — Nobuyoshi Nakada <nobu@...>
なかだです。
[#41138] [Bug #3243] Can't build Ruby after r26506 — Yuki Sonoda <redmine@...>
Bug #3243: Can't build Ruby after r26506
[#41140] [Bug:trunk] the behavior of Tempfile#size was changed — Yusuke ENDOH <mame@...>
なかださん
Hi,
[#41173] [Feature #3251] allow to unlock mutex locked by another thread — Yusuke Endoh <redmine@...>
Feature #3251: allow to unlock mutex locked by another thread
[#41192] Re: [ruby-cvs:34848] Ruby:r27635 (trunk): * cont.c: apply FIBER_USE_NATIVE patch. This patch improve — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
[#41212] 実装凍結解除とリリース協力のお願い — Yugui <yugui@...>
Yuguiです。
[#41219] [ruby_1_9_2] コンパイルエラー — Takahiro Kambe <taca@...>
ruby_1_9_2ブランチのコンパイルでエラーが起きます。
[#41223] 正規表現オブジェクト中のキャプチャの数 — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
きしもとです
[#41225] io/console IO#raw error when io is closed in the block — Tanaka Akira <akr@...>
io/console を使ってみたのですが、ちょっとうまく使えません。
[#41247] Regexpの仕様について — Masaya TARUI <tarui@...>
樽家です。
[#41259] Re: [ruby-cvs:34935] Ruby:r27723 (trunk): * ext/psych/parser.c (parse): Return strings encoded as — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#41278] [BUG:1.9] BINARY should not be ASCII-compatible — Yugui <yugui@...>
WXVndWkbJEIkRyQ5ISMbKEIKCgo+IBskQiRHISIkKiQqJGAkTSQzJDMkXiRHJE41RE9AJEclKyVQ
普段、あまりM17Nの件に反応しない卜部ですが、
2010/5/11 Urabe Shyouhei <shyouhei@ruby-lang.org>:
[#41286] ruby_1_9_2 on NetBSD 5.1_RC1(+) — Takahiro Kambe <taca@...>
再び、こんばんは。
[#41316] [Bug #3295] make test aborted — Kazuhiro NISHIYAMA <redmine@...>
Bug #3295: make test aborted
チケット #3295 が更新されました。 (by Yusuke Endoh)
[#41329] NoMethodErrorなどのmessage — Masatoshi SEKI <m_seki@...>
咳といいます。
まつもと ゆきひろです
[#41334] [Bug #3307] ext/tk がheader fileの有無を誤判定する — Masaya Tarui <redmine@...>
Bug #3307: ext/tk がheader fileの有無を誤判定する
[#41348] [Bug #3316] Kernel#caller returns nil as well — Nobuhiro IMAI <redmine@...>
Bug #3316: Kernel#caller returns nil as well
遠藤です。
[#41350] [Bug #3318] net/imap/test_imap.rb reports an error on Windows — Usaku NAKAMURA <redmine@...>
Bug #3318: net/imap/test_imap.rb reports an error on Windows
[#41353] [Bug #3037] testrb の動作が1.8.7 の testrb と違いすぎる — Yusuke Endoh <redmine@...>
チケット #3037 が更新されました。 (by Yusuke Endoh)
2010年5月19日21:04 Yusuke Endoh <redmine@ruby-lang.org>:
[#41377] [Bug #3326] ruby_1_8がAIXでコンパイルできません。 — Yutaka Kanemoto <redmine@...>
Bug #3326: ruby_1_8がAIXでコンパイルできません。
[#41382] [Feature #3328] Kernel#p outputs as default_internal encoding, and so on — Masaya Tarui <redmine@...>
Feature #3328: Kernel#p outputs as default_internal encoding, and so on
[#41407] [Bug #3339] win32ole test failure — Usaku NAKAMURA <redmine@...>
Bug #3339: win32ole test failure
助田です。
こんにちは、なかむら(う)です。
助田です。
こんにちは、なかむら(う)です。
志村と申します
[#41423] [Bug #3345] webrick test failure on Windows(?) — Usaku NAKAMURA <redmine@...>
Bug #3345: webrick test failure on Windows(?)
[#41430] [bug:trunk] rubyspec: Kernel.spawn redirects both STDERR and STDOUT to the given name ERROR — Yusuke ENDOH <mame@...>
遠藤です。
[#41452] [Bug #3360] rdoc fails when including BOM — white leaf <redmine@...>
Bug #3360: rdoc fails when including BOM
チケット #3360 が更新されました。 (by Nobuyoshi Nakada)
[#41481] [Bug #3370] test failure of drb — Usaku NAKAMURA <redmine@...>
Bug #3370: test failure of drb
[ruby-dev:41290] Re: [BUG:1.9] BINARY should not be ASCII-compatible
2010/5/11 Urabe Shyouhei <shyouhei@ruby-lang.org>: > 偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ > てます。 偉い人は置いておいて、私はよりよい可能性があればいくらでも軽薄に立場を変えます。 ただ、それが本当によりよいのかについては慎重でありたく、-devで意見を聞きたい訳です。 > ゴールを確認しましょう。どうせM17Nの問題が魔法のように解決するのはありえませ > ん。Yuguiさんとしてはどうなるのが目標ですか? (snip) > * wycatsが黙る > * 低レベルライブラリ作者が黙る > * ユーザーが黙る 誰かが黙る必要もないと思うわけですよ。これまで-talkに流れているように常に、バグを書いてRubyがバグを検出したことについて文句を言う人がいるでしょうから。 一方、低水準ライブラリのバグを高水準の開発者が、事前検出できない程度に低くアプリケーションライフサイクルの中で遭遇する程度には高い確率で踏まされるのは悲劇です。 悲劇を言語が食い止められるならそうあるべきです。 > 仮にBINARYをASCII incompatibleにすると、既存の拡張ライブラリが生成するありとあ > らゆる文字列がscript encodingと連結不可能になるわけです。 「確率的に連結可能」なのと「連結不能」なのでは連結不能なほうがましだというのが、アプリケーション開発者の悲鳴から思ったことですね。 ただ、 > * 低レベルライブラリ作者が黙る (snip) > これを修正して回るには > 相当なマンパワーが必要ですね。拡張ライブラリ作者のなかには「この理不尽に見舞わ > れる限り俺は1.9に移行しない!」って言い出す人、出てくると思いますよ。 この視点を忘れておりました。それを踏まえて、第一の選択肢としては > ASCII compatibilityに関して言えば、俺の理解では誰もがハッピーになる魔法 > は存在しないです。どういった落とし所に落ち着いたところで、結局不幸な人は出てく > ると思います。今更振る舞いを変更するコストと不幸の総和は、このままで行く不幸と > どっちが大きいでしょうね?最終的に決めるのは私ではないですが、もし私が決めるとし > たら、現状維持で行くと思います。 これに賛同します。rb_str_newが生成する文字列はascii-compatibleなままでいきましょう。それでも、もし可能ならば アプリケーション開発者の悲劇を防ぎたいです。たとえば、ASCII-8BIT(1.8との互換性のためのもの, index 0)とBINARY(octetのためもの)を分離して、 ASCII-8BITは任意のエンコーディングと結合可能で結果はASCII-8BIT、という仕組みなんかはどうでしょうか。 -- Yuki Sonoda (Yugui) yugui@yugui.jp http://yugui.jp