Miguel de Icaza

Cross-platform, standalone Silverilght Applications

Miguel de Icaza (miguel@gnome.org) — Tue, 06 May 2008 19:41:00 GMT

Tamir Khason published an interesting approach at hosting standalone Silverlight applications.

His solution is a Windows.Forms application that hosts a Windows.Forms.WebControl and inside the WebControl he hosts Silverlight.

Unlike my proposal for standalone Silverlight Applications that is currently Moonlight-specific (and currently limited to Linux/X11) this approach works on Windows with .NET and with Linux using Mono and Moonlight:

Left side: .NET hosting WebControl and Silverlight on Windows; Right side: Mono hosting WebControl and Moonlight running on Linux.

In addition to hosting the WebControl for hosting Silverlight, a thread is running to dispatch http requests locally using HttpListener. HttpListener is an embeddable HTTP server that is part of the class libraries, and exposes a very limited API. You can host ASP.NET with HttpListener by doing the bindings by hand, or you could use our Mono.WebServer library (part of our XSP/mod_mono distribution) to allow your applications to have a fully hosted ASP.NET server.

Mono.WebServer is what iFolder uses to embed the ASP.NET server to expose SOAP-based WebServices to clients.

Of course, this currently does not work on MacOS X as we do have no implementation of WebControl for Windows.Forms on OSX, something that a contributor might want to look into.

You can get the source for the sample from Tamir's page.

Consulting Gig at Novell

Miguel de Icaza (miguel@gnome.org) — Tue, 06 May 2008 18:06:00 GMT

We are looking for consultants to work on a six to nine month project at Novell to write a prototype for a Visual Studio addin in C# or C++ that will connect Visual Studio and its debugging infrastructure to a remote Linux machine running Mono and the Mono Debugger.

If you are interested in working with us in this project, you must have good C# and C++ skills, experience with networking and protocol design, knowledge of COM and assembly language programming are pluses.

We are looking to bring two consultants for the duration of this project. If you are interested, please click this link and attach your resume, pointers to some existing projects of yours and so on.

Rodrigo Kumpera Completes the Mono Verifier

Miguel de Icaza (miguel@gnome.org) — Wed, 30 Apr 2008 20:52:00 GMT

Rodrigo Kumpera, one of our VM developers has completed the instruction verifier for Mono's virtual machine. This effort started in June of last year.

The verifier is a late addition to the Mono VM as it was not a priority to run untrusted code inside the virtual machine.

But as Mono user base grew, it became important to support this feature. Second Life needs this to run potentially malicious code that is uploaded by a user, and we need this to provide an execution sandbox when running Moonlight on the browser.

Rodrigo did this work in stages: the first stage was to add support for the 1.0 virtual machine opcodes. Once that was done, verificiation for the 2.0 generic instructions was added.

This is an important milestone in our support for Silverlight 2.0 support on Linux.

Congratulations to Rodrigo for his work!

Mono and the Google Summer of Code 2008

Miguel de Icaza (miguel@gnome.org) — Mon, 28 Apr 2008 04:18:00 GMT

This year Mono is participating again on the Google Summer of Code. A list of the applications that were accepted is available at Google's page.

This year the quality of the applications and the new ideas submitted (aside from those we proposed) was fantastic. They were too good, and it was very hard to select the final projects (we wanted to pick 33 of the 75 projects proposed, but there were only 15 slots available).

LinuxersForObama

Miguel de Icaza (miguel@gnome.org) — Fri, 18 Apr 2008 21:28:00 GMT

Linuxers, BSDers, FLOSSers, GNUers, OSSers, Mysqlers, Gnomers, KDErs, Monoers, Javaers, PHPers, I invite you to donate to Obama through the LinuxersForObama campaign hosted at My.BarackObama.com web site.

If you are a US citizen, or a legal immigrant (green card holder), you can contribute 10, 20, or perhaps 2,300 to the Obama campaign.

You can donate here http://my.barackobama.com/page/outreach/view/main/LinuxersForObama.

I called the campaign "LinuxersForObama" because its short. I know it should have been called "GNULinuxBSDApacheX11PythonPerlMySQLPostgressPerlRubyJavaRailsMonoForObama", but it was getting hard to type.

And if you are a Windowser or Mac()er, but you like how Linuxers stick it to the man, feel free to donate to my LinuxersForObama campaign.

In retrospect, I should have created one campaign per product, and use that to settle once and for all, which is the best FLOSS project.

Standalone Silverlight Applications

Miguel de Icaza (miguel@gnome.org) — Thu, 17 Apr 2008 19:38:00 GMT

Last year we created a framework to run Silverlight applications as native applications. At the time we called those applications moonlight desklets.

The desklets are Silverlight applications that run in standalone mode, with full access to the entire Mono API stack (as opposed to be limited to the .NET subset for the web) and that can optionally render without frames. This is a screenshot from three desklets running on Linux from last year:

Beyond hack-value, there are in my opinion many reasons why this is valuable. Powerful .NET programming model, powerful graphics and animation framework, reuse the same code base for Web and desktop development, and a sandboxed execution model.

Many people have asked us privately about this.

The Magical `mopen` Command

To run a standalone desklet, all you have to do run the mopen command, like this:

	$ mopen ruler

The above command will look for a directory called "ruler" listed in your PATH, and if the file default.xaml lives inside that directory, it will open that file up. This XAML file can in turn reference managed code.

We did this so applications could be deployed in directories, very much like they are deployed on MacOS. The rules are simple, applications should be self-contained, keep all their data relative to their executable base directory, the foundation for this started with our application deployment guidelines.

It also draws inspiration from the bundles from MacOS X and the `open' command there.

How does this work? Lets consider our enterprise pixel measuring tool, the Moonlight ruler, which is made up of two files:

default.xaml, the basic XAML container, it references the managed code in ruler.dll
ruler.cs contains the code to draw the ruler.

This is what it looks like when you run it:

Awesome Moonlight desktop ruler.

Details

At LugRadio Live this weekend in San Francisco I decided to turn my Mono talk into a Moonlight talk, and I discussed some of the things that we have been doing with Moonlight.

Let me start with this artist rendition of Moonlight's Core:

The orange pieces were built by the Mono/Moonlight team at Novell. The green pieces are provided by Microsoft (and only for use in the browser context, we will get back to this later) and the blue stuff is stuff that we consume from the community.

The Moonlight Core provides the high-level canvas, the XAML loading, the animation framework, timers, media streaming and demuxing and event dispatching. It also has very few dependencies, it uses Cairo to render graphics and interfaces with our media pipeline and needs codecs to do video (currently ffmpeg if you build from source, or Microsoft's when we release).

Our engine today has three frontends:

The most important one of course is the plugin front-end, the one that is embedded into Firefox and renders the Silverlight content.

The other front-end is a Gtk# widget, a simple Gtk+ host that embeds the Moonlight Core into a widget and allows developers to embed any kind of XAML content (including managed code) inside it. I did a demo of Banshee embedding a grid of video players at LugRadio.

This is a widget that can be used to spice up your application. If you feel that you need some bling for your application, some gratuitous animations and special effects, the GtkSilver widget can help you. Using it is trivial:

	using Gtk.Moonlight;

	[...]
	void SetupWidget ()
	{
		Application.Init ();
	
		GtkSilver surface = new GtkSilver ();

		surface.LoadFile ("MyAnimation.xaml");

	        
		Window w = new Window ("Demo");
		w.Add (surface);
		w.ShowAll ();
		Application.Run ();
	}

If you want to get a handle on specific objects, you can just use the FindName method on the surface's canvas:


	MediaElement handler = (MediaElement) surface.Canvas.FindName ("MyVideoPlayer");

	// Start playback.
	handler.Play ();

And the third interface is the fabulous mopen command that we previously described (which is conveniently implemented on top of GtkSilver; yes, we know, we are geniuses).

The Two Stacks

As you might suspect from reading about GtkSilver and the browser, the Moonlight managed stack (that is, the C#/.NET APIs) actually comes in two shapes:

Browser API: This is what people creating Silverlight applications are familiar with. Its a subset of .NET 3.5 and it has limitations as to what you can do: no local file system access and a sandbox that encapsulates all the actions of Silverlight applications.
Full API: We also offer the full API, this is our implementation of .NET 3.5 that has been augmented with the Silverlight APIs.

As you can guess, GtkSilver and the desklets today use the Full API; And our browser plugin uses the more limited Browser API and the security sandbox.

We will get back to this soon.

Adobe Air

Adobe AIR has a great experience for installing native applications on your system, and they are cross platform (Windows, Mac and Linux).

I found a cute twitter application built with it, and have been a happy user of it for a few weeks (see screenshot).

I have no idea how extensive the AIR APIs are, whether they are sandboxed or whether they provide full access to all the APIs like our Moonlight Full API provides, but you can build some cute desktop applications with it.

I like it.

Silverlight Desktop Apps

Part of the reason why our Desklets did not evolve much in the last year was because there were no controls for them. You could build your own, but that was a lot of work, and it was hard to share, and most importantly, everyone knew that Microsoft was going to ship controls for Silverlight.

Now that controls are part of Silverlight 2.0 and that most of the high-level controls have been open sourced and that they are incredibly powerful and great to skin it makes sense to think again about native desktop applications using Silverlight.

We as a team can certainly create a Linux-only platform for these controls, and live happily with mopen, but we would miss an opportunity of having something cross platform like AIR is.

Ideally, Microsoft would follow our direction and implement and distribute the same mopen functionality that we have for Windows and Mac. This would ensure maximum adoption of standalone Silverlight-applications.

In a less ideal world, we (the Mono/Moonlight community) could port Moonlight's mopen command to Windows and MacOS, but with none of the power of influence that Microsoft has.

Directions and Challenges

Michael Hutchinson has suggested that we should have an minstall tool in the same spirit of mopen. This tool would take care of installation on each platform, creating shortcuts, desktop links and using the right icon.

Moonlight currently runs on systems with Cairo, and requires Gtk+ for event processing. It might be interesting to get it running on Win32, OSX and others with the tiniest footprint possible (bundling Gtk+ for Windows and MacOS for native apps sound large).

Another alternative is to use Microsoft's Silverlight on Windows to implement `mopen' as opposed to porting Moonlight. Apparently its possible to instantiate it through COM in some form, but that would still leave OSX out.

The codecs that Microsoft will distribute for use with Moonlight are limited to use inside the browser. This will prevent Moonlight's standalone applications from playing back any vc-1, wmv, wma, mp3 content.

We could add OS-specific codecs; On Linux we could call into Fluendo's commercial codecs, on Windows and Mac use the system codecs.

But we could also standardize on free video and audio codecs for the desktop edition: add support for the free video and audio codecs (BBC's Dirac, which will become VC-2, Vorbis and Theora).

We are currently busy doing Moonlight 1.0, and then we will get busy doing 2.0. So we will not be able to spend time on any of these projects for quite some time, but these are projects that developers in the community could work on or companies interested in pushing Moonlight in that direction.

Discuss.

Mono C# compiler now also MIT X11 licensed

Miguel de Icaza (miguel@gnome.org) — Wed, 16 Apr 2008 21:58:00 GMT

I know, so exciting, a license.

We are dual-licensing under this uber-liberal license because:

We are changing the license to allow parts of the compiler to be reused as part of MonoDevelop, our LINQ class libraries and to embed it in ASP.NET.
In MonoDevelop: This will allow the compiler to be used to improve code-completion to support C# 3.0 as well as improving the heuristics when offering completions. This will reuse the front end and parts of the backend.
Compiler hosting inside ASP.NET: This will embed the whole compiler into the ASP.NET process, eliminating about one second for each compilation of a piece of code. In the past, for each request for an uncompiled resource, we would have to call the compiler, wait for its output and then load the output. This typically shaves between 0.7 to 1 second on those scenarios, ideal to improve the developer experience.
LINQ Class Libraries: This will allow us to reuse parts of the compiler in our System.Core implementation for LINQ for the current 3.5 generation and upcoming generations. Many corner cases are handled by the compiler, and we will now be able to lift those pieces. This will mostly use the backend of the compiler.

Detailed InvalidCastException Goodness Comes to a VM Near You.

Miguel de Icaza (miguel@gnome.org) — Wed, 16 Apr 2008 20:56:00 GMT

When you perform an invalid cast in Mono (trying to force one type into another with a cast) or JIT would throw an InvalidCastException. If you are lucky, you would get a line number (compile with -g, run with --debug), but if you had a complicated expression you would have no idea what the problem was.

A few weeks ago, in support of Marek's growing pains in tracking down some bugs, Zoltan checked in support for a new feature in the Mono runtime: --debug=casts. Now, When you pass this option to the runtime, it will report the type that you are trying to cast. This feature is not activated by default as it generates more code, and consumes more memory.

This sample:

	$ cat demo.cs
        class Test {
                static void Main ()
                {
                        string s = "hola";
                        object j = s;

                        object d = (Test) j;
                }
        }
	$ mono demo.exe

	Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type.
	   at Test.Main () [0x00000] 

	$ mono --debug=casts demo.exe

	Unhandled Exception: System.InvalidCastException: Unable to cast object of type 'System.String' to type 'Test'.
	  at Test.Main () [0x00008] in /tmp/demo.cs:10

Awesome.

Generic Code Sharing: Good and Bad News

Miguel de Icaza (miguel@gnome.org) — Wed, 16 Apr 2008 19:19:00 GMT

Mark Probst has been working for the past few months on adding support to the Mono JIT to support generic code sharing. This is a technique that allows the JIT to share the same code generated for two differently instantiated types, for example:

	class Stack<T> {
	    T [] data = new T [10];
	    int top;
	
	    public void Push (T t) { data [top++] = t; }
	    public T    Pop  ()    { return data [--top]; }
	    public int  Count      { get { return top; } }
	}

	class Test {
		static void Main ()
		{
			Stack<long> ls = new Stack<long> ();
			ls.Push (10);
	
			Stack<Test> ts = new Stack<Test> ();
			ts.Push (new Test ());
	
			Console.WriteLine ("Count={0} {1}", ls.Count, ts.Count);
		}
	}

The JIT must generate different code for the actual Stack instantiation, one must contain a pointer (32 bits on 32 bit machines) and another one must contain 64 bits. So the structures are different in memory, and so is the implementation for Push and Pop.

But certain methods do not depend on the datatype sizes (for example) and could be shared regardless of how their container type is instantiated.

Mark posted the Good news, the bad news and his strategy to deal with the bad news. Am going to limit myself to the good news, and you can click on the link and read the thread for the bad news:

Now for some interesting statistics.  Apart from the runtime's test
suite I've used three other test suites/benchmarks, namely IronPython
(running pystone), Nemerle (compiling its own compiler) and FSharp
(compiling and running a Hello World program).  Here are the
Good-News-statistics.  The numbers given are "no sharing / sharing"
and have been collected on a 32 bit system:

IronPython
  Methods compiled: 3614 / 3368
  native code space used: 719k / 691k

Nemerle
  Method compiled: 7210 / 6302
  native code space used: 2001k / 1943k

FSharp
  Methods compiled: 15529 / 11431
  native code space used: 2193k / 2062k

See his post for the rest.

Update: Mark informs me that the "bad news" that I conveniently left out of this post (memory consumption in FSharp for bookkeeping was 600k of memory) has now been fixed.

The 600k of bookkeeping in the FSharp test has been now turned down to 14k. So we can scratch that "bad news" part. Congratulations Mark!

Open Source Powershell Implementation

Miguel de Icaza (miguel@gnome.org) — Mon, 07 Apr 2008 14:59:00 GMT

This weekend ath the Code Camp in Waltham, Igor Moochnick announced the release of pash his open source power shell implementation. It currently runs on Linux, MacOS, WindowsCE and Windows.

pash on Linux.

Igor's project is hosted on sourceforge.

A few years ago Ryan Paul from Arstechnica wrote a nice guide to powershell (when it was still called Monad Shell).

OOXML: The Wins

Miguel de Icaza (miguel@gnome.org) — Wed, 02 Apr 2008 21:54:00 GMT

Regardless of where you stand on the outcome of OOXML becoming an ISO standard, it is worth pointing out that the opposition to OOXML pushed Microsoft into more open directions.

If you are sulking because OOXML was approved, it is worth looking at what actually was accomplished since December of 2005 when the process begun.

Before OOXML came to ISO and the global review of it begun:

Microsoft moving away from their proprietary file formats to open, and XML-based (easier to manipulate, produce and consume) file formats.
Novel raised a record number of issues on the specification, many of which were solved before the spec was approved by ECMA.
About 700 pages worth of descriptions for the formula specifications (one of the major issues from our end when we joined ECMA TC45 in December of 2005).
The OOXML specification placed under the OSP.

Once OOXML went for discussion at ISO, a number of good things came out and are major community wins:

1. The specifications for the old binary file formats were published under the OSP (February of 2008).

2. The above documents were backed up by the British Library in case Microsoft ever stops publishing them (announcement).

3. Microsoft is funding the development of a translator between the old binary file formats and OOXML which should assist folks that have experience in one format and want to understand the other, or just want to convert documents back and forth. If your app lacked support for OOXML, but had support for the old formats, you can use these tools.

4. Microsoft agreed that future versions of OOXML will be covered by the OSP a concern that some people had about future versions of the document.

5. Microsoft pledged to modify future versions of Office to implement the ISO version of OOXML.

6. working group was created to look into harmonization of OOXML and ODF, something that many developers involved in office suites have been advocating for a long time.

7. Microsoft pledged to support features to support other file formats as native file formats in their office suite:

Last year we sponsored a translator project that gave people the ability to read and write ODF files from Microsoft Office. Last month we announced that we would update the Office product so that the ODF translators could natively plug into Office and give people the same options they get from the other file formats. People will be able to set ODF as the default format in Office if that's what they want by simply installing the translators and then changing their settings.

8. Lots of clarifications went into the spec, and people should be happy about that.

9. And finally, now that OOXML is an ISO standard, as Patrick Durusau implied there are many winners.

Anyways, I wanted to keep this short and uplifting, this seems like a win for everyone all around.

Preemptive-reply-to-the-above-paragraph: I will not reply/approve any flames, FUD or half-truths.

I love Reddit Captions

Miguel de Icaza (miguel@gnome.org) — Fri, 28 Mar 2008 15:59:00 GMT

OOXML, looking forward

Miguel de Icaza (miguel@gnome.org) — Wed, 26 Mar 2008 17:49:00 GMT

I have been reading the OOXML storm in a teacup for more than a year now. Am looking forward to the approval of OOXML as an ISO standard and to be able to move the discussion back to the things that actually matter: free and open source software.

For a year, countless bytes have been wasted on what is now a very difficult plot to follow, specially for people that have not followed it since the start (or as Bill Maher said last week "Its like trying to make sense of a LOST episode". Note: am a Lost fan).

When we go back to what matters, we should be ready to ask IBM to open source its Lotus Notes software based on Open Office (as staunch supporters of open formats, and open source, I think its in their best interest to do so). There are nice components in Lotus Notes that would be nice to integrate into the upcoming OpenOffice 3.

But most importantly, it is a time for all of those strong advocates of open standards to stop talking, and start walking. I look forward for all that energy that went into discussing the pros and cons of OOXML to join an open source project and start contributing code, documentation, support, create support forums, file good bug reports and help us make free and open source software better.

In case you have not been noticing, Apple is gaining market share on the desktop. Some of our own kernel hackers, desktop hackers, web hackers that used to be Linux or BSD users are flocking to the proprietary OSX.

We need to change that, lets reverse that trend, and lets focus on what actually matters: the free and open source desktop. To make this happen we will need all the help that we can get.

Punditry and lobbying will not get us very far, real work will.

Mono: 2008 Google Summer of Code

Miguel de Icaza (miguel@gnome.org) — Tue, 25 Mar 2008 03:04:00 GMT

The Mono project will be participating once again in the Google Summer of Code.

Although some ideas from various teams are available in our student projects page this year, I want to encourage students to feel free to submit ideas that they think should be done with Mono.

In past years, a handful of students suggested their own ideas as to what would be an interesting project to work on during the summer, we liked those and turned those into full fledged projects.

Feel free to suggest a project that you think would be useful to the Mono community, and to discuss your idea with us in the Mono Summer of Code IRC channel: #monosoc on irc.gnome.org

Documentation: Generics and CSS

Miguel de Icaza (miguel@gnome.org) — Mon, 24 Mar 2008 22:51:00 GMT

Mono contributor Jonathan has been hard at work and has added support for Generics to Monodoc as well as importing the ECMA documentation for the new generic APIs.

Monodoc now also support man pages (we have a handful now, and we will later add all the mono ones) and we now render using a CSS stylesheet instead of the collection of gross hacks that we used to have.

Check the new docs out.

Pastor Wright

Miguel de Icaza (miguel@gnome.org) — Sat, 22 Mar 2008 18:14:00 GMT

From Dave Winer's blog:

Melroy Hodge, from Queens, NY, a contact on Twitter, sent a pointer to a YouTube video of a longer excerpt of Jeremiah Wright's post-911 sermon, one of the speeches that soundbites were shown repeatedly on cable news this week. I guess it's not surprising that the cable news excerpts gave a very misleading impression. (Next time this happens we must do an immediate fact-check.) http://www.youtube.com/watch?v=QOdlnzkeoyQ
This is a must-watch video. Stop what you're doing, right now, and watch it.
I found myself captivated by Wright's ideas and the way he expresses them.
I agree with everything he said.
I would have been willing to cut him some slack, because this was less than a week after the attack, and those were crazy days, who knew what was coming next. But he was right, we have done what they did to us, and we're doing it again in Iraq. The US was led by despotic people and we followed; we wanted to punish someone, anyone, and it didn't matter if they had anything to do with what happened to us. And we did.

Read the whole post from Dave Winer's blog. The video as he says, is a must-watch.

Also, from the twitter-o-sphere:

OOXML SDK

Miguel de Icaza (miguel@gnome.org) — Sat, 22 Mar 2008 18:07:00 GMT

Microsoft is working on a OOXML SDK for managed languages. They have announced a roadmap:

Being selfish here, I would love to see this SDK relreased under an MS-PL license myself, I think it would be great to get folks outside of the Windows world consume and produce OOXML files easily.

This is a win-win for everyone. Microsoft gets more products consuming and producing OOXML documents on the Windows and MacOS worlds through Mono, and we get a great API to use on Linux with .NET languages.

Although I have emailed a few friends, am not sure am reaching the right people inside Microsoft. I would love to discuss the advantages that MS-PLing the code base would have.

It has to be under a license like the MS-PL as opposed to just a license to use and distribute on Linux for this code to make it and be distributed eventually into Linux distributions.

Dog Whisperer

Miguel de Icaza (miguel@gnome.org) — Sat, 22 Mar 2008 18:07:00 GMT

We became fans of the Dog Whisperer TV show from the Discovery Channel in the past few months. Sadly, we are unable to have a dog at home, so we might look for a new place.

My friend Shelly pointed me to Gladewell's article on the New Yorker about Cesar Milan, just as fun and interesting as watching the show.

Mono Debugger, now with 2.0 support

Miguel de Icaza (miguel@gnome.org) — Wed, 19 Mar 2008 22:01:00 GMT

Last week, Martin Baulig announced that the debugger in trunk adds supports to many 2.0 features, our last major feature missing in the debugger.

The biggest news is that the debugger now has support for C# 2.0
features such as generics, anonymous methods and iterators:

  * We can currently print fields in generic instances, print their
    types and parent classes.

  * Recursive generic types (see test/src/TestRecursiveGenerics.cs for
    an example) are supported, but need more testing.

  * There is some limited support for method invocations, but we can't
    get their types yet.

  * Support for anonymous methods and iterators should now be pretty
    much complete; we can fully access captured variables etc.

To try out the updated debugger in trunk, you must use Mono from trunk. With this code in place, we have now started the work to integrate it into MonoDevelop.

MonoDevelop 1.1 (due in six months) will have support for the debugger.

Remote Debugging

Additionally, Harald announced that they have modified the Mono Debugger to support remote debugging (useful for debugging embedded systems for instance).

They wrote a detailed document on the architecture for their remote debugging framework.

Their work is now licensed under the MIT X11 license, which will allow us to integrate this directly into the Mono and Mono Debugger distributions.

Banshee Release

Miguel de Icaza (miguel@gnome.org) — Fri, 14 Mar 2008 20:58:00 GMT

Yesterday Aaron released the first preview of Banshee 1.0, the Digg-o-Sphere does an in-depth review of the release announcement:

This is what Banshee looks like:

Banshee on Linux.

In other news, thanks to the work of Scott, Banshee will soon be distributed for Windows as well:

Bringing open source media players to Windows.

Banshee uses Lluis' Mono.Addins framework to allow third party developers to extend banshee with interesting new features.

MonoDevelop 1.0 has been Released

Miguel de Icaza (miguel@gnome.org) — Fri, 14 Mar 2008 20:07:00 GMT

After a few years in the oven, we are ready to announce the first release of MonoDevelop. Lluis has put together a set of in-depth release notes that covers the major features available in MonoDevelop and links to various tutorials and screencasts as well as extensive screenshots of what is available in MonoDevelop 1.0.

MonoDevelop 1.0 is designed mostly for Linux developers creating Gnome and ASP.NET applications but MonoDevelop is also available for MacOS users that download our Mono installer and will still be useful if they are building Mono-based applications on OSX.

The IDE has many of the features that you would expect from a modern IDE for Mono: support for programming in multiple languages, an extensible design, editors and designers for ASP.NET and Gnome applications, integration with Unix toolchains and Visual Studio Solutions, support for source code control and following standard Unix development practices, integrated NUnit testing, Unix Packaging and Deployment (following the GNU conventions, and Mono conventions for libraries and packages), internationalization and localization, tools to maintain your project documentation and command line tools to access this functionality.

We have some pretty good language support in this release: C#, VisualBasic.NET, Java, C and C++. Check the previous link for the details as to how extensive the support is for each feature.

Some screencasts:

Creating a Simple User Interface with MonoDevelop.
Creating Custom Widgets with MonoDevelop.
You wrote it, now you want to ship it, see how MonoDevelop can help you: Buildig Packages with MonoDevelop.
Using Subversion to host your source code, see Using Version Control with MonoDevelop.

There is more documentation on MonoDevelop available as well.

The Early MonoDevelop History.

In late 2003, a few developers were looking for an IDE to write C# code in Linux, not something too fancy, but something that would provide Intellisense features.

Windows developers were used to Visual Studio, and Mike Krueger and the developers at Alpha Sierra Papa had created the very successful SharpDevelop project, a .NET Windows.Forms-based application. At the time, Mono did not have a working Windows.Forms implementation (it would take another three years before our official 1.0 release of Windows.Forms) so this ruled.

Although there had been an attempt to make SharpDevelop portable by Mike (with a variation on the theme of Eclipse's toolkit) this effort had not been completed, and SharpDevelop continued to be a Windows.Forms application.

Pedro Abelleira first extracted the editor and intellisense engine from SharpDevelop into a standalone component that rendered using Gtk# instead of Windows.Forms. This was back late in 2003. Initially it was only going to be a text editor.

Development started mostly on irc and quickly contributors started to porting various other pieces from SharpDevelop or rewriting the GUI components with Glade and Gtk#. By late 2003 Todd Berman had taken over the maintenance duties of MonoDevelop and sent me a email on December 31st:

Oh, and we are shooting for eating our own MonoDevelop dog food by the end of this coming weekend, and it looks like we will be there even before then.

History of the GUI Designers

As regular Gnome developers were were very happy using Glade and Gtk#'s [Widget] attributes to bind the XML GUI representation to our own variables. You double clicked on the .glade file, and Glade would launch from within MonoDevelop, you would tweak your UI, save it, and rerun from MonoDevelop.

Around this time Dan Winship from the desktop team started working on a new GUI designer for Gnome, the Stetic GUI designer. This was a Gtk#-based GUI designer, and the idea is that this could be embedded in other applications. An early screencast of Stetic capabilities is available here:

Stetic in March 2005.

Work continued, but Dan eventually moved on to other projects. By the end of 2005 we were looking at integrating a GUI designer directly into MonoDevelop and Stetic was not ready to do that, so instead Lluis integrated Glade-3 into MonoDevelop:

MonoDevelop with Glade-3, January 2006

This project did not live for too long. Glade-3 had to be patched, and we quickly realized that all the features that we wanted would require more than trivial changes to Glade-3. So we decided that instead of investing time in the C code base and the bridge to C#, that we would complete Stetic which was entirely written in C#, this is what it looks like today:

Stetic Designer inside MonoDevelop.

A complete screencast of Stetic and today's MonoDevelop integration shows all the work that Lluis and his team did to provide a smooth editing experience.

Today MonoDevelop not only supports forms design, but it also provides menu and toolbar editors and support for managing your icon collection in your application.

Menu editor

A key feature of .NET is the creation of reusable components. Lluis brought this to MonoDevelop and the stetic editor. This screencast shows how to create widget libraries with MonoDevelop and Stetic that you can later reuse in your projects or in other projects.

The Future

The team has already started work on the next release of MonoDevelop, version 1.1. Our goal is to release new versions of MonoDevelop every six months. To do this, we are planning on doing all of the disruptive changes on branches, and always keep our HEAD revision stable.

There are a number of incremental improvements on our task list, but also some exciting new features. There were many things that we could not get in time for 1.0 are being incorporated or implemented since the 1.0 tree branched a few months ago. Some of the new features that trunk users or alpha testers can get include:

New Managed Editor: The text editor is now entirely managed and has many new features like configurable keybindings (Really nice Emacs keybindings), split windows, Emacs/Firefox-like incremental search on a toolbar (no more annoying dialog box popping up in the middle of your source code) and one of the most requested features: region folding.

Moving to a fully managed widget written in C# gives us a lot of flexibility to improve the editor. This is a theme that was consistent in the 1.0 release, moving from Glade to Stetic and moving from the GdlDock to our own managed dock paid off every time in terms of developer agility and features that we could implement.

ASP.NET editor: new improvements will provide auto-complete and intellisense while editing .aspx files. Also, with the maturity of WebKit/Gtk we are hoping to replace Mozilla as the GUI editor for ASP.NET pages with this.

Integrated Debugging: Currently the Mono Debugger is only available as a command line tool. Our next release of MonoDevelop will provide debugging directly from the IDE.

Windows Port: There is now a Windows profile release of MonoDevelop. This will be great for developers that are building applications using Gtk# on Windows and want to get access to the Stetic GUI designer which currently requires them to use Linux to do this. It is not our intention to compete with SharpDevelop as an open source IDE for Windows Programmers although there might be some overlap.

msbuild-based model: We want to move to the Visual Studio build model to improve interoperability with Visual Studio, Blend and SharpDevelop and other tools that use msbuild files as their interoperability layer. This will allow developers to easily move across tools to work on different parts of a project.

XML Editor: A backport from SharpDevelop's XML editor has been integrated.

Future versions of MonoDevelop will extend on this feature set an integrate Ivan's Windows.Forms designer, Alan's Silverlight designer and improve Michael's ASP.NET designer.

Mono on the iPhone, video

Miguel de Icaza (miguel@gnome.org) — Wed, 12 Mar 2008 21:05:00 GMT

This video shows the Mono C# compiler building a sample native ObjC# application on the iPhone and then running the resulting executable on the iPhone.

Pay special attention to the beautiful error messages that our C# compiler generates.

This is using the ObjC# bindings that provide access to the Objective-C APIs from C#.

Discussion of the bindings and the Cocoa# APIs takes place in the cocoa-sharp and mono-osx mailing lists.

Update: better version, this one the typing with two hands and with some widgets on the screen and some events hooked up:

See Geoff's Norton for more details and also this one with comic included.

Of course, the iPhone is a locked platform, and chances of people being allowed to run Mono seem low.

The real question is when Android will be open enough that we can do a port of Mono to it (there is no C SDK at this point for Android).

Mix 08

Miguel de Icaza (miguel@gnome.org) — Tue, 11 Mar 2008 22:35:00 GMT

Just got back from Mix 08 in Las Vegas. It was good to catch up again with old friends and make new friends. As usual, the event was a blast. To me the big interesting news were Silverlight 2.0 and the ASP.NET MVC release (details at Phil's blog).

Ray's keynote was light on the details, and too abstract for my taste.

The IE8 announcements were interesting. Their contributed test suite for CSS is good news, and came up with two nice new features: activities and webslices. Both ideas and their specifications were released under the OSP, and apparently by the end of the day there was a Mozilla plugin that implemented Activities. Hopefully we will get WebSlices on Linux as well.

Of course my personal favorite were the Silverlight 2 updates.

Since I attended mostly the hallway session, am using this weekend to catch up on the actual sessions. But I loved Joe Stegman's presentation on Silverlight 2 which Mike Harsh described as "we wanted to show code, not slides, lots of examples; you know, developer porn".

Sadly, I could not make it back to Part 2 with Mike, as the room was full and the bouncers were turning people away (and I also missed the repeat the next day).

Office Ribbon

If you love the software that you build, Jensen Harris' presentation on the History of the Office Ribbon is probably the most inspiring talk I have seen in years.

Every developer building GUI applications should listen to this presentation. This is as inspiring as Joel's articles on UI design were a few years ago when we were working on GNOME 2 or Andy's focus on empowering users were back on the Eazel days.

Silverlight 2

First things first. Catching up with Silverlight 2 is a great place to get demos, samples, tutorials, presentations and in-depth coverage of what is new in Silverlight 2.

Silverlight 1.1 consisted of a .NET binding on top of the core Silverlight 1.0 engine and the addition of the DLR and DLR-based languages. This was never intended to be the last word on it, and it was mostly a showcase of things to come.

Silverlight 2 is the evolution of the 1.1 model in a number of directions.

The distribution model: Possibly the most interesting change is that there is now a "core" of Silverlight that will be available on every system and a model to bundle extra libraries for Silverlight. This keeps the Silverlight 2 download small, but most importantly it means that Silverlight 2.0 can ship without having to complete and freeze the APIs for every possible feature that people want.

The "extras" collection of controls are delivered in this way (like the databound controls) as well as things like the DLR. This means that you can use the DLR today, and still allow the DLR and Iron* teams to continue working and improving it without locking developers to an old version of the DLR that would have been deployed with every 2.0 installation.

Some other important changes:

The application model is more consistent, and some of the common usage patterns for applications are directly handled by the new model (download all assets at once).
A control framework. In 1.0 and 1.1, every developer had to create his own control framework, with 2.0 the control framework is in the core, and there is a nice collection of standard controls available (with text input!).
Styles: The control framework also allows for skinning of controls through XAML snippets. For instance, consider a button, there a number of states that a button is rendered as: focused, unfocused, pressed, not-pressed. To transition from one to the other you can specify a XAML storyboard that will transition the button from any state to any other state. And you can also controls what is rendered, and how, independently of the control itself.
Seadragon images. This is the support to quickly download images and implement infinite zooming. See this TED presentation for the details and a nice demo.
Networking: support for socket connections (there are many restrictions here on what can be done) and support for allowing clients to issue HTTP requests to other web sites (this is similar to Flash policy files for the same feature).
Updated DLR and Iron*.

Open source Silverlight Controls

At the keynote Scott announced that the high-level Silverlight controls were going to be open sourced, they will be released under the MS-PL.

There was apparently a miss-understanding and the controls were released inadvertently under a more restrictive license, but both Scott and Brian confirmed that they wanted us to use those controls.

This is brilliant, not only because it helps us, but for a load of useful reasons: it will let developers learn how to write controls early on the Silverlight 2 release process and will allow developers to fine-tune controls if they don't do exactly what they need.

This is important in particular for things like the DataGrid view, as there history has shown that there is no one-size-fits-all (regardless of how parameterized these controls are)

Moonlight

On Thursday I did a presentation on Moonlight. Due to the general nervousness of this presentation I forgot to do a few demos that I wanted to show. I wanted to show Popfly and wanted to show the Silverlight Journal (both 1.0-based applications).

If you install Moonlight from SVN, you will be able to watch the presentation on Linux.

Sebastien is now working on the security aspects of Moonlight (auditing code, understanding the attack surface, trying to break our code). He posted an updated diagram of the trusted callers in the various Silverlight 2 assemblies.

Improving Mix

I personally would like to see "Meet the Experts" come back. Meet the Experts last year (and at the PDC) happens in the afternoon, as a last-session, there is food delivered and there are no other sessions scheduled, so its a good time for everyone to get together and quickly get some questions answered.

In my opinion, the bars and the party are no substitute for this session. Discussing styling of Silverlight controls on the bar goes more or less like this "WHAT ARE THE LIMITATIONS?", "NONE, YOU CAN CHANGE THE ENTIRE VISUAL TREE", "THE WHAT TREE?", "VISUAL", "WHAT?", "THE VISUAL TREE", "WHERE IS THE TREE?".

I still had a blast, but I would like to see "Meet the Experts" back on the agenda.

Mono on the iPhone

Miguel de Icaza (miguel@gnome.org) — Mon, 10 Mar 2008 23:42:00 GMT

Luke Howard from PADL Software Ltd sent me some screenshots of Mono ported to the iPhone:

Some stats:

# hostinfo
Mach kernel version:
         Darwin Kernel Version 9.0.0d1: Wed Oct 10 00:07:50 PDT 2007; 
root:xnu-933.0.0.204.obj~7/RELEASE_ARM_S5L8900XRB
Kernel configured for a single processor only.
1 processor is physically available.
1 processor is logically available.
Processor type: armv6 (arm v6)
Processor active: 0
Primary memory available: 116.00 megabytes
Default processor set: 26 tasks, 164 threads, 1 processors
Load average: 0.00, Mach factor: 0.98
# export MONO_DISABLE_SHM=1
# ./mono hello.exe
Hello Mono World
#

Channel9 works with Moonlight!

Miguel de Icaza (miguel@gnome.org) — Sat, 08 Mar 2008 19:15:00 GMT

I just got back from Mix, updates my Moonlight from SVN and the videos at channel9 are now working with Mono.

Inside Silverlight 2 Beta 1, an overview with Scott Guthrie

This is one of the important pieces of our media pipeline that was missing (support for the HTTP streaming protocol). The implementation is based on the work that Fernando and Rolf did using the recently released specifications that Microsoft published.

Sadly, I was not able to show that at Mix. Its also the first take, so more testing and exercising will be required.

Pre-Mix 08: Moonlight Updates

Miguel de Icaza (miguel@gnome.org) — Mon, 03 Mar 2008 10:52:00 GMT

We have been hard at work in Moonlight and I keep postponing when to blog some updates about our work every few days hoping to cram some new feature in the blog post.

And every few days turn into every few weeks and the next thing you know what should have been published a month ago ends up being my pre-Mix post.

Some of the most important changes in the last two months have been:

Moonlight Media Pipeline: So far we had been using ffmpeg's pipeline to process media. This means that ffmpeg was in charge of detecting the media formats, locating the codecs, demultiplexing the data, and decoding the data into video and audio frames.

The ffmpeg pipeline was fine as a sample pipeline, but we needed a few more things. We needed more control over the pipeline to implement things like media streaming and supporting seek operations over HTTP; We want to be able to relicense the code under non-LGPL terms (for people that can not use the LGPL or some commercial uses) and we need to plug Microsoft's Media Pack media decoders.

Rolf rewrote our multimedia pipeline so that the code on SVN no longer depends on ffmpeg's pipeline and only uses ffmpeg's decoders for video and audio:

The end goal is to plug Microsoft's Media Pack (this contains the codecs video and audio) into Moonlight:

The installers that we currently distribute for Linux do not contain the ffmpeg media codecs. If you need to test media you will need to compile the code from source.

Streaming: With our new pipeline we are now able to stream media. In the past Moonlight downloaded the media file into the local file system, and only when the entire file was downloaded we would start the playback.

Moonlight can now start playback as soon as there is enough buffered data. This works for media that is only available over HTTP. Fernando has been working on the support for media that supports the MMS-over-HTTP (controlling seeking for example). Luckily, the specs for HTTP-based streaming to Windows Media servers were released last week (also the specs for the ASF container format, which should help validate our implementation).

Test Tools: As part of our collaboration with Microsoft we received various tools that are used to test Silverlight. We could not reuse the tools directly for Moonlight (too many Win32-isms, too hard to plug into Mozilla/Linux) so Jackson rewrote all of that code for Linux.

The test tools include plugins that expose Javascript APIs to control Silverlight and the browser, simulate user events and take snapshots of the screen. Microsoft has given us permission to open source our implementation of these tools.

This should help us in creating our own tests, and in checking our own code for regressions beyond the test suites that we will have received from them.

The code should hit SVN soon.

Mozilla Installers: We created some installers for Mozilla that should offer a one-click install experience for users on Linux.

Verifier: Rodrigo continues to work on Mono's CIL verifier and on strengthening the image loader, work that will not be used immediately for our Silverlight 1.0 support, but that will be important for 2.0 (when Mono is required).

Historically Mono had not been used to execute untrusted code as we mostly were a runtime for desktop and server applications and errors in the images fell directly in the "doctor it hurts when I do this" category.

But with Silverlight 2.0 the story changes, Mono will be executing potentially hostile code so this work is mandatory. Additionally, Sebastien has been improving Gendarme and his Monoxide tool to help in the audit process and we have created a security audit plan for the runtime. This work, like the verifier work is a work in progress.

In addition to using it for Silverlight, the verifier work will enable the SecondLife folks to allow the execution of binary code in their simulators instead of being limiting SecondLife to use LSL-based scripts.

Windowless Support: As it turns out Windowless rendering is used by many Silverlight applications. This is where Silverlight content seamlessly blends with the HTMl content. This is a must-have for things like Tafiti, the XamlPad, and the Vista simulator and nice-to-have for some other sites.

The good news is that Chris has implemented the support for it:

The bad news is that this is limited to Firefox 3.0, the 2.0 edition does not have support for Windowless rendering.

See Chris' blog entry for the details about the challenges and limitations of Moonlight/Windowless in Firefox/Linux.

Bug weeks: With the test suite running on Linux we have been focusing on passing all the Microsoft tests that we can and implementing the major features missing (like Windowless support).

Silverlight 2.0 Other than the JIT support for Silvelright 2.0 at this point we have not done any work on it (well there are 3 classes stubbed privately).

There are two reasons for this: the updated 2.0 API is not public and although we have access to it, it is a bit of a mess to try to keep two separate trees (public and private) to support this and since Mix is just around the corner, we will just wait until next week.

The second reason is that we want to focus on shipping 1.0, completing the media pack integration and working on the configuration aspects of Moonlight (auto-update configuration for instance).

Our Priorities

Everyone on the team has been working very hard to get all the pieces in place, and we are getting closer to completion. Every time we fix a bug, it has a nice ripple effect of fixing various other issues that we had seen in some sites at once.

Our priority currently is to ship Moonlight 1.0, and this means more or less:

Integrate the Microsoft Media Pack.
Complete our media pipeline.
Fix all the bugs exposed by the test suites.
Investigate some of the problems with some video card/driver configurations that seem to burn a lot of cycles.
Improve the performance for heavily animated scenes.

Am excited about the Mix conference, looking forward to see the demos and what gets announced. And obviously very excited about my own session on Thursday to talk about Moonlight and Mono.

Time to go to sleep. Marek and myself are on a 7am flight and it will be hard to make it.

Wooohooo! Am on Channel9!

Miguel de Icaza (miguel@gnome.org) — Sat, 01 Mar 2008 00:38:00 GMT

The interview that I had when I visited Microsoft for the Lang.NET 2008 has been posted to Channel9. Its a conversation between Charles, Dragos (from the Volta team) and myself on open source, .NET, Mono, Moonlight and other fun topics.

Mono and the Game Developers Conference

Miguel de Icaza (miguel@gnome.org) — Wed, 27 Feb 2008 01:42:00 GMT

Last week some of us from the Mono team at Novell went to San Francisco for the Game Developers Conference. As some of my dear readers know, I was not much of a gamer a year ago, and I do not claim to understand this industry.

Mono is currently being used by a major publisher [1] to script a new version of a popular franchise (the new edition) and Mono is also the engine that drives Unity3D for scripting and SecondLife is beta testing Mono now on their beta grid.

Other than being fascinated by Unity3D and SecondLife, we had not really paid much attention to games. But in the last nine months we started to get a constant stream of requests to license the Mono runtime to power more and more games.

When Joseph Hill joined Novell in January as Mono's product manager we started to revisit some of these request. People wanted to get a proprietary license for Mono to use on the PlayStation, the XBox and the Wii and some folks also wanted Mono under non-LGPL terms (as it turns out, important to prevent cheating).

Three weeks before the GDC conference, our in-house expert on the game industry Michael Hutchinson told us that this conference existed. In a couple of days we booked some space on the show and we got things in place, we were going to promote Mono as an accelerated scripting engine.

Mono in Games

As it turns out, .NET-based tools and .NET-based scripting of tools are pervasive in the game industry.

As for the games themselves, engines are typically written in a combination of C++, C and assembly language and the high-level code is written with scripting languages. Lua is the most popular language to embed in a game (a procedural C-like language) and Python, variations on Lisp and a never ending stream of evolved batch languages.

People want to reuse Mono on games for a few different tasks. These are some of the reasons that we know about:

Speed: as games become more complex, and people spend more money on software that takes advantage of GPUs, optimizing compilers and even special hardware for physics the weakest performance spot on a game has typically been the language that has been used to implement the high-level portions of the game.
In a world that is increasingly green, it is a waste of perfectly healthy computer cycles to interpret your code when you can use an optimizing JIT compiler to run your code.
Mainstream Language Support: In some cases, game companies have created their own languages, evolved or modified existing languages (modified versions of Lua are common). Some people would like to get access to more mainstream languages to develop their game logic.
In the short term, jumping from procedural languages to object oriented languages is a first jump.
Hopefully they will drink the functional kool-aid and use some of the C# functional features, or even F# to write their games.
Code Sharing: C# or .NET code that is today written to run on servers, or as part of the tools being used to create games can now be easily be reused on the game itself.
Mainstream Tool Support: Many games engines are already being developed with Visual Studio. Game developers can use the same tools to develop and debug the high-level game play scripts that they use to develop and debug the game engine.

Luckily, developers that have been writing Lua code for years will be happy to know that they can compile their Lua code to run on Mono (and get the performance boost they need) by using the Lua2IL compiler.

Update: The always great Lua developers have pointed out that the new thing is not Lua2IL but LuaCLR.

Mono and XNA

Mono does not really attempt to compete with Microsoft XNA

Microsoft's XNA is an end-to-end solution for game developers that want to create games for Windows, the XBox and the Zune, the XNA approach is to write manage code on *top* of XNA.

This works for certain kinds of games, but in the game developer space, some developers need to support more than one console and the high-end games (am sure there is a technical terms for these) end up licensing game engines, audio engines, graphics and physics from all kinds of middleware vendors.

In those cases (even when targeting the XBox) C# and .NET would not be available to the game developer.

So we basically think of the Mono runtime merely as a fast scripting engine with all of the ECMA/ISO CLI benefits and not really as providers of gaming APIs.

There has been some discussion in the #mono channel recently about whether we would create or endorse a gaming API developed by a third party. Like blessing Tao or OpenTK as the standard way of building games for Mono.

Although there is some value in having a blessed set of libraries for Mono, and I have no problem if people want to call their libraries Mono.Gaming, at this point the team at Novell is not able to dedicate any cycles to this effort (we can provide spiritual support, along the lines of yelling "Go team! Go" from the sidelines).

Intrinsics and Parallel Code

Am personally fascinated by running computational code on the GPU or taking advantage of special CPU instructions at the runtime level. Last year I wrote a bit about how we could implement this in Mono (Microsoft has already an implementation) and later we even made it part of our interviewing process.

At the conference some people asked as to whether it would be possible to take advantage of the PlayStation3 six SPE processors. During the conference I had no idea that there was already a project using Mono on the PS3 with Linux that already does this, but the idea sounded fascinating.

It is particularly fascinating because the SPEs on the PS3 do not have the same limitations than GPU computations have, these are full blown CPUs (with some memory limitations) but still general purpose computation devices.

Paolo pointed me to CellDotNet: A project to make it possible to run .NET code on the Cell architecture.. CellDotNet is basically a JIT compiler (written in entirely in C#) that can compile CIL bytecodes into native code for the PS3 SPE processors (this is a project from Klaus Hansen and Rasmus Halland).

They have ported the SciMark benchmark to use some vector operations in the SPE. Currently I am unable to report the numbers as I do not have a PS3 running Linux, but I am expensing a PS3 as we speak to be able to report these back to you dear readers.

What makes CellDotNet all the more interesting is combining C# new functional features with the the Parallel Extensions to .NET.

Two good articles to get a grasp on what this offers are: Optimize Managed Code For Multi-Core Machines and Parallel LINQ: Running Queries On Multi-Core Processors.

PLINQ is built on top of the Language Integrated Query (LINQ), and although it has been promoted mostly as a technology to do database queries, the Parallel LINQ extensions basically supports map/reduce inside C#.

These libraries are only available as a technology preview currently for .NET and they do not exist yet for Mono. Hopefully we will get these implemented at some point.

[1] Our contract with said major publisher does not allow me to disclose who they are or the the game they develop on my blog. But it allows Novell to publish the information on the Novell site. After a year of asking Novell people to put this information on the web site, the information has not yet been posted. So the mystery as to what this is will sadly continue.

Lang.NET talks available

Miguel de Icaza (miguel@gnome.org) — Mon, 25 Feb 2008 04:32:00 GMT

The Lang.NET 2008 talks have been published.

They require Silverlight 1.0, but Moonlight compiled from source with ffmpeg support is able to play those presentations back.

If you are in a rush, see the following post for details on downloading the WMV file (so you do not need to install Moonlight from source on Linux).

Mono Hackweek Summary

Miguel de Icaza (miguel@gnome.org) — Sat, 23 Feb 2008 19:39:00 GMT

Some of the Mono folks have blogged about their work for last week hack-week:

Paolo and Zoltan rearchitected the Regular expression library in Mono and got a 9x performance improvement in regular expression matching. The work had two components: redesign of the opcodes in the regular expression engine, and generating native code using Reflection.Emit. At least for the Language Shootout case, the new regular expression code is the second best (Tcl is faster, but apparently Tcl does not cope with Unicode regexes).

Wade worked on MythTV under XGL and making Tomboy Scale.

Andrew added Zeroconf/Bonjour support to Giver (a tool used to easily share files with friends or nearby users). And he also worked on Tasky a simple task management tool that integrates with Remember the Milk. He also wrote a command line tool to remotely control Tomboy. screencast.

Mike added support to importing data to his Exert Project (fitness/workout log software) that he started last Hack Week.

Sebastien revamped and added various new rules to Gendarme, our analyzer for CLI assemblies to spot errors and common programming mistakes.

He also improved its APIs and performance. He also started to fix some bugs in our class libraries based on the analysis done by Gendarme.

Jonathan ported his XMPP/VB.NET client to Mono:

And also got MonoDevelop running natively on Windows:

Jonathan Pryor spent the week polishing various loose ends. Including the release of his fantastic NDesk.GetOptions command-line parsing library and providing documentation to various components in Mono.

Atsushi worked on the implementation of WebHttpBinding (part of 3.5 WCF) and various other parts. See his blog for details.

Mark polished his MathMap composer tool.

Marek did some work towards replacing System.Reflection.Emit with Cecil. After some discussion we believe we can keep both backends, one to keep things as usual, and another to be used with MonoDevelop (so MCS provides the actual parsing for the editor intellisense and compile-as-you-type support).

Jackson worked on a couple of interesting demonstrations with Aaron, which hopefully they will be able to demo soon.

Carlos spent his time improving System.IO.Serial, there were a handful of events not implemented that he worked on.

Andreia and Marek worked on a Gtk# native client for Bugzilla.

Stephane created a new Gtk.Print/Cairo dialog for F-Spot and worked on support for TimeZones in F-Spot (code has not been commited yet).

Everaldo worked on packaging Mono for Maemo4. He has promised a number of blog posts detailing the work on GarMono, and the new packages that will be included on it.

Rolf continued to replace SRE with Cecil in the VB.NET compiler.

Lluis worked on improving Mono.Addins and creating an add-in for authoring add-ins in MonoDevelop.

Paolo early on also extended C# to allow inline-IL assembly language code (similar to __asm__ in C or C++ in some compilers). See the blog post for the various samples of C# with embedded IL.

Chris worked on a scheme compiler.

Jeff learned more about Regular Expressions than he wanted to. Update: Jeff wrote an add-in for MonoDevelop to do Evolution plugins in C#.

Update: I had not finished reading all the status reports on the mailing list. Dick Porter wrote bluetooth support for F-Spot. There is a bug in the system underlying bluetooth C libraries that prevents it from working correctly out of the box, but hopefully that will get fixed.

Update: Mike Krueger improved extensively the search functionality in MonoDevelop, it now implements Emacs/Mozilla-like searching and he also wrote an assembly browser/decompiler that is plugged right into the solution browser.

As for me, I spent the week going insane over the incredibly frustrating T61p problems with performance. Inspired by Marek's encouragement to learn LINQ and functional-style programming, I started a project that I abandoned quickly to implement a managed spreadsheet.

At least I learned two lessons: am more comfortable writing tokenizers using the regular call-back system than the automatically generated state machine from generators. I also learned that OOXML is very easy to parse, but it would be nice for PDF files to have hyperlinks in the spec.

I am probably missing a few things, but I did not catch all the blog posts this week.