[#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:46494] Refinement仕様
まつもと ゆきひろです
土曜日のRefinement会議で出た宿題について。
以下の仕様候補のうちいずれを選ぶかという話でした。
(a) re-open
一度usingされたモジュール(またはクラス)をre-openした場合、そ
のモジュール/クラスの本体でrefinementが有効かどうか。
(b) inheritance
usingされたモジュールをincludeしたクラス(またはクラス)、およ
びusingされたクラスを継承したクラスの本体でrefinementが有効か
どうか。
上記、(a),(b)ともに定義の字面上usingが登場しない局面で、
refinementが有効かどうかという判断になります。usingが明示的
に登場しないのに挙動が変化することは混乱を呼ぶ可能性がありま
す。また、モジュール・クラスの定義がロードされる順序によって、
挙動が変化してしてしまうことで、更なる混乱の可能性があります。
さらに目に見える範囲にusingがないことで、最適化が難しいという
こともあるでしょう。
(c) module_eval
module_evalを使ったトリックは、松田さんのRubyConf発表でもあ
り、なかなか興味深いテクニックなのですが、その一方、同じコー
ドがrefinement有効で呼び出されるのか確定できず、最適化が難し
い上に、インラインキャッシュと相性が悪いという問題があります。
ちなみに現状では(a),(b),(c)とも有効だが、(c)についてはインラ
インメソッドキャッシュに関連する深刻なバグがあり、r37616で修
正が試みられたが、深刻な速度低下問題によりrevertされた、と認
識しています。合ってる?
で、週末つらつらと考えたのですが、
* refinementはレキシカルななにかではなく、モジュール・クラ
スに追加される属性である
という点をより明確にして、(a),(b)ともに有効にしようと思います。
(c)については悩んだのですが、かなり深刻な問題だと思うので、
* module_eval(&b)の形式は禁止(例外)
* またはrefinement状態が異なる状態でのブロックの実行は禁止
のいずれかではどうだろうかと思っています。前者であれば松田テ
クニックが使えないことになるわけで、個人的には後者を望んでい
ますが、前者でも仕方がないと思っています。将来制約緩和の可能
性はあるので。
残る問題はTwitterで、なかださんが指摘したprependとrefinement
の関係です。つまり
class B
def foo
p :B
end
end
module A
refine B do
def foo
p [:refine, :A, :B]
end
end
end
module C
def foo
super
p :C
end
end
class B
prepend C
end
module D
using A
B.new.foo # => なにが出力されるか
end
という問題です。選択肢としては
(1) refineはprependを含めてそのクラスのメソッドを上書きする
(現状)。よって出力は[:refine, :A, :B]
(2) refineはprependで修飾される前の基本メソッドを置き換える。
のいずれかですが、私はこれは(1)が望ましいと思います。つまり、
ローカルの指定であるrefinementの方が優先されるべきだと思うか
らです。ただし、[ruby-dev:46477]にある探索手法の提案では、私
が理解する限りでは自動的に(2)の挙動になるので、その辺は検討
の余地があると思います。
まつもと ゆきひろ /:|)