by Miguel de Icaza

Went to Provo today to do a small presentation about Mono in an open session to Novell engineers. It went pretty well, and I also got to talk with various developers about Novell's existing product line.

Of particular interest are iFolder and NetMail

Posted on 12 Aug 2003

New apartment

by Miguel de Icaza

I signed my lease for my new apartment, which will be just a few blocks away from my current place. Nat will be my neighbor.

Posted on 10 Aug 2003

New Chapter

by Miguel de Icaza

A fresh new chapter begins.

More updates at Nat's site

Two fantastic movies this weekend. I just finished watching Was tun, wenn's brennt? which Laura recommended. Yesterday Alex, Nat and myself went to see L'Auberge Espagnole.

Maria Laura in Mexico:

Posted on 04 Aug 2003


by Miguel de Icaza

Guido recently quoted a conversation we had about Parrot. I said to him that the Parrot VM design was based on ideology (Guido quoted me as saying religion ;-).

One of my favorite books is Computer Architecture: A quantitative approach.

The parrot design is based on ideology because some of the core design considerations are just that: `real machine use registers, hence register-based intermediate code is faster'. An ideology-based design is one where the design decisions are driven by punch lines and not by a careful and quantitative study of the problem at hand.

Mono implements the .NET virtual execution system; This execution system uses a stack-based instruction set to transport code. Mono never actually sees the stack operations, because we treat the stack-based operations by their name: a serialization format for a tree representation of the original code.

So for example, if you have an operation like:

		a = b + c;

The code can be thought of as:

A possible serialization of this tree is easily expressed by a lisp-like expression:

	(assign a (add b c))

Another possible serialization is using bytecodes, for a stack machine

	ldloc b
	ldloc c
	stloc a

The above set of stack instructions can be easily decoded back into its original form (see drawing above). This is what the Mono JIT does: it transforms its input CIL bytecodes into various trees like this (we call these the forest of trees):

(stind.i4 regoffset[0xfffffff8(%ebp)] (add (ldind.i4 regoffset[0xfffffff4(%ebp)]) 
				      (ldind.i4 regoffset[0xfffffffc(%ebp)])))

The above if the debugging output that renders our C-based trees. We then use a code generator generator to transform the high-level operations (not listed in this example) into a list of low-level instructions:

        1  loadi4_membase R9 <- %ebp
        2  loadi4_membase R10 <- %ebp
        3  add R8 <- R9 R10 clobbers: 1
        4  move %eax <- R8

Depending on the optimizations turned on, there might be other steps involved, the end result is:

	mov    0x8(%ebp),%eax
	mov    0xc(%ebp),%ecx
	add    %ecx,%eax

(Actually, I had to trick the JIT compiler into doing this, because dead-code elimination and inlining in Mono eliminate redundant code).

Scripting languages

Now, am interested in this debate, because I think that Mono and the .NET VM are ideal virtual machines for scripting languages. Since the .NET folks have done a fair ammount of work into the interop issues (The Common Language Specification) and it is a fairly advance virtual machine, my interest is making Mono a good host for those languages.

It has been said `.NET works great for static languages, but not for scripting'. Which is not true; VB.NET and JScript are both dynamic languages that happen to work just fine on the .NET Framework. And we are convinced that the virtual machine can be improved.

The main issue we have today with Mono and scripting languages is that nobody has done a quantitatie study of what are the performance problems of running a dynamic language in the .NET/Mono CLR: Without an attempt to have a native compiler for the platform, and studying the problems, it is not possible to solve them.

In one particular case (Lisp), we know that implementors will likely want to structure their code (or their generated code) like this:

class Cell {
	Atom Head;
	Cell tail;

Method ()
	if (object is Cell){
	} if (object is Atom){

So what they need in this particular case is a fast implementation of the `is' operator (the `isinst' instruction). For this, we did a proposal

Posted on 22 Jul 2003


by Miguel de Icaza

Posted on 13 Jul 2003

by Miguel de Icaza

Lots of Mono improvements recently; We released version 0.25 recently, which included plenty of the updates to the runtime and class libraries that were required by our partnership with Source Gear to run their vault software on Linux.

Still doing plenty of traveling, after the awesome GUADEC conference in Dublin, I visited Madrid fora couple of days, and then came to Mexico to do some paperwork. Will be flying to Oregon to the O'Reilly conference on July 8th

Will be on Mexico this weekend, and I get to vote (por the PRD of course)

Posted on 02 Jul 2003

by Miguel de Icaza

Miggy went to Brazil, met girl, fell in love, got engaged.

Pictures are here, here, here and here.

Posted on 12 Jun 2003

by Miguel de Icaza

Data Loss

My T30 hard drive died today with all of my information. If you know of a good data recovery service that deals with Linux file systems, please let me know (

Now I have an excuse for not replying to pending mail.

Update: I did recover all my data from a company that does disk drive recovery. I was fortunate enough that only the beginning of the hard drive got scratched, and my Linux data partition was not there. Now a long and painful process of pulling the data back begins.

Posted on 25 Apr 2003

by Miguel de Icaza

Generators Zen

I got most of the iterators support on the Mono C# compiler working now, hopefully these will be checked in CVS as soon as I polish a few things. You can read a small tutorial about them here.

I think that this has more potential than advertised.

Basically, the iterators support in C# simplifies the implementation of methods that return IEnumerable and IEnumerator classes. Typically an implementor would have to create a helper class that would track the state of the enumerable class, and implement a number of methods: MoveNext, Reset, and GetCurrent. Implementing this state machine is not only boring, but also error prone.

Implementing these patterns are so boring, that the average developer fights the system, and designs clever workarounds: From passing a delegate (a method pointer) to be called back, and have the enumerator work linearly; to construct an array with all the results, and returning this; or the worst, exposing the internals of their object. These solutions might work, but they are not available to the platform developers, as they have to provide the right framework for developers; This also means that average developers wont have their code integrate nicely with the underlying platform and interoperate nicely with others.

The C# iterator support works around the problem. Now it is trivial to implement these enumeration interfaces. There is no excuse to not use the system pattern, as it is so simple to use. Lame sample follows:

	IEnumerable CountToThree ()
		print ("About to say one");
		yield 1;
		print ("About to say two");
		yield 2;
		print ("About to say three");
		yield 3;

When invoked, say from the foreach construct:

	foreach (int value in CountToThree){
		print (value);

The message "About to say one" would be printed, then, the routine would return, and the value would be printed by the print in the foreach main loop. Then, when the next value is about to be retrieved, the execution will be resumed where it left, and the string "About to say two" would be printed, and the value 2 returned.

Notice something: the values are not pre-computed ahead of time and returned: they are returned as they are consumed. This is implemented by a clever state machine and an internal class generated by the C# compiler.

Now, today as I explained my excitement to Ettore on the yield keyword, I realized that it could have more uses outside the scope of implementing enumerator interfaces. Part of the beauty of the yield is that from the developer perspective, it suspends the execution of the method at that point, only to be resumed later on.

This beauty is not obvious at first. It took quite some time for me to assimilate this. Lets repeat it again: the yield keyword suspends the execution of the routine, only to be resumed later. This is not only interesting, this is absolutely fabulous.

What the designers of C# have done here, is that they have taken an annoying and error prone pattern and have made a language extension that effectively addresses a problem.

But it seems like yield could be used for a lot more. In fact, over the years I have implemented plenty of state machines, in the presence of non-blocking operations. Non-blocking protocols handlers, parsers, and GUI applications. It starts to feel like a waste to have this functionality under-used.

For example, an streaming XML parser looks like this:

HandleToken (int token)
	switch (state){
		case START:
			if (match (token, "<")){
				state = "<";
			error ();
		case "<":
			if (match (token, identifier)){
				state = IDENTIFIER;
			error ();
			if (match (token, OPEN_QUOTES)){
				state = QUOTE_HANDLING;
			} if (match (token, ">"){
				state = START;

It would be fascinating if this could be implemeted with yield:

HandleToken (int token)
	if (match (token, "<")){
		if (match (token, identifier)){
			if (match (token, OPEN_QUOTES)){
			} if (match (token, ">")){
				goto open; 	// you know you love it.

Ok, that is probably not the best example, as this is just the first time I have thought of this (Am sure the lisp, scheme, icon people have better examples of this). The one things missing here is how to resume the method, and how to provide any new parameters to it. Maybe a resume (method, args) would do the trick.

But the same sort of patterns exist on GUI applications: for example consider the state handling of user input while doing region selection (or the other hundred states tracked by Gnumeric for example).

Extending C# string support

A few things I would like to see in C#, these do not even require changes to the language, but only to the String class:

class String {
	// Returns the string STR replicated COUNT times.
	static string operator * (String str, int count);

	// Splits the string used the provided string
	static string operator / (String str, String sep);
	static string operator / (String str, char c);

	// Extracts a range of characters, notice that String.Substring is annoying
	static string this [int start, int end] 

string s = "Hello World;

print (s [0, 4]);  	// prints "Hello"
print (s [-2, 2]);	// prints "ld"
print (s * 2);		// prints "Hello WorldHello World"
string [] j = s / " ";  // returns {"Hello", "World"}


Been fascinated about the Gtk# Wiki

Posted on 22 Apr 2003

by Miguel de Icaza

After Zoltan got us some nice 20% of performance back in the compiler by providing the GC with object maps and having the compiler drop unused structures early on, I felt compelled to do some performance work myself. My results not as impressive as Zoltan, got us another 10% from using a negative type lookup (it was there, but not fully used) and another 5% from using the new namespace information (Paolo got us a new Mono method to fetch all the namespaces in a type).

Also been fixing plenty of bugs in the compiler so Paolo wont complain when I look at C# 2.0 features. There is one bug that I have tried to fix four times now, and made some progress. I have patches to fix part of this, but not to gracefully handle some of the side effects.

After doing pure bug fixing this weekend, I started the work on C# Iterators, a fascinating new addition to the language. Initially I got pretty scared at them, because I did not have any ideas on how to handle the iterator state. Now that I figured how trivial and simple it is, I started to implement it. This is going to be very nice to use.

Posted on 21 Apr 2003

« Newer entries | Older entries »