!kiyoka.blog.2012_04 RSSPLAIN

Related pages: !kiyoka.blog.list
55555553133333333033344444444444444404445555555555555555555555555555555555555555555555555550555555555555555550555555555505555555555550555555555555555555555555555555555555555555555555555555555555055555255555555555555055555555555555555555555555555555555555555555555555555550555555555555555550555555555555555555555550555555555555555555550555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555505
5

kiyoka日記。NendoSekkaの開発や、最近思うことなど

5

最新10件!kiyoka.blog   過去記事一覧!kiyoka.blog.list

5

kiyoka.blog_header 

5

このブログを書いている人: 西山 清香(kiyoka) - twitter: @kiyokaEXT

5

5

 

5

 

3

kiyoka.2012_04_28[KVS][TRIE] distributed-trieEXT 0.8.0 リリース

1

distributed-trie-logo

3

ファーストリリース。

3

とりあえずSekkaに組み込んでライブラリAPIとして使えるということが検証済みなのでリリースした。

3

コードの高速化はまだやってない。ソースコードはもうすこしリファクタリングが必要かも。

3

また、trieキーの削除には対応していないなど、まだまだ改善しないといけないこと多いが…

3

 

3

高速化は 0.8.x でやり、キーの削除は 0.9.x でやるという感じのぼんやりとしたマイルストーンを予定している。

3

どのDBでどこまでスケールするのかという計測も順次やっていかんとなぁ。

3

 

0

comment (disabled)

3

3

 

3

 

4

kiyoka.2012_04_26[Sekka][KVS] Sekka辞書にdistributed-trieEXTを利用する際の最適値を見付けた

4

 

4

先日、曖昧文字列マッチングのindexをtrieにしたが、モッサリした動きになったと書いた。

4
 「kiyoka.2012_04_23[Sekka][KVS] distributed-trieを使って曖昧文字列検索実装してみた感想」
4

 

4

今日はSekka 1.1.0はこれで行けるという最適値を見付けたのでメモしておく。

4

以下の設定でほぼリアルタイム(0.2秒間隔)で変換でき、ユーザー語彙登録中も1秒以内に変換レスポンスが返ってくる。

4

Sekka 1.0.xよりも少ないメモリ使用量で効率的に動けるようになり、前のように10秒以上レスポンスが返ってこない場面も無くなった。

4

 

4

最適な組みあわせ

4
KVSはTokyo Cabinetを使う。Redisは不要。
4
Tokyo Cabinetのキャッシュ設定を256MByteにする。 ( #xmsiz=256m )
4

 

4

やっと、distributed-trieの成果が現れてきたので嬉しい。

4

 

0

comment (disabled)

4

4

 

4

 

5

kiyoka.2012_04_23[Sekka][KVS] distributed-trieを使って曖昧文字列検索実装してみた感想

5

 

5

曖昧文字列マッチングのindexをtrieにしたのだが、前よりもモッサリした感じになった。

5

 

5

以前のバージョン 1.0.x では、"Kanji"というクエリに対して、1.6MByte程度のインデックスがKVSから1回で返ってき

5

ていた。

5
 例
5
  MASTER::(ka)    ka ... kanji ... (1.6MByteもある)
5

 

5

今回のtrieを使ったバージョン 1.1.x (開発版) ではtrieのツリーを辿りながら、曖昧文字列マッチングをするという方式に変えた。

5

文字列の流さが10文字であれば、悪くて100回程度のKVSへのリクエストが飛ぶ可能性がある。

5
  例
5
  Master::Index::k     a$
5
  Master::Index::ka    n
5
  Master::Index::kan   j
5
  Master::Index::kanj  i$
5
  .
5
  .
5

 

5

良くなった点

5

登録が軽くなった。

5

ユーザー辞書に新規の語彙を追加した時にも重くならない。

5

read/writeのバランスが良くなった。

5

1.0.xでは辞書登録中は重くて10秒以上レスポンスが返ってこないことも多かったが、1.1.xでは辞書登録の影響はほんとんど無くなった。

5

1.0.xではインデックスの更新に、1.6MByteのwriteが発生することになるので、かなりDISK I/Oに負荷を掛けていたに違いない。

5

1.1.xでは小さいエントリを沢山細切れに書くようになる。writeの合間にreadも可能だ。

5

 

5

悪くなった点

5

変換レスポンスが悪くなった。

5

Tokyo Cabinetを使った時の体感的なレスポンスが悪くなった。

5

sekka-benchmarkコマンドでベンチマークを取ると3倍ほど速くなっているんだけど、それはベンチマークの方法が悪いということで…

5

Redisを使った時はほとんど劣化は無いような気がする。

5

 

5

辞書が大きくなった

5

辞書のリストア用TSVイメージであるSEKKA-JISYO.SMALL.tsvが223Mから381Mに増えた。

5

結果、redis-serverが消費するRAM容量が800MByteから1.4GByteに増えた。

5

redis-serverが消費する容量の増加具合が比例していない気もするが、Redisのkeyのインデックス分なのではないかと推測する。

5

KVSのエントリ数は 3873011件 から 11533536件 に増えた。エントリ数は約3倍だ。

5

 

5

改善案

5

1.0.x は Tokyo Cabinetが使うメモリ容量は64MByteだが、それを256Mや512Mくらいに設定してやれば、もしかしたら良いバランスに落ちつく可能性がある。

5

要はDISKのreadを適度に抑制してやる必要があるわけだ。

5

RedisはDISK I/Oが無いので高速なのは当然だが、メモリが大量にある人向けのオプションだなぁ。

5

自分はRedisを使うけど。

5

 

5

感想

5

なんかローカルにsekka-serverを立てる場合、良くなったのか悪くなったのかわからないなぁ。

5

多分、今回の変更でスケールアウトするようになったのは確実なのでそのあたりも調べてみたい。

5

しかしスケールアウトするといってもぴったりマッチするKVSも無いわけだが… (Redis Clusterか?)

5

うーん、何だか趣味の領域を脱出できてない気がする…

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_20[Life] SHOT NOTEで撮ったノートをクリーンアップしてみた

5

この手順の通りやってみた。なかなか良かったのでメモしておく。

5
 How to clean up photos of whiteboards with Gimp EXT
5

 

5
 EuYe
5

↑この手書きのノートを、iPhone用のSHOT NOTEのアプリで撮り、

5

例の記事の通りGimpで加工するとこうなる。↓

5

 

5

ドキュメントに貼るのであれば、スキャンした画像を意識せず見れるので気が散らないと思う。

5
 kvc8
5

 

5

ただ、SHOT NOTEの場合は方眼紙の点線があるので、それを消すためには、Gimpのガウシアン差分の半径 1のピクセル数を7.0ではなく50.0くらいにする必要があった。

5
 Gj16
5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_16[IDE][Clojure] Light Tableが凄い

5
 Chris Granger - Light Table - a new IDE conceptEXT
5

 

5

まだまだIDEの新しい考えかたはできるんだなぁと関心する。

5

Clojureを使うことがあたら試してみよう。

5

JavaScriptに対応したら結構普及したりしてね。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_15[本][NoSQL] 「ビッグデータを征す クラウドの技術 Hadoop&NoSQL」を読んだ

5

NoSQL(分散KVS)関連の仕組みがよくまとまっている。いいぞこれ。

5
 4048705741  ビッグデータを征す クラウドの技術 Hadoop&NoSQL: ASCII.technologies
5

NoSQLの部分はHBaseとCassandoraが中心に解説してあるのだけど、原理から教えてくれるので、他の分散KVSがどういうものか検討が付くようになる。

5

CAP定理についてここまで平易に書かれているものは無いような気がする。

5

おかげで、Amazon DynamoDBがどういう位置付けでどういう用途に向いているかも間接的にわかった。

5

もし、自分のように運用まで手がまわらなくて、でもHbaseやCassandoraのような本格的な分散KVSを使いたい場合はDynamoDBに頼るのが良いのだろうと思った。

5

今後NoSQLをウォッチしていきたい人は一度読んでおくことをお薦めする。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_13[AWS][KVS] Amazon DynamoDBが思ったほど低レイテンシではなかった件

5

DynamoDBを使ってみた。

5

これまで、私はTokyo Cabinet、memcacehd、 Redisといった、わりと単純なデータモデルのKey-Value Storeを使ってきた。

5

そんな私が、DynamoDBを使ってだいぶ違うということを感じたので記事にしたい。

5

それはRemote APIのレイテンシが小さいか大きいかで全く適用範囲が違う別モノだということだ。

5

 

5

分散Key-Value Storeといってもいろんなタイプがある

5

Key-Value Storeというくくりが広すぎるということもある。(NoSQLという呼び名も同じ)

5

とにかく、分散ハッシュテーブルの原理を使ってスケールアウト可能なやつは全てKey-Value Storeと呼ばれているので注意が必要。

5

大きく分けると「ドキュメントデータベース」と「それ以外」になると思う。

5

 

5

分散Key-Value Storeの分類

5

もっと別の分類方法があると思うが、アプリケーションとしてどちらを適用するかという観点で見た場合の分類として考えてほしい。

5
 HXWe
5

 

5

ドキュメント指向データベース

5

傾向として書き込みは低速、APIのレイテンシは長い。

5

一般的に、JSONなどの複雑なデータを格納することができる。

5

カラム毎にインデックスを設定することができ、後でカラムに対する検索クエリが使える。

5

そういう分類をすればSimpleDBとDynamoDBはドキュメント指向データベースだと思う。

5

MongoDBやCouchDB、BigTableも同じカテゴリに入るだろう。

5

 

5

それ以外

5

傾向として書き込みは高速、APIのレイテンシは短い。

5

Key-Value StoreのValueに保存するデータ構造がシンプルなものを全部をこっちに入れたい。

5

Tokyo Cabinet、Redis、memcached、memcachedプロトコルでアクセスできる殆どのデータベースはこっち。

5

他にもOkuyama、flareなどデータベースもこちら。

5

 

5

シングルスレッドのレイテンシ

5

Redisはシンプルスレッドのプログラムから秒間10000オーダーのレスポンスを返してくれる。

5

現在開発中のdistributed-trieEXTはそういう低いレイテンシを期待したtrieのライブラリだが、それをSimpleDBとDynamoDBに適用しようとして無理だとわかった。

5

DynamoDBの方は宣伝文句に「低レイテンシ」と書いてあるので期待してしまったのだが、シングルスレッドからのレイテンシは長めで、高いスループットは出せない。

5

APIはhttpの上にRESTで構築されているので、シングルスレッドからは秒間100オーダーを出すのがやっとだろう。実際にAWS SDKに入っているPure Rubyのクライアントからは秒間20を出すのがやっとだった。

5

従って、DynamoDBが「低レイテンシ」と書いてあるのは、複数のスレッドから平行にアクセスした場合のトータルで計算したらレイテンシが低いという意味でとらえるべき。

5

それは低レイテンシとは言わない気がするけどなぁ。高スループットは但しいけど。

5

 

5

勘違いの要因

5

DynamoDBの方は宣伝文句に「低レイテンシ」と書いてあるので、もしかしてドキュメントベースのようにもmemcachedのようにも使える万能なものだと勘違いしてしまったのが要因。

5

 

5

まとめ

5

DynamoDBはKVSと呼ばれているが、memcachedのような低レイテンシなKVSと混同して使うと失敗する。

5

むしろ、メンテナンスのいらないApache CouchDBEXTのようなものとして使うこと。

5

 

5

補足

5

適用範囲を間違えただけでDynamoDBが期待外れの性能という意味ではありません。

5

複数スレッドからのスループットは期待通りであり、DBを止めずに限界スループットを上げていける様は圧巻です。将来きっと何かに使います。

5
   Amazon DynamoDB Overview, a fully managed NoSQL database service
5

 

5

参考

5
 key-valueストアの基礎知識EXT
5
 Bigtableと分散KVS - スティルハウスの書庫EXT
5
 分散KVSの使い方 - sdyuki-develEXT
5
 ここで言うところの分散KVSには、BigTableやCassandraなどの、いわゆる
5
 Multi dimensional sorted storeは含めていない。これらの分散データストア
5
 はkey-valueよりも高級なデータモデルを持ち、単純なKVSの効率上の問題を解
5
 決しようとしている。
5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_12[Sekka] Sekka 1.0.0 リリース

5

SKKライクな日本語入力メソッド Sekka 1.0.0をリリースしました。(リリースノート Sekka.ReleaseNote)

2
 iStock_000016378483XSmall
5

 

5

リリースの概要

5

Sekka初の安定板リリースです。

5

ひととおりの機能が長期間の使用に耐えて安定してきたので、1.0.0とします。

5

memcachedの負荷が重くなった時に、sekka-serverがmemcachedが落ちているというメッセージを返していたので、少し余裕を見てタイムアウト設定を1秒にしました。

5

その後、localhostでsekka-serverでも上記のメッセージは見なくなったので、一応の調整はできたと考えています。

5

 

5

以下リリースノートです。

5

version 1.0.0

5
Memcachedのタイムアウトを1秒に拡大した。
5

 

5

次の目標

5

先日「kiyoka.2012_04_04[Sekka][IME] Sekkaのブランチを1.0と1.1にわける予定)」で書いた通り、開発版のブランチ 1.1系を開発していきます。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_07[Ruby][Nendo] Ruby 2.0(開発版)に入ったEnumerable::Lazyを試してみた(Nendo編)

5

kiyoka.2012_04_01[Ruby][Nendo] Ruby 2.0(開発版)に入ったEnumerable::Lazyを試してみた」の続き。

5

Ruby 2.0をビルドする手順は先日の記事を参照してほしい。

5

今日は、Nendoでも試してみた。

5
 3389153383_a26bb54126_m もうひとつLazyな写真
5

 

5

Nendo 0.6.4でもそのままLazyの効果は出た。

5

そういえば、書き忘れていたが、Lazyは使用メモリを削減するだけじゃなくて、計算量も削減するのだった。実際に必要な分しか計算しない。

5

今回のサンプルプログラムでは、take 5 しているので、grepして見つかった最初の5行が見つかったところで計算を打ち切る。

5

 

5

Lazyの効果

5

実際に大きなサイズのtest.txtを用意した。

5
$ du -sh test.txt
5
58M     test.txt
5

 

5

Lazyなし

5
$ time nendo ./lazy_sample.nnd 
5
[without Lazy]
5
ruby
5
ruby's
5
rubying
5
ruby
5
ruby's
5
=> VmPeak:        428816 kB  (418MByte)
5
65.48user 0.43system 1:11.54elapsed 92%CPU (0avgtext+0avgdata 1572592maxresident)k
5

 

5

Lazyあり

5
$ time nendo ./lazy_sample.nnd lazy
5
[with    Lazy]
5
ruby
5
ruby's
5
rubying
5
ruby
5
ruby's
5
=> VmPeak:         65544 kB  ( 64MByte)
5
2.19user 0.04system 0:02.45elapsed 91%CPU (0avgtext+0avgdata 132704maxresident)k
5

 

5

メモリ消費量が減ったと同時にCPU消費も減ったことも確認できた。

5

すばらしい。

5

 

5

実験したソースコード

5

先日のRubyコードはリファクタリングして読みやすくした。

5
 lazy_sample.rb
5
 sample for Enumerable::Lazy of Ruby 2.0 — GistEXT
5

 

5

Nendo版はRuby版と対比させやすいようなコーディングにしてあるので比較してみてほしい。

5
 lazy_sample.scm
5
 Nendo sample for Enumerable::Lazy of Ruby 2.0 — GistEXT
5

 

5

感想

5

Nendoに変更を加えなくてもとりあえずLazyになった。素晴らしすぎるぜ。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_05[MySQL][NoSQL] MySQL CluterがRDBMSのASIC特性を保持しつつスケールアウトできるのはなぜか

5

タイトルは釣りです…  誰か教理由を教えてください。

5

そんなことがあるわけないので、何かミスリードがあるに違いない。

5
 MySQL ::  MySQL Cluster: スケーラビリティEXT
5
 zzFG
5
 MySQL Clusterの自動シャーディング
5
   他の分散型データベースとは異なり、シャード間でクエリーおよびトランザ
5
   クションを実行する際にJOIN処理を実行する機能を損なうことはなく、
5
   ACIDを犠牲にすることもありません。
5

 

5

もう少し調べてみるつもり。

5
 MySQL ::  MySQL Cluster に関する FAQEXT
5

 

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_04[Sekka][IME] Sekkaのブランチを1.0と1.1にわける予定

5

 

5

二つの系列に分けることを考えている。

5
1.0は安定版としてメンテナンスモードへ(0.9系列をそのまま1.0へ)
5
1.1は開発版としてアグレッシブな変更を入れるモードへ
5
 nbNH
5

 

5

1.1の取っ掛かりとして、distributed-trieEXTを組み込む。

5

さてどれだけ日本語変換のレスポンスが良くなるか。

5

今のSekka 0.9系列は単語によってレスポンス性能にムラがある。

5

曖昧文字列検索のインデックスに偏りがあるせいだ。

5

distributed-trieでそのあたりのムラが減少するとみている。

5

 

5

余力があれば、その後曖昧検索付きのmigemoが作れるか実験してみたい。Sekkaの辞書を使えばできるはず。

5

問題は、生成した正規表現が大きすぎるのでEmacsが拒否してくるという可能性か。そのあたりはひと工夫要りそう。

5

いろいろやってみたいことはあるので、開発版はしばらく不安定になるかもしれない。

5

 

5

それにしても日本語入力は興味が尽きないテーマだなぁ。

5

何か新しい技術なりライブラリ(今回は分散KVSとtrieだが)があると、とりあえず日本語入力に適用してみるとその素性がつかめるし楽しい。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_03[Life] SHOT NOTEはじめました

5
 手書きメモをスッキリデジタル化「ショットノート」 EXT
5

もう、マウスで図を描くのがいやになった。ちょっとした図を描く時は時間をかけたくない。

5

というわけで、究極のUIである紙とペンを使うことにした。

5

写真はLサイズで、MacBook Proの13インチと比べてもそんなに大きくないので、机を占有しない。

5

実際に描いてみると、Mサイズでも十分図が描けそうな感じがした。

5
 B004JF4P58 キングジム ショットノ-ト Lサイズ 白
5

 

5
 EuYe
5

期待通り、短時間で図が描けてしまう。

5

Blogでなにか込み入ったことを説明する場合は、文章を書く手間も省けそうだし読む側もきっと図を見たほうが早い。

5

早速、githubで公開しているソフトウェア(distributed-trie)のREADMEにも使い始めた。

5

上の図を、SHOT NOTEで取り込んで若干色を加工すると下の図になる。

5
 urEv
5

メンテの必要の無い図を書く時は、全部これでいこう(笑)

5

おすすめです。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_04_01[Ruby][Nendo] Ruby 2.0(開発版)に入ったEnumerable::Lazyを試してみた

5

ゆくゆくは Ruby 2.0に入るようだ。

5

今回、Ruby 2.0の開発版を実際に動かしてみた。

5
 Ruby 2.0 Enumerable::Lazy EXT
5

3389965080_eaa5bc957c_m (うちの猫がLazyな時の写真)

5

 

5

Lazyが無いとどうなるか

5

 

5

次の例ように、ファイルから行単位で処理するようなRubyプログラムがあるとする。

5

bashで書くならば、 "grep ruby test.txt | head -5" のような処理。

5

 

5
  File.open( 'test.txt' ) do |f|
5
    arr = f.map(&:chomp).grep(/ruby/).take( 5 )
5
    arr.each{ |x| puts x }
5
  end
5

 

5

一般的に、読みやすいコードを心掛けると上のように全行をメモリに読み込んで処理するように書くだろう。

5

mapとかeachを使ってメソッドチェーンを多用すれば簡潔に書けるからだ。

5

 

5

ただ、メソッドチェーンの度に新しいArrayが確保されるため、test.txtが大きいとメモリを大量に消費する。

5

Lazy(遅延評価)はこれを綺麗に解決してくれる。

5

 

5

 

5

Ruby 2.0をインストールする方法

5

 

5

Ruby 2.0をビルドしたいなら、githubからcloneするのが簡単だ。

5

masterブランチがRuby 2.0の開発版になっているようだ。

5
git clone https://github.com/ruby/ruby.git
5
Cloning into ruby...
5
remote: Counting objects: 222847, done.        
5
remote: Compressing objects: 100% (44673/44673), done.        
5
Receiving objects:  92% (206057/222847), 64.40 MiB | 317 KiB/s   pwd
5
remote: Total 222847 (delta 177021), reused 220708 (delta 176422)        
5
Receiving objects: 100% (222847/222847), 76.22 MiB | 310 KiB/s, done.
5
Resolving deltas: 100% (177021/177021), done.
5

 

5
~/work/github $ cd ruby/
5
~/work/github/ruby $ ls Makefile*
5
Makefile.in
5

 

5
~/work/github/ruby $ autoconf
5
~/work/github/ruby $ bash ./configure
5
checking build system type... x86_64-unknown-linux-gnu
5
checking host system type... x86_64-unknown-linux-gnu
5
   .
5
   .
5
.ext/include/x86_64-linux/ruby/config.h updated
5
verconf.h updated
5
ruby library version = 2.0.0
5
configure: creating ./config.status
5
config.status: creating Makefile
5
config.status: creating ruby-2.0.pc
5

 

5
~/work/github/ruby $ make dist
5
ruby ./tool/make-snapshot tmp 
5
Exporting trunk@35198
5
Exported revision 35198.
5
take a breath, and go ahead
5
creating configure... done
5
creating prerequisites...
5
   .
5
   .
5
prerequisites done
5
creating bzip tarball... /home/kiyoka/work/github/ruby/tmp/ruby-2.0.0-r35198.tar.bz2 done
5
creating gzip tarball... /home/kiyoka/work/github/ruby/tmp/ruby-2.0.0-r35198.tar.gz done
5
creating zip archive... /home/kiyoka/work/github/ruby/tmp/ruby-2.0.0-r35198.zip failed
5
* /home/kiyoka/work/github/ruby/tmp/ruby-2.0.0-r35198.tar.bz2
5
  SIZE:   9913268 bytes
5
  MD5:    943937f8635458fedfc271f97e6133c9
5
  SHA256: ed5850f393db8ec39568fcd9446566ebcdabe4584c0f8c7a827e21e0bd0a9e3a
5
5
* /home/kiyoka/work/github/ruby/tmp/ruby-2.0.0-r35198.tar.gz
5
  SIZE:   12561052 bytes
5
  MD5:    60bb6bdf08dcdbf424cd757b517ded75
5
  SHA256: 898aa4e3222d5585621112dd8c277d3e565a130540f2ea8a5bd4b0d70c7ad334
5
~/work/github/ruby $ 
5

 

5

できた tmp/*.tar.gz をオフィシャルリリースされた ruby-1.9.3-p125 の tar.gz と同様にビルド、インストールできる。

5

※ ちなみに、私は stowというツールでいろんなRuby環境をスイッチできるようにしている。

5

 

5

Lazyの効果

5

実際に大きなサイズのtest.txtを用意して試してみた。

5
$ du -sh test.txt 
5
198M    test.txt
5

 

5

Lazyなし

5
$ ruby ./lazy_sample.rb 
5
[without Lazy]
5
bioruby
5
eruby
5
fxruby
5
hruby
5
hruby's
5
=> VmPeak:       1282188 kB  (1252.1MB)
5

 

5

Lazyあり

5
$ ruby ./lazy_sample.rb lazy
5
[with    Lazy]
5
bioruby
5
eruby
5
fxruby
5
hruby
5
hruby's
5
=> VmPeak:         26280 kB    (25.6MB)
5

 

5

プロセスがどこまでも肥大したか(ピーク)を調べると、lazyを使ったバージョンは25.6MByteしかメモリを消費しないことがわかった。

5

".lazy." の6文字を追加しただけでこれだけの効果がある。素晴らしい。

5

 

5

実験したソースコード

5
 lazy_sample.rb
5
 sample for Enumerable::Lazy of Ruby 2.0 — GistEXT
5

 

5

感想

5

Rubyに遅延評価が入るとは思ってなかったのでこれは嬉しい。

5

私が作っているLisp処理系のNendoはRubyとのインテグレーション済みなので、Nendoのmapやfor-eachにEnumerable::Lazy型を渡せば同様にLazyに処理できるはず。(今度実験してみよう)

5

実は、普段Nendoで500MByteクラスのテキストファイルを処理することがよくある。その度に、メモリ消費量を削減するためにfor-eachで1行づつ処理するループをコーディングしていた。

5

もうその必要が無くなるだろう。Ruby 2.0が正式リリースされるのが本当に楽しみになったぞ、これは。

5

 

0

comment (disabled)

5