[#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 <[email protected]>:
まつもと ゆきひろです
遠藤です。
まつもと ゆきひろです
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 <[email protected]>:
[#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 <[email protected]>:
(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 <[email protected]>:
(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 <[email protected]>:
[#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:46600] [ruby-trunk - Feature #6993][Closed] Class#allocate の仕様変更(Cレベル)
Issue #6993 has been updated by mame (Yusuke Endoh). Status changed from Assigned to Closed Class#allocate は C レベルの set_trace_func でもフックできなくなったという非互換があります、 ということで preview2 を出してみて、文句が来たら reopen して考えましょう。 -- Yusuke Endoh <[email protected]> ---------------------------------------- Feature #6993: Class#allocate の仕様変更(Cレベル) https://bugs.ruby-lang.org/issues/6993#change-33710 Author: ko1 (Koichi Sasada) Status: Closed Priority: Normal Assignee: nobu (Nobuyoshi Nakada) Category: core Target version: 2.0.0 =begin ささだです. 現在,Class#new を呼び出すと,Class#allocate が呼ばれます.Class#allocate は,次のような特徴を持つ,ちょっと特殊なメソッドになっています. * 普通に定義しても Class#new からは使われない * 実際に動かす処理 func は rb_define_alloc_func(klass, func) として登録する * func は ID_ALLOCATOR という特殊なメソッド名で登録される(対応するシンボル名はなし,つまり rb_id2name(ID_ALLOCATOR) は NULL を返す * func は rb_funcall(klass, ID_ALLOCATOR, ...) で呼ばれる これは,変な allocator を定義出来ないようにするための処置だったと思います(多分). 他にも, * backtrace には現れない * set_trace_func ではスキップする という特殊な処理をしており,Ruby からは見えないようになっています.ただし,set_trace_func には現れませんが,C で trace_func を登録すると呼べてしまう,という中途半端な感じになっています. これについて,中田さんと協議したんですが,そもそも allocator function はメソッド呼び出し(rb_funcall)で呼ばないでもいいんでないか,という結論を得ました.具体的には,rb_classext_t に allocator function を登録するようにして,それを呼び出す,ということになります. あり得る問題点としては,allocator function から super が出来ない,という話がありました.ただし,そんなことやる奴はいないだろう,ということで allocator function の制限とするのがいいのではないか,という議論になりました. 副次的な効果として,allocator function のためにメソッドフレームを積む必要がなくなり,ユーザ定義クラスの生成が若干速くなる,ということがあります. なお,もう一方の選択肢としては,allocator function を backtrace や set_trace_func などで特別扱いしない,というものがありましたが,今まで見えなかったものが見えると互換性的にまずいかもしれない,という話がありました. というわけで,こんな感じで(中田さんが)進めようと思うのですが,何かお気づきの点がありましたらご指摘下さい. =end -- http://bugs.ruby-lang.org/