The first design meeting took place 21st April (see the IRC log for the first Ruby design meeting). The topics discussed included:
- After research on Ruby MVM implementation was kicked off recently, the meeting discussed a few implementation details and the solutions currently available in Rubinius and JRuby. The Ruby MVM mailing list and design documents are available now.
- Running the RubySpec for the Ruby 1.8.x code base was discussed. Results of a RubySpec run of Ruby 1.8.7 are available online.
The work on a Ruby specification is also the topic of two Ruby Google Summoer of Code (GSoC) 2008 projects:
- Specs for Ruby Standard Libraries by Federico Builes
- Improve Standard Library Specs by Arthur Schreiber
Rubinius today has around 150 people who have received commit rights. The vast, vast majority of their work has been in the kernel, because this is the largest part of the whole system. And probably 95% of that work has been writing Ruby code. This means that for pretty much all contributers, helping with Rubinius means writing Ruby code. And thus to them, it is Ruby in Ruby.
Brian Ford, also of the Rubinius project, provides some more information:
In the new C++ VM (which is not yet complete but substantially implemented), we have 12,619 lines of C++, and in our kernel directory, we have 23,882 lines of, what now, oh, right Ruby code.Note: Both Evan's and Brian's blog posts were written in reply to a post by JRuby's Charles' Nutter, in which he takes issue with Rubinius' "Ruby in Ruby" motto.
[..]
The C VM (named shotgun) was not our last word. Nor is the next generation C++ VM. They are both pragmatic steps toward a higher goal. And, let’s be very clear. We have not recently implemented a bunch of core methods in C. I’ve done two major pieces of rework recently that introduced a number of primitives (chunks of C code that access the VM directly). One was LookupTable, which was written in C because it is used heavily in the VM. However, it is exposed to Ruby code as well because, oh yes, we write a ton of stuff in Ruby, like stuff related to method and constant lookup. LookupTable acts a lot like a Hash, but separating it from Hash actually made Hash more clear and enabled writing even more of Hash in Ruby.