Hello planet libre,

J’ai codé une application android pour recevoir des notifications de son téléphone. Le principe est simple: vous créez un compte jabber pour votre appareil et vous l’inscrivez dans vos amis gtalk (vérifiez que ça marche avec pidgin/empathy en vous envoyant un message). Puis vous installez l’application sur votre appareil et vous la configurez comme il faut en réglant les champs “login compte jabber téléphone”/”mot de passe compte jabber téléphone”/”adresse gmail à notifier”. Vous démarrez alors le service et votre téléphone vous transmet les sms qu’il reçoit et vous notifie des appels de vos correspondants. J’avoue que ça n’est pas d’une utilité fantastique, mais j’aime bien être notifié de tout et n’importe quoi sur mon ordinateur, et ce genre de notifications me manquait. Je prévois de rajouter de petites fonctionnalités comme la possibilité de répondre aux sms quand j’aurai un peu de temps. Évidemment le code est libre (LGPL, même, puisque google code ne connait pas la WTFPL ). N’hésitez pas à me laisser des commentaires gentils. L’url du projet:

https://code.google.com/p/talkmyphone/

PS: Je ne garantis pas que ça marche sur votre téléphone. J’ai fait ça sur mon temps libre, pour le fun, et je ne compte pas y passer des nuits blanches. Mais je regarderai les rapports de bug s’il y en a…

Qui n’a jamais perdu par erreur une compilation, une session ssh ou une fenêtre irssi en fermant une console par inadvertance, à cause d’un lag réseau, ou bien à cause d’un redémarrage brutal de X11? Les outils présentés ici permettent de vous affranchir de ce genre de problème.

dtach est un petit programme bien pratique qui sert à détacher un programme de la console où celui-ci tourne. De manière simple, ça veut dire que si on quitte le terminal dans lequel on a lancé le programme détaché, on pourra par une courte commande récupérer ce programme. Exemple, la commande suivante permet de lancer le programme irssi en détaché, sur le socket /tmp/irssi.sock (qui sera créé par le programme), où, s’il est déjà lancé, de récupérer ce programme.

dtach -A /tmp/irssi.sock /usr/bin/irssi

J’en connais des tas qui ne jurent que par gnu screen. Mais  à quoi bon, si on peut se contenter d’un simple alias?

alias irssi='dtach -A /tmp/irssi.sock /usr/bin/irssi'

Jusque là, je me contentais de deux ou trois alias du genre, et j’avais une petite fonction au début de mon .zshrc qui me permettait de toujours lancer mon shell en détaché. Cependant, tout ceci manquant de souplesse, je me suis intéressé à screen et à ses alternatives, et je dois dire que je trouve tmux vraiment propre. Je mets de côté tous les aspects de coupage d’écran en deux, onglets et tutti quanti, qui  sont plus ou moins inutiles quand on utilise un vrai window manager. Si screen et tmux peuvent tous deux ouvrir un nombre illimité de sessions (screen pouvant, si j’ai bien compris, ouvrir jusqu’à 10 fenêtres au sein de la même session), tmux offre un mécanisme pour alterner entre différentes sessions que j’ai cherché en vain dans screen (je vois d’ici les ardents défenseurs de leur programme favori venir me crucifier dans les commentaires: tant pis, si ça existe, j’assume ma mauvaise lecture des pages de manuel). Dans tmux, avec la configuration par défaut, un simple CTRL-b suivi de s montre une liste à choix des sessions ouvertes (attachées ou détachées) et il suffit alors de selectionner une entrée pour que tmux se connecte à ladite session (et si vous aimez couper l’écran en deux et mettre plusieurs fenêtres dans la même session, vous pouvez, sans limitation de nombre).

Voici quelques lignes que j’ai rajoutées au début de mon .zshrc: elles garantissent qu’une nouvelle session tmux est toujours lancée avec le shell. La fermeture de la session en cours entraine l’essai de connection à une autre session, sauf s’il n’y a plus aucune session de lancée.

# TMUX
# if no session is started, start a new session
if test -z ${TMUX}; then
tmux
fi
# when quitting tmux, try to attach
while test -z ${TMUX}; do
tmux attach || break
done


Et désormais je lance irssi de la manière suivante:

# IRSSI IN TMUX
# switch to irssi session (and if necessary starts this session before)
irssi()
{
if tmux has -t irssi >/dev/null; then
tmux switch -t irssi
else
TMUX="" tmux new -d -s irssi /usr/bin/irssi
tmux switch -t irssi
fi
}


Si vous utilisez zsh et/ou urxvt, et que vous souhaitez tenter l’essai, je vous suggère de jeter un coup d’oeil à ma configuration (les problèmes de couleurs et de scrolling y sont réglés). À noter qu’il existe d’autres alternatives à gnu screen, dont le très prometteur neercs, qui permet entre autre de détacher des programmes qu’on avait oublié de lancer dans neercs.

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…