最初のデザインミーティングは4月21日に行われた(source)(最初のRubyデザインミーティングについてはIRCログを参照のこと(source))。討論の議題には、次のようなものがあった。
- Ruby MVM実装に関する研究が最近開始されてから(source)、ミーティングではいくつかの実装の詳細とRubiniusとJRubyで現在利用可能なソリューションについて議論した。現在、Ruby MVMメーリングリストとデザインドキュメント(source)が利用可能である。
- RubySpecをRuby 1.8.xコードベースで実行することが議論された。Ruby1.8.7でのRubySpecの実行結果はオンラインで参照できる(source)。
Ruby仕様への取り組みは、次の2つのRuby Google Summoer of Code(GSoC)2008プロジェクトの議題でもある(source)。 RubySpecを重視しているプロジェクトはRubiniusプロジェクトである。その開発者はRuby用の実行可能な仕様の記述にかなりの時間を費やしている。Rubiniusにおける最近の開発は、Evan Phoenix氏のCからC++へのコアVM('shotgun')の移植であった。注意すべきことは、Rubiniusの目標はRuby実装を(主に)Rubyで記述することであるが、コアVMはC(現在はC++)で記述されたことだ。このようなC++ VMにもかかわらず、Rubiniusチームがなぜ「Ruby in Ruby」のモットーを堅持しているのかについてEvan Phoenix氏は次のように説明している(source)。
Rubiniusにはコミット権限を取得した約150人が関与しています。彼らの仕事の大部分はカーネルに関係しています。カーネルがシステム全体の最大部分であるからです。そして、恐らくその仕事の95%はRubyコードを記述することです。つまり、ほぼすべての貢献者にとって、Rubiniusの支援とはRubyコードを記述することを意味しています。したがって彼らにとって、これは「Ruby in Ruby」なのです。
Brian Ford氏(彼もまたRubiniusプロジェクトの一員である)は、さらに多くの情報を提供している(source)。
新しいC++ VM(まだ未完成だが、ほぼ実装完了)では、12,619行のC++があり、カーネルディレクトリでは、23,882行のRubyコードがある。
[..]
CVM(shotgunと呼ばれる)は私たちの最終目標ではありませんでした。また、次世代C++ VMも違います。これらはどちらも、より高い目標に向けた実質的なステップです。そして、明確にしましょう。私たちは最近、一連のコアメソッドをCで実装していません。私は最近、手直し作業の2つの主要部分を行い、多数のプリミティブ(直接VMにアクセスするCコードの塊)を導入しました。その1つはLookupTableです。これはVMでよく使用されるためCで記述されましたが、Rubyコードにも示されています。なぜなら、私たちはRubyでメソッドや定数参照に関連するものなどを大量に記述したからです。LookupTableはHashとよく似た役割を果たしますが、Hashと切り離すことで、実際にHashがより明確になり、Rubyでより多くのHashを記述することも可能になりました。
注意: Evan氏とBrian氏のブログ投稿は、JRubyの作者Charles' Nutter氏による投稿(そこで彼はRubiniusの「Ruby in Ruby」モットーに反論している)への返答として書かれたものである(source)。
原文はこちらです:http://www.infoq.com/news/2008/04/ruby-impl-roundup-spec-meetings