Well, lot of things happened in the past weeks. Work on getting One-Click RubyInstaller with MinGW out of the door, RubySpecs and of lot of satisfaction.

Please keep reading for the good part of this post…

We are not alone, and we have clear goals!

I can no longer say I’m the only insane one working with Ruby on Windows ;-)
Jokes apart, please welcome Gordon Thiesfeld who noticed a few important glitches of MRI (more on that later). He also did some work in the wiki to
reflect our status and Roadmap. Thank you Gordon!

Right now we have small but clear goals, we will keep focused on those.

A community more interested in support Ruby on Windows

Following the butterfly effect of RubyInside post, a few projects shown interest about adding support—or at least—play nice with Windows.

Thanks goes to Sam Smoot, David Leal, Dan Kubb and Martin Kihlgren (sorry, couldn’t find a good link to add).

The good news is that DataObjects (DO), the low level layer that powers the ORM DataMapper soon will be available for Windows (as for their 0.9.0 release).

In other news, Jeff Davis from ruby-pg followed our Integration Request idea and filled in so we can work together making development and release of binaries for Ruby PostgreSQL work for all of us.

These projects give us the opportunity to play with Git on Windows, so a discussion was raised in the mailing list to determine our DVCS for RubyInstaller.

Less quirks for us.

Vista

David Leal was having some issues getting the Sandbox working under Vista. Turns out it was Not Our Fault™, but some glitches of the changes introduced in Vista and MinGW.

John E. from MinGW project released an update and we updated the recipes to use these files instead.

system(‘gem’) vs system(‘gem.bat’)

Was annoying needed to patch every Rakefile or Ruby script that called gem or rake or any other tool installed via RubyGems. Turns out that wasn’t a Windows fault, but some faulty logic in the Windows version of Ruby when dealing with system() calls.

Thanks to Nobuyoshi Nakada, 1.8 branch includes this fix, which solves a few things we discussed on rubyinstaller-devel mailing list to ease the need of tweaking the environment for MinGW.

Rubinius, RubySpecs, and speed.

After the huge quantity of problems 1.8.7 preview release introduced for MinGW build of Ruby. I decided will be good get RubySpecs (part of Rubinius project) working on MRI on Windows.

Thanks to Brian Ford (brixen), he introduced a few changes into MSpec (the RSpec-like tool used in Rubinius) that now let us focus on the specs of Ruby.

Since I wanted to avoid break the great rubinius 0/0 reports, I setup coLinux running Ubuntu and installed Ruby to have 4 environments to test everything under the same machine:

  • MRI 1.8.6-p114 (i386-mswin32) (Windows with VC6)
  • MRI 1.8.6-p114 (i386-mingw32) (Windows with GCC 3.4.5)
  • MRI 1.8.6-p144 (i686-linux) (Linux with GCC 4.1.2)
  • RBX 1.8.6 compatible (i686-pc-linux-gnu) (Rubinius, Linux with GCC 4.1.2)

Wow, lot of configurations, don’t you think? :-P

Just for sake of testing, now that I’m on it, used the old sudoku solver to evaluate how fast these interpreters will go1:

*Interpreter* *Average (secs.)* *Speedup*
i386-mswin32 13.112 1 (reference)
i386-mingw32 8.875 1.48
i686-linux 8.808 1.49
i686-pc-linux-gnu 7.218 1.82

Nice, keeping in consideration that both MRI and Rubinius are running inside coLinux, which is Linux on top of Windows kernel.

Also is nice to see Rubinius got better: from 88 seconds to current results [2].

1 Look at this pastie for the raw numbers.

2 Previous results here