L'Aube des Héros

L'oeil extérieur

2012-01-29T13:41:00.003+01:00

Depuis que quelques bonnes âmes essayent Médoc, je retrouve nombre de petites limitations, ou de cas particuliers que j'avais ignoré un peu rapidement. Le résultat, c'est que le logiciel s'améliore lentement, mais sûrement.

Ce sont des choses bêtes: la localisation, par exemple, qui envoyait des dates en français à la base de données. Ou le support multi-devices: Sane ne reconnait que mon scanner HP, j'ai donc paresseusement simplifié Médoc en prenant le premier device disponible. Mais une simple webcam, par exemple, est considéré comme étant un device supplémentaire, et tout d'un coup, l'hypothèse ne tient plus.

La morale de cette histoire, c'est:
- Eat your own dog food
- Mais faites tester par d'autres!

Un client Twitter en OCaml

2012-01-22T20:41:00.002+01:00

Pourquoi s'arrêter en si bon chemin? Voici un nouvel œuf de canard: le même client Twitter pour l'API stream, mais cette fois-ci en OCaml. Utilisant Yojson et OCurl, c'est le port copie conforme du client C++.

Si jamais je me décidais à enregistrer les messages dans une base de données, c'est plutôt à partir du client OCaml que je continuerais.

Oeuf de canard - C++ et zlib

2012-01-17T17:36:00.002+01:00

Un vieil œuf de canard que je viens de poster: mon vieux wrapper zlib est maintenant dans le nid douillet de Github, avec deux binaires triviaux pour la compression et la décompression.

Peaufinage

2012-01-13T23:34:00.004+01:00

Quelques améliorations de Médoc: tout d'abord, je rends l'OCR optionnel, puisque la version 2 de Tesseract, empaquetée sous Debian, est assez buggée et crashe régulièrement. Si un document ne passe pas, allez donc désactiver l'option.

Ensuite, j'ai tenté d'améliorer le look de la boite de dialogue du scan: la bibliothèque Sane contient déjà la notion de groupe, il suffisait donc de recoller les morceaux. Une boite de dialogue typique ressemble à ça:

Notez également que la barre de progression est maintenant intégrée, ce qui l'évite de surgir sur le bureau alors que l'on est en train de faire autre chose pendant un long scan.

Un gros morceau sera de revoir en détail l'ordre des contrôles dans chaque boite de dialogue, afin de simplifier la navigation par la touche Tab.

Streaming API Twitter

2012-01-08T19:11:00.003+01:00

Non, je ne me suis pas encore vendu aux médias sociaux, mais puisque je pourrais en avoir besoin bientôt, je me suis lancé dans l'écriture d'un tout petit programme en C++ destiné à lire les feeds Twitter en temps réel. Combinant curl et json_spirit, suffisamment grand pour ne pas être pratique à poster, mais suffisamment petit pour ne pas valoir un projet à lui tout seul, c'était le candidat parfait pour mon dépôt "Œufs de canard" dont je parlais dans un post précédent (j'avais en effet déjà une idée derrière le bec).

Le code se trouve ici. L'on lancera le programme ainsi:

./twitterstream -u username -p password -k mot1 -k mot2 -k mot3...

Et devraient surgir à l'écran les messages filtrant sur un des mots-clé passés dans les options -k.

Je suis impressionné par le débit: sur des mots relativement courants, ça descend à toute vitesse.

Je me tâte maintenant à ajouter une couche de persistance vers une base de données... Peut-être après Médoc v2!

Oeufs de canard

2012-01-08T19:06:00.003+01:00

J'inaugure mon nouveau dépôt Œufs de canard, où je placerai mes programmes de test, ce qui sera plus simple que de faire d'interminables listings plus ou moins bien formatés ici. Plus de contenu, moins de blabla, voici mes vœux pour ce blog en 2012 (vous allez me dire, ça commence bien...).

J'oubliais...

2012-01-07T00:27:00.001+01:00

Et bonne année, aussi!

Covariance

2012-01-06T23:57:00.004+01:00

C'est étrangement une fonctionnalité qui semble relativement peu connue des programmeurs C++: la covariance des types de retours dans les fonctions surchargées.

L'exemple standard est la déclaration d'une méthode "clone", qui renvoie une copie de l'objet. Prenons une classe A:


class A
{
public:
  virtual ~A();
  virtual A * clone() const;
};

Maintenant, comment écrire une classe B dérivant de A, de manière à ce que la méthode clone fonctionne, c'est à dire renvoie une instance de B si le type sous-jacent est B? Ou plus exactement, quel devrait être le type de retour de la méthode clone de B?

L'on peut bien entendu retourner A. C'est clair, net et précis lorsque l'on travaille avec A, mais c'est dommage lorsque l'on travaille directement avec B: appeler clone renvoie un pointeur sur A, alors que l'on sait pertinemment que c'est un B, et on doit donc le caster vers B pour travailler avec.

Profitons donc de cette fonctionnalité introduite dans C++98, qui dit que si une méthode virtuelle renvoie un pointeur, l'on peut surcharger cette méthode avec un type de retour pointeur vers un objet dérivé. L'on écrira donc:


class B : public A
{
public:
  B * clone() const;
};

Et la méthode clone fonctionnera exactement de la manière désirée.

Il est à noter que le type de retour peut-être différent du type parent: si A dérive de B, et C dérive de D, une méthode de A retournant C peut être surchargée dans B comme retournant D.

Il est à noter également que malheureusement, cette fonctionnalité devient de moins en moins utile: de nos jours, il est de plus en plus rare de renvoyer un pointeur à poil, et il n'est pas possible d'obtenir le même résultat avec un shared_ptr, par exemple. Dans ce cas, il faudra renvoyer systématiquement le type parent, et faire un cast.

Yaaaa!

2011-12-29T20:47:00.000+01:00

Vu la vie de Genghis Khan hier à la télé... Ça me donne envie de rejouer à Mount & Blade. Pas bon pour le développement, ça!

C'est maintenant que ça commence

2011-12-23T19:49:00.003+01:00

De très bons retours de ma présentation de Médoc sur LinuxFr (ici et là). Merci à tous les commentateurs! J'en retire plus particulièrement ces quelques points:

Tout d'abord, faire fonctionner Médoc sur la machine de quelqu'un d'autre est un sacré défi. L'on a découvert des soucis liés aux locales, et je soupçonne peut-être certains problèmes 32/64 bits. Enfin, les autres scanners ont des options spécifiques que je n'avais pas implémentées

Ensuite, utiliser du JPG pour mes images n'est probablement pas l'idée du siècle: en effet, un format comme DjVu semble bien plus approprié. J'espère pouvoir réduire significativement la taille de la base, qui devient de plus en plus difficile à sauvegarder.

Enfin, il semble pertinent de réintégrer la reconnaissance de caractères, d'autant plus que Debian fournit maintenant la bibliothèque ocrad. Les autres solutions de reconnaissance de caractères ne fournissaient pas de bibliothèque C, ce qui m'avait refroidi.

Pas mal de boulot devant moi, donc. Tout d'abord, je vais, ou plutôt, je suis en train d'installer une Ubuntu 32 bits avec une locale française dans une machine virtuelle, pour tenter de reproduire certains bugs qui m'ont été signalés. Ensuite, je vais m'attaquer à l'amélioration du logiciel, ajout de fonctionnalités, et simplification du processus d'installation.

Médoc v1.0

2011-12-17T23:11:00.002+01:00

Voilà, la dernière fonctionnalité de base vient d'être implémentée. La galerie étant maintenant munie de fonctions de sélection et de ré-ordonnancement, j'annonce que Médoc est pleinement utilisable, et tague donc cette version 1.0. Un peu de documentation sur l'installation est disponible sur le wiki du dépôt chez Github.

Murf

2011-12-14T23:08:00.005+01:00

C'était bien la peine de passer une heure à faire des benchmarks. J'utilisais au boulot un boost::unordered_set d'entiers, avec des performances très décevantes, et l'on m'avait recommandé de remplacer la fonction de hachage par défaut avec MurmurHash, avec des résultats tout à fait impressionnants. J'ai donc tenté de les reproduire à la maison, mais, étrangement, ce fut impossible... La version standard de l'unordered_set est légèrement plus lente dans la bibliothèque standard que chez Boost, mais surtout, l'utilisation de MurmurHash plombe les performances très sérieusement.

Avec des chaines de caractères, par contre, MurmurHash commence à montrer les dents, et se montre plus rapide. Étrangement, dans ce cas, le hashset de la bibliothèque standard est plus rapide.

J'ai dû rater quelque chose, mais quoi?

Une gallerie en wxWidgets

2011-12-04T00:22:00.004+01:00

C'est basique, mais ça fait le boulot. Je viens de merger la branche gallerie dans la branche principale, maintenant que mon contrôle de galerie d'images est suffisamment fonctionnel. Voici la bête:

Vu que je n'avais rien modifié dans ma branche principale, le merge a été particulièrement simple:


git branch master <= hop, de retour sur la branche princpale
git merge gallery <= on merge la gallerie, de fait un simple fast forward
git branch -d gallery <= et on détruit la branche devenue inutile

Il reste encore à permettre le réarrangement des pages, et on devrait être fonctionnellement complet.

En vrac

2011-12-01T23:44:00.003+01:00

Pic de fréquentation aujourd'hui!

Pour une raison que j'ignore, tout le monde (enfin, toutes proportions gardées) s'est précipité sur mon tutorial lwt, qui trainait sur le blog depuis 6 mois. La révolution fonctionnelle est en marche!

Petit souci classique dans mon composant wxWidgets de galerie: je code en dur la largeur du composant, ce qui me permet d'y placer exactement le nombre d'images requis en largeur. Malheureusement, quand il y a trop d'images en longueur, la barre de défilement verticale apparait, ce qui réduit de quelques dizaines de pixels la largeur de la zone client, provoquant une très inutile barre de défilement horizontale (ça va, vous suivez?). Je pense tenter de corriger cela en forçant la barre verticale à être toujours présente, et ma zone client juste assez grande pour faire tenir mes images en largeur plus la barre.

Ah, et je suis enfin plongé dans la partie "sociale" de Github. Je ne pensais pas y rencontrer quiconque, mais si, Dongorath, commentateur de ce blog, me "follow"! Si tu me lis encore, coucou Dongo :)

Github - Ça vient doucement...

2011-11-27T19:17:00.002+01:00

Aujourd'hui, je me suis mis à implémenter une vraie galerie d'images au lieu de la bête listbox, pour représenter la liste des images déjà importées. Ce fut donc l'occasion d'essayer de comprendre comment faire une branche sur git, et la pousser sur github. Avec l'aide de StackOverflow, voilà ce que je fis:

Tout d'abord, créer une nouvelle branche à l'aide de la commande "checkout":

# git checkout -b gallery

Git me confirme que mes changements sont maintenant bien situés sur la branche, et m'indique "Switched to a new branch 'gallery'".

# git branch

* gallery
master

C'est bien la confirmation que j'ai maintenant deux branches, et que ma branche courante est gallery. Ouf!

# git commit

# git push origin gallery

Voilà, ma branche est partie sur github. Je vérifie sur le graphe des branches que tout est bien comme je m'y attendais.

Je vais finir par y comprendre quelque chose.

Benchmark

2011-11-22T23:16:00.002+01:00

Je testais aujourd'hui les performances d'un nouveau bout de code pour faire de la sérialisation, templaté de partout, le comparant à du vieux code moins générique, mais réputé rapide.

Et je ne comprenais pas pourquoi mon nouveau code, sur un bout tout simple, le calcul de la taille du buffer nécessaire à la sérialisation d'un vecteur de chaînes de caractères, était plus lent. Pour un vecteur de 10000 chaînes, mon code tournait à 19µs, et l'autre à 14µs.

L'algorithme était pourtant tout bête: on prend 4 pour contenir la taille du vecteur, puis on ajoute pour chaque chaîne 4, pour la longueur de la chaine, puis la longueur de la chaîne elle-même. En pseudo-code, pour un vecteur v: 4 + (for each c in v : 4 + length(c)).

Je tente de remplacer mes itérateurs par des entiers et des index, j'enlève et remets les templates, je vérifie bien que le compilo inline tout... Toujours la différence.

Finalement, c'était tout bête. Une telle différence vient rarement des micro-optimisations du code, et bien plus souvent d'un algorithme suboptimal. Le vieux code calculait la longueur de cette manière: 4 + 4 * length(v) + (for each c in v : length(c)). Ce qui sauvait 10000 additions contre une simple multiplication, et me coûtait les 4µs.

wxWidgets - Un OK plus standard

2011-11-19T18:20:00.004+01:00

Avant:

Après:

La méthode wxDialog::CreateStdDialogButtonSizer créé automatiquement les boutons standards pour la plateforme, en termes de disposition (à droite, OK puis Cancel pour Windows, Cancel puis OK pour Apple et GTK, avec le texte et les icônes...). La méthode renvoie un sizer, qu'il est possible d'ajouter directement au sizer principal de la boite de dialogue.

C'est y pas plus joli comme ça?

OCaml détecté

2011-11-13T23:00:00.001+01:00

Yay, Github a manifestement refait tourner les statistiques, et détecte bien maintenant que Médoc est fait à 45% d'OCaml.

Écrire son propre wxImageHandler - Lire des PDF

2011-11-13T19:42:00.002+01:00

La bibliothèque wxWidgets fait reposer son système de chargement d'images sur la classe wxImageHandler. L'idée est d'en dériver, et de fournir l'implémentation pour lire son type d'image particulier. Une fois ajouté au framework, l'application peut lire le nouveau type d'image de manière transparente.

Voici un wxImageHandler très basique pour afficher, sous forme d'image, des fichiers PDF, en utilisant les routines de la bibliothèque ImageMagick.

Tout d'abord, le fichier d'en tête, tout simple: l'on dérive de wxImageHandler, et l'on implémente les méthodes "GetImageCount", "LoadFile", "SaveFile", et "DoCanRead".


#include <wx/wx.h>

class PdfImageHandler : public wxImageHandler
{
public:
  PdfImageHandler();

  virtual int GetImageCount(wxInputStream & stream);
  virtual bool LoadFile(wxImage * image,
                        wxInputStream & stream, 
                        bool verbose=true, 
                        int index=-1);
  virtual bool SaveFile(wxImage * image, 
                        wxOutputStream & stream, 
                        bool verbose=true);
  
protected:
  bool DoCanRead(wxInputStream & stream);
};

À l'implémentation, l'on utilise l'API Magick++, et un peu de MagickCore, pour lire le fichier PDF et le renvoyer sous forme d'image.


#include "PdfImageHandler.h"

#include <Magick++.h> 
#include <wx/mstream.h>

namespace
{
  std::list<Magick::Image> loadImages(wxInputStream & stream)
  {
    wxFileOffset offset = stream.TellI();
    wxMemoryOutputStream buffer;
    stream.Read(buffer);
    stream.SeekI(offset);
    
    Magick::Blob blob  
      (buffer.GetOutputStreamBuffer()->GetBufferStart(),
       buffer.GetOutputStreamBuffer()->GetBufferSize());
    
    std::list<Magick::Image> images;
    Magick::readImages(&images, blob);
    return images;
  }
}

PdfImageHandler::PdfImageHandler()
{
  SetName(_("PdfImageHanlder"));
  SetExtension(_("pdf"));
}

int PdfImageHandler::GetImageCount(wxInputStream & stream)
{
  return loadImages(stream).size();
}

bool PdfImageHandler::LoadFile(wxImage * image, 
                               wxInputStream & stream, 
                               bool verbose, 
                               int index)
{
  std::list<Magick::Image> images = loadImages(stream);
  std::list<Magick::Image>::iterator it = images.begin();
  if(index != -1)
  {
    std::advance(it, index);
  }
  if(it != images.end())
  {
    Magick::Image & page = *it;
    Magick::Blob blob;
    page.write(&blob);
    wxMemoryInputStream input(blob.data(), blob.length());
    *image = wxImage(input);
    return true;
  }
  else
  {
    return false;
  }
}

bool PdfImageHandler::SaveFile(wxImage * image, 
                               wxOutputStream & stream, 
                               bool verbose)
{
  return false;
}

bool PdfImageHandler::DoCanRead(wxInputStream & stream)
{
  unsigned char hdr[4];
  if(!stream.Read(hdr, WXSIZEOF(hdr)))
  {
    return false;
  }
  else
  {
    return memcmp(hdr, "%PDF", WXSIZEOF(hdr)) == 0;
  }
}

La routine est malheureusement très inefficace: l'on se retrouvera à charger l'ensemble du PDF pour retourner le nombre de pages, puis recharger l'ensemble du PDF pour retourner chaque page. ImageMagick propose des routines permettant de "pinger" une image, c'est à dire d'en charger les propriétés sans les données. Pas sûr que le chargement de fichiers PDF, qui passe par GhostScript, permette ce genre d'astuce pour ne charger que l'image courante.

Mais si ce n'est pas rapide, au moins, ça marche! Une fois le handler ajouté, via une ligne du type

wxImage::AddHandler(new PdfImageHandler);

il devient possible de charger directement un fichier PDF dans une wxImage. L'on pourra utiliser wxImage::GetImageCount et le paramètre d'index du constructeur pour aller chercher chaque page individuellement.

Je commence à apprécier Github

2011-11-07T23:22:00.003+01:00

Ce site est un vrai petit bijou. Je découvre leur système de tickets, qui permet de lever des bugs ou des feature requests, de les assigner à un développeur et à une release et de les tagger. Ensuite, lorsque l'on corrige le ticket n, il suffit d'avoir "fix #n", "fixes #n", "close #n" ou "closes #n" dans le message de commit. Par exemple, mon dernier commit: "Added possibility to clear all loaded images. Fixes #1." ferme automatiquement le ticket correspondant, en y incluant le commentaire et un lien vers le commit, et ceci, pratiquement immédiatement après le push.

Par contre, étrangement, les statistiques en termes de langages utilisés ont l'air un poil cassé: j'ai commité ce week-end un millier de lignes d'OCaml et un peu de SQL, mais Github indique obstinément 100% de C++.

Médoc - C'est utilisable

2011-11-02T22:45:00.005+01:00

Mon dernier commit complète la phase initiale du client lourd Médoc: il est maintenant possible d'importer un document via le scanner, puis de le sauver dans la base de données. Il aura fallu ajouter quelques boites de dialogues pour entrer la configuration de la base, et pour définir les détails du document.

Il va falloir travailler sur bon nombre de détails pour rendre le client vraiment efficace, comme par exemple pouvoir effacer ou réordonner les pages, ou sauver les paramètres de la session précédente pour ne pas avoir à tout redéfinir à chaque fois.

Le problème principal, pour l'instant, est d'arriver à trouver enfin la configuration du scanner qui fonctionne correctement. Pour mon scanner HP, SANE me sort la liste d'options suivante:

Déjà, pour "Length measurement", il faut absolument changer l'option de "Padded" à "Approximate", sinon le scanner ajoute de lui même une horrible bande blanche en dessus des documents. Ensuite, vient le souci du batch: mon scanner peut scanner une pile de documents d'un coup, dans lequel cas il faut à la fin de chaque page boucler et tester si le scanner est prêt. Si l'on a bien mis l'option "Batch", le scanner répond après la dernière page qu'il n'y a plus de documents, et tout s'arrête. Tout va bien. Si l'on oublie l'option "Batch", par contre, le scanner tourne indéfiniment.

Pire, lors du scan à plat: dans ce cas, le scanner indique toujours un document comme étant disponible. Dans ce cas, il ne faut simplement pas boucler. Il semblerait donc que je sois obligé de demander à l'utilisateur son intention. J'aurais préféré que le scan soit plus intelligent, et me retourne une condition d'arrêt dans tous les cas.

Bien entendu, ce n'est valide que pour mon modèle de scanner. À partir de là, si quiconque veut tenter l'aventure, hic sunt dracones.

Mélanger pqxx et wxWidgets

2011-10-31T23:58:00.003+01:00

Une part non négligeable du boulot de développeur est de convertir des données d'un format vers un autre pour faire causer deux composants séparés.

Alors, pour une fois que c'est simple, l'on ne va pas bouder notre plaisir. C'est que le concepteur de libpqxx a eu la bonne idée de fournir des type traits pour passer ses propres types à la base de données pour les requêtes préparées.

Si l'on veut donc pouvoir sauver des chaînes de caractères wxWidgets (wxString) ou des dates (wxDateTime), il suffit d'implémenter le trait qui va bien. Cela ressemble à ça:


namespace pqxx
{
  template<> struct PQXX_LIBEXPORT string_traits<wxString>
  {
    static const char * name() { return "wxString"; }
    static bool has_null() { return false; }
    static bool is_null(const wxString &) { return false; }
    static wxString null() 
    { internal::throw_null_conversion(name()); return wxString(); }
    static void from_string(const char Str[], wxString & Obj) 
    { Obj = wxString(Str, wxConvUTF8); }
    static PGSTD::string to_string(const wxString & Obj) 
    { return std::string(Obj.mb_str(wxConvUTF8)); }
  };
  
  template<> struct PQXX_LIBEXPORT string_traits<wxDateTime>
  {
    static const char * name() { return "wxDateTime"; }
    static bool has_null() { return false; }
    static bool is_null(const wxDateTime &) 
    { return false; }
    static wxDateTime null() 
    { internal::throw_null_conversion(name()); return wxDateTime(); }
    static void from_string(const char Str[], wxDateTime & Obj) 
    { Obj.ParseDateTime(wxString(Str, wxConvUTF8)); }
    static PGSTD::string to_string(const wxDateTime & Obj) 
    { return std::string(Obj.Format().mb_str(wxConvUTF8)); }
  };
}

L'on indique simplement comment convertir une PGSTD::string (qui est en fait une bête std::string) dans le type de travail, et basta, avec ça, les appels du type

T.prepared("statement")(wxString1)(wxString2)(wxDateTime1).exec();

passent comme une lettre à la poste.

La punchcard de github

2011-10-30T15:52:00.002+01:00

J'aime bien le graphique "punchcard" de github. Pour Médoc, par exemple, l'on voit bien que je ne suis pas un matinal, et que je code le week-end et en soirée (forcément, le reste du temps, je code pour manger). Plus étrange, il semble que je sois plus productif en début de semaine qu'en fin.

L'on pourra comparer (façon de parler...) avec la punchcard du noyau linux, où les développeurs travaillent principalement la semaine entre 9h et 17h.

Je suis plutôt satisfait de GitHub, non que j'utilise plus d'un pouillème de ses fonctionnalités. Le push est très rapide, le site réactif, et les stats rigolotes.

std::lower_bound

2011-10-22T00:39:00.002+02:00

Imaginons que l'on veuille enregistrer une série de segments [a; b[, et à partir d'un point donné, rapidement retrouver le segment auquel il appartient. Typiquement: sachant que chaque événement court entre deux dates, pour une date donnée, trouver de quel événement il s'agit.

Comment donc placer ses segments dans une structure pour s'y retrouver simplement et efficacement?

Et comment gérer plusieurs segments qui se chevauchent?

Médoc - Dernières nouvelles

2011-10-18T00:06:00.002+02:00

Belles améliorations ce week-end de la partie import. J'ai découvert que je m'étais planté sur le nombre d'options disponibles, et qu'il y en avait de fait bien plus. Deux options en particulier:

La length-measurement: mon scanner HP considère (et renvoie via l'API) que la longueur de la page est environ deux fois plus grande que la largeur. Par défaut (l'option Padded), il ajoute donc une grande bande blanche en dessous de la page standard 210x297. Mais en mode Approximate, il me renvoie un signal de fin de données lorsqu'il arrive à la vraie fin de la page.

Le batch-scan: sans cette option, le scan à plat fonctionne normalement, mais le scan déroulant pour plusieurs documents s'y perd, et après la dernière page se met à scanner des pages vides jusqu'à ce que l'on termine le job manuellement. Avec l'option, il s'arrête à la dernière page, mais c'est alors le scan à plat qui refuse d'avancer! Il n'est pas sûr que j'arrive à trouver la combinaison d'options qui marche tout le temps, donc il va peut-être falloir que l'utilisateur indique s'il compte scanner une seule ou plusieurs pages.

Ceci dit, et pour peu que l'on fasse attention aux options, l'import est parfaitement fonctionnel. Quelques options supplémentaires, comme le réarrangement des pages, ou la rotation d'une image, seront utiles, bien sûr. Mais maintenant, le minimum nécessaire pour rendre l'outil utile est d'implémenter les fonctions d'export, vers une base de données Médoc, ou vers un pdf.

Et Jira se facebookise

2011-10-13T00:10:00.002+02:00

Décidément, c'est la saison.

Atlassian Software est une petite boite australienne qui a fait son trou dans les outils collaboratifs, et notamment Jira, qui est un outil web de suivi de bugs, plutôt bien fait d'ailleurs.

Nous avons bondi de la version 3.7 à la version 4.4, et là, c'est le drame. Cette transition corrige quelques défauts qui étaient certes ennuyeux, mais mineurs, mais surtout propulse le système de suivi à l'ère Facebook. Fausse bonne idée? Probablement.

Flux RSS de partout, avatars personnalisés, aucun doute, c'est du Web 2.0.

Que vous aimiez Ajax ou pas, vous aller en manger. L'ensemble de la plateforme, et plus particulièrement l'écran principal (le "dashboard") est maintenant asynchrone. Au démarrage, plutôt que de voir ses filtres habituels (typiquement, la liste des bugs assignés), l'on a droit à des panneaux vides avec des petites barres de progression type enseigne de barbier, pour finalement afficher quelque chose d'intéressant plusieurs secondes plus tard. C'est la même chose pour ajouter un commentaire à un ticket, ou enregistrer son temps de travail. Le javascript est présent en doses pour rhinocéros, chaque menu est dynamique, chaque panneau ou section du bug peut se replier ou se déplier, et les différentes sections de la page peuvent être réarrangées par glisser déposer.

Le résultat, c'est un site beaucoup plus lent sous Firefox, et à peu près inutilisable sous Internet Explorer 8.

Mais c'est joli, ce qui a probablement été suffisant pour convaincre le manager kivabien de procéder à la mise à jour.

Project Euler fait peau neuve

2011-10-12T23:00:00.003+02:00

Le site de Project Euler, le site de problèmes informatico-mathématiques, faisait un peu figure de dinosaure du Web. Eh bien, c'est fini, à la mi-Septembre le site web a été refondu en une version bien plus Web 2.0.

Le style est plus aéré, les statistiques ont été légèrement modifiés, et il y a maintenant un système de médailles basé sur les problèmes résolus, comme par exemple avoir résolu 50 problèmes liés aux nombres premiers, ou d'avoir résolu 12 problèmes au dessus du centième. L'on notera également un système de suivi permet de tenir ses amis à l’œil.

Les performances semblent avoir décru, et le site parait vraiment ramer. C'était parfois le cas avec l'ancien, donc difficile de savoir si c'est dû à une plus grande popularité, ou que le nouveau site cause une charge plus importante sur leurs serveurs. Ce n'est de toutes façons pas très gênant, ce n'est pas comme si je résolvais les problèmes si vite que leur chargement devienne fastidieux.

Médoc et wxWidgets

2011-10-08T19:32:00.005+02:00

Il est tentant de vouloir adapter les bibliothèques, au passé souvent chargé, aux concepts et techniques du C++ moderne. Et pourtant, principalement pour les projets assez indépendants, il vaut mieux s'asseoir un peu sur ses principes, et utiliser la bibliothèque de la manière qu'elle a été pensée.

Prenons la bonne vieille wxWidgets, avec laquelle je suis en train de créer mon client lourd Médoc. Elle utilise sa propre classe de chaines de caractères, afin de supporter plusieurs types d'encodage, ses propres tableaux dynamiques en place du bon vieux std::vector, et utilise des macros un peu partout.

J'ai tendance à importer immédiatement quelques utilitaires de base que je garde dans un coin, du genre conversion entre wxString et std::string. Mais pour Médoc, je crois bien pouvoir m'en passer: mes entrées comme mes sorties passant soit par wxWidgets elle-même, soit par des bibliothèques en C pur, il est plus cohérent de simplement utiliser des wxString partout.

Voilà donc, en 300 lignes, un programme qui permet de charger des images dans une liste, et de les afficher en cliquant dessus:

C'est maintenant que ça se gâte: remplacer la liste d'images par une vraie galerie, permettant d'afficher une miniature de l'image, et d'en changer l'ordre par du glisser-déposer.

4 ans...

2011-10-03T23:46:00.003+02:00

Je postais mon premier message sur ce blog le 1er Octobre 2007. 4 ans et 324 messages plus tard, les thématiques n'ont pas beaucoup changé (C++, OCaml, Postgresql, jeux vidéos). On a causé C++0x, on a causé Blender, on a même causé Emacs et astuces Debian.

Merci à mes lecteurs de chez l'université de Metz, de chez LinuxFR, de chez le "site du zéro", de chez Identi.ca (des Adaistes...) et de partout ailleurs de leur assiduité. Je leur souhaite de vouloir me lire encore pendant de nombreuses années, parce que j'ai bien des choses à dire!

Entre le C++0x qui va commencer à arriver en production dans divers systèmes à travers le monde, des nouveautés attendues dans Postgresql (je pense notamment aux ranges, qui je l'espère permettront de simplifier les bases de données historiques), les nombreux jeux que j'attends de pied ferme (Skyrim!), et diverses bêtises à partager, nous en avons pour un petit bout de temps.

@+!

Un client lourd Médoc

2011-09-30T00:39:00.002+02:00

Mon projet de documentation Médoc continue de fonctionner impeccablement, du moins du côté de la base de données et du client Web. Par contre, le client lourd en OCaml et LablGTK, chargé de charger les documents dans la base à partir du scanner ou d'un fichier, commence à tomber en ruines.

Pas très ergonomique d'une part, et pas très intégré d'autre part (la plupart des commandes, telles le chargement de fichier ou le scan en lui-même, sont faites à partir de lignes de commandes lancées par le programme). Je me suis donc mis à écrire un client lourd en C++ avec WxWidgets qui soit un peu plus pratique à utiliser. La libsane se chargera de piloter le scanner, libmagick++ sait apparemment transformer un pdf en image, et la libharu sait transformer une image en pdf.

Y'a plus qu'à coller les morceaux.

Courir après sa base de données

2011-09-28T22:48:00.005+02:00

Julien me parlait de systèmes de suivi de courses type marathon ou trail à base de RFID, et il n'en a pas fallu plus pour enflammer mon imagination. Je pensais à ce à quoi ressemblerait un schéma de base de données enregistrant le passage des coureurs à des points donnés, afin de permettre le suivi par les commissaires de courses, le public, et la publication des résultats et des statistiques pour les coureurs. Et on dirait bien qu'un tel système présente une sacrée dose de défis.

L'on s'intéressera plutôt aux courses de type ultramarathon ou trail, sur chemins ou en pleine nature, où les coureurs doivent s'enregistrer auprès des commissaires de courses à des points de passages déterminés. Le coureur passe donc son RFID au dessus de l'appareil du commissaire de course, et repart.

Voyons donc ce schéma. Les faits sont assez simples: une table contenant chaque détection d'un coureur à un point de passage. Mais qu'est-ce qu'un coureur, et qu'est-ce que c'est qu'un point de passage? Redéfinissons: notre table contient chaque détection d'un RFID par un appareil. Et il ne doit pas être possible de modifier ou d'enlever une ligne: une détection est une détection. Elle s'est effectuée à une certaine heure déterminée par l'appareil, et reçue à une autre heure (parfois beaucoup plus tard s'il y a des soucis de connectivité) par la base de données.

(device_id, rfid, device_timestamp, local_timestamp)

L'on pensera bien sûr aux pannes: si un rfid ou un appareil ne fonctionne plus, le commissaire pourrait se retrouver forcé d'enregistrer les coureurs manuellement via un autre type d'identification, comme un dossard.

(marshal_id, runner_id, marshal_timestamp, local_timestamp)

Ce sont les faits: irréfutables.

Maintenant, tout le problème est de rajouter les tables qui permettront d'associer les appareils aux points de passages, et les RFID aux coureurs.

- Un coureur découvre en milieu de course que son RFID est défectueux, et un commissaire de course lui en fournit un autre
- N'ayant cependant pas rendu son premier RFID, qui s'est tout à coup mis à remarcher, il passe parfois l'un, parfois l'autre aux points de passages
- Deux coureurs échangent un sac, et oublient que leur RFID était dedans

- Un commissaire change de point de passage, et garde avec lui son appareil
- Les commissaires découvrent que l'appareil pour la détection à l'arrivée est en panne, et décident de rapatrier un autre appareil pour l'arrivée, où une détection précise est plus importante

Toute la difficulté est donc de maintenir l'état le plus fréquent (un coureur ayant correctement été enregistré par son RFID par les bon appareils aux bons endroits), tout en permettant un réglage fin de toutes les petites déviations qui surviennent lorsque la réalité débarque avec ses gros sabots dans la théorie.

Peut-on rajouter la positien GPS de chaque appareil à chaque enregistrement pour tenter de les associer automatiquement à un point de passage?
Peut-être des tables se basant sur des plages horaires ou géographiques: de telle heure à telle heure, ou de tel point de passage à tel point de passage, le coureur A avait le RFID f, puis il est passé au RFID g?
Ou tout simplement des tables d'override: tel enregistrement doit être ignoré, tel autre doit être considéré comme ayant détecté le RFID g et non f?

Pas évident.

Github

2011-09-27T23:03:00.003+02:00

J'ai enfin fait le saut, et me voici sur github. Ayant depuis longtemps eu l'envie de m'essayer à git, le logiciel de contrôle de version décentralisé crée par Linus Torvalds, je me suis ouvert un compte sur github, et j'ai commencé à commiter.

Github est particulièrement bien: guidant pas à pas la création du dépôt et la configuration de git, réactif et ergonomique, c'est un petit bijou d'interface. Les performances ont également l'air d'être au rendez-vous.

Utilisant git de manière mono-utilisateur et mono-branche, mon utilisation est très proche de Subversion (en beaucoup plus rapide cependant, mais les dépôts Subversion de tortue de chez Sourceforge n'aident pas non plus), j'espère cependant au moins m'y initier suffisamment pour ne plus être complètement perdu lorsque certains collègues plus dégourdis jonglent avec git-svn sur les dépôts du boulot.

Déjà quelques trucs qui m'ont un petit peu bloqué: il n'est pas possible d'avoir des répertoires vides. La solution standard est de créer un .gitignore vide dans le répertoire, et d'ajouter ce fichier. Également, ajouter un répertoire est récursif, ce qui est souvent bien, mais parfois lourd lorsque ce répertoire contient déjà un build, par exemple. Le plus simple est de commencer par nettoyer tous les fichiers non voulus avant d'ajouter.

Le crible en détail, partie 2

2011-09-22T00:15:00.002+02:00

Continuons donc à décortiquer le programme.

La fonction principale de notre crible contient la sous-fonction do_sieve, qui permet une fois de plus de devenir tail recursive, ou à récursion terminale en bon français.

Elle prend comme paramètres l'entier courant à tester, l'ensemble des multiples des nombres premiers précédents, et la liste courante des nombres premiers. À partir de là, c'est tout bête: l'on retire le premier élément de nos multiples, et on le compare à l'entier à tester. S'ils sont égaux, notre entier courant est un multiple, donc non premier, l'on ré-appelle donc notre fonction récursive avec l'entier suivant. Si ce n'est pas l'entier à tester, on a trouvé un nombre premier! L'on ajoute tous ses multiples à la liste des multiples, l'on rajoute l'entier à la liste de nos nombres premiers, et l'on appelle la fonction récursivement. Et bien sûr, puisqu'il faut bien sortir un jour de la récursion, n'oublions pas notre condition de sortie: lorsque l'entier courant atteint le maximum passé en paramètre de la fonction principale, l'on retourne nos nombres premiers.

Notez l'optimisation qui consiste à zapper les multiples de 2: l'on démarre à 3, et l'on passe de 2 en 2 pour l'entier courant et pour le calcul des multiples.

Voici une indication des performances. Loin des meilleurs résultats impératifs, mais tout à fait utilisables.

Limite	Temps
100 000	140ms
1 000 000	2.7s
10 000 000	41s

Le crible en détail, partie 1

2011-09-17T14:13:00.003+02:00

Mon post précédent était un poil laconique, je vais donc reprendre quelques détails d'implémentation, et en profiter pour vous convaincre que OCaml, ça roxe.

Les premières lignes sont simplement la définition d'un set sur les entiers. Les sets en OCaml fonctionnent via des modules paramétrés par d'autres modules suivant une certaine signature. L'on créé donc un module définissant un type t et sa comparaison, avec lequel on paramétrise le module Set.Make.


module OrderedInt =
struct
  type t = int
  let compare = compare
end

module IntSet = Set.Make(OrderedInt)

Ceci va donc définir un module tout neuf, que j'appelle IntSet, et qui fournit des fonctions pour travailler sur des sets fonctionnels, c'est à dire sans effets de bords. Ainsi, ajouter un élément au set retourne en fait un nouveau set contenant l'élément. C'est plus efficace qu'il n'y parait, et surtout, cela permet de raisonner à plus haut niveau, d'une manière plus mathématique.

Ensuite, définissons une fonction qui nous sera utile plus tard, qui retourne une liste d'entiers entre deux entiers définis, avec un pas.


let seq_step a b t = 
  let rec do_seq_step a acc = 
    if a > b then 
      acc
    else
      do_seq_step (a + t) (a::acc)
  in
  List.rev (do_seq_step a [])

La fonction définit une sous-fonction do_seq_step, prenant l'entier courant a, et la liste d'entiers accumulés jusque là acc. La récursion est triviale: si mon entier courant a atteint ma borne supérieure, retournons la liste accumulée jusque là. Sinon, appelons récursivement la fonction, avec mon entier courant incrémenté du pas, et ma liste à laquelle j'aurais ajouté mon entier courant.

Depuis la fonction externe, l'on appelle la sous-fonction en passant la borne inférieure, et une liste vide. Enfin, parce que l'on a accumulé les entiers à l'envers (en partant de 3 de 2 en 2: [3], puis [5; 3], puis [7; 5; 3]...), l'on inverse la liste avec List.rev. Le résultat:


# seq_step 3 10 2;;
- : int list = [3; 5; 7; 9]

Notez que l'on aurait pu implémenter la fonction d'un coup, de cette façon:


let rec seq_step2 a b t = 
  if a > b then
    []
  else
    a::(seq_step2 (a + t) b t)

Le résultat semble strictement le même, et pourtant:


# seq_step 1 1000000 1;;
- : int list =
[1; 2; 3; 4; 5; 6; 7; 8; 9; ...]

# seq_step2 1 1000000 1;;
Stack overflow during evaluation (looping recursion?).

La deuxième version est arrêtée nette par un dépassement de pile. C'est que la première version est une récursion terminale (ou tail-recursion en anglais), c'est à dire qu'elle peut être trivialement transformée en une fonction itérative, ce que fait le compilateur. La deuxième, elle, utilise la pile comme accumulateur implicite, et provoque donc un dépassement de pile lorsque le nombre de récursions devient trop important.

Pour des raisons de performances et d'extensibilité, il est donc recommandé d'implémenter ses fonctions de manière récursive terminale à chaque fois que cela est possible.

Voilà, suivant l'approche ascendante qui sied bien à OCaml et aux langages fonctionnels, c'est à dire la construction de fonctions de base, puis de fonctions plus haut niveau utilisant ces briques, les utilitaires utilisés pour le crible. Dans la deuxième partie, je reprendrait plus en détails l'algorithme du crible lui-même.

Implémentation fonctionnelle d'un crible d'Ératosthène

2011-09-17T00:32:00.003+02:00

Voilà l'engin:


module OrderedInt =
struct
  type t = int
  let compare = compare
end

module IntSet = Set.Make(OrderedInt)

let seq_step a b t = 
  let rec do_seq_step a acc = 
    if a > b then 
      acc
    else
      do_seq_step (a + t) (a::acc)
  in
  List.rev (do_seq_step a [])

let sieve n = 
  let rec do_sieve current multiples primes = 
    if current > n then
      primes
    else if IntSet.is_empty multiples || IntSet.min_elt multiples <> current then
      do_sieve 
        (current + 2) 
        (List.fold_left 
           (fun acc e -> IntSet.add e acc)
           multiples
           (seq_step (current * 3) n (current * 2)))
        (current::primes)
    else
      do_sieve (current + 2) (IntSet.remove current multiples) primes
  in
  do_sieve 3 IntSet.empty [2]

Sur ma machine, compilé en natif, trouver les nombres premiers en dessous du million prend 2,7 secondes.

Un peu de fonctionel

2011-09-14T00:10:00.003+02:00

Je me suis remis à Project Euler, et résolu quelques problèmes supplémentaires. Je continue à tenter d'apporter des solutions aussi fonctionnelles pures que possible, ce qui m'a amener à réfléchir à un crible d’Ératosthène fonctionnel pur. Jusqu'ici, j'utilisais les fonctionnalités impératives d'OCaml pour m'en tirer un avec un gros tableau de booléens, mais en fait, si l'on considère un set d'entiers pour les multiplies, il est facile de faire quelque chose de plutôt efficace. Je dois mettre un peu d'ordre dans mon code, et je le posterai ici.

Normal maps et Blender 2.5 - Créer un astéroïde

2011-08-31T00:05:00.010+02:00

Le nouveau Blender ayant changé pas mal de choses, voici la version mise à jour de mon tutoriel sur les normal map, cette foi-ci pour créer un astéroïde.

Voici l'écran initial de Blender, après être passé à 4 vues (Ctrl-Alt-Q). Virons le cube (sélection avec bouton droit, puis DEL), et ajoutons une icosphère (Shift-A, Mesh => Icosphere).

L'on peut maintenant tortiller la sphère dans tous les sens: s + déplacements de souris pour changer sa taille, et s suivi de x, y ou z pour changer la taille dans une dimension seulement. L'on peut sélectionner les points individuellement en passant en mode vertex (TAB), et en sélectionnant les points avec le bouton droit. La touche g permet de déplacer les vertex, et l'on peut une fois de plus restreindre la dimension avec les touches x, y ou z. Formons donc un patatoïde.

Lequel patatoïde nous pouvons maintenant donner une forme plus douce, en y ajoutant le modifier "subdivisions". Dans le menu de droite, allez chercher le tab "Modifiers" (la petite clé à molette), et choisissez "Subdivision Surface". Mettons View et Render à 2.

L'on va ensuite rendre notre patatoïde tout doux: passez en mode vertex (TAB), selectionnez tout (a), et choisissez dans le menu "Mesh Tools" à gauche le shading "Smooth".

Allez chercher le tab "Material", et ajoutez un nouveau matériau.

Allez ensuite chercher le tab "Texture", et ajoutez une nouvelle texture. Pour donner un aspect rugueux à notre astéroïde, nous allons choisir une texture de type "Cloud", choisir un "noise" à "Hard", et changer son influence en désactivant "Colo" (pour couleur) et en activant "Nor" pour normales.

Ajustez vos couleurs, et admirez!

Maintenant, passons à la création de l'objet à exporter. D'abord, dupliquez l'astéroïde (Shift-D). Il est possible de renommer les objets en "high poly" et "low poly", par exemple, dans le menu "Object", histoire de ne pas se perdre. Enlevez le modifier de subdivisions afin de retrouver notre objet initial.

Ensuite, générez la texture UV (mode vertex, u, "Smart UV project"). Vous pouvez maintenant effectuer le rendu de la texture, en allant dans le tab "Render" (le petit appareil photo), et en allant tout en bas dans "Bake". Choisissez le bake mode "Normals", avec normal space "Object". Lancez le rendu avec "Bake".

Tout en haut, passez de la vue "Default" à la vue "UV editing" pour admirer votre œuvre. Sauvez l'image, puis exportez l'objet!

Avec OSG, je transforme l'objet exporté en Wavefront (.obj) vers un .osg, puis j'édite manuellement le .osg afin de dupliquer le noeud de texture, pour ajouter une deuxième texture avec un identifiant à 1. Je change ensuite les noms pour avoir ma texture de couleurs en 0, et ma texture de normales en 1, comme l'attend mon programme.

Et voilà le travail:

1000 cubes

2011-08-16T23:31:00.005+02:00

Un millier de cubes orbitant tranquillement. Le système monte gentiment en charge, avec une charge CPU à 125%, c'est à dire un proc à 100% pour afficher le plus d'images possible à la seconde, et 25% en calcul d'orbites et en passage de messages.

Orbites

2011-08-15T23:52:00.002+02:00

Il faut voir le cube tourner (je vais essayer de générer une vidéo), mais voilà déjà une image. Mon framework fonctionne, et devrait monter en charge facilement.

Cela représente donc un cube, doué d'une vitesse initiale, orbitant autour d'une masse pour l'instant non représentée. Cela devrait prouver ou pas la possibilité de mettre à jour des centaines d'objets, et de les représenter de façon fluide en recalculant "rarement" la position et la vitesse, puis en faisant une extrapolation à chaque image.

Week-end de folie chez Debian

2011-08-15T00:16:00.002+02:00

La bonne vieille Wheezy prend du poil de la bête: non seulement nous sommes passés en noyau 3.0, mais en plus Iceweasel 5 est sorti! Au menu, un très bon support de Youtube en HTML5. Peut-être vais-je enfin pouvoir me débarrasser de Flash?

Mon compilo est intelligent

2011-08-12T23:54:00.002+02:00

Brave g++!


#include <array>



int main()

{

  std::array<int, 5> a = {1, 2, 3, 4};

  std::array<int, 5> b = {1, 2, 3, 4, 5};

  std::array<int, 5> c = {1, 2, 3, 4, 5, 6};

  

  return 0;

}

Les tableaux a et b passent comme une lettre à la poste, mais le compilo hurle fort justement sur le tableau c, avec l'on ne peut plus explicite message:


array.cpp:9:43: error: too many initializers for ‘std::array<int, 5ul>’

Je n'en attendais pas tant. Magnifique!

Événements

2011-08-10T23:13:00.003+02:00

Je suis en train d'essayer de construire un truc qui se tient autour de boost::asio et de la programmation orientée événements. L'idée est de construire quelques briques de plus haut niveau autour d'asio, et d'en tirer quelque chose d'utilisable.

Tout tourne autour d'un boost::asio::io_service::strand, que j'ai collé dans une classe de base. J'en dérive (virtuellement!) ensuite des classes d'utilitaires tels un timer, ou un notifier / listener. Ensuite, il ne reste qu'à dériver sa classe depuis les classes d'utilitaires: l'on veut écouter tel type d'événements, recevoir un signal toutes les secondes, etc. Tout passer par le strand unique à la classe (d'où l'héritage virtuel), ce qui permet de s'affranchir complétement des locks.

Cela veut également dire que l'état de l'objet ne doit être modifié que depuis le strand, ce qui n'est aucunement garanti lorsque l'on appelle une méthode de l'objet. Il faut donc réexpédier tous les appels de méthodes publiques vers une méthode privée correspondante, à travers le strand. Vu que l'on passe alors un message, il n'est plus possible d'obtenir des valeurs de retour, uniquement des callbacks ou des objets protégés.

Bien évidemment, ce genre d'approche n'est utile que pour une classe limitée de problèmes. Écrire un raytracer orienté événement n'est probablement pas une bonne idée. En revanche, ces techniques pourraient bien se prêter aux jeux.

Iceweasel 5 bientôt dans Squeeze!

2011-08-03T21:16:00.002+02:00

La page d'"excuses" de Debian:

Too young, only 3 of 10 days old

Il y a quelques autres points, mais j'ai bien l'impression qu'on se dirige vers un Firefox un poil moderne pour dans une semaine. Chouette!

Et moi qui vous délaisse!

2011-08-01T22:54:00.004+02:00

C'est que, entre le recrutement d'espions britanniques cherchant à se recaser (eh oui), les batailles incessantes avec un système de middleware dont le nom commence par Tib et finit par Co, et le passage une fois de plus de la souris de la main droite à la main gauche pour des raisons de santé, il faut encore que j'arrive à caser du code à moi.

Le système d'update callbacks pour faire mon système de navigation à l'estime marche d'enfer: je puis passer entre mon système graphique, tournant à plusieurs centaines d'images par seconde, et le système de gamplay, tournant lui à 20 cycles, voire moins, par seconde, sans risquer ni de hacher l'un ni d'envahir l'autre.

En revanche, ma nième tentative pour obtenir un bump mapping dans l'espace tangent s'est achevé par une cuisante défaite. Je n'y arrive simplement pas. Je vais donc rester aux normales dans l'espace objet, telles que je les ai gérées jusqu'à présent.

Read

2011-07-27T00:16:00.004+02:00

"Mais pourquoi", me demande mon collègue, "est-ce que mon programme fonctionne quand je le débugge, mais pas lorsque je l'exécute? On dirait qu'il attrape de mauvais paquets du réseau, et il se retrouve à lire n'importe quoi."

Arf, du C#. Tentons d'y voir clair.

D'habitude, j'ai absolument horreur de débugger un programme qui ne donne pas les mêmes résultats lorsqu'il tourne dans un débuggeur. Mais là, il m'a semblé que ça ne devait pas être trop difficile. Déjà, il fut facile de s'en assurer, ce n'était pas le débuggeur, mais les breakpoints. Sans breakpoints, le programme foirait, semblant effectivement lire des données pourries sur le réseau. Avec breakpoints, ça passait.

Je tentais de voir quels étaient les breakpoints "magiques", en les ajoutant et les retirant suivant la rigoureuse méthode de Monte Carlo (c'est à dire au pif). Finalement, une ligne attira mon attention. Quelque chose comme:


networkStream.Read(data, length);

Je changeais prestement la ligne pour afficher côte à côte "length" et la valeur de retour de la méthode. S'affiche:


67889 - 1280

Tête du collègue médusé. Eh oui. Même en C#, et comme en C, "Read" va lire et retourner ce qu'il trouve dans le tampon, et peut donc renvoyer moins que la taille demandée. Le breakpoint permettait simplement à l'ensemble du paquet d'arriver dans le tampon, et donc de faire fonctionner le programme (le contenu des données était ignoré). Mais lors d'une exécution normale, Read était appelé avant que tout le paquet ne soit arrivé. Lors de la deuxième lecture, c'était la fin du premier paquet qui passait, et qui était donc interprété en dépit du bon sens.

Je dirigeais mon coreligionnaire vers une méthode à nous, répondant au doux nom de ReadExactly, et implémentée avec une belle boucle qui accumulait les Read jusqu'à la taille désirée.

Trop de choix

2011-07-23T00:55:00.003+02:00


void cb::EntityManager::processEvents()
{
  std::deque<std::shared_ptr<EntityEvent> > events;
  m_eventQueue->popAll(events);
  // version 1
  std::for_each(events.begin(),
                events.end(),
                std::bind(&EntityEvent::accept, std::placeholders::_1, this));
  // version 2
  for(const std::shared_ptr<EntityEvent> & event : events)
  {
    event->accept(this);
  }
  // version 3
  std::for_each(events.begin(),
                events.end(),
                [this](const std::shared_ptr<EntityEvent> & event){event->accept(this);});
}

Et je fais comment, moi, maintenant?

Autant j'adore les lambdas, autant c'est ici la solution la moins préférable: l'on a la déclaration explicite du contenu, contrairement à la solution basée sur std::bind, et l'on a l'overhead du la création de l'objet lambda, contrairement au range-based for.

Au final, je crois que je la solution du range-based for me plaît plus, car elle me semble vaguement plus efficace. Il faudra que je benchmarke un peu tout ça.

Coder efficacement avec Emacs - Partie 6 - Compilation

2011-07-20T23:19:00.004+02:00

Une de mes fonctionnalités favorites d'Emacs, c'est la console qui affiche les résultats de compilation. Il est possible de cliquer (ou d'utiliser d'absconses commandes clavier) pour aller d'erreur en erreur à travers le source. C'est quand même bien plus pratique que d'avoir la compilation dans une console à côté, et d'aller chercher le fichier et la ligne.

La commande, c'est M-x compile. Tout bête, mais déjà trop lorsque l'on est un serial compileur comme moi. Un petit

(define-key global-map [f5] 'compile)

dans mon .emacs et voici la touche F5 affectée à la compilation. Tapons F5: la ligne de compilation par défaut apparaît. Entrée, et c'est lancé. La combinaison F5-Entrée est devenue chez moi un automatisme. L'on peut changer la ligne de compilation, qui sera maintenue tant que la session est ouverte.

La commande de compilation par défaut est make -k, mais il est possible de la changer pour un mode particulier. Si comme moi vous êtes un fanatique d'omake pour compiler vos projets C ou C++:


(add-hook 'c-mode-common-hook
  (lambda ()
    (set (make-local-variable 'compile-command) "omake -j 4 -R")))

Et pour changer la commande par défaut hors d'un mode particulier:


(setq compile-command "omake -j 4 -R")

Bon codage!

C++0x - std::unique_ptr et types partiels

2011-07-17T00:02:00.003+02:00

Prenons un exemple très simple: l'idiome "pimpl" (dont le nom m'horripile, mais bon), encore appelé "pointeur opaque". Dans le .h, on forward déclare notre type interne, que l'on définit dans le .cpp. L'idée est de cacher l'implémentation, ce qui a également l'avantage de permettre une compilation plus rapide en évitant à l'interface l'inclusion d'une myriade d'en têtes pour les types privés.

Là, en bon dev C++11, l'on se dit, chic, je vais utiliser un std::unique_ptr. Voyons ce que cela donne. Ici, l'on a la classe Impl, forward déclarée, utilisée dans un std::unique_ptr, suivi d'un bout de code confirmant au compilo que l'on a bien l'intention d'instancier la classe Interface:


#include <memory>

class Impl;

class Interface
{
public:
  Interface();

private:
  std::unique_ptr<Impl> m_impl;
};

void create()
{
  Interface i;
}

L'on est immédiatement couvert d'injures par le compilateur:

g++ -std=gnu++0x -c uniq.cpp
In file included from /usr/include/c++/4.6/memory:85:0,
from uniq.cpp:1:
/usr/include/c++/4.6/bits/unique_ptr.h: In member function ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = Impl]’:
/usr/include/c++/4.6/bits/unique_ptr.h:245:4: instantiated from ‘void std::unique_ptr<_Tp, _Dp>::reset(std::unique_ptr<_Tp, _Dp>::pointer) [with _Tp = Impl, _Dp = std::default_delete, std::unique_ptr<_Tp, _Dp>::pointer = Impl*]’
/usr/include/c++/4.6/bits/unique_ptr.h:169:23: instantiated from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = Impl, _Dp = std::default_delete]’
uniq.cpp:5:7: instantiated from here
/usr/include/c++/4.6/bits/unique_ptr.h:63:14: error: invalid application of ‘sizeof’ to incomplete type ‘Impl’

Rajoutons juste un destructeur:


#include <memory>

class Impl;

class Interface
{
public:
  Interface();
  ~Interface();

private:
  std::unique_ptr<Impl> m_impl;
};

void create()
{
  Interface i;
}

Et g++ nous claque deux bises.

En effet, et d'après ce tableau, contrairement à std::shared_ptr, std::unique_ptr ne peut être détruit que si son type sous-jacent est complètement défini. Dans le premier exemple, le destructeur n'est pas défini, et g++ en définit donc un par défaut, inline. Il n'a donc pas accès au type Impl, ce qui cause l'erreur. Par contre, dans le deuxième exemple, l'on a décidé de fournir un destructeur quelque part ailleurs. Le compilateur n'a donc pas besoin de générer le code pour détruire notre pointeur. Celui-ci sera généré à la définition du destructeur, probablement dans le fichier source, et donc probablement après la définition complète d'Impl.

Design

2011-07-14T22:48:00.003+02:00

Je ne suis pas convaincu par ma manière actuelle de mettre à jour mon graphe de scènes. Attendant entre chaque frame pour mettre à jour mes objets, je ne puis utiliser à fond les dernières fonctionnalités de threading d'OpenSceneGraph.

J'ai donc pensé à un système de queue d'événements, qui sont lus via un callback, et mettent à jour les structures qui sont lus par les nœuds dans leurs propres callbacks de mise à jour. Ces structures seraient de la forme (timestamp, position, direction), et permettraient au nœud de mettre à jour sa position à chaque image en extrapolant.

Tout est là dedans:

Debian downgrade

2011-07-12T00:24:00.003+02:00

Arf, petit bug! À la suite d'un crash dans la libdbd, je ne pouvais plus démarrer le bon vieux gnucash et faire mes comptes. Downgradons donc dans la joie et la bonne humeur.

Après quelques recherches, j'atterris sur la page snapshot de Debian, dans laquelle je puis retrouver mon paquet. Je décide de passer de la 0.8.3-1+s-1 à la 0.8.2-1-4.1, et me retrouve avec un lien vers la libdbd-pgsql 0.8.2-1-4.1. Un petit dpkg -i plus tard, je démarre GnuCash, et miracle, j'y suis!

Par contre, il va maintenant falloir faire attention à chaque fois que je mets à jour: ne pas laisser le système me remplacer ma précieuse libdbd avant que le bug soit fixé.

Debian, c'est comme attendre le bus...

2011-07-10T13:06:00.003+02:00

On attend une version de gcc, et y'en a 3 qui arrivent en même temps :)

Maintenant qu'avec g++4.6, on a à peu près toutes les fonctionnalités de c++0x (c++11), j'attends maintenant avec impatience la mise à jour d'Iceweasel. Les web sockets m'intriguent, et bien qu'étant un peu allergique au Javascript, j'aimerais bien expérimenter avec des applications réellement réactives.

C++0x - std::set vs std::unordered_set

2011-07-02T20:48:00.003+02:00

Il aura tout de même fallu attendre C++0x (ou devrais-je commencer à dire C++2011?) pour voir enfin apparaître les tables de hachage dans la bibliothèque standard. Diverses extensions, ansi que Boost, proposaient leurs implémentations, mais ça fait toujours plaisir de voir les choses se standardiser.

Je dois cependant avouer que les tables de hachage m'ont souvent laissé un peu perplexe: leurs performances dépendent énormément du bon choix pour la fonction de hachage, ce qui rend fort difficile les prédictions. Je préfère généralement un bon arbre binaire, qui va certes nécessiter une allocation à chaque insertion et une recherche logarithmique, mais que j'ai l'impression de mieux comprendre.

Voyons donc un petit benchmark afin de se faire une idée. D'un côté, le bon vieux std::set, de l'autre, le std::unordered_set. L'on insère 1000 entiers, on mesure le temps, et l'on recommence.

Comme l'on pouvait s'y attendre, l'on voit que l'insertion dans un std::set augmente de manière logarithmique. L'on voit également que l'insertion dans un std::unordered_set augmente de manière linéaire, sauf au moment des rehash: une fois que la table est trop pleine, le conteneur réalloue une nouvelle table plus grande, et y hache de nouveau chaque élément.

Alors oui, le std::unordered_est est plus rapide que le std::set, sur un ensemble qui tendrait plutôt à défavoriser ce dernier: ayant utilisé des entiers consécutifs, le hachage est très efficace (c'est l'entier lui même), et il n'y a pas de collisions.

Cependant, si le std::unordered_set est plus efficace sur le long terme, ses performances instantanées peuvent tout d'un coup devenir absolument horribles si l'on doit re-hacher. Un programme qui nécessite de bonnes performances à chaque insertion, et pas seulement dans l'ensemble, devra l'éviter.

Une approche intéressante pour profiter des performances des tables de hachage sans payer un rehash couteux de temps en temps est d'amortir ce hachage: lorsque la table devient trop grande, l'on alloue une nouvelle table dans laquelle on met le nouvel élément. Chaque nouvelle insertion embarque avec elle quelques éléments de la vieille table, et chaque recherche vérifie les deux tables. Ainsi, au fur et à mesure, les éléments de la petite table sont déplacés dans la grande, et l'on peut se débarrasser de la petite, et recommencer le processus une fois que la grande devient à son tour trop pleine.

Voici le code du benchmark. Étrangement, la table de hachage a de meilleures performances à froid, et le std::set à chaud, ce qui est la raison pour laquelle je commence à insérer dans un set sans mesurer. Et je ne m'explique absolument pas le blip aux 3/4 de l'insertion dans le std::set, qui se reproduit à chaque exécution


#include <iostream>
#include <chrono>
#include <vector>
#include <set>
#include <unordered_set>

int main()
{
  int interval = 1000;
  int points = 1000000;
  
  std::vector<std::chrono::microseconds> setTimes;
  std::vector<std::chrono::microseconds> hashTimes;
  
  setTimes.reserve(points / interval);
  hashTimes.reserve(points / interval);
  
  {
    std::unordered_set<int> container;
    auto base = std::chrono::system_clock::now();
    for(int i = 0; i < points; ++i)
    {
      container.insert(i);
      if(i % interval == 0)
      {
        hashTimes.push_back(std::chrono::system_clock::now() - base);
      }
    }
  }

  {
    std::set<int> container;
    auto base = std::chrono::system_clock::now();
    for(int i = 0; i < points; ++i)
    {
      container.insert(i);
    }
  }
  {
    std::set<int> container;
    auto base = std::chrono::system_clock::now();
    for(int i = 0; i < points; ++i)
    {
      container.insert(i);
      if(i % interval == 0)
      {
        setTimes.push_back(std::chrono::system_clock::now() - base);
      }
    }
  }
  
  auto it = setTimes.begin();
  auto end = setTimes.end();
  auto it2 = hashTimes.begin();
  for(; it != end; ++it, ++it2)
  {
    std::cout << it->count() << "\t" <<  it2->count() << "\n";
  }
  std::cout.flush();
}

Commit 1024

2011-06-23T00:01:00.002+02:00

Un beau chiffre rond pour une implémentation fonctionnelle (dans le sens paradigme, pas dans le sens qualitatif) d'une couche client serveur au dessus de boost asio.

g++ 4.6 et C++0x - Range based for

2011-06-18T19:17:00.002+02:00

Petit bonus du week-end, g++4.6 débarque sur Debian Wheezy. La principale avancée concerne les "range based for", qui sonnent le glas pour la bonne vielle macro BOOST_FOREACH.

Pour une macro, BOOST_FOREACH était plutôt propre et utile, mais en dehors des détails d'implémentation à s'arracher les cheveux (cherchez un peu si ça vous amuse), elle souffrait de ne pas pouvoir utiliser proprement des déclarations templates, à cause notamment des virgules. Exemple:


#include <vector>
#include <string>
#include <iostream>
#include <boost/foreach.hpp>

int main()
{
  std::vector<std::pair<int, std::string> > v = 
    {std::make_pair(1, "a"),
     std::make_pair(2, "b")};

  BOOST_FOREACH(const std::pair<int, std::string> & item, v)
  {
    std::cout << item.first << " - " << item.second << std::endl;
  }

  return 0;
}

Oh, la belle erreur de compile!


foreach.cpp:12:60: error: macro "BOOST_FOREACH" passed 3 arguments, but takes just 2
foreach.cpp: In function ‘int main()’:
foreach.cpp:12:3: error: ‘BOOST_FOREACH’ was not declared in this scope
foreach.cpp:13:3: error: expected ‘;’ before ‘{’ token

La solution est triviale:


  typedef std::pair<int, std::string> ItemT;
  BOOST_FOREACH(const ItemT & item, v)
  {
    std::cout << item.first << " - " << item.second << std::endl;
  }

Triviale, mais ennuyeuse. Et non-standard. Et quand bien même utiliser des typedef pour ses types est une bonne idée, l'on on a parfois pas envie. Place donc à la solution 0x:


#include <vector>
#include <string>
#include <iostream>

int main()
{
  std::vector<std::pair<int, std::string> > v = 
    {std::make_pair(1, "a"),
     std::make_pair(2, "b")};
  
  for(const std::pair<int, std::string> & item : v)
  {
    std::cout << item.first << " - " << item.second << std::endl;
  }
  
  return 0;
}

C'est pas plus joli?

Entre les range based for et les lambdas, plus aucune raison d'utiliser la macro boost, et presque plus aucune raison d'utiliser une vieille boucle for. L'est pas belle, la vie?

Asio et sockets - Un design alternatif

2011-06-12T00:17:00.002+02:00

Jusqu'à présent, j'avais plutôt pris une route orientée objet, avec une session de base qui contient les appels socket asio dont il fallait dériver.

Cependant, je suis en train de me demander si une approche purement basée sur les callbacks pourrait donner de meilleurs résultats.

Je viens de commiter une classe très simple, dont on ne dérivera à priori pas, et dont voici la signature:


class SocketSession : public std::enable_shared_from_this<SocketSession>
{
public:
  SocketSession(boost::asio::io_service & io_service);
  
  void connect(const std::string & host,
               int port,
               const std::function<void()> & callback);
  
  template<typename BODY>
  void readMessage(const std::function<void(const std::shared_ptr<Header> &, 
                                            const std::shared_ptr<BODY> &)>
                                            & callback);

  template<typename BODY>
  void sendMessage(const BODY & body);
}

Toutes les méthodes publiques sont thread safe, car appelant en interne les méthodes correspondantes à travers un strand. L'appelant, lui, se contente de passer les callbacks, lequels peuvent être également protégés par leur propre strand.

Avantages:

Le système est complètement thread safe

Pas besoin de locks, les appels sont tous protégés par le strand. C'est particulièrement utile pour l'envoi de messages, puisqu'il faut pousser les messages dans une queue afin de n'avoir qu'un seul appel à async_write

Contrairement à mon implémentation "dérivante", la partie socket pourra tourner de manière concurrente avec l'appelant, ce qui pourrait permettre une meilleure montée en charge (à vérifier, cependant). Tout du moins, en laissant à l'utilisateur de la classe le choix de protéger ses callbacks à travers un strand, on peut permettre une meilleure parallélisation lorsque c'est possible

L'inconvénient majeur est la multiplication des callbacks, et donc de copies et d'allocations.

Postgresql et encore plus de requêtes récursives

2011-06-08T22:18:00.004+02:00

L'on m'a posé récemment un intéressant problème de base de données qui pourrait se traduire ainsi: étant donné la liste d'employés suivante, déterminer le premier directeur auquel se rattache chaque employé:


create table employees(
 id integer not null,
 name text not null,
 level text not null,
 manager_id integer null);

insert into employees values
(1, 'Anne', 'CEO', null),
(2, 'Barbara', 'Director', 1),
(3, 'Carole', 'Director', 2),
(4, 'Delphine', 'Director', 2),
(5, 'Eleonore', 'Supervisor', 2),
(6, 'Fanny', 'Supervisor', 3),
(7, 'Gwen', 'Supervisor', 5),
(8, 'Henriette', 'Supervisor', 7),
(9, 'Isabelle', 'Employee', 5),
(10, 'Juliette', 'Employee', 6),
(11, 'Kariane', 'Employee', 5),
(12, 'Lucie', 'Employee', 4);

La première étape est de pondre une requête récursive, nous donnant pour chaque employé la liste de ses chefs. L'on tiendra à jour également la distance hiérarchique:


with recursive managers(employee_id, manager_id, depth) as(
select id, manager_id, 1 from employees
 union
select m.employee_id, e.manager_id, m.depth + 1
from managers m
join employees e on m.manager_id = e.id)
select 
 e1.id, 
 e1.name, 
 m.depth, 
 e2.id, 
 e2.name, 
 e2.level
from managers m
join employees e1 on m.employee_id = e1.id
join employees e2 on m.manager_id = e2.id

Cette requête retourne les résultats suivants:


2,Barbara,1,1,Anne,CEO
3,Carole,1,2,Barbara,Director
4,Delphine,1,2,Barbara,Director
5,Eleonore,1,2,Barbara,Director
6,Fanny,1,3,Carole,Director
7,Gwen,1,5,Eleonore,Supervisor
8,Henriette,1,7,Gwen,Supervisor
9,Isabelle,1,5,Eleonore,Supervisor
10,Juliette,1,6,Fanny,Supervisor
11,Kariane,1,5,Eleonore,Supervisor
12,Lucie,1,4,Delphine,Director
3,Carole,2,1,Anne,CEO
4,Delphine,2,1,Anne,CEO
5,Eleonore,2,1,Anne,CEO
6,Fanny,2,2,Barbara,Director
7,Gwen,2,2,Barbara,Director
8,Henriette,2,5,Eleonore,Supervisor
9,Isabelle,2,2,Barbara,Director
10,Juliette,2,3,Carole,Director
11,Kariane,2,2,Barbara,Director
12,Lucie,2,2,Barbara,Director
6,Fanny,3,1,Anne,CEO
7,Gwen,3,1,Anne,CEO
8,Henriette,3,2,Barbara,Director
9,Isabelle,3,1,Anne,CEO
10,Juliette,3,2,Barbara,Director
11,Kariane,3,1,Anne,CEO
12,Lucie,3,1,Anne,CEO
8,Henriette,4,1,Anne,CEO
10,Juliette,4,1,Anne,CEO

On approche. Prenons donc seulement le cas où un chef est un directeur, et voyons ce que cela donne:


with recursive managers(employee_id, manager_id, depth) as(
select id, manager_id, 1 from employees
 union
select m.employee_id, e.manager_id, m.depth + 1
from managers m
join employees e on m.manager_id = e.id)
select 
 e1.id, 
 e1.name, 
 m.depth, 
 e2.id, 
 e2.name, 
 e2.level
from managers m
join employees e1 on m.employee_id = e1.id
join employees e2 on m.manager_id = e2.id
where e2.level = 'Director'

3,Carole,1,2,Barbara,Director
4,Delphine,1,2,Barbara,Director
5,Eleonore,1,2,Barbara,Director
6,Fanny,2,2,Barbara,Director
6,Fanny,1,3,Carole,Director
7,Gwen,2,2,Barbara,Director
8,Henriette,3,2,Barbara,Director
9,Isabelle,2,2,Barbara,Director
10,Juliette,3,2,Barbara,Director
10,Juliette,2,3,Carole,Director
11,Kariane,2,2,Barbara,Director
12,Lucie,2,2,Barbara,Director
12,Lucie,1,4,Delphine,Director

Mieux! Mais comme parfois un directeur dépend d'un autre directeur, les pauvres Fanny, Juliette et Lucie sont en double. Il faut donc ne récupérer pour un employé que le cas où la profondeur est la plus basse. Cela donne des requêtes plutôt ésotériques en vieux SQL. Mais une fois de plus, la modernité nous tend les bras, et les window function permettent de résoudre le problème (presque) immédiatement. Prenons donc la fonction rank(), qui retourne le rang d'une ligne sur une certaine partition. Nous cherchons donc le rang d'une ligne d'employé, partitionné sur cet employé, et ordonné par la profondeur:


with recursive managers(employee_id, manager_id, depth) as(
select id, manager_id, 1 from employees
 union
select m.employee_id, e.manager_id, m.depth + 1
from managers m
join employees e on m.manager_id = e.id)
select 
 e1.name as employee_name, 
 e2.name as director_name, 
 rank() over (partition by e1.name order by depth)
from managers m
join employees e1 on m.employee_id = e1.id
join employees e2 on m.manager_id = e2.id
where e2.level = 'Director'

Carole,Barbara,1
Delphine,Barbara,1
Eleonore,Barbara,1
Fanny,Carole,1
Fanny,Barbara,2
Gwen,Barbara,1
Henriette,Barbara,1
Isabelle,Barbara,1
Juliette,Carole,1
Juliette,Barbara,2
Kariane,Barbara,1
Lucie,Delphine,1
Lucie,Barbara,2

On y est presque. Nous voilà donc avec le rang basé sur la profondeur, par nom. Lucie dépend donc d'abord de Delphine, et ensuite de Barbara. Maintenant, obtenir le résultat final est trivial:


select employee_name, director_name 
from
(
 with recursive managers(employee_id, manager_id, depth) as(
 select id, manager_id, 1 from employees
  union
 select m.employee_id, e.manager_id, m.depth + 1
 from managers m
 join employees e on m.manager_id = e.id)
 select 
  e1.name as employee_name, 
  e2.name as director_name, 
  rank() over (partition by e1.name order by depth)
 from managers m
 join employees e1 on m.employee_id = e1.id
 join employees e2 on m.manager_id = e2.id
 where e2.level = 'Director'
) t
where rank = 1

Carole,Barbara
Delphine,Barbara
Eleonore,Barbara
Fanny,Carole
Gwen,Barbara
Henriette,Barbara
Isabelle,Barbara
Juliette,Carole
Kariane,Barbara
Lucie,Delphine

La requête n'est certes pas tout à fait basique, mais elle est relativement claire grâce à la séparation entre la partie récursive d'abord, la window fonction ensuite, et enfin la sur-requête finale pour présenter les résultats. Sans ces outils, l'on aurait eu une panoplie de sous-requêtes se joignant elles-mêmes, pour un résultat bien moins propre, et bien moins efficace.

Plus d'asio, et copy_if

2011-06-05T00:19:00.002+02:00

Je me remets à Asio, et j'essaie notamment de ré-implémenter un handler potable pour mes connections socket en multithreadé. L'idée est également d'abstraire un peu toute la cochonnerie derrière, afin de pouvoir implémenter très proprement son protocole à l'aide de callbacks. J'espère obtenir quelque chose de suffisamment puissant et réactif avec une intégration asynchrone avec un pool de connections vers la base.

Dans un tout autre registre, je me suis battu récemment avec la STL, et notamment avec l'absence de copy_if. Ce que je voulais vraiment:


std::copy_if(input.begin(),
             input.end(),
             std::back_inserter(output),
             boost::bind(&Class::predicate, this, _1));

Mais, copy_if ayant (selon Stroustrup) été oublié, il faut faire avec et utiliser remove_copy_if, qui fait exactement l'inverse. Je me suis battu avec des std::not1 et des bind dans tous les sens, sans arriver à faire compiler la chose. En fait, c'était tout bête.


std::remove_copy_if(input.begin(),
                    input.end(),
                    std::back_inserter(output),
                    !boost::bind(&Class::predicate, this, _1));

Pourquoi ça marche? J'avoue que je ne comprends pas vraiment le fonctionnement interne de bind, et que je le vois plus comme un pointeur sur fonction, avec lequel un ! ne fonctionnerait pas. C'est donc assez magique.

Valgrind massif - Mémoire un peu trop vive

2011-06-03T22:38:00.004+02:00

Je me suis mis à utiliser massif de la suite Valgrind, destiné à mesurer l'utilisation mémoire d'un programme au cours du temps, plus spécifiquement du tas (c'est à dire de la mémoire allouée via malloc/new).

L'outil est très bien tourné: il suffit de compiler son programme avec -g, et de le faire tourner sous massif. Un petit rapport est généré, contenant un certain nombre de snapshots avec le détail de l'utilisation mémoire, et la liste des appels l'ayant générée.

C'est là que l'on retrouve nos bonnes vieilles structures de données: les std::set et les std::map sont des structures tout à fait épatantes, mais l'overhead est significatif. L'on retrouvera ainsi quelles structures bénéficieraient d'une transformation vers un std::deque trié, par exemple.

C'est également une bonne manière de trouver les buffers qui grandissent perpétuellement. Un bout de code qui lirait les paquets venus du réseau pourrait par exemple être implémenté avec un vecteur effectuant des resize() pour redimensionner à la taille du paquet. Mais si resize() peut augmenter la capacité si besoin, il ne la réduit jamais! La seule manière de réduire proprement un vecteur, c'est de l'échanger avec un vecteur tout neuf. Démonstration:


#include <iostream>
#include <vector>

int main()
{
  std::vector<int> a;
  
  std::cout << "size\tcapacity\n";
  std::cout << a.size() << "\t" << a.capacity() << "\n";
  
  a.resize(10000);

  std::cout << a.size() << "\t" << a.capacity() << "\n";

  a.resize(1);

  std::cout << a.size() << "\t" << a.capacity() << "\n";
  
  std::vector<int> b(a.begin(), a.end());
  std::swap(b, a);

  std::cout << a.size() << "\t" << a.capacity() << "\n";

  std::cout.flush();

  return 0;
}

À l'exécution:


size    capacity
0       0
10000   10000
1       10000
1       1

La lib geos

2011-06-03T00:28:00.003+02:00

La bibliothèque geos permet de gérer des objets géométriques en vue d'une intégration avec divers logiciels de gestion de données géographiques. L'on remarquera en particulier le support du format WKB (pour Well Known Binary) qui le rend donc compatible (efficacement!) avec Postgresql/Postgis.

J'étudie actuellement la possibilité d'utiliser ces outils pour gérer mes mondes OpenRailz. Le gros intérêt est d'avoir déjà tout un tas d'opérations sur les géométries. Les défauts sont tout une plus grande difficulté d'intégration (pas de visiteurs, donc probablement besoin de faire de moches dynamic_cast pour afficher la géométrie, par exemple), des std::auto_ptr un peu partout qui vont faire hurler mon compilo C++0x, et enfin probablement des soucis pour gérer les objets 3D correctement.

J'imagine qu'en considérant un certain nombre de couches horizontales dans le monde, l'on peut se ramener à des problèmes en 2D dans chaque couche.

Première étape, pondre un schéma de BDD qui tienne la route.

Postgresql et Postgis pour l'aviation

2011-05-26T00:16:00.002+02:00

Découvert via le planet de Postgresql, une excellente présentation d'une utilisation de Postgis, le module Postgresql de gestion des données géographiques, dans le domaine de l'aviation, et plus particulièrement de la gestion des plans de vols.

XSD - Pas évident

2011-05-16T23:34:00.002+02:00

Assez moches, finalement, les schémas XSD. Documentation absconse, grammaire peu claire, et bien trop de façons de générer la même chose.

C'est que j'essaie de reprendre le bon vieux mlxsd et de le rendre un peu plus respectueux des standards. Et c'est pas de la tarte.

Ocaml Lwt - Mini tutorial

2011-05-02T18:00:00.004+02:00

Connaissez-vous Lwt? C'est une bibliothèque proposant un modèle asynchrone autour des fibres, ou threads légers (déjà qu'un thread était un processus léger, est-ce qu'une fibre est un processus vachement léger?) coopératifs, c'est à dire que la fibre va s'exécuter jusqu'à ce qu'elle laisse le champ libre à une autre fibre, via des appels spéciaux, par exemple pour effectuer des opérations d'entrée sortie, ou attendre un résultat fourni par une autre fibre.

Je trouve le manuel un poil léger, donc voici une série d'exemples très simples pour se faire une idée de l'utilisation du bazar. L'idée est généralement de créer un thread lwt, puis de le faire tourner via un appel à Lwt_main.run jusqu'à ce que l'exécution du thread soit complétée, et d'en récupérer une valeur de retour.

Dans un terminal ocaml, ces commandes permettent de charger les bibliothèques lwt:


#use "topfind";;
#require "lwt";;
#require "lwt.extra";;

C'est parti. L'exemple le plus simple: ce bout de code créé un bête thread lwt déjà terminé, contenant la valeur 3. Le Lwt_main.run attend que le thread soit complété et en retourne la valeur. Dans ce cas, il n'a rien à faire que de simplement retourner 3.

let t = Lwt.return 3 in
Lwt_main.run t

Un premier exemple faisant enfin quelque chose: l'on utilise la fonction Lwt_unix.sleep, lequel retourne un thread qui se termine au bout d'un certain temps. Cette fonction va donc dormir pendant 2 secondes avant de retourner unit.

let t = Lwt_unix.sleep 2. in
Lwt_main.run t

Voici l'utilisation d'une routine d'entrée sortie. Parce que les threads sont coopératifs, il est nécessaire de ne jamais bloquer ou utiliser des fonctions d'entrée / sortie non bénies par lwt. L'on utilisera donc Lwt_io pour lire et écrire des fichiers ou les entrées sorties standard. Le modèle est le même: notre thread écrit "Miaou" sur la sortie standard, et le thread est complété.

let t = Lwt_io.write_line 
  Lwt_io.stdout
  "Miaou"
in
Lwt_main.run t

Ah, la fonction Lwt.bind! Elle permet de chaîner les threads: quand un thread est complété, il passe son résultat au suivant, qui s'exécute à son tour. Dans notre cas, le plus simple, nous passons unit à la fonction qui écrit. Vous l'aurez deviné, ce bout de code attend 2 secondes, puis affiche "Miaou" à l'écran.

let t = 
  Lwt.bind
    (Lwt_unix.sleep 2.)
    (fun () -> Lwt_io.write_line Lwt_io.stdout "Miaou")
in
Lwt_main.run t

Enfin, un exemple démontrant les capacités asynchrones de Lwt. Dans cet exemple, l'on créé 3 threads qui chacun attendent un certain temps avant d'afficher un message. La fonction Lwt.join retourne une fois que les 3 threads sont complétés. Quelque soit l'ordre dans lequel les threads ont été passés à la fonction, ils s'afficheront bien en temps voulu.

let sleep_and_print duration message = 
  Lwt.bind
    (Lwt_unix.sleep duration)
    (fun () -> Lwt_io.write_line Lwt_io.stdout message)
in
let t = Lwt.join
  [sleep_and_print 3. "3 secondes";
   sleep_and_print 4. "4 secondes";
   sleep_and_print 2. "2 secondes"]
in
Lwt_main.run t

Voilà les bases, à partir de là il ne s'agit plus que de chaîner les fonctions d'entrées sorties Lwt décrites dans le manuel.

J'ai l'intention d'essayer d'écrire un petit moteur asynchrone orienté événements, permettant à l'utilisateur de souscrire dynamiquement à un certain nombre d'entrées, comme par exemple une horloge, des entrées réseau, ou des passages de messages (probablement pas pour OpenRailz, mais on ne sait jamais...).

Le mot de la fin: OCaml ne permet pas l'exécution concurrente de code car il possède, tout comme Python d'ailleurs, un verrou global. Lwt ne change pas cette règle, et n'est donc pas orienté vers du "number crunching", par exemple, mais permet en revanche de designer de manière très élégante des applications réactives devant gérer des événements complexes. Les appels coopératifs s'assurent que l'application n'est jamais en train d'attendre alors qu'un autre bout de code pourrait être exécuté, ce qui permet d'aller taper dans la base de données, écouter des messages réseau, lire des fichiers, et logger dans d'autres d'une manière transparente et claire. Cool non?

Performances: Asio custom alloc

2011-04-24T12:02:00.004+02:00

Reprenant le post précédent, je me suis demandé quel était l'effet des allocations sur les performances. Puisqu'Asio permet de customiser ses allocateurs, j'ai adapté l'exemple fourni par Asio à ma comparaison boost::bind contre lambda.

Tout d'abord, Valgrind confirme effectivement que les allocations sont parties (test réduit à 2000 tâches, sinon ça prenait la nuit):


==3194== Memcheck, a memory error detector
==3194== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3194== HEAP SUMMARY:
==3194==     in use at exit: 0 bytes in 0 blocks
==3194==   total heap usage: 2,006 allocs, 2,006 frees, 96,496 bytes allocated

==3205== Memcheck, a memory error detector
==3205== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3205== HEAP SUMMARY:
==3205==     in use at exit: 0 bytes in 0 blocks
==3205==   total heap usage: 6 allocs, 6 frees, 496 bytes allocated

Ensuite, étonnamment, les performances ne sont pas si différentes:

J'avais imaginé que le million d'allocations prendrait la part du lion dans l'exécution du programme, mais de fait l'on ne parle que d'une différence de 10%. C'est toujours bon à prendre, mais loin d'être un miracle.

Pour un gain de 0.15μs par allocation, il me semble inutile de se fatiguer à passer par un allocateur fait à la mimine, à part peut-être dans les cas extrêmes où l'on cherche à réduire la latence par tous les moyens.

Performances: lambda vs boost::bind

2011-04-20T22:48:00.002+02:00

Maintenant que l'on a les lambdas, peut-on se passer de boost::bind? Et qui est le plus rapide?

Voici un petit programme qui fait tourner un certain nombre de "tâches" de manière asynchrone à travers le framework asio, en passant un handler soit via un (une?) lambda, soit un boost::bind.


#include <iostream>
#include <chrono>

#include <boost/asio.hpp>
#include <boost/bind.hpp>


class Recursive
{
public:
  Recursive(boost::asio::io_service & io_service,
            bool lambda,
            int max):
    m_io_service(io_service),
    m_lambda(lambda),
    m_max(max)
  {
  }
  
  void run(int i)
  {
    if(i < m_max)
    {
      if(m_lambda)
      {
        m_io_service.post([this, i](){run(i + 1);});
      }
      else
      {
        m_io_service.post(boost::bind(&Recursive::run,
                                      this,
                                      i + 1));
      }
    }
  }
  
private:
  boost::asio::io_service & m_io_service;
  bool m_lambda;
  int m_max;
};

int main()
{
  {
    boost::asio::io_service io_service;
    Recursive rec(io_service, true, 10000000);
    io_service.post([&rec](){rec.run(0);});
    
    auto t1 = std::chrono::system_clock::now();
    
    io_service.run();
    
    auto t2 = std::chrono::system_clock::now();
    std::cout << "lambda: " << (t2 - t1).count() << std::endl;
  }

  {
    boost::asio::io_service io_service;
    Recursive rec(io_service, false, 10000000);
    io_service.post([&rec](){rec.run(0);});
    
    auto t1 = std::chrono::system_clock::now();
    
    io_service.run();
    
    auto t2 = std::chrono::system_clock::now();
    std::cout << "bind: " << (t2 - t1).count() << std::endl;
  }
}

Eh bien, les braves petites lambdas sont significativement plus rapides que boost::bind, d'environ 5 à 6 %. Il ne s'agit pas d'allocations, valgrind confirmant que les allocations mémoire restent les mêmes. Peut-être le foncteur correspondant à un boost::bind est-il plus compliqué à construire.

Fglrx sur Debian - Encore des histoires

2011-04-13T01:44:00.002+02:00

Ça faisait longtemps que ça n'avait pas foiré, j'avais donc perdu l'habitude. Le retour de manivelle fut rude: avec l'arrivée du noyau 2.6.38, le serveur X m'a sauté à la figure avec ses habituels "fglrx(0): ACPI: DRM connection failed", "atiddxDriScreenInit failed", pour finir par segfaulter lamentablement.

Une petite recherche finit par me convaincre que le module noyau n'était tout simplement pas présent. À l'installation et à la désinstallation du module fglrx-modules-dkms, je voyais bien la compile pour les noyaux 2.6.30 et 2.6.32, mais pas pour le nouveau menu.

Finalement, c'était tout bête. Il me fallait simplement les kernel headers 2.6.38. Un petit "aptitude install linux-headers-2.6.38-2-amd64", lequel automatiquement construit tous les modules nécessaires, et je suis de retour avec l'accélération matérielle.

Ouf.

Postgresql et Ocaml: performances à l'insertion

2011-04-06T23:56:00.003+02:00

Postgresql permet 2 types d'insertions: les insertions en pur SQL à l'aide d'un "insert", et les copies. À quel point les copies sont-elles plus efficaces que les insertions?

Voici quelques tests rapides via le mode immédiat d'Ocaml, en passant par le wrappeur Postgres. Ouvrons tout d'abord une connexion.


ocaml -I /usr/lib/ocaml/postgresql/ -I /usr/lib/ocaml/threads
# #load "unix.cma";;
# #load "threads.cma";;
# #load "bigarray.cma";;
# #load "postgresql.cma";;
# let connectionstring = "host=localhost dbname=Test";;
# let c = new Postgresql.connection ~conninfo:connectionstring ();;

Voici quelques fonctions de base qui servent respectivement à créer une séquence de a à b, et à mesurer le temps pour exécuter une fonction donnée. Notez que "seq" est un peu alambiquée pour permettre la tail-recursion (et donc de demander des sequences de 1M d'éléments sans dépassement de pile).


# let seq a b = 
   let rec do_seq a r = 
    if a > b then r else do_seq (a + 1) (a::r) 
   in List.rev(do_seq a []);;
# let time f e = 
   let t1 = Unix.gettimeofday() in f e; 
   let t2 = Unix.gettimeofday() in 
   t2 -. t1;;

Et enfin, les deux fonctions à tester, l'une faisant tourner n insertions dans une transaction, l'autre utilisant la copie.


# let run n = 
   ignore(c#exec "begin"); 
   List.iter 
    (fun e -> ignore(c#exec  
                     ~params:[|string_of_int e; "def"; "0.143"|] 
                     "insert into data values($1, $2, $3)")) 
    (seq 1 n); 
   ignore(c#exec "commit");;
# let batch n = 
   ignore(c#exec "copy data from stdin"); 
   List.iter 
    (fun e -> ignore(c#putline ((string_of_int e)^"\tdef\t0.143\n"))) 
    (seq 1 n); 
   ignore c#endcopy;;

Ces fonctions font strictement la même chose, c'est à dire insérer pour i de 1 à n, {i, "def", 0.143} dans une table ayant pour colonnes un entier, une chaîne, et un double.

L'on fait tourner...


# time run 100000;;
- : float = 13.3781638145446777
# time batch 100000;;
- : float = 0.458184957504272461

Ce qui nous donne un déjà très honorable 7500 insertions par seconde avec des insert, et un ahurissant 220000 insertions par seconde avec une copie. Les gains sont encore plus significatifs avec plus de lignes, la copie atteignant 240000 insertions par seconde pour 1 million d'éléments.

Notez tout de même que ma base est configurée avec fsync = off afin d'éviter les coûteuses synchronisations avec le disque. Quand bien même il est vrai qu'attendre que tout soit écrit aplanirait les différences, un cas d'utilisation standard d'insertions massives est la jointure avec une table temporaire pour faire un select, par exemple, pour lequel les écritures disques ne rentreront pas en compte.

Ce qui nous fait donc quand même une insertion par copie 30 fois plus rapide qu'une insertion en SQL pur.

stream iterators

2011-04-05T00:01:00.004+02:00

C'est un équilibre, il me faut ma dose de code. Et vu que j'en ai en quantités industrielles au boulot, j'ai plutôt tendance à me rattraper sur mes lectures une fois réintégré mon trou. Cependant, ce n'est pas une raison pour se laisser totalement abattre, et je me suis dit que j'allais mentionner une fonctionnalité que je me suis mis à utiliser récemment: les stream iterators. À ma grande honte, je dois admettre que j'en ai compris l'utilité en notant un exercice d'un candidat lors d'une de nos sessions de recrutement. L'ensemble était moyen, mais sa manière de lire les fichiers de données était tout à fait remarquable.

Exercice classique: étant donné un fichier contenant une liste d'entiers, les mettre dans un vecteur, et les afficher à l'écran.

Les solutions habituelles vont du plus manuel à coup de buffers et de recherche d'espaces, ou de caractères non numériques, à des choses plus propres de type boucles avec des ifstream. Sans parler des soucis à la fin du fichier, pour savoir quand s'arrêter, comment supporter un retour chariot final ou pas...

Avec les istream_iterator, c'est un plaisir: comme leur nom l'indique, on leur donne un istream, et on itère.


#include <iostream>
#include <fstream>
#include <vector>
#include <algorithm>
#include <iterator>

int main()
{
  std::vector<int> myNumbers;

  std::ifstream f("myfile.txt");
  std::copy(std::istream_iterator<int>(f),
            std::istream_iterator<int>(),
            std::back_inserter(myNumbers));
  
  std::for_each(myNumbers.begin(),
                myNumbers.end(),
                [](int i){std::cout << i << "\n";});
  std::cout.flush();

  return 0;
}

Et le résultat:


$ cat myfile.txt 
1 123 33 2222 1425
78
11

$ ./test
1
123
33
2222
1425
78
11

J'avoue, je n'ai pas pu m'empêcher de coller une lambda. On ne se refait pas.

Alors certes, ce n'est que de l'encapsulation de fonctionnalités de base. Mais c'est pour moi le bon idiome pour ce genre d'activités, et j'aimerais voir plus de code se baser dessus, et moins sur des solutions à la mimine et trop souvent buggées.

La beauté de la chose apparaît complétement lorsque l'on se rend compte qu'on peut passer n'importe quel objet streamable en paramètre template. Créez votre objet, son opérateur de stream, et basta, lisez-en des listes et des listes.

Dernière remarque, un poil hors sujet: je crois que la beauté des stream et de la hiérarchie de classe associée n'apparaît vraiment que le jour où vous devez faire un test unitaire d'une horreur prenant un FILE *. Le triptyque istream pour la classe générique, istringstream pour les tests unitaires et ifstream pour la production resplendit au firmament de l'ingénierie logicielle.

Être consistent...

2011-03-22T22:49:00.003+01:00

Rhaaa, IBM! Ils viennent de confirmer après 3 jours d'arrachage de cheveux qu'ils ne supportent pas une fonctionnalité qui semble pourtant basique.

DB2, ou plutôt son API C, répondant au doux nom de CLI, fournit un mode très efficace exécuter plusieurs fois une même requête. L'idée est de créer un tableau, de "binder" ce tableau à une colonne (via un appel à SQLBindParameter), puis d'exécuter la requête préparée. Tout est envoyé en une fois à la base, ce qui évite l'effet ping-pong entre le client et le serveur. Par exemple, une requête "insert into mytable values(?)" permet d'insérer des milliers de lignes en un seul appel.

Nous codons donc une belle couche d'abstraction en C++, et continuons joyeusement à coder.

Jusqu'au jour où je découvre que le binding par colonnes ne fonctionne pas avec les procédures stockées. Dans le genre, je créé une procédure qui fait un bête insert dans mytable, et j'appelle "call myproc(?)". Pire, DB2 va exécuter la procédure, mais seulement sur le premier élément, ce qui cause un beau bordel dans la base. La documentation est peu claire sur ce point précis, la spec ODBC dit que ça devrait marcher. Eh ben non.

Reprenons: Une fonctionnalité qui semble pourtant aller de soi manque, ce manquement est mal documenté, et au lieu d'envoyer un message d'erreur clair, seule une partie de la requête tourne, causant une corruption des données. Peut-être que la raison fondamentale est que insert, update et delete supportent un vrai mode d'insertion par tableau, mais dans ce cas pourquoi ne pas au moins tenter d'être consistent, et pour le moteur de base de données de revenir dans un mode ligne par ligne dans le cas des procédures stockées? J'ai du mal à penser qu'IBM n'a pas les moyens humains de fournir quelque chose qui semble aussi trivial.

La solution, c'est d'utiliser le binding par valeur pour toute requête contenant une procédure stockée, mais c'est difficile à abstraire, puisqu'il faut soit laisser à l'utilisateur le choix (et donc la chance de se tromper), soit tenter d'analyser la requête pour détecter si elle est optimisable. En l'occurence, j'ai choisi la sale mais raisonnablement triviale solution d'optimiser si le premier mot de la requête est "insert". Et le code de la couche d'abstraction devient plus moche car il doit supporter deux types de bindings, et donc deux chemins de code, avec les presque duplications et l'augmentation des risques de se bugs qui vont avec. Beurk.

g++ 4.5 et C++0x - Les nouveautés

2011-03-13T12:26:00.002+01:00

J'ai porté Openrailz sous g++4.5, ce qui me permet d'utiliser plus de fonctionnalités de C++0x, mais a également soulevé quelque problèmes inattendus. Petit topo.

Destructeur virtuel et = default

Tout d'abord, les mauvaises nouvelles. Je ne sais si vous avez déjà souffert du problème, mais je n'ai jamais trouvé une manière complétement satisfaisante d'implémenter le destructeur virtuel en écrivant une interface. L'on peut inliner le code:


class Miaou
{
  virtual ~Miaou() {}
};

mais c'est moche. L'on peut mettre le code en dessous:


class Miaou
{
  virtual ~Miaou();
};

inline Miaou::~Miaou()
{
}

mais c'est encore plus moche, sans compter la verbosité lorsque la déclaration est un peu plus complexe (gros template, par exemple). Enfin, l'on peut juste mettre la déclaration dans son .cpp, mais on se retrouve avec un .cpp qui ne contient qu'une déclaration vide, et toujours aussi potentiellement verbeuse.

Lorsque j'ai découvert le = default de C++0x, je me suis dit, bonne nouvelle, voilà enfin comment résoudre le problème:


class Miaou
{
  virtual ~Miaou() = default;
};

C'est joli, moderne, et ça fait exactement ce que ça dit. Malheureusement, c'est également interdit par le standard, et si g++4.4 laissait passer, g++4.5 le bloque. Le standard interdit en effet de déclarer un destructeur virtuel par défaut à la première déclaration. C'est à dire que pour écrire du code correct, il faut faire:


class Miaou
{
  virtual ~Miaou();
};

inline Miaou::~Miaou() = default;

ce qui est tout aussi moche. Retour donc a la case départ.

Strict aliasing rules et boost::optional

J'avais commencé à virer les boost::optional de ma codebase, car ils causaient un ennuyeux warning dans g++4.4:


#include <iostream>
#include <boost/optional.hpp>

int main()
{
  boost::optional<int> b;
  if(b)
  {
    std::cout << *b << std::endl;
  }

  return 0;
}

La compilation avec g++4.4 renvoie ce message:

optional.cpp: In function ‘int main()’:
optional.cpp:10: warning: dereferencing pointer ‘’ does break strict-aliasing rules
optional.cpp:10: note: initialized from here

Alors, bien sûr, l'on peut utiliser le flag -fno-strict-aliasing, mais l'on réduit les performances.

Les discussions sont allé bon train sur les mailing-lists de Boost, mais il semblerait que le code soit en fait bon, et qu'il s'agisse d'un bug de g++4.4. G++4.5 ne se plaint pas sur ce code, et je compte donc bien le réintégrer vite fait, en particulier pour gérer les colonnes nullables dans mon code de base de données (voir le post précédent).

Et bien sûr... Les lambdas!

Va falloir commencer à s'habituer aux listes de captures, et faire gaffe au passage par valeur / référence. Raison de plus pour commencer le plus tôt possible, et en coller partout. 'tention les yeux! Notons également des améliorations sur les variadic templates, et les chaînes de caractères unicode.

Variadic Templates et pqxx

2011-03-12T17:34:00.003+01:00

Je me suis lancé de nouveau dans l'utilisation des variadic templates pour simplifier (!) les appels à la base de données. La chose est un poil touffue, et compile avec g++4.5. Tout d'abord,un exemple d'utilisation: on créé un type Query avec les types des paramètres d'entrée et de sortie en paramètres template. L'on peut ensuite faire tourner la requête avec execute, lequel prend les paramètres d'entrée fortement typés. Ensuite, un itérateur permet de récupérer les résultats sous forme de std::tuple.


typedef 
  db::Query<db::ParamSet<std::string, std::string>, 
            db::ResultSet<std::string, std::string> >
  QueryT;
QueryT query(dbConn, "select $2::text, $1::text");  
query.execute("abc", "def");

for_each(query.begin(),
         query.end(),
         [](const QueryT::ResultType & result)
         {
           std::cout << std::get<0>(result) << "\t" 
                     << std::get<1>(result) << std::endl;
         });

Et pour ceux que ça intéresse, le code derrière tout ça. Il ne supporte pour l'instant que les chaînes de caractères en entrée, je laisse de côté le long et ennuyeux code pour gérer d'autres types (basé sur les Traits). Le principe est un peu toujours le même: dérouler le variadic template à l'aide de classes récursives partiellement spécialisées. Notez que le ResultSet est instancié, bien que n'ayant pas d'attributs. Lassé de me battre avec le compilo qui ne comprenait pas mes appels de méthodes statiques, j'ai instancié tout ça.


namespace db
{
  template <typename ... Args>
  class ParamSet;
  
  template<>
  class ParamSet<>
  {
  public:
    void prepare(const pqxx::prepare::declaration &)
    {
    }
    
    pqxx::prepare::invocation & execute(pqxx::prepare::invocation & invocation)
    {
      return invocation;
    }
  };
  
  template <typename T, typename ... Args>
  class ParamSet<T, Args...>
  {
  public:
    void prepare(const pqxx::prepare::declaration & declaration)
    {
      m_sub.prepare(declaration("text", pqxx::prepare::treat_string));
    }
    
    pqxx::prepare::invocation & execute(pqxx::prepare::invocation & invocation, 
                                        const T & data, 
                                        Args... others)
    {
      return m_sub.execute(invocation(data), others...);
    }
    
  private:
    ParamSet<Args...> m_sub;
  };
  
  template<typename ... Args>
  class ResultSet;

  template<>
  class ResultSet<>
  {
  public:
    template<size_t N, typename TUPLE>
    void doPopulate(const pqxx::result::tuple::const_iterator &, TUPLE &)
    {
    }    
  };
  
  template<typename T, typename ... Args>
  class ResultSet<T, Args...>
  {
  public:
    typedef std::tuple<T, Args...> TupleT;
    
    void populate(const pqxx::result::tuple & input, TupleT & output)
    {
      doPopulate<0>(input.begin(), output);
    }
    
    template<size_t N, typename TUPLE>
    void doPopulate(const pqxx::result::tuple::const_iterator & it, TUPLE & output)
    {
      std::get<N>(output) = it->as<T>();
      m_sub.doPopulate<N + 1>(it + 1, output);
    }
    
  private:
    ResultSet<Args...> m_sub;
  };
  
  template<typename PARAMSET, typename RESULTSET>
  class Query
  {
  public:
    Query(const std::shared_ptr<pqxx::connection> & dbConn, 
          const std::string & sql):
      m_dbConn(dbConn),
      m_sql(sql)
    {
      m_paramSet.prepare(m_dbConn->prepare(sql, sql));
    }

    template<typename ... Args>
    void execute(Args... args)
    {
      pqxx::work transaction(*m_dbConn, "Transaction");
      pqxx::prepare::invocation invocation = 
        transaction.prepared(m_sql);
      
      pqxx::result result = m_paramSet.execute(invocation, args...).exec();
      m_result.resize(result.size());
      
      auto it = result.begin();
      auto end = result.end();
      auto it_r = m_result.begin();

      for(; it != end; ++it, ++it_r)
      {
        m_resultSet.populate(*it, *it_r);
      }
    }
    
    size_t size() const
    {
      return m_result.size();
    }
    
    typedef typename RESULTSET::TupleT ResultType;
    typedef typename std::vector<typename RESULTSET::TupleT>::const_iterator 
      const_iterator;
    
    const_iterator begin()
    {
      return m_result.begin();
    }

    const_iterator end()
    {
      return m_result.end();
    }
    
  private:
    std::shared_ptr<pqxx::connection> m_dbConn;
    std::string m_sql;
    PARAMSET m_paramSet;
    RESULTSET m_resultSet;
    std::vector<typename RESULTSET::TupleT> m_result;
  };
}

GnuCash 2.4.2 débarque sur Debian Wheezy

2011-03-06T13:28:00.003+01:00

Enfin, les paquets intéressants débarquent dans Debian Testing. Je fais mes comptes depuis plus d'un an déjà (essayez au moins une fois quelques mois pour voir, c'est très intéressant!), j'utilise GnuCash et j'en suis fort satisfait. Peut-être moins joli que Grisbi et KMyMoney, mais il fait le boulot, et c'est le principal.

La fonctionnalité la plus intéressante de cette nouvelle release est la possibilité d'utiliser une base de données au lieu de fichiers XML. Voici donc la marche à suivre pour bouger sur Postgresql.

Tout d'abord, assurez-vous que Postgres est installé, avec un compte qui marche et les permissions qui vont bien

Installez le paquet libdbd-pgsql

Créez la base gnucash avec la commande suivante: createdb gnucash

Démarrez gnucash, et ouvrez votre fichier de compte

Allez dans File -> Save as, et choisissez "postgres" dans la section "data format". La fenêtre change, et vous demande vos identifiants de connexion. Entrez le login (et le mot de passe si vous en avez un), zappez le baratin de Gnome-Keyring (OK à tout (sauf si vous êtes un accro de sa sécurité)), et basta!

Les plus curieux d'entre vous pourront aller jeter un coup d'œil à la base, et admirer les tables accounts, transactions et splits qui contiennent l'essentiel des données intéressantes.

En dehors de faire son geek, passer à un backend sur base de données est pratique par exemple si l'on a déjà des systèmes de sauvegarde tournant sur la base. Et c'est toujours ça de moins à penser lors d'une migration sur une autre machine.

Ais-je rêvé? Pas de boost::mutex::is_locked!

2011-03-04T23:26:00.003+01:00

Je l'aurais pourtant juré (et j'ai eu l'air bête au boulot à cause de ça), mais contrairement à ce que je croyais et malgré ma certitude que je l'avait déjà utilisée, les {boost,std}::mutex n'ont pas de méthode is_locked qui permettrait de savoir si le mutex est acquis ou pas.

Dès que je mentionne cette fonctionnalité, l'on me regarde avec des grands yeux: "Mais pourquoi voudrais-tu faire ça? Si tu en as besoin, c'est que ton design est pourri / que tu ne sais pas utiliser les mutex / que tu est bête" (rayer la mention inutile). Alors, oui, je comprends bien que la plupart des utilisations d'une telle méthode sont des aberrations. Mais voilà mon cas d'utilisation:

Imaginez que vous avez une belle classe, gentiment thread-safe (et Wikipédia peut aller se rhabiller avec son "à fil sécurisé", non mais...), et donc possédant un beau mutex (privé, mutable, un beau mutex, quoi). Les méthodes publiques acquièrent le mutex, et appellent des méthodes privées qui s'attendent donc à ce que le mutex soit déjà pris, ce qui est donc une précondition. Afin que le prochain gus écrivant sa méthode publique dans ma classe ne casse tout, j'aimerais beaucoup pouvoir effectivement vérifier cette précondition, avec par exemple un assert(m_mutex.is_locked()). Si mon gus oublie d'acquérir le verrou, il aura une belle assertion lors de ses tests unitaires (encore faut-il qu'il écrive des tests unitaires, mais c'est un autre débat).

Et la, généralement, mon interlocuteur change d'avis: "Tiens, c'est vrai, ça serait pratique...".

Les solutions
Car elles existent.

Une possibilité est pour chaque méthode privée s'attendant à être protégée de prendre en arguments un lock (et pas un mutex), inutilisé dans le corps de la méthode. C'est une sorte de rappel, l'appelant de la fonction devant obligatoirement créer un objet lock. Bien sûr, l'on peut le contourner en créant un objet lock vide, ou qui acquiert un autre mutex, ou qui appelle unlock avant de passer l'objet, mais bon, il faut vraiment être pervers. Autre iconvénient: c'est assez moche, car ça bave dans l'interface.

Une autre possibilité est d'écrire la méthode is_locked, en tentant d'acquérir à nouveau le verrou avec un try_lock, et en vérifiant le résultat. Ce n'est pas spécialement efficace, mais dans une assertion virée des builds optimisés, ce n'est probablement pas un problème. Inconvénient: cela ne marche que si le mutex est non récursif. Sinon, c'est cassé.

Décevant.

Brain overload

2011-02-18T21:13:00.004+01:00

Entre d'épineux problèmes de design au boulot, et d'épineux problèmes de design sur OpenRailz, on ne peut pas dire que je code beaucoup, à mon grand regret.

C'est que maintenant qu'OpenRailz permet de créer des gares, des rails, des trains, et d'assigner des itinéraires, il est temps de commencer à créer de vraies villes. Pour ce faire, je pense pour l'instant à effectuer un pavage du plan à l'aide de polygones, pour en faire des routes et des zones constructibles. Il serait probablement raisonnablement aisé de créer ainsi une ville complétement procédurale, mais je me heurte cependant aux difficultés d'interface: comment fournir au joueur les outils pour créer ses routes, sans affoler le générateur de ville, et sans causer des mini-trous moches au niveau du pavage?

Postgresql 9.0 chez Debian!

2011-02-12T15:53:00.003+01:00

Bonne surprise lors de mon aptitude update; aptitude dist-upgrade hebdomadaire (j'aime bien être à jour), les paquets Postgres 9.0 viennent d'atterrir dans Testing. Cela m'a permis de découvrir les outils de mise à jour, qui sont plutôt efficaces.

Par coup de bol, le passage du méta-paquet postgresql de 8.4 à 9.0 ne m'a pas proposé de virer 8.4, puisque j'avais postgis qui en dépendait. Si ce n'est pas votre cas et que la mise à jour vous propose de supprimer 8.4, annulez, et forcez le paquet 8.4 en manuel (m dans aptitude). Maintenant, laisser l'installation ajouter 9.0 sur un autre port.

C'est là que tout devient simple: passez root, et tapez:

pg_dropcluster --stop 9.0 main
pg_upgradecluster 8.4 main

Le nouveau cluster créé par l'installeur Debian est oblitéré, un nouveau cluster est créé, et les bases migrées dessus, et les ports inversés. Une fois ce processus terminé, vérifiez vos bases (et peut-être redémarrer certains services, chez moi Ocsigen s'est fait dessus lors du changement), puis, quand vous êtes contents,

pg_dropcluster 8.4 main

Un peu de nettoyage dans aptitude pour virer tout ce qui est 8.4, et basta!

'tention cependant!

Toutes les dépendances ne sont pas encore arrivées: postgis est encore en 8.4, et pgadmin foire méchamment. Quand bien même les paquets qui vont bien devraient débarquer incessamment sous peu, si vous faites quoi que ce soit d'important avec votre base, peut-être est-il plus sage d'attendre un poil.

La vraie brochette d'iguane de Fallout

2011-02-10T20:49:00.001+01:00

J'ai découvert dans les rues de Hong Kong la fameuse brochette d'iguane de Fallout!

Itinéraires

2011-01-23T19:29:00.005+01:00

Le nouveau système d'itinéraires est en grande partie implémentée. Il est maintenant possible de donner une liste d'ordres à son train, et de l'observer allant d'une gare à une autre. Il est également possible d'arrêter et de redémarrer son train en route.

Ce sera évidemment bien plus joli avec des noms de gares plutôt que des numéros.

La GUI se met à jour

2011-01-22T23:54:00.002+01:00

Mon observer (nommé RWData) fonctionne comme prévu. J'en ai profité pour revoir un petit peu les interfaces de propriétés. Pour les trains, donc, nous avons la vitesse courante, qui se met à jour au fur et à mesure, et la boite qui contiendra bientôt l'itinéraire.

Des nouvelles d'Infinity

2011-01-22T14:50:00.003+01:00

Comme mentionné dans un post précédent, je surveille de près le projet Infinity, l'ambitieux projet de MMORPG spatial amateur (ou plutôt semi-pro, comme on le verra dans la suite du post). Hier, son concepteur a publié sa rétrospective pour 2010, et a notamment annoncé un changement majeur sur la conduite du projet: maintenant secondé par un développeur pro, il a monté une entreprise, I-novae studios, et se concentre sur la vente du moteur de jeu.

Ceci a bien entendu causé quelques changements dans ses priorités, et il semble que beaucoup de temps ait été passé sur les bug fix, le port vers d'autres architectures, l'intégration à .NET, et bien évidemment l'effort marketing. Le jeu Infinity en lui-même n'est pas abandonné, mais mis de côté en attendant que la vente du moteur permette au studio de recruter une véritable équipe de développement.

La communauté est très divisée par ces nouvelles. Tout en admettant que la vente du moteur est la chose à faire pour lever des fonds, l'inévitable recul de la date de publication du jeu Infinity est difficilement vécue par ceux qui espéraient que le silence de ces derniers mois débouche sur une béta jouable.

Tous les fans d'Infinity (et j'en suis!) devront donc continuer de prendre leur mal en patience, et d'espérer un rapide succès commercial du moteur. Plus personnellement, j'espère tout de même que nous aurons au moins quelques vidéos à se mettre sous la dent.

20 000 lignes

2011-01-22T14:31:00.002+01:00

Voilà, c'est atteint, le projet fait maintenant très exactement 20032 lignes de code, avec l'ajout hier soir d'une implémentation générique d'un observer (on dit vraiment "patron de conception" pour design pattern???). Je vous en causerai plus avant après nettoyage du code.

Mais, pour en revenir à nos lignes, je pense être plutôt dans une pente descendante: avec l'implémentation de piglet et la simplification annoncée du système d'itinéraires, c'est beaucoup de code qui va jarreter. Les systèmes de contrôle de version étant faits pour ça, j'ai la ferme intention d'oblitérer de vastes quantités de code.

Openrailz v0.2 sur Sourceforge

2011-01-19T23:34:00.005+01:00

À la demande générale, j'ai publié sur Sourceforge la dernière version du code et des ressources d'OpenRailz dans un beau paquet. Pour Windows, malheureusement, il va falloir être un peu plus patients, et attendre que je trouve la motivation de porter le code.

Pour ceux qui veulent tenter la compilation sous Linux, la difficulté va surtout dépendre de la disponibilités des bons paquets pour votre distribution préférée. Le fichier INSTALL explique comment compiler avec une Debian Squeeze, la seule subtilité étant qu'il faudra compiler soit-même wxWidgets 2.9 (pour l'antialiasing). Pour la compilation en elle-même, un bête omake dans le répertoire principal fera l'affaire, mais il sera plus efficace de suivre d'un peu plus près la documentation, et d'utiliser les en-têtes précompilées ainsi que la compilation en parallèle.

Les ressources sont fournies avec le code, et sont dans le répertoire "data". L'exécutable cherchant par défaut les données dans le répertoire courant, le mieux est de se placer dans le répertoire principal, et lancer OpenRailz en tapant ./debug/bin/openrailz.

C'est là que tout se corse: je n'ai pu tester OpenRailz qu'avec ma carte vidéo, une Radeon HD 4870, en utilisant les drivers propriétaires, et j'ai peu de doutes que bien d'autres cartes ne supportent pas les shaders de la manière dont je les ai écrits. C'est vraiment au petit bonheur la chance. Les fichiers de shaders sont dans le répertoire data/shader, et sont lus au runtime, donc vous pouvez tripatouiller un peu pour tenter de résoudre d'éventuels problèmes.

Si, par le plus grand des hasards, OpenRailz se décidait à démarrer proprement, vous pourrez alors vous amuser un petit peu avec les circuits.

La navigation se fait en maintenant le bouton droit pour l'orientation, et le bouton central pour les déplacements

Ajoutez une gare, en sélectionnant l'icône "Build station", et en maintenant le bouton gauche à partir d'un endroit du terrain pour orienter le bâtiment

Ajoutez quelques autres gares (backspace pour effacer la gare courante)

Passez en mode rails avec l'icône "Track layout". Les waypoints des gares apparaissent, en rouge car ils ne peuvent pas être manipulés

Sélectionnez-en un, il devient doré. Puis cliquez et maintenez pour créer un autre waypoint. Une fois le bouton lâché, un rail apparaît si un chemin peut-être calculé. Re-cliquez et glissez pour réorienter un waypoint (manipulable, en vert) existant

Le train courant est situé dans la première gare que vous avez créée. Passez en mode sélection avec l'icône "Selection tool", et cliquez sur une autre gare. S'il existe un chemin, le train va s'y déplacer!

Et maintenant?

2011-01-16T23:22:00.005+01:00

Malgré quelques bugs, cette démo de déplacement des trains est une avancée majeure et valide le modèle d'entités graphiques (le bien nommé piglet), le modèle de rails, et le pathfinder. La pose de rails, malheureusement, reste très ardue, mais ce sous-système est suffisamment générique pour être facilement amélioré plus tard, ce qui le rend non prioritaire.

Je peux donc travailler sur l'amélioration du réalisme (accélérations et décélérations), l'interface (simplifier mon modèle d'itinéraires), et enfin m'attaquer à des améliorations de gameplay. Je pense notamment à enfin intégrer l'aspect passagers, avec des gares qui se remplissent de passagers désireux de voyager. L'aspect financier, avec le coût des gares, des rails et des trains, viendra plus tard.

Mais peut-être avant tout ça faut il d'abord trouver enfin un modèle raisonnable pour les callbacks (fonctions de rappel, me dit Wikipedia (!)) entre le moteur et la GUI. L'approche monolithique consistant à faire dériver chaque élément de la GUI d'une interface qui fait tout (sélections de trains et de gares, changements de vitesse, itinéraires, passagers dans les gares, etc) est trop limitée: non seulement cette interface mammouth couplerait tous les composants, mais cela veut dire que des centaines de fois par seconde, chaque train va envoyer sa nouvelle vitesse, chaque gare va envoyer son nouveau nombre de passagers, et bien d'autres événements vont être générés et envoyés à des boites de dialogue qui vont pour la plupart les ignorer.

Inspiré par une approche que j'ai vue au boulot (chut!), je vais tenter quelque chose de plus découplé: permettre à chaque composant de la GUI de s'enregistrer auprès d'un événement donné, en lui passant une fonction de callback, et gérer l'enregistrement dynamiquement au fur et à mesure des besoins de l'utilisateur. Ansi, l'utilisateur cliquant sur une gare, la boite de propriétés de la gare enregistre un callback directement sur un objet représentant le nombre de passagers. Lorsque ce nombre change, la boite de propriétés en est informée, et affiche la nouvelle valeur. Lorsque la gare est dé-sélectionnée, la boite de propriétés se dés-enregistre. Ainsi, pas d'interface monolithique, pas de couplage entre des événements indépendants, et, je l'espère, moins de code à gérer.

Openrailz tech demo 3 - La vidéo

2011-01-15T21:24:00.003+01:00

Openrailz tech demo 3

Il a fallu franchement se battre avec les formats, mais enfin, la vidéo est là. L'on remarquera que le train à tendance à défier les lois de la physique avec ses demi-tours sur l'aile et ses démarrages et freinages au quart de tour, mais l'on a bien les fonctionnalités de base.

I've got the power!

2011-01-15T18:28:00.002+01:00

Enfin, j'ai les trains bougeant de gare en gare!

Certes, c'est un petit peu bizarre par moments, les "demi-tours" dans les gares sont un poil irréalistes... Mais enfin, l'on peut contrôler le déplacement des trains à la souris, et voir le pathfinder en marche. Je vous poste une vidéo bientôt.

1000ème commit

2011-01-15T17:36:00.002+01:00

Alors j'allais quand même sortir une jolie capture d'écran pour cette occasion! Voici donc un train en gare. La plus grande partie de la logique est implémentée, il ne reste plus qu'à ajouter quelques contrôles pour pouvoir indiquer au train où aller, et l'on devrait enfin pouvoir commencer à bouger.

Tests unitaires

2011-01-09T23:40:00.003+01:00

Mais comment ai-je pu coder pendant des années sans tests unitaires? Ce truc, c'est LA pratique qui a augmenté mon rendement, m'a permis de mieux dormir la nuit, et m'a sauvé la vie (professionnelle, tout du moins) plus d'une fois.

Il y a quelques années, j'avais eu entre les mains un bouquin sur le développement orienté tests (le TTD, "Test Driven Development"), et j'avais douté leur déclaration qu'une fois touché aux tests unitaires, on ne pouvait plus s'en passer. Eh bien, ils avaient raison. Une fois utilisés correctement, les avantages sont tels qu'il devient évident que l'on ne peut vivre sans.

Cependant, utilisés à mauvais escient, ils peuvent faire plus de mal que de bien. Il y a donc quelques règles à garder à l'esprit quand on se lance à écrire du code.

Les tests unitaires influencent le design. Il est rare qu'un bout de code quelconque, une fois atteint une complexité minimale, puisse être testé tel quel. Lorsque l'on sait que l'on va devoir tester le code, l'on tend à diminuer les effets de bord, à découpler ses routines, à écrire des interfaces afin de pouvoir "moquer" ses objets. Ça tombe bien, ce sont le genre d'habitudes qui améliorent la qualité du code!

Corollaire du point précédent: il est généralement difficile d'ajouter des tests unitaires à un projet existant. Le projet dépend probablement de fichiers de configuration non moqués, force les logs vers un fichier, cause à la base de données, n'est pas séparé par bibliothèques indépendantes, dépend d'une GUI, dépend de l'horloge, écrit ses résultats dans un fichier Excel, etc. Demander tout à coup aux développeurs de "tester toute la codebase mais sans y toucher" est voué à l'échec. Pour approcher un gros projet non testé, il va falloir doucement, au fur et à mesure des nouvelles fonctionnalités ou des corrections de dysfonctionnements, tenter d'abstraire et de découpler pour pouvoir tester le changement. Au fur et à mesure que le code évolue, le nombre de tests augmente, et la qualité du produit avec.

Il existe un point où la loi des rendements décroissants entre en ligne. À moins de coder pour la NASA ou autre cas où la qualité doit être absolue, l'abus de tests unitaires rend le code plus difficile à changer (car il risque de casser une batterie de tests). Le développeur peu scrupuleux (et, croyez le ou non, il y en a!), plutôt que de plonger dans les abîmes de la perplexité, se laisse aller à sa paresse naturelle et désactive les tests urticants. Avant peu, les 3/4 des tests ont été éliminés, et ne testent plus rien du tout (point bonus aux développeurs qui désactivent les tests en commentant l'intérieur de chaque routine, afin que leur forfait n'apparaisse pas dans les statistiques de chaque build).

À contrario, l'utilité des tests augmente exponentiellement avec leur nombre. Quelques tests sur les fonctionnalités de base ne vont probablement jamais casser, et quand bien même un bug se serait glissé dans le code, il aurait été rapidement trouvé. Tandis qu'une batterie de tests sur les fonctionnalités centrales mais plus complexes vont trouver beaucoup plus de régressions. C'est pour cela qu'il peut être difficile de convaincre certains développeurs: n'ayant rien vu venir après avoir coder leur petite dizaine de tests, ils n'en voient pas l'intérêt. Il faut persévérer!

Le test, c'est comme le chocolat: un incomparable sentiment de plénitude lorsque la dose est bonne.

En voiture Simone

2011-01-05T22:03:00.004+01:00

Je ne peux plus reculer, il n'y a plus d'échappatoire possible: la prochaine étape est vraiment de faire bouger les trains entre les gares. Pas mal de plomberie, et quelques soucis à résoudre (par exemple, je ne suis toujours pas sûr de la manière de faire faire demi-tour à mes trains...), avec je l'espère un résultat enfin visible bientôt!

Bonne année 2011!

2011-01-01T17:32:00.001+01:00

En plus, cette année est un nombre premier, que demander de plus.

Bisous à toutes et à tous!

Bug!

2010-12-20T14:08:00.003+01:00

Les rails sont de retour, mais j'ai du rater une étape:

Voyage mouvementé en perspective?

Contrôle

2010-12-20T00:17:00.003+01:00

Avec la réorganisation du système d'entités graphiques, construire sa voie ferrée devient plus facile (ou moins frustrant, c'est selon). Voici donc mon petit message de Noël en traverses de chemin de fer:

C++0x - Moins de Boost, plus de Standard

2010-12-16T22:24:00.004+01:00

Je me suis livré à un petit nettoyage de mes en-têtes précompilées, en enlevant les en-têtes Boost pour lesquelles j'avais un remplacement en C++0x.

Peu de gain, au final, puisque j'économise environ 12Mo sur des précompilations faisant entre 120 et 300Mo, mais c'est toujours ça de pris, sans compter un code plus cohérent. Voici les remplacements:

<boost/shared_ptr.hpp> est remplacé par <memory> et son std::shared_ptr

<boost/scoped_ptr.hpp> et <boost/scoped_array.hpp> sont remplacés par l'excellent std::unique_ptr

<boost/static_assert.hpp> est remplacé par static_assert

<boost/optional.hpp> vire à cause des soucis d'aliasing

<boost/enable_shared_from_this.hpp> est fourni par std::shared_from_this

<boost/thread.hpp> est remplacé par <thread>. Attention cependant, pas encore de groupes de threads dans le standard!

<boost/non_copyable.hpp> est remplacé par les suppressions de méthodes (mot-clé delete)

Bibliothèque piglet

2010-12-11T22:22:00.002+01:00

La bibliothèque piglet pour "Platform Independent Graphical Layer Entity Tools" (désolé, pas pu m'empêcher...) sépare enfin le système d'entités, lequel reçoit un lifting à la mesure de son importance. J'ai des pages couvertes de diagrammes de classes, mais l'idée est d'avoir plusieurs types d'entités, contenant chacun un objet graphique abstrait. L'implémentation OSG s'effectue en implémentant l'interface d'objet graphique, et la modification d'objets s'opère via un visiteur (après toutes ces années, j'ai enfin compris qu'un visiteur n'était qu'un double dispatch un peu bidouillé, mieux vaut tard que jamais...).

Dans l'immédiat, ça ne va pas donner beaucoup de différences à l'écran (et ça commence à faire un moment, me hurlera ma horde de fans déchaînés, qui n'aura pas tort), mais cela permettra enfin, je l'espère, d'implémenter de manière à peu près correcte des objets qui s'animent en temps réel, notamment les voies lors de l'ajustement des waypoints.

C'est reculer pour mieux sauter, et c'est probablement la meilleure manière d'arriver quelque part. Le système d'entités a démarré très simplement, et a fait un boulot admirable jusqu'ici. Les besoins autour de l'affichage des objets graphiques sont maintenant plus clairs, et surtout j'ai une implémentation qui marche. C'est donc maintenant, ni trop tôt et ni trop tard, qu'est le moment idéal pour retravailler le module en profondeur.

Sinon, et sur un tout autre sujet, je pense enfin pouvoir me débarrasser des derniers boost::shared_ptr du code et les remplacer par des std::shared_ptr, avec l'espoir, entre autres, de virer quelques fichiers d'en têtes de ma pré-compilation pour retarder du même coup le moment où il va me falloir investir dans quelques barrettes de RAM.

C++0x - Chronomètres

2010-12-07T23:17:00.003+01:00

Enfin, et c'est pas trop tôt, une interface C++ pour mesurer le temps. Celle-ci vient de plus avec d'intéressantes fonctionnalités. Mais voyons d'abord un petit programme d'exemple:


#include <chrono>
#include <iostream>

int main()
{
  auto t1 = std::chrono::system_clock::now();
  usleep(100000);
  auto t2 = std::chrono::system_clock::now();

  std::cout << (t2 - t1).count() << std::endl;
  
  return 0;
}

Tout bête! Remarquez l'utilisation de auto pour ne pas avoir à m'ennuyer à définir le complexe type retourné par la méthode statique. Cependant, et c'est là que je trouve que le standard fait très fort, les types fournis permettent de s'affranchir totalement des problèmes d'unités souvent rencontrés dans ces cas là: quelle est la précision fournie par la bibliothèque? Et quelle est la précision voulue par l'utilisateur? C'est là que le type duration (ici implicite) de (t2 - t1) donne toute sa mesure. Regardons plutôt:


#include <chrono>
#include <iostream>

int main()
{
  auto t1 = std::chrono::system_clock::now();
  usleep(100000);
  auto t2 = std::chrono::system_clock::now();
  
  std::chrono::nanoseconds n = (t2 - t1);
  std::cout << n.count() << std::endl;

  std::chrono::microseconds u = (t2 - t1);
  std::cout << u.count() << std::endl;

  std::chrono::duration<double> d = (t2 - t1);
  std::cout << d.count() << std::endl;

  return 0;
}

Là où ça devient magique, c'est que la valeur est automatiquement convertie dans l'unité demandée. Le programme affiche:


100059000
100059
0.100059

Ces types std::chrono::nanoseconds et std::chrono::microseconds sont des typedef sur le type duration, lequel prend comme paramètres templates le type de base, et un ratio (avec un défaut de 1, pour les secondes).

Et, cerise sur le gâteau, g++ refusera même de compiler une conversion non exacte. La ligne

std::chrono::seconds s = (t2 - t1);

renvoie le message d'erreur suivant:

error: static assertion failed: "the resulting duration is not exactly representable"

En effet, le typedef std::seconds prenant en type de base un entier, la conversion perd en précision. Pour que cela marche, il faut utiliser un double, comme dans l'exemple précédent.

Qui a dit que le C++ n'était pas intuitif? :)

C++0x - std::atomic

2010-12-06T23:40:00.004+01:00

Les variables atomiques dans c++0x fournissent (enfin!) une manière standard pour protéger les types de base, avec un support automatique des instructions atomiques quand elles sont disponibles. Voyons le programme suivant avec g++4.4.


#include <thread>
#include <iostream>

void increment(int & counter)
{
  for(size_t i = 0; i < 10000; i++)
  {
    counter++;
  }
}

void decrement(int & counter)
{
  for(size_t i = 0; i < 10000; i++)
  {
    counter--;
  }
}

int main()
{
  int counter;

  std::thread t1(&increment, std::ref(counter));
  std::thread t2(&decrement, std::ref(counter));
  
  t1.join();
  t2.join();

  std::cout << counter << std::endl;
  
  return 0;
}

C'est prévisible, le programme va afficher des nombres totalement farfelus en sortie, car counter n'est pas protégé.

Maintenant, protégeons counter:


#include <cstdatomic>
#include <thread>
#include <iostream>

void increment(std::atomic<int> & counter)
{
  for(size_t i = 0; i < 10000; i++)
  {
    counter++;
  }
}

void decrement(std::atomic<int> & counter)
{
  for(size_t i = 0; i < 10000; i++)
  {
    counter--;
  }
}

int main()
{
  std::atomic<int> counter;

  std::thread t1(&increment, std::ref(counter));
  std::thread t2(&decrement, std::ref(counter));
  
  t1.join();
  t2.join();

  std::cout << counter << std::endl;
  
  return 0;
}

Magie de la technologie moderne, le programme affiche systématiquement un beau 0 tout rond. Un appel de la méthode is_lock_free() sur counter (atomic_is_lock_free() sur gcc 4.5, plus avancé au niveau des standards) vous dira si votre architecture supporte les instructions atomiques.

Voilà, c'est à peu près tout! A noter cependant que l'en-tête atomic a fait son arrivée dans gcc 4.5. Avec cette version, le programme d'exemple (de mémoire), serait (et avec les lambdas, s'il vous plait!):


#include <atomic>
#include <thread>
#include <iostream>

int main()
{
  std::atomic<int> counter;

  std::thread t1([&counter]()
    {for(size_t i = 0; i < 10000; i++) counter++;});
  std::thread t2([&counter]()
    {for(size_t i = 0; i < 10000; i++) counter--;});
  
  t1.join();
  t2.join();

  std::cout << counter << std::endl;
  
  return 0;
}

C'est mieux

2010-12-01T00:18:00.002+01:00

Les UserObject et les callbacks semblent donner un design un peu plus raisonnable. L'envers de la médaille, c'est que je suis revenu d'un bon en arrière, et je me retrouve à ré-implémenter la création des waypoints (va falloir que je trouve bon un nom en français).

Rendez-vous dans quelques semaines pour redécouvrir Openrailz pareil qu'aujourd'hui :)

C++0x - shared_ptr, bind, et for_each

2010-11-27T22:57:00.003+01:00

Pour ceux qui utilisaient déjà Boost, rien de fondamentalement nouveau sous le soleil: C++0x fournit enfin en standard une implémentation de pointeur partagé, ainsi que la fonction de bind qui va bien. Le vieux code Boost peut être mis à jour simplement en remplaçant vos boost:: par des std::, hormis cependant une petite subtilité: les paramètres tels _1, _2, ne sont pas dans le namespace global comme avec boost, mais dans le namespace std::placeholders. L'on pourra soit faire un using namespace std::placeholders;, soit, pour éviter les conflits si l'on inclut également Boost, créer un alias afin de réduire la verbosité du code.


#include <iostream>
#include <algorithm>
#include <memory>
#include <vector>
#include <string>

namespace p = std::placeholders;

class Miaou
{
public:
  Miaou(const std::string & v):
    m_v(v)
  {
  }
  
  void print()
  {
    std::cout << m_v << std::endl;
  }

private:
  std::string m_v;
};

int main()
{
  std::vector<std::shared_ptr<Miaou> > v = 
    {std::shared_ptr<Miaou>(new Miaou("a")), 
     std::shared_ptr<Miaou>(new Miaou("b")), 
     std::shared_ptr<Miaou>(new Miaou("c"))};
  
  std::for_each(v.begin(),
                v.end(),
                std::bind(&Miaou::print, p::_1));
  
  return 0;
}

Avec ces constructions additionnelles de ce côté, et les lambdas de l'autre, ce sont tous les algorithmes qui deviennent bien plus utiles. Je rêve de pouvoir enfin donner à std::accumulate la place qui lui revient!

Ça n'aura pas duré longtemps...

2010-11-24T23:42:00.002+01:00

mais mon design est pourri. Je vous rappelle l'idée: faire dériver chaque objet (station, section de rail, etc) à la fois d'un objet logique et d'un objet graphique. Le problème, il est que les objets sont inter-dépendants: la création d'une station force la création de sections de rails associés. Donc, quand l'objet logique station est créé, comment fait-il pour créer les objets complets (logique + graphique) pour la section? L'on n'est limité à passer de complexes factories un peu partout. C'est moche, c'est compliqué, et c'est intestable. Bref, à jeter.

Je suis vraiment au carrefour de l'architecture du truc, si je le fais bien, ça ira tout seul, sinon, je risque fort de me lasser à force de me battre avec le code.

C'est pas grave, j'ai des tas d'idées. Dériver de l'objet logique était bien pour la gestion des objets, de leur construction et de leur destruction. Je garde donc l'idée que l'objet logique doit pouvoir posséder l'objet graphique, mais j'essaie de découpler.

Chaque objet logique possède donc un "UserObject", qui dérive d'une interface. En plus de cela, la classe World est munie d'un dispatcheur, qui permet au système graphique de détecter toutes le créations et destructions d'objets logiques. À la création d'un objet logique, le système graphique peut ainsi ajouter un "UserObject" graphique. A la destruction, l'objet graphique s'en va en même temps que l'objet logique.

Le concept de user objets est très courant, comme par exemple dans wxWidgets ou dans Open Scene Graph. J'ai donc bon espoir que l'idée colle également à ma logique.

Boost asio - Queues de messages - Un exemple complet

2010-11-21T20:13:00.003+01:00

Voilà un exemple complet avec un service unique, et des queues de messages parallélisables (pour Prime) et séquentielles (pour Logger). Dans l'objet Logger, plutôt que de maintenir une référence sur le service, on construit un objet strand, lequel garantit que tous les appels passés par lui seront séquentiels.

Notez la création et la destruction de l'objet m_work. Lorsqu'il est détruit, il assure que les appels à io_service::run vont retourner une fois que tous les messages auront été traités, ce qui permet de terminer l'application une fois que toutes les requêtes auront été complétées. Afin également d'éviter la destruction prématurée des objets Logger et Prime, les appels à boost::bind prennent un shared_from_this qui va garder une référence sur l'objet au sein du message.

Pour compiler sous Unix:

g++ main.cpp -o main -lboost_system-mt -lboost_thread-mt


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace boost::assign;

class Service : public boost::noncopyable
{
public:
  Service(int nbThreads):
    m_work(new boost::asio::io_service::work(m_service))
  {
    for(int i = 0; i < nbThreads; ++i)
    {
      m_threadGroup.create_thread
        (boost::bind(&boost::asio::io_service::run, 
                     boost::ref(m_service)));
    }
  }
  
  ~Service()
  {
    m_work.reset();
    m_threadGroup.join_all();
  }

  boost::asio::io_service & getService()
  {
    return m_service;
  }

private:
  boost::asio::io_service m_service;
  boost::scoped_ptr m_work;
  boost::thread_group m_threadGroup;
};

class Logger : public boost::noncopyable,
               public boost::enable_shared_from_this
{
public:
  Logger(boost::asio::io_service & service):
    m_strand(service)
  {
  }
  
  void log(const std::string & message)
  {
    m_strand.dispatch(boost::bind(&Logger::doLog, 
                                  shared_from_this(), 
                                  message));
  }
  
private:
  void doLog(const std::string & message)
  {
    std::cout << message << std::endl;
  }
  
  boost::asio::io_service::strand m_strand;
};

class Prime : public boost::noncopyable,
              public boost::enable_shared_from_this
{
public:
  Prime(boost::asio::io_service & service,
        const boost::shared_ptr & logger):
    m_service(service),
    m_logger(logger)
  {
  }
  
  void nthPrime(size_t n)
  {
    m_service.dispatch(boost::bind(&Prime::doNthPrime, 
                                   shared_from_this(), 
                                   n));
  }
  
private:
  void doNthPrime(size_t n)
  {
    std::vector primes(1, 2);
    size_t current = 2;
    while(primes.size() < n)
    {
      current++;
      size_t i;
      for(i = 0; i < primes.size(); ++i)
      {
        if(current % primes.at(i) == 0)
          break;
      }
      if(i >= primes.size())
      {
        primes.push_back(current);
      }
    }
    std::ostringstream str;
    str << n << "th prime is " << primes.at(n - 1);
    m_logger->log(str.str());
  }
  
  boost::asio::io_service & m_service;
  boost::shared_ptr m_logger;
};

int main()
{
  boost::shared_ptr service
    (new Service(3));
  boost::shared_ptr logger
    (new Logger(service->getService()));
  boost::shared_ptr prime
    (new Prime(service->getService(), logger));
  
  std::vector values;
  values += 
    20000, 10000, 5000, 7500, 15000,
    17000, 14000, 11000, 21000, 11000;
  
  std::for_each(values.begin(),
                values.end(),
                boost::bind(&Prime::nthPrime, prime, _1));
}

Asio fournit bien plus qu'une couche d'abstraction au dessus des sockets réseau. Il serait dommage de cantonner cette bibliothèque à la communication client serveur, alors qu'elle fournit un paradigme puissant pour construire des applications événementielles sans avoir à s'arracher les cheveux sur les problèmes bas-niveau.

Boost asio - Queues de messages

2010-11-21T15:12:00.005+01:00

La bibliothèque Asio, intégrée à Boost, permet de gérer des événements de manière asynchrone. Principalement utilisée pour le réseau, elle peut également être très utile pour résoudre des problèmes de programmation concurrente. Un exemple très simple: la gestion de queues de messages.

Prenons donc une classe qui affiche des messages sur la console. Une manière de gérer l'accès concurrent est de mettre un bon vieux mutex autour de l'appel à std::cout, forçant chaque thread à attendre sur des opérations d'entrées sorties potentiellement longues. Une autre manière, souvent plus efficace, est d'ajouter le message sur une queue, laquelle est lue par un thread unique chargé de l'affichage. Comment faire de même avec Asio?


class Logger
{
public:
  Logger():
    m_work(m_service),
    m_thread(boost::bind(&boost::asio::io_service::run, 
                         boost::ref(m_service)))
  {
  }
  
  ~Logger()
  {
    m_service.stop();
    m_thread.join();
  }
  
  void log(const std::string & message)
  {
    m_service.dispatch(boost::bind(&Logger::doLog, this, message));
  }
  
private:
  void doLog(const std::string & message)
  {
    std::cout << message << std::endl;
  }
  
  boost::asio::io_service m_service;
  boost::asio::io_service::work m_work;
  boost::thread m_thread;
};

Cette classe s'utilise simplement en instanciant l'objet Logger, puis en appelant la méthode log. L'appel à log est thread safe, et peut donc être appelé par n'importe quel thread de l'application. L'affichage, lui, ne tourne que depuis le thread interne de la classe. Pas de mutex, pas de conditions, tout est planqué dans Asio.

Remarquez l'objet work, qui indique à m_service qu'il y a toujours quelque chose à faire, pour éviter que m_service.run() ne retourne prématurément.

Et pour l'opération inverse, c'est à dire l'utilisation d'une queue de messages pour faire tourner des calculs potentiellement lourds simultanément? C'est à peine plus complexe, comme par exemple dans cette classe qui calcule le n-ième nombre premier.


class Prime
{
public:
  Prime():
    m_work(m_service)
  {
    m_threadGroup.create_thread(boost::bind(&boost::asio::io_service::run, 
                                            boost::ref(m_service)));
    m_threadGroup.create_thread(boost::bind(&boost::asio::io_service::run, 
                                            boost::ref(m_service)));
    m_threadGroup.create_thread(boost::bind(&boost::asio::io_service::run, 
                                            boost::ref(m_service)));
    m_threadGroup.create_thread(boost::bind(&boost::asio::io_service::run, 
                                            boost::ref(m_service)));
  }

  ~Prime()
  {
    m_service.stop();
    m_threadGroup.join_all();
  }
 
  void nthPrime(size_t n)
  {
    m_service.dispatch(boost::bind(&Prime::doNthPrime, this, n));
  }
  
private:
  void doNthPrime(size_t n)
  {
    std::vector primes(1, 2);
    size_t current = 2;
    while(primes.size() < n)
    {
      current++;
      size_t i;
      for(i = 0; i < primes.size(); ++i)
      {
        if(current % primes.at(i) == 0)
          break;
      }
      if(i >= primes.size())
      {
        primes.push_back(current);
      }
    }
    std::cout << primes.at(n - 1);
  }
  
  boost::asio::io_service m_service;
  boost::asio::io_service::work m_work;
  boost::thread_group m_threadGroup;
};

Faisant tourner 4 threads à partir du bon vieux thread pool de chez Boost, cette classe va empiler les requêtes et n'en faire tourner que 4 maximum à la fois.

L'étape suivant serait d'appeler Logger depuis Prime, afin de n'afficher le résultat que depuis un seul thread. L'on peut ainsi construire un programme à partir de briques de base qui gèrent elles-mêmes l'accès concurrent, sans avoir à se (trop) se préoccuper de l'accès concurrent ou d'interbloquages.

Cette approche est cependant limitée par l'explosion du nombre de threads dans l'application, chaque brique gérant un certain nombre de threads indépendants. Lorsque la charge de travail est lourde, l'on risque de se retrouver avec beaucoup plus de threads tentant de s'exécuter que de processeurs.

L'on peut alors modifier quelque peu son approche, pour partager un même service asio au sein du programme, et laisser à la bibliothèque le soin d'ordonnancer les tâches.

S'assurer que l'accès à certaines ressources demeure séquentiel, comme pour notre Logger, peut se faire grâce aux strands. Démonstration dans un prochain post.

Pas assez d'objet?

2010-11-19T00:35:00.002+01:00

Je ne suis pas satisfait de mon design autour des concepts principaux d'OpenRailz que sont les sections de rails et les stations. Peut-être ais-je péché par excès d'anti-POO primaire, et, cherchant un style plus fonctionnel, me retrouve avec quantités de collections d'objets. Je cherche donc à centraliser un petit peu, pour une fois, en utilisant le bon vieil héritage multiple (que je pourrais transformer en interface à un moment ou à un autre, c'est à voir).

Le résultat, c'est que plutôt que de séparer ma station de l'entité la représentant, je créé une classe StationEntity qui dérive à la fois de Station et de OsgEntity.

Nous verrons ce que cela donne.

Fallout 3 - New Vegas - C'est plié

2010-11-14T17:02:00.004+01:00

Après 50 heures de jeu, me voilà déjà à la fin... Ou plutôt, une des fins. Fallout 3 New Vegas a tenu toutes les promesses, les quêtes étaient intéressantes, interactives et profondes, les personnages attachants, et l'histoire tout à fait prenante.

J'hésite maintenant entre reprendre une sauvegarde un peu en arrière et essayer d'autres fins, ou tout redémarrer du début avec une ligne très différente. Mais là, tout de suite, je vais plutôt me remettre à coder. Faut que je me remette de mon overdose!