Silverlight/C#, Flash/ActionScript 3 and Canvas/Javascript

by Miguel de Icaza

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:

Posted on 12 Aug 2009

C# 4's Dynamic in Mono

by Miguel de Icaza

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,
			    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#.

Posted on 11 Aug 2009

C# Sqlite

by Miguel de Icaza

Noah Hart did a line-by-line port of Sqlite to C# and has uploaded the code to

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 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).

Posted on 06 Aug 2009

MonoTouch: Mono on iPhone closed preview

by Miguel de Icaza

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.

Posted on 03 Aug 2009

MonoTouch: Mono on iPhone closed preview

by Miguel de Icaza

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.

Posted on 03 Aug 2009

Bridging C# and C++ on Unix

by Miguel de Icaza

Unlike Microsoft's .NET, Mono lacks a C++ compiler that can generate CIL code or mixed CIL/native code. This makes it harder for C++ codebases to integrate with C# code.

One solution to the problem is to write C wrappers for every C++ method and then use P/Invoke to call into each wrapper. Dealing with virtual methods then becomes challenging.

Andreia Gaita explains on Binding C++ APIs a technique that can be used to bridge the C++ and C# worlds using Mono's built-in support for COM objects.

Posted on 03 Aug 2009

IronRuby Progres

by Miguel de Icaza

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.

Posted on 03 Aug 2009

SUSE Studio is out - The Linux Appliance Builder

by Miguel de Icaza

Update: Nat Friedman has written two great blog posts on SUSE Studio, check them out here:

Today Novell announced the release of Nat's latest project: SUSE Studio. Nat has been working on this for a very long time.

Studio is a tool that allows anyone with a web browser to create Linux-based systems and appliances. We believe that this is one of Linux' major strengths and we wanted to turn this potential into a reality.

In addition to custom Linux builds, Nat's team has put a strong focus on Linux-based appliances.

The goal of an appliance is:

  • Perform a single task well.
  • Requires minimal assembly and setup.
  • It comes as a standalone unit.

The idea is that software developers can combine into a single deployable unit (a) the operating system; (b) your software plus any dependencies requires; (c) the proper configuration and data files required to operate.

When you build your appliance with Studio, you can select the kind of system you want, the packages you want to install, you can preconfigure the system and you can even test-drive the result over the web (it uses a Flash applet) and even fine tune or do some last minute touches over the web (inside the Flash applet) before producing your final version:

Test your Linux over the web.

The resulting Linux distribution can be downloaded as an ISO image, you can update it, you can create a bootable USB Linux system with your software, generate a VMWare image or VPC image and next week you should be able to deploy them in Amazon EC2.

We have been using Studio for building the Mono downloaded VMware/VPC images for a while. We bundle the latest Mono, MonoDevelop and various ASP.NET and Windows.Forms samples for developers to try out.

As a software developer, you can move from a world where you let the end users assemble the solution themselves:

Into a setup where you deliver the entire package to your end user:

The above scenario is common in the Linux world, non-existent in the OSX world, and only large OEMs are able to do the same on the Windows world.

What we wanted to do was enable anyone, with little Linux expertise to setup their own operating systems. You do not have to be an expert on kernels, boot loading, dependencies or anything else to produce your own operating system.

In addition to Unix software, we are going to make it very easy for Windows developers to bring their applications to Linux. Our Mono for Visual Studio project will now allow developers to go straight from Visual Studio into a Linux powered appliance:

Mono Visual Studio Plugin allows .NET to Appliance compilation.

Posted on 28 Jul 2009

Proposed C# extensions

by Miguel de Icaza

Scott Peterson has written a proposal to extend C# to support parameterless anonymous methods.

Scott's proposal includes a patch for Mono's C# compiler that implements the suggestion.

The short story is that with this patch allows constructor initializers to also initialize events in an object. So you can now write code like this:

var button = new Button () {
    Label = "Push Me",
    Relief = ReliefStyle.None,
    Clicked +=> Console.WriteLine ("ouch!")

Both Bockover and myself love the 3.0 initializer syntax for objects and the only place where the awesomeness broke was the event initialization.

Posted on 27 Jul 2009

Improving Mono's compatibility with .NET CLR

by Miguel de Icaza

For as long as we remember, most new versions of IronPython, IronRuby or the Dynamic Language Runtime exposed new missing functionality in Mono.

After a major release of any of these tools that deeply exercise the internal Reflection.Emit support and the runtime we would implement the missing features and ship a new Mono version.

As part of the Microsoft/Novell collaboration on Silverlight for Linux, a couple of months ago, we received from Microsoft the test suite for the Silverlight class libraries.

We have been working on fixing all of the issues exposed by the test suite. The test suite exposed bugs in Mono and missing features that are necessary for Silverlight in general, as well as the DLR and the DLR-based languages like IronRuby and IronPython.

We are pretty excited about the progress and the increased compatibility of Mono with Microsoft's .NET.

Posted on 27 Jul 2009

« Newer entries | Older entries »