Is it that time of the year when I unleash Google Docs' Survey platform on the users of my blog.

Every once in a while people ask us "When will you support Mono on..." and our answer is usually "thanks for your feedback, we will carefully consider it".

The reality is that all we have at this point is a lot of anecdotal data. Since my previous surveys on Mono, Mono for OSX, Mono for the iPhone and Mono for Visual Studio turned out to be great tools to understand what people actually want, I have created a new survey.

In this survey, I want to know how much people are willing to pay for (or not pay) for Mono commercial support on a variety of platforms: Red Hat Enterprise Linux, HP-UX, AIX, Solaris on a variety of architectures.

Go to my survey

The .NET and Mono user communities are working together in Spain to organize a joint .NET/Mono Code Camp. This Code Camp is going to be interesting because it is putting together two communities with very different points of view, but between which there is a lot of synergy. It will be a good chance to talk about Mono, Moonlight, MonoDevelop, MonoTouch and all the stuff we are working on.

Lluis just announced that the call for papers is ending this Friday, so not much time is left if you want to participate with a talk. There are more details in his blog post

While I was gone, a pretty nice site called MonoTouch.infowas created that is aggregating all kinds of MonoTouch samples, posts, and discussions.

From the MonoTouch Bill Splitter page.

It is aggregating many of the samples being discussed in the tweetosphere and from the MonoTouch mailing list.

The samples are particularly useful as MonoTouch merges two worlds: .NET development and Objective-C programming on the iPhone/iTouch.

MonoTouch supports the Objective-C like setup where classes can respond to messages and you have to structure your code with MVC patterns. But it also supports the C# event-style programming mode, where developers can use lambda functions to hook up to interesting events.

You can also follow @monotouchinfo on twitter.

Meinrad Recheis emailed me to inform me that he has forked the Gitty project (a project that was doing a line-by-line port of a Java version of GIT) and that the project is making progress on having a full C# based GIT implementation.

GitSharp source code can be downloaded from github and they are making sure that GitSharp works on both .NET and Mono.

I can not wait for a MonoDevelop UI for it!

Been following some of the discussion around Action Script 3 on the tweetosphere. Here are three implementations of the same model from Joa Ebert (he works on a fabulous Flash product for doing music that I absolutely love).

From his Flirting with Silverlight post:

Lately a lot of discussion had the ActionScript language as its focus. People start complaining about complex language features but I think they are great because the end user will benefit from that. Yesterday evening I had my very first test with Silverlight — and I am really impressed.

It took me a short amount of time to port the strange attractor to Silverlight. I agree that this is may be not a fair comparison because I know C# already but have a look at the source code. I make heavy use of type inference and the Matrix4x4 class has the plus, multiply and array-index operator overloaded. The code is more readable. And besides: it executes really fast. Faster than my heavily optimized ActionScript version. Imagine I would write var bleh = 1.0 in ActionScript. Framerate would drop to something like zero. But this is sad since there is no reason for me to write var bleh: Number = 1.0. A modern compiler should be able to figure this out. haXe can do it, C# can do it, OCaml can do it and lots of others as well.

Remember: This was my first time using Silverlight. To achieve the same result with Flash you have to be kind of an expert in strange player and language “features”. Now tell me again that the end user will not benefit.

Here are the three implementations:

• Silverlight/C#.
• Canvas/Javascript.
• Flash/ActionScript 3

C# 4.0 introduces the dynamic type into the language. The language will ship in Visual Studio 2010.

Once a variable is declared as having type dynamic, operations on these value are not done or verified at compile time, but instead happen entirely at runtime.

Marek has been working on Mono's C# 4 implementation and it is coming along nicely. Zoltan wrote a small "PInvoke" dynamic class using Mono's C# compiler that allows you to call C library methods like this:

	dynamic d = new PInvoke ("libc");
	d.printf ("I have been clicked %d times", times);
	

In this case "printf" is resolved at runtime to be a method in the "libc" library. This is similar to Python's ctype library in about 70 lines of C# leveraging LINQ Expression, the Dynamic Language Runtime and C#'s dynamic:

The code is:

using System;
using System.Dynamic;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
using System.Threading;
using System.Linq.Expressions;

class PInvokeMetaObject : DynamicMetaObject {

    public PInvokeMetaObject (Expression parameter, object o) :
        base (parameter, BindingRestrictions.Empty, o) { }

    public override DynamicMetaObject BindInvokeMember (InvokeMemberBinder binder, DynamicMetaObject[] args) {

        var self = this.Expression;
        var pinvoke = (PInvoke)base.Value;

        var arg_types = new Type [args.Length];
        var arg_exps = new Expression [args.Length];

        for (int i = 0; i < args.Length; ++i) {
            arg_types [i] = args [i].LimitType;
            arg_exps [i] = args [i].Expression;
        }

        var m = pinvoke.GetInvoke (binder.Name, arg_types);
        var target = Expression.Block (
			    Expression.Call (m, arg_exps),
			    Expression.Default (typeof (object)));
        var restrictions = BindingRestrictions.GetTypeRestriction (self, typeof (PInvoke));

        return new DynamicMetaObject (target, restrictions);
    }
}

public class PInvoke : DynamicObject {
    string dll;

    AssemblyBuilder ab;
    ModuleBuilder moduleb;
    int id_gen;

    public PInvoke (string dll) {
        this.dll = dll;
    }

    public override DynamicMetaObject GetMetaObject (Expression parameter) {
        return new PInvokeMetaObject (parameter, this);
    }

    public MethodInfo GetInvoke (string entry_point, Type[] arg_types) {
        if (ab == null) {
            AssemblyName aname = new AssemblyName ("ctype");
            ab = AppDomain.CurrentDomain.DefineDynamicAssembly (aname, AssemblyBuilderAccess.Run);
            moduleb = ab.DefineDynamicModule ("ctype");
        }

        // Can't use DynamicMethod as they don't support custom attributes
        var tb = moduleb.DefineType ("ctype_" + Interlocked.Increment (ref id_gen) + "_" + entry_point);

        tb.DefinePInvokeMethod ("Invoke", dll, entry_point,
			    MethodAttributes.Static|MethodAttributes.PinvokeImpl,
			    CallingConventions.Standard, typeof
			    (void), arg_types,
			    CallingConvention.StdCall, CharSet.Auto);

        var t = tb.CreateType ();
        var m = t.GetMethod ("Invoke", BindingFlags.Static|BindingFlags.NonPublic);

        return m;
    }
}

public class Tests
{
    public static void Main (String[] args) {
        dynamic d = new PInvoke ("libc");

        for (int i = 0; i < 100; ++i)
            d.printf ("Hello, World %d\n", i);
    }
}    
	

You can download the C# 4.0 Future document for details.

Mono's C# 4 compiler so far implements optional parameters, named parameters, has support for the new covariant and contravariant specifiers and the dynamic keyword is evolving very quickly (as shown by the example above).

If you want to test drive Mono's C# 4.0 compiler, you need Mono from Git and you must pass the "--enable-profile4=yes" argument. Once you do this, the new compiler will be installed as dmcs on your system.

Nikhil has a nice sample that shows JSon integrated directly into C#.

Noah Hart did a line-by-line port of Sqlite to C# and has uploaded the code to code.google.com/p/csharp-sqlite.

The frequently asked questions on the web site talks about performance (it is about 5 times slower than native code, but still, it can do 1.5 million selects per second, 300k inserts per second).

Still, not bad for a line-by-line port; Folks on the #mono channel on irc.gnome.org a couple of days ago were commenting on the possible ways of tuning it up by not forcing the C way where the C# way would work just fine.

The potential for this library is huge. It could be used for ASP.NET servers running in medium trust mode, or it could be used by Silverlight applications.

It seems like Tim Anderson is attempting to remove all the P/Invokes from it to make it run on Silverlight (the P/Invokes are mostly used for doing file-level locking; Again part of the line-by-line history of it).

Antonio Cangiano from IBM compares the performance of the recently released IronRuby with Ruby 1.8 and 1.9 on Windows.

On his blog post he looks at both the micro benchmarks and overall benchmarks. The summarized results:

Antonio comment:

IronRuby went from being much slower than Ruby MRI to considerably faster across nearly all the tests. That’s major progress for sure, and the team behind the project deserves mad props for it.

One final warning before we get too excited here. IronRuby is not faster than Ruby 1.9.1 at this stage. Don’t let that first chart mislead you. While it’s faster in certain tests, it’s also slower is many others. Currently, it’s situated between Ruby 1.8.6 and Ruby 1.9.1, but much closer to the latter. The reason why this chart is misleading is that it doesn’t take into account any tests that timed out, and several of such timeouts were caused by IronRuby (more than those caused by Ruby 1.9.1). If you were to add, say, 300 seconds to the total, for each timeout for the two implementations, you’d quickly see that Ruby 1.9.1 still has the edge. The second chart that compares macro-benchmarks does a better job at realistically showing how IronRuby sits between Ruby 1.8.6 and Ruby 1.9.1 from a performance standpoint. If you were to plot every single benchmark on a chart, you’d find a similar outcomes for a large percentage of the tests.

Whether it’s faster than Ruby 1.9 or not, now that good performances are staring to show up, it’s easier to see IronRuby delivering on it’s goal of becoming the main implementation choice for those who both develop and deploy on Windows. This, paired with the .NET and possible Visual Studio integration, the great tools available to .NET developers, and the ability to execute Ruby code in the browser client-side thanks to projects like Silverlight/Moonlight and Gestalt, make the project all the more interesting.

We have reached feature completion status for our MonoTouch project and we are looking for some adventurous iPhone developers that might be interested in trying out Mono for the iPhone and the MonoTouch APIs (A C# API for building Cocoa applications).

We are doing a closed preview to gather feedback on MonoTouch, if you would like to be part of this preview/beta, please fill out the signup form.

You can browse the source code for the sample widget catalog built using the MonoTouch.UIKit .NET binding to Cocoa's UIKit.

We have reached feature completion status for our MonoTouch project and we are looking for some adventurous iPhone developers that might be interested in trying out Mono for the iPhone and the MonoTouch APIs (A C# API for building Cocoa applications).

We are doing a closed preview to gather feedback on MonoTouch, if you would like to be part of this preview/beta, please fill out the signup form.

You can browse the source code for the sample widget catalog built using the MonoTouch.UIKit .NET binding to Cocoa's UIKit.