MJHutchinson.com Michael Hutchinson's Home on the Web

When I initially wrote the ASP.NET code completion, I added support for completing attribute values for enums and bools. More generalised completion using TypeConverter.GetStandardValues isn't so easy, since I don't want to load arbitrary types into the MD process, so I skipped this for now. However, I did special-case System.Drawing.Color, since it's used a lot.

This morning, based on a suggestion from Aaron, I tweaked it to generate custom icons for each colour:

In other news, I landed the new ASP.NET completion parser, which is much more robust, and is also able to generate a tree, so it will soon replace the DOM parser too. The new design also means I'll be able to unify it with the XML and Moonlight (XAML) addins.

I recently returned from a family holiday in Maine, and will post photos when I got them sorted out and uploaded to Flickr.

I have been making good progress on ASP.NET source editing, as evidenced by the following screenshot:

Yes, that is code folding, error underlining, and a path bar. However, the document outline pad isn't hooked up yet for ASP.NET[Update 2008/5/2: outlining implemented].

I've been getting a lot of practical experience with handwritten parsers recently. The ASP.NET addin has two parsers; the first builds a full DOM, and the second provides document path information very efficiently.

The path parser is designed to accept individual characters as the user types them, instantly providing information about the current context. This is very useful for code completion and smart indentation, and is obviously near-ideal for the path bar too. It's about as robust as I can make it, recovering effectively from most errors. However, I wrote a state-based XML parser where each state was a path object, which has proved rather unwieldy to extend cleanly for ASP.NET, so this may well get replaced soon.

The DOM parser was originally written for the CodeBehind field generation. It's based on Mono's ASP.NET tokeniser, which makes it rather fragile; when it encounters a syntax error, it dies. For its original use, this is sensible behaviour, but for a text editor it needs to be much more robust, so I intend to modify the path parser to build this DOM instead.

I plan to roll a lot of this back into the XML addin, which will provide a solid base for XAML completion for Moonlight apps.

Today I implemented an oft-requested feature for MonoDevelop: making the code completion and info tooltips transparent when the Control key is held down. This enables you to take a look at the code that the window's obscuring, without dismissing the popup:

This feature's in MonoDevelop trunk, and can be tried out right away. You'll need GTK+ 2.12 or above (GTK# only needs to be 2.8 or above) and Compiz or any other compositing window manager. It's also available in my MonoDevelop trunk builds on the openSUSE build service.

This behaviour is encapsulated in a class that can be attached to any Gtk.Window, and handles a couple of nasty hacks and workarounds.

Here's a quick summary of interesting things from the past few months that I haven't blogged. Unfortunately I can't give each topic the time it deserves, but I think that's better than not mentioning them at all.

GHOP Results

The Google Highly Open Participation contest finished, and was a great success, with 40 completed tasks, a great improvement over my earlier post. Of particular note was the huge number of rules implemented for Gendarme. I'd like to thank all of our successful students and their mentors, and congratulations to Dan Abramov, our Grand Prize winner. I'd also like to single out Andreas Noever, another absolutely stellar student who very narrowly missed out on the top spot.

Novell Hack Week

During Novell Hack Week I worked on an automatic error reporting system that I intend to use in MonoDevelop at some point. I got rather hung up on collecting as much system and process information as I could, so it unfortunately wasn't completed.

However, I did have fun "architecting" a client/server/webserver data channel, which I planned to re-use for several other purposes: reporting problems' solutions back to the user, and collecting application usage data. Now that I've seen how useful such data can be, in Jensen Harris's awesome presentation on how the Microsoft Office ribbon was developed, I'm particularly interested in having something similar in MonoDevelop.

Game Developer's Conference

Towards the end of February some of us on the Mono team went to the Game Developers Conference in San Francisco to promote Mono as a game scripting engine, and find out what games developers need to make this work for them. All in all it was great fun, and very successful. Miguel has a longer writeup.

I would be interested to find out what we could do to make Mono more attractive for gaming, both for embedding as a scripting engine, and as a portable runtime, and how this could be supported by MonoDevelop. One of the real strengths of Mono is the development tools, and I would like MonoDevelop to become part of the gaming development ecosystem. One suggestion would be an "Axiom Studio" addin for MonoDevelop as an alternative to XNA.

MonoDevelop 1.0 Release

After years of development, we released MonoDevelop 1.0 alongside Mono 1.9, and work is already well underway on the next release. I'm already working on ASP.NET code completion, which is coming along quite nicely. I've also updated and integrated Matt Ward's XML Editor into MonoDevelop trunk.

Google Summer of Code

MonoDevelop is once again taking part in the Google Summer of Code under Mono's umbrella. I really enjoyed mentoring Marcos last year, and I'm looking forward to doing some mentoring this year.

Visit to the UK

These past couple of weeks I was in the UK visiting family and friends. it was nice to see people again after 5 months in another continent!

Unfortunately, I have blogged very little in recent months. I shall follow this post with a summary of the things I've skipped blogging, but for now, I offer up the following tantalising screenshot by way of apology:

Now that MonoDevelop 1.0 is on the verge of shipping, I have begun to plan the parser that will underpin the ASP.NET code completion and visual designer in upcoming versions of MonoDevelop. During a discussion with our ASP.NET expert Marek, I found out about an obscure ASP.NET feature that currently causes problems for Mono's ASP.NET parser, and is entirely counterintuitive to anyone with any XML knowledge.

The Google Highly Open Participation (GHOP) contest has been running for a couple of weeks now, and the Mono Project has seen a fair bit of action. Sadly we've only had five completed tasks, with a couple more almost done. On a lot of the claimed tasks, many of the students and mentors have been slow to act, busy with real life work. I think that the timescale of the tasks makes things difficult. It's not easy to think up a task that an inexperienced student can complete within five days, especially considering that they often need to get up to speed with the technologies before starting, and need to fit it in around schoolwork. Hopefully now that the Christmas holidays are beginning, students will have a lot more time to spend on the GHOP!

I apologise to any student who's been held up from starting further tasks because of delays in reviewing and closing the tasks. Doing a proper job takes quite a bit of time, and the Mono team has a lot of other important things to do too, like getting the shiny new Mono 1.2.6 and MonoDevelop 1.0 Beta 3 releases ready.

I'd like to put out a general request to everyone and anyone in the Mono community, or working with Mono-based apps, to lend a hand for the GHOP. You can submit proposals for tasks on the Mono GHOP issue tracker, and critique students' work. It doesn't matter if you can't write code — help with docs or icons. Go out and send students our way. This has the potential to be a huge community event. You can find us hanging out on #mono-ghop as well as the usual IRC channels on GIMPNet IRC.

So far, all five completed tasks for the Mono GHOP have been MonoDevelop -related. I'm really pleased with the amount of interest we've had so far. I'd like to thank our hard-working students and mentors, and the wonderful people at Google's Open-Source Program Office who put this contest together.

• Dan Abramov submitted a very cleanly-written addin to integrate the Smokey code analysis tool . I'll be using this to tidy up minor bugs in the MonoDevelop codebase, and hopefully we can ship it in the addin repository after the 1.0 release.
• This was followed by some fantastic icons from Vinicius Depizzol ("videpizzol"), and these will certainly be in the 1.0 release. They're not yet in SVN due to my pending review of our icon usage and handling in MonoDevelop.
• The completed Brazilian Portuguese translation by Renato Felipe Atilio ("renatoat") is now our most up-to-date first translation, though due to changes to our translation infrastructure it's not merged into SVN yet.
• The latest addition to our still-meagre documentation comes from "entereczek", a Tutorial for C/C++ Projects. I've put it on the MonoDevelop wiki.
• Although not strictly a MonoDevelop contribution, "dwashing" created a MonoDevelop solution for F-Spot that's been committed to SVN.

Please continue to suggest, claim and review tasks. We still have plenty left on the issue tracker over at Google Code.Pop over to #mono-ghop on GIMPNet IRC to discuss things or to hang out with us.

[UPDATE]: It has been pointed out to me that the premise of this article is wrong. The compiler specifically avoids this problem by hoisting the captured variables into an inner class of which the generated method is also an instance member, and creating a new instance of this class for each call. I'm not sure what bug I ran into that causes the behaviour I denounced, or whether it was simply sloppy handling of reference types on my part -- but I feel particularly stupid having vaguely remembered "inner classes" from reading Raymond Chen's fine explanation of this over a year ago, yet not having checked it before posting this article. Nonetheless, I shall let the article remain as a reminder of the code that this wonderful feature saves you from having to write. Also, the queue/lock-based code may still be useful when one needs data passed to the GTK thread in a guaranteed order.

Anonymous delegates are incredibly useful, especially in that they can "capture" variables from a parent scope. Used within a single thread, they are very easy to understand. However, if you're using them to pass data across threads, you need to understand how the variable capture works.

Consider the following code snippet, in which the "data" variable is captured from the delegate's parent scope.

void ProcessIncomingData (string data)
{
Gtk.Application.Invoke (delegate (object sender, EventArgs e) {
textBuffer.AddText (data);
});
}


What's wrong with this?

It's a bad idea to mess with the packaged version of Mono on your Linux distro by installing another version of Mono on top of it or into another of your distro's standard prefixes such as /usr/local. Your distro's developers, testers and packagers have tested the packaged version of Mono to make sure that it works with the various applications that depend on it, such as MonoDevelop, Tomboy, F-Spot, Beagle and Banshee. In addition, you're likely to end up with unusual errors due to mismatched bits and pieces interacting in unpredictable ways.

If you need a more recent version in order to test new features and bugfixes, please keep a properly separated parallel Mono environment. By following these instructions you can ensure that you don't affect your stable Mono platform while experimenting with newer versions.

This applies to platform bindings such as GTK#, GtkSourceView# and GNOME# too!