When am browsing documentation for an API on the .NET Framework in the Microsoft Documentation Browser I get the signature for the method in a bunch of languages.

I typically only care about the C# signature, I really do not care about the other five languages. Now, when I turn them off with the "Language Filter: " to only show C# that works fine as long as I do not try to read another page. As soon as I switch to a different API the filter is reset and shows "All" again.

I tried Googling for an answer. I even tried search-dot-msn-dot-com-ing it, but I could not find any way of forcing the doc browser to keep it funky.

As the subject says, Mono, Beagle and F-Spot are now included in the second beta of Nexenta.

Nexenta is an operating system built on top of the OpenSolaris core and the Debian userland.

Beagle is the Mono-based desktop search that we implemented at Novell (similar in spirit to Google Desktop search or Apple's spotlight).

F-Spot is our personal photo management software.

This is great, and we look forward to help the Nexenta developers with any issues they might have with Mono on OpenSolaris.

Although to reach magnificent-hack status we still need Sun and Apple to ship Mono.

Video

Oh, and if you have not seen the video from the previous blog entry, you should.

This video is too funny.

Gobble, gobble.

The Jesus General proposes some updates to the amendments.

The comments section has some great suggestions as well.

The Mono team is working on a number of directions to improve code generation. Although Massi has worked on a number of advanced optimizations to improve code generation (based on SSA and HSSA), the improvements were dominated by problems on the register allocation.

We are working in two directions to fix this issue. A long-term fix is the new linear IR representation which Zoltan is working on. This code today is available in the mini-linear-il branch on SVN. The intention of this new IR is to improve the visibility of register usage to the register allocator, so it can make better choices when producing code.

A second line of work emerged from our research into inlining. Turning on the Mono inliner produced worse code than not turning on the inlining at all (we have it turned off by default on Mono). The problem was that inlining produced plenty of local variables and the resulting IR became very hard to optimize by the higher layers of the JIT engine so Massimiliano devised a plan to eliminate these extra temporary variables.

The details of this new optimization can be found on his mailing list post "Tree Mover".

What follows are a few excerpts from the email. Consider this piece of C# code:

	private int f;
	
	public int F {
	        get {
	                return f;
	        }
	        set {
	                f = value;
	        }
	}
	
	static int Inline (int a) {
	        return a * 4;
	}
	
	public override int Cprop (int v) {
	        return Inline (F + v);
	}
	

The IR produced with the method "Cprop" is this:

	 (outarg (ldind.i arg[0]))
	 (stind.i4 local[2] call[get_F])
	 (outarg (add (ldind.i4 local[2]) (ldind.i4 arg[1])))
	 (setret call[Inline])
	

The problem happens when we inline the call to "Inline", which turns the IR into this:

	 (stind.ref local[3] (ldind.i arg[0]))
	 (stind.i4 local[2] (ldind.i4 (add (ldind.ref local[3]) iconst[8])))
	 (stind.i4 local[4] (ldind.i4 local[2]))
	 (stind.i4 local[6] (add (ldind.i4 local[4]) (ldind.i4 arg[1])))
	 (stind.i4 local[5] (mul (ldind.i4 local[6]) iconst[4]))
	 (stind.i4 local[4] (ldind.i4 local[5]))
	 (setret (ldind.i4 local[4]))
	

The extra variables introduce the extra pressue on the register allocator, which today produces pretty bad code (see Massi's original post for the details).

What Massi's new tree mover code does is remove the unused local variables from the previous representation:

	 (setret (shl (add (ldind.i4 (add (ldind.ref arg[0]) iconst[8]))
	 (ldind.i4 arg[1])) iconst[2]))
	

That is a much better tree to cope with in the code generation phase, and produces nice and compact assembly code.

Read his post "Tree Mover" for details for the actual assembly code produced before and after and benchmark information.

Ankit Jain which maintains the Mono IL assembler has started a blog here.

He is currently working on adding generics support to our assembler and disassemblers and working on roundtripping the assemblies (the process of disassembling and reassembling the libraries and obtaining the same binaries).

Lluis blogs about his recent work to integrate the Glade-3 GUI designer into MonoDevelop.

With his recent changes you can maintain your Glade-based UIs from within MonoDevelop: changing properties of widgets, manipulating your UI and the best bit is that whenever you add a new event handler it automatically adds the stub of code to the C# file.

You can see a screenshot in his post.

Mono supports a number of platforms, Windows included. For us, supporting Windows is important because it helps us debug our code, helps ensure that we are doing things portably, and is useful to test applications on Mono in Windows and contrast it with .NET on Windows.

Today on the mono-list someone mentioned another use of Mono on Windows (as part of a bug report), which made my day:

It's reasonable to ask why someone should be interested in running Mono on Windows when the original .NET is available. My reason is that Mono applications can be run without an install. .NET requires a lengthy installation (and a reboot with 1.1 SP) that many administrators (if not users) will not consider. Mono can be copied on (or even run from a memory stick).

It is not every day that you run into reasons to run an open source implementation of a Microsoft standard on a Microsoft operating system.

Mono on S390x

In the mean time, in another side of the universe Neale completed the 64 bit port of Mono to the S390x. It is part of Mono 1.1.13.

Banshee Update

Aaron posted an update on his work on Banshee, the awesome Mono-based music player that ships with SUSE Linux.

Imeem on Mac

Congratulations to the Imeem folks for shipping their Imeem Client for OSX.

Imeem is the second commercial Mono OSX application that ships.

I just woke up to the announcement over at Chris Blizzard's blog (from Planet Gnome) that Mono today was included in Rawhide, the staging area for the next release of Fedora Core.

These are fantastic news for Mono users and developers everywhere and for Fedora users which will get both Mono and the various Mono-based applications that have been cooking.

Am looking forward to work together with the Fedora folks.

If you are a new Mono user, here are some useful links:

• A directory of introductory topics to Mono.
• Links our development plans, broken up by category. A good entry point into the Mono hacking universe.
• Mono's Platform Support.
• Gnome users will be interested in Gtk#: our binding to the GNOME platform libraries.
• Documentation on Embedding Mono into your C application, to extend your application with Mono-based code.
• Programming Languages that are supported by Mono. As your tour guide, I suggest you look into these tasty new languages: Boo, IronPython and Nemerle.
• For those learning C# for the first time, I still strongly recommend the ECMA 334 specification: the first few chapters include a very well written tutorial.
• Edd and Niels book remains a good introduction to Mono and GUI programming on Linux: Mono: A Developer's Notebook.

The Jesus General posts a few profiles from the documentary Persons of Interest.

The "Reports to the General" over at the Jesus General are always fun, make sure you check them out.

Reminds me of what Molly Ivins said about vegetarians.