With Mono, is has often happened that I have wanted to work on a fun new feature (say, C# 3) or implement a fun new class.

But most of the time, just when am about to do something fun for a change, I think "don't we have a lot of bugs out there to fix?", so I take a look at bugzilla and try to fix them, follow up on some bugs, try to produce test cases.

By the time am done, I have no energy left for the fun hack.

I need some "guilt-free" time, where I can indulge myself into doing some work that is completely pointless. But there is a fine balance between happy-fun-fun hacking, and making sure that Mono gets a great reputation.

Since a few folks have asked on irc and they are not using my innovative comment-reading service, am reposting (with some slight edits and clarifications) the answer to "Will Mono implement C# 3.0?"

Yes, we will be implementing C# 3.0.

We have been waiting for two reasons: first, we wanted to focus on bug fixing the existing compilers to ensure that we have a solid foundation to build upon. I very much like the Joel Test that states `Do you fix bugs before writing new code?'.

C# 3.0 is made up of about a dozen new small features. The features are very easy to implement but they rely heavily on the 2.0 foundation: iterators, anonymous methods, variable lifting and generics.

Since we have been fixing and improving the 2.0 compiler anyways, we get to implement the next draft of the specification instead of the current draft. This means that there is less code to rewrite when and if things change.

Fixing bugs first turned out to be a really important. In C# 3.0 lambda functions are built on the foundation laid out by anonymous methods. And it turned out that our anonymous method implementation even a few months ago had some very bad bugs on it. It took Martin Baulig a few months to completely fix it. I wrote about Martin's work here. The second piece is LINQ, some bits and pieces of the libraries have been implemented, those live in our Olive subproject. Alejandro Serrano and Marek Safar have contributed the core to the Query space, and Atsushi did some of the work on the XML Query libraries. We certainly could use help and contributions in that area.

Anecdote: we started on the C# 2.0 compiler about six months before C# 2.0 was actually announced at the 2003 PDC. Through ECMA we had early access to the virtual machine changes to support generics, and the language changes to C#. By the time of the PDC we had almost a functional generics compiler.

The spec was not set in stone, and it would change in subtle places for the next two years. So during the next two years we worked on and off in completing the support and implementing the changes to the language as it happened.

Most of the hard test cases came when C# 2.0 was released to the public as part of .NET 2.0. About six weeks into the release (mid-December and January) we started receiving a lot of bug reports from people that were using the new features.

Second Mini-Anecdote: Pretty much every new release of IronPython has exposed limitations in our runtime, our class libraries or our compilers. IronPython has really helped Mono become a better runtime.

Just minutes before the speech last night, Keith Olberman had a quick recap of the mistakes done so far.

Loved the delivery. Crooks and Liars has the video and the transcript (the video is better, as it has a moving sidebar with the summary, like Colbert's "The Word").

C# 3.0 introduces a number of small enhancements to the language. The combination of these enhancements is what drives the LINQ.

Although much of the focus has been on the SQL-like feeling that it gives the language to manipulate collections, XML and databases in an efficient way, some fascinating side effects are explored in this tutorial.

The tutorial introduces the new features in C# one by one, there are a couple of interesting examples, a simple functional-style loop:

// From:
for (int i = 1; i < 10; ++i) Console.WriteLine(i);

// To:
Sequence.Range(1, 10).ForEach(i => Console.WriteLine(i));
	

A nice introduction to delayed evaluation, an RPN calculator:

// the following computes (5*2)-1
Token[] tkns = {
    new Token(5),
    new Token(2),
    new Token(TokenType.Multiply),
    new Token(1),
    new Token(TokenType.Subtract)
};

Stack st = new Stack();

// The RPN Token Processor
tkns.Switch(
    i => (int)i.Type,
    s => st.Push(s.Operand),
    s => st.Push(st.Pop() + st.Pop()),
    s => st.Push(-st.Pop() + st.Pop()),
    s => st.Push(st.Pop() * st.Pop()),
    s => st.Push(1/st.Pop() * st.Pop())
);

Console.WriteLine(st.Pop());

And finally a section on how to parse WordML using LINQ, extracting the text:

	wordDoc.Element(w + "body").Descendants(w + "p").
		Select(p => new {
        		ParagraphNode = p,
        		Style = GetParagraphStyle(p),
        		ParaText = p.Elements(w + "r").Elements(w + "t").
				Aggregate("", (s1, i1) => s1 = s1 + (string)i1)}).
		Foreach(p =>
			 Console.WriteLine("{0} {1}", p.Style.PadRight(12), p.ParaText));
	

Very educational read.

After the release of the SecondLife client as open source software, Cory has a pre-town hall answers post.

The SecondLife client is dual licensed under the GPL and commercial licenses.

Regarding the use of Mono, Cory states:

Open Sourcing the client does not impact continued development of Mono or other planned improvements to LSL. Although Mono is also an Open Source project, that code will be running on the server, not the client. As has been previously discussed, part of the reason for going to Mono and the Common Language Runtime is to eventually allow more flexibility in scripting language choice.

Cory explains some of the rationale for open sourcing the client:

Third, security. While many of you raised question about security, the reality is that Open Source will result in a more secure viewer and Second Life for everyone. Will exploits be found as a result of code examination? Almost certainly, but the odds are far higher than the person discovering the bug is someone working to make Second Life better. Would those exploits have been found by reverse engineering in order to crack the client? Yes, but with a far smaller chance that the exploit will be made public. Also, as part of the preparation for Open Source, we conducted a security audit and took other precautions to mitigate the security risks.

Fourth, as we continue to scale the Second Life development team --- and thank you to the many folks who have helped to get our hiring pipeline humming again --- Open Source becomes a great way for potential developers to demonstrate their skill and creativity with our code. Moreover, it makes it even easier for remote developers to become part of Linden Lab. The possibility space for Second Life is enormous, so the more development horsepower we can apply to it --- whether working for Linden Lab or now --- the faster we all can take Second Life from where it is today into the future.

And also, a new book on SecondLife is coming out.

Rolf has committed to SVN his latest batch of changes that allowed his Visual Basic.NET compiler to bootstrap under Mono/Linux. This basically means that the full cycle for VB in Mono has now been completed.

Rolf's VB compiler is an implementation of Visual Basic.NET version 8. So it has support for generics and all the new stuff in the language.

Rolf wrote his compiler in VB itself, and he uses generics everywhere, so in addition of being a good self-test, it has proven to be a good test for Mono (he already has identified a few spots where the Mono JIT should be tuned).

The following are from an internal email he sent on Friday (am trying to convince him to have a blog and blog these fun facts):

Friday Results:

        compile vbnc with vbc:                      4.8 seconds
        compile vbnc with vbnc/MS:                 14.2 seconds
        compile vbnc with vbnc/Mono/Linux:         15.1 seconds
        compile vbnc using a bootstrapped binary:  19.0 seconds

        compile vbruntime with vbc:                 1.4 seconds
        compile vbruntime with vbnc/MS:             3.5 seconds
        compile vbruntime with vbnc/Mono/Linux:     4.2 seconds
        compile vbruntime with bootstrapped binary: 4.9 seconds

The memory consumption on Friday was at 475 megs of RAM. Ben and Atsushi provided some suggestions, and the results for Monday are:

	compile vbnc using a bootstrapped binary:  10.0 seconds

	Memory usage: 264 MB

In managed applications memory allocations are important, because they have an impact on performance. Also notice that memory usage as reported by the Mono default profiler, means all the memory allocation. The actual working set is much smaller, since the GC will reuse all unused memory.

Atsushi also has a few tune-ups to the string class that reduces plenty of the extra allocations that the compiler was incurring into.

To bootstrap your own VBNC compiler, get the vbnc module, then go into the vbnc/bin directory, and run make bootstrap.

Bonus: in addition to bootstrapping itself, the compiler can now compile the Microsoft.VisualBasic runtime (the new version is written in VB.NET as well). And can do a full bootstrap with the new runtime as well.

Although binaries compiled with Microsoft's VB.NET compiler would run unmodified on Linux, it was not possible to use VB code in ASP.NET applications (as those get compiled on the first page hit) or if developers wanted to debug and tune up a few things on their target Linux/OSX machine.

In the next few weeks we hope to have this packaged.

I will exchange an equivalent number of hours hacking your favorite Mono feature in exchange for someone implementing Google Calendar support into Evolution.

The APIs to use Google calendar service are here.

Meta-proposal: someone writes a "Software Contribution Exchange" (SCE) where people offer patches to software in exchange for patches in other applications. The NASDAQ of patches.

I just had a stroke of genius.

My blog software is this home-grown tiny program that generates static HTML, and never quite bothered to turn that into a server application for the sake of supporting comments.

So I was looking to host comments on some comment hosting provider like HaloScan, I signed up, registered but was not very happy with the interface offered to posters. For anything more than a small form, you have to upgrade the basic account.

The stroke of genius was to create a Google Group for my blog and just link to it. That way I get adequate tools to manage the comments, and posters get adequate tools to track it.

Thanks, thanks; you are welcome; I know!; yes, yes; I love that show too. You can just put your donation in the hat.

The open question is whether the comment link should only appear on the blog, or it should also appear at the end of each entry on the RSS feed, for the sake of those using things like Google Reader. Discuss among yourselves.

Seems like my favorite blog Billmon is off the air.

Since Billmon hinted for a while that he was going to stop blogging, I made a backup of his site a few days before he shut down the site.

If you are a Billmon fan, and want to get a copy of the archive I made, you can get it here (Hosted at Coral).

Aaron Bockover has a couple of interesting posts on the Banshee music player:

• Scripting Banshee. Aaron embedded the Boo language into Banshee to help prototype, test and extend it.
• Audio Profile Configuration for the Masses: in which he presents his work to provide a user friendly interface to configuring your underlying media platform.
  Screencast and screenshots included.
• Radio Support in Banshee. Check his description of the implementation, but most importantly of his use of the Rhapsody Web Services to match the radio music with cover art, artist information and more.

Aaron has shown his craftsmanship in building Banshee, which is a labor of love.

Paco posted a few screenshots of Gtk SQL# a tool to interact with SQL databases using the System.Data API.

The Mono.Xna developers continue to make progress. Alan blogs about the progress here.

Jonathan Pobst will be joining the Managed Windows.Forms team at Novell on Monday. Jonathan has been a Windows.Forms 2.0 contributor and also developed the Mono Migration Assistant tool (Moma).