Miguel de Icaza

Mono Debugger

Miguel de Icaza (miguel@gnome.org) — Fri, 16 Dec 2005 19:19:00 GMT

Martin has announced a new release of the Mono Debugger.

This is the first time that I have been able to use the debugger for a real application. It still has a few rough edges, but at least its working.

The documentation for the command line interface can be found here.

Syriana

Miguel de Icaza (miguel@gnome.org) — Mon, 12 Dec 2005 07:27:00 GMT

Just got back from watching Syriana. Loved it.

Human Development Trends

Miguel de Icaza (miguel@gnome.org) — Sun, 11 Dec 2005 00:57:00 GMT

Various statistics of human development trends in flash-tutorial form here http://gapminder.org/.

Harold Pinter's Nobel Prize Lecture

Miguel de Icaza (miguel@gnome.org) — Thu, 08 Dec 2005 09:56:00 GMT

A transcript is available here.

Political language, as used by politicians, does not venture into any of this territory since the majority of politicians, on the evidence available to us, are interested not in truth but in power and in the maintenance of that power. To maintain that power it is essential that people remain in ignorance, that they live in ignorance of the truth, even the truth of their own lives. What surrounds us therefore is a vast tapestry of lies, upon which we feed.

Mono goes to Munich

Miguel de Icaza (miguel@gnome.org) — Tue, 06 Dec 2005 17:47:00 GMT

I will be in Munich this week. Drop me an email if you want to meet. My schedule is a bit compact, but if you are interested you can join me and others for lunch or dinner Wednesday, Thursday or Friday.

Jonathan Chambers Screenshots COM in Mono

Miguel de Icaza (miguel@gnome.org) — Sat, 03 Dec 2005 06:05:00 GMT

Jonathan has posted a screenshot of his COM support for Mono. The sample shows Mono launching Excel with COM interop.

Check Jonathan blog for more information on his effort to support COM and its variants in Mono.

ChronoJump

Miguel de Icaza (miguel@gnome.org) — Fri, 02 Dec 2005 05:14:00 GMT

My friend Xavi which is a sports instructor and also a circus performer got interested in Linux and free software a few years ago. He decided to learn C#, Gtk# and create his first GUI application some time ago and has now shipped it.

His application is ChronoJump. Its interesting because he was the first user for the Gtk# port of NPlot.

He also built some custom hardware to take the measurements:

Some NPlot Graphs.

Web report generation.

Hardware prototype.

More screenshots are here.

The Web Desktop

Miguel de Icaza (miguel@gnome.org) — Sun, 27 Nov 2005 16:24:00 GMT

As a follow up to yesterday's web-based desktop communication engine, I wanted to comment on a few ideas that we have been bouncing around.

Clearly the HTTP end-points on desktop applications would be useful to invoke an arbitrary set of methods on each application. I envision a system in which we can remotely manipulate desktop applications through HTTP. The same idea that I pitched a few years ago on top of CORBA.

The difference this time is that writing the client code is trivial, unlike the previous attempt where writing the client code to talk to a CORBA server was very difficult.

But in addition to this HTTP-based RPC interface, it would be nice to make the GNOME desktop Web-Aware.

Let me explain with a few use cases that we have been discussing at Novell:

Photo Sharing: A common household issue that I face is when I import pictures from a party into my F-Spot photo management program.

Here is where the problem arises: people want to look at the pictures right away, or they want copies of the pictures, or they want me to tag them or annotate them. All of those at once.

I hear you say "Post them to Flickr", well that would be fine except that the informed in the audience will demand a full resolution version. They will hand you an email address and demand that a bunch of pictures be emailed. Emailing is a drag, because more than a handful of high-resolution pictures is a drag as they typically bounce.

I could export to a folder and then scp the files over, but thats just because am a beautiful and unique snowflake. Other non-hacker types might not be able to pull the scp trick.

A few people have suggested to use the photo sharing protocol that iPhoto has. The problem is that a custom protocol for photo sharing requires photo-sharing-aware applications. And these applications are not as ubiquitous as a web browser is.

The Solution: F-Spot coult have a "File/Web Share" which would basically run an HTTP server. In the particular case of F-Spot it can just embed our embeddable web server and expose the pictures with an ASP.NET application.

By doing this, my wife and friends can use their laptops to browse the pictures, email them, print them or send them around right there.

Music Playback: Today I use Banshee as my media player. I have it available at home on my large music repository and on my laptop with a few songs that I carry with me.

Again, I would like to have a "File/Web Share" option that I could use at home to play music from any room in the house from a laptop. Or when am traveling let others listen to interesting music from my laptop.

For this particular case, a general purpose web interface can be cooked, and the media playback could be a Flash-based MP3 player (these are very easy to produce with FlashMX).

Web Serving It is not necessary for the applications to embed a web server. If embedding a web server is complicated they can just launch an external web server.

Mono based applications have a couple of choices: they can embed a raw HTTP server using HttpListener (available in the 2.x profile on trunk) or they can embed directly XSP which would let them host ASP.NET pages with little or no work.

Multiplexor: In both cases the HTTP-based multiplexing system that I described before can be used by remote users. As far as they know the url will always be "http://machinename:123/application/frontend" or something like that. The routing system will merely send an HTTP 303 redirect to the correct port.

The multiplexing system is not required, is merely cute.

Summary: a Web-ready GNOME desktop would have applications expose two HTTP-based interfaces: an HTML one for users and a raw HTTP interface for applications.

A web-aware desktop is not tremendously revolutionary, but it adds a little bit of convenience. A set of HTTP-accessible interfaces will make our desktop more scriptable than it currently is.

Debate

Miguel de Icaza (miguel@gnome.org) — Sun, 27 Nov 2005 05:58:00 GMT

Havoc, I was not trying to debate. I agree with your qualifications on your second post about SOAP, in fact depending on the task or depending on the day I would choose one over another, I just took exception at the "masochist" comment. I have no desire to debate the SOAP vs REST discussions again, they were long and boring two years ago and they likely will be long and boring today.

That being said, my post about building the communications infrastructure on the desktop over HTTP was quite serious. I have been having this discussion over chicken schwarmas at lunch for months. I was not joking, nor was I trying to ridicule the discussion, I really believe that there is a lot to win with this model. The more I thought about it, the more sense it made to have applications speak HTTP on the desktop.

The discussion over SOAP and REST reminded me that I had long postponed a blog entry on my thoughts on the subject.

Will try to cook up a prototype activator.

SOAP and REST

Miguel de Icaza (miguel@gnome.org) — Sun, 27 Nov 2005 00:56:00 GMT

Am glad that Havoc brings up the simplicity of jamming and pulling XML from a socket:

Miguel, that's cool, I know SOAP (with a library) doesn't involve a ton of application code. My point is more that (to me) it's just not worth learning about for this sort of thing. If you want to get a couple of pieces of data on an Amazon product you just do "get url contents" and "stuff into XML parser" and "grab the Item node" and that's about it. All programmers already know how to download a URL and pull out an XML node, and being able to try out requests in the browser by editing the address in the location bar is pretty useful. "REST" is just very conceptually simple and requires no ramp-up time, even if it involves a couple more lines of code.

Recently I have been considering the implementation of a system that would replace D-BUS and CORBA with a simple HTTP framework.

At the core of such replacement there is an activation and arbitration system running on a well known location, for example: http://localhost:123/. This can be an Apache module or a custom built HTTP server.

The daemon, very much like our existing activation systems (bonobo-activation and d-bus) has a list of services that can be started on demand and provides assorted services to participants.

When an application starts, it registers itself with the local arbitration daemon, it does this with a RESTful call, lets say:

http://localhost:123/registration/id=f-spot&location=http://localhost:9000/

Where "f-spot" in this case is the name of the application, and "localhost:9000" is the end point where F-Spot happens to have an HTTP server running that exposes the F-Spot RESTful API.

A client application that wants to communicate with F-Spot always contacts the well-known end-point:

http://localhost:123/app/f-spot/request

The arbitration daemon merely returns an HTTP 303 result pointing to: http://localhost:9000/request. The http client library already has support for this redirection.

If F-Spot was not running, the arbitration daemon would look into a special directory that lists the available applications. The file could be called "f-spot.service" and it would describe how to launch f-spot, very similar to the way d-bus does it:

	[Service]
	Name=f-spot
	Exec=/opt/gnome/bin/f-spot

The request comes in on http://localhost:123/f-spot/request, the activator launches f-spot, f-spot registers itself using the previously discussed call, a redirect is then sent to the client and you are done.

To use this system as a message bus, in the same spirit as d-bus, you merely connect and listen to another well known-end point: http://localhost:123/bus/event-name. The connection is never closed by the server and clients keep reading data from this stream.

To push information into the bus, a POST request is done http://localhost:123/bus/event-name. The contents of the POST are then delivered to all the clients that are listening on the endpoint.

The format and protocol for the information that flows on that particular HTTP request as REST is up to the creator, users would have to follow that format. For example it could be one line at a time, or it could be a url pointing to the full message.

As for the security of this system, it should use a mechanism similar to what we have used in the past with Bonobo Activation: a randomly generated password is generated and stored on the file system in a well known location, and private location (~/.config/private/something).

The security process is the only component that requires a little bit of code. The rest can be implemented just with an HTTP client and the HTTP server for those providing information. A client application would only needs something like this:

	FILE f = popen ("http-get-key");
	fgets (password, sizeof (buf), f);
	close (f);

The benefits I think are multiple:

HTTP is a well known protocol.
There are plenty of HTTP client and server implementations that can be employed.
The protocol can be as simple or as complex as needed by the applications. From passing all the arguments on a REST header as arguments to the tool-aware SOAP.
HTTP works well with large volumes of data and large numbers of clients.
Scaling HTTP is a well understood problem.
Users can start with a REST API, but can easily move to SOAP if they need to.
HTTP includes format negotiations: clients can request a number of different formats and the server can send the best possible match, it is already part of the protocol. This colors the request with a second dimension if they choose to.
Servers can take advantage of HTTP frameworks to implement their functionality on the desktop.
It is not another dependency on an obscure Linux library.
The possibility of easily capturing, proxying and caching any requests.
Redirects could be used to redirect request to remote hosts transparently and securily.
And finally, makes the desktop "Web 2.0 ready" :-)

HTTP on its own has plenty of fantastic advantages that today we are bound to reimplement with things like D-Bus or live without them.

The implementation of this infrastructure is trivial. All I need now is a name for the project.

The Boo Version

Miguel de Icaza (miguel@gnome.org) — Sat, 26 Nov 2005 22:36:00 GMT

The same version of the C# program written in Boo:

	if len(argv) < 3:
		print "Usage is: associate-id token searchterm"
		return
	
	search = AmazonSearchService ()
	kr = KeywordRequest (keyword: argv [2], tag: argv [0],
		devtag: argv [1], mode:"books", page: "1", type: "lite")
	
	for detail in search.KeywordSearchRequest (kr).Details:
		print "Product: ${detail.ProductName}"
		if detail.Authors != null:
			print "Authors: {0}", string.Join (", ", detail.Authors)

To build:

	$ mcs -target:library AmazonSearchService.cs -r:System.Web.Services
	$ booc am.boo -r:AmazonSearchService.dll

To run:

	$ mono am.exe YourAssociateID YourToken YourQuery

PlanetGnome observations

Miguel de Icaza (miguel@gnome.org) — Sat, 26 Nov 2005 17:24:00 GMT

Havoc claims on his "Adventures in Web 2.0" post that Amazon has a SOAP API "for masochists". What exactly is difficult about SOAP exactly?

It took me longer to register with Amazon and obtain my developer key after reading his post than it took me to write a small C# program.

Step 1: Google for "Amazon WSDL", pass the link to the wsdl compiler:


	$ wsdl http://soap.amazon.com/schemas2/AmazonWebServices.wsdl

Step 2: register with Amazon, obtain your IDs.

Step 3: write trivial program:

using System;
using System.Web;

class X {
	static void Main (string [] args)
	{
		if (args.Length != 3){
			Console.Error.WriteLine ("Usage is: amazon amazon-affiliate-id amazon-access-key keyword");
			return;
		}
		
		AmazonSearchService s = new AmazonSearchService ();
		KeywordRequest kr = new KeywordRequest ();

		kr.keyword = args [3];
		kr.tag = args [0];
		kr.devtag = args [1];
		kr.mode = "books";
		kr.page = "1";
		kr.type = "lite";
		
		ProductInfo pi = s.KeywordSearchRequest (kr);
		foreach (Details detail in pi.Details){
			Console.WriteLine ("Product: {0}", detail.ProductName);

			if (detail.Authors != null)
				Console.WriteLine ("Authors: {0}", string.Join (", ", detail.Authors));
		}
	}
}

Step 4: Compile the sample code, and include the generated client code from WSDL, link with the Web Services library:


	$ mcs am.cs AmazonSearchService.cs -r:System.Web.Services

Step 5: Run:


	$ mono --debug am.exe myassociate-id  my-key "bugs in writing"
	Product: Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs (Microsoft Programming Series)
	Authors: Steve Maguire
	Product: BUGS in Writing: A Guide to Debugging Your Prose (2nd Edition)
	Authors: lyn dupre
	Product: The Writing Bug (Meet the Author)
	Authors: Lee Bennett Hopkins, Diane Rubinger
	Product: BUGS in writing: A guide to debugging your prose in mathematics ; taken from BUGS in writing a guide to debugging your prose
	Authors: Lyn DupreÌ
	Product: Raewyn's Got the Writing Bug (Voyages)
	Authors: Raewyn Caisley, Brian Gilkes
	Product: The Millennium Bug.(Brief Article)(Poem) : An article from: New Statesman (1996)
	Product: Hooking the Nose of the Leviathan: Information, Knowledge, and the Mysteries of Bonding in The Gold Bug Variations. : An article from: The Review of Contemporary Fiction
	Product: Mai-Lee's bug disaster. (poem) : An article from: U.S. Kids
	Product: Don't Bug Me!
	Authors: Gillian McHale
	Product: All this talk about the millennium bug is sheer techno-paranoia, isn't it? But then again.... (year 2000 furor) : An article from: New Statesman (1996)

I concede that using SOAP with printf and jamming the output down a socket is harder than using a toolkit. But jamming down printf-generated XML down a socket without having a complete HTTP client stack implemented is asking for trouble on both counts anyways.

Alvaro and US Airport Security

Alvaro complains about being treated like a criminal in US airports. I would argue that every time you cope with "security" you are treated like a criminal, and this is not limited to US airports.

Alvaro just came from Mexico, where every person entering the country is randomly subject to a full property search on arrival. The situation is no different in Europe. If you are white or European they will mostly leave you alone, but if you look remotely like arriving from Africa you get a very different treatment in immigration and customs.

My point is merely that singling out the US airports for this treatment is not really fair. Annoying, perhaps, but with international travel you must be ready to cope with these kinds of things.

March 2003

Miguel de Icaza (miguel@gnome.org) — Fri, 25 Nov 2005 02:14:00 GMT

Boston

Paris

New MonoDevelop release

Miguel de Icaza (miguel@gnome.org) — Thu, 24 Nov 2005 17:24:00 GMT

Lluis has released a new version of MonoDevelop, there are plenty of new features in this release. The release notes are here.

A Welcome Page: a starting point for your ongoing projects.
New component-based architecture for the IDE. For details see the Architecture Overview.
New Add-In manager to install, update and remove plugins for the MonoDevelop IDE.
A command-line build tool, so you can integrate MonoDevelop projects into your batch compilation process.
Smartindent for C# and Boo languages.

This release is the results of many months of work where he rearchitected MonoDevelop to be a modular IDE.

The core of MonoDevelop basically offers a framework for plugins and third-party components. The framework includes a system to install, upgrade or remove plugins and little more. For instance it does not have any notion of projects.

All the functionality of the IDE has been moved into its own modules that are layered on top of it.

The new Welcome Page.

OpenOffice

Miguel de Icaza (miguel@gnome.org) — Wed, 23 Nov 2005 17:22:00 GMT

Radek Doulik talks about his work on his Cairo-based Canvas for OpenOffice and shows the quality difference.

He also posted his slides for his presentation.

Office File Formats

Novell will be sending some folks from our Open Office team to the newly created ECMA TC45 working group. We hope to determine if the standard will be open enough and the details complete enough to allow for interoperability.

Gtk+/Quartz on OSX

Miguel de Icaza (miguel@gnome.org) — Wed, 23 Nov 2005 17:11:00 GMT

Imendio has checked into CVS their Gtk for OSX port.

Robert Fisk Lecture in LA

Miguel de Icaza (miguel@gnome.org) — Sun, 20 Nov 2005 05:21:00 GMT

Robert Fisk lecture in LA is available in MP3 format here.

Robert is an incredible story teller.

In this talk he describes some of his experiences as a journalist on the Middle East in the past twenty years and why he started to write his new book "The Great War of Civilization".

Packed with anecdotes. The parallels between the British occupation of Iraq and the new occupation are incredible.

Mono Status '05

Miguel de Icaza (miguel@gnome.org) — Thu, 17 Nov 2005 16:35:00 GMT

Mono Directions: (Article Permalink)

We just released Mono 1.1.10, our best release so far. The major feature missing from this release to call it Mono 1.2 is the completion of our Windows.Forms implementation.

In this document I only present the direction of development of the Mono team at Novell; A more comprehensive view of other Mono developments by the Mono community is something that am working on and will post at a later date.

I also present how our team's priorities are shifting in response to Novell's own internal use of Mono and external factors like the final release of .NET 2.0.

Index

Code Development Process
Windows.Forms
2.0 Support
Mono Debugger
MonoDevelop IDE
Mono Virtual Machine: ports
Precise Garbage Collector
Code Generation and Optimization
C# Compiler
Visual Basic Compiler
Code Access Security
ASP.NET
API stability
Gtk#
Integration of Google Summer of Code Projects
JScript Compiler

Code Development Process

Since the Mono 1.1.xx series has got a significant amount of fixes over 1.0.xx we have encouraged users and developers to move to the Mono 1.1.xx series.

To avoid regressions we have done a number of things:

We incorporated all of our tests into our pre-release process `make distcheck' to ensure that we do not release something with known bugs.
We fixed the bugs that were preventing the NUnit tests to complete or disabled the tests that were specific to an environment (tests that require Internet access or to contact a specific host) from the standard test process.
We started development of new features in branches and only when the feature is complete we have "landed" the feature into the main repository.

We have used this separate branch development for the new string collation framework, the ASP.NET implementation, the new cross platform register allocator and the Cairo 1.0 migration. And we currently do the same for our VM optimizations, the precise garbage collector work and the C# 2.0 compiler.

The basic idea is that we turned the 1.1.xx series into a release that can be deployed on production as opposed to merely a development release. This is similar in spirit to the kernel 2.6.xx releases.

As a general rule we try to fix bugs before we write new features.

For details on what has been done in the 1.1.xx development cycle, please see the release notes for each of the releases: 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.1.9 and 1.1.10.

Windows.Forms

Windows.Forms is the only piece that is holding us from officially renaming Mono to Mono 1.2, it is still missing a few features. Our plan is to complete the missing features by the end of this month and then move to bug fixing and testing open source our publicly accessible Windows.Forms applications. We are planning on spending three months on bug fixing at this point.

Our aim with Mono 1.2 is to release a Windows.Forms implementation that implements the .NET 1.1 API, not the 2.0 API.

These are the most visible missing bits from feature completion:

Multiple Document Interface (MDI).
Menu merging in the presence of MDI.
Our RichTextBox is lacking a few features: selection margin, bullets, indentations as well as a few public methods and properties.

Our Windows.Forms implementation is implemented on top of the GDI+ API for rendering and a relatively small driver to interact with the host windowing system. Our GDI+ implementation on Unix (Linux and OSX) uses Cairo as the rendering engine. As for the windowing system drivers, today we have two complete drivers (Unix/X11 and Win32) and one driver under development (OSX).

Some minor features missing are:

Integrate the artwork from the Tango Project as the default for the Windows.Forms toolkit.
Complete the MacOS X driver for Windows.Forms.
Add support for translucency to controls.
Double buffering: although we support double buffering we have it disabled for many controls just to keep compatibility with the settings on the same controls on Microsoft's implementation. We will likely change this setting to improve the user experience.

There are a number of features that we have explicitly postponed from this release and will only make it into 1.2 if they are contributed by external contributors, otherwise they will have to wait for Mono 2.0:

Pango. Currently Windows.Forms is limited to render text with the GDI+ API so it lacks all the text rendering capabilities of Pango for international text and complex scripts.
Completing the Gtk+ theme module to have controls match the Gnome look and feel.
Our GDI+ implementation lacks support for bezier-based regions (we only support rectangles).
Input methods.
Printing.

Our WinForms page tracks the progress.

2.0 Support

We started work on the foundation for 2.0 in mid-2003 as soon as the early drafts of the new changes were submitted to ECMA. This gave us plenty of time to work on our C# 2.0 compiler and the changes to our VM to support generics. Today they are both considered feature complete.

Our IL assembler and IL disassembler are almost complete and should be able to roundtrip our generics-based libraries soon.

The core is complete enough that the latest versions of IronPython and Nermerle work with it.

Developers are starting to use the new features available in 2.0 and they have started to file bugs against our runtime and compiler.

So far our policy was that we supported the 1.1 profile for the libraries. The 2.0 profile is being developed but is only supported in the "if it breaks, you get to keep both pieces" modality. Bugs on the 2.0 support in the compiler and runtime were routinely fixed.

With the release of .NET 2.0 we are shifting some of our development efforts to work on the most important areas of the 2.0 profile.

We are hoping to include the most important bits of the profile in the upcoming release of Mono 1.2, but we are not making any promises about the completeness of the 2.0 APIs. Mono 1.2 will release when Windows.Forms is complete.

The System.Xml 2 is pretty complete, mscorlib and System assemblies still require significant amounts of work.

See also the ASP.NET section for details on the progress in that area.

Mono Debugger

Martin has been working on our debugger. Today it is capable of debugging 1.x applications (2.0 should be supported as soon as Cecil support for generics is completed).

To test the debugger today you must use SVN versions of Mono as well as the debugger as it is still rapidly changing.

We are now accepting feedback on the debugger: limitations and interface. Since it currently only works as a command line debugger you might want to read the debugger guide in our web site.

If you find problems with the debugger, please file a file a bug report.

MonoDevelop IDE

Lluis has moved from working on ASP.NET 2.0 to work on the MonoDevelop IDE.

Our most important goal with MonoDevelop is to make it rock solid and eliminate every crashing bug that has been reported.

As for the features, MonoDevelop now sports a plugin architecture similar to Eclipse: components can be downloaded and installed without having to recompile the application (see here).

Integration of a GUI designer is progressing (currently Glade3, but we hope to replace it with Stetic when it becomes available).

Finally as the debugger interface stabilizes we plan on enabling the debugger interface in MonoDevelop again.

Mono's Virtual Machine: Ports

During the last year the Mono JIT has been ported to three new architectures (x86-64, Itanium and Arm processors) in addition to the platforms it supported before (x86, PowerPC, SPARC, SPARC 64 bits and S390).

At this point the Novell team does not have any plans to work on new ports. Although some members of the community have expressed their interest in adding S390x and MIPS support to Mono.

Precise Garbage Collector

Paolo has been working on a new garbage collector (GC) engine. Currently Mono GC interface is almost pluggable (the work to plug different GCs was done a few months ago).

The new GC engine is a precise, generational, compacting collector. This means that the Mono GC will be able to return memory to the operating system when it no longer needs it.

We are making a few tradeoffs to ship this version of the collector quickly. For instance this new GC will treat the stack conservatively has two effects: it makes it easy for embedders of Mono to use the new GC but it also might flag a lot of pinned objects.

We hope that the new GC can be tested in February or March, the code will start landing in December.

Code Generation and Optimization

We have been working for quite some time on various new code optimizations. The code is getting ready to be submitted to the main Mono repository. Over the next few weeks expect various patches to be posted.

Currently we are working on the following areas to improve the performance of the generated code

Enabling some stronger optimizations by default (inlining and fastdce). These require us to avoid any significant regressions (both in the generated code quality as well as the JIT time).
New optimization framework (HSSA-based platform) and optimizations built on top of it (PRE and GVNPRE).
Eliminating the tree-based intermediate representation (IR) and go directly from the CIL code to the list-of-instructions IR.

Massi has recently posted his Fast Dead Code Elimination and he described it on this blog post.

Massi has also been working on our HSSA-based framework and dead code elimination based on it. This optimization should be posted for review to the mailing list this week.

Once those two are done, Massi is going to work towards making FastDCE + CopyProp + Inlining be part of the default optimizations for Mono which will bring some immediate visible results.

After this our plans for HSSA are:

Implement copy propagation.
Full redundancy elimination (easier to spot than partial).
Partial redundancy elimination PRE (harder to spot and handle).

The quality of the code might suffer because removing redundant code introduces new temporary variables. To fix this we need a feedback mechanism to the register allocator that does not exist today.

To address the previous (and other problems) Zoltan is starting work to eliminate the tree-based IR from Mono.

C# Compiler

The C# compiler comes in two editions:

gmcs: supports completely the latest ECMA specification (3rd edition), produces binaries that reference the 2.0 libraries.
mcs: supports the latest ECMA specification minus the generic extensions (3rd edition). This produces binaries that reference the 1.0 libraries.

Our gmcs compiler support as of November 2005 is known to lack one feature: the late changes to nullable types in the specification. Other than that the compiler is considered feature complete.

As the C# compiler is at the core of much of our work we will continue to focus on bug fixes. The recent C# 3.0 features although easy to implement will have to wait.

Visual Basic

We had plans last year to complete a free Visual Basic compiler. Today the compiler exists in beta form and Novell will no longer fund the development of this compiler.

The folks at Mono Brazil have taken over the development and maintenance of the compiler.

The VB compiler is based on an old mcs fork that was originally created by Rafael Texeira. To upgrade the compiler from its current form to support generics in 2.0 we believe that it might be necessary to start from a fresh copy of `gmcs' and merge the various changes that make up the VB compiler.

Code Access Security

Code Access Security (CAS) has been available in Mono since version 1.1.4, it is enabled by running `mono' with the --security command line option.

Although CAS is in a very advanced stage and it will be available on Mono 1.2 we will not guarantee that CAS is complete until the next major release of Mono. We are still missing the code verifier and in 2.0 there are new CAS features that we do not implement yet.

Sebastien who maintains the code has been busy adding CAS attributes to our class libraries and creating the associated tests, he discussed the state of CAS here.

As for how the CAS permissions are being set, he discusses that here.

Sebastien has written a general bug finding tool, similar in spirit to FxCop, which we are using to set the proper CAS rules on our libraries. You can learn more on the Gendarme page.

ASP.NET

We released a fairly updated version of ASP.NET with Mono 1.1.9 which is much faster and consumes less memory. Our new implementation uses several tricks to improve the performance which we will blog about later.

In Mono 1.1.10 Gonzalo introduced a new automatic configuration option to the Apache module. Setting up mod_mono now behaves like other modules for other languages, for instance users and administrators can drop .asmx, .ashx or .aspx files anywhere on their exposed directories and they will automatically be handled by Mono's ASP.NET implementation without having to make any changes to the ASP.NET configuration.

As for the 2.0 support in ASP.NET we have implemented various controls that do not depend on the new Configuration API (menus, trees, masterpages, gridviews and anything they require).

Chris Toshok has taken over from Lluis on developing ASP.NET 2.0 and is almost done with the new System.Configuration namespace which is the foundation for the next batch of features in ASP.NET (profiles, portal parts and many others required it).

Chris has also done some work on an open source implementation of Atlas.

API stability

As for the stability of the APIs: the System.* ones are set in stone and we verify the compatibility using our "corcompare" tools. The .NET 1.1.x API has been implemented (as described in Mono 1.0 Features).

The Mono.* namespace on the other hand is still a moving target.

the Mono.Cairo assembly has had to adapt to the changes in the underlying Cairo 1.0 library and we also had to do various changes to cope with early bugs and limitations in our API design.

The Mono.Posix assembly has incorporated a new namespace: Mono.Unix which offers a more comprehensive binding and also provides a high-level .NET-ish API for accessing Unix as opposed to Mono.Posix which only contained raw access to Unix.

Gtk#

Version 2.4 of Gtk# has been released. The new features on this release are documented here, it binds Gtk 2.4 which is the most commonly available version of Gtk+ at this point.

We have created an upgrade guide for developers moving their code from Gtk# 1 to Gtk# 2.

On the development side of Gtk#, a new version is available for testing that binds the Gtk+ 2.8 API and exposes a handful of new methods as well as the Cairo properties that are part of Gtk+ 2.8.

The work to add databinding support to Gtk# is currently on hold until Windows.Forms is completed. We expect to work again on a databound-aware Gtk# after Mono 1.2 has shipped.

Integration of Google Summer of Code Projects

We have integrated a few of the projects that were developed thanks to the Google Summer of Code program:

Monodoc improvements (collaboration, Mozilla integration, CSS ification) from Mario Sopena.
xbuild: an implementation of msbuild is on our tree, but not compiled by default yet. By Marek Sieradzki.
DataGridView, by Pedro Martínez.
xaml compiler and helper classes from Iain McCoy.
The Javascript runtime improvements from Florian Gross.
Cecil from JB Evain is being used for Gendarme and Bugfind and we hope to start our linker soon.

We are planning on integrating the ASP.NET editor work from Michael Hutchinson and Blagovest Dachev as well as the bugfinder engine from Aaron Tomb into Gendarme.

ADO.NET 2

T Senganal will take over the maintenance of ADO.NET and will start working with the developers that are using the new features in ADO.NET 2 to get their providers working on Mono.

JScript

Cesar is very close to pass all the Mozilla JavaScript tests with our implementation of JScript.

If you want to track the state of the JScript compiler and runtime see the JScript page on the Mono web site.

End

You have reached the end. Congratulations!

TV

Miguel de Icaza (miguel@gnome.org) — Thu, 17 Nov 2005 04:05:00 GMT

Been loving the US version of "The Office", the awkward moments are all there.

I also find "American Dad" hilarious. My love is divided between the fish and the alien.

F-Spot Monitor

Miguel de Icaza (miguel@gnome.org) — Wed, 16 Nov 2005 05:43:00 GMT

A few weeks ago I purchased a 24" flat screen from Dell. The sole purpose of this monitor is to run F-Spot to manage my home photo collection. Today I completed the F-Spot setup at home.

Link-o-Fest'05

Miguel de Icaza (miguel@gnome.org) — Wed, 16 Nov 2005 04:29:00 GMT

Noam Chomsky on the debate about intelligent design:

To proponents, intelligent design is the notion that the universe is too complex to have developed without a nudge from a higher power than evolution or natural selection.
To detractors, intelligent design is creationism --- the literal interpretation of the Book of Genesis --- in a thin guise, or simply vacuous, about as interesting as "I don't understand" as has always been true in the sciences before understanding is reached.
Accordingly, there cannot be a "debate."

Robert Fisk on the rebranding of torture:

What Americans do to their prisoners is "abuse" and there was a wonderful moment last week when Amy Goodman, who is every leftist's dream, showed a clip from Pontecorvo's wonderful 1965 movie "The Battle of Algiers" on her Democracy Now program. "Col. Mathieu" -- the film is semi-fictional -- was shown explaining why torture was necessary to safeguard French lives.
Then up popped Bush's real spokesman, Scott McClellan, to say that while he would not discuss interrogation methods, the primary aim of the administration was to safeguard U.S. lives.
U.S. journalists now refer to "abuse laws" rather than torture laws.

Molly Ivins has her own take:

I have known George W. Bush since we were both in high school -- we have dozens of mutual friends. I have written two books about him and so have interviewed many dozens more who know him well in one way or another. Spare me the tough talk. He didn't play football -- he was a cheerleader. ''He is really competitive,'' said one friend. ``You wouldn't believe how tough he is on a tennis court!''

I tried to track down Robert Fisk as he tours the US but the only confirmed dates that I have are for California this weekend and I do not feel like crossing the country. If you happen to know of any dates somewhere closer to the East Coast, please drop me an email.

Norman Finkelstein is talking on Thursday in Boston. Details are available here. Norman is the author of the "Beyond Chutzpah" and "Israel-Palestine Conflict" books. Am pretty psyched.

Fast DCE Implementation Posted

Miguel de Icaza (miguel@gnome.org) — Wed, 16 Nov 2005 03:54:00 GMT

Massi posted his fast implementation of Dead Code Elimiation for the Mono runtime.

This is an optimization that we can hopefully enable by default, as opposed to the more expensive SSA-based optimizations.

This is the first on a series of optimizations patches that Massi is completing.

Dan Pena Ajena

Miguel de Icaza (miguel@gnome.org) — Tue, 15 Nov 2005 23:19:00 GMT

El presidente Fox y su cabinete, nada más dan pena ajena. Que verguenza, y es que es una tras otra. Deberían de tener un examen de admisión.

Ese es el problema de elegir a alguien que bajaron del cerro a tamborazos.

Microsoft Memos

Miguel de Icaza (miguel@gnome.org) — Fri, 11 Nov 2005 16:31:00 GMT

I was reading the leaked memos from Microsoft and as I was reading the first few paragraphs, I could not stop thinking that nobody on their right mind writes internal company memos like this. Nobody puts this kind of history background.

Consider the recipients: "Executive Staff and Direct Reports; Distinguished Engineers".

I could not stop thinking that these memos were written to be leaked. They read like ads.

Update: Alex points out that Cringely made the same observation. The difference is his article is actually interesting. Here is a tidbit:

But I have to say that Gates or Ozzie or whoever actually wrote these documents has done a very effective job of differentiating the company roles in a way that makes Google appear to be the bad guy, and Microsoft appear to be the good guy. Google is going to develop and deploy Internet services while Microsoft is going to ENABLE the deployment of such services BY ITS DEVELOPER PARTNERS. This makes Google the would-be monopolist.
Looking deeper, though, we see that the only way Microsoft can achieve its vision is by continuing to own the platform. They want us to be GRATEFUL, in fact, that such an enlightened outfit is running the store. And this will work to an extent, but only to an extent. Then what happens? All hell breaks loose as Microsoft again changes the game. Here's how: read the rest

Italian Fallujah Documentary

Miguel de Icaza (miguel@gnome.org) — Fri, 11 Nov 2005 16:26:00 GMT

The Italian documentary about the use of chemical weapons in Fallujah can be downloaded here.

A guy which sounds pretty upset about it is here.

Robert Fisk described the use of Phosphorus bombs on the civilian population of Beirut, you can read a couple of pages with Google Print: here.

Update: A reader points that the official page for the RAI documentary contains more download options and formats. The page is here.

F-Spot Tagging screencast

Miguel de Icaza (miguel@gnome.org) — Fri, 11 Nov 2005 15:09:00 GMT

Jakub has done a screencast of the new tagging feature in F-Spot.

Nat's Photo Tagging

Miguel de Icaza (miguel@gnome.org) — Thu, 10 Nov 2005 05:56:00 GMT

Nat recently implemented tag-typing for F-Spot, our new photo management software. For those of us with large picture collections this is probably one of the best interfaces for tagging.

See Nat's post here and his latest patch here.

Send copious amounts of email to Nat until he does a screencast of this new feature. You have to see it to appreciate it.

On the hacking side of things, the beauty of this patch is that it was coded in two afternoons after long busy work days for Nat.

Secret Prisons

Miguel de Icaza (miguel@gnome.org) — Thu, 03 Nov 2005 15:43:00 GMT

The Washington Post yesterday ran an article that claims that the CIA has a network of secret prisons where they have been incarcerating suspects. The CIA denies such prisons exist:

The CIA has been hiding and interrogating some of its most important al Qaeda captives at a Soviet-era compound in Eastern Europe, according to U.S. and foreign officials familiar with the arrangement.
The secret facility is part of a covert prison system set up by the CIA nearly four years ago that at various times has included sites in eight countries, including Thailand, Afghanistan and several democracies in Eastern Europe, as well as a small center at the Guantanamo Bay prison in Cuba, according to current and former intelligence officials and diplomats from three continents.
...
Mid-level and senior CIA officers began arguing two years ago that the system was unsustainable and diverted the agency from its unique espionage mission.
"We never sat down, as far as I know, and came up with a grand strategy," said one former senior intelligence officer who is familiar with the program but not the location of the prisons. "Everything was very reactive. That's how you get to a situation where you pick people up, send them into a netherworld and don't say, 'What are we going to do with them afterwards?' "

Billmon weights in:

The plot line should be familiar to students of the Abu Ghraib atrocities. Interrogation tactics originally developed and/or authorized for use against "high value targets" at Guantanamo were exported first to the broader Gitmo population, and then to Iraq, where they were put into mass production by a group of half-trained or entirely untrained intelligence officers and MPs. The result was an entirely predictable moral and political disaster -- one which may have cost the United States whatever slim chance it had of establishing a popular, pro-Western government in Baghdad.
Likewise, the CIA's mini-archipelago seems to have grown like a poisonous weed in the absence of any coherent strategy for fighting Islamic terrorism, other than the initial impulse to hunt down the "evildoers." But now, like a dog who chases cars and actually catches one, the war cabinet faces the awkward question of what do with its secret prisoners and their secret prisons, even as the media finally starts to peel back the layers of secrecy. This story is going to cause something close to panic in more than one Eastern European capital, I suspect, and a relatively quick exit from that Soviet-era "compound." Where will the CIA take its human contraband now?
It seems to me that the Cheney administration has been trapped -- both by its ostentatious rejection of the "law enforcement" model of counterterrorism, and by its complete, willful failure to understand the limits of hard power and the steadily rising importance of soft power in a struggle that will last years, if not decades. Policies based on the adrenaline rush of war fever (circa 2002) were never likely to be sustainable. They also haven't brought us any closer to capturing Osama or prevented the transformation of Al Qaeda from an organization to a movement, one that is much more difficult to fight with dirty war tactics.

In other news, Mexico joined the International Criminal Court which upset a few people in the US:

Washington had warned Mexico that if it ratified the ICC and refused to sign an accord exempting U.S. nationals from the court's jurisdiction, it would cut 11.5 million dollars in funding from aid programs for fighting drug trafficking, according to human rights groups. The amount is equal to almost 40 percent of the economic aid Mexico receives from the United States.

Linux Desktop

Miguel de Icaza (miguel@gnome.org) — Wed, 02 Nov 2005 23:18:00 GMT

Nat makes an observation about the Linux Desktop.

Imeem and Mono

Miguel de Icaza (miguel@gnome.org) — Mon, 31 Oct 2005 23:42:00 GMT

Today we did a news brief with the Imeem folks. Imeem developed a client tool to create private networks with a number of tools (blogs, instant messaging, profiles, searching, file sharing).

Imeem uses Mono on their servers and also they use it on their MacOS port to reuse the same codebase that they had on Windows. Like iFolder, they are creating a native Objective-C interface using Cocoa and communicating with Mono to call into the engine.

My understanding is that Imeem uses Mono's cryptographic codebase extensively.

Someone should do an interview with Dalton Caldwell founder and CEO of Imeem.