Ruby Weekly Report

1.9.3 is nearing you / 1.8.7 will be died.

2011-07-10T11:15:00.002+09:00

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 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]

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 use ThreadGroup actively, and they don't want to expand it. Why ruby needs ThreadGroup?
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 to ThreadGroup, 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 around ThreadGroup 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() in eval.c calls rb_thread_terminate_all() in thread.c
rb_mutex_unlock_all() is called by rb_thread_terminate_all(), all Mutexes will be released
rb_finalize_1() is called
rb_gc_call_finalizer_at_exit() called by rb_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] でそれは仕様である事が伝えられています．

欠席裁判

2011-06-26T14:19:00.002+09:00

Bug 3924 Performance bug (in require?)

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

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

nahi (Hiroshi Nakamura) measured loading times of 2 rails 3.0.7 apps on 1.9.2p274, 1.9.3dev r32204, 1.9.3dev r32204 with Shyouhei's expand_path cache patch.

He asked a downside of this patch.

Then, mame3 (Yusuke ENDOH) said that paths stored in cache won't never be collected by GC.

--

中村さん (nahi)が2つのrails 3.0.7アプリにおいて，1.9.2p274, 1.9.3dev r32204, 1.9.3dev r32204 に shyouheiさんのexpand_path cache patchを加えた物で起動時間を測定しました．

そして彼はこのパッチのデメリットを聞いたところ，遠藤さんがキャッシュされたpathはGCされず，メモリリークするのではないかとの懸念を示しました．

[ruby-dev:43898] Bug assigning party

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

Sasada announced bug assigning party will be held tomorrow. (6/26 JST)

The party attendees assign not-assigned tickets to maintainers, etc.

Not-assigned tickets are over 100.

--

ささださんが1.9.3リリース前に，未アサインのチケットを
誰かに押し付け
適切な担当者にアサインする会を開くそうです．

欠席裁判怖い

kosaki0: こわい
kosaki0: いないと欠席裁判で無茶振りされる会ですか
ko1_ndk: そうです＞無茶ぶり

(Logs from #ruby-ja, ircnet)

Feature 4921 Remove intern.h

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

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

Naruse proposed that remove intern.h.

First, what's intern.h?

I think intern means "internal", but if it is, it's not good that intern.h is in include/ruby.

Matz agreed at [ruby-dev:43876] if it won't raise compatibility problem.

This change will be included soon.
Contents in intern.h will be moved into ruby.h, and intern.h will only include ruby.h and nothing else.

[ruby-core:37336] I have imported Rake 0.9.2 to trunk

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

Eric imported rake 0.9.2 to trunk.

Eric が rake 0.9.2 を trunk にマージした旨を伝えています．

Bug 4920 Process.daemon()呼び出しによりタイマースレッドが２つ出来てしまう

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

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

Kosaki reported a bug that another 2 timer threads are created when call Process.daemon.

Fixed at r32221.

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

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

Patch (from r32226) pasted on mail

Nagai proposed method ThreadGroup#make_local_space as a ThreadGroup improvement.

ThreadGroup#make_local_space creates independent space by a one ThreadGroup for methods.

Method that defined in ThreadGroup that has local space is available only in that ThreadGroup.

Other ThreadGroups can see original method, they don't get effect.

闇

2011-06-22T13:40:00.002+09:00

Bug 4909 Trap handlers should not be re-enterable?

From [ruby-dev:43852] trapハンドラは再入されてはいけないのではないか？

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

Kosaki said, the following code shouldn't raise any Exception.

n = 0
intrap = 0

parent = $$

trap(:USR1) {
  if intrap == 1
    raise "trap nested"
  end
  intrap = 1
  10000.times {
    n += 1
  }
  intrap = 0
}

fork do
 Process.kill(:USR1, parent) while true
end

sleep 100

Problems are:

You can raise stack overflow by throwing signal continuous (like this program).
There is no signal blocking method; like sigprocmask() in ruby level, so we can't write good signal handlers in ruby.

He also said that C masks signal during running signal handler, so MRI should make same consideration as C.

Feature 4891 Vector#normalize

From [ruby-dev:43829] Vector#normalize

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

Patch (by mrkn) https://gist.github.com/1029140

mrkn suggested new method Vector#normalize to normalize Vector.

Lafortune will be import this method.

Is there feature freeze to release 1.9.3? I think no announce exists about freezing.

[Bug 4444] Errors at test_parallel.rb on Windows platform

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

Now windows can run make test-all parallel. thanks usa.

[ruby-list:48190] [ANN]RubyKaigi2011 1st day night "YamiRubyKaigi2011" information and call for proposals

From [ruby-list:48190] [ANN]日本Ruby会議2011 1日目夜「闇RubyKaigi2011」開催情報とスピーカー募集のお知らせ

Related link (Japanese) http://yamirubykaigi.wordpress.com/

"YamiRubyKaigi2011" will hold at RubyKaigi2011 1st day night.

RubyKaigi2011 attendees can attend this event too.
And YamiRubyKaigi2011 has limited special attending campaign. RubyKaigi2011 executive committee will announce that.

Information page (Japanese): http://yamirubykaigi.wordpress.com/2011/06/21/yamirubykaigi2011info/

RubyKaigi 1st day night; 7/16(Sat) 20:00-21:30 (JST)

http://rubykaigi.org/2011/en/schedule/details/16MDN

YamiRubyKaigi2011 also wants speakers.

CFP description is here: http://yamirubykaigi.wordpress.com/2011/06/21/yamirubykaigi2011cfp/ (Japanese)

Theme: Anything about Ruby

Time: 3min-5min

This is last chance to talk in RubyKaigi2011.

You can apply to this event as speaker before RubyKaigi2011 or at RubyKaigi2011 first day (detail will be announced at place!)

Tip: Yami (闇) means darkness in Japanese.

Note: This page is not official announce.

闇RubyKaigiとやらがRubyKaigi2011の1日目の夜にあるそうですよ．

Feature 4907 enumerable#permutation and combination

From [ruby-core:37231] enumerable#permutation and combination

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

既にArrayにはpermutationとcombinationで組み合わせ，順列を生成できるが，Enumerableなオブジェクトでもできるべきだという提案．

今のところ進展は見られない．

Write a patch!

2011-06-18T01:05:00.000+09:00

This is my first report; 最初のレポートをお届けします.

[ruby-dev:43834] new deadlock detection

ko1 proposed a new deadlock detection method with patch.

How it works

"Thread waker" changes sleeper
Only compareing living thread num and sleeper is needed for detection

Asset

Deadlock detection code is more beautiful than currents.

Patch

patch is in mail (base64 encoded)

[ruby-core:37164] Enumerable#lazy

(1..100).map{|x| 長い文字列等を生成する作業 }.select{|x| それを選択する作業 } 等だと，まず Enumerable#map を実行して
中間配列を生成，そしてその配列を Enumerable#select に渡すのですが，長い文字列等を作り配列にするとかなりのメモリを消費するため，
生成した物を中間配列を生成せずにそのまま次の Enumerable#select に渡したいよね，という話は前から上がっていた． (後述の rude_map もそれ)

Enumerable#rude_map なども良いが，見た目カッコ悪い．どうせなら別のEnumeratorを生成して，綺麗にどんなメソッドでも遅延評価できると良いのでは? という案もあった．

このチケットはその案，Enumerable#lazy を実装し， (1..100).lazy.map{|x| 長い文字列等を生成する作業 }.select{|x| それを選択する作業 } などで好きなEnumerableメソッドを遅延評価できる．

Enumerable#lazy は Enumerable::Lazy クラスのオブジェクトを返します．

Enumerable::Lazy は Enumerable のサブクラスで，Enumerableをインクルードしています．そのためあなたはLazyでもEnumerableと同じメソッドを利用することができるそうです． (ただし一部のメソッドはLazyで再実装されている物もあります)

Ruby での実装 (動作を確認するための仮の実装) lazy.rb

あわせて読みたい #4653 Enumerable#rude_map

[ruby-core:37170] Literal Instantiation breaks Object Model

例えば String.new ではinitialize呼ばれるのに，リテラルから生成した場合呼ばれないじゃねーか．と

リテラル化するときもRubyレベルで定義されたinitialize呼ぶべきじゃないでしょうかー．というバグ(提案?)

バグには見えないし，対応する理由も特に見当たらないのでReject．奥義「パッチを書いてこい」

Hi

2011-06-17T00:49:00.001+09:00

Hi.