With the great work that the rubiniius hackers in Portland, Oregon have been doing I thought I'd better sit down with them and find out more. Given their plans, we may see a few installments of this side interview.
I think you might be the first .rbc (rubinius coders) group around. I'm jealous. How and why did you guys start this up?
Thomas: I'm not really sure who got the idea rolling, but Aaron happened to mention an interest in rubinius at our last PDX.rb meeting (I missed the beginning of the meeting, so this probably had come up earlier). I expressed similar interest and he suggested getting together to hack on it. I don't know if the discussion with Phil and Brian happened before or after our conversation, but I was sure that it was the right approach to get the ball rolling. Trying to tackle a new project like rubinius is a bit intimidating, but when you have someone else sitting there to bounce things off of, it makes it a little less so.
Phil: I have been interested in Rubinius for a couple of months now, but it seemed to be moving so fast that it was difficult to get a hold on what was going on. When Aaron and I found out that Brian was involved in rubinius development it seemed like a great opportunity to for him to be our 'guide' to rubinius. It's great to be able to ask questions about the history of the code or why something was done. There's not a huge amount of documentation in Rubinius yet (hopefully that's changing) so it's tough to jump in and start contributing without someone to help explain how things are organized and why they are that way.
Brian: From my view, it was rather impromptu. When I attended the 2/6 pdx.rb meeting, I wasn't prepared to or planning on saying anything about Rubinius. Aaron and Phil piped up and I thought I'd throw my 2 cents in. I didn't think I had that much to contribute. Later in stroll over to LuckyLab (a nearby bar) Phil suggested getting together. Aaron posted an event to the pdxruby.org site and we met. Of course, I was thrilled to see some local interest, so I came prepared with a whole list of things we could work on. :) Irb seemed like a good place to start. If I have 2 tabs open in iTerm, one is probably IRSSI and the other is surely irb.
Aaron: I asked at the monthly pdx.rb gathering if anyone was interested in working together to contribute to rubinius. Both Phil Tomson, Brian Ford and myself had already signed up for commit rights. It quickly became apparent that Brian was up to speed on the activity in the irc channel and commit logs.
I really enjoyed meeting the guys up in Seattle a few years ago and have always hoped to be able to contribute to their on going projects. I like building groups that help each other, instead of rivalries.
I also feel more comfortable meeting in person to ask questions. Old habit, I suppose.
You picked irb as your first project, and it looks like you've got a simple working version out already. Tell us about it. How much work did you need to do on rubinius to get it working?
Brian: Unfortunately, I was probably a roadblock to getting sirb going during our meetup. I failed to grasp that we would have a persistent machine that would contain the state ( e.g. the state from previously evaluated expressions). Later last weekend, after thinking that an irb transcript would just be a program, and remembering that in Prototype B (the MRI-based VM Evan had prototyped) there was a Machine class, I looked for the analogue in shotgun (Prototype S, the C VM). From there, it wasn't a whole lot of work. Again, unfortunately, this was after our meetup so no one was around to share the excitement, except on IRC.
Aaron: We located the Readline.readline stub in kernel/core/readline.rb and replaced
""
print prompt
STDIN.read(1024)
When we added Compile.execute(str) to the loop in apps/irb/sirb.rb Phil pointed out that this had no context which is something I had always taken for granted. So we then started looking at stdlib/irb.rb with ./shotgun/rubinius stdlib/irb.rb and examining the backtrace.
This lead into a tour that covered rspec, mri, target host, and what was left to do before rspec could run natively on rubinius and the convolutedness to run it until then.
Thomas: Well, honestly, what we did when we met bears little resemblance to what is out there now. We used it as a gateway mostly to try and understand how the compiler functioned (irb, or sirb, in this case, is perfect for this -- it has to invoke the compiler on small chunks of code as user inputs them). What Brian later committed was quite a bit more complete than what we had put together, but I guess the kernel of that got started in our initial attempt.
zenspider and Eric up in the Seattle.rb are big believers in using forcing functions to make their code better. How is (or isn't) sirb a forcing function for rubinius? What other projects are you going to work on that might be forcing functions for rubinius?
Thomas: Mostly sirb just sounded like a good first start -- we're all heavy users of irb in our normal ruby development. In fact, when I first started looking at rubinius, I looked for its irb implementation.
I think that mostly we'll just be looking for good bite-sized chunks of missing functionality, documentation or whatever that we can tackle in a single afternoon. Of course, one would hope that over time this leads to each of us being able to contribute even more on our own.
Aaron: Forcing functions are new concept for me. My driving force is to find something that can be done within a few hours and committed. The feeling of accomplishment is the biggest piece. I need to find out more about identifying forcing functions.
Brian: Well, I had to head over to Wikipedia to look up forcing function. :) I remember the use from my Diff Eq math class. I see sirb as both an extremely useful tool to have while developing code for Rubinius, as well as great way to expose how Rubinius works, You can, for instance, pass command line arguments that cause sirb to print the s-expression or assembly, etc. for every expression it evaluates. This could help people get a handle on what's happening during the compilation phase. The direct access to this should enable people to make quicker progress when working on Rubinius.
rubinius isn't the only thing you guys are working on, I also hear you're learning OCaml. How is that meshing with the Ruby, Garnet, and C work you're doing for rubinius?
Aaron: Learning other languages has always taught me more about ones I already know.
Thomas: This was our first meeting, so that remains to be seen. I didn't even realize that Aaron, Brian and Phil had talked about OCaml, but oddly enough, it's the functional language I've been most interested in studying for some time now. It remains to be seen how this will fit with the rubinius work, but I think at the least it shows a common interest in learning something new.
Phil: I'd like to add that I've been wanting to learn a functional programming language for a while now. After finding a presentation on the web (something like "The one day compiler") where someone had posted slides about how they created a make-like tool using OCaml I was impressed with the capabilities of OCaml and decided that I wanted to learn it. I also started seeing some ads show up in gmail about OCaml jobs in the financial industry, so that told me that people are starting to get paid (and apparently well paid) to code in OCaml. The fact that OCaml also supports OO programming was also a draw (I don't think that Haskell does?)
Brian: I think the consensus was that we'd focus on Rubinius, since adding OCaml to the mix could be distracting with the limited time we have available. However, hopefully we'll still entertain the idea of getting together to learn OCaml. I plan on using it in my current game theory math class to implement the finite state automata we're using to model repeated games, and compare that to a Ruby implementation.
This bi-week's sponsor is Ruby for Rails
If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:
- Episode 1, in which Charles, Thomas, and Ola talk about their plans for JRuby.
- Episode 2, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team and YARV.
- Episode 3, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team Rails and (more about) YARV.
- Episode 4, in which Charles, Thomas, Ola, and Tor Norbye talk about JRuby and NetBeans.
- Episode 5, in which Charles, Thomas, and Ola talk about groovy.
Hey Pat, thanks for the opportunity to talk about this. We've only met once, but it's already got me excited and thinking about rubinius constantly. Let's hope the day job doesn't suffer. ;~)
ReplyDelete