evan.musing << current

It’s been too long since my last post, so I’m going to try to keep to a strict schedule of at least one post a week.

For this week, I’d first like to wish everyone a happy holidays.

Now onto rubinius. The pace of the project has increased a lot — we’ve moved from revision 25 to revision 255 in only about a month, which is amazing. There are about 4 of us who have arisen as the core developers, with around 6 or so others that have sent in patches and gotten commit rights. Ohloh has begun tracking our stats.

There has been a big push to get a good testing framework worked out to move further towards rspec. brixen and srbaker have been committing spec files and getting the filesystem laid out, as well as working on a driver to run specs against rubinius easily. I think that soon there will be a rubinius testing committee that arises to drive all the rubinius testing.

As for me, I’m currently focused on about 4 main goals. The first was to get a good framework for the rubinius workflow to seen by everyone and to set down a little bit of process to keep everything moving smoothly. To that end, I’ve been hacking furiously on collaboa, adding features that I want to use. The result is rubini.us. It’s running our custom collaboa instance, to which i’ve added 2 of the nicest features of trac: a wiki and a timeline. The other feature I’ve added is tags, to help organize and search the tickets and wiki.

I’ll be putting down collaboa for a little bit to focus on the rubinius source again. My first task is to get the VM self-hosted, that is to say, getting the compiler to compile itself so that the standalone rubinius VM can actually compile and run programs all by itself. The last push to this goal had me integrating the parser from syd-parser to generate sexps from strings and files full of ruby code. There is still some debugging to work out there, but it is functioning. Now I’ll be focusing on getting the compiler runtime to work properly. I suspect that I’ll have a first cut of this goal committed within the next few days, then I’ll dig in and fix a few bugs that I’m aware of in the compiler process. My hope is that the first cut will work well enough that the testing guys will be able to just ask the VM to run a file full of ruby code and it will do it properly. This will also make running the bfts tests under the VM a lot easier.

The last big goal on my plate is the integration of code to allow for methods to be implemented by C functions. 1.8 sports this ability and it is used constantly, actually forming the core of the 1.8 core library. rubinius will have the exact same C api as 1.8, to make porting C extensions from 1.8 to rubinius that much easier. The idea is to write a shim library that sits between the C extension and the rubinius core. This shim library will protect the core from corruption and still give the C extension all the same power that it currently has. The working name for this framework is RNI (Ruby Native Interface), but people have been pretty vocal about picking a different name. If you have a suggestion, leave it in the comments.

Well, that rounds out this post. See you in 2007!