Mono Brainshare Presentations

Thanks to Pedro Santos I got a full list of the Mono Brainshare PPT files:

• Introducing Mono for Developers [ppt];
• Advanced Mono Development: Best Practices [ppt];
• Mono: Developing and Deploying .NET Applications for Linux [ppt];
• Mono: Rapid GUI Application Development on Linux [ppt];
• Developing ASP .NET on Linux with Mono - ainda n�o h� o ppt dispon�vel
• Using Mono to Develop the Next Version of Novell iFolder [ppt];
• Developing with the System.DirectoryServices Namespace API for Mono [ppt].

Notice that the slides that Erik and myself used were slightly different than those that we published for the event, as we continue the long tradition of `Redo your presentation the night before'.

On Novell and Toolkits

Nat just posted the official Novell position on the toolkits

I just posted this to Slashdot:

As Nat has posted elsewhere, the Heise article is wrong.

My team and other teams within Novell continue to develop and use Gtk as their toolkit (recently open sourced Simias/iFolder for instance) and all of the Mono GUI development tools.

The only use of Qt that am aware of today is SUSE's recently open sourced YAST.

Btw, if you have been following my posts on my blog and on the desktop-devel-list, you will know that my feeling is that all of the existing toolkits today (Gtk, Qt, XUL and VCL) will become obsolete and we need to start looking at the next generation toolkit system.

Next Generation Toolkits

One of the interesting aspects of Avalon is that they built the widget set on the equivalent of Gnome's AA canvas. Canvas and Canvas items. They call them `FrameworkElements', but it is the same model: once you "paint" something, it stays there (link)

Nautilus had a branch that had some more advanced canvas items than the ones we ship in libgnomecanvas: Andy had written some canvas items that rendered tiny visualizations of a web page, so "web page" links would update live.

Novell LDAP for Mono

Sunil has an amazing tutorial on using the Novell.LDAP library for Mono. To find, go here and search for "DirectoryServices" on the Title. Sorry, the direct link fails.

IronPython: Paper

Jim's paper on IronPython is out, where Jim shows that loosely typed scripting languages can take advantage of the CLR to outperform their interpreter implementations.

My plan was to write a short pithy article called, "Why .NET is a terrible platform for dynamic languages".

Unfortunately, as I carried out my experiments I found the CLR to be a surprisingly good target for dynamic languages, or at least for the highly dynamic specific case of Python. This was unfortunate because it meant that instead of writing a short pithy paper I had to build a full Python implementation for this new platform to see if there would be any hidden traps along the way. Because performance is such a dominant question for Python on the CLR, the rest of this paper focuses entirely on performance issues and measurements.

MonoDevelop: Software Building Architecture: (Article Permalink)

This document is the result of various discussions with Mono and MonoDevelop users on their needs to build, package and distribute their software by using Mono Develop.

I will update this as the discussion evolves on the mailing list.

Considerations

Not all software projects handled by MonoDevelop are equal, there is a range of options that must be taken into consideration:

• Web Services.
• Web Applications (.aspx/.ashx).
• ECMA Console and GUI applications.
• C libraries (typically glue).
• Compilation of different languages.
• Execution-specific environments.

In addition to the above, certain applications must probe for specific features on the target system where the software is to be deployed (C libraries most of the time) or conditionally use one or more assemblies at build time. Only a minority of applications will require this.

We want applications to be self contained, so running an application within MonoDevelop will not cause a full make/make install process to be triggered before it can be executed.

Instead, applications should run from any directory being invoked, and should pull any data files that they require using relative paths to the executable path. Most of the time this is not an issue, since data files can be embedded into the executable as resource files (images, icons, glade, xml resources are common ones).

This is necessary so when a user runs an application in MonoDevelop, MonoDevelop only needs to trigger the compilation and running of the program on its current path for it to be functional.

Output

The master file remains the "cbmx" Combine file. All the information is kept there, and auxiliary files are only generated to allow people to deploy applications without requiring MonoDevelop to be installed.

The generated output from the new build system should be a hand generated configure script that will probe system features and generate Makefiles to compile, install and remove a piece of software.

Probing for optional configuration options will be done using pkg-config

Autoconf and automake are to be avoided for the traditional C# targets, as these systems are better suited for C and C++ development and have their own sets of portability and dependency problems.

Compilation

The build should be driven by make in all cases. The current infrastructure should be modified to generate the makefiles for the current project before each compilation, and two targets can provide all the needed features: all builds the software, and run would run the execution script for this program.

This means that instead of calling the compiler with a response file that we have hand-crafted, we should produce the Makefile for it that contains everything we need it to build.

The response file can still be used internally by the Makefile to work around possible command-size limitations in Unix, so something like:

Execution Scripts

Mono programs typically include a wrapper script to invoke them, like this:

	#!/bin/sh
	/usr/bin/mono /usr/bin/program.exe $*
	

In certain Linux systems it is possible to have the kernel invoke program.exe directly, but this is a feature only available on certain kernels, not necessarily available to users without root access, and it is definitely not available on the other platforms that Mono supports.

Compiled executables for Mono will contain the above shell script to invoke the program. In addition, the shell script could be used to set an LD_LIBRARY_PATH for glue/helper libraries.

Probing System Features

Our runtime and class libraries can isolate us from many system specific dependencies but there are still some features that we might want to support conditionally.

For the sake of having a binary that works on every platform out of the box without recompilation, it is sometimes preferable to delay until runtime conditional features like this. Although this might not always be possible.

There are two places where probing takes place:

• During development, from the IDE.
• At deployment time, possibly without the IDE.

Today we should use pkg-config to do the heavy lifting in terms of probing for existing libraries: a dialog box can be used to define a library, dependencies and possible the conditional build definitions that are needed.

Probing of low-level Unix features in a way that integrates with the IDE has not been yet studied, but I feel that these must be done in a case-by-case basis: Library probing, method probing, or maybe even adding a hook to insert some shell scripts to do the work.

The probing would be generated into a configure file and would update a configuration file (ProjectConfig.cs for C# code, and ProjectConfig.h for C code). The same files that MonoDevelop would maintain from the IDE, these files basically contain:

Web Building

During development, when the user requests to run a web page, or a web service should probe for an available port, launch XSP on that port and finally start a web browser pointing to that address.

The only trick is catching when the web browser has been closed so we can return MonoDevelop to the "development" mode and shut down the XSP server.

We could just plainly ignore this and just trigger the execution.

Java and Mono

We should add a profile for developing using Java targetting the CLI. This would take care of creating the jar files from the referenced assemblies, use the system javac compiler and invoke Mono with IKVM with the proper arguments.

This should bring into consideration the integration of existing JAR files into the IDE, and call IKVMC to build DLL files out of the system jar files.

Source Code Packaging

The generated makefiles should support a target to ship the source code, a feature that should also be available from MonoDevelop's IDE. This probably can be done as a the `dist' makefile targte.

Binary Packaging

Creation of an RPM spec file is a possibility, but RPMs are not portable to every platform. Maybe a zip file, or a compressed tar file are options.

Since the packages should allow to be hosted on any prefix location like MacOS applications, it might not be much of an issue.

Keynote at Brainshare

In a few more hours Erik and myself will be doing the Mono components of the Friday keynote at Novell's Brainshare event.

In spite of his race, that man is extremely valuable to me. He is not some random dingbat I found on the Strip.

You can watch the keynote live tomorrow at 9am MST or you can wait and get the archive.

We'd be fools not to ride this strange torpedo all the way to the end.

Gnome Users Conference in Spain

The Gnome Users in Spain (host of the largest Linux deployment today) are having the "GUADEC Hispana", their Gnome Users and Developers Conference for the Spanish speaking developers on the 21-23 of May in Almedralejo, Spain.

Novell Brainshare Announcements

Chris Stone just announced that Novell will be moving the whole company to OpenOffice by the end of the year, and to Linux on the desktop a year after (I did not see the graph clearly).

iFolder and Simias (A metadata-based file system, with built-in synchronization) have been Open Sourced as well, and you can check it out here. Simias is similar to Longhorn's WinFS and i tis built on Mono.

Nat just demoed the desktop, with iFolder/Simias to share and synchronize the data between a Windows machine and a Linux machine and demostrated the Groupwise support for Evolution and Gaim.

On Fragmentation, reply

Havoc, you are skipping over the fact that a viable compromise for the community is not a viable compromise for some products, and hence why you see some companies picking a particular technology as I described at length below.

The community can go XPCOM/PyGtk if they choose to (btw, same legal problems apply related to patents on COM ;-), but it is unlikely that the larger projects will pick on this.

You are right that a "wrapper" could encapsulate Longhorn. But I think it will be a useless effort.

No ISV will pick a layer on top of the Longhorn layer on Windows today or tomorrow: .NET is simple, easy to use as opposed to older APIs. ISVs will demand native support for them.

Perl and Python directly support COM and .NET APIs today for interop. Am sure others will agree that why wrap everything in Longhorn, when you can just use your favorite language interop to use those features?

As I said, I still believe that the "Open Source Desktop Components" is a better way of going, more than the "Linux-based Open Source Desktop".

Underestimating Longhorn: Also, we should not under-estimate Longhorn. This is not a traditional OS anymore. This is an OS, that exposes .NET APIs as well as plugin interfaces for classes at every layer of the stack: file system, synchronization, transactions, communications, presentation and a miriad things more. "Wrappers" will hardly cut it here.

Not surprisingly, I think that Mono is the best possible path for ISVs: it allows them to share plenty of code (not all of it if they are aiming at "perfect" integration) between the various platforms with a high-level programming language. With a runtime environment that will let developers take advantage of the APIs in the major market.

On Fragmentation

So the core of Havoc's thesis can be summed up as:

We need to avoid fragmentation as various Unix desktop companies pick up a platform to develop software.

Sun is a major Linux Desktop player that will never ship Mono, but is using Java. So we should use Java to avoid fragmentation.

Legal and technical details, while interesting topics, are not at the core of this debate.

Novell: At least from this side, there has not been a company mandate to pick Mono over Java for any projects. Individual teams and projects inside the company have picked up on its own merits: iFolder, F-Spot and a few other internal projects which are not public yet. Some other internal projects picked Java for their own efforts.

The community has picked up on Mono/Gtk for a few applications on its own as well, the Gnome Foundation had no saying on this.

In a few areas, we believe that we should use Mono, but avoiding a community splint is an important consideration to us. Our plans to adopt Mono on Evolution are on hold, as well as integrating Mono with OpenOffice (notice that OpenOffice already has hooks for .NET though).

Sun: I will just assume that Sun developers have enough experience, and visibility into Java, that to them it is a natural fit to pick Java for projects, and that there is some degree of company mandate to use it. Am assuming this based on the naming of their Java Desktop System.

Longhorn: Microosft jokes aside, an important consideration for some projects is the fact that Longhorn will be released, will get deployed and the OS APIs have switched from C/C++ to CLR-based API.

In the Longhorn world, APIs are no longer your C/C++ grandmother APIs. Every new API introduced for the operating system is built on top of .NET. If you want to take advantage of it, you must write .NET code.

Writing code in Java is nice for writing code that is portable and uses to the lowest common denominator. But living in this bubble is not an option on Windows.

So the rationale for using Mono in some cases internally has been the fact that in Longhorn, you will have to write code in C#. Even if we have to write different GUIs (like iFolder: it will have three implementations: Windows.Forms, Gtk# and in the future a Cocoa# based one), we still get to share a lot of the functionality below.

Maybe the community does not need this kind of functionality, but most ISVs will, and that I think is a pretty big setback for Java and its Java ways. To survive in the desktop ISV market, Java will have to break with the write-once-run-anywhere mantra, and deeply integrate with Longhorn's WinFX.

If I were Sun, I would be retargetting my JVM code generator on Windows to generate CIL and making sure they can use every single Longhorn API.

Who are we and what are we building?

I personally think that we should move away from the "Linux Desktop" view of the world, and more into the "Open Source Desktop and Components" (I first heard this idea from Nat a few months ago).

It may sound like a trivial difference, but it is not. As much as I love the Linux desktop, and as much as I love our tools, the most successful desktop components today are OpenOffice and Mozilla because of their cross-platform nature.

Windows NT, XP, MacOS X and Longhorn will be with us for a long time. The best possible outcome of open source will likely be a segmented market like 33/33/33 for the desktop market.

In my opinion Java, Swing, Gtk+ nor Qt address effectively portability to all these systems. And by that, I mean that you always end up with an alien application: either the look, or the integration into the platform is substandard.

Mozilla and Abi to a larger extent got this relatively close to right. The botttom line is: no technology today gives you transparent portability.

The best bet today is to share as much as possible on your "engine" and redo the OS integration components for each OS you support.

Forks

Today there is already a major fork on the road.

Audio/Video: Today we got Xine, GStreamer and Helix as platforms for doing audio/media playback with different angles on the problem and no clear way of uniting them any time soon. Not to mention all the different player-level components.

I would love to see a standardized C-based interface that every one of them exposed and allow people to pick one over the other. I for one am not excited about requiring 160 megs of GStreamer code on my machine to essentially play mp3s and CDs.

And having an interface for the above is probably more important than any amount of Gtk+, Java, C# or Python skin on top of it.

Office Suites: We got plenty to choose from here: OpenOffice (in my opinion the only contender for the next three years) and the two smaller open source solutions.

Still, when it comes to engaging the community and pushing in a single direction, we got half the Gnome community pushing for Gnumeric/Abiword. If we can not reach concensus at this level with the community, I think we are going to have a hard problem selling anyone into agreeing into Java or C#.

Ok, gotta catch a plane.

Paolo's follow up

For those keeping up with the language debate in Planet.Gnome, am linking to Paolo's excellent second follow up on the subject. Paolo is not yet aggregated in Planet.Gnome.

Paolo touches on why the ECMA CLI VM is a better VM to pick and describes his gives his view on the patent risks.

Preparing for Brainshare

Am getting ready to attend the Novell Brainshare conference in Salt Lake City this coming week. This trip agenda is pretty packed.

Am doing two presentations on Advanced Development with Mono as well as attending plenty of meetings with users, customers and reporters. Am looking forward to demostrate some of the latest developments in Mono and MonoDevelop

Sadly, we are not bringing our SPARC to the show to demostrate it, as it is kind of heavy ;-).

Am doing a talk at a local users group, but I can not find the e-mail with the information for my presentation, so if you know what it is, please mail me the information.

Latest Mono Develop

Installed the latest MonoDevelop from CVS. It now comes with integrated Mono Documentation (from MonoDoc) and the Mono Debugger.

New Planet

Discovered Blogs at MSDN, fascinating stuff on all things .NET related. For those interested in tracking Avalon and XAML, you also should check out Longhorn Blogs.

Java, Gtk and Mono

If you see this from Planet Gnome, you might want to read the rest from the source since it keeps the nice CSS.

Java, Gtk and Mono: (Article Permalink)

So today I figured it would be an interesting excercise to write a small Gtk# application with Java. To do this, I used IKVM the Java VM implementation that runs on top of .NET and Mono.

There are two possible ways of using IKVM: one is to use it as a Just-in-Time compiler which translates the Java bytecodes into .NET Intermediate Language as it goes. But this means that at runtime you are compiling things twice: the Java-to-CIL JIT and the CIL-to-Native JIT.

Gtk# is really a bad name. Because Gtk# is not limited to C#, any programming language in the .NET framework can use it today and because it covers more than only the Gtk API, it covers various other components of the GNOME Development Platform.

Getting Started

First, you need to get your hands on Mono and Gtk#, you can get these from Mono Download page and Gtk# from their sourceforge page, or if you are lazy like I am, you use the packages on Red Carpet.

The next step is to download IKVM.

Exposing .NET Libraries to Java

Now, Gtk# is a .NET assembly (this is the ECMA lingo for "library"), and Java does not know anything about this. It is necessary first to generate some stubs for these classes to let the Java compiler knows about the types defined in the C# world. This is done using the netexp.exe program from IKVM, like this:

    $ mono netexp.exe /mono/lib/mscorlib.dll
    $ mono netexp.exe /mono/lib/gtk-sharp.dll
    $ mono netexp.exe /mono/lib/glib-sharp.dll
    $ mono netexp.exe /mono/lib/atk-sharp.dll

The above commands basically "imports" all of the types and their definitions into something suitable for Java to consume, the result is:

    $ ls *.jar
    atk-sharp.jar  glib-sharp.jar  gtk-sharp.jar  mscorlib.jar

The netexp.exe program will import all of the types into the "cli" namespace. So if you had a class called "Gtk.Window", it will be exposed to Java as "cli.Gtk.Window".

Compiling our program

So I begun with a small Java program, I had to Google for Hello World, since I did not remember much of Java, and I have to say, I am still not comfortable with the classpath thing. Anyways here is my sample little program:

import cli.Gtk.*;
public class Demo {
	public static void main(String[] args) {
		Application.Init ();
		Application.Run ();
	}
}

To compile the above program type:

    $ javac -classpath gtk-sharp.jar Demo.java

This produces a Demo.class file that contains the Java bytecodes. The -classpath file instructs the Java compiler to find the type definitions on the gtk-sharp.jar file that we had previously produced with netexp.exe.

Running our Java code in Mono

Now, it is not possible to run this directly in Java, since the jar files produced by netexp.exe are only stubs, so we will need to run this in the Mono world using IKVM in JIT mode:

    $ mono ikvm.exe -classpath .:gtk-sharp.jar Demo

The above just sits there waiting for events, so feel free to kill that. We will now add some meat to the program, this is a slightly more interesting sample:

import cli.Gtk.*;
import cli.GLib.*;

public class Demo {
	public static void main(String[] args) {
		Application.Init ();
		Window w = new Window ("Hello Mono with Java#");
		Button b = new Button ("Click me");
		w.Add (b);
		w.ShowAll ();
		Application.Run ();
	}
}

To compile, you will need to reference the libraries we created before:

    $ javac -classpath 'gtk-sharp.jar:glib-sharp.jar:atk-sharp.jar:
    mscorlib.jar:.' Demo.java

This will produce Demo.class, now run it:

    $ mono ikvm.exe -classpath .:gtk-sharp.jar Demo

The result is shown here:

The above is basically translating Demo.class from JVM bytecodes to ECMA CIL, then the Mono JIT translates that into native x86 code. The next step is to precompile the Java code directly into .NET code, which will skip the double JIT process:

    $ mono ikvmc.exe -reference:`pwd`/classpath.dll Demo.class \
      gtk-sharp.jar
    $ ls *exe
    Demo.exe
    $

The above compiled the code directly into a a Mono/.NET executable, to run it, just do:

    $ mono Demo.exe

Compiling Java code to x86 code

But we can go one step further. We can avoid completely the JIT process by precompiling the .exe file which contains instructions in the ECMA Common Intermediate Language into native x86 code using Mono's Ahead-of-Time compiler, to do this, type:

    $ mono --aot Demo.exe
    $ ls Demo.*
    Demo.class  Demo.dll  Demo.exe  Demo.exe.so

The Demo.exe.so contains the native x86 code. Mono still requires the Demo.exe file to be around to extract metadata, but the Just-in-Time compiler will not be used in that case:

    $ mono Demo.exe

Mono detects the shared object file and resolves methods to those contained in the image file. You can see the native code generated by using the objdump command:

    $ objdump -d Demo.exe.so
    ...
    

Caveat: in some versions of IKVM references to System.IntPtr are turned into gnu.classpath.RawData, and your program might not compile in the javac, to fix this problem do:

    $ echo "package gnu.classpath;" > RawData.java
    $ echo "public class RawData {}" >> RawData.java
    $ javac RawData.java
    $ mkdir -p gnu/classpath
    $ mv RawData.class gnu/classpath

How complete is Mono/IKVM?

Mono and IKVM depend on the GNU Classpath, so it is as complete as open source Java, but you get the added advantage of accessing any Mono/.NET libraries as well.

Today Mono/IKVM can run large applications like Eclipse, Jython and JBoss. Screenshot of Eclipse running on Mono.

Patent issues in the software industry

On Software Patents: (Article Permalink)

I was asked to post this on my blog, a copy of a post from the mono mailing list. This is slightly edited from the original:

The fear that people have on Mono's legal issues apply equally as well
to everything else.  Let me explain.

Sun owns various patents on Java, and they might just feel at some
point threatened enough to use them as a weapon against open source. 
In the same way people feel that Microsoft might pull that trigger.

Just to put things into a different perspective: Sun has litigated over
Java in the past (against Microsoft) over a contractual dispute and has
done threatening legal moves against JBoss at some point (which I do
not claim to understand) over bits of J2EE.

If Java on Linux became a threat to Sun, would they use their patents? 
I do not know, and I hope not.  Am only illustrating the point, just
like other people have vehemently illustrated the Microsoft patent risk
before.  

There is nothing in Java that makes it any safer than Mono at this
point.  We do not have any guarantees, any written statements, any
guarantees that Java on Linux will not be sued under certain
conditions.

Microsoft has granted RAND+Royalty Free licenses to any patents they
might own that are required to implement the ECMA 334/335 standards. 
So at least our core VM, classes and compilers are safe from any
litigation from *Microsoft*.  

Now, pay attention to the above, because it is important.

The fact that Microsoft has given access to any patents they might hold
on .NET does not mean that a third party that has a patent that is
required to implement ECMA (or Java) will grant that license.

Why does this matter?  Because we just do not know if someone has a
patent on pieces that Java and .NET implement.  There might very well
be one that we are not aware of.  The patent might remain sleeping for
a few years before someone decides to profit from it.

And the above is important.  It is important because even with a fully
re-engineered virtual machine, runtime system and the rest, we do not
know if you will not be infringing on a Sun, Microsoft or third party
patent.

With the current patent situation, it is probably impossible to ask
small startups or individual developers to do a patent review before
they make decisions on how to implement their software, only very large
companies might afford it, and believe me, even with vast resources,
you might be taken to court by an unknown (Eolas patent for example) or
by a law firm who focuses on purchasing dormant patents and litigate
them.

Nat used to say "If you write a thousand lines of code, you are
violating someone's patent today".  

The picture is not pretty for anyone in the software industry.  

But this is similar to what happens to biology students: on their first
four semesters as they learn about all the dangers, infections, vectors
for infections and bacteria, they stop eating everything, they start
washing their hands with special products, they double clean their
utensils, they wash their fruits ten times a day.

Two years later they are eating food with their bare hands again. 

Paolo on Havoc's thoughts

Paolo has written some follow up comments to Havoc's language advocacy post today.

Iraq on the Record

A report on the 237 missleading statements made by the Bush Administration on the threat possed by Iraq is now available from the House of Representatives Web Site, it includes a nice PDF with the report and graphics and a searchable database.

Mono with SPARC/Solaris support

Last night Zoltan Varga checked-in his last patches that complete the Mono JIT port to the SPARC (with Solaris). The system passes all of our regression tests, and bootstraps Mono from scratch.

We had support for SPARC v8 and v9 as an interpreter, and some early work had been started by Mark last year. Zoltan picked up on the job on the first week of February and got the port done in marginally more than a month.

With three JIT ports now (1 CISC, 2 RISC), most of the portability issues on the JIT must have been taken care of.

Edd on the Mono Meeting

Edd has written a fantastic article on the Mono Meeting. The Slashdot peanut gallery has initiated a flame-fest over the comment that to me C is dead.

Gnome Notifier

The Gnome Notifier is definitely not a production system, it is a toy that illustrates a simple way of sending notifications to the system (some other people have discussed this before. Ideally a more complete system would have a history mechanism, and a way of browsing/answering previous messages.

For example, the most annoying problem I have with GAIM (My Instant Messenger in GNOME) is that whenever there is an interaction (you got disconnected from a remote site, or someone added you to their buddy list) a pop-up window shows up. This pop-up window shows up in the middle of your typing and grabs the focus. If you are writing code, writing an e-mail or doing any other form of typing, you are likely going to accept whatever is the default button by mistake, as you press the spacebar. Not to mention that you will have to re-type a few letters.

What I would like is for someone to integrate that into the Panel in some form, patch Gaim and all the other offenders, and have a way of getting back all the pending notifications.

I believe strongly that the Gnome Human Interface Guidelines should incorporate notification patterns and practies in their document, the following comes from the UI talk at the Microsoft PDC where there is a nice classification of user interaction:

Spectrum of Interaction Possibilities, from the PDC

Our hearts with the people from Madrid

Very sad news this morning; An outrageous attack on Madrid. Speechless.

Gnome Notifier

This is a quick hack that I put together in December 2002, a small notifier that looks like the Windows XP notifier with a nice little scrolling thingie. Someone asked me today about this hack, so am uploading it here.

The notifier embeds HTML with a few small tags that get displayed.

The nice trick back then was that you can send notifications to it by changing a Gconf key. You can then send notifications using the gconf api from your favorite language or from the command line language.

To use it today, do:

$ gnome-notifier &

Then to do notifications, you call a command line tool:

It supports a cute little prefix "run:", which does the obvious:

notify is just a shell script that calls gconftool.

Ideally this would be incorporated in some form into the panel, and with a history mechanism, you could use that to replace things like Gaim's annoying notifications.

XAML

So someone has implemented a XAML-like stack for Windows.Forms. Just to be clear on the danger of XAML for the Linux desktop: it is not about the markup language being a problem: its about the fact that XAML developers would create XAML applications that are bound to the Avalon toolkit.

So it comes down to: No Avalon, no app.

Mono CAS configuration tool

Benjamin Wootton has been working on Mono's Code Access Security (CAS) support. CAS is a way of creating arbitrary "sandboxes" in the .NET environment. The idea here is to load and execute untrusted side-by-side with your trusted code code without compromising your application. Similar in spirit to Java's security model.

CAS is needed for the various "click-once" setups for downloading, running and updating applications over the web, but more advanced uses enable scenarios like running untrusted plugins in a trusted application (for instance, a file format importer downloaded from the network, or plugins for your application which you do not necessarily want to trust).

You can read his list of requirements here; The project status page (with all his patches to add CAS to Mono) and a screenshot of his Mono CAS Configuration tool.

Anonymous Methods in Mono's C# compiler

I have been working on anonymous method support for the compiler in stages. My latest patch for the curious lives here.

The first one was to implement the implicit method group conversions to delegates, that one allows you to write things like:

void Method ()
{
	button.Clicked += clicked_handler;
	...
}
void clicked_handler ()
{
}

The second stage was to handle anonymous method declarations inline, and move the body of the code into an helper method in a chunk like this:

void Method ()
{
	button.Clicked += delegate {
		Console.WriteLine ("hello");
	}
}

Until that point things were relatively simple, the next step was a lot more tricky, and it involved capturing local variables:

void Method ()
{
	int i = 0;
	
	button.Clicked += delegate {
		Console.WriteLine (i);
	}
}

The above code needs to be compiled into something like:

void Method ()
{
	Locals1 __locals = new Locals1 ();
	locals1.i = 0;
	button.Clicked += locals1.__AnonymousMethod1;
}

class Locals1 {
	int i;
	
	void _AnonymousMethod ()
	{
		Console.WriteLine (i);
	}
}

Things get more complicated when you add multiple levels of scopes to variables:

void Method ()
{
	for (int i = 0; i < 10; i++){
		int j = 0;
		button.Clicked += delegate {
			Console.WriteLine (i + j);
		}
		int z = i + j;
	}
}

The above needs to generate roughly this:

void Method ()
{
	Local1 locals1 = new Locals1 ();
	locals1.i = i;
	
	for (int i = 0; i < 10; i++){
		Locals2 locals2 = new Locals2 ();
		locals2.locals1 = locals1;
		locals2.j = 0;
		
		button.Clicked += locals2.AnonymousMethod1;
		z = locals2.locals1.i + locals2.j;
	}
}

class Locals1 {
	int i;
}

class Locals2 {
	Locals1 locals1;
	int j;

	void AnonymousMethod ()
	{
		Console.WriteLine (locals1.i, j);		
	}
}

So fairly tricky: the variable can be accessed from the method containing the anonymous method.

One of the trickiest parts is the process that guesses the return value for the anonymous method: it might seem like inference is at work, but in fact during the resolution process we know the type we requiere, so the compiler triggers the resolution of the inner block when it gets this information.

Another complex bit was that the resolution/emit phases of the compiler had to be completely decoupled (they were already partially decoupled) because it is necessary to identify any variables that might be captured before we can even generate the first line of the block.

The patch is my work-in-progress code, it can not be checked into CVS just yet, since it breaks the iterator support in the compiler, so that must be fixed first.

First Mono Summit

I need to finish my write up and post the pictures of the event, but that will come later ;-)

My two cents

Mono hackers in Boston

This week the Mono Novell hackers have met for the first time in Boston, and we have been discussing the various tasks that need to be completed for Mono 1.0 and 1.2. IRC has been relatively quiet, and the exchange of ideas and discussions in town have been great.

The good news: we are on schedule for the 1.0 release, with a very nice cushion to test things. The only areas that are going to be very close to the deadline are System.Data and System.Drawing.

We got a few folks explain their areas of work to the others (so far I attended the meetings on security, remoting and the debugging session).

Duncan has been leading the release engineering meetings and laying down a process for the ongoing builds, and the 1.0 release packages.

Martin, Mike, Todd and Daniel are busy working on a small surprise for MonoDevelop, that they are hoping to demostrate on the open house this Friday/Saturday.

Windows.Forms is alive again! Peter Bartok demostrated various applications working with the new Wine, and together with Jordi Mas, they are resolving the various rendering integration issues between Libgdiplus (cairo) and WineLib (Wine turned into a library).

XAML

I read with interest Edd's thoughts on XAML and a new UI for GNOME. I have been doing some small XAML tests recently, and it is a very easy markup to generate. As I mentioned before the issue with XAML is that it will be very attractive to developers to move from HTML to XAML, as it provides more control, more widgetry and is an extensible system.

The future of Linux on the desktop is in fact on the line: if enterprise developers and IT developers fall in love with Xaml for building their in-house applications it will marginalize again Linux on the desktop.

There are two views of how to solve this problem. The Nat Friedman view of building a matching system in the meantime: leveraging our existing technologies, or the Miggy-view, which is lets implement the Avalon/XAML API. I think we should pursue both paths.