For your progressive needs, this week has a couple of interesting events in Boston:
Posted on 05 Jun 2006
Duncan pointed me today to this blog entry from Google Research: "Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken".
Posted on 03 Jun 2006
Tonight Laura, Duncan and myself went to watch "An Inconvenient Truth", featuring Al Gore as he presents his case for action to stop global warming.
The movie, which follows Al Gore through as he delivers the same speech over and over around the globe had everyone in the movie theather glued to their seats.
As the before and after images start rolling and the graphs and numbers of warming in the planet and the pictures of large chunks of ice the size of entire states start thawing the sense of urgency grows.
By the end of the movie not only everyone was applauding, but stayed seated as the credits and some extra messages kept rolling and applauded again. Few movies have that effect on people.
I highly recommend it.
Here is the YouTube Trailer.
Now, when I got home I Googled for the movie, to find the web site, and one of the sponsored link ads pointed to "Friends of Science" (not linking to them), which has a section on "Myths and Facts" about Global Warming. The section on Myths and Facts probably were strong enough a few months ago. They probably managed to make some people doubt the negative effects of Global Warming, but compared to the arguments put forth by Al Gore in the movie they just represent a radiography of the kind of shady discourse that passes as science and debate nowadays.
In addition, last night we watched the PBS documentary on the AIDS epidemic (now you can watch it online). Both Bill Clinton and Al Gore appear on the documentary. After listening to both of them, Clinton very articulate and passionte, and Gore making the case in front of the Security Council on a health issue Laura turned and asked me "And this is the guy they tried to impeach?".
Posted on 03 Jun 2006
Stetic Lluis completed the work in Stetic, the Gtk# GUI designer, to support menu and toolbar editing. His work is based around Gtk+ UIAction/Action/ActionGroup, which takes advantage of the new features in modern Gtk+'s.
Read his full blog entry for further screenshots and explanations. The code is available on trunk.
MonoDevelop and C# 2.0: on the same blog entry Lluis talks about the integration of SharpDevelop 2.0's NRefactor code. This means that MonoDevelop will now do proper completion and parsing of C# 2.0 projects (Generics, anonymous methods, partial clases and so on).
Zac Bowling: has two interesting posts this week: his progress on Mozilla embedding. His post describes his work to give us finer control over embedding Mozilla in our applications (in particular to implement Windows.Forms's WebControl).
He also has a very nice post about uses of Mono beyond running your application on Linux and tips for .NET developers.
Google announced Picasa running on Linux, I agree with Robert Love's opinion that using and improving Wine was the right thing to do for Google. Wine and Picasa stability and performance are very impressive.
Posted on 26 May 2006
Independently of the open source debate surrouding Java, I enjoyed very much this blog entry from Sun's CEO. In particular:
I'm still amazed when I hear folks wondering how Sun monetizes Java. So at the risk of repetition, I'd like to share a few thoughts.
Then there was the civil war era in the US, when locomotive companies all had their own railroad widths and shapes - designed only to work with their rail cars and steam engines. How'd they fare? They failed, standards emerged that unified railways and rail lines, and that era created massive wealth, connecting economies within economies. Standards grew markets and value.
Posted on 26 May 2006
The Google Summer of Code has started, and we have announced the list of projects that will be mentored in the Mono group here.
This will be another exciting summer.
Posted on 25 May 2006
Disclaimer: I do not know how people are using continuations to build web applications, but on the ongoing debate about continuations and the web, Ian Griffith's has a small tutorial and makes the following observation which sounds sensibe:
But continuations seem to offer a solution. Whenever we get to the point in the code where we need to generate a page and feed it back to the user, we could create a continuation, store it somewhere, and then return control to the web server. When the next request comes in, a framework could retrieve that continuation, and execute it, allowing us to continue from where we left off.
You could probably cruft up a working example of this style of coding in a web app by writing an iterator function in C# which did a yield return each time it wanted to show a page to the user and wait for the results. Languages with comprehensive support for continuations could offer a more elegant example of the same idea.
However, I think this is a bad idea. Although the relationship between the code and the user navigation path is apparently simple, it hides subtle but significant details. This makes the same mistake as we did in the 1990s with distributed object models. We'd like to believe we're hiding a lot of implementation details behind a simple abstraction. In practice we're hiding important features behind an inappropriate abstraction. Our industry has more or less learned the lesson that procedure calls are an unworkably naive abstraction for request/response messaging over a network. I suspect that it's equally naive to attempt to manage the complexities of user/web server interactions with simple sequential code.
We abused iterators last year to implement our HTTP application pipeline, but am not sure this is something that can be easily generalized and is certainly not easy to explain.
In the meantime, Tomi Valkeinen has prototyped a continuations framework for Mono.
Update: Even if there is a good design for a web framework that uses continuations at its core, doesn't this require the state to be preserved in the server in some form?
Posted on 21 May 2006
In the last few weeks a large number of bugs have been fixed in our Windows.Forms implementation which finally has allowed us to get larger applications running with Mono.
As time goes by we are able to run more complicated applications with Mono.
In October I imported a version of Paint.Net, a paint application built with .NET into our repository. I made some changes to it to get it working on Linux, this is a screenshot as of this afternoon:
Paint.NET running on Linux
Paint.NET has been a fantastic test case, it is made up of about 70,000 lines of C# code. Update: The port runs in Mono, without any external dependencies (no Wine for instance).
Compiling Paint.NET on Mono: the first steps
To get the code building on Linux, I had to remove all the references to a third party library that was used by the Paint.NET back in October (DotNetWidgets). This is the last release of Paint.NET that targeted .NET 1.x; Newer versions of Paint.NET have replaced DotNetWidgets for the Strip controls in Windows.Forms.
The port is not as clean as I would like to, as I switched strategies in the middle of the port, let me explain.
First I used prj2make to turn the Visual Studio solution into a Makefile; Then I had to rename some of the files, as the actual filenames were spelled differently (filename casing) than the files distributed. This was easy.
A rather large and obnoxious task was replacing all the calls to DotNetWidgets (which provided Paint.NET with a spiced up UI experience) with the more simple widgets that ship as part of the standard API. This was done by removing the reference to the library and then changing the code to use the simpler widgets in a loop.
And this was my first mistake in the port. Instead of planning the port, I kind of brute forced the port on my spare time. About one third of the way in manually replacing the code in my favorite editor, I realized that I should just have implemented the DotNetWidgets interface and be done with it. The result was a 129 line source file that in one hour gave me everything I needed to get Paint.NET building without this dependency.
Exercise for the reader: describe the morale of the story.
Making it Run
This Paint application despite its young age is quite sophisticated and calls into a number of Win32 libraries to use features not exposed directly by the .NET libraries. For example, it determines the number of CPUs to adjust its thread pool, it uses low-level heap routines from the OS and other things like that.
Luckily all this OS-specific code is neatly split into the SystemLayer directory of Paint.Net and wrapped in a handful of classes.
Since most of these routines are very simple to provide in Unix I initially decided that it would be a good idea to implement these functions in a way that other future Windows.Forms applications would benefit, so I started implementing a number of routines that are now part of our "supporw" library.
Also, supportw is useful in showing how we can map unmanaged calls back into managed calls, so it was a useful example to have around for anyone which might need to "bounce" unmanaged calls into the managed world.
At this point in November, Paint.NET started running into missing functionality in Mono's System.Drawing and Mono's Windows.Forms; I would take a break of a few months before coming back to it a couple of weeks ago.
One of the early road blocks that I ran into with Paint.NET was the incomplete support for Regions in our System.Drawing implementation. We supported rectangular regions, but not the GraphicsPath-based regions.
Implementing this was not an easy task. Around the same time we started working with a third party control vendor that uses System.Drawing extensively for his commercial product and we also ran into ZedGraph which is a popular library for generating plots which was running into some gradient issues with our implementation.
Sebastien was kind enough to take on the challenge of implementing these hard tasks.
Sebastien blogged extensively about his work on GDI+, some screenshots:
Blogging about this attracted Bill Holmes, which helped refine the finer points of the gradient brushes.
With GraphicsPath-based Regions implemented, gradients in place it is now possible to get most of the basic operations in Paint.NET going without a crash.
We are still missing support for "GraphicsPath.WidenPath" (used by Paint.NET to paint ellipses and rectangles, but really, who uses that these days? Aren't bezier paths all people need?).
Another missing feature are PathGradientBrushes. We do not believe that this can be implemented with Cairo, but we would love to be proved wrong. Cairo is the underlying engine that we use to implement GDI+.
Some of the us secretly wish that the Xara Xtreme library was already open sourced (they are planning on releasing it) but to use it, we would need it to be licensed under the LGPL or the MPL license.
Once the graphics issues were sorted out, Paint.NET turned out to be a QA engineer dream come true. After a while, we got to the point where we can actually draw with the program and we have fixed the most critical performance problems (initially it was not even possible to draw, due to a trigger-happy redraw routine).
Midways through the port, I changed direction. Instead of continuing to work on supporting the emulation of unmanaged APIs by emulation or by bouncing the API to managed code, I started to do a more regular "port". So I started to replace calls to SystemLayer with proper Unix calls or other Mono libraries. This has proved to be much simpler.
We might still implement a few emulation routines for some P/Invokes, depending on the popularity of the technique, but in general we will advocate that folks use OS-specific calls depending on their needs.
Paint.NET has exposed a lot of bugs in our Windows.Forms implementation (current bug list).
Sadly, in addition to the bugs reported, we need to fix also the minor details, and the cosmetic aspects of Windows.Forms before we can ship it.
At Novell, Jackson, Peter and Mike are now being joined by Atsushi, Gonzalo and Chris (who were up to this point working on ASP.NET 2.0) to assist in fixing bugs in Windows.Forms.
And of course lots of people in the community are helping out, specially Alexander Olk, Jordi Mas and Jonathan Chambers.
Carlos is now working in collecting applications from the CodeProject and SourceForge and repeat the process that I described above for Paint.NET: we will be gathering applications as test cases and Carlos will be routinely testing them for potential regressions.
In addition, although we had a NUnit test case for Windows.Forms we were not really using it, so many failures went unnoticed for a while. So our immediate next step is to make sure that our NUnit tests pass on Unix (Atsushi just recently fixed them on Windows, as we had some incorrect tests or tests that depended on a specific release of the framework).
Atsushi has a great call for contributors that includes some background information on those which migh be interesting in helping:
So I have started to look around existing bug list and work on it. At first I thought that it is highly difficult task: to extract simple reproducible code from problematic sources, and of course, to fix bugs. Turned out that it is not that difficult. Actually, it is very easy to find MWF bugs. If you run your MWF program, it will immediately show you some problems. What I don't want you to do at this stage is just to report it as is. We kinda know that your code does not work on Mono. It's almost not a bug report. Please try to create good bug report. Here I want to share my ideas on how you can try creating good MWF bug reports and bugfixes.
Followed by some easy-to-follow steps on how to squash the bugs.
There are a number of exciting new developments in the Mono Universe that I hope to write about next week in more detail (news on our compacting GC, a new IR representation for Mono, a few touch-ups for our inliner).
The summer of code has some great proposals, and hopefully next week we will have the definite list of projects that we will be mentoring, but the one am most excited about is a VB.NET compiler (VB.NET 8, with Generics and all that) written in VB.NET.
Posted on 19 May 2006
An interview with Rick Brewster, one of the authors of Paint.NET, available here.
I nominated myself to the project manager position and the four of us (Brandon Ortiz, Chris Trevino, Luke Walker, and myself) kicked out a v1.0 product in about 15 weeks. We didn't start with the source code to Paint, but instead built Paint.NET from scratch -- I was quite impressed with how easy it was to build an application in C# and to keep it organized.
The primary goal of Paint.NET is ease of use. One rule of ease of use is recognizing that "people don't." They don't follow or even read directions (I certainly don't), they don't read dialog boxes (I hate dialog boxes), they don't backup their files, etc. And many people aren't interested in figuring out all sorts of complex or technical things. They just want it to work.
I don't believe that we should be aiming to replace Photoshop or The GIMP.
The rest of the interview is great, I recommend reading it.
Posted on 19 May 2006
Its been on my TODO list for ages.
Ideally, I should find myself an open source conference in Egypt as open-source based tourism is way better than just showing up at the airport and checking into your hotel.
Posted on 19 May 2006