Slow and Steady - mono

My Novell Hack Week project: Implement support for Mono in Automake

nospam@example.com (Raja R Harinath) — Mon, 02 Jul 2007 06:33:30 +0000

This week was hack week for all the Open Source hackers at Novell, where we got to work on ideas and projects that we were personally interested in. I decided to work on something that I've been planning for a long time, ever since I joined the Mono project, in fact: add support for Mono in Automake.

It has been a while since I hacked on the automake source tree, but I didn't have too much trouble getting started. In the end, I got most of the features I intended for it:

support for building Mono exes and dlls

support for installing them in the GAC

support out-of-tree builds

dependency tracking on sources

support for specifying resources, and tracking dependencies on them

support for specifying references, and tracking dependencies on them

support for multiple languages, include C#, VB.NET, Nemerle, Boo

easy extensibility of the support to other languages -- essentially, just need to add the filename extension of the language to SUFFIXES

bundled autoconf macro to detect installed compilers and other tools

... and some examples, test cases, and documentation to explain how to use all of it

Stuff missing include

autoconf macros to detect if libraries are installed or not

support for Microsoft's compilers -- basically a question of replacing '/' with '\' in filenames, where appropriate

support for response files -- mainly wrt distributing sources mentioned in them

real life experience with actual projects using all the above features

The whole effort took up most of the five days. I spent much of Monday checking out the code from CVS into git and looking at how support for C and other languages was implemented. I had most of the basic support done by Tuesday, got all dependency tracking working by Wednesday, and added documentation, autoconf support, and GAC-installation support by Friday afternoon. I'm very happy that I spent the time upfront to import the project into git, since it saved me from spending a lot of timeslices tracking my changes.

The code is available as a series of patches to Automake (packed conveniently in a tarball), and there's also an example project that shows how to use it. I also have a "lightning talk" short video about the project.

As much as I enjoyed the coding, I also thoroughly enjoyed working with the whole Bangalore open source team, all in the same conference room for five days, with everyone having a good time, and good food.

More thoughts about MCS and GMCS

nospam@example.com (Raja R Harinath) — Thu, 16 Feb 2006 15:53:00 +0000

Martin got GMCS to work on Windows, with a small caveat -- there's no API to change the MethodAttributes of a MethodBuilder. I have a couple of observations:

the caveat isn't really a big deal. You only need to set NewSlot when there is a new keyword used in the declaration. Otherwise, it's useful but not necessary (See bug 74852 for the gory details)

these changes, coupled with my older changes should allow us to have more code similarity between MCS and GMCS. Specifically, I think we can put in a couple of stubs: DropGenericTypeArguments and DropGenericMethodArguments into MCS and eliminate a big part of the textual differences between MCS and GMCS in non-generics related code. We already started on this in doc.cs

MCS: Implemented ::-lookup (qualified alias member) feature

nospam@example.com (Raja R Harinath) — Wed, 03 Aug 2005 08:26:00 +0000

Today, I added my first "tick-mark" feature to Mono's C# compiler: qualified-alias-member or '::' lookup. It's a relatively small feature, and doesn't impact much, code-wise.

In all, it took about a day's worth of effort from start to check-in. But, that one-day effort needed quite some preparatory work. I'd pretty much decided on the approach a couple of months ago, and had a reasonable plan-of-attack, and was looking for an opportune time to work on it. More importantly, the past few months I spent incessantly refactoring the name- and type-lookup facilities in the compiler has paid off, making the task of implementing '::' trivial.

Thread-safety and me

nospam@example.com (Raja R Harinath) — Sat, 25 Jun 2005 02:14:00 +0000

I'm thinking of working on fixing Mono's Dictionary to be thread-safe.

It seems ironic: I wrote a large part of that Wiki page, and I'm in large part responsible for the dictionary code not being thread-safe. "Blame" me for the use of the move-to-front heurstic in the dictionary code, and I must say, it was a beautiful piece of code: see how simple it made the 'Remove()' code.

Of course I've disliked threads all along, and this gives me more reasons to blame threads for the ugliness they bring into the world.