[#38782] [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

15 messages 2009/07/14
[#38784] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/14

永井@知能.九工大です.

[#38790] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38791] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/15

永井@知能.九工大です.

[#38792] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38793] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/15

永井@知能.九工大です.

[#38794] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38843] 複素数リテラルについて — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

32 messages 2009/07/21
[#38855] Re: 複素数リテラルについて — Yusuke ENDOH <mame@...> 2009/07/22

遠藤です。

[#38857] Re: 複素数リテラルについて — Tadayoshi Funaba <tadf@...> 2009/07/22

> は十分検討されたのでしょうか。積極的に反対なわけではないですが、

[#38912] String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...>

xibbarこと藤岡です。(なぜか届かないので再送します)

19 messages 2009/07/27
[#38918] Re: String#valid_encoding?にオプションが欲しい — "NARUSE, Yui" <naruse@...> 2009/07/27

成瀬です。

[#38925] Re: String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...> 2009/07/27

xibbarです。

[#38927] Re: String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...> 2009/07/28

xibbarです。

[#38914] [Bug #1819] Ruby-1.9.1を使用しDB(MySQL)接続時にエラー — Ryouhei Saita 斉田 <redmine@...>

Bug #1819: Ruby-1.9.1を使用しDB(MySQL)接続時にエラー

11 messages 2009/07/27

[#38932] Enumerator#peek — Tanaka Akira <akr@...>

Enumerator#peek を新設するのはどうでしょうか。

16 messages 2009/07/28

[ruby-dev:38769] RCLASS_M_TBL() の構造の変更

From: SASADA Koichi <ko1@...>
Date: 2009-07-13 10:01:13 UTC
List: ruby-dev #38769
 ささだです.

 RCLASS_M_TBL(klass) は,key が method id,value が method body を 表す
NODE* ,という st_table ですが,この value を NODE* から,GC 管理ではな
い,独自のデータ構造にしてもいいでしょうか.つまり,メソッドを表現するた
めに NODE を使わないようにしよう,という提案です.

 実装はこれからですが,何か意見・異論・反論・不明点など,頂ければ.

 かなり,内部の話なので,勝手に変えちゃってもいいような気がしましたが,
とりあえず ruby.h で公開されているメンバ変数の話なので,-dev に振ってみ
ました.

メリット:

・NODE の制限の撤廃

 メソッドの情報をもう少し足したいとき,NODE だと 3 word (最近だと 4
word まで書けますが)しか情報を付加できない,というのがあります.実際,
今は NODE を 2 つリンクさせてメソッドを表現しています.ちょっと,かっこ
わるいなぁ,という気がします.

 この辺の構造を,もっと柔軟にしたい,というのが一番のモチベーション.

・GC pressure の緩和

 NODE は GC 対象です.メソッドを表現する NODE は,比較的長寿命なオブ
ジェクトなので,mark コストをコンスタントに上昇させます.

 先日,このために 部分的世代別 GC が導入されました(あんまり mark しな
い)が,そもそも GC 管理オブジェクトにしなければ問題ないと思います.

(クラスのコピーとか考えると,やはり GC 管理になっちゃうかもしれないけ
ど,ちょっと実装してみないとわからない)

デメリット:

・互換性

 誰かがこの構成に依存した何かを作っていると,まずいことが起こるような気
がしますが,しかし誰か使ってるかなぁ.


-- 
// SASADA Koichi at atdot dot net

In This Thread

Prev Next