1.9.3 is nearing you / 1.8.7 will be died.

There are many threads from the previous report, because of the ticket assigning party.

先週の欠席裁判ことチケットアサイン会で大量のメールが届きました．

また，先週出す予定だったのに1週間も遅れてしまって申し訳ないです!

Sorry for delay.

[ruby-list:48199] [ANN] nokogiri 1.4.5 and 1.4.6 リリース

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/48199

nokogiri の最新バージョンがリリースされたようです．

[ruby-list:48200] [ANN] ruby 1.8.7 patchlevel 352 released

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/48200

Ruby 1.8.7's latest patch release has been released.

Bug 4950 ほぼ同時に異なる種類のシグナルを受信すると片方のシグナルハンドラが実行されない

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/44005

Ticket in redmine http://redmine.ruby-lang.org/issues/4950

Nagachika reported that the following code should output [1,2] or [2,1], but
[1] (or [2]) is outputted.

He's also saying signal handler that not ran will run when ruby is exiting.

And he wrote a patch to resolve this bug. [ruby-dev:44007]

Delivering signal to handler is delayed until signal processed in main thread, so delivering is jammed if timer thread stopped polling.

Then, ko1 commented ([ruby-dev:44009]) that:

I was creating a patch because Kosaki-san noticed same problem with solution to me.

But, I have a problem that make test freezes in copy_stream test. I've not resolved this problem yet.

Bug 4962 come back gem_prelude!

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/37730

Ticket in redmine http://redmine.ruby-lang.org/issues/4962

遠藤さんが1.9.3のベンチマークは1.9.2のベンチマークより遅い事がkosakiさんに伝えられたことから，
どこが遅くしているかを調査しました．

調査の結果，gem_prelude.rbの廃止がそれを引き起こしているようです．

rubygemsの読み込みはたくさんのオブジェクトを生成し参照を保持するので，
GCマークフェーズ実行時のネックになっているようです．

そしてこの問題を解決する3つの提案をしています:

1. 世代別GCを導入する; これは全ての拡張ライブラリの変更も要求するので2.0まで不可能．
2. Rubygemsをダイエットする; 可能なかぎり生成するオブジェクトを減らし，参照を保持しないように変更する
3. gem_prelude.rb をrubygemsの遅延ロードのために復活させる

また，1.9.3での最適解は3番のgem_prelude.rb復活だと言っています．

次に [ruby-core:37743] でkosakiさんが
gemを無効化してベンチマーク計測を行うとtrunkのほうが192より速いが，逆に有効化するとtrunkのほうが遅い事を報告しています．

しばらくたったあと，Rubygemsのdrbrainがいくつかの無駄な部分をrubygemsに発見したので，無駄な部分がどうベンチマークに影響しているかを調査している
ということを報告し ([ruby-core:37818])，
その後Rubygemsにパッチをあてたtrunkで1.9.2p180より約-10秒 (--disable-gemsしたtrunkと1.9.2p180の比較だと13秒速い) 速くなっていることを報告しています ([ruby-core:37821])

次に [ruby-core:37833] で r32429 でパッチをコミットした事を報告しています．

tenderloveが別のパッチを [ruby-core:37815] で投稿していますが，筆者にはよくわからないので割愛させてください(解説希望)

[ruby-dev:43920] ThreadGroup#make_local_space! (Re: ThreadGroup の強化案)

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/43920

Previous report http://rbwr.blogspot.com/2011/06/blog-post_26.html

shyouhei asked a use case of ThreadGroup.

He also said:

At my little research in past, there are no many real world example to use Thread in bundles.

Next, you wrote this proposal use case is "sandboxing" in your mail, but I think we must expand first $SAFE because
sandboxing is implemented in $SAFE (but I can't say "$SAFE is perfect"), and I can't think any advantage if we use ThreadGroup for sandboxing.

By the way I agree to do something to ThreadGroup because ThreadGroup doesn't have much of features.
But I think ThreadGroup is still useless however we add some new features to ThreadGroup because
use case of ThreadGroup is not decided.

Next, nagai-san answered in [ruby-dev:43978],

Q. What is use case of bundling Threads ?

I think Thread generally works with a bundle. In past times, ThreadGroup is equal to Array because
doesn't have much features (without automatically appending sub thread). So people doesn't use ThreadGroup.
This improvement expand use case of ThreadGroup, this also means increase the range of Thread programming.

Q. "sandboxing" is implemented by $SAFE...

I want an environment that can run generally ruby script using functional method without environment taint.

If run script with wrap in anonymous module, Functional method defining doesn't work well.
Functional method defining is necessary evil however if it taints global environment.

He also said all these problems can't be solved in $SAFE, if we solve this issue in $SAFE, he think make_local_space! is needed for each ThreadGroup.

Then, kosaki-san asked in [ruby-dev:43979]

1. Discussion is stopped; This issue will not be going to merge.
2. Java has ThreadGroup; that is as poor as ruby's... java users doesn't use ThreadGroup actively, and they don't want to expand it. Why ruby needs ThreadGroup?
3. Future of Thread is dark... Because we can't increase parallel level with GVL.
4. But if we use multi process or multi vm, after all this improvement is useless.
5. So please explain why this improvement is needed in form "if ThreadGroup can do X, Y becomes happy", not "currently ThreadGroup can't do Z."
6. We need lock for each ThreadGroup if we add some new method to ThreadGroup, does this improvement effects to JRuby? (it doesn't have GVL)

nagai-san answered to these in [ruby-dev:43980]

1. Discussion is stopped because most user doesn't use ThreadGroup. most users don't have trouble around ThreadGroup because they're not using.
2. i feel ThreadGroup is useless, does this mean i'm strange?
3. that is it if 1 process ruby only. but that is not if working in multiple servers.
4. In head of my first mail in this issue is real problem that i think it's useless
5. method namespace needs lock when only adding, is this wrong?
6. I can't say about it... because i was thinking in existing features. sorry

[ruby-dev:44027] [RubyKaigi] Next version of Ruby 1.8 and 1.9

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/44027

Arrangements of RubyKaigi2011 Next Version of Ruby 1.8 and 1.9.

• Abstract of development status of 1.9.3 - yugui (5 minutes)
• 1.8.7 development deadline
• Why there is no 1.8.8?
• 1.9.3 new features - abstract by yugui, detail by others (20 minutes)
• Committer Q&A (30 minutes)

NOTE: This is not official announcement.

---

RubyKaigi2011 Next Version of Ruby 1.8 and 1.9 についての話

また今年もいろいろあるようです．尚，これは公式アナウンスじゃないですよ．

[ruby-list:48197] 「Rubyリファレンスマニュアル刷新計画」2011-06分のスナップショットリリース

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/48197

「るりま」の2011-06スナップショットがリリースされました．

Bug 4987 test/rake doesn't work at all

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/37847

Ticket in redmine http://redmine.ruby-lang.org/issues/4987

nobu reported test/rake/test_rake.rb is depending on non-existent library flexmock.

Then drbrain answered ([ruby-core:37852]) that he won't be able remove this testing dependency until after RubyKaigi.

--

なかださんがテスト test/rake/test_rake.rb が外部ライブラリ flexmock に依存していることを報告しています．

drbrainさんがこの依存を取り除く事はRubyKaigiが終わるまで厳しいだろうと回答しています． ([ruby-core:37852])

Feature 4985 Add %S[] support for making a list of symbols

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/37840

Ticket in redmine http://redmine.ruby-lang.org/issues/4985

tenderlove proposed new syntax %S[] for making a list of symbols.

%S[foo bar] #=> [:foo, :bar]

But matz said, [ruby-core:37844]:

Interesting idea (include Joel's)! But I am not sure whether they are the right prefix.

These are ideas of prefix:

%S[foo bar]
:[foo bar] # It's conflicts with :[] ("[]".to_sym), ':' manages hard works
%:[foo bar] # ':' manages hard works
%i[foo bar]
%I[foo bar]

---

tenderloveが新しい構文 %S[] を提案しています．これはSymbolの配列を作成するものです．

%S[foo bar] #=> [:foo, :bar]

しかしまつもとさんが [ruby-core:37844] でアイデアは良いものの，はたしてこのprefix %S が良いものだろうか．と言っています．

代替案としていくつかが提案されました:

%S[foo bar]
:[foo bar] # It's conflicts with :[] ("[]".to_sym)
%i[foo bar]
%I[foo bar]
%:[foo bar]

Bug 4988 ObjectSpace.#define_finalizer内でMutexをロックして解放しないまま抜けるとabortする

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/44049

Ticket in redmine http://redmine.ruby-lang.org/issues/4988

Patch by Masaki (Glass_saga) http://redmine.ruby-lang.org/attachments/1865/patch.diff

Patch by shyouhei [ruby-dev:44051]

Masaki (@Glass_saga) reported the following code crashes:

ObjectSpace.define_finalizer("") do
 Mutex.new.lock
end

-

[BUG] thread_free: keeping_mutexes must be NULL (0x1fa0510:0x21f8ac0)
ruby 1.9.3dev (2011-07-07 trunk 32437) [x86_64-linux]

-- Control frame information -----------------------------------------------


-- C level backtrace information -------------------------------------------
../ruby_trunk/bin/ruby() [0x529687] vm_dump.c:796
../ruby_trunk/bin/ruby() [0x576768] error.c:258
../ruby_trunk/bin/ruby(rb_bug+0xa2) [0x577bc2] error.c:270
../ruby_trunk/bin/ruby(ruby_vm_destruct+0x17f) [0x52741f] vm.c:1744
../ruby_trunk/bin/ruby(ruby_cleanup+0x283) [0x4174c3] eval.c:184
../ruby_trunk/bin/ruby(ruby_run_node+0x3d) [0x4176cd] eval.c:241
../ruby_trunk/bin/ruby() [0x414849] main.c:38
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff) [0x7f7785469eff]
../ruby_trunk/bin/ruby() [0x414739]

Then he guessed why this crashes:

1. At interpreter quitting, ruby_cleanup() in eval.c calls rb_thread_terminate_all() in thread.c
2. rb_mutex_unlock_all() is called by rb_thread_terminate_all(), all Mutexes will be released
3. rb_finalize_1() is called
4. rb_gc_call_finalizer_at_exit() called by rb_finalize_1(), call finalizers
5. A one of finalizers quitted with locked Mutex
6. Crashes in ruby_vm_destruct() called after finalizing

Glass also wrote a patch, but this patch has problem that call finalizers before call rb_thread_terminate_all(). [ruby-dev:44050]

Shyouhei wrote another patch, but this patch is not right if calling ruby_vm_run_at_exit_hooks() at current position is to make vm->main_thread can't be seen from at_exit inner.

---

おそろしい事を．

ObjectSpace.define_finalizer(""){Mutex.new.lock} でRubyが異常終了するという話．

ファイナライザの中でMutexとは．すごいものだ．

[ruby-core:37866] About 1.8.7 EOL

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/37866

Ticket in Redmine http://redmine.ruby-lang.org/issues/4996

1.8.7 の End Of Life (寿命，サポート終了日) についての話

安心してください．今じゃないから．しかし，そろそろ自分たちは「いつどのように1.8.7は死ぬべきか」を議論すべきでしょう．

「おまえらは1.9を使うべき」 自分は何度も何度も何度も何度も行ってきました．もう一度言います．「おまえらは1.9を使うべき」．
そろそろ1.9.3がリリースされようとしています．(自分は手伝うことができませんが)それは素晴らしい物です．さらによい機能，さらに速い実行，Rubygems統合．
Railsは完璧に動きます．1.9を1年以上利用していますが，もうもどることはできないです．

じゃあどこに1.8.7を使う理由があるんだ．システム管理者の都合ですね．明確です．
当時1.8.7は最新だったため広く受け入れられ多くの人が使ってきた．新たにソフトウェアに追加するのをやめても，バグ修正やメンテナンスは必要なものです．
そのメンテナンスが1.8.7に自分が3年間やってきたことにあたります．

私はあなたたちがまだ1.8.7用ソフトウェアを開発していることをしっています. 近いうちにRubyコミュニティ全体が1.9に向かって移行をすすめ，1.8.7ベースのシステムはメンテナンスがされなくなることでしょう．
そのようになるのは避けたいと思っています．1.9に準備して適切に移行することが良いと思っています．

なので1.9への移行を支援するため，1.8.7の寿命を決めることが重要だと自分は考えます．
少なくともあなたは1.8がサポートされている限り1.8を使うであろうということを考えると，是非止めましょう．
寿命を迎えた後自分を含め誰も1.8.7を修正したり手を加えたりしないようにする事が重要だと思います．

自分が理想と考える1.8が死ぬまでの道のりは:

• いままでと同じようにバグを修正: 2012年6月まで提供
• セキュリティ関連の修正のみ: 2013年6月まで

是非ご意見を．

(一部意訳が含まれています．これは筆者による意訳です．非公式なものです．)

[ruby-core:37882] で，WindowsでのRuby1.9のパフォーマンス問題は深刻だ(?)との問題が指摘されていますが，それに対して「1.9.3ではrequireでの大幅なパフォーマンス改善が入ります」と回答しています ([ruby-core:37883])

またRailsコミッタでもあるtenderloveが [ruby-core:37899] で

Rails 4 はたぶん1.9のみをサポートすることになるでしょう．Rails 3.1 の段階では，1.9で作成したアプリケーション
は1.9でのみ動作します．

Rails チームは 3.2 を 2012 年にリリースすると思われます(1.8サポート込みで). その後自分は 4.0 (1.9のみサポート) を 2013年にリリースされることを期待しています．

1.8から開放されるのが待ちきれません :-)

とコメントしています．

Feature 5000 skip string creation of when clause

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/44068

Ticket in redmine http://redmine.ruby-lang.org/issues/5000

mame3 proposed that return same string in when syntax. (without x="foo" or "#{foo}x")

$ cat t.rb
5000000.times do
  case nil
  when "foo"
  when "bar"
  when "baz"
  end
end

# Without patch
$ time ./ruby.org t.rb
real    0m4.561s
user    0m4.488s
sys     0m0.004s

# With patch
$ time ./ruby.new t.rb
real    0m2.881s
user    0m2.828s
sys     0m0.036s

Bug 4971 Module class_variables

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/44034

Ticket in redmine http://redmine.ruby-lang.org/issues/4971

shugom said currently ruby's Module#class_variables doesn't return superclass class variable.

class Foo
  @@foo = 123
end

class Bar < Foo
  @@bar = 456
end

p Bar.class_variables #=> 1.8: ["@@bar", "@@foo"], 1.9: [:@@bar]

[ruby-dev:44055] [ANN] Ruby 1.9.3 Release plan

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/44055

Fix of Ruby 1.9.3 Release Plan.

• 2011-07-10: Create ruby19_3 branch, revert Module#mix. Implementation freeze.
• 2011-07-17 or 18: ruby-1.9.3-preview1
• 2011-08-01: ruby-1.9.3-preview2
• 2011-08-26: ruby-1.9.3 hopefully

NOTE: Release plan must be not like "ruby1.9.3 should be released at 2011-08-26. core team shouldn't make any delays." This is wrong.

---

Ruby 1.9.3 のリリースプランが正確な日付とともに修正・確定されました．

• 2011-07-10: ruby_1_9_3 ブランチを作成し，Module#mixをrevertした上実装を確定
• 2011-07-17 か 18: ruby-1.9.3-preview1
• 2011-08-01: ruby-1.9.3-preview2
• 2011-08-26: ruby-1.9.3 をリリースできると良い

NOTE: リリースプランは絶対ではありません．

Tips: 原文の hopefully がなんかコードネームのように見えることから，一部の開発者がコードネームのように使っていますが，公式のコードネームではないので注意してください． hopefully はやくリリースされないかなあ．

Bug 4925 Infinite recursion allowed in rescue clause

From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/37346

Ticket in redmine http://redmine.ruby-lang.org/issues/4925

def a
  b
rescue NameError
  a
end
a

どんな例外でも，このようにrescueの中で再帰をするとCPUとメモリをRubyが食い尽くすことが報告されています．
(本来はSystemStackErrorが出るべき)

1.9系列でのみ再現し1.8のHEADでは再現しないことも．

しかし [ruby-core:37926] でそれは仕様である事が伝えられています．