John Lam at Microsoft has released the first preview of IronRuby: a Ruby compiler that targets the .NET framework (licensed under the MS-Pl license, which is by all intents and purposes an open source license).
The source code is here. Seo Sanghyeon has already put together a kit to build and run it on Linux with Mono. There is one downside, you will need Mono from SVN, as you need the same fixes for Mono that were required to run IronPython 2.0 and Dynamic Language Runtime (DLR).
Congratulations to the DLR team at Microsoft for this release. They have also been working towards opening up the development process to external contributors:
We're also happy to announce that we will be accepting source code contributions into the IronRuby libraries. Right now we have a lot of logistical work that we still need to do, but we fully intend on getting IronRuby onto Rubyforge by the end of August.
Some of you may be wondering why we are only accepting contributions into the libraries and not the entire compiler. It's because IronRuby is built on top of the Dynamic Language Runtime (DLR), and the public interfaces to the DLR are not complete at this time. Since the DLR will ship as part of the CLR in the future, we cannot accept contributions into the IronRuby compiler, at least initially. However, once the DLR matures and reaches 1.0 status with fully supported public interfaces, we will fully open up all parts of the IronRuby project for external contributions.
It is worth noting that the future home of IronRuby wont be CodePlex but RubyForge, John said:
I (and I'll use I here since I fully take responsibility for this decision if it doesn't work) felt that more folks contributing to open source projects were comfortable with Subversion than with TFS. I wanted to make it as easy as possible for folks to contribute, so Rubyforge was the natural choice here.
Value Types and Null, the mistery continues
You will notice a patch in Seo's distribution. This patch is necessary because until today I had refused to implement this broken behavior of CSC 2.0 in Mono's C# compiler.
Today I finally gave up the resistance and implemented it in version 82517. But I must point out that so far there is no good explanation as to why this broken behavior is present in CSC in the first place. A few months ago I posted the question on this blog and we had a lively discussion but never found a satisfactory answer to this behavior.