p = mv (aka Momentum)

There have been some amazing things happening in the rubinius world in the last week.

  • compiler2 (aka. c2) became stable enough that we began using it for everyday usage. This is big in my mind because c2 is vastly superior to compiler1. Also, it shows the power of the approach we’re taking. To my knowledge, we’re the only project to write 2 completely separate compilers for our project. We were able to do this primarily because both compilers have been written entirely in ruby.
  • Springboarding off c2 being stable, Kernel#eval() got implemented in really an incredibly small number of lines and in a short amount of time. I began working on it at midnight one night. Worked til 3am that night, then again the rest of the next day. So in about 12 hours, we had a eval that passes the craziest of eval specs. Most of the reason for that was again the approach. Having MethodContext’s be first class objects made getting all the proper info for eval simple. The architecture for c2 made it super easy to add in the custom logic to make eval operate properly. Again, all done 100% in ruby.
  • Again, coming off eval working, irb became functional. Getting it running flushed out a few bugs (5 I think), and it runs perfectly. This is big for anyone that has looked at the irb codebase. It contains a lot of meta-magic as well as a large, complicated ruby tokenizer for parsing the code the user types in. This is giant news for me because it means that the project has finally built the codebase and momentum to run real world ruby code. I almost wet my pants when I fired up irb and it worked.
  • Galvanized by the success of irb running, I started in on rake. Rake contains a great set of tests to use to make sure rubinius is actually working properly, so I started in on those. I first found that rake’s test use flexmock, another library that jim wrote. So I started on flexmock’s tests instead. That exposed a few bugs, but after about an hour, it was running at 100%. Flexmock uses a TON of meta-magic, so having it work validates a lot of work we’ve been doing. On to rake’s test, again, flushing out bugs. I managed to get everything working except for a few things that depend on our currently broken Dir.glob.
    But in the end, I was able to have rake process our Rakefile properly and spit out the list of tasks and run a few of them. So awesome.
  • Lastly, we removed compiler1 completely and renamed compiler2 to compiler. The compiler is dead! Long live the compiler!

Man, it’s been a busy last 7 days. I’m so excited about these developments because as I said earlier, it means that the momentum on the project has built up the point that we’re making real progress running real world code. This is a seminal moment for the project. Up to now, we’ve been running uphill, slogging through specs and trying to get enough code in place. We’ve finally reached the top of the first hill and now we’re running downhill, headed for 1.0. There are a lot more hills in front of us, but clearing the first one means that there is no going back.

My hat is off to every single rubinius committer and person that has helped out on the project, most of all EngineYard. We’d never have reached this milestone in the project this early if it weren’t for all of you. Find me on the street and I’ll buy you a coffee, or in a bar and I’ll buy you a beer.


12 thoughts on “p = mv (aka Momentum)

  1. Congrats to you and everyone involved, Evan. I git pulled everything a couple of moments ago and was really excited to know irb worked from a tweet you posted a couple of days past.
    It’s really coming together, and you guys deserve all possible praise.

  2. Fantastic news, Evan!

    It really is exciting now that almost every commit fixes issues in real world code. The community is clearly electrified, and is also growing impressively.

    Tthe body of specs is just fantastic, and I love the momentum that you’ve maintained there.

    Congrats to you and the team.

  3. Totally kickass.

    The ruby specs is just one of the fantastic side effects of the project.

    Looking forward to when the focus shifts to performance.

  4. Hi.

    I’m contacting you through this form because I can’t seem to find contact details for Rubinius developers. You don’t seem to have a mailing list either.

    I’ve spent the past half year working on making Ruby’s garbage collector more copy-on-write friendly. To make a long story short: copy-on-write semantics on modern Unix systems makes it possible save a lot of memory in Ruby server applications, but Ruby’s garbage collector modifies objects every time it scans through the heap, thus rendering copy-on-write semantics useless. My patches fix that.
    I’m wondering whether Rubinius’s garbage collector is/will be copy-on-write friendly. I’m also wondering whether it’s a simple mark-and-sweep GC or a generational GC. If you’re interested in discussion, please email me.🙂


Comments are closed.