Here's the first episode of the serial rubinius interview since we've gone to our new bi-weekly format. There's some good stuff in here about a roadmap, the new fastmethodcontext work Evan's been doing, and user contributions. Before we get to that, there's some great news in the rubinius community that I'd like to pass along.
One thing that I'm incredibly happy to hear about is a Portland, OR group that's meeting regularily to hack on rubinius (and learn OCaml — an odd combination). They've already turned out a simple, but working, irb. I'm in the middle of an interview with them that should be posted in the next day or so.
Another idea that has come up on the irc channel is an aggregator for rubinius blog feeds. There are a number of bloggers there: Evan, Wilson, Brian, mae (Matt Elder), and rue among them.
There's been some discussion about a rubinius roadmap on the irc channel. What are the odds we're going to see something like that? What's going to be on it?
Brian: Evan is definitely the one to set the roadmap. And I think it's important that he does it fairly soon so that we can focus on getting the essential features done for 1.0. This has become something of an issue recently as different people see Rubinius as a playground for ideas. While all the contributions are (mostly?) heartily appreciated, too little shared vision means too many separate directions. That's just plain tough with any project.
While I'm certainly not setting any roadmap, I'm all in for helping document it and explain it. I'm also continually pestering Evan to co-author a book. No one has announced anything about it, but Evan, Wilson, and I have talked about doing this together. I'll leave it up to Evan to decide if he wants to publicly confirm that.
The reason I think a book at this stage would be great is because it would get written while Rubinius development is occurring and will hopefully get a lot of folks interested. I think the AWDWR was a huge help in getting people knee-deep in Rails quickly, and doing things mostly right from the beginning.
Wilson: Compatibility with other Ruby implementations is one important item that we need to publicize. For newcomers to the project, knowing which behaviors are bugs, and which are deliberate differences that need a 'compatibility mode' added can be a challenge. Obviously a roadmap isn't a spec, but I think even a little treatment of this could help people get started.
Brian: I think compatibility is extremely important. Until now, what did we have to worry about? Just whether MRI was available on the platform. Now, with all these Ruby implementations, we have to consider it. The issue it, what is our reference for evaluating compatibility? What does 'compatibility' really mean. So far, I've seen people grabbing ideas of compatibility from other language domains and some of those aren't appropriate. Consider the recent concern that Rubinius having Tuple as a core class will encourage, or at least result in, some programmer coding in a dependency on Tuple. If that program is run on MRI without a compatibility class, it will fail. For me, that is more similar to a logic error in a program than an compatibility issue. It is also important to note that with rare exception, we are not changing the behavior of any core MRI class. Anyway, my main point is that we have some defining to do regarding compatibility. In Ruby, classes, methods, etc. can come and go at any time and duck-typing is the name of the game. So I think our idea of compatibility has to be defined similar to how we deal with 'types' and duck-typing.
Evan: A roadmap is absolutely necessary, because it sets the tone for 1.0 release. As for timeframe, I'm trying to finish up the patch to add FastMethodContext and a bunch of other speed related fixes. Once that's done, I'm going to do the first parts of the roadmap. I'll be on vacation for a week starting the 13th, so my plan is to return from the trip having done parts of the roadmap.
As for the contents of the roadmap, I plan to layout features and new classes to be implemented for 1.0. The list will include threading (Scheduler, Thread, NativeThread), additional hooks, and much more.
Evan, rue has been talking about the impending release of the new fastmethodcontext too. What can you tell us about this? How much of a performance impact will it have?
Evan: FastMethodContext increases the performance of the VM by simplifying the creation of stack objects, used to store information about method calls. Something like 85% of all objects created in the system are just stack objects, so making them faster helps speed up everything else. Due to the amount of time the system spends just creating, maintaining, and recycling these objects, improvement them vastly changes performance.
Back at the beginning of this serial interview, I asked you what contributions had surprised you the most. Now that we're a couple of months (and 500 or so SVN commits) further along, it's time to rephrase the question. What have been the most impactful contributions so far.
Brian: Hmm, good question. I think one significant thing is how much of the core lib is now passing specs. We have nearly 1,000 specs covering the essential classes like NilClass, TrueClass, FalseClass, Fixnum, Bignum, Float, Array, String, Regexp. Just a couple of days ago, out of 132 String specs, over 80 were failing. We're down to 50 or less. Most of the Float, Fixnum, and Bignum, Regexp, and Array specs now pass. This has been due to great contributions from a bunch of folks, so I'd say, the most impactful lately has been the contributions of a whole group of people. :) Nothing like getting collaboration going. If I were to single anyone out for special mention, I'd probably say Alan Hurdle (hurdlea). He pretty much single-handedly whipped Regexp into shape. There were some essential methods before, but now it's nearly complete.
Evan:I agree. Alan Hurdle has really kicked ass on many fronts. He's really shown how much the project lets people dive right in and make a big difference. My hope is that with more documentation and roadmaps, the interpreter will be as accessible as the ruby-basedruntime has proven to be.
Wilson: Several weeks ago, I wasted some time complaining about the Numeric API in Ruby. 'coerced_from', 'prec_f', etc.. there are tons of methods that are never used directly in user code; at least, no code I've ever seen. People came along shortly after that and implemented what looks like the whole set of them. That greatly improved the Rubinius feature set, and helped me understand why Ruby does it that way in the first place. Awesome.
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.
3 comments:
Pat, a small correction (from one of the Portland group you mention): yes, we did get a basic irb implementation working. Strictly speaking, that is true, but what we hacked on (it was mostly Brian, actually) holds very little resemblance to what Brian checked in a couple days later. It's a minor thing, but I'd hate for us to get credit as a group for Brian's work.
Thanks for the update Thomas. I still think you guys rock for getting this started, and am looking forward to seeing what you do next.
Congrats on the great progress that Rubinius hackers have made. Very nice!
Pat, do you think you can squeeze in an interview or two from ko1 on the status of the Ruby VM?
Post a Comment