More Microsoft Open Source

by Miguel de Icaza

A parser and scanner for VB.NET has been released by Microsoft. It is written in VB.

Manufacturing the Facts.

Kuwait Times: "U.S truck carrying radioactive material caught in Kuwait".

Tehran Times: "The MNA reported for the first time the coalition forces suspicious transfer of WMD parts from Kuwait to Southern Iraq by trucks."

Update: Someone researched this in depth here, and apparently the trucks were coming *out*, not in.

Posted on 16 Jun 2004

Cocoa Sharp

by Miguel de Icaza

The Cocoa# developers got their first window showing on the MacOS X, and they also got inheritance working. This is a young binding, but here is a screenshot of what it looks like:

Cocoa# sample application.

Posted on 15 Jun 2004

Web Page Thumbails Sharp!

by Miguel de Icaza

Ross improved on a script from Matt to do web page thumbnails.

Here is the same written C#, Gtk# and Gecko#.

using System;
using Gtk;
using Gecko;

class X {
	static WebControl wc;
	static string output = "shot.png";
	static string url;
	static int width = -1;
	static int height = -1;
	static void Main (string [] args)
		for (int i = 0; i < args.Length; i++){
			switch (args [i]){
			case "-width":
				try {
					width = Int32.Parse (args [i]);
				} catch {
					Console.WriteLine ("-width requires an numeric argument");
			case "-height":
				try {
					height = Int32.Parse (args [i]);
				} catch {
					Console.WriteLine ("-height requires an numeric argument");
			case "-help":
			case "-h":
				Help ();
				if (url == null)
					url = args [i];
				else if (output == null)
					output = args [i];
					Help ();

		Window w = new Window ("test");
		wc = new WebControl ();
		wc.LoadUrl (args [0]);
		wc.NetStop += MakeShot;
		wc.Show ();
		wc.SetSizeRequest (1024, 768);
		w.Add (wc);
		w.ShowAll ();

	static void Help ()
		Console.WriteLine ("Usage is: shot [-width N] [-height N] url [shot]");
		Environment.Exit (0);
	static void MakeShot (object sender, EventArgs a)
		Gdk.Window win = wc.GdkWindow;
		int iwidth = wc.Allocation.Width;
		int iheight = wc.Allocation.Height;
		Gdk.Pixbuf p = new Gdk.Pixbuf (Gdk.Colorspace.Rgb, false, 8, iwidth, iheight);
		Gdk.Pixbuf scaled;
		p.GetFromDrawable (win, win.Colormap, 0, 0, 0, 0, iwidth, iheight);
		if (width == -1){
			if (height == -1)
				scaled = p;
				scaled = p.ScaleSimple (height * iwidth / iheight, height, Gdk.InterpType.Hyper);
		} else {
			if (height == -1)
				scaled = p.ScaleSimple (width, width * iheight / iwidth, Gdk.InterpType.Hyper);
				scaled = p.ScaleSimple (width, height, Gdk.InterpType.Hyper);
		scaled.Savev (output, "png", null, null); 
		Application.Quit (); 

Posted on 14 Jun 2004

On .NET and portability

by Miguel de Icaza

Jeff posted on portability of Java vs .NET code in an article.

First lets state the obvious: you can write portable code with C# and .NET (duh). Our C# compiler uses plenty of .NET APIs and works just fine across Linux, Solaris, MacOS and Windows. Scott also pointed to nGallery 1.6.1 Mono-compliance post which has some nice portability rules.

Porting an application from the real .NET to Mono is a relatively simple exercise in most cases (path separators and filename casing). A situation that I would like to fix on upcoming versions of Mono to simplify the porting (with some kind of configuration flag).

It is also a matter of how much your application needs to integrate with the OS. Some applications needs this functionality, and some others do not.

If my choice is between a system that does not let me integrate with the OS easily or a system that does, I personally rather use the later and be responsible for any portability issues myself.

That being said, I personally love to write software that takes advantage of the native platform am on, specially on the desktop. I want to take advantage of what my desktop has to offer: Gtk# (when using Linux), Cairo, OpenGL, Cocoa# (when using the Mac), GConf, Gnome Printing, and access to Posix.

If my software uses all of the above libraries, will it be easily portable? Most likely not.

Consider what the iFolder team is doing: they are writing the core libraries as a cross platform reusable component. This component is called "Simias" and provides the basic synchronization and replication services. Simias works unchanged on Linux, MacOS, Windows and Solaris. Like every other cross platform software, it must be tested on each platform, and bugs on each platform must be debugged.

This is not different than doing any other kind of cross platform development.

Then they integrate with each operating system natively at the user interface level. Windows.Forms and COM on Windows; Gtk# on Linux and in the future Cocoa# on the Mac.

Although Gtk# looks and feels like Windows.Forms on Windows, the problem that they were facing is that Gtk# was an extra download for people using iFolder, and they chose to keep things simple for the end user.

Mono as a new Wine?

Although Jeff's post is fairly naive and not that interesting I do have a problem with his follow up: Mono is not just a `Wine-like' technology to emulate an API.

Mono is a complete development stack, with a standard core from ECMA and ISO. Jeff has obviously not written any code with Mono, or he would know that it is quite an enjoyable standalone development platform as oppposed to just a runtime.

Mono is also not limited to run the .NET code, thanks to IKVM: a Java VM written entirely in C# and .NET, we can run Java code just as well as .NET on the same virtual machine, and have them happily talking to each other.

Posted on 11 Jun 2004

Jeffrey in Boston

by Miguel de Icaza

Jeffrey McManus is in Boston this week.

Nat Interview

Another interview with Nat on the Novell Linux Strategy.

Nat and Dan in Bangalore.

Laura in Kona


Arturo's Laptop

Arturo is a modern day Indiana Jones, a resourceful humanist. On this picture with his laptop and portable 17" monitor, making up for a hard learned lesson: do not fight gravity with your notebook LCD screen.

Arturo and his C64-like TiBook.

Posted on 08 Jun 2004

On the Google IPO

by Miguel de Icaza

Mitch Kapor: "In a better world, would all public corporations be more accountable to their shareholders? Hell, yes. But today's shareholders are, in the main, no better than the vast majority of companies they invest in. They only really care about their financial upside, not the means by which it is achieved. Exploitation of labor here and abroad a la Wal-mart, environmental degradation, and massive corporate welfare through government subsidies and sweetheart deals a la Halliburton are perfectly acceptable sources of profit and make for perfectly good investments most say."

Summer movies: The Corporation and Farenheit 9/11

Trailers are now available on Rotten Tomatoes, and a list of dates in the US

Can not wait to see Michael Moore's new movie, opens on June 25th!

Venus Transit

Venus Transit on Tuesday.

Posted on 05 Jun 2004

MonoDevelop on MacOS

by Miguel de Icaza

With Mono Beta2 I was able to get MonoDevelop to work on my Mac.

You must get Mono Beta 2 (0.95), gtksourceview (0.7 Fink), Mozilla (Fink), GtkSourceView# (0.3), Gecko# 0.4 and MonoDevelop 0.4.

MonoDevelop on MacOS X

There are a few Linux-isms in there that you must fix, a quick workaround is to add the following to your $prefix/etc/mono/config file:

<dllmap dll="libgtk-win32-2.0-0.dll" target="libgtk-x11-2.0.0.dylib"/> <dllmap dll="gnomevfs-2" target="libgnomevfs-2.dylib"/> <dllmap dll="gdldock" target="libgdldock.dylib"/> <dllmap dll="libMonoPosixHelper" target="libMonoPosixHelper.dylib"/> <dllmap dll="" target="libgtk-x11-2.0.0.dylib"/> <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.0.dylib"/>

Then you must edit $prefix/lib/monodevelop/bin/gdl-sharp.config, this is what I have:

<configuration> <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.0.dylib"/> <dllmap dll="libgobject-2.0-0.dll" target=""/> <dllmap dll="libatk-1.0-0.dll" target=""/> <dllmap dll="libgtk-win32-2.0-0.dll" target=""/> </configuration>

You still need to use GDK_USE_XFT=0 from the command line.

Of course, the real fix is to get MonoDevelop to generate those files (and fix the few incorrect hardcoded references to x11), but I will let Todd do that.

InfoWorld Innovators!

I was named one of InfoWorld's 2004 innovators: here.


Maria in Rio.


Mauricio and Laura at the Metropolitan.

At the first day of the ECMA meeting in Hawaii.

Laura and Marcelo in March.

Posted on 31 May 2004

Al Gore remarks at NYU

by Miguel de Icaza

Al Gore's remarks at NYU..

Finkelstein in Toronto

video and audio.

Posted on 28 May 2004

Follow up

by Miguel de Icaza

Mark Pilgrim has a great follow up to his freedom-0 article.

Nemerle, C# and Anonymous Methods.

Spent some time this afternoon playing with Nemerle and their latest release.

Specially nice since now MonoDevelop supports Nemerle in the built-in editor.

My main problem is that I find it hard to think in any other way which is not the standard programming that I have grown up to do, maybe I need a hobby programming task to do. It will have to wait until we release Mono 1.0, right now things are busy.

My personal wish: I would like a C#-like scripting language myself. Sprinkle a few perlisms, rubyisms and pythonisms in there. Drop the class carcass.

A small patch I have been playing with in my copious spare time is one to turn all unresolved method calls in C# to a dynamic code translation. So basically:

  object a = new XmlDocument ();
  a.Load ("/tmp/a.xml");

ie, notice that the type of the variable is `o'. The downside: the runtime has to transform the incoming parameters to something that matches the call, you loose the compiler safety net, and its slower. But at least you can prototype quickly ;-)

I do not like the current implementation of anonymous methods, it really does not work in the presence of nested anonymous methods, so I have gone back to the drawing board and have now a new design for this internal chunk of the compiler that am a lot happier with. As soon as the beast compiles, I will upload a new patch.

The C# compiler also gained recently a new flag: -pkg:NAME which integrates pkg-config directly into the compiler. We are making the world a better place, one command line option a day.

Managed code is fast

Andreas, Ben and Paolo have been discussing moving existing code that we implement in C to the managed world, as our JIT is in some cases as good as the C compiler and the transition from managed to unmanaged is too costly: we can now move more code into the managed world.

The old gcc exceptions mechanism that the Mono JIT used for a long time to speedup calls into the unmanaged world is gone. It was too much of a support nightmare (gcc and libc would often be out of sync, rendering the optimization useless), and instead Zoltan has cooked up some ways to improve the transition cost on x86 and SPARC.


The PowerPC port got a big boost today with various fixes checked in from Paolo; Neale continues to update the S390 port and Zoltan has checked in some fixes to support Linux on the SPARC (in addition to Solaris).

We still need to support the Itanium and the x86-64 CPUs (if you have a good recommendation about a book on these platform, please mail me) as they are important platforms for SUSE.

Thread.Abort and File locking

Lluis completed this week the Thread.Abort implementation for Mono. Our old implementation had various issues if we aborted thread while we were in unmanaged code (since there was no way to clean things up). Lluis' new implementation now shuts down things properly.

Now this might seem like a problem that few people would run into, but the reality is that it happened a lot with people using ThreadPools, ASP.NET or WebRequests since all of them triggered a call to Thread.Abort, and the side effects were ugly: from assertions in the runtime, to hangs at program exit.

This fixes the last major reliability blocker problem we had for Mono 1.0.

Dick in the meantime implemented the locking functionality for Files, a feature that some people needed and that was not really there before.

Xslt Joshua and documentation

Joshua has checked in the tools to produce HTML out of Monodoc. Real men use Monodoc, but if you feel like giving up on your manhood, now you can browse uncompressed, not-as-beautiful, not-indexed classes ;-)

Marek. Martin. Raja

They are rapidly closing the last pending bugs in the MCS compiler, none of them are crucial, but we want to ship with as few bugs as possible in the compiler. At this point, we are no longer accepting large changes to the compiler (which also means that Anonymous Methods will just not make it into the 1.0 release, too bad, they were too cute).

Posted on 22 May 2004

More patents

by Miguel de Icaza

Seth has raised some valid points on the patent problem, as it related to Mono.

A big problem with everyone raising potential patent problems with Mono is not that they are wrong in any way, but there are a few problems with it:

  • Not using Mono in any shape or form is not a blank waiver against patents. That means that even if you choose to stick to your beloved C, Python, C++ or anything else, for any new software you write, you are likely to infringe on someone else's patents (or even the same ones that Mono could potentially infringe).
  • Patents can be: declared void with prior art showing that such invention did exist in the past. Alternatively, you can route around it by using a different technique than the one described in the patent to provide the same feature (or something close) to avoid infringing on a patent.
  • Most people have no idea of what a patent is, or how it works. The actual invention is the claims bit. Not the introduction, not the summary, not the background, not the references and not the drawings. They help in making the claims, but they are not the patent itself. If you want to play patent-lawyer on Internet, you should at least familiarize yourself with the process.

Now, it is hard to argue with the nay-sayers about routing around the patent for two reasons: we do not know what might be patented and valid (ie, no prior art can be found or properly articulated) and most importantly for any given topic we can engage in weeks of discussion on what-if scenarios.

We do not plan on infringing patents, and if were to infringe on patent, we will either find prior art that renders that particular claim invalid, or rewrite the code to work in a different form. We do not like software patents, but we will abide by the legal rules.

If you can not think of a different way of running a C# program than the one that exists today, you are not a very imaginative/innovative programmer. The worst possible scenario is not `They will stop distribution forever'. The worst possible scenario is `They can stop distribution until we find a workaround'.

And again, remember, the software patents problem is not limited to the specific instance of Mono. Everything Seth said applies equally well to every bit of our open source stack today: do we infringe on a Microsoft patent? Do *you* know for sure you do not? Have you performed a patent search? On every possible bit?

Red Hat has chosen to adopt Java (despite the same potential problems with patents) and has decided that it is in their interest not to use C#/Mono. Like Red Hat's Seth states: this is self inflicted damage on their part, and they will not be able to ship any of our leading edge GPL code (Simias, iFolder, F-Spot or any of our future development tools).

Red Hat could either stop whining, and have their developers work in Mono and use Mono, and help us fight bogus patents or route around them, or they can keep posting to their blogs more fear-mongering.

Andy Satori has posted his insight here.

If you are going to reply, I just ask you that you take a step back, and for every instance of the word `Mono' replace it with every major open source project today `gnu libc', `linux kernel', `Open Office', `samba', `x11', `cairo', `gtk+', `qt', `binutils', `gcc', gnome', `qt', `mozilla', `my favorite file system', use your imagination.

Does your foe have a patent to it? Or someone that can be acquired by your foe?

On Stop Energy: my policy

Most people operate in Stop Energy mode, so I typically ignore them, and keep moving.

A small story I like to tell people: when I started writing Gnumeric, I was very afraid of one thing: the computational engine. How do we recalculate the value of cells when a change happens? How do we make this perform well? How do we do iterative computations? How do you resolve recursive references?

All of those problems were fairly scary, and I did not have an answer to them. I looked at all the source code I could find for spreadsheets around that time, and none of it did even a remotely good job: it was all pretty amateur, and none of it really did anything remotely close to what commercial software did.

I started work on Gnumeric nonetheless, figuring `When the time comes, I will face that problem', and spent the next three months making sure that Gnumeric was visually pleasant, that it looked like Excel, and that the "feel" was right. I tried to implement computations trivially during that time in a couple hour hack and that failed miserably.

By the third month, I decided I would not touch a computer until I figured out an algorithm for doing these computations, I took a pencil and a notebook and went to write down the steps. Surprisingly after a few hours of work I had something that looked correct.

That same day I implemented the computational engine with the features I wanted and it just worked!

What I like about this story, is that I could have given up at any point since there was a large problem ahead of me: a problem I had no answers to. And I see this with many free software developers, students and even in normal social situations: people stop doing things because they see a big problem ahead of them that they can not possibly conceive working around. My advise to every young programmer is to start writing code and delay addressing imaginary problems until they become real.

I like people who find and propose solutions.

The Mono team (both the community and the Novell employees working on it) is pretty much such a group: a group solving problems, and moving forward.

Interview with a soldier

Ran into this interview this morning. From the Sacramento Bee.

Incidentally, watched For of War this week, McNamara at some point says `We need to win the hearts and minds of the Vietnamese people'.

Posted on 20 May 2004

« Newer entries | Older entries »