Antonio Cangiano's latest series of Ruby benchmarks showed that IronRuby performs much better than Ruby 1.8.6. Luis Lavena commented that Antonio is "comparing IronRuby performance with a 12 years old compiler (VC6) which is the one used by official One-Click Installer". Luis is working on a replacement for the One-Click Installer, which would have performed much better, as a second round of benchmarks showed.
InfoQ talked to Luis Lavena to learn more on this, apparently urgently needed, new Windows installer for Ruby 1.8.6 and 1.9.
Although very useful for the Ruby community, there must be more exciting things to do than writing an installer?
Yes, indeed there are more funny things to do than building and rebuilding Ruby and it's dependencies until you get it right. The motivation behind it was always to scratch my own itch.
Personally, I've used Ruby on Windows as glue and scripting for my development dealing with C, C++ and even Assembler, Ruby helped me stay on focus and automate several tasks.
I thought it was valuable to share my knowledge and experience gained over the years with the community, which was very receptive and open.
How does this new installer differ from the old one?
The new installer focuses on getting Ruby right, and get it to integrate more properly and easily on Windows.
The second big point of it is to lower the barrier between Linux and Windows users with regards to the tools available. Most of the Windows users that lack the knowledge to build stuff on Windows need to wait for gem authors or other contributors to release native gems for them.
It became a huge deal since the way Ruby builds extensions and how it integrates with the compiler forced the usage of a 12 years old compiler (Visual C 6.0). That compiler not being available on the net made things more difficult to maintain.
This new installer, instead of being based on binary releases provided by some Ruby-core developers, builds completely from scratch, that gave us the opportunity to further tweak configuration options, versions of extensions bundled, etc.
Not only that, but we substituted certain dependencies like GNU Readline with a pure-ruby version called rb-readline.
Aiming to accelerate release cycles, this new installer does not include 3rd party libraries, which consume a huge amount of time to verify and maintain into the installers.
Users are going to get a minimal installer that includes Ruby, RubyGems and documentation, and from there they will be able to install needed gems without to worry about bloated downloads.
Why is creating a new installer such a big deal, can't you just recompile Ruby and be done with it?
While may sound simple, is not just packaging Ruby and shipping it.
Ruby depends on several packages like ZLib, OpenSSL, Readline and many others that require external libraries. Some of those externals libraries are hard to find pre-compiled for Windows.
When those binaries are not present, we need to fall back and build ourselves. One example is that we use a not-so-old version of OpenSSL since they lack up to date binaries and building from source is a very complex task.
Sometimes it is more than just Ruby but the whole ecosystem around it that needs to be updated and tweaked.
If we have a new Ruby binary for Windows, what does this mean for Gems with native extensions? Can I use Gems with native extensions built for the 'old' Ruby use with RubyInstaller's version?
While you can do it, sometimes forcing a gem to work on this version of Ruby would not work. This is one of the reasons RubyInstaller has been in development for the past year.
For those who are familiar with C, the language Ruby is written in, they will know that when compiling C programs they link to a library called CRT for C Runtime library, that offers several low level services like memory allocation, string processing, IO, etc.
Both GCC and VC6 target and link against the same CRT (MSVCRT.DLL) (see Luis' blog for more information).
That solves one piece of the problem. The other part is Ruby code.
Now, when compiling Ruby, it stores inside and in some configuration files the compiler and flags used to built it, so when building with VC6, it defines the RUBY_PLATFORM as "mswin32", and when used GCC it defines it as "mingw32"
In theory, both are binary compatible, but now is up to the Ruby code for some libraries how is going to interact with that.
Some developers include platform specific code in their libraries, and to determine if the library is working on Windows, they check RUBY_PLATFORM and look for "mswin", "mswin32" or sometimes "win"
Being "mingw32" part of RUBY_PLATFORM, those libraries are going to think you're running on Linux, and thus, fail.
So now is the time to get those developers fix those bad habits.
I've been suggesting usage of RUBY_PLATFORM =~ /mingw|mswin/ to guard Windows code.
Do you have a date for the first release in mind?
The main goals as today has been reached:
- Get Ruby 1.8.6 and 1.9.1 building in automated fashion
- Be able to bundle those into installers
- Simplify the development using a Development Kit package available to users.
- Make it easier for gem authors to ship tools for Windows users, using rake-compiler.
I've outlined a few tasks in the project TODO. I'm going to rearrange it and better reflect all that in the RubyInstaller Wiki.
Once we complete the documentation and most of the Installer tasks, I believe we are going to be in position to release the first stable version.
More information on the Ruby Installer and the recent preview 1 release can be found on Luis' Blog. The Ruby Installer repository is located on GitHub.
