My excuse for being there for almost a week was the ECMA meeting for the CLI and C#. As Brad pointed out, there are now two public mailing lists for providing feedback and discussing the ongoing work of the ECMA CLI and C# standard efforts, you can subscribe to them by going here for C# and here for CLI

During the meeting there was a set of "interesting" proposals to the C# language, and I have come up with my own, watch this space for them.

After the ECMA meetings were over during the day, I would run to the beach and do some all-amateur snorkeling action: the hotel where we stayed at was packed with multi-colored fish and large turtles that would swim next to you, minding their own business.

Build Buddy released

At Ximian we developed a tool to build, package, sign, qa and distribute the Gnome desktop, which we refered to as "Build Buddy". This week it was released as GPL software.

Build buddy uses an XML-based configuration file similar to the RPM spec file to describe how to build a package and apply optional configuration options and patches depending on the target operating system. It can work on a cluster of computers and can also run various builds for different operating system on the same machine by using chroot-ed environments (we call those "jails").

We will be moving our XML build files to the public CVS this week.

Brilliant mockups

Nat pointed me to the Scoop proposal. We have been talking about implementing this kind of functionality to solve the issue with the IM client in Gnome poping up all the time, and handling other notifications that the system has for quite some time. The mockups in that site are a great starting place.

Movie of the Night

Went with Duncan and Robert to see Fog of War featuring Robert McNamara. A media rich movie, surely inspired by his book on the Vietnam mistake. Gorgeous music by Philip Glass. Obligatory watching required.

Message to Nat

Dude, if you read this, please return our salami and cheese. We checked your fridge while you were out, and you have to dispose those tomatoes you got six weeks ago, they are starting to smell.

I love the Internet

Sometimes I get advise from random people on writing code.

The Independent/UK is running the Real State of the Union report.

DaCapo

A research project called DaCapo implemented a memory management toolkit in Java for the Jikes Java VM. This GC engine looks fairly good.

One of the fascinating things about Jikes's JIT engine is that it was completely written in Java. Absolutely mind-blowing. The upside is that many things can now be done in a higher-level language than C like JITing and garbage collection, the downside is that these systems are fairly heavy during compilation time and are best suited for server use and not desktop use.

A balancing act would be fantastic.

In Mono a few months ago we discussed a few possibilities on implementing more code in the managed world for the JIT engine. One of the options is to expose our current IR, and perform a few optimization in the C# world who could mutate the IR and keep the two existing layers: CIL to IR and IR to machine code to remain intact.

To make the above balanced, we could invoke the C#-based optimizations only conditionally, for example, when doing Ahead-of-Time compilation of code.

Just turned the TV on

I turned the TV on, to Bush saying that abstention was the only way of fighting STDs, followed by an applause. Oddly, I was not tuned to Comedy Central.

Little is known about the new intermediate language that Sun is working on. All I know is that Guy Steele is involved in this effort.

The story has various interesting elements: a new intermediate language for high-performance computing; A call to get IBM and Cray involved into the architecture/design of such an intermediate language, a new language (or maybe a language extension) to take advantage of these features and finally because they want to create an industry standard out of it.

This is interesting in many levels: first, it could be a departure from Java's current focus of compatibility. This policy of VM compatibility, while good for software developers, and to Sun's story of write-once, run anywhere has also lead to the stagnation of the VM specification, and the intermediate byte code language. Which is a source of criticism from people who want a performing intermediate language. Today the Java intermediate representation can not be effectively used as it is for high performance code.

But Sun has the engineering talent, the knowledge, and the team to turn their expertise in optimizing compilers into a new intermediate language that would better suite the Fortran/C/C++ developers.

I of course would love to see the ECMA CLI be the foundation for this work, but if I were in their shoes, I would probably begin by extending the Java byte codes towards supporting features from the Sun IR for their optimizing compilers, or extend the Sun IR to support object-oriented features that could support Java.

Maybe Sun is interested in going through an ECMA-like process to standardize this intermediate representation. Am looking forward to learn more about this project.

My interest in this comes from the work we have done in Mono and Mono's IR. Although we are very proud of the code generation engine we have, it is still in its infancy in terms of the optimizations we can perform. I guess I would love to learn how Mono can benefit from it, and even maybe be able to consume this IR.

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.

Chris (of Hungry Programmer's fame, X-Word, LessTif, Jafar and most importantly Evolution) had a close encouter with the FBI and the Secret Service and they took all of his computers, details are here.

Small Mono Status Report

We keep focused on our Mono 1.0 release, so those of us working on this release get to enjoy fixing bugs, while the others developers get bored to death implementing new code and boring new features.

To keep the excitement some folks have been doing performance tuning, the Mono C# compiler has been a good test bed to improve our performance. Various elements come into play: precompilation (which for compilation gives a 30% performance boost), VM improvements (method to assembly inlyining, optimizations, memory saving), class library improvements (reducing the memory size used by our classes) and in particular the compiler got tons of tune ups. Ben, Gonzalo Jackson, Paolo and Zoltan have all been working on this.

A lot of interesting data came from the mono --profile output on the compiler, and by reducing the memory usage of the compiler we were able to get 26% of performance improvements in a month. So now the compiler is down to 2.9 seconds in bootstrap time (without precompilation compilation, just pure JITing) on my machine.

MonoDevelop, a port to Gtk# of SharpDevelop has been gaining momentum, and we have now moved it to the Mono CVS repository, although we are using Subversion for this project. This project has drawn a lot of attention and has helped improve and tune some of Gtk# which is quite mature nowadays.

On the other fronts, it is mostly bug fixing: the networking stack, the xml stack, the web services stack, asp.net is getting a lot of attention, and a lot of bug fixing.

Martin is taking a sabatical to complete the core of the debugger. Once he is done with these core changes, we will bind the UI to MonoDevelop while he completes the compiler Generics support, and maybe we will drag him back to the debugger for another pass of bug fixes.

Peter is working on integrating the Wine and Cairo, so we avoid having them fighting for the screen as we have them now. This will include updating our port of WineLib to the latest version of Wine.

The MacOS X port is working, but it needs testers on MacOS to try the latest editions of the Boehm GC do build fixes and so on. On the PowerPC, we are moving our focus to Linux.

First University Project

Eric Durand and Francois Beauchemin from the Laval University will be implementing the compiler for regular expressions to CIL for the Mono runtime. This is part of their last semester work, and I will get to evaluate their work.

A couple of interesting links founds on Slashdot posts. First, a fascinating reading at The Register from the CES in Las Vegas: "HP declares war on sharing culture", then the home page for professor William Kahan which contains tons of interesting articles on floating point, algebra, math and java.

Some folks have been using Mono as a research platform recently (virtual machine, dynamic code generation, code optimization, profiling, recompilation, tuning, security) and more.

Duncan told me that he met with a few folks from a University during his holidays and they said that they chose Mono over Rotor for research because Mono has a real JIT as opposed to Rotor's simple JIT, and we also have a solid base for optimizations with our SSA platform.

Many areas in Mono can be improved for people who approach it for research though. We should improve these areas. We need better documents in a per-function basis, a lot of the time we do not have those and unless you are familiar with the code it might be hard to understand on a first read what things do. We also need to document the fields used in our structures better.

Now, the good news is that if you are a dedicated hacker, in a few weeks you can understand the JIT engine and implement some nice optimizations. Recently Patrik Torstensson came back to hack the JIT engine and implemented various optimizations (signed div constant fodling, inlining of common opcodes, peephole optimizations), as well as fixing various hard bugs.

Massimiliano Mantione as part of the hiring interview for the JIT engine wrote Arrays Bound Check elimination.

Peter today announced his new MBuild tool. A replacement for Make/Ant/Nant/MSBuild.

As we discussed the various benefits that MBuild has over other systems on irc in #mono, I came to a realization: There are tons of good new, fresh ideas in MBuild. Which is quite unusual in a build system.

The tarball is available here: http://www.newton.cx/~peter/files/mbuild-0.0.1.tar.gz Start at the README, and then check out doc/Manifesto.txt.

Bush in 30 Seconds

The finalist videos are out, you need QuickTime to watch them.

Slow day

Slow day, mostly administrivia, coping with the new office at the new building. We moved from Boston to Cambridge, very close to Quantum Bookstore. Still got a chance to check up jwz's livejournal and tried to use BlogLines to browse my blogs.

Good article

Can not remember where I found this link today, from George Soros: The Bubble of American Supremacy..

Fantastic vacations in Brazil, today am leaving Rio de Janeiro and going back to Boston.

Mono Develop

pedro, tberman and jluke have made a tremendous amount of progress on their effort to port SharpDevelop from Windows.Forms to Gtk#. They got intellisense working, the shell and are now porting the various smaller dialog boxes, which is a great sign of the progress, in only three weeks.

Martin has been improving the reliability of the debugger. The debugger is made up of a core API and various "interfaces" to it. The only one working today (the others have bit-rot) is a bizarre command line language.

Before I went on vacation, I was debating what to do about the UI for the Mono Debugger, I thought we should write a new debugger by pulling as many nice widgets from the gIDE/Anjuta efforts and redo the debugger, but now with MonoDevelop being available it only makes sense to integrate the debugger directly into the IDE instead of creating a new UI just for the debugger, and we get to reuse syntax coloring, intellisense and the other SharpDevelop shell features.

Once MonoDevelop matures a bit more, it will make sense to also do port the code coverage GUI to it, implement a GUI for the profiler and move Gtk-NUnit# to it.