Jb in a nutshell

newton:~/Sources/temp jbevain$ monodis dummy.dll 
.assembly 'dummy'
{
  .hash algorithm 0x00000000
  .ver  0:0:0:0
}

.module Dummy // GUID = {1764306C-0167-41BE-86B8-52ED3980F771}

Pretty simple assembly huh? Well, I’ve never been as happy to see the output of monodis. After three days of hard work, it is what Cecil produced while running this code:

<span class="kwrd">using</span> System;

<span class="kwrd">using</span> Mono.Cecil;

<span class="kwrd">public</span> <span class="kwrd">class</span> EntryPoint {

    <span class="kwrd">public</span> <span class="kwrd">static</span> <span class="kwrd">void</span> Main ()
    {
        Console.WriteLine (<span class="str">"Running ..."</span>);
        WriteDummyAssembly ();
        Console.WriteLine (<span class="str">"... Ended"</span>);
    }

    <span class="kwrd">public</span> <span class="kwrd">static</span> <span class="kwrd">void</span> WriteDummyAssembly ()
    {
        IAssemblyDefinition asm = AssemblyFactory.DefineAssembly (
            <span class="str">"dummy"</span>, <span class="str">"Dummy"</span>, TargetRuntime.NET_1_1);
        AssemblyFactory.SaveAssembly (asm, <span class="str">"dummy.dll"</span>, AssemblyKind.Dll);
    }
}

This does not looks very complicated but believe me, writing PE binary are neither simple nor fun. The good news is that both Mono and Cecil are able to read this assembly. I mean, Cecil can read assemblies it has produced, wow, isn’t there some kind of beauty here ? The bad news is that Microsoft’s Framework still throws me an error, but heh!

Ok ok, stop blogging, go back to work.

El Miguel blogged about the third revision of the ECMA CLI 335 standard.

As the author of a library that should be able to emit assemblies compliant to the above standard, I’ve been happy to see in this document the description of a standardized debugging symbols store, just like Microsoft’s PDB, and Mono’s MDB. Having, and using, such a standard, would allow users to share debugging infos between differents CLI informations. For instance you’re developping an ASP.NET site on Windows in Visual Studio, you compile the whole thing in Debug mode, and then, you deploy your libraries on a Linux server, hosting XSP. If an error occurs in your code, you would be able to see exactly where. Otherwise, the detail level for an error in a Release configuration is the method. Not very easy to find where errors are in this way.

So the idea of having a file format standardized is somewhat exciting. Especially for me, since I won’t have to write a factory of debugging store emitters…

After some discussions and investigations, it appears that the CLIDB format is the kind of symbols store that the SSCLI (aka Rotor) emits. Also I’ve been said that Microsoft does not plans to implement this standard, because they’re happy with their PDB files. Also, if Microsoft’s CLR does not understands this format, and .net compilers are not able to emit this kind of store, why would Mono implement this standard, as they already have a file format?

Let me recap:

• This day, we can’t share debugging infos between CLI implementations.
• Mono emits its own, but Open Source MDB format.
• Microsoft’s CLR emits Microsoft’s PDB files.
• Microsoft is not willing to open the PDB file format, they consider it as an internal feature.
• Microsoft has open the format used by its Open Source implementation of the CLI (the SSCLI): the CLIDB file format.
• The CLIDB file format is now part of the ECMA-335 CLI standard.
• But why would other implementors use this file format instead of their own if the main one does not the same?

If you’re just like me willing to be able to use one and only one file format to store debugging symbols, please let Microsoft know it.

The Tech-Ed itself

Last week, I attended Tech-Ed Europe. Wow, at least six thousand people were there. The average level of talks was pretty good. Things like Indigo and the DSL tools seems at least promising. There is a bunch of blogs about the event, so I won’t make another one.

It was nice to meet there L’ami Sami, Jean-Louis, and Rafi from the Mainsoft team.

It’s the only Mono t-shirt i’ve spotted during the whole event!

My friend Mathieu and I decided that we both needed a picture “a la” Ingo Rammer, here is mine:

Sadly, now that I have one, I’m still not as smart as him. His first talk was simple, yet effective, and he is a very skilled speaker. Yes, i’ve been impressed by this one.

Amsterdam

Amsterdam is a somewhat disturbing city. People there are loving blue and yellow things during the day, like their trains for instance:

I know that you know, the color they love at night:

Ok, it was not the one you expected. You won’t have pics of the red district. Please note that this picture has nothing to do with Mainsoft.

At least two or three people by day have asked us “extasy ? coke ?” while we were walking through the city. Another one asked us “sucking ? licking ? fucking ?”. Somewhat disturbing I said.

However, i’ve loved the architecture of the city, and some appartements looked very nice, but the life there seems very expensive. More than in Paris…

I’m now working back on Cecil, but this will be the subject of another blog entry.

I’ve played with Lego today

Well, it was some kind of special Lego… I’ve taken bricks from :

• A nice tutorial about Tray Icons for GNOME
• An perfect and simple example
• An amazing Mono Live
• GPL icons from a nice project
• A simple ATOM feed

With those bricks, I’ve made a very simple and totally incomplete GMail Notification Icon for GNOME. It looks like that:

Yet, it’s no really usable. Username and password are hard-coded, and you just know if you have, or not, unread mails.

If someone is willing to use my code to produce a better applet, he would not have a lot of things to do. The list is simple:

• Use GConf to save username and password
• Write a really simple window to ask user whether or not username and password have to be stored
• Write another simple window to be shown when a new mail arrives, and then disappears

This nice person will find the code here: GMailTray