rubinius Serial Interview: Episode IV

This time around, we're talking about cooperation between JRuby and rubinius developers. It's a timely topic, since Nick Sieger is starting a Serial JRuby Interview. Good times.

Evan wasn't available this time around ... I understand he's in seclusion working on rubinius' Garbage Collection. I'd rather have him get that right than respond to these — I think you'll agree.

---

I've been really excited to see all the discussion between the JRbuy developers and rubinius developers -- in fact, Nick Sieger (who's been hanging around in #rubinius) is now a committer for the JRuby project. What benefits do you see coming from this kind of cooperation?

Wilson: It's a pretty good time, really. JRuby people share cool optimizations from Hotspot, and Rubinius people scour the net for research papers to steal from. I hope to see the two groups collaborate on RCRs over at http://rcrchive.net I think everyone agrees, for example, that the class variable behavior in Ruby 1.8 is insane. As we get around to implementing 'rough edges' of Ruby, we are going to write up requests to smooth them out. Hopefully Nick will vote for mine, and I'll vote for his. Heh.

Nick: Well, certainly we hope to all mutually benefit and better each others' efforts. I think it's significant to see such a deep level of cooperation and comraderie from two teams with similar goals. We could compete against each other for the title of fastest or most fully-functional ruby implementation, but the friendliness of the Ruby community for one seems to have a big effect on our working together.

If you could get the core Ruby and alternative VM implementers together for a week, what issues would you like to see them focus on?

Nick: Being new to the implementation game, with no examples gained from first-hand pains re-implementing Ruby that need to be improved, I would say the first thing to do would be to just brainstorm and agree upon a top-N list of things that need to be fixed. Several areas of Ruby need whittling back and don't have to be so complicated. Re-examine the most common usage patterns and "say no" to those edge case features that have little value.

If I were to try to name specifics, some of the things going around IRC lately are threading/concurrency (needs to be easier to do right and do well) and language features that are too intertwined with the parser/syntax tree ( e.g., "defined?") that make implementors' lives difficult.

Wilson: I think that week could be profitably spent writing test cases and working on the spec framework. A comprehensive set of executable specs will help everyone.

Alternately, we could all get drunk and read through the JVM Hotspot source code.

The biggest news in Ruby land right now is probably the announcement of a fully merged YARV. What effect does this have on rubinius?

Nick: Well, it's more visible fresh blood, that should be more accessible to Ruby hackers. Hopefully some of the cross-platform compilation and execution issues that exist will go away soon and make it easy for Rubinius and JRuby hackers to steal — umm, incorporate more ideas that might allow for more implementation sharing in the future. For example, a shared or compatible bytecode.

Wilson: I think it means the race is on. Heh.

One tricky aspect is that YARV is targetting 1.9. JRuby is aimed at 1.8, while Rubinius is forming up on something like "1.9 transitional". By that I mean that we sometimes take the 'low road' and implement things in a way that is compatible with existing code, but perhaps not the letter of the ruby1.8.5 law.

An example: the defined? keyword in Rubinius returns true or false. Ruby 1.8.5 returns a string or nil.

That sounds like an incompatibility, but it turns out that every scrap of public Ruby code uses defined? as the condition of an if/unless statement. True or false works fine, and is a lot easier to implement.

I'm not sure if that makes Rubinius an 'Opinionated VM' or not. I know that I'd rather get a feature working and move to the next one than spend a week on all the implementation details from 1.8. We can get our heads together later and decide what the real Ruby Spec is.

---

This episode is brought to you by: Code Craft. It's a new book from No Starch Press about becoming a better programmer, good stuff.

Previous episodes of the Serial Rubinius Interview are available here:

• Episode 1, in which we talk about the rubinius community
• Episode 2, in which we talk about cuby and testing tools
• Episode 3, in which we talk about rubinius documentation

• Episode 1, in which Charles, Thomas, and Ola talk about their plans for JRuby.

The Five Things Meme

Now that Charles Nutter has tagged me with the Five Things meme, I guess I ought to give it a shot. Here are five things you probably don't know about me:

• I never intended to get into computing as anything more than a hobby. I planned on being a chmical engineer instead.
  I joined the army straight out of High School to earn money to go to college, and got involved in computers and networks. Then when I got out, Boeing offered me a job and I just never found my way back to school.
• (From the above) I'm self-taught (well, I have an unorthodox education — I've learned a lot from a lot of people)... no degree, only a few college level classes taken here and there.
• I used to manage the Koha project. It's a free software library management system. It looks like they're doing just fine without me though.
• I'm a fan of the classical period, and humanities in general. I read the Illiad and the Oddesey when I was in fourth grade (my dad's method of getting me to read stuff was to leave copies sitting around) and haven't looked back. If I could figure out a way to get paid for sitting in a musty library reading old latin/greek/syriac/hebrew texts I'd drop this computing stuff in a heartbeat.
• I'd really like to write a book of textual/literary analysis of the sermons/discourses of Alma the Younger in the Books of Alma and Mosiah in the Book of Mormon.

Now, I'd like to see what five things I didn't know about Kevin Tew, Doug Tolton, James Gray, Wilson Bilkovich, and Eric Hodel will reveal.

RSpec and Unit Tests: Localizing Problems or Reducing Coupling

I'm just starting to work through a copy of Working Effectively with Legacy Code by Michael Feathers. I've had my eye on the book for a while, and am really glad I was able to borrow a copy (now I just need to buy my own). Like any good book it's making me think, making me question things I've taken at face value. So far, the best example of this is in his discussion of Unit Testing.

I've recently been looking more at RSpec and BDD instead of Test::Unit, bu haven't quite caught the vision. Something that Michael wrote made me wonder about it even more. One of the big values of RSpec is that it reduces coupling between tests and code, which sounds really good. Then I read Michael's list of the qualities of good unit tests:

1. They run fast.
2. They help us localize problems.

(see p. 13).

At first this seems like it contradicts the aim of reducing coupling (a la RSpec). I can see two possible responses:

1. RSpec isn't about unit testing, it's about testing at a higher level — but does this mean we should still have unit tests?
2. Specifications and Contexts should be written against specific classes (though not necessarily against specific methods — but doesn't this limit the decoupling we can do?

I'm not sure a completely grok this. Anyone want to weigh in?

Abandoned Projects, Bus Proofing, and a Draft Directive

I'm glad the people behind RubyForge have come out with a formal plan for handling 'abandoned' projects. I don't like the decision they made, but it's their's to make, so I guess I can't argue. Instead, I'd like to make sure I 'bus proof' my projects — if I get hit by a bus (or otherwise drop off the 'Net),

To me, running a project is both an opportunity and a responsibility. In starting several projects, I've taken on an obligation to the community, and if I just abandon a project I'm not fulfilling that obligation. (To me, while "Free as in speech" is more important than "Free as in beer", "Free as in puppies" is pretty important too.)

I'd like it to be clear that I want my project taken over and maintained. The immediate parallel that comes to mind is a Living Will. Here's my first cut at it:

If someone wants to take over this project, they should send email to me, the project administrator. If there is no response within one month, they should send email explaining the situation and asking for me to respond to the ruby-talk list. If there is no response from the project admin within one month I, the project administrator, direct the RubyForge administrators to add the requester to the project with full administrative privilege. If I do do not respond within a further month, the requester may then remove any administrative privileges for this project from my account.

After a bit of discussion around this idea, I plan on attaching a directive like this to all of my projects on RubyForge, and encourage everyone else to do the same. (Tom Copeland suggested that I put it in the Doc Manager of the project.)

I don't think this is just a problem (and solution) for the Ruby Community there are a lot of projects on Sourceforge, Savannah, etc. I'd love to hear comments from non-Rubyists too. I hope that given enough eyes and minds, we can come up with a standard directive (or maybe a couple of them) that can solve this problem.

Representing Ruby Objects

Just a note, this post is a work in progress, and should see updates about twice a week. Hopefully it's useful even while it's incomplete.

Representing Ruby Objects

To start with, it's probably worth describing a bit about how rubinius source is laid out, then we can dive into the specifics about Ruby objects.

The rubinius source tree is laid out like this (omitting stuff we're not interested in for now):

(trunk)
 kernel/
   core/
 lib/
   bytecode/
   cpu/
 shotgun/
   lib/

The kernel and lib directories contain the Ruby code required to implement any given object. The few things that can't be written in Ruby are written in C, and live in shotgun/lib. Having as much code as possible written in Ruby makes approaching rubinius very easy.

Internal Representation of Ruby Objects

The files we're most concerned with are:

• lib/object.rb
• shotgun/lib/object.h
• shotgun/lib/object.c