Rubinius Serial Interview, Episode II

Episode I seemed popular (good thing I start at one, and didn't do episodes 4-6 first), so here's a second go at it. Thanks again to Evan and Wilson for taking part in this, and for the positive feedback I've gotten from the community.

---

cuby has been mentioned twice now, once in the original interview with Evan, and again in the last installment. Can you tell us a bit more about it? Maybe give an example?

Evan: cuby is a tool that we're going to beginning using soon to make the core of the VM a bit easier to work with. The core concept is that it's functions like a pretty complicated C preprocessor, but where the input is ruby code and the output is C code. The intention is not to be able to run any old ruby code into it and get C code out, it's to make write the C code that goes into the core easier by making it at least look ruby like when it's written.

A simple example would be, say that you've already setup what cuby calls a type map that looks like:

{ :Object => { :class => "object_class(%s)" } }

and then you've got cuby code:

obj.declare :Object
obj.class

That would output the following C code:

object_class(obj);

I'd probably liken it to the first C++ compiler that was really just a preprocessor that output normal C code that was then compiled.

Wilson: The basic idea is to rip off (gently) an idea from Squeak, and maybe one from the Algol-based stack computers. In other words, code the system in a simplified dialect of itself. Cuby uses a subset of Ruby to generate platform-specific C code that can then be compiled into the VM.

The Rubinius C core isn't quite boilerplate, but it is deliberately extremely simple. I don't think anyone is going to write Photoshop 12 in Cuby, but for the kind of highly-standardized C code we want to see in the VM core, I think it's an interesting idea.

What new user contributions have surprised you the most?

Evan: I'd say how much work is being done to add RSpec specs for rubinius. People really seem to like them and are putting quite a bit of work into getting them running well.

Wilson: I'm not personally surprised by the RSpec slant, because all right-thinking, freedom-loving Ruby users use RSpec. However, something in the works recently has managed to be a happy surprise. A spec technique is underway that will allow any two Ruby implementations to be compared.

I'm making up the syntax here, since it's not finalized, but..

code = "puts 5"
code.output_from(:rubinius).should == code.output_from(:jruby)

Would execute the code under the two named interpreters, and fail unless they produced identical STDOUT.

Running valgrind on rubinius is a cool feature of the project. How else are you looking to keep code quality high?

Wilson: Valgrind is amazingly great, and counts as at least three items in the code quality armamentarium.

I was toying with the idea of rigging gcov to produce code coverage stats for the C code exercised by the Ruby tests (*phew*), but that's starting to look like an excuse for grey hair.

I'm also excited by Xray, which basically amounts to a MacOS X port of DTrace. I intend to use that to peer into the guts, when it becomes available. Solaris is cool, but I'm not man enough to use it as my main development system, and I look forward to such things being available on systems with, uhh.. sound cards.

P.S. I will build a personal shrine to anyone who ports Valgrind to MacOS X. With incense and everything.

Evan: I try to impress upon anyone working on the rubinius C code to keep things as simple as possible. There will be no awards for fancy C code in the rubinius core (in fact, there may be unawards for doing so), so that helps because the simpler the code, the less chance of there being strange bugs.

I'm still looking for a good C analysis tool for OS X, so if anyone knows of one, let me know.

With Heckle being released, what are the chances of rubinius getting heckled?

Evan: I don't see why not once rubinius is self hosted. The 'kernel' of rubinius is just normal ruby code, so as long as the specs and tests perform the right checks, it will work eventually.

Btw, self hosted means that the rubinius VM is able to compile new methods on it's own. Currently it still requires 1.8 to compile methods for it.

Wilson: Heckle is awesome, and I look forward to using it. However, it will definitely need a feature to let you ignore 'safe' mutation points before it will be very helpful to Rubinius. Getting any non-trivial system to pass Heckle without any errors is basically impossible.

---

Wilson is a big fan of this book, so we've picked it as our sponsor for this edpisode. If you're interested in working on rubinius (or any other VM) it's probably a good addition to your library. Update: if you have ad blocking on, you've missed the 'sponsor' adds. Wilson recommended the bookVirtual Machines.

Previous episodes of the Serial Rubinius Interview are available here:

• Episode I, in which we talk about the rubinius community