Ports: August has been a good month for Mono ports. Zoltan has completed the JIT port to the IA64 platform, another 64 bit port of the Mono VM. Wade has made some RPMs based on a CVS snapshot that you can install on SLES9/IA64 (Update: Link to an external site with the snapshots).
In the meantime Paolo has made significant progress on the ARM JIT port. It is now running on both little-endian and big-endian machines. Geoff even managed to build Mono and run Mono on his 133 Mhz Linksys machine
Plenty of progress on the students from Google's Summer of Code:
XBuild: Marek reports that his implementation of msbuild (xbuild) is now able to compile itself. Congratulations!
ASP.NET Editor: Michael has merged Blago's code into the ASP.NET editor and it is now possible to create ASP.NET controls and also edit the HTML with the Mozilla editor. You can see his screenshot here. The code is available from SVN from the module `aspeditor'.
XAML Compiler: Iain has reached feature completion on his XAML compiler.
Bug Finder: Aaron report talks about some real bugs being found by his bug finding tool. His bug finding tool uses the Cecil library to read the metadata and analizes the program for known mistakes that developers incur on.
DIVA: This is probably the flashiest and most visual of all the summer of code projects. This is a video editor that uses GStreamer. I recommend you read Michael's blog which is gives a detailed description of his progress and has various videos of the various UI widgets he has created to create an open source video editor with Mono and Gtk#. Michael just integrated Mono.Cairo into his application to polish various of his widgets.
Compilers: Florian assisted Cesar in various JScript tests and the results are very promising. Mono's JScript compiler is passing more and more of the Rhino tests. Jaen checked in his Ruby.NET compiler into the repository and Florian has been assisting a bit. Discussion is happening on the #ruby.net channel on irc.gnome.org.
Work on GCC CIL has made great progress but suffered a set back as Jey broke his wrist this week.
And finally PHP.NET is on schedule to complete the goals that Raffa signed up for in the summer of code. He will continue working on the other milestones as part of his university work after the summer is over.
Cecil: Cecil continues to make progress. The best way of tracking Cecil progress is on JB's blog. It is now capable of writing assemblies and hopefully soon we can start on the Mono diet linker.
Monodoc: has received plenty of improvements: now it uses Mozilla, has font changing features, can summarize contributions, supports CSS rendering and integrated Lucene indexing to search the contents of documentation.
DataGrid: Pedro continues to make progress on the Winforms DataGrid widget. His code hopefully can soon go into SVN.
ASP.NET: We just landed a large patch to our implementation of ASP.NET.
Libgdiplus: Now that Cairo 1.0 and the API is frozen we ported Libgdiplus to use the new version of Cairo. The code is almost ready to be landed on the main branch but there are a few loose ends still required before we commit it. The good news is that Windows.Forms applications are now significantly faster.
MSDN Browser: Ben wrote a beautiful piece of code: a Gtk# client application for browsing MSDN documentation. The beauty? 220 lines of C# take a look at it and marvel at all the features Ben is using.
IronPython: Zoltan has fixed pretty much all bugs in Mono that prevented Mono from running IronPython 0.9 and its included regression test suite. We have identified a couple of problems that still must be fixed, but hopefully they will be in place by the time we release Mono 1.1.9.
MCS Just when we thought that we were done with the C# compiler Microsoft rectified a problem in the Nullable Types specification. We are all glad that they did and Hari is working on fixing this. In the meantime Marek and Atsushi continue on a quest to eliminate MCS bugs and to make the compiler stricter and more useful.
There is one regression in the usefulness of mcs that I have noticed recently. In the past the compiler would continue reporting errors for other problem areas in your source, but now it stops too early. Way too early. So when you have been hacking for a few hours straight you might need a few builds to get all the errors ironed out. You always do, but we used to need less.
The problem originates in that in a few places in the compiler we decided that if we can not compile a chunk it was best to stop processing and not continue as the compiler might depend on the types being defined and that might cause the compiler to crash. At the time, I felt that it was best to stop the compiler, but now am thinking that maybe we would serve our users best if we coped with incomplete trees in the compiler and produce more errors. It wont be easy to change this though.
Posted on 27 Aug 2005