Method Group Conversions

Today I implemented the Method Group Conversions finally, after getting some clarity of mind. The patch was relatively short, mostly shuffling existing code around. So it is now possible to write:

	Button b = new Button ("Hello");
	b.Clicked += handle_click;
	...

	void handle_click (object o, EventArgs e)
	{
	}

Specially interesting to Gtk# developers, since the plan is to move the delegate signatures from the GtkSharp namespace into the class that defines the delegate, so people will be saved from writing:

	// What they would have to write:
	b.SizeAllocated += new Widget.SizeAllocatedHandler (handler);

	// What they can write:
	b.SizeAllocated += handler;

	void handler (object o, SizeAllocatedArgs args)
	{
	}

I talked to Martin today for a while about the debugger. It is finally back in shape: it can debug managed an unmanaged, so people can use it to debug the JIT. The bad news is that it requires an NPTL threading system, which is only available on Red Hat 9 or with 2.6 kernel installations.

One of the limitations of the debugger is its current command line language is yacc-based and grew organically. It is not really great for interactive work.

I have been pondering what to do about this: an option was to use JScript, but its not ready. Another was to use something like IronPython, but that is also far away, and another is to roll-a-tiny-command-line-system.

Am leaning towards rolling our own command line language, my struggle is between a few models:

TCL model

Extrapolate variables first, then parse into strings, implement statements as commands. Ultra simple.

The shell model

extrapolate variables first, perform language parsing, use ; and \n as separators parse chunks as string vectors; use reserved keywords. More complex

The Perl model

The parser drives the process, extrapolation happens at the language level, and is not a input hack. Use semicolons to delimit-statements, and braces for grouping. Not clear if the interactivity will feel right

Each model has its beauty, and it is hard to make a decision. Will roll the dice next week.

On top of that, I want the command line processor to perform some parsing for us, so we can type:

	(mdb) b -thread 4 Main

In C#, the "break" command would be implemented like this:

	class Break : Command {
		[Argument] public int thread { get {} set {} }

		public Break (string [] args)
		{
		}
	}

So the thread property would be set to "4", and the Break command would receive { "Main" } as an argument.

Mono and MacOS X

I installed Mono on MacOS X. This is the first time that I use a Mac for doing development. A few impressions: The Mac UI is incredibly pretty, am glad the Gnome folks are using this as a model to follow. After using the Mac, Longhorn and XP feel cheesy, and Gnome feels rather professional, but not as complete.

Now, the big downside of the MacOS is their kernel. This is on a machine that is faster than my laptop, and still takes three times as much to build the Mono C sources.

The problem can be tracked down to their Mach kernel. In a way its good, because it makes us look much better for server and heavy duty use. On the other hand, if they did not have Avi from the Mach team running their decisions, that kernel would have been long gone and Linux or FreeBSD kernel would be used instead.

A few years ago, I looked into implementing the Mach-O file format, its a primitive beast, it should not be hard to implement that and implement the few things in Linux that MacOS needs to get their UI tools running on a decent kernel.

The new alpha GC from Hans Boehm works on MacOS with Mono, which addresses one of the big problems people had. Mono-wise: there are a few JIT failures with OS 10.3 though while things work on 10.2.

To assist in the debugging, I started learning about the PowerPC architecture. So far I have only seen two nice things about its design (the conditional register files, and the summary overflow bit,) but the choice of opcode names is the worst I have ever seen. Psychologically it has the effect of making me think `This instruction set sucks'. I might be wrong, it might be just a perception thing, but having used the SPARC and the MIPS in the past, which are pretty beautiful designs, you are left wondering about chips designed outside of universities.

Other updates

Jordi Mas is joining the Mono team on Monday. He will be working on GDI+ and System.Drawing, that will be a good first task for him. In the meantime, Peter Bartok is taking over the gargantuan effort to make Wine-current work as a library, and make it use Cairo in the X11 backend to solve the fight we had between those two.

Lluis has checked-in th esupport to th eweb srevice page to render a sample seesion of what a request to the webserver looks like. Gonzalo got the FileSystemWatcher interface implemented on Windows and Linux (using FAM, and falling back to polling) which is pretty cool and Jackson has been working in our tracing support for ASP.NET, all very nice, new toys for the weekend.