Expanding the Mono team.

by Miguel de Icaza

I am looking to hire a full-time developer to work on the Mono JIT engine. This would include working on the code generation engine of the JIT (so compiler experience, low-level programming experience is a plus), advanced optimizations for the compilation engine (various SSA-based optimizations, array-bounds check elimination, fast-call conventions, loop optimizations), debugging interfaces and would involve dealing with a garbage collected, multi-threaded runtime environment.

We are porting the Mono JIT to various platforms, so you would be learning new assembly languages, new ABIs and more. If you are interested, drop me an email at miguel@ximian.com

Posted on 14 Oct 2003

Problems on my machine

by Miguel de Icaza

I have been applying every one of those "Apply this patch immediately" updates that I have received on e-mail from support@microsoft.com, and my machine seems slower every time.

Update: I have received on last count 9 emails from people informing me that the above is a virus. Guys, it was a joke. Obviously I failed in my attempt to be funny.

Evolution and Mono

Chris Toshok today has been working on embedding Mono and Mono-based applications inside Evolution in their new UI branch.

Here is a screenshot embedding the Mono documentation browser in Evolution:

More Mono Bloggers

New mono bloggers, I think I should track them in in Monologue.

Posted on 13 Oct 2003

by Miguel de Icaza

Posted on 12 Oct 2003

Birthday Theme

by Miguel de Icaza

Some people have asked me about the theme for this year Birthday's present. This year theme is going to be `Nice and Expensive'. It is a repetition of an old-time favorite. But this year, lets try harder to stick to the theme.

Posted on 09 Oct 2003

Robert Fisk on the attack on Syria

by Miguel de Icaza

The article is here, and I had forgotten about the Syria Accountability Act that was making the news last year until I ran into Robert's article today.

Multi-threaded MonoLogue: Gonzalo has fixed all the runtime bugs

We modified the Monologue software to use multiple-threads to download the RSS feeds concurrently, and this exposed a couple of tricky bugs in the runtime and our DNS setup. Gonzalo was on a quest to track all of these problems down, and our abusive version of Monologue is now fully functional.

Now the major source of problems was not a Mono bug, but a dead-lock condition that was not obvious. Turns out that Monologue/threaded happened to fill the Threadpool queue (no surprises there: threadpool will just take care of things), but the Http code needed a thread from the pool to download things (the API is using the async version of this as well), and that caused a deadlock.

Posted on 07 Oct 2003

MonoLogue: Mono's aggregator is up and running

by Miguel de Icaza

Ben wrote an RSS aggregator that we are running now on http://www.go-mono.com/monologue to track the Mono blogs. You can now get all your Mono news in a single spot. This is similar in spirit to Jeff's Planet GNOME

If you are interested in running the aggregator in your machine for your own personal blog reading, just download the `monologue' module from our AnonCVS repository.

On RSS Aggregators

I have tried three kinds of RSS aggregators out there: desktop-based, mozilla-based and html-based. From my personal browsing experience I believe that the HTML-based aggregators are the best kind. Specially when we you are using Mozilla/Firebird with tab browsing.

There are plenty of desktop-based aggregators for both Windows and Linux (I tried them all in a quest for the perfect UI). The desktop-based aggregators typically embed a web browser in the browsing pane to render the news. And this is the source of most frustration with them.

The embedded HTML rendering engine has some very bizarre interaction glitches when you follow links, and you try to go back in history, or when you start following links inside the aggregator (which it is bound to happen).

Since it is not really possible to read comfortably the news inside the aggregator, you can either open a new window (uncomfortable) or hope that the aggregator can instruct your browser to open a new tab, but it is still annoying to use.

The obvious answer to the above problem is to put the aggregator inside the browser. Luckily Mozilla/Firebird have made plugin authoring a breeze, and there are a couple of options out there.

These aggregators today suffer from a problem shared by the desktop-based aggregators: they are based on the modern news-reading/mail-reading model. These present the user with a collection of folders with items old and new, and you read your feeds one by one. This model is ill-suited for blog reading because blogs do not produce large volumes of data per day, and you most likely want to read all the new things in the day at once. Not once per week, so the interaction model is basically to read a single post on each folder and move to the next one, and repeat this a number of times per day. Not very efficient.

The third kind, the one I like the most are the aggregators that generate an HTML page with the consolidated data. This in my opinion is the best model because you get to read HTML content on your main HTML browser and all the tools available on your browser are available to you and most important: there are no surprises on the behavior. Since it aggregates all the data at once, every time you visit it, you can get a snapshot of what is happening, rather than having to check 20 sources one by one.

Firebird users probably will like the last one the most, since its a feature packed browser, and with a rich set of extensions that make browsing more efficient. But in general any user of a tabbed-based browser will enjoy the later kind the most.

Escalation of Violence

Yesterday there was another suicide bombing in Israel. The reaction was an attack on an alleged terrorist training camp in Syria. Following the Bush doctrine of `destroy evidence first, cover-up with non-answers later'.

Been thinking this morning that it is time to write a Israeli-Palestine Conflict Primer. On second thought, maybe I should just strongly recommend reading John Pilger's Palestine Is Still The Issue an eight-parth documentary available online (wish they sold the video on DVD).

Edward Said passed away, his latest article and a tribute to his writing.

The Hamas group that has been striking at the civilian population was initially funded by Israel in the 70's to undermine the growing popularity of the PLO and Arafat. A policy that now has backfired. Some details here.

Posted on 05 Oct 2003

SouceGear is done!

by Miguel de Icaza

We completed the SouceGear project!

The project included adding a lot of functionality to Mono to support Web Services on the client (mostly having a full XmlSerializer implementation as well as its close family members) and making Mono robust.

To make sure that Mono was robust, SourceGear designed a series of extensive tests that Mono would be put under, and the acceptance criteria for the work we did included running the tests for a 24 hour period of time on a single instance of the virtual machine. Needless to say, making the Mono VM robust enough to run these tests for 24 hours was not easy, and we ran into all sorts of low-level interesting features, memory leaks, race conditions and other assorted small problems that would not have shown under normal circumstances. We are very happy about this.

In the meantime, while parts of the team were tracking down the elusive bugs in the runtime, Lluis took the time to implement the server side component of ASP.NET, so as part of the SourceGear effort, we also got our web services stack implement on the server, which was a nice plus.

More on exceptions

I was feeling that I should argue a bit more about exceptions, until I received a mail from Krzysztof Cwalina at Microsoft, he raises a good point about exceptions and the null return pattern: they do not allow an error to be propagated, nor details about the error.

He is absolutely right, and my example with files was not a good one. I had in mind APIs that did not need to propagate a rich error or details about the condition. Krzysztof said:

One problem with null is that you may get notified about the problem really far away from the point when the error occurred. Exception will be thrown right there at the point where the error occurs. The other problem is that null cannot tell you why the error occurred. Error codes have their own set of problems.

Of course (as with every design) it's a tradeoff. In this case a tradeoff between better error reporting (fail fast, rich error message) and performance (and other things). In general, we err on the side of better reliability, clarity of errors, etc. when designing the Framework. We have several exceptions to the general rule in explicitly identified performance-sensitive APIs.

IXmlSerializable explained

Lluis the man behind the Mono implementation of Remoting and Xml Serializer explains on his latest blog entry how the undocumented IXmlSerializable interface works. If you ever wondered how you could have precise control over the Xml mapping in XmlSerializer, this is the interface used internally by the framework.

Welcome Sebastien Pouliot and Duncan Mak!

Sebastien, the man behind the Mono cryptographic infrastructure now has his own blog.

Duncan also started his

Posted on 01 Oct 2003

Anders Hejlsberg

by Miguel de Icaza

In a recent interview Anders said:

If you ask beginning programmers to write a calendar control, they often think to themselves, "Oh, I'm going to write the world's best calendar control! It's going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other." They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They'll think, "In the next version of the application, I'm going to do so much more."

Once they start thinking about how they're actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they've painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like. [Artima's interview with Anders]

I like Anders' position regarding Checked Exceptions, contrast this with James Gosling's statement, which I believe does paint a broken picture:

One of the traditional things to screw up in C code is opening a data file to read. It's semi-traditional in the C world to not check the return code, because you just know the file is there, right? So you just open the file and you read it. But someday months from now when your program is in deployment, some system administrator reconfigures files, and the file ends up in the wrong place. Your program goes to open the file. It's not there, and the open call returns you an error code that you never check. You take this file descriptor and slap it into your file descriptor variable. The value happens to be -1, which isn't very useful as a file descriptor, but it's still an integer, right? So you're still happily calling reads. And as far as you can tell, the world is all rosy, except the data just isn't there. [Artima's interview with James Gosling]

This is in fact the source of many security problems. One of the first security code audits I witnessed was by a volunteer that reviewed my first setuid application that I shipped as part of the Midnight Commander (the software only shipped after the security audit). A 200 line program got back 700 lines worth of comments, many of them related to not checking error conditions from trivial system calls like `close()'.

But modern C APIs do not use int return codes, in fact not even the C standard library uses those: that is only the low-level Unix C API that has this feature. The standard C library API returns a FILE * object, and for instance, most of Gtk+ and Gnome APIs return objects (in the form of a pointer to an object).

The beauty of returning a pointer to an object, is that you can return NULL as your standard error return value, and if the value mattered, you will most likely take the necessary steps to check its return value, or they application will just crash the moment you try to use it.

This could be applied to the .NET and Java APIs to reduce the amount of required try/catchs. For example, the File.IO.OpenRead method could be (shown here is the artist's representation):

	public static FileStream OpenRead (string file)
		int fd = open (file);
		if (f == -1)
			return null;
		return new FileStreamFromFD (f);

Which makes null a valid return value. If you fail to check for the return value, you would get a nice NullReferenceException, but you would allow the expensive creation of an exception object, and the ugly try/catch block in the call site.

Obviously we can not change the existing APIs, but we could encourage developers to minimize their use of exceptions. In my limited personal experience with software design, when I have faced applications with tons of Exceptions it was extremely hard to keep up with them. A rewrite of the software to avoid exceptions and use the more sane API paid for.

More Mono Bloggers

I wrote about Ben previously, he now has a blog which we are hosting for him at Ximian.

Posted on 29 Sep 2003

Assembling life

by Miguel de Icaza

Laura and myself have been shopping for various items for our new appartment. Once we had chosen the rug, everything fell into place, and in two hours we swiftly sorted out our color differences. The rug really ties the room together.

New Mono Bloggers

Martin Baulig now has a blog. He talks mostly about his work on the C# compiler. He is not lucky enough to be using my LameBlog technology.

Posted on 27 Sep 2003


by Miguel de Icaza

Just coming back from the HispaLinux congress in Madrid. This was a very short trip: only two days in Madrid, traveled all this and did not have enough time to eat enough ham.

Update on Extremadura from Jose: they are 100,000 Linux desktop machines in the administration and 276 machines on public centers. The public machines are fewer than the 1,500 from the Telecentros, but still a healthy number.

Try Ximian Desktop 2

The fine folks in Spain have a Live CD with Ximian Desktop 2. You can try Ximian Desktop without installing Linux on your machine, the whole system runs from a CD.

OpenOffice gets .NET support

Federico pointed me to the announcement of OpenOffice's support for C# and the CLI, it is here:

We are pleased to provide a preview of the CLI-UNO language binding. It gives developers the possibility to write client programs for OpenOffice.org, as well as stand-alone UNO applications, with CLI languages, such as C# and VB.NET.

The details about the language binding are here: http://udk.openoffice.org/cli/cli-uno.html.


The Microsoft PDC program is getting more and more interesting. As a sneak preview of the table of contents of a System.Xml/System.Data based book shows. Dare also sent me a link to the ASP.NET changes. Fantastic!

Posted on 24 Sep 2003

« Newer entries | Older entries »