incron est un programme fonctionnant sur le même principe que cron, mais basé sur des événements dans le système de fichiers plutôt que sur des moments de la journée. C’est très propre: pour l’utiliser, on spécifie un ou des fichiers à surveiller, un type d’action à détecter sur le(s) fichier(s) en question, et une commande à déclencher lorsque l’événement survient. Je me suis dit que c’était l’occasion où jamais de mettre à jour un vieux script que j’avais, qui me met au courant des modifications sur mes logs (je tire l’idée de ce script d’un ancien post sur le planet libre).

Après avoir installé incron, j’édite ma table de configuration incron:

incrontab -e

Avec mon éditeur favori, je lui mets la ligne suivante:

/var/log/kernel.log IN_MODIFY sh /home/me/documents/scripts/popLog.sh /var/log/kernel.log

popLog.sh est un script qui prend en argument un log, en extrait la dernière ligne modifiée, la colorise avec source-highlight et l’envoie en notification par le biais de notify-send. Le but de ce script est donc d’afficher le dernier log dans une bulle, avec coloration syntaxique.

Je fournis le script en question, et j’ajoute quelques explications:

• source-highlight a besoin de parler un code couleurs compris par les bulles de notifications. notification-daemon comprend des couleurs de type <span color=”couleur”>mots à colorier</span>, d’où le fichier supplémentaire awesome.outlang (que j’avais écrit à l’origine pour naughty et donc compatible avec celui-ci, pour les utilisateurs d’awesome wm – à ce propos il y a plusieurs entrées dans le wiki pour faire des choses semblables).
• incron ne comprend pas bien les variables d’environnement, il vaut mieux les redéfinir dans le script, comme je l’ai fait.
• faites attention à ne pas faire n’importe quoi avec incron, il est facile de créer une boucle infinie en surveillant par exemple /var/log/everything.log (vous notifiant du lancement de ce script, et donc générant une nouvelle notification): IN_NO_LOOP est votre ami.
• incron prend des chemins absolus.

Après tous ces avertissements, voici /home/me/documents/scripts/popLog.sh:

#!/usr/bin/env bash

# Usage: popLog /var/log/yourlog
# pops a colored log with the last line of the log

export DISPLAY=":0.0"
export HOME="/home/me"

#Urgency
infoUrgency='low'
warningUrgency='normal'
errorUrgency='critical'
securityUrgency='critical'

#Popup time
infoPopupTime=5000
warningPopupTime=8000
errorPopupTime=11000
securityPopupTime=11000

#Icons
infoIcon='/usr/share/icons/gnome/32x32/status/dialog-information.png'
warningIcon='/usr/share/icons/gnome/32x32/status/dialog-warning.png'
errorIcon='/usr/share/icons/gnome/32x32/status/dialog-error.png'
securityIcon='/usr/share/icons/gnome/32x32/status/security-medium.png'

coloredLog=$(tail -n 1 $1 |                   \
  source-highlight --failsafe                 \
                   --src-lang=log             \
                   --style-file=default.style \
                   --outlang-def=${HOME}/documents/scripts/awesome.outlang)

if [[ $coloredLog!='' ]]; then

    if [[ $(echo $1|grep info) ]]; then messageType='info'; fi
    if [[ $(echo $1|grep warn) ]]; then messageType='warning'; fi
    if [[ $(echo $1|grep err) ]]; then messageType='error'; fi
    if [[ $(echo $1|grep auth) ]]; then messageType='security'; fi
    if [[ $(echo $1|grep access) ]]; then messageType='security';fi
    if [[ $(echo $notification|grep 'UFW BLOCK INPUT') ]]; then
        messageType='security'; fi
    if [[ $messageType == '' ]]; then messageType='info'; fi

    case $messageType in
    info)
        urgency=$infoUrgency
        icon=$infoIcon
        popupTime=$infoPopupTime
    ;;
    warning)
        urgency=$warningUrgency
        icon=$warningIcon
        popupTime=$warningPopupTime
    ;;
    error)
        urgency=$errorUrgency
        icon=$errorIcon
        popupTime=$errorPopupTime
    ;;
    security)
        urgency=$securityUrgency
        icon=$securityIcon
        popupTime=$securityPopupTime
    ;;
    esac

    notify-send -u $urgency -t $popupTime -i "$icon" "$1" "$coloredLog"
fi

Et voici /home/me/documents/scripts/awesome.outlang:

extension "awesome"

color "<span color=\"$style\">$text</span>"

colormap
"green" "#33CC00"
"red" "#FF0000"
"darkred" "#990000"
"blue" "#0000FF"
"brown" "#9A1900"
"pink" "#CC33CC"
"yellow" "#FFCC00"
"cyan" "#66FFFF"
"purple" "#993399"
"orange" "#FF6600"
"brightorange" "#FF9900"
"brightgreen" "#33FF33"
"darkgreen" "#009900"
"black" "#000000"
"teal" "#008080"
"gray" "#808080"
"darkblue" "#000080"
default "#66FFFF"
end

Je vous laisse faire joujou, je suis sûr que vous allez trouver plein d’idées.

J’ai envie d’attirer l’attention sur une fonctionnalité sympa de vim, qui pourtant semble méconnue de pas mal de monde, même des utilisateurs avancés: la commande “:GetLatestVimScripts”, ou son alias “:GLVS”.

Le principe est simple: vous installez un script pour vim, et vous voulez que ce script se maintienne à jour (c’est à dire que vous voulez profiter des versions successives du script par l’auteur). Au lieu de vous embêter à vérifier si il y a des nouvelles versions périodiquement et d’avoir à suivre un procédé d’installation qui differera selon que vous ayez affaire à un vimscript, un vimball, ou une quelconque archive, vous pouvez tout simplement dire à vim de gérer tous vos scripts d’un coup. Pour cela, il vous suffit de maintenir à jour la liste des scripts qui vous intéressent dans le fichier ~/.vim/GetLatest/GetLatestVimScripts.dat . Le format de ce fichier est simple:

<numéro du script> <numéro de version installée du script> :AutoInstall: <nom du script>

Le numéro du script est dans l’url sur sourceforge, donné par “scriptid”. La version installée du script est maintenue directement par la commande “:GLVS”. Si vous voulez être sûr que la mise à jour soit faite, mettez 1.

Maintenant, votre répertoire ~/.vim est assez facile à transporter. J’ai pour habitude d’en garder une copie “vide”, avec une arborescence sous la forme:

.vim/
.vim/GetLatest/
.vim/GetLatest/GetLatestVimScripts.dat

Un test?

Vous pouvez tester l’astuce assez simplement: Sauvez votre répertoire ~/.vim (si vous en avez un) en le bougeant sous un autre nom, et faites en un nouveau ou vous recréerez l’arborescence décrite précedemment. Insérez dans GetLatestVimScripts.dat les lignes suivantes:

ScriptID SourceID Filename
--------------------------
# Les lignes commençant par '#' sont des commentaires
# Les deux premières lignes sont nécessaires
#
# Script permettant d'avoir une complétion grâce à la touche <tab>
# le premier numéro a été obtenu dans l'url du script:
# http://www.vim.org/scripts/script.php?script_id=1643
1643 1 :AutoInstall: supertab.vim

- Ouvrez vim, tapez :GLVS. Le script va se mettre à jour de lui-même.

- Vous pouvez tester le script, assez sympa, qui permet de compléter les mots que vous tapez avec la touche de tabulation (pour savoir comment ça se paramètre, lisez le script, pour l’instant sa doc est incluse en commentaire dans le code – j’ai proposé au mainteneur un patch avec une vraie doc vim, accessible par :help et j’ai bon espoir qu’il l’inclue dans une future version)

- Fin de la démo. Vous pouvez supprimer votre répertoire .vim et remettre votre ancienne configuration (si vous en aviez une).

Une petite explication supplémentaire s’impose. Le mot clé :AutoInstall: dans la ligne que j’ai préconisée n’est pas obligatoire. Cela vient du fait que tous les scripts ne sont pas installables automatiquement (mais tous sont téléchargeables automatiquement). Cela dit, les scripts sourceforge sont assez standards et la plupart seront autoinstallables même si l’auteur du script ne connaissait pas la fonctionnalité. Si jamais votre script ne s’installe pas correctement, vous pouvez écrire à son auteur afin qu’il le modifie (ça marche, je l’ai fait récemment avec zenburn en aidant son auteur à le mettre sous forme de vimball) et en attendant, retirer ce mot clé.

En espérant que ça serve…
En bonus, voici la liste des plugins que j’utilise. C’est très orienté C++. Mon conseil, c’est de vous abonner au flux rss de vim.org, comme ça vous serez au courant des plugins sympa qui sortent.

ScriptID SourceID Filename
--------------------------
39   1 :AutoInstall: matchit.zip
40   1 :AutoInstall: Drawit.vim
273  1 :AutoInstall: taglist.zip
294  1 :AutoInstall: Align.vim
302  1 :AutoInstall: AnsiEsc.vim
415  1 :AutoInstall: zenburn.vim
489  1 :AutoInstall: Manpageview.vim
610  1 :AutoInstall: ctags.vim
642  1 :AutoInstall: getscript.vim
1066 1 :AutoInstall: cecutil.vim
1075 1 :AutoInstall: netrw.vim
1116 1 :AutoInstall: maplesyrup.tar.gz
1195 1 :AutoInstall: vis.vba.gz
1502 1 :AutoInstall: vimball.vim
1506 1 :AutoInstall: LargeFile.vim
1520 1 :AutoInstall: omnicppcomplete.zip
1643 1 :AutoInstall: supertab.vim
1658 1 :AutoInstall: NERD_tree.zip
1697 1 :AutoInstall: surround.vim
2136 1 :AutoInstall: repeat.vim
2164 1 :AutoInstall: renamec.vim
2527 1 :AutoInstall: jpythonfold.vim
2540 1 :AutoInstall: snipMate.zip
2645 1 :AutoInstall: colourscheme_bandit.vim
2646 1 :AutoInstall: ctags_highlighting.vba

L’annonce vient de tomber sur la mailing liste : gdb vient de sortir dans sa version 7.0! Vous vous dîtes: “Bof, gdb je connais, une nouvelle version d’un débogueur qui sort, il n’y a pas de quoi fouetter un chat.” Détrompez-vous!  Les progrès apportés sont tels que je n’allais pas vous laisser les ignorer. Je veux bien entendu parler du “reverse debugging”.

Hein? C’est quoi? Bon, j’explique : normalement, dans un debugger (ou un “débogueur”, en bon français), on déroule le programme toujours dans le même sens. Et ben maintenant, on a la possibilité de revenir en arrière!
Dans le concept, c’est un peu comme rembobiner un film, mais pour un programme. Donc voilà, par exemple, on avait “c” pour “continue”, on a maintenant “rc” pour “reverse continue”. Bon, ça paye pas de mine, comme ça, mais à faire c’est probablement assez compliqué. Ça fait tellement longtemps qu’on parle d’ajouter cela dans gdb que ça justifie amplement le passage direct de 6.8 à 7.0 dans les numéros de versions. Ça explique aussi pourquoi les développeurs la qualifiaient d’avance de “major release”.

Là, on marque une pause et on s’incline. Ceux qui savent comment fonctionne un ordinateur se demandent comment ça peut bien marcher (allez regarder le code source, les gars). On se rend compte de l’exploit technique que ça doit représenter, on y ajoute une petite réflexion sur le nombre d’architectures que le machin supporte, et on se dit que décidemment il y a des gens très forts.

Je ne m’arrête pas en si bon chemin. Ceux qui ont tenté d’utiliser gdb ont probablement aussi un assez mauvais souvenir de la maniabilité du programme. C’est pas très, comment dire…  “user friendly”. Bon, pour répondre à ces gens là je ne vous promets pas de miracle, mais sachez que gdb est devenu scriptable en python. Ça promet d’améliorer sérieusement sa souplesse, mais aussi, mon petit doigt me dit qu’on devrait probablement
voir de nouveaux front-end ultra souples voir le jour.

Voilà pour mes features préférées, mais il y en a d’autres. Je vous lie la fameuse annonce, qui vaut son pesant de cacahuètes. Vivement que ma distribution le package.

L’annonce
La nouvelle doc sur le reverse debugging

On m’a donné une astuce bien sympa pour générer de la documentation de manière conditionnelle avec doxygen. J’utilise ça dans le projet que je code au boulot, et je pense que ça vaut le coup de partager. L’idée est de générer la  documentation automatiquement à chaque compilation de mon projet, en faisant appel aux features avancées de doxygen en fonction des outils dont dispose l’utilisateur : dot, htags, perl, etc… On va donc vérifier quels programmes sont présents grâce au configure.ac, et on va générer le doxyfile en fonction desquels sont présents.

L’exemple que je donne n’est pas complet, mais vous pouvez vous en inspirer:

Fichier configure.ac

AC_CHECK_PROG([DOT], [dot], [yes], [no])
AC_CHECK_PROG([HTAGS], [htags], [yes], [no])
AC_PATH_PROG([PERL], [perl], [])
AM_CONDITIONAL([DOXYGEN], [test "x$doxygen_ok" = xyes])
AM_CONDITIONAL([DOT], [test "x$dot_ok" = xyes])

AC_CONFIG_FILES(
    doc/doxygen_html.cfg
)

Ensuite, il suffit de glisser les bonnes références dans le fichier doc/doxygen_html.cfg.in :

USE_HTAGS              = @HTAGS@
PERL_PATH              = @PERL@
HAVE_DOT               = @DOT@

Ainsi, après l’appel de ./configure, le fichier doxygen_html.cfg va être généré, et les expressions entre @ vont y être remplacées par les bonnes valeurs. Vous pourrez ensuite vous servir de ce fichier pour véritablement générer la doc…

Au boulot, j’usilise les autotools comme buildsystem de mon projet. C’est pas l’idéal, je préfererais un truc plus moderne du style cmake, mais vu que tout le monde y est j’ai pas trop le choix. Bon, et qu’est ce qu’on fait pendant que ça compile? Généralement, rien : ça dure pas assez longtemps pour se mettre à un autre truc et trop pour ne pas glander sur xkcd.

Alors voilà un bon truc, qui s’adaptera facilement à des Makefile classiques, pour être prévenu par un popup lorsque votre compilation ou vos tests se terminent: vous ajoutez un appel à notify-send dans la cible par défaut de vos Makefiles, de manière à ce que celui-ci vienne en dernier. Autant sur un Makefile, c’est pas très dur, autant avec les autohells, j’ai galéré. En fait c’est tout simple, il suffit d’utiliser une cible ‘-local’ dans le Makefile.am, qui permet d’overrider les cibles par défaut. Ici, ça sera donc all-local. Bon, et comme vous voulez que le projet continue à marcher si vous ne disposez pas de notify-send, il faut modifier aussi le configure.ac.

Ça donne:

- configure.ac :

#-----------------------------------------------------------------------
# Support for notify-send
#-----------------------------------------------------------------------
AC_CHECK_PROG([notify_ok], [notify-send], [yes], [no])
AM_CONDITIONAL([NOTIFYSEND], [test "x$notify_ok" = xyes])

- Makefile.am :

if NOTIFYSEND
all-local:
    notify-send --icon=${PWD}/chemin/vers/icone/du/projet "My project" "Finished!"
endif

Voilà, j’espère que ça va vous servir. Pour info, notify-send est un outil utilisant dbus qu’on trouve la plupart du temps dans le paquet libnotify. On doit même pouvoir faire sans, en utilisant directement dbus-send, mais la syntaxe est moins aisée (si vous l’avez, n’hésitez pas à laisser un commentaire).

Aujourd’hui, après avoir passé un bout de temps à déchiffrer la sortie d’une compilation, je me suis mis en quête d’améliorer mon quotidien et d’y mettre… des couleurs!

Pour ce faire, on cherche un peu ce qui existe déjà, et on tombe sur colorgcc. C’est disponible sur pas mal de distributions, c’est juste un script perl à appeler à la place de gcc, et ça rajoute des couleurs. Pour en profiter, il suffit de glisser dans vos Makefile

CXX=/usr/bin/colorgcc

Avec les autotools, on peut régler ça à l’invocation du script configure :

./configure CXX=/usr/bin/colorgcc

Bon. Pas mal. Maintenant, les diff. Au boulot, je n’ai pas mieux sous la main qu’un svn comme gestionnaire de version. Quand je me tape des svn diff, j’aime bien que ça soit un peu lisible. Et si on se mettait ça en couleurs? En lisant un peu la doc, on voit qu’il suffit de se faire un script. Mettons diffwrap.sh.

#!/bin/sh
# Configure your favorite diff program here.
DIFF="/usr/bin/colordiff"
# Subversion provides the paths we need as the sixth and seventh
# parameters.
LEFT=${6}
RIGHT=${7}
# Call the diff command
$DIFF $LEFT $RIGHT
# Return an errorcode of 0 if no differences were detected, 1 if some were.
# Any other errorcode will be treated as fatal.

J’ai installé colordiff pour faire le boulot. Il suffit après d’éditer ~/.subversion/config, et d’ajouter, section [helpers]

diff-cmd = /path/to/diffwrap.sh

Bon ok, mais quand je fais make, j’ai toujours beaucoup de sortie Il n’y aurait pas moyen de se cantonner aux erreurs gcc lorsqu’il y en a? Aller, on va baisser un peu ça avec un petit peu (le -j3 est pour multithreader le make : j’ai un dual core, autant en profiter).

alias make='make -j3 -s'

Bien entendu, en tant qu’adepte de vim, j’utilise aussi beaucoup :make. Dans le .vimrc, il peut s’avérer utile de glisser alors:

autocmd BufNewFile,BufRead,BufEnter *.cpp,*.hpp set makeprg=make\ -j3\ -s

Au passage, j’espère que vous connaissiez omnicppcomplete, qui va chez moi dans la même section du .vimrc:

autocmd BufNewFile,BufRead,BufEnter *.cpp,*.hpp set omnifunc=omni#cpp#complete#Main

On combine tout ça à quelques alias assez connus, et on vit un peu mieux dans sa console…

# SOME COLORS
if [ -x /usr/bin/dircolors ]; then
    eval "`dircolors -b`"
    alias ls='ls --color=auto'
    alias dir='dir --color=auto'
    alias vdir='vdir --color=auto'
    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
    alias diff='colordiff'
    alias less='less -R'
fi

Si vous avez des trucs utiles, n’hésitez pas! Je suis en particulier à la recherche d’un script vim qui exploiterait un rien les options ‘errorformat’ et ‘QuickFixCmdPost’ afin d’améliorer encore la lisibilité des compilations dans la fenêtre quickfix.

Ça faisait longtemps que je n’avais pas fait d’article, j’en profite donc pour rendre hommage au méconnu vimgdb. vimgdb est un patch pour vim qui permet de débogguer dans vim. On ne vantera jamais assez les mérites d’un déboggeur (franchement, il y a un stade où il faut arrêter les fprintf(stdout, “kikoo”) et les cout <<”lol”), que ce soit parce que c’est franchement plus élégant, que c’est plus le pratique quand on maitrise, ou parce que c’est mille fois plus puissant.

Alors, me direz-vous, chers adeptes de gvim, qu’il existe déjà un plugin pour vim nommé clewn (ou voir mieux, pyclewn) qui fait la même chose sans se taper de recompilation intempestive de son éditeur favori. Eh bien moi je vous répond: oui mais dans gvim on ne peut pas retrouver le shell en tapant Ctrl-Z (ce qui met vim en arrière-plan) et c’est un sérieux handicap pour les gens comme moi qui apprécient énormément cette feature (au fait, fg est votre ami si vous découvrez en lisant l’article et que vous ne savez pas comment revenir à vim).

Malheureusement, le paquet fait défaut sur la plupart des distrib (sauf archlinux, où je me suis permis de l’ajouter dans AUR — si vous avez des suggestions pour améliorer le pkgbuild, n’hésitez pas). Vous pouvez donc vous inspirer dudit pkgbuild pour compiler votre version, ou suivre les indications du site (je vais pas vous dire comment compiler un programme, quand même!).

Après, en installant le plugin vim pour gdb (comme indiqué dans la procédure du lien précédent), vous avez accès à tout un cas de commandes sympa (:help gdb pour l’aide), qui permettent de voir vos variables et de suivre le déroulement des opérations dans l’éditeur. Cool, non? Preuve que c’est bien pensé, je n’ai eu à changer aucun des raccourcis par défaut (J’ai juste changé un “where” en “where all” dans .vim/macros/gdb_mappings.vim). Evidemment, il est aussi possible d’ajouter ses propres mappings ou de modifier ceux qui sont fournis. N’oubliez pas de rajouter run macros/gdb_mappings.vim dans votre .vimrc!

Je vous suggère aussi de vous renseigner sur gdb et de suivre le tuto de Peter Jay Salzman, qui m’a bien initié. Pour ma part, je conserve aussi dans un coin un excellent lien qui me sert de référence en cas de trou de mémoire…

Bon déboggage!

Si vous souhaitez des screenshots, regardez par là…

PS: apparemment mon pkgbuild a été marqué “out of date”, je vais corriger ça dès que possible…

Ce petit billet me sert à vous faire suivre une information par le développeur de MonkeyChow, un des lecteurs de flux rss “web-based” dont je parlais il n’y a pas si longtemps dans cet article.

Greetings. I am the author for MonkeyChow. I’m sorry to resort to English. My high-school French serves me poorly here.

MonkeyChow is updated frequently and can be found here
http://www.shokk.com/blog/monkeychow-weekly-tarballs/

I will update the screencast in the near future to show off the new features. in the meantime, new features are explained in these articles.
http://www.shokk.com/blog/articles/category/monkeychow/

Substantiellement, en français, l’auteur nous signifie que MonkeyChow est mis à jour régulièrement et qu’il a de nouvelles fonctionnalités. La vidéo de démo sera mise à jour d’ici peu, et on peut déjà trouver sur son blog (en) les articles qui relatent ces fonctionnalités.

Ça méritera qu’on y jette un coup d’oeil…

Je recherche en ce moment des outils qui me permettraient d’importer/exporter de l’uml pour un projet C++ que je vais faire cet été. L’idée est la suivante : je souhaiterais que les modifications de mon code soient répercutées sur un fichier contenant de l’uml sous un format quelconque, et je souhaiterais par ailleurs pouvoir générer du code à partir de ce format. Idéalement, une règle dans le Makefile, appelée à chaque génération du projet serait idéale pour ce genre de truc.

À moins que j’ai mal compris, Umbrello est bien capable de générer du code, mais malheureusement l’import est une autre histoire : si celui-ci est bien capable d’importer une classe à partir du C++, en revanche il ne génère aucun diagramme (voir la page consacrée de l’aide) :

Note that Umbrello UML Modeller will not create any kind of Diagram for showing your classes, they will only be imported into your Model so that you can use them later in any diagram you want.

J’ai aussi jeté un coup d’oeil du côté d’ArgoUml. Malheureusement, de ce côté non plus c’est pas la panacée puisqu’ici on ne parle que de java : moi, je veux du C++.

What is ArgoUML?

[...]

ArgoUML also has the ability to reverse engineer compiling Java code and generate UML diagrams for it.

En allant inspecter les moteurs de recherche, j’ai fini par tomber sur un outil intéressant : dia2code. Celui-ci prend en entrée un schéma uml en dia, et génère du code dans le langage choisi. J’ai regardé la section examples du site, c’est assez convaincant. Pour ce schéma :
Les fichiers suivants seront générés :
foowindow.cpp 1/14

#include "foowindow.h"

void FooWindow::redraw (  ){
}

foowindow.h 2/14

#ifndef FOOWINDOW_H
#define FOOWINDOW_H

#include "window.h"

class FooWindow: public Window {
  // Associations
  // Attributes
  // Operations
  public:
    void redraw (  );
};

#endif

foowindowmanager.cpp 3/14

#include "foowindowmanager.h"

foowindowmanager.h 4/14

#ifndef FOOWINDOWMANAGER_H
#define FOOWINDOWMANAGER_H

#include "windowmanager.h"

class FooWindowManager: public WindowManager {
  // Associations
  // Attributes
  // Operations
};

#endif

point.cpp 5/14

#include "point.h"

Point::Point ( float x, float y ){
}

float Point::getX (  ){
}

float Point::getY (  ){
}

point.h 6/14

#ifndef POINT_H
#define POINT_H

class Point {
  // Associations
  // Attributes
  private:
    float x;
    float y;
  // Operations
  public:
    Point ( float x, float y );
    float getX (  );
    float getY (  );
};

#endif

rectangle.cpp 7/14

#include "rectangle.h"

float Rectangle::getArea (  ){
}

rectangle.h 8/14

#ifndef RECTANGLE_H
#define RECTANGLE_H

#include "point.h"
#include "shape.h"

class Rectangle: public Shape {
  // Associations
   Point points;
  // Attributes
  // Operations
  public:
    float getArea (  );
};

#endif

shape.cpp 9/14

#include "shape.h"

shape.h 10/14

#ifndef SHAPE_H
#define SHAPE_H

class Shape {
  // Associations
  // Attributes
  // Operations
  public:
    virtual float getArea (  ) = 0;
};

#endif

window.cpp 11/14

#include "window.h"

window.h 12/14

#ifndef WINDOW_H
#define WINDOW_H

#include "shape.h"

class Window {
  // Associations
  // Attributes
  private:
    Shape visualrep;
  // Operations
  public:
    virtual void redraw (  ) = 0;
};

#endif

windowmanager.cpp 13/14

#include "windowmanager.h"

windowmanager.h 14/14

#ifndef WINDOWMANAGER_H
#define WINDOWMANAGER_H

#include "window.h"

class WindowManager {
  // Associations
   Window windows;
  // Attributes
  // Operations
};

#endif

Pas mal. Il y a de l’idée. Maintenant, cherchons s’il existe le procédé inverse. J’ai trouvé trois outils capables de générer de l’uml dia à partir du C++ : cpp2dia, autodia et medoosa. Autant vous dire tout de suite que rien de spécialement convaincant ne sort de ces programmes.

• Le dernier de ces 3 à avoir été mis à jour semble être autodia (2007). Autodia est un script perl qui peut parser plusieurs langage, mais il semblerait que le module C++ soit buggué. D’abord, la sortie est immonde et complètement enchevêtrée. Mais ça, ça s’édite avec dia (du moment que les associations sont bonnes, moi je suis content). Ensuite il prend mal les noms des classes puisqu’il m’a embarqué l’accolade ouvrante à chaque génération de classe (Je le soupçonne en fait d’avoir oublié de gérer les namespaces). J’ai tout de même écrit à l’auteur pour lui signaler le problème.
• cpp2dia est celui qui n’a pas été mis à jour depuis le plus de temps (mai 2003). Cependant, les screenshots ont l’air sympa. C’est un script tcl que j’ai réussi à faire marcher, mais qui ne m’a pas du tout donné le même genre de résultat que ce qu’on peut voir sur le site. Pourtant, l’idée est intéressante : au lieu de parser le programme lui-même, il se sert des ctags pour récupérer ce qui l’intéresse, comptant ainsi sur un programme qui marche assez bien et auquel on peut résolument faire confiance. Par ailleurs, il utilise neato (qui fait partie de graphviz) pour organiser le tout, donc la sortie est nettement plus lisible. Malheurleusement, j’ai eu beau traffiquer mon ~/.cpp2diarc, dans tous les sens, pas de bol pour moi, les attributs ne sont pas pris en compte (J’ai aussi contacté l’auteur pour lui demander s’il avait une astuce).
• Il reste medoosa, sans doute le plus élaboré des trois, mais non véritablement mieux maintenu que cpp2dia (août 2003 pour la dernière release). Ce programme a été écrit par un thésard, et sait lui aussi produire des sorties assez sexy. L’idée originale est que celui-ci se sert de ccdoc, un utilitaire de documentation à la doxygen, pour générer le graphe. Malheureusement, il faut une vieille version de ccdoc (la 0.7a) pour le faire marcher, et j’ai été incapable de trouver celle-ci en téléchargement (encore une fois, j’ai contacté l’auteur pour lui signaler ce problème, lui conseillant de s’arranger avec les auteurs de ccdoc pour qu’ils remettent une vieille version en ligne, car cela nuit à son programme).

Conclusion : rien de bien convaincant pour l’instant. Cependant, je n’avais pas encore regardé bouml et je viens de voir qu’ils mentionnaient le genre de fonctionnalités que je recherche. Quelqu’un a testé? Ou bien dans le cas général, connaissez-vous un quelque chose capable de faire mon bonheur?