John Lam of Microsoft released IronRuby this July 23rd. IronRuby is destined to enable the use of Ruby with .Net to build Windows applications. It targets the Dynamic Language Runtime, which Microsoft plans for IronRuby, IronPython and VBx, a dynamic version of Visual Basic. This post is a tutorial for hacking IronRuby.
In this tutorial I’ll show:
A few months ago, I emailed John about the possibility of using his RubyCLR, the precursor to IronRuby, to integrate with open-source IDEs. John was quite open to the idea. This new project renews my interest as already, IronPython has been integrated within the Visual Studio environment, and it would be great to tackle the VS integration of IronRuby in the future.
I checked out the source code to IronRuby in its really early pre-Alpha stage (so you should expect incompleteness and bugs). Antonio Cangiano wrote a long post about this, but this first release is under Microsoft’s Permissive License, so that anyone can look at the code and modify it.
1. Building IronRuby
1. Make sure you have the IronRuby source code and that you have extracted it, and also the .Net framework installed.
2. Because of a bug in Microsoft’s .Net framework installation, paths to the framework or the corresponding system environment variables are not set correctly. Check the path to your latest version of .Net framework by looking in the Windows\Microsoft.Net directory.
Mine is: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
3. In IronRuby’s installed directory, edit Build.cmd and replace
%frameworkdir%\%frameworkversion% by your full path to your .Net framework dir.
4. Save Build.cmd.
Mine contains
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\msbuild.exe /p:Configuration=Release /t:Rebuild IronRuby.sln
5. Launch Build.cmd from the command line.
IronRuby should now build successfully.
2. Testing IronRuby
1. Launch rbx.exe in the Bin\Release subdirectory and try a simple Ruby command like 3+5 or puts ‘Hello!’
2. A simple .Net interop test:
require 'System.Windows.Forms'
f=System::Windows::Forms
f::MessageBox.show "Hello from .Net!"
3. A string test which fails:
Here, we can see that string concatenation unfortunately modifies the first argument. We’ll see how to fix this in IronRuby’s source code in a short while, but first we’ll set up a nice Visual environment to code in.
3. Setting up Visual C# Express 2005 to hack IronRuby
1. Download Visual C# Express 2005 and install it. Do register the software.
2. Load the IronRuby solution file, IronRuby.sln, in the Visual C# Express 2005 IDE.
3. You can then build IronRuby straight from the IDE and also modify it which we will now see by going through fixing the bug encountered above.
4. Hacking IronRuby to fix the string addition operation bug
After grasping the overall source-code structure, I narrowed down the bug to the Ruby\Builtins\MutableStrings.cs file and the Concatenate(MutableString self, MutableString other) implementation of RubyMethodAttribute “+”:
[RubyMethodAttribute("+", RubyMethodAttributes.PublicInstance)]
public static MutableString Concatenate(MutableString self, MutableString other) {
return self.Append(other);
}
self.Append(other) was obviously effecting the concatenation but modifying self (as that’s what Append should do) and returning the result.
To fix this in C#, I needed to instantiate a new temporary MutableString object to which I could in turn append self and other and return this instead:
MutableString result = new MutableString();
return result.Append(self).Append(other);
Once you’ve modified an existing IronRuby implementation, you can Build the solution within the Visual C# IDE (F6).
After a successful build, you can browse to the IronRuby Bin\Debug directory (or Bin\Release if you set it up this way within Visual C#) and check whether rbx.exe is recently timestamped.
Just double-click on rbx.exe to launch it and to check the bug fix:
Don’t forget to exit the debug version of rbx if you’re doing other modifications or you won’t be able to build it.
5. Extending IronRuby with new Ruby methods implementations using Visual C#
Here, we’ll be adding a new Ruby method implementation to the Ruby Builtins classes, so a simple Build of the code would not work, as there is intermediate C# code which has to be generated automatically thanks to a small program named ClassInitGenerator.
There’s a bad path setting in one of the files we’ll need, so we have to fix this first:
1. Browse to the Src\Ruby\Builtins directory
2. Right-click the GenerateInitializers.cmd file and select Properties.
3. Uncheck the Read-Only attribute and click Apply, then OK.
4. Right-click the same file again and select Edit.
5. Remove the initial ‘..\’
Your new file should contain:
..\..\..\Bin\Debug\ClassInitGenerator > Initializer.Generated.cs
6. Save the file.
As Antonio Cangiano of IBM Toronto’s Software Labs and others rightly pointed out, a simple float division will throw IronRuby astray:
That’s because the Ruby “/” method for floats within the Builtins\FloatOps.cs file is not implemented yet.
Here’s my simple code for the IronRuby implementation of the Ruby “/” operation:
[RubyMethodAttribute("/", RubyMethodAttributes.PublicInstance)]
public static double Divide(double self, double other)
{
return (self / other);
}
Here are the steps to recreate an extended IronRuby with the IDE:
1. Save the FloatOps.cs file (or the project)
2. Right-click ClassInitGenerator in the solution tree-view and select Build
3. Browse to Src\Ruby\Builtins and launch GenerateInitializers.cmd. A new Initializer.Generated.cs file will be generated. If the Visual C# IDE asks for it to be reloaded, click “Yes”.
4. Select the Solution and Build it (F6)
5. Browse to the \Bin\Debug directory and launch rbx.exe to test it:
You can now hack away at IronRuby with the Visual C# IDE. Microsoft will be accepting outside contributions to the source code which is expected to be on RubyForge by the end of August.
Other interesting posts about IronRuby:
Additional thoughts
This is a great milestone achieved by John and the team and I would love to see Ruby used to produce full-fledged Windows apps. Given Microsoft’s horrendous track record at supporting standards, and habit of ‘extending’ technologies to extinguish them later on, I want to see where this will go and I am also watching Microsoft’s sudden embracing of the terms ‘Open Source’.
However, for successful people and teams, history is not a perfect image of the future as they can transcend that.
John’s work on RubyCLR previously and IronRuby for the DLR today is testament to his great hacking skills and success at integrating Ruby and the .Net framework.
Well done, John.
