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つの提案をしています:
- 世代別GCを導入する; これは全ての拡張ライブラリの変更も要求するので2.0まで不可能.
- Rubygemsをダイエットする; 可能なかぎり生成するオブジェクトを減らし,参照を保持しないように変更する
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 useThreadGroup
for sandboxing.
By the way I agree to do something to
ThreadGroup
becauseThreadGroup
doesn't have much of features.
But I thinkThreadGroup
is still useless however we add some new features toThreadGroup
because
use case ofThreadGroup
is not decided.
Next, nagai-san answered in [ruby-dev:43978],
Q. What is use case of bundling Thread
s ?
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 useThreadGroup
.
This improvement expand use case ofThreadGroup
, this also means increase the range ofThread
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]
- Discussion is stopped; This issue will not be going to merge.
- Java has
ThreadGroup
; that is as poor as ruby's... java users doesn't useThreadGroup
actively, and they don't want to expand it. Why ruby needsThreadGroup
? - Future of
Thread
is dark... Because we can't increase parallel level with GVL. - But if we use multi process or multi vm, after all this improvement is useless.
- 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."
- We need lock for each
ThreadGroup
if we add some new method toThreadGroup
, does this improvement effects to JRuby? (it doesn't have GVL)
nagai-san answered to these in [ruby-dev:43980]
- Discussion is stopped because most user doesn't use
ThreadGroup
. most users don't have trouble aroundThreadGroup
because they're not using. - i feel
ThreadGroup
is useless, does this mean i'm strange? - that is it if 1 process ruby only. but that is not if working in multiple servers.
- In head of my first mail in this issue is real problem that i think it's useless
- method namespace needs lock when only adding, is this wrong?
- 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:
- At interpreter quitting,
ruby_cleanup()
ineval.c
callsrb_thread_terminate_all()
inthread.c
rb_mutex_unlock_all()
is called byrb_thread_terminate_all()
, allMutex
es will be releasedrb_finalize_1()
is calledrb_gc_call_finalizer_at_exit()
called byrb_finalize_1()
, call finalizers- A one of finalizers quitted with locked
Mutex
- 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] でそれは仕様である事が伝えられています.