Antonio Cangiano has provided a fascinating glimpse into the current state of the many VM implementations of Ruby. He has run a sizable set of benchmarks against seven different Ruby implementations:

• Ruby 1.8.5 on Linux
• Ruby 1.8.5 on Windows
• Ruby 1.9 (Yarv/Rite) on Linux
• JRuby on Linux
• Gardens Point Ruby.NET on Windows
• Rubinius on Linux
• Cardinal on Linux

The graph above shows the averages and median scores, but the details are just as interesting. I also completely agree with Antonio’s caveats:

• Don’t read too much into this and don’t draw any final conclusions. Each of these exciting projects have their own reason for being, as well as different pros and cons, which are not considered in this post. They each have a different level of stability and completeness. Furthermore, some of them haven’t been optimized for speed yet. Take this post for what it is: an interesting experiment;
• The results may entirely change in the next 3, 6, 12 months… I’ll be back!
• The scope of the benchmarks is limited because they can’t stress every single feature of each implementation. It’s just a sensible set of benchmarks that give us a general idea of where we are in terms of speed;
• These tests were run on my machine, your mileage may vary;

This year’s first regional Ruby conference, the MountainWest RubyConf will be held March 16th and 17th in Salt Lake City, UT. It is accepting registrations until Feb 23rd. While it might be small in its geographical reach, it looks like a very big conference in almost every other way.

In your views

  def _time_entry_form(entry)
    _form_for(entry,R(AddTimeEntry))
  end

  def _form_for(record,handler,options={})
   attributes = record.attribute_names
   if options[:only]
     attributes = options[:only]
   elsif options[:omit]
     attributes -= options[:omit]
   end
   attributes -= ["id"]
   form :action => handler, :method => 'post' do
      attributes.each do |e|
        p do
          label "#{e}: ", :for => e
          input :type => 'text', :name => e, :value => record.send(e)
        end
      end
      input :type => 'submit', :value => "Submit"
    end
  end

In your controllers

  class AddClient < R '/client/new'

    def get
      @client = Client.new
      render :add_client
    end

    def post
      Models::Client.create(input)
      redirect ShowClients
    end

  end

Oh ye gods of camping.. what do you think?

I’m pleased to announce a new Ruby Users Group for folks north of San Francisco (or who like to go to Sebastopol, CA): the North Bay Ruby Users Group.

Our first meeting is this week; February 15th, 2007 at 7:00pm. O’Reilly has graciously offered us a place to meet, so we’ll be holding the meetings at O’Reilly HQ in Sebastopol, CA (directions).

Meetings are on the third Thursday of each month. If you’re interested in learning more, please sign up for the mailing list.

Our first meeting will feature Keith Fahlgren and myself, kicking things off by discussing how O’Reilly uses Ruby to make good things happen.

Please RSVP on the mailing list so we know how much pizza to buy. We hope to see you there!

IntelliJ has posted a screencast demo of their Ruby plugin. It looks really nice! Even better… in the screencast they’re using my open source project, Instant Rails, to supply their instance of Ruby — cool!

Professors John Gough and Wayne Kelly at Queensland University of Technology in Brisbane, Australia, just announced the second release of their Ruby.NET compiler that statically compiles Ruby programs for the .NET CLR. Ruby is such a dynamic language that it hard for me to understand how they can even do this (an eWeek.com article last summer discussed some of the unique challenges).

The big news is that it successfully runs all 871 in Ruby’s installation test suite (in samples/test.rb). Their next goal is to get Ruby on Rails running:

We have just started work on getting Ruby on Rails to run on Ruby.NET and have started work on adding interoperability features to allow .NET programs written in other languages to conveniently use Ruby components and vice versa. We hope to include some of these features in the next public release.

Our plan now is to perform public releases more frequently, approximately once a month. Once we have stabalized the major design choices (including those required for interop) we will move to a more traditional open source type model where others can contribute directly to the code base. We expect this to happen in the second half of this year.