Cette année la finale portait comme d’habitude sur un sujet d’IA. Apparemment on a été bien gâté puisqu’on a eu droit à un serveur de jeu *presque* sans bug ( ) et des outils de test vraiment super (miam le launcher graphique). Le sujet complet sera probablement proposé sur le site plus tard mais en attendant voici la trame générale : chaque joueur contrôlait 3 hamsters sur une carte composé de case pouvant représentée une surface, un obstacle ou un trou. Sur certaines cases étaient disposés des pommes (je vous passe les détails cosmiques sur le pourquoi du comment du couple hamster-pomme) et le but était, bien entendu, de les ramener dans son camp (les deux lignes du haut de la carte). Bien sur il y’avait plus à faire que du simple pathfinding. Les hamsters était, entre autre, muni de grappin et pouvait projeter des trognons de pomme (stock limité) aux hamsters ennemis. Il était également possible de composer une stratégie pour faire coopérer les hamsters sur le passage d’une tranchée (assemblage de case trou) soit pour aller plus vite, soit parce que c’était la seule possibilité d’aller chercher des pommes (ce qui donnait lieu à des cartes tordus). La partie la plus dure de l’exercice était que, à chaque tour de jeu, on devait donner trois ordres à chacun de nos trois hamsters ce qui nécessitait de deviner les coups que pouvait réaliser l’adversaire pour nous barrer la route.

Au départ ma stratégie était d’aller chercher un stock de pomme suffisant pour gagner puis de le défendre farouchement contre l’adversaire mais, malgré les 36h, je n’ai pas pu mené la deuxième partie à bien. C’est pourquoi mon IA s’est borné à aller chercher les pommes de la meilleure manière possible. Néanmoins je suis assez satisfait de certains passage comme la détection des collisions et le système général de décision (bon, même si ca a été codé à l’arrache, je l’avoue). D’ailleurs, sur le point entre parenthèse, je précise que, comme on pouvait s’en douter, je n’ai pas eu accès à C# pendant la finale (bouh C++). Le point positif c’est que maintenant je peux cracher sur C++ en étant crédible . Néanmoins je place beaucoup d’espoir sur la présence de C# à la prochaine édition vu que ça avait l’air de marcher pas trop mal sur le site d’entraînement (et que j’ai vu resortir un orga avec un livre C# sous le bras à la fin :-° ).

Pour conclure je dirai que j’ai été très heureux de participer, à la fois pour le plaisir de pousser mes limites mais également pour (re-)rencontrer des gens intéressants (folks de #sdz et les gens présent à Strasbourg). Notons également la bonne bouffe et le superbe tee-shirt (principe du « coding for the cotton » en application ici ) .

Les photos ont commencé à arriver sur le site et on devrait bientôt les avoir toutes disponibles ainsi que les résultats finaux dans quelques semaines.

PS: Ha et j’ai aussi atterri 3ème du concours de Poker organisé pendant la finale, poker qui a encore donné lieu à d’autres super moments. Merci à l’orga-maitre de jeu pour les parties endiablés .

PS²: Avant de clore le billet, une petite pensée pour O’Reilly France, sponsor de Prologin, qui décidé de fermer juste après la fin de la finale. C’est une grande perte pour la littérature informatique française.

Without further introduction, here is the Python version :

#!/usr/bin/env python

import dbus, gobject, dbus.glib

NICK = "Kiri"
CHAN = "#riverotte"

bus = dbus.SessionBus()

obj = bus.get_object("im.pidgin.purple.PurpleService", "/im/pidgin/purple/PurpleObject")
purple = dbus.Interface(obj, "im.pidgin.purple.PurpleInterface")

obj = bus.get_object ("org.xchat.service", "/org/xchat/Remote")
xchat = dbus.Interface(obj, "org.xchat.plugin")

away = False

def statuschangementCallback(acctID, old, new):
	global away
	cur_status = purple.PurpleSavedstatusGetCurrent()
	message = purple.PurpleSavedstatusGetMessage(cur_status)

	if (purple.PurpleSavedstatusIsIdleaway() == 1):
		message = "aw"

	message = message.replace(" ", "_")
	if (len(message) > 8):
		return
	serv_id = xchat.FindContext("", CHAN)
	xchat.SetContext(serv_id)
	xchat.Command("nick "+NICK+"`"+message)
	if (purple.PurpleSavedstatusGetType(cur_status) == 5):
		xchat.Command("away")
		away = True
	elif (away):
		xchat.Command("back")
		away = False

bus.add_signal_receiver(statuschangementCallback, dbus_interface="im.pidgin.purple.PurpleInterface", signal_name="AccountStatusChanged")

gobject.MainLoop().run()

And here is the C# version :

using System;
using GLib;
using NDesk.DBus;

[Interface("im.pidgin.purple.PurpleInterface")]
public interface PurpleInterface
{
int PurpleSavedstatusIsIdleaway();
int PurpleSavedstatusGetCurrent();
string PurpleSavedstatusGetMessage(int status);
int PurpleSavedstatusGetType(int status);
event StatusChangedEventHandler AccountStatusChanged;
}

[Interface("org.xchat.plugin")]
public interface XChatInterface
{
uint FindContext(string serv, string channel);
void SetContext(uint cont);
void Command(string cmd);
}

public delegate void StatusChangedEventHandler();

class Plugin
{
const string Nick = « Kiri »;
const string Chan = « #riverotte »;

static bool away;

public static void Main()
{
MainLoop ml = new MainLoop();
BusG.Init();

XChatInterface xchat = Bus.Session.GetObject(« org.xchat.service », new ObjectPath(« /org/xchat/Remote »));
PurpleInterface purple = Bus.Session.GetObject (« im.pidgin.purple.PurpleService », new ObjectPath(« /im/pidgin/purple/PurpleObject »));

purple.AccountStatusChanged += delegate {
int cur_status = purple.PurpleSavedstatusGetCurrent();
string message = purple.PurpleSavedstatusGetMessage(cur_status);

if (purple.PurpleSavedstatusIsIdleaway() == 1) {
message = « aw »;
}

message = message.Replace( » « , « _ »);
if (message.Length > return;

xchat.SetContext(xchat.FindContext(«  », Chan));
xchat.Command(« nick  » + Nick + « ` » + message);

if (purple.PurpleSavedstatusGetType(cur_status) == 5) {
xchat.Command(« away »);
away = true;
} else if (away) {
xchat.Command(« back »);
away = false;
}
};

ml.Run();
}
}

Preliminary

First of all, one may find that the Python code is shorter. But if you remove the boilerplate code (the interfaces and delegate), which could be both autogenerated with a future release of D-Bus Explorer anyway (ad inside ), the overhead is about 3-4 lines ({ } included). So no real advantage there.

Readability != Conciseness

Now for readability. Python has always been praised for being concise and all. Why do I say ‘concise’ there ? Because IMHO conciseness and readability aren’t the same things at all.

When friends show me a OCaml sexy hack, the first thing I reply is « and what does it do ? ». Don’t mistake me, I don’t use OCaml that much and sure these things come with habit, but nonetheless, I’m not completely alien to the programming style and, even with that knowledge, I can’t tell what a « concise » 20 lines OCaml program do. You can call me dumbass but I’m pretty sure I’m not the only one in this case. Anyway, all of this to illustrate that, at least for some people (which I’m part of), these two concepts of readability and conciseness are not equivalent.

Returning to our matter, I think the previous story illustrate the case of the C# example. Indeed, it may not be shorter at first sight but (and I’m convinced about that) even if you never programmed in C#, you know, with a quick glance, what it does. Verbosity is not a bad thing if it’s not extreme (read, VB). Complain about that in comments, with arguments, if you disagree.

Of course, it can hold true for the Python snippet too. This first part was just to clear the idea that conciseness ⇔ readability.

Tackling the binding problems

Now there is another important aspect to take care (in my sense) : language integration. I won’t talk about the ‘global away’ line and the inherent block semantic which I find strange in a « Python is the C programmer best friend » context as it’s more a personal preference. However, since we are talking about C, I just can’t see the design difference between the Python snippet and an equivalent C one coded with libdbus so what’s the advantage to use Python over C for D-Bus ? In fact, what I want to point out is that having binding is good and all, but, IMHO, having integrated binding is better. What do I mean by integrated ? Well, look at the C# code and you will see several things which make Managed D-Bus « integrated » compared to dbus-python :

• Real polymorphism with interface and genericity (What GetObject is doing ? I don’t care, I have my interface definition for reference purpose).
• No dbus.Interface, everything is handled thanks to attribute and reflection.
• Integrated events, not a silly bus.add_signal_receiver() C-ism.

All of that allow D-Bus specific calls to blend more nicely in the rest of the application. To the contrary, I often see Python scripts which look more like a patchwork of different paradigm and convention style.

Having an interface-based way to access DBus’ methods also provides type safety (provided that you don’t fight with your keyboard or that you use the kind of autogenerating tool I described before) and I’m pretty sure your computer who-doesn’t-like-runtime-error will also be happier. And with a tool like D-Bus Explorer you don’t have to search tons of docs for type informations (still ad inside).

This last point is more debatable since it touches the more general philosophy of dynamic typing against static typing. My general stance on that is that, even if dynamic typing simplifies the process of writing the first code, it’s very damageable at the end for several points (which are also valid in our test case) :

• Type information is « volatile » meaning that, even if you know what that function of yours is supposed to return when you write it down, chances are that you will have to re-read the whole thing (or check the doc, or take a look at the unit testsn or something else time-consuming) later to remember what it does because, well, time and coffee do their job. Whereas in static typing langage, if the API is well made and if you have some sort of auto-completion, you can pretty most always deduce things from the full prototype.
• Continuing from point 1, it’s even worse for those guys who have to understand what you did before writing their own code.
• It’s not robust by default : you have to write unit tests to make sure no one is going to screw that part of the code with type mismatch (who said shortness ?).

Conclusion

So, to conclude, even if this post looks like a monologue against Python, it’s not. I understand Python advantages over traditional typed language and, as the first script shows, I even use it to test my ideas. What I wanted to highlight is that I consider Python *not* suited to large applications where several people have to collaborate (especially if there are no strong policy or rigor inside the team). Python as a powerful Bash replacement, yes. Python as a nice framework for testing and prototyping ideas, good, why not. Python as en embeddable scripting language, sure, it’s made for that in a sense. But Python for a large and maintainable application ? No, not for me.

NB: this post is what some might call a (badly hidden) troll. Instead of that, I would like to present this post as an invitation to discuss in comments, so feel free to drop your thoughts.

Well at first some background, with C# 2.0 appeared a new usage of the keyword delegate in form of anonymous functions or closure (although they aren’t really new in themselves).

One of the most useful feature of anonymous method is the concept of ‘variable capture’ but even though it proves useful here it’s not the main part of the pattern.

Together with this C# 2.0′s anonymous method feature, the compiler also get enhanced to allow delegate type inference for variable and parameter. Indeed before C# 2.0 you had to explicitly initialize a delegate in order to use it :

private delegate void Func(int someInt);
Func func = new Func(MyMethod);

With C# 2.0 this dummy syntax is removed and one can write the more concise :

private delegate void Func(int someInt);
Func func = MyMethod;

But what this had to do with our subject ? Well you may know it or not but when you create anonymous method using only the delegate keyword (i.e. without any definition of parameters) the compiler automatically adapt the signature of the anonymous method to the underlying delegate. In other word it’s a cheap way to make Proxy (where Proxy refers to the design pattern that might be described as : « Providing an interface to a class which doesn’t implement it natively »).

How can we use this feature then ? Say you want to run a method on a dedicated thread (like the target toolkit’s mainloop in Circ) then this method (that we will call StartPresentation) might want some information to initialize the presentation like, for example, a reference to the main controller, the title for the Window etc… (which used to be the case in previous version of Circ).

Problem : the Thread class allow only a method which signature correspond to the ThreadStart delegate (defined as public delegate void ThreadStart();) in its constructor. Unfortunately, in our case, it doesn’t correspond the signature of our StartPresentation method. Nonetheless, thanks to some delegate magic, you can circumvent this limitation with this pattern :

public void InitializePresentation()
{
    // Well usually the MainControl isn't defined
    // there but it shows closure's ability to
    // capture outer variables
    MainControl ctrl = new MainControl();
    Thread thread = new Thread(delegate {
            StartPresentation(ctrl, "Window's Title);
    });
    thread.Start();
}

And here you go ! The anonymous method signature is automatically mapped to the one of the ThreadStart’s delegate by the compiler without any developer intervention.

So as Miguel said on his blog, Mono.Xna is now « mature » enough to run Rob’s Pong.

As the  »  » suggests, I’m not comfortable anymore with the idea that Mono.Xna is getting more and more mature. In fact it’s totally the contrary : I’m more and more suspicious towards Mono.Xna. Even though there are great people behind it (Antti, Alan, David Hudson…) the project lack a consistence IMHO. Still now I don’t really know who is the « Game Master » behind Mono.Xna nor did I see the skeleton of a real organization behind it. Actually Mono.Xna appears to me more like a big mess than a shiny piece of code. Things are quickly (doesn’t influence the patch length though )  hacked upon the stubs without a common talk or a design plan from the team. What I fear is that all this work will ultimately result in nothing because of its crappiness (writing unit tests isn’t sufficient). Maybe at some point we will be able to just stop the « hackers folly », design a correct infrastructure and fork the existing code where possible in the new design.

For the moment things are still easy because SDL.NET helps a lot (I’m still unconvinced that tying Mono.Xna so deeply in SDL.NET is a good idea but that’s another matter). But things will get exponentially harder when the Content Pipeline, for example, will need to be implemented.

Reading the HIG made me realize that today, with all this 3D interfaces buzz, things are getting a lot less accessible for people who suffers from some deficiency. That’s why I want to implement some stuff from ATK in order to provide maximum accessibility for these people who deserve to be able to communicate on IRC like any other geek. I may also use AT-SPI but the main interface to it seems to be only Corbra/Bonobo ATM which is far from being efficient in C# code even though there is apparently some work to get a D-Bus binding which would be better and simpler for me to implement.

Definitely, I think that Accessibility must be one of the key feature of Circ. Integrating libcontrast in contrast was already a smallish step towards that goal but there is more work to be done before telling that Circ is accessible.

Les IDE comme Visual ou Borland Turbo propose des modules pour faire de l’UML et ainsi assuré une forte relation entre le design et le coding. Sous Linux cependant l’éditeur qui est de facto standard (Monodevelop) ne propose pas d’éditer directement de l’UML (je crois me souvenir de quelque qui s’appelait MonoUML mais ça a du tomber aux oubliettes). Pour en revenir à Dia je l’ai utilisé afin de remettre a plat quelques idées que j’avais pour Circ et j’avoue que je trouve l’utilisation très agréable même si a priori il n’est pas fait pour ça à la base (a contrario ArgoUML m’a rebuté presque instantanément ).

Les avantages de Dia à mon sens sont : indépendance du langage de prog sous-jacent (sous ArgoUML on est quasiment obligé d’utiliser des Java-ismes), les options d’export du diagramme (même si le module SVG merde un peu chez moi ), la possibilité d’écrire des générateurs de code (il n’y en a pas encore pour C# mais pourquoi pas un jour ) et globalement l’utilisation intuitive et rapide (Gnome powaaa ).