Ruby Implementations Roundup: Ruby Spec, New Design Meetings, Rubinius uses C++

Posted by Werner Schuster on Apr 29, 2008

Sections

Development,

Architecture & Design

Topics

Ruby ,

Technology ,

Dynamic Languages ,

Language ,

Runtimes

Tags

Rubinius ,

RubySpec ,

Google Summer of Code ,

IronRuby ,

Ruby1.9 ,

JRuby

With Ruby 1.8.x, Ruby 1.9.x, Rubinius, JRuby, IronRuby and other Ruby implementations, a lot of developers are working on Ruby runtimes. To coordinate compatibility and the future of the Ruby platform, Ruby design meetings have been set up.

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 next design meeting in scheduled for 30th April - see the Ruby Design Wiki for the agenda and the details for the next Ruby design meeting.

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

A project that puts great emphasis on a RubySpec is the Rubinius project, whose developers spend a great amount of time writing executable specifications for Ruby. A recent development in Rubinius was Evan Phoenix' port of the core VM ('shotgun') from C to C++. As a reminder, while the aim of Rubinius is to write a Ruby implementation in (mostly) Ruby, the core VM was written in C - and now C++. Despite this C++ VM, Evan Phoenix explains why the Rubinius team sticks with the Ruby in Ruby motto:

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

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.

• Older >