Jb in a nutshell

Ohloh Journal

Jb Evain — Sat, 07 Jun 2008 14:39:00 +0200

I’ve recently noticed that ohloh now allows you to publish a journal, made of short entries (less than 400 characters).

It feels more specialized than twitter, and pretty useful to log short updates on what I am hacking on, or short news for a project. For instance, Sébastien already started using it to publish short news about Gendarme.

That looks pretty nice to me, let see what ends up in my ohloh journal.

Sharpen, an Open Source Java to C# converter

Jb Evain — Tue, 20 May 2008 21:18:00 +0200

Today folks at db4o released Sharpen, an open source Java to C# converter.

Am happy to see this coming, as it is soming I’ve pushed strongly for when I was working at db4objects, and was hacking on it, mentored by its main developer, Rodrigo. There I had the chance to improve the generated code, to make it look like hand written code, that follows .net conventions.

It’s nothing magic, and requires compromises on both the Java and the generated C#, but it’s pretty handy, easily hackable, and all in all, damn useful.

Rodrigo wrote a nice tutorial on Sharpen.

Time to port your Java applications to the amazing Mono!

Old boxes

Jb Evain — Tue, 20 May 2008 12:42:00 +0200

While Miguel was having fun discovering new games, I saved from the dust a few precious boxes.

Now that they’re safe, I can go back to play Mass Effect.

Mono and the Summer of Code

Jb Evain — Fri, 28 Mar 2008 22:29:00 +0100

For the fourth time, Mono has been accepted as a mentoring organization for Google’s Summer of Code.

I started contributing to Mono at the end of 2004, and I was lucky to be accepted as a student for the very first Summer of Code during the 2005 summer. And I was even luckier to be accepted again the year after. This year, just like the year before, I’m a possible mentor.

The Summer of Code is an amazing opportunity for young developers to be involved in a FOSS project, to learn, to practice programming on exciting projects, while being surrounded with talented peoples. And also to have a great summer. And to get a cool t-shirt.

Oh, and for what it’s worth, five students (including me) from the previous SoC editions are now employed by Novell to work on Mono or Moonlight.

So yeah, if I had an advice, that would be to go have a look at the proposed tasks, you can even submit your own original proposal if you think you have a bright idea, and apply for it. You have three days.

Mono.Cecil vs System.Reflection

Jb Evain — Tue, 18 Mar 2008 11:25:00 +0100

My friend Patrick, who’s leading the amazing NDepend effort wrote a great post comparing Cecil against the built-in System.Reflection:

Mono.Cecil vs System.Reflection

Thanks Patrick for the kind words!

An elegant LINQ to db4o provider, and a few LINQ tricks

Jb Evain — Wed, 06 Feb 2008 18:30:00 +0100

Last year, when I was working at db4objects on db4o, I insisted on the need for db4o to act as a LINQ provider, and with that in mind, prototyped one. I’am happy today to see a LINQ provider making it to db4o’s SVN, especially as I had the chance to influence its design, as I was also researching LINQ for Mono. For that matters, I find LINQ to db4o’s design particularly elegant.

I’ll use that occasion to describe a few LINQ tricks. Hopefully, the folks at db4o won’t mind if I steal the show. Actually I think it will even unburden my good friend Rodrigo, who’s apparently tired of blogging.

Making a type queryable with LINQ

Let’s take db4o’s example. What you do first is getting an IObjectContainer, with the idea to store and retrieve objects.

using (var container = Db4oFactory.OpenFile ("data.db4o")) {
    // ...
}

So the goal was to be able to write somethings either like:

var peoples = from container.Query<Person> ()
             where p.Name == "jb" && p.Age == 25
             select p

or like:

var peoples = from Person p in container
             where p.Name == "jb" && p.Age == 25
             select p

There’s a few things that we didn’t like with the first method. First an IObjectContainer already have a Query<T> method, which is used for native queries, and secondly, aesthetically, it doesn’t look as good as the second one.

So we went for the second possibility. The issue is that IObjectContainer doesn’t implement any interface that the compiler could use to perform LINQ queries on it.

The trick here is that when the compiler encounters the form:

from Person p in container

It will try to compile it as:

container.Cast<Person> ()

And expect that this Cast<T> returns an IEnumerable<T>, on which he can perform LINQ query. The good news is that this Cast method can very well be an extension method.

With that in mind, the entry point of LINQ to db4o is really simple:

public static IDb4oLinqQuery<T> Cast<T>(this IObjectContainer container)
{
    return new Db4oQuery<T>(container);
}

Now comes the question of what is this IDb4oLinqQuery<T>.

Implementing a lightweight LINQ provider

LINQ is still a pretty new technology, so it’s not always easy to find good advices from people that are already experienced in the fine art of writing LINQ providers. If I don’t have the pretension to be one of those experienced guys, I know of at least one folk who used the following trick, and which is happy with it.

So today, the standard way of writing a LINQ provider seems to be implementing the interface System.Linq.IQueryable, and to implement a full fledged LINQ provider. Matt Warren have written an excellent series of posts about it. LINQ to db4o uses some code from his posts. Bart de Smet also wrote a nice one.

My very first prototype was also following this path, but at that time, we changed it quickly for an excellent reason.

Thing is that the IQueryable path is an all or nothing solution. It keeps building an expression tree, until you decide to work on its result, either by calling GetEnumerator, or by calling AsEnumerable on it.

Another thing is that db4o is only able to optimize a (comparatively with something like LINQ to SQL) very little subset of the possible LINQ operations. Actually, it can really optimize only Where, Count, OrderBy and ThenBy.

And again, here comes the magic of the extension methods. All LINQ operations are actually extension methods on IEnumerable<T>, or on a child of it, like IQueryable<T>.

The trick here, was simply to re-define the supported LINQ operations, on a custom interface. And that’s what the IDb4oLinqQuery interface we talked before is. It’s simply a marker interface:

public interface IDb4oLinqQuery<T> : IEnumerable<T>
{
}

And thanks to the C#3 magic, we can redefine the LINQ operations on it:

public static class Db4oLinqQueryExtensions
{
    public static IDb4oLinqQuery<TSource> Where<TSource>(this IDb4oLinqQuery<TSource> self, Expression<Func<TSource, bool>> expression)
    {
        // ..
    }

    public static int Count<TSource>(this IDb4oLinqQuery<TSource> self)
    {
        // ..
    }
}

The major advantage of this solution, is that it allows the LINQ query to fallback to LINQ to Objects, anytime a LINQ operations is not supported. So by default, is something cannot be optimized, the LINQ to db4o will return all the types for a certain type, and as we fall back to LINQ to Objects, the user will at least get the result it wanted, even if it doesn’t run at full speed. I think it’s something that makes this solution really elegant.

Let’s take a detailed example:

var peoples = from Person p in container
             where p.Name == "jb" 
             orderby p.Age
             select new { p.Age }

The compiler here sees four steps.

First it use the first Cast trick, that creates an IDb4oLinqQuery of T,
Secondly, it call the Where methods defined for IDb4oLinqQuery,
Then it does the same for OrderBy, which can be optimized,
And then only, as db4o cannot optimize the creation of an anonymous type, it will fall back to LINQ to Objects, but only for the select part, while the two first parts run completely optimized, and almost as fast as the db4o low level query mechanism.

That’s really nice if you ask me.

Using an expression tree as a dictionary key

That one is simple.

LINQ to db4o caches how a query is created, depending on the expression tree it gets. Thing is that System.Linq.Expression doesn’t override Equals and GetHashCode, and as the compiler re-creates a whole new tree every time it sees one, hence Expressions are poor candidate for being keys in Dictionary. The trick here is simply to have an IEqualityComparer for Expressions. It’s seems that it’s not trivial to implement, but they managed to get a pretty nice one.

Analyzing properties body’s

This trick is also a simple one, and it’s the same one that db4o uses for its Native Query functionality, LINQ to db4o uses the Cecil.FlowAnalysis library to read the body of the properties, so they know which fields are impacted by the LINQ query.

That’s all folks

Kuddos to db4o for such a nice addition, hopefully it’ll run on Mono soon!

Yet another Hello World

Jb Evain — Wed, 30 Jan 2008 21:51:00 +0100

using System;
using System.Linq.Expressions;

class HelloWorldOfTrees {

    static void Main ()
    {
        var param = Expression.Parameter (typeof (string), "p");

        var cwl = Expression.Lambda<Action<string>> (
            Expression.Call (
                typeof (Console).GetMethod (
                    "WriteLine", new [] { typeof (string) }),
                param), param).Compile ();

        cwl ("Hello World !");
    }
}

[mono] /tmp @ gmcs test.cs 
[mono] /tmp @ mono test.exe 
Hello World !

Well heh, you can’t do really much more than that, but at least, that is working (sort of).

Mono presentation at Microsoft Techdays

Jb Evain — Sun, 27 Jan 2008 13:51:00 +0100

For the second year in a row, I’ll be presenting a session about Mono and Moonlight during the Microsoft Techdays that take place in Paris, on Feb 11. We’ll have the pleasure to have with me my oh so famous boss Miguel, to introduce my session, and answer a few questions.

Here’s the direct link to the session sum up: Présentation des projets Mono et Moonlight .

Update: You can download the slides of the presentation.

We're back baby

Jb Evain — Sun, 13 Jan 2008 16:45:00 +0100

After having undergone a month of technical difficulties, this blog is back online. Sorry for the turbulences. More technical content to follow. Happy new year!

A handful of useful scripts

Jb Evain — Thu, 11 Oct 2007 11:16:00 +0200

I've just uploaded a zip file containing a handful of scripts I use in my every day routine.

cleol: Clean the end of lines of the files passed as arguments. Accept ruby wildcards (such as * or **/*). That will replace the windows style line endings by unix style line endings, but will also remove useless white-spaces.
clprop: Clean the svn properties of the files passed as arguments. Accept ruby wildcards (such as * or **/*). That will remove the svn:executable properties, and set the svn:eol-style to native to the files.
svnci: My own script that prompt me my favorite lightweight editor to edit my ChangeLog entries.
monoport: I've detailed this one in this blog entry. I recently added to it the possibility to get a monoport entry printed to stdout. Typically, it allows me to apply patches directly from monoport:
```
monoport -g:4512 | patch -p0
```
Requires the cute library hpricot.