Jb in a nutshell

Miguel blogged a list of iPhone applications that were made using Unity3D, and scripted with Mono.

I’m delighted to have cute applications using Mono to show, and one involves raptors!

One of the concern for Unity3D is to reduce the size of the download as much as possible. And Mono certainly weight a little bit in the download. We have a page on our wiki which describes how to reduce the size of the runtime, but am writing today about what Unity3D uses to reduce the size of the different managed parts, be it the core libraries, or the managed part of the game itself.

They are using two different tools to reduce the size of the assemblies. So first of all, once the application is compiled, the first tool they use is the Mono Linker. I already had the occasion to write about the linker, as it is a tool that I started writing during the second Google Summer of Code I spent as a student, and that I’ve worked on when I joined Novell. The linker is today a mature piece of code, that is exercised during every single Mono build, as it is used to produce the Moonlight 2.0 version of our class library.

So they are using the linker, and this makes sure that everything that is not needed by the game or the engine is removed from the assemblies.

When the linking stage is achieved, they pre-compile the assemblies to native code using our AOT (Ahead of Time) compiler. This is necessary, as the iPhone prevents any JIT to run.

After AOT, you end up with a native binary, and the original managed binary, which still contains the intermediate code. If the assembly has been completely AOTed, this intermediate code is no longer necessary.

Here comes the second tool they’re using. This is a tool which is pretty new, and that I wrote for this specific usage. It’s called `mono-cil-strip`, and is now built along the traditional tools that we ship, such as ilasm or the linker. It uses a special mode of Cecil I hacked on, which preserves the original metadata structure of the assembly, but empties every single method body. It’s necessary to keep the native binary in sync with the managed binary, while still removing parts of it.

If you’re compiling your assemblies ahead of time, and looking for some bytes to save, here’s a neat way to do so.

Sadly I don’t have numbers handy, so I’ll encourage you to give it a try, but here we are, every single iPhone application produced using Unity3D went through Cecil (twice!).

And that’s pretty cool :)

There was a discussion recently about why the class ExpressionVisitor, which every programmer that developed a LINQ provider or code manipulating .net 3.5 expression trees knows about.

I certainly agree that this class could have been made public, as basically everyone ends up embedding it. Even if it could use a little refactoring to visit lists.

Thing is that I have a naming issue with this class ever since I saw it on Matt’s blog. To me it does more than just visiting an expression tree. It allows you to transform it. And when I’m facing an expression tree, I often like to sometimes visit it, and at some other times, transform it.

That’s basically the reason why I have both a:

class ExpressionVisitor {

    public void Visit (Expression expression)
    {
        // ..
    }

    // ...
}

And a:

class ExpressionTransformer {

    public Expression Visit (Expression expression)
    {
        // ..
    }

    // ...
}

Simply because I write a lot of code that would look like:

SomethingExpression VisitSomethingExpression (SomethingExpression expression)
{
    if (Foo (expression))
        return expression;

    if (Bar (expression))
        return expression;

    Baz (expression);
    return expression;
}

And it looks a lot better (and is also a tiny bit faster) this way:

void VisitSomethingExpression (SomethingExpression expression)
{
    if (Foo (expression))
        return;

    if (Bar (expression))
        return;

    Baz (expression);
}

So if they make the current ExpressionVisitor public, having a real non transforming ExpressionVisitor will introduce an interesting naming issue.

I submitted a bug to the DLR CodePlex, as the namespace System.Linq.Expressions will come from the DLR in .net 4. What about voting for it?

As I was writing in my last entry, announcing the most awesome Cecil.Decompiler library, I took my last week off to host a CodeCamp event at my parents place in the quiet place of Ardèche, France.

I had the pleasure to host, by order of arrival,

• Romain Verdier
• Patrice Lamarche
• Vincent Bourdon
• Robert Pickering
• Mathieu Szablowski
• Sébastien Lebreton

While I was working on the core of the decompiler, I paired with Romain to work on improving our pattern matching story, to refine a basic AST to something more evolved. We still clearly need to do some work here, as we’re not completely satisfied with what we came with. Robert with his experience of F# and pattern matching then helped Romain.

Patrice worked on a NUnit addin which allow us to write tests that are executed for both optimized and non optimized code. He then joined Vincent to work on the Visual Basic language support. Vincent also wrote a ColoredConsoleFormatter, which adds some color to my tests in the console routines.

Robert started a Windows.Forms front tend in F# a while ago, but we decided to switch to C#, to lower the entry barrier for contributions. The inimitable Sébastien took the responsibility to write the front-end for the next millennium. I’ll force him to blog on it ASAP.

Mathieu took the pictures. He sadly was busy working on a presentation he had to do for a client next week.

On the next monday, Vincent told me something like: wow it’s quite depressing, I barely had a single laugh today, while we were laughing every five minutes during the last few days.

So we maybe weren’t the most productive crowd of week-end hackers, but at least we had tons of fun.

I guess that if I had a lesson to take from the event, it would have been to prepare it a little bit more, and have more fine grained tasks, but I also loved the organic way it evolved.

Thanks guys for the week-end, hopefully we’ll manage to organize more of those CodeCamp.

I know I’m quite late to present what I’ve been working on during the last Hack-Week we had at Novell, but better late than never, right?

Cecil.Decompiler is a library which relies on Cecil, takes one of its method, and give you back an object graph representing the decompiled body of the method, an AST, depending on the language you target. It also provides you ways to pretty print this AST at your convenience.

It takes its roots in Cecil and is actually a refactoring of the Cecil.FlowAnalysis library that folks at db4o contributed to the Mono project.

During the last Hack-Week, I started refactoring Cecil.FlowAnalysis, and since then, I’ve been working pretty seldom on it. It was last month that I decided to give it a kick, and even took a week of vacations to organize a CodeCamp with friends to give it a boost and have fun altogether.

The next blog post will be the occasion to describe the last week, and to thank my friends for their help.

Let me first warn you. It’s still very young, and doesn’t support a lot of constructions. On the other hand, it can already do pretty neat stuff, and its architecture makes it easy to use and improve, or add new languages.

The mandatory picture of a little program using the decompiler to decompile itself:

Don’t pay attention to the code as it’s full of debug code. Basically only the last two lines are interesting.

The code can be pulled from SVN:

http://anonsvn.mono-project.com/source/trunk/cecil/decompiler

I guess this will trigger a few interesting questions, so I cooked a little list of questions I already had, and answers I provided.

Q: What it is usable for?

A: It can be very useful for tools that perform static analysis on the assembly. For instance, Gendarme could use it to detect more complex patterns in your code.

Q: Why would you work on such a project while there’s obviously a better known tool that seems to do the same (and which have been working for a long time)?

A: Cecil.Decompiler is Open Source, and licensed under the very liberal MIT/X11. Also it’s a library, which makes it easy to use from your own IDE, tool, or whatever project you can think of.

Q: But then what’s a good library without a good GUI?

A: I’ll write more on that later, but my good friend Sébastien, author of the fantastic Reflexil project, started a Windows Forms GUI on top of it. And from what I understand, he plans to write the core of his tool using in platform agnostic fashion, so that plugins for his GUI could be re-used by a Gtk# GUI for instance.

Q: Why don’t you push a binary distribution for now?

A: The project is still very new, and we’re changing it a lot. So if someone is interested in having a look at it, he should rather directly pull the sources from SVN regularly.

Q: Should I start filing bugs ?

A: It’s not worth it fom now, we’re pretty much aware of what’s missing and failing.