[#46329] [ruby-trunk - Feature #7252][Assigned] version number of 2.0 release — "usa (Usaku NAKAMURA)" <usa@...>
>> 旧来の開発版/開発版とかもういらないんじゃないですかね。
前田です。
[#46344] Subversion repository breakage and rollback — "NARUSE, Yui" <naruse@...>
Sorry for this trouble,
[#46346] [ruby-trunk - Bug #7262][Open] module extension (#include/#prepend) in refinements — "matz (Yukihiro Matsumoto)" <matz@...>
[#46350] RubySpecメンテナ — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
On 11/01/2012 07:43 PM, Yukihiro Matsumoto wrote:
2012年11月2日 12:44 Urabe Shyouhei <shyouhei@ruby-lang.org>:
まつもと ゆきひろです
遠藤です。
まつもと ゆきひろです
On 11/02/2012 03:47 AM, Yukihiro Matsumoto wrote:
[#46414] [ruby-trunk - Bug #7287][Open] please rename atomic.h which conflicts with /usr/include/atomic.h in Solaris10 — "ngoto (Naohisa Goto)" <ngotogenome@...>
きしもとです
[#46434] トラップハンドラで許されない操作はなにか — KOSAKI Motohiro <kosaki.motohiro@...>
GyRCPi46aiRHJDkbKEIKCltCdWcgIzcxMzRdIBskQiRyRDQkWSRGJCQkRj88SiUkSjtFTU1MZEJq
近永と申します。
2012/11/9 Tomoyuki Chikanaga <nagachika00@gmail.com>:
[#46477] Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...>
refinement を導入するときの性能に対する excuse が「method cache に殆どあ
前田です。
ささだです.
前田です。
ささだです.
前田です。
(2012/11/12 18:20), Shugo Maeda wrote:
前田です。
なかだです。
前田です。
なかだです。
前田です。
(2012/11/16 17:22), Shugo Maeda wrote:
前田です。
[#46494] Refinement仕様 — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#46509] [ruby-trunk - Bug #7344][Open] gem pristine bigdecimal が失敗してしまう — "hsbt (Hiroshi SHIBATA)" <shibata.hiroshi@...>
[#46540] Re: [ruby-cvs:44900] kosaki:r37730 (trunk): * thread.c, vm_core.h: big rename th to cur_th when works only — SASADA Koichi <ko1@...>
こういう変更を,理由の説明や事前の連絡無く行われると混乱します.
2012/11/19 SASADA Koichi <ko1@atdot.net>:
(2012/11/19 21:57), KOSAKI Motohiro wrote:
[#46547] ベンチマークが終わらない — SASADA Koichi <ko1@...>
shugo さんの refinement の修正についてベンチマークを取ろうと,昨日からす
定点観測でもベンチマークがおわってないみたいですね…(タイムアウト処理入れているので気が付きませんでした)
(2012/11/20 8:04), Narihiro Nakamura wrote:
2012年11月20日 8:11 SASADA Koichi <ko1@atdot.net>:
(2012/11/21 16:05), NARUSE, Yui wrote:
[#46574] Re: [ruby-cvs:44880] tadf:r37710 (trunk): * bignum.c (rb_cstr_to_inum): should accept underscores of — "NARUSE, Yui" <naruse@...>
2012/11/18 <tadf@ruby-lang.org>:
[#46641] Fwd: [ruby-changes:25810] kosaki:r37867 (trunk): * thread.c (rb_mutex_trylock, rb_mutex_unlock, mutex_sleep): — SASADA Koichi <ko1@...>
Mutex#lock とかを,trap handler 中で出来ない,ってのは,すみません,どの
> Mutex#lock とかを,trap handler 中で出来ない,ってのは,すみません,どの
[#46647] [ruby-trunk - Bug #7452][Assigned] Main thread is stopped after running finalizers if the main thread has a finalizer — "mrkn (Kenta Murata)" <muraken@...>
[ruby-dev:46491] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo):
前田です。
2012年11月12日 14:58 SASADA Koichi <ko1@atdot.net>:
> この件,私が実装しても shugo さんがされても良いかと思います.ただ,話
> の順番がおかしい,という気がしています.refinement の導入は,
> (refinement の関係の無い部分での)コストが十分に低い,という前提があっ
> たと思います.しかし,今回の件は,この前提をひっくり返している,もしくは
> ひっくり返す可能性があります.
すみません、いったんrevertしました。
テストはskipする状態で残してありますが、このテストが通らない場合はmodule_eval
のブロックでrefinementsを有効にする機能は削るつもりです。
> 動くので「大問題」ではないと思いますが,このままリリースするには抵抗が
> あります.
リリースするまでに性能の問題がクリアできない場合は機能を削ることを考えて
いましたが、ささださんの作業を考えると一時的にでも入れるべきではなかった
ですね。すみません。
>> * refineした時にrefine対象クラスにメソッドがない時はどうするか
>> メソッドがない時も常にrefineされたことを示すmethod entryを追加する?
>
> その点,私もあのあと気づいたのですが,refine されるメソッドは追加する
> と良いと思います.
追加しない場合、メソッド探索失敗時もrefinementsの探索パスを通すことに
なるかなと思いますが、後でrefine対象のクラスにメソッドが追加されたりすると
まずそうなので、やっぱりrefineした時点でメソッドを追加しておかないと
まずそうです。
> (そもそも,refine されるべきメソッドがないのに refine できる,って仕様
> はどうなの,という気もしましたが.まぁ,そういうシチュエーションもあるの
> かなぁ)
refineの対象はメソッドではなくクラスなので、新規メソッドの追加も仕様と
したいと考えています。
具体的なユースケースとしては、例えばRSpecのshouldのようなものがあります。
>> * refineされたメソッドの呼出時にrb_call_info_tにどういう情報を格納するか
>> Twitterでは、refineされたことを示すmethod entryを入れておくということでしたが、
>> 今のvm_call_methodの構造だとrb_call_info_tの中身を書き換えてgotoするような
>> 形になっているので、どういう変更を意図されているのかよくわかりませんでした。
>
> goto は無いですが,この辺は特に変更は不要な気がします.
vm_call_methodに分岐を増やして、
case VM_METHOD_TYPE_REFINED:{
rb_call_info_t cie = *ci;
ci = &cie;
ci->me = (refinementsから探索したmethod entry、または元のクラスのmethod entry);
if (ci->me != 0) {
goto normal_method_dispatch;
}
else {
/* refinementsからメソッドが見つからず、元のクラスにもメソッド定義がない場合 */
goto start_method_dispatch;
}
とするようなイメージで合っていますか?
refinementsから探索したmethod entryは通常のインラインキャッシュには
載らないのですよね?
# できれば別のところにキャッシュを置いた方がいいかもしれないですけど。
> 結論が出たら,私が実装しますかね.
意図を正しく理解できているか不安ではありますが、ささださんは他にも作業が
たくさんありそうなので、いったん私がやってみましょうか?
あと、本題と関係ありませんが、コードを読んでいて以下の疑問がありました。
* rb_iseq_t::ic_entriesはまだ使われていますか?
* callinfoとcall_infoで名前の付け方に揺れがあるのは意図的ですか?
--
Shugo Maeda