Bonjour,

Toute personne qui programme finit un jour ou l’autre par se demander où héberger son code source en vue de lui donner une bonne visibilité. Les solutions traditionnelles, comme SourceForge, sont aujourd’hui concurrencées par de nombreuses autres plateformes. Je vous propose de vous présenter aujourd’hui GitHub.

GitHub est un service web d’hébergement et de gestion de développement de logiciels qui repose sur l’utilisation du programme Git. C’est un système rapide, léger et simple d’utilisation qui présente au moins deux avantages sur ses concurrents :

• Il est très facile de faire un fork d’un projet.
• Les fichiers peuvent être édités directement sur le site.

Comme la plupart de ses concurrents, GitHub permet aussi d’ajouter un wiki, de la documentation, une mailing list, un bug tracker, et bien d’autres choses.

Pour ceux qui tiennent à jour un blog (plus ou moins régulièrement d’ailleurs), la possibilité d’avoir accès à une pastebin qui se comporte comme un dépôt Git indépendant est une chose vraiment appréciable.

J’aurai l’occasion de vous en reparler prochainement à l’occasion de la présentation, sur ce blog, d’une petite bibliothèque dédiée aux listes doublement chaînées circulaires immutables (pour ceux qui se souviennent, j’ai déjà eu l’occasion de présenter la version mutable sur ce blog).

Le logiciel libre Hugin est une interface graphique pour la suite logicielle Panorama Tools. Il permet de réaliser des panoramas de qualité à partir d’une série d’images chevauchantes. Les algorithmes mis en œuvre permettent de corriger les variations d’exposition, fréquentes lorsqu’on utilise un réflex numérique en mode automatique, ainsi que de multiples paramètres liés à l’objectif et/ou à la manière dont le photographe a réalisé ses clichés. Ce tutoriel offre un aperçu des possibilités du logiciel ne vise donc pas à l’exhaustivité. Les lecteurs qui souhaitent approfondir leur connaissance de cet outil pourront consulter avec profit la documentation officielle.

Point de départ : plusieurs images d’un même paysage

Lors d’une randonnée, il n’est pas rare de trouver des paysages à couper le souffle, notamment des cirques et des chaînes de montagnes qu’il n’est pas possible de capturer en une seule fois, même avec un très grand angle. Dans ce cas, on peut prendre plusieurs clichés et les assembler pour former un diaporama. Dans ce tutoriel, nous allons partir des trois images suivantes :

Gauche	Centre	Droite

Nous allons charger ces trois images dans Hugin et lui demander de les assembler pour former un panorama. Nous pourrions aussi le faire manuellement ou à l’aide de logiciels spécifiques (tel que Canon Photo Stitch). Cependant, nous allons voir que le rendu obtenu avec Hugin est presque toujours optimal, ce qui n’est pas le cas avec d’autres logiciels. On commence donc par lancer le logiciel, qui se présente sous cette forme :

Cette fenêtre comporte un onglet Assistant, ouvert dès le démarrage de l’application, qui propose une procédure simplifiée de création de panoramas, en trois étapes : (1) chargement des images, (2) alignement et (3) assemblage des panneaux pour former le diaporama. L’autre méthode permet de régler plus de paramètres mais nécessite de plus amples explications. Elle fait appel à tous les autres onglets de la fenêtre : Images, Appareil photo et objectifs, Recadrer, Points de contrôle, Optimisations, Exposition et Assemblage. C’est cette seconde méthode que nous allons présenter ici.

Sélection des images à assembler

Commençons donc par nous rendre dans l’onglet Images. On ajoute ensuite la série d’images qui compose le panorama (« Ajouter des images individuelles »), ce qui nous donne quelque chose comme ceci :

Création de points de contrôle dans les zones de recouvrement

On se dirige ensuite vers le bouton « Créer des points de contrôle ». Ceci indique à Hugin que nous voulons qu’il chercher des zones de recouvrement entre les différentes images. Dans ces zones, des points sont utilisés comme repères pour l’alignement. Nous verrons ensuite qu’il est possible d’optimiser les points choisis (mais Hugin s’en sort généralement très bien, même avec la configuration de base). Pour information, j’ai coutume de demander 100 points de contrôle, mais on peut demander moins et c’est généralement suffisant.

On peut contrôler les points qui ont été trouvés dans l’onglet Points de contrôle :

Si le nombre de points de contrôle est insuffisant, il est possible d’en ajouter de nouveaux et/ou d’en définir manuellement. On peut également utiliser l’outil Céleste pour supprimer les points de contrôle situés dans le ciel (parfois moins fiables).

Optimisations diverses

On peut ensuite effectuer des optimisations sur les distorsions (distorsion en barillet, mouvements de tangage ou de roulis lors des prises de vues, etc.) et l’exposition des images (gamme dynamique faible ou étendue, balance des blancs fixe ou variable d’un cliché à l’autre, etc.) :

Assemblage final et création du panorama

Il ne reste plus alors qu’à réaliser l’assemblage proprement dit, et obtenir ainsi un panorama. Là encore, de nombreux réglages sont possibles, notamment le type de projection utilisé (cylindrique, rectilinéaire, Mercator, etc.), le recadrage automatique ou encore la manière dont Hugin doit construire le panorama final (fusion de l’exposition, fusion de type HDR, etc.)

L’image ci-dessus vous montre qu’il est possible de contrôler le type d’image en sortie (image JPEG, TIFF, etc.) et la nature des outils utilisés pour l’assemblage.

Et voici la récompense :

Vous trouverez ici l’image en taille originale.

Pour finir, voici quelques autres exemples de panoramas créés avec Hugin :

• Un autre panorama de neige pris au même endroit
• Un panorama plus ambitieux constitué de 10 images

Cordialement,
Cacophrène

Yesterday, a pretty young woman told me that writing about programming languages really need to be done in English. Now that I know she reads my humble texts, I have to follow its advice. So now… let’s be a bit more serious.
As you probably know, polymorphic variants are often seen as a light and elegant alternative to OCaml constructors. Yet these two concepts are not completely interchangeable : that is why they coexist in OCaml. Here I describe a possible use of polymorphic variants to refine some function signatures from the OCaml standard library by adding type constraints.

Too simple to be safe ?

To make things clearer, let’s consider the example of floating-point numbers (or simply floats) and their corresponding OCaml type. The core module defines many functions which deal with floats, such as square root (sqrt) and exponential (exp). Both have the same signature :

val sqrt : float -> float
val exp : float -> float

This short signature means that the function receives a floating-point number as argument and returns a floating-point number as result. Now try to remember your math lessons. You should probably know that exponential is defined from R to R+, whereas square root is defined from R+ to R+. In other words, there is no way to compute the square root of strictly negative numbers. As a consequence, we expect the sqrt function to raise an exception when the input value is negative. Actually, instead of raising an exception, the IEEE 754 standard introduces a special float value called NaN (not a number) to handle these cases.

# let x = -3.5;;
val x : float = -3.5
# exp x;;
- : float = 0.0301973834223185
# sqrt x;;
- : float = nan

Due to its special status, NaN is only able to spread again and again through successive computations, so that the final value is always NaN. This is a convenient solution… but we can also try to get more explicit signatures. This can be achieved with polymorphic variants (this is false suspense before true headache).

The strange world of polymorphic variants

Polymorphic variants are quite subtle stuff that I cannot explain in one short sentence. Therefore, people who are not familiar with this concept should refer to the OCaml manual (politeness for RTFM). For the others, the only thing I really expect you to know by heart is that [> `Foo] means « at least `Foo, but maybe something else », whereas [< `Foo | `Bar] means « nothing more than `Foo and `Bar ». This is the key of what we are going to do in this short article. So first, let’s define a new type :

type ‘a t = ‘a * float

The polymorphic parameter will be used to add some flags to the float value. These flags are polymorphic variants. Of course, the whole definition will be left abstract in the module signature. Then we need two functions for building positive and negative numbers floats, and a specialized value for zero :

let zero = (‘Nil, 0.0)
let positive flo = if flo > 0. then (‘Pos, flo) else invalid_arg "positive"
let negative flo = if flo < 0. then (‘Neg, flo) else invalid_arg "negative"

These functions have quite clear signatures :

val zero : [> ‘Nil] t
val positive : float -> [> ‘Pos] t
val negative : float -> [> ‘Neg] t

Note the use of > in the above signatures and try to understand its aim. Then let’s write another function to convert a given t value to floating-point number :

let to_float = snd

And that’s all ! We are now able to make things a bit safer. One example :

let sqrt = function ‘Nil, _ -> zero | ‘Pos, x -> (‘Pos, sqrt x)

This new sqrt function has a fairly explicit (maybe also cryptic) signature :

val sqrt : [< ‘Nil | ‘Pos] t -> [> ‘Nil | ‘Pos] t

It just means that sqrt expects a non-negative float (either `Nil or `Pos) and returns a non-negative float. Wonderful ! Now we can write many more float-related functions :

let exp t = (‘Pos, exp (to_float t))
let log (‘Pos, x) =
  let r = log x in
  if r = 0. then zero
  else if r < 0. then (‘Neg, x) else (‘Pos, x)
let abs t =
  let flo = abs_float (to_float t) in
  if flo = 0. then zero else (‘Pos, flo)

and their signatures :

val exp : [< ‘Neg| ‘Nil | ‘Pos] t -> [> ‘Pos] t
val log : [‘Pos] t -> [> ‘Neg| ‘Nil | ‘Pos] t
val abs : ‘a t -> [> ‘Nil | ‘Pos] t

We cannot do unsafe computations by composing functions anymore. For instance, the following code is rejected at compile time :

let sqrt_log x = sqrt (log x)
                      ^^^^^^^
Error: This expression has type
         ([> `Neg | `Nil | `Pos ] as 'a) t = 'a * float
       but an expression was expected of type
         ([< `Nil | `Pos ] as 'b) t = 'b * float
       The second variant type does not allow tag(s) `Neg

The compiler is complaining because log can return negative values, and sqrt cannot handle them. We should thus write something like this :

type nonneg = [`Nil | `Pos]

let sqrt_log x =
  match log x with
  | `Neg, _ -> None
  | #nonneg, _ as y -> Some (sqrt y)

and we get the following signature :

val sqrt_log : [ `Pos ] t -> [> `Nil | `Pos ] t option

That’s all folks !
Cacophrène

J’ai eu l’occasion d’assister ce week-end à trois conférences données dans le cadre des Journées Méditerranéennes du Logiciel Libre (JM2L). Comme il est connu qu’on ne râle jamais mieux qu’en français, cette partie ne sera pas écrite dans la langue de Shakespeare.

• Création d’un logiciel libre, Thibault Duponchelle
• Robots mobiles et autonomes contrôlés avec Pharo, Noury Bouraqadi
• Autour de SSL/TSL, Philippe Lhardy

Je tiens d’emblée à dire que l’avis formulé ici n’engage que moi. Le ton adopté est volontairement critique, sans doute un peu exagérateur, mais c’est à dessein : on apprend en tombant.

Création d’un logiciel libre

Cette première conférence avait pour objectif de présenter dans leurs grandes lignes les recettes qui permettent de concevoir efficacement un logiciel libre. Le conférencier a donc rappelé les conseils donnés aux programmeurs (documentez-vous, posez des questions, entraînez-vous, etc.) et mis l’accent sur le grand nombre d’outils accessibles pour faciliter le travail (débogueurs, générateurs de documentation, logiciels de gestion de versions, forges, etc.). Je regrette que la seule application évoquée lors de la conférence (un émulateur de calculatrices) ait un point de départ juridiquement contestable et ne présente qu’un intérêt très limité. Franchement, si j’accepte de payer 200€ une calculatrice aux airs de petit ordinateur, est-ce vraiment pour y installer Tétris ou DragonBall ? S’il y avait un exemple de logiciel libre à ne pas présenter, c’était justement celui-là.

Robots mobiles et autonomes contrôlés avec Pharo

Cette seconde conférence a été donnée par un enseignant-chercheur de l’école des Mines de Douai. Il y était question de robotique et d’un fork du langage Smalltalk appelé Pharo. C’est un langage à objets et à typage dynamique, assez éloigné de ma culture informatique. Les possibilités ont l’air intéressantes, mais la conférence laisse un goût amer : les nombreuses démonstrations (une dizaine) manquaient de vigueur et donnaient l’impression qu’on travaille avec Pharo par ajouts de rustines successives sans jamais penser le programme dans sa globalité. Dommage, le potentiel était là.

Autour de SSL/TSL

Sans doute la conférence que j’ai le plus apprécié. La sécurité informatique est aussi un domaine que je connais peu. Le conférencier a fait preuve de pédagogie avec des exemples variés et des schémas soignés. Au fil des diapos, on se demande quand même ce qu’Alice avait de si important à dire à Bob.

Conclusion

Il serait peut-être intéressant de proposer, pour la session 2011, un atelier d’initiation à la programmation fonctionnelle à travers le langage OCaml. Cela permettrait de sortir des sentiers battus et de montrer que le typage statique fort est aussi capable de produire des outils puissants. Le problème avec les idées, c’est qu’on les lance sans réfléchir, et il n’y a presque jamais personne pour les rattraper avant qu’elles ne se brisent.

Cordialement,
Cacophrène

Si vous avez des enseignants dans votre entourage, vous serez peut-être sollicités (si ce n’est déjà fait) pour créer des questionnaires à choix multiples (QCM). Les QCM constituent un outil commode pour évaluer des élèves ou des étudiants. Ils se présentent sous la forme de questions auxquelles plusieurs réponses possibles sont proposées. En général, une seule de ces réponses est correcte; les autres, appelées distracteurs, visent à éprouver la maîtrise du sujet par les candidats. À ce titre, elles se doivent d’être plausibles.

En règle générale, l’évaluateur souhaite produire deux versions de son questionnaire : une version vierge destinée aux candidats, et une version corrigée, souvent destinée à l’impression sur transparent, pour l’aider dans la correction des copies. Nous allons voir qu’il est possible de satisfaire à toutes ces exigences en utilisant LaTeX sans aucune extension dédiée !

Des paquets

Comme toujours, on commence un document LaTeX par l’écriture de son préambule. Dans le cas qui nous intéresse, nous allons rédiger un questionnaire en français à l’aide de la classe article. Nous avons donc besoin du code suivant :

\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[french]{babel}
\usepackage[T1]{fontenc}
\usepackage{lmodern}

Les cases à cocher seront représentées par des symboles mathématiques, de sorte que nous devons aussi charger les paquets fournis par la société mathématique américaine :

\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}

Nous souhaitons en outre utiliser tout l’espace disponible afin de réduire la longueur de l’énoncé. Nous souhaitons donc écrire nos questions sur plusieurs colonnes (paquet multicol). Nous aurons aussi besoin de personnaliser l’en-tête et le pied de page (paquet fancyhdr)… et vous verrez plus tard que les macros que nous allons écrire nécessitent le paquet ifthen :

\usepackage{ifthen}
\usepackage{multicol}
\usepackage{fancyhdr} 

Des macros

Afin de pouvoir passer facilement du mode « énoncé » au mode « corrigé », nous allons définir une variable booléenne correction et l’initialiser à faux (false) :

\newboolean{correction}
\setboolean{correction}{false}

Nous allons aussi définir un compteur pour les numéros des questions :

\newcounter{QNumber}

Définir une question

Nous allons ensuite écrire une macro \Question qui permet de définir une nouvelle question. Cette macro reçoit deux arguments : le premier, facultatif, indique quel est le caractère à placer en fin de question (le plus souvent ‘:’, mais on peut aussi trouver un point d’interrogation), et le second n’est autre que la question elle-même. Nous écrivons donc :

\newcommand{\Question}[2][:]{
  \stepcounter{QNumber}
  \noindent\textbf{Question \theQNumber} -- #2~#1
}

Ajouter une liste de choix

Nous allons aussi définir un environnement Reponse pour permettre d’entrer les différents choix proposés à la sagacité des candidats :

\newenvironment{Reponse}{
  \begin{list}{$\square$}{\leftmargin=5em}
}{
  \end{list}\vspace{1em}
}

Proposition correcte et distracteurs

Il ne nous reste plus qu’à définir la macro \Vrai (resp. \Faux) pour ajouter une proposition vraie (resp. fausse) :

\newcommand{\Vrai}{
  \item[\ifthenelse{\boolean{correction}}{$\blacksquare$}{$\square$}]}
\newcommand{\Faux}{\item[$\square$]}

Vous remarquerez que le symbole utilisé par la macro \Vrai dépend de l’état de la variable booléenne correction. De cette façon, si correction est égal à true, les réponses justes seront marquées par un carré plein, ce qui révèle la correction du questionnaire.

En-tête et pied de page

On souhaite ajouter en en-tête de la première page des champs permettant au condidat d’indiquer son nom et son prénom :

\chead{\ifthenelse{\thepage=1}{
  \textbf{Nom :}
  \makebox[12em]{\dotfill}
  \hspace{2em}
  \textbf{Prénom :}
  \makebox[12em]{\dotfill}}{}} 

Si les questions continuent au verso, on veut que le recto de la première page se termine par la mention « Tournez la page s’il vous plaît » :

\rfoot{\ifthenelse{\thepage=1}{\textit{(tournez la page s.v.p)}}{}}

Je laisse au lecteur le soin de généraliser ceci à toutes les pages impaires dans le cas d’un questionnaire comportant plus de deux pages pleines.

Compilation du document

Pour compiler votre document et produire un fichier PDF, il vous suffit d’utiliser la commande pdflatex qcm.tex. En changeant la valeur du booléen correction, vous obtenez ainsi un énoncé et un corrigé. Le code source est disponible ici.

Cordialement,
Cacophrène

Après un long moment d’absence et de sérieux doutes sur la pérennité de ce blog, je reviens vous parler de LablGTK. Cette fois-ci, je ne vous présenterai pas un autre module de la bibliothèque. Pour célébrer la renaissance de ce blog, à la suite de mon admission en thèse (dans un domaine très éloigné du sujet de ce blog), je vous propose de parler du mécanisme de callback dans LablGTK.

Nous allons aborder dans ce billet une manière automatisée d’associer des fonctions callback à des widgets. Mais, pour partir sur de bonnes bases, nous allons d’abord rappeler ce qu’est une fonction callback.

Le principe d’une fonction callback

Une fonction callback (je ne me risque pas à proposer de traduction) est une fonction qui est communiquée dans un argument passé à une autre fonction. Dans le cas de GTK, un widget interagit avec l’utilisateur en émettant des événements auxquels des fonctions peuvent être associées. Ces dernières, on l’aura compris, ont pour but de répondre à l’événement émis, et donc in fine à l’utilisateur. Par exemple, le code suivant est typique :

let main_window =
  let window = GWindow.window
    ~title:"LablGTK demo"
    ~position:`CENTER
    ~width:640 ~height:480 () in
  window#connect#destroy ~callback:GMain.quit;
  window 

Ce code crée la fenêtre principale d’une application. On y indique également qu’il faut fermer l’application (GMain.quit) lorsque la fenêtre est détruite (ce qui se traduit par la levée de l’événement destroy). Dans ce cas, la fonction GMain.quit est utilisée comme callback.

Séparation de l’interface et du code

Pour construire une application, on recommande généralement de dissocier les éléments de l’interface et les actions associées. Le code est ainsi mieux structuré et plus facile à maintenir. Par exemple, on peut considérer un module GUI qui contient l’ensemble des widgets de l’interface, et divers modules qui définissent les actions associées (copie, collage, zoom, enregistrement, etc.). Malgré des qualités indéniables, cette approche présente au moins deux inconvénients de taille :

• Chaque fois que l’interface est modifiée (par exemple en ajoutant ou en supprimant un widget), le module qui définit l’action correspondante doit être mis à jour pour ajouter ou supprimer un enregistrement de fonction callback et tenir ainsi compte des modifications réalisées en amont.
• Le module qui définit les actions n’est plus autonome : il dépend du module d’interface de l’application, de sorte que sa réutilisation dans un autre contexte devient plus difficile.

Nous allons présenter ici une solution qui résout ces deux problèmes et permet d’automatiser l’enregistrement des fonctions callback.

Automatisation du mécanisme de callback

Quelques nouveaux types

Pour automatiser le mécanisme d’enregistrement des fonctions callback, nous allons commencer par définir des types qui correspondent à une action particulière, comme l’activation d’un élément ou un clic gauche de souris. Ce sont :

class type clickable = 
  object
    method clicked : callback:(unit -> unit) -> GtkSignal.id
  end

class type activatable = 
  object
    method activate : callback:(unit -> unit) -> GtkSignal.id
  end

Notez que l’on pourrait écrire de très nombreux autres types de ce genre, mais ceux-ci sont les plus fréquents car ils couvrent à la fois les barres d’outils et les menus, c’est-à-dire les éléments les plus susceptibles d’être modifiés dans une interface (on peut aussi voir dans ces définitions, quoique d’assez loin, une influence des typeclass de Haskell). On va ensuite définir un type somme pour réunir le tout :

type item =
  | C of clickable
  | A of activatable

Stockage des couples identifiant/données

Nous allons ensuite définir une table de hachage destinée à stocker des identifiants (type string) et des données associées. Ces données sont constituées d’une liste d’objets (item list) et d’une fonction de callback (de type unit -> unit). Comme nous voulons modifier ces valeurs directement, nous allons les stocker sous forme de références :

val table : (string, action list ref * (unit -> unit) ref) Hashtbl.t

Nous allons maintenant définir une fonction register_any qui, étant donné une fonction f, un identifiant id et un widget wid, ajoute f wid (de type item) à la liste des objets associés à l’identifiant id :

let register_any f id wid =
  let item = f wid in
  try
    let items = fst (Hashtbl.find table id) in
    items := item :: !items
  with Not_found -> Hashtbl.add table id (ref [item], ref ignore)

Remarque : vous avez peut-être remarqué que, si l’identifiant n’existe pas dans la table de hachage, les données ajoutées comportent une fonction callback qui ne fait rien (Pervasives.ignore). Elle pourra bien sûr être modifiée par la suite !

Enregistrement des widgets

Nous pouvons ensuite définir des fonctions spécialisées pour les deux types clickable et activatable définis précédemment :

let register_clickable ~id obj = 
  register_any (fun obj -> C (obj#connect :> clickable)) id obj

let register_activatable ~id obj = 
  register_any (fun obj -> A (obj#connect :> activatable)) id obj

Ces fonctions ont la signature suivante :

val register_clickable : id:string ->  -> unit

val register_activatable : id:string ->  -> unit

En d’autres termes, elles reçoivent en entrée un identifiant de type string et un widget dont la méthode connect est un sur-ensemble de la classe clickable (ou activatable, respectivement).

Enregistrement des fonctions de callback

Il faut ensuite écrire une fonction capable d’enregistrer les fonctions callback. Pour simplifier son utilisation, on souhaite qu’elle renvoie en sortie la fonction reçue en entrée :

let register_callback ~id f =
  try snd (Hashtbl.find table id) := f; f with Not_found -> f

Cette fonction est de type :

val register_callback : id:string -> (unit -> unit) -> unit -> unit

Association des fonctions aux widgets

Il ne reste plus qu’à définir la fonction qui associe les callback au lancement de l’application :

let connect_all () =
  Hashtbl.iter (fun _ ({contents = t}, {contents = f}) ->
    List.iter (function
      | C connect -> ignore (connect#clicked ~callback:f)
      | A connect -> ignore (connect#activate ~callback:f)
    ) t
  ) table

Rappel : en OCaml, les références peuvent être vues comme des valeurs de type record avec un champ unique appelé contents. On peut donc filtrer les références en écrivant {contents = x}, où x désigne le contenu de la référence.

Cette fonction présente une signature très simple :

val connect_all : unit -> unit

Utilisation du module dans le programme

L’utilisation de ce module dans un programme se déroule en trois temps :

• Tout d’abord, les éléments de l’interface sont créés et enregistrés avec les fonctions register_clickable ou register_activatable. À cet effet, un identifiant spécifique est nécessaire… mais celui-ci peut être recyclé avantageusement et servir pour les plugins, voire pour la traduction de l’application en plusieurs langues.
• Ensuite, les fonctions callback sont enregistrées avec register_callback et le même identifiant que précédemment. Les modules qui les contiennent restent indépendants du module d’interface. Accessoirement, les équipes de développeurs qui se parlent peu auront moins de surprises lors de la mise en commun de leur code ;-).
• Enfin, au lancement de l’application, on connecte tous les widgets à leurs fonctions respectives à l’aide d’un unique appel à connect_all. On n’oublie personne !

On peut bien entendu imaginer diverses généralisations plus ou moins complexes de ce procédé, notamment au cas des fonctions callback multiples. On aurait alors une table de hachage de type :

val table : (string, action list ref * (unit -> unit) list ref) Hashtbl.t

et la fonction connect_all deviendrait :

let connect_all () =
  Hashtbl.iter (fun _ ({contents = obj_list}, {contents = fun_list}) ->
    List.iter (fun item ->
      let f = match item with
        | C connect -> (fun f -> ignore (connect#clicked ~callback:f))
        | A connect -> (fun f -> ignore (connect#activate ~callback:f))
      in List.iter f fun_list
    ) obj_list
  ) table

Remarque : il commence à y avoir beaucoup d’itérateurs imbriqués. Il faut bien voir qu’il s’agit d’appliquer les fonctions associées à l’identifiant id à chacun des éléments enregistrés.

En conclusion…

D’abord, un lien vers le code complet et l’interface complète.

Il est certain que l’intérêt d’un tel module se ressent surtout dans de moyennes ou grosses applications, dont l’interface est complexe et présente un certain niveau de redondance. Je ne pense pas qu’il soit raisonnable de l’utiliser pour écrire un pong.

Voilà, c’est tout pour ajourd’hui !

Cordialement,
Cacophrène

Le temps me manque plus cruellement que jamais pour alimenter ce blog. Pourtant, ce ne sont pas les sujets qui manquent. L’actualité, à elle seule, apporte matière à des dizaines de billets.

Un billet, par exemple, pourrait évoquer le décès récent de Robin Milner et retracer son brillant parcours d’inventeur du langage ML et coauteur de l’algorithme d’inférence qui porte désormais son nom, l’algorithme de Hindley-Milner.

Les temps actuels sont aussi enrichissants en dehors du monde informatique. Les débats de société récents sur les changements climatiques et les biotechnologies soulèvent des questions scientifiques et philosophiques qui mériteraient de longs développements. Hélas, je n’ai plus le temps pour ça.

Peut-être le blog réouvrera-t-il ses portes un jour… mais pour l’heure, rideau ! J’adresse mes sincères remerciements à tous les lecteurs qui ont suivi ces billets avec intérêt.

Bien cordialement,
Cacophrène

Après un long moment d’absence, je reviens pour vous parler d’une notion dont l’intérêt m’a été révélé par un article sur le blog de bluestorm. Il s’agit des types fantômes, dont je souhaite vous montrer ici tout le bien. Naturellement, je vais partir d’un cas concret autour de ce que je développe actuellement.

Le contexte

Une application pour microscopistes

Je suis actuellement en train d’écrire les grandes lignes d’un programme destiné à des microscopistes amateurs, dont il existe déjà une version en Visual Basic (à réécrire et faire évoluer). Ce programme doit permettre de mettre en forme des images pour un forum en leur ajoutant un cartouche contenant diverses informations utiles (échelle, type de matériel, coloration éventuelle, etc.). Je vous donne une image ci-dessous pour vous faire une idée. Une caractéristique importante de ce logiciel réside dans sa capacité à dessiner des échelles à partir d’une relation entre un nombre X de pixels et une taille Y en micromètres, déterminée sur une image étalon.

Spores d’helvelle après coloration.
Objectif Zeiss Planapo 100/1.3

Image d’étalon

Une image étalon est une photo dont les éléments ont une taille connue, prise dans les mêmes conditions qu’une image classique. Le plus souvent, il s’agit d’une « règle » dont les graduations sont espacées de 10 µm (la bagatelle de 100 graduations dans un millimètre…). Le programme charge l’image d’étalon, l’analyse à la manière d’un outil de reconnaissance de caractères (en beaucoup plus simple !), et en déduit la taille d’une graduation, exprimée en pixels. De son côté, l’utilisateur indique la taille réelle correspondante, en micromètres cette fois-ci (cf. l’image ci-dessous).

Image d’étalon (1 graduation correspond à 10 µm).
Objectif Zeiss Plan Neofluar 63/1.25

Manipulation d’images

Pour automatiser la reconnaissance des graduations, on souhaite implémenter l’algorithme suivant (plutôt une recette de cuisine) :

• Charger l’image en couleur (24 bits).
• La transformer en niveaux de gris.
• Augmenter la luminosité pour éclaircir le fond.
• Passer en noir et blanc.
• Effacer les poussières pour uniformiser le fond.
• Reboucher les trous dans les traits de graduations.
• Mesurer les traits de graduation et les espaces qu’ils délimitent.
• En déduire la taille d’une graduation (un espace + un trait).

Pour y parvenir, nous allons utiliser LablGTK et CamlImages, deux bibliothèques qui dialoguent plutôt bien. Nous allons nous fixer comme objectif d’écrire un type picture polymorphe. Nous nous en servirons pour distinguer les images en couleur (24 bits), en niveaux de gris et en noir et blanc. Les fonctions telles que get_width ou get_pixbuf s’appliqueront à tout type d’image.

Choix d’une interface

Pour faire court, nous voudrions quelque chose comme ceci :

type 'a picture

type fullcolor
type grayscale
type monochrom

val from_file : string -> fullcolor picture
(** Charge une image en couleurs. *)

(** Fonctions usuelles, valables pour tout type d'image. *)
val copy : 'a picture -> 'a picture
val get_width : 'a picture -> int
val get_height : 'a picture -> int
val get_pixbuf : 'a picture -> GdkPixbuf.pixbuf

val grayscale : 
  ?filter:(Color.rgb -> int) -> 
  fullcolor picture -> grayscale picture
(** Conversion en niveaux de gris d'une image couleur (24 bits). *)

val black_and_white :
  ?threshold:int ->
  grayscale picture -> monochrom picture
(** Conversion en noir et blanc d'une image en niveaux de gris. *)

val noise_reduction :
  ?threshold:int ->
  monochrom picture -> monochrom picture
(** Effacement des poussières sur une image en noir et blanc. *)

val fill_gaps :
  ?threshold:int ->
  monochrom picture -> monochrom picture
(** Rebouchage des trous sur une image en noir et blanc. *)

Pour que cet algorithme ne reste pas nébuleux, voici un PDF d’illustration.

Du côté de l’implémentation

Après l’interface, voyons l’implémentation. A priori, cela peut sembler difficile. Pourtant, grâce aux types fantômes, nous n’avons presque rien à faire ! Définissons d’abord le type picture :

type 'a picture = {pict: OImages.rgb24_class}

Ne vous étonnez pas de trouver ici un record alors qu’il paraît inutile. Le vrai type picture, que j’utilise dans mon application, contient d’autres champs (mais aucun n’est de type 'a, c’est très important). Il a été simplifié ici par souci de pédagogie.

Définissons maintenant trois types fantômes :

type fullcolor
type grayscale
type monochrom

Un type fantôme est un type utilisé comme paramètre d’un autre type (à la manière du type int dans int list), mais qui ne sert pas dans la définition de ce type (comme 'a dans 'a picture ci-dessus). Le type fantôme vous permet d’ajouter une information (une contrainte) qui sera propagée correctement par l’algorithme d’inférence de types, sans impact sur l’implémentation. Dans mon cas, il s’agit surtout de s’assurer que l’on passe bien une image en niveaux de gris à la fonction black_and_white, par exemple.

Nous pouvons maintenant écrire la fonction de création :

let from_file str = {pict = OImages.rgb24 (OImages.load path [])}

puis les fonctions utilitaires :

let get_width t = t.pict#width
let get_height t = t.pict#height
let get_pixbuf t = Imagegdk.to_pixbuf t.pict#coerce
let copy t = {t with pict = Oo.copy t.pict}

Nous pouvons maintenant en venir aux fonctions qui agissent directement sur l’image et, comme vous allez le constater, on ne se doute de rien en lisant cette partie du code :

let grayscale ?(filter = Color.brightness) pic =
  let res = copy pic in
  let img = res.pict in
  for x = 0 to img#width - 1 do
    for y = 0 to img#height - 1 do
      let res = filter (img#unsafe_get x y) in
      img#unsafe_set x y {Color.r = res; g = res; b = res}
    done
  done;
  res

let black = {Color.r = 0; g = 0; b = 0}
let white = {Color.r = 255; g = 255; b = 255}

let black_and_white ?(threshold = 0x90) pic =
  let res = copy pic in
  let img = res.pict in
  for x = 0 to img#width - 1 do
    for y = 0 to img#height - 1 do
      let rgb = img#unsafe_get x y in
      img#unsafe_set x y (if rgb.Color.r > threshold then white else black)
    done
  done;
  res

et ainsi de suite (le détail d’implémentation des fonctions   et fill_gaps sort du cadre de ce billet; je peux développer sur demande, mais il ne me semble pas pertinent de le faire ici). Avec un appel à ocamlc -i, toutes ces fonctions accepteraient des images de type 'a picture. La contrainte que nous avons posée dans l’interface est à la fois valide et transparente du côté de l’implémentation.

Il est intéressant de noter que les types fantômes apportent une information supplémentaire sans impact sur l’implémentation. Cela renforce la sûreté du code sans nuire aux performances (imaginez la lourdeur qui consisterait à s’assurer d’abord que tous les pixels sont bien des teintes de gris !).

En guise de conclusion…

Je parlais d’un aller simple vers le monde des fantômes. Vous savez maintenant pourquoi : quand on y a goûté, on ne peut plus s’en passer. Les types fantômes, c’est bien, mangez-en !

À bientôt,
Cacophrène

Je vous ai parlé, dans le précédent billet, de l’intégration du widget GtkSourceView 2.0 dans la bibliothèque LablGTK. Voyons ici ce qui change par rapport à l’ancien widget.

Voici ci-dessous un petit code qui permet de voir quelques-unes des nouveautés de GtkSourceView 2.0, entre autres les thèmes (GtkStyleScheme) et la matérialisation des espaces. Un thème est choisi aléatoirement au lancement de l’application (évidemment, plus vous en avez et plus il y aura de visuels possibles…). Pour tester, placez le code suivant dans un fichier test.ml, puis compilez avec :

Si vous voulez utiliser un nom différent, n’oubliez pas de modifier la fonction read dans le code source !

let window =
  GMain.init ();
  let wnd = GWindow.window 
    ~title:"GtkSourceView 2.0 Demo" 
    ~position:`CENTER 
    ~resizable:false  
    ~width:800 ~height:600 () in 
  wnd#connect#destroy GMain.quit; 
  wnd 
 
let ocaml = 
  let manager = GSourceView2.source_language_manager ~default:true in 
  match manager#language "objective-caml" with 
  | None -> failwith "La coloration syntaxique pour OCaml n'est pas disponible !" 
  | some -> some
 
let manager = GSourceView2.source_style_scheme_manager ~default:true 
let schemes = Array.of_list manager#style_scheme_ids 
 
let get_random_style_scheme () = 
  Random.self_init (); 
  match manager#style_scheme schemes.(Random.int (Array.length schemes)) with 
  | None -> assert false 
  | some -> some 
 
let scroll = GBin.scrolled_window 
  ~hpolicy:`ALWAYS 
  ~vpolicy:`ALWAYS 
  ~packing:window#add () 
 
let source = 
  let src = GSourceView2.source_view 
    ~draw_spaces:[`NEWLINE; `SPACE] (* Matérialisation des espaces. *) 
    ~auto_indent:true 
    ~indent_on_tab:true (* Quelques étiquettes ont été renommées *) 
    ~indent_width:2 
    ~insert_spaces_instead_of_tabs:true 
    ~right_margin_position:80 
    ~show_line_numbers:true 
    ~show_right_margin:true 
    ~packing:scroll#add () in 
  src#misc#modify_font_by_name "Monospace 10"; 
  let buf = src#source_buffer in 
  buf#set_language ocaml; 
  buf#set_highlight_syntax true; 
  buf#set_style_scheme (get_random_style_scheme ()); 
  src 
 
let read () = 
  let ich = open_in "test.ml" in 
  let len = in_channel_length ich in 
  let str = String.create len in 
  really_input ich str 0 len; 
  close_in ich; 
  Glib.Convert.locale_to_utf8 str 
 
let _ = 
  source#source_buffer#set_text (read ()); 
  window#show (); 
  GMain.main ()

Ce code nous donne quelque chose comme ça :

Le nouveau widget bénéficie d’une interface plus agréable à utiliser, avec des étiquettes plus parlantes qu’auparavant. Il ne lui manque plus que la factorisation du code (code folding) et l’auto-complétion, qui sont sans doute les deux fonctionnalités les plus attendues pour les prochaines versions.

À bientôt,
Cacophrène

Je vous propose de poursuivre notre exploration de la bibliothèque LablGTK. Dans ce billet, nous allons parler du module GPack. Celui-ci contient tous les widgets nécessaires à la réalisation d’interfaces complexes. La plupart d’entre eux sont transparents pour l’utilisateur, car ils n’ont pas de représentation graphique. Pourtant, comme nous allons le voir ici, ce sont de précieux alliés !

Introduction

Nous avons vu dans un précédent billet que l’élément principal d’une interface est généralement une fenêtre (GtkWindow). Or ce widget ne peut contenir qu’un seul widget enfant. Cela semble, a priori, une limitation majeure. Pourtant, GTK permet de réaliser des interfaces arbitrairement complexes. Il est donc possible de lever cette limitation. Pour cela, GTK définit des conteneurs, c’est-à-dire des widgets dont la fonction principale est de contenir d’autres widgets. Ces conteneurs peuvent être imbriqués à souhait et constituent donc une solution à la fois élégante et souple.

Les boîtes horizontales (GtkHBox)

Ces boîtes permettent d’insérer des widgets horizontalement. Les enfants sont insérés avec la méthode #add, ou avec #pack si l’on souhaite paramétrer finement le style d’insertion (entre autres, la capacité du widget enfant à être élargi pour remplir l’espace disponible). Voyez par exemple :

let window =
  GMain.init ();
  let wnd = GWindow.window ~width:150 ~height:100 () in
  wnd#connect#destroy GMain.quit;
  wnd

let packing = 
  let hbox = GPack.hbox
    ~spacing:5 (* Les enfants sont espacés de 5 pixels. *)
    ~border_width:5 (* La boîte possède une bordure de 5 pixels. *)
    ~packing:window#add () in
  hbox#pack ~expand:false

let _ = 
  List.iter (fun text -> ignore (GMisc.label ~packing ~text ())) ["foo"; "bar"];
  window#show ();
  GMain.main ()

Pour info : cet exemple, comme les suivants, est complet et peut-être testé dans l’interpréteur après avoir chargé la bibliothèque LablGTK.

Les boîtes verticales (GtkVBox)

Les boîtes verticales fonctionnent de la même manière que les boîtes horizontales, à un détail près : les widgets enfants sont insérés verticalement.

let window =
  GMain.init ();
  let wnd = GWindow.window ~width:150 ~height:100 () in
  wnd#connect#destroy GMain.quit;
  wnd

let packing = 
  let vbox = GPack.vbox
    ~spacing:5 (* Les enfants sont espacés de 5 pixels. *)
    ~border_width:5 (* La boîte possède une bordure de 5 pixels. *)
    ~packing:window#add () in
  vbox#pack ~expand:false

let _ = 
  List.iter (fun text -> ignore (GMisc.label ~packing ~text ())) ["foo"; "bar"];
  window#show ();
  GMain.main ()

Les tableaux (GtkTable)

Les tableaux (GtkTable) sont un moyen pratique d’organiser des widgets sous forme de tableaux (on s’en serait douté…). Ils peuvent être utilisés, par exemple, pour créer des palettes. Les widgets sont insérés à l’aide de la méthode #attach en indiquant l’emplacement des coins gauche (left) et haut (top) du widget.

let window =
  GMain.init ();
  let wnd = GWindow.window () in
  wnd#connect#destroy GMain.quit;
  wnd

let attach = 
  let table = GPack.table 
    ~rows:4 (* Nombre de rangées. *)
    ~columns:4 (* Nombre de colonnes. *)
    ~row_spacings:2 (* Espacement des éléments d'une même rangée. *)
    ~col_spacings:2 (* Espacement des éléments d'une même colonne. *)
    ~packing:window#add () in
  fun i -> table#attach ~left:(i mod 4) ~top:(i / 4)

let _ = 
  Random.self_init ();
  for i = 0 to 24 do
    let r = Random.int 256 and g = Random.int 256 and b = Random.int 256 in
    let text = Printf.sprintf "#%02x%02x%02x" r g b in
    let entry = GEdit.entry ~text ~width:80 ~packing:(attach i) () in
    entry#misc#modify_base [`NORMAL, `NAME text]
  done;
  window#show ();
  GMain.main ()

Les boîtes pour boutons (GtkButtonBox)

GTK fournit une boîte spécialement conçue pour recevoir des boutons : il s’agit de GtkButtonBox, ou GPack.button_box dans LablGTK. Elle est conçue pour vous permettre d’organiser des boutons à la manière des boîtes de dialogue :

let window =
  GMain.init ();
  let wnd = GWindow.window
    ~title:"Button box demo"
    ~position:`CENTER 
    ~resizable:false
    ~width:300 ~height:150 () in
  wnd#connect#destroy GMain.quit;
  wnd

let vbox = GPack.vbox 
  ~spacing:2 
  ~border_width:2
  ~packing:window#add ()

let view = GText.view ~packing:vbox#add ()

let bbox = GPack.button_box `HORIZONTAL
  ~layout:`EDGE (* C'est ici que l'on choisit la disposition des boutons. *)
  ~border_width:2
  ~packing:(vbox#pack ~expand:false) ()

let help = GButton.button ~stock:`HELP ~packing:bbox#add ()
let quit = GButton.button ~stock:`QUIT ~packing:bbox#add ()

let _ =
  window#show ();
  GMain.main ()

Autres éléments

Le module GPack définit d’autres widgets, notamment les pages à onglets (GtkNotebook) et les panneaux mobiles (GtkPaned). En raison de leur intérêt tout particulier dans la réalisation d’interfaces, nous y consacrerons un billet entier.

Atelier : Le triangle de Pascal

Pour terminer, je vous propose de réaliser une petite application qui affiche à l’écran les coefficients binomiaux en les présentant sous la forme du célèbre triangle de Pascal. Voici à quoi devra ressembler notre application :

Pour réaliser notre application, nous avons besoin d’une fenêtre :

let window =
  let wnd = GWindow.window
    ~title:"GPack demo"
    ~position:`CENTER
    ~resizable:false
    ~width:400 ~height:300 () in
  wnd#connect#destroy GMain.quit;
  wnd

Celle-ci doit recevoir deux éléments distincts : une fenêtre assortie de barres de défilement, pour recevoir le triangle, et un bouton de fermeture. Nous allons donc commencer par insérer une boîte verticale dans window :

let vbox = GPack.vbox 
  ~border_width:2 
  ~spacing:2 
  ~packing:window#add ()

Nous pouvons alors ajouter les barres de défilement pour permettre à l’utilisateur d’explorer les lignes du triangle :

let scroll = GBin.scrolled_window
  ~hpolicy:`ALWAYS
  ~vpolicy:`ALWAYS
  ~packing:window#add ()

Ces barres de défilement ajoutées avec GBin.scrolled_window ne résolvent pas le problème de GWindow.window, car l’une comme l’autre ne peuvent contenir qu’un seul widget enfant. Pour lever cette limitation, nous devons donc insérer une boîte verticale à l’intérieur des barres de défilement. Ici, comme il doit être possible de faire défiler le contenu de la boîte, on utilise la méthode #add_with_viewport au lieu du classique #add. Ce qui nous donne :

let vbox, packing = 
  let vbox = GPack.vbox
    ~spacing:2
    ~packing:scroll#add_with_viewport () in
  vbox, vbox#pack ~expand:false

Écrivons maintenant une fonction spécialisée (par application partielle) de GMisc.label pour nous simplifier la tâche :

let label = GMisc.label ~height:50 ~width:50 ~xalign:0.5

Pour information, les paramètres height et width fixent la taille des étiquettes produites (pas étonnant quand même…), et xalign détermine l’alignement du texte (aligné à gauche avec 0.0, centré avec 0.5 et aligné à droite avec 1.0).

Venons-en maintenant au coeur du problème. Nous devons écrire une fonction qui affiche les lignes successives du triangle de Pascal en calculant les coefficients. Ici, les boucles sont pratiques, je préfère donc donner une version en style impératif. Les principales étapes sont les suivantes :

• Pour tout entier i entre 1 et n, créer un nouveau conteneur horizontal (GPack.hbox) et la fonction d’empaquetage associée (packing).
• Pour tout entier j entre 1 et j, calculer le coefficient binomial, égal à 1 lorsque j = 1 ou j = i, et coeff(i – 1, j – 1) + coeff(i – 1, j) sinon. Le stocker dans une table de hachage pour réutilisation ultérieure (mémoïsation).
• Créer une étiquette (GMisc.label) contenant le coefficient, et l’insérer dans le conteneur horizontal précédemment créé.

Nous pouvons satisfaire à toutes ces exigences avec le code suivant :

let create n =
  let mem = Hashtbl.create n in
  let get = Hashtbl.find mem in
  for i = 1 to n do
    let packing = (GPack.hbox ~spacing:2 ~packing ())#pack ~expand:false in
    for j = 1 to i do
      let coef =
        if j = 1 || j = i then 1 
        else get (i - 1, j) + get (i - 1, j - 1) in
      label ~text:(string_of_int coef) ~packing ();
      Hashtbl.add mem (i, j) coef
    done
  done

Nous pouvons maintenant terminer notre application en lui ajoutant un bouton de fermeture. C’est le moment de se rappeler que le conteneur GPack.button_box est destiné tout spécialement à recevoir des boutons :

let quit = 
  let bbox = GPack.button_box `HORIZONTAL 
    ~layout:`END 
    ~packing:(vbox#pack ~expand:false) () in
  let quit = GButton.button ~stock:`QUIT ~packing:bbox#add () in
  quit#connect#clicked window#destroy;
  quit

Pour finir, quelques lignes qui vérifient que le nombre de lignes à afficher est bien passé en argument, et qu’il s’agit d’un entier valide compris entre 1 et 25 (limites arbitraires) :

let _ =
  try
    if Array.length Sys.argv = 2 then (
      let n = int_of_string Sys.argv.(1) in
      if n > 0 && n < 26 then create n else raise Exit;
      window#show ();
      GMain.main ()
    ) else raise Exit 
  with _ -> prerr_endline "Usage: triangle.ml TAILLE"

C’est tout ! Il ne nous reste plus qu’à lancer l’application :

Voici aussi un lien vers le code complet de cet atelier.

À bientôt,
Cacophrène