[#41531] [Bug #3385] ext/dbm: accept various version of db — Takahiro Kambe <redmine@...>
Bug #3385: ext/dbm: accept various version of db
2010年6月3日23:38 Takahiro Kambe <redmine@ruby-lang.org>:
2011年11月12日8:14 Tanaka Akira <akr@fsij.org>:
[#41536] RUBY_DEBUG=gc_stress [FATAL] failed to allocate memory — Tanaka Akira <akr@...>
コンパイル時に RUBY_DEBUG_ENV というマクロを定義しておくと、
[#41543] [Bug #3398] 1.9.2 SEGV during test-all — Yuki Sonoda <redmine@...>
Bug #3398: 1.9.2 SEGV during test-all
[#41597] [Bug #3433] Error that occurs by BasicSocket#sendmsg — Masaya Tarui <redmine@...>
Bug #3433: Error that occurs by BasicSocket#sendmsg
[#41600] 質問・提案:cgi.rbの後継となるライブラリについて — Dice <tetradice@...>
Diceです。cgi.rbの後継ライブラリについて質問させてください。
藤岡です。
かくたにです。
藤岡さん、かくたにさん、返信ありがとうございます。
藤岡です。
Diceです。藤岡さん、返信ありがとうございます。
[#41610] [Bug #3443] requireが遅くなる — Yusuke Endoh <redmine@...>
Bug #3443: requireが遅くなる
[#41623] [Feature:trunk] argument delegation — Nobuyoshi Nakada <nobu@...>
なかだです。
遠藤です。
まつもと ゆきひろです
前田です。
[#41672] [Bug #3463] 1.9.2-preview3 で [BUG] gc_sweep(): unknown data type 0x0 — Tomoyuki Chikanaga <redmine@...>
チケット #3463 が更新されました。 (by Tomoyuki Chikanaga)
[#41674] [Bug #3464] win32ole failure load TYPELIB on mswin64 vista — sakiyama shin <redmine@...>
Bug #3464: win32ole failure load TYPELIB on mswin64 vista
[#41702] WIN32OLE_METHOD offset_vtbl — kuwamoto shintaro <beuniv@...>
こんばんわ
助田です。
こんにちは、なかむら(う)です。
助田です。
artonです。
2010/6/24 arton <artonx@yahoo.co.jp>:
[#41705] [Bug #3471][Rejected] ./miniruby sample/test.rbで1NotOK — Shyouhei Urabe <redmine@...>
チケット #3471 が更新されました。 (by Shyouhei Urabe)
2010年6月24日16:53 Shyouhei Urabe <redmine@ruby-lang.org>:
[#41711] [Bug #3473] make clear-installed-list — Usaku NAKAMURA <redmine@...>
Bug #3473: make clear-installed-list
[#41730] (ruby/tk) ruby_1_9_2 への backport — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#41752] [Bug #3490][Assigned] test_pack_utf8 failure on mswin64 — Yusuke Endoh <redmine@...>
チケット #3490 が更新されました。 (by Yusuke Endoh)
[#41760] Hash[] の引数が Array の場合の振る舞い — とみたまさひろ <tommy@...>
とみたです。
[ruby-dev:41686] Re: 質問・提案:cgi.rbの後継となるライブラリについて
成瀬です。 2010年6月22日15:44 NAKAMURA, Hiroshi <nakahiro@gmail.com>: >>> ですが、Rubyを使う初心者が幸せになるのであれば >>> (そして初心者以外の人を不幸にするのでなければ) >>> 改善するだけの価値はあると思います。 > > ↑は正しいですね。あとはバランスかな。 > >> Ruby 開発陣が不幸になる可能性を忘れていませんか。 > > こう極端に返してしまうと、では全て標準添付するなということにならないですか。 > そうじゃなくて、どこかでバランスを取る必要がある、ということでしょう。 > >> 標準添付ライブラリのメンテナが消えた場合、泣きながらメンテナンス >> するのは Ruby 開発陣です。 > > 消えたのか消したのか消えるものなのかわかりませんが、とりあえず > 「標準添付ライブラリのメンテナがいない」という現象は今後も起こるでしょう。 > 泣きながらメンテナンスするより、よい方法を探しましょう。 > > > で、ruby-osslの時にも言いましたが、標準添付ライブラリをgemにすることを > まじめに考えてみませんか。「Ruby開発陣」として、標準添付ライブラリをgemに > して追い出すための障壁は何ですか。たとえば遠藤さんが上げられた「重症」 > または「重症になる可能性が高い」ものをgemにして、 > > 1. 標準添付ライブラリから単純になくしてさようなら。 > 2. リリース時に最新gemを取ってきて同梱する手順を整え、 > make installでgem installまでやっちゃう。 > 3. 同じくmake install-gemでgem installできるようにする。 > > などをした時の、メリットデメリットを挙げてみませんか。 gem にしてもリリース時に同梱するならば結局我々がメンテしないと いけないんじゃないでしょうか。 どうせするなら標準添付にしておいたほうが本体の影響でバグッたときに 気づきやすいので現状の方がいいでしょう。 make install で勝手に入るのにバグッたままで良いというのは ちょっとわたしの感覚ではありえませんし、 make install でこけるという最悪のパターンも考えると gem 化に 何がしかのメリットを見出すことができません。 いっそさくっと削除してしまったほうがヤル気のある人が gem を 作るだろうのでいいようにすら思います。 > ちなみに最初にgem化する例として、loggerあたりを実験に使う、というのが > よいと思ってます。ファイルひとつなのでインパクト小さいから。 gem 化まではこれやるだけでいいのでしょうけれど、 最終的なインパクトはリリースして、各種パッケージの人々が パッケージング作業を行う際に初めて気づくだろうので、 その辺おっかないですねぇ。 -- NARUSE, Yui naruse@airemix.jp