en vrac pour les codeurs...

dernière mise à jour: 3 janvier 2014

Use the sources, Luke

La documentation n'étant jamais à jour, il faut parfois aller lire les sources pour comprendre (parfois) le pourquoi du comment. Moi même, je n'y arrive pas toujours. Cette page me sert d'aide mémoire, donc c'est tout en vrac...

On peut marquer une image. Il existe quelques macros pour abstraire certaines choses, mais ce n'est pas très fini.

les bugs

Il y en a probablement pas mal, mais dans l'ensemble, c'est assez stable. Peut-être quand même quelques petits 'memory leak' qui trainent dans des recoins obscurs... Exemple:

           foo = Image_alloc(bla...);
           Image_tripote(foo, bar);
           Image_DeAllocate(foo);
           free(foo);        /* ne pas oublier ça... */

A ce moment, les zones mémoires contenant les pixels de l'image sont rendues au gestionnaire de mémoire, mais l'en-tête du descripteur d'image est encore malloc-é. Il convient donc de rajouter un free(foo).

Xv n'affiche pas les TGA fabriqués par Libimage ? Le bug n'est pas dans libimage, mais dans Xv. D'après les spécifications du format TGA, on peut ajouter un commentaire dans le fichier. Or, Xv ne reconnait plus les TGA comme des TGA si ce commentaire est présent, ce qui est le cas par défaut dans la bib. Le workaround est simple: il faut ajouter Image_set_comment(img, ""); avant d'enregistrer le fichier afin d'enlever le commentaire. Je pense même qu'il y a un truc dans le Makefile.

le flag 'modified' du descripteur d'image est mal géré. Oui, en effet, il n'est parfois pas positionné par les fonctions qui le devrait. Une revue complète de tout le code pour corriger ce souci est programmée pour 2012.

Par contre, le fait que certaines fonctions ne semblent pas finies n'est pas un bug. C'est un 'undocumented feature'. Et qu'il manque la documentation, c'est le lazzy effect.

les projets

Début 2007, j'ai découvert que le compilateur g77 était un produit en fin de vie, et que les Linux récents avaient de plus en plus tendance à préférer gfortran. Il est donc probable que l'interface actuelle soit mise à l'écart et remplacée par un équivalent plus moderne.

le portage

Merci au généreur donateur d'une Sun U5 grace auquel j'ai enfin pu finaliser l'adaptation du machin à une autre architecture que le trop commun i386 sous Linux, en l'occurence un processeur UltraSparc, tournant sous OpenBSD 4.4. Et ça a été plus facile que je ne le pensait, les soucis de boutisme ayant déja été réglés dans une vie antérieure. D'autre part, ça a été une bonne occasion de nettoyer le code d'un certain nombre de warnings assez génants.

Je dois d'abord préciser que la fidèle machine sur laquelle je fabrique le kluge est une très vieille Debian (une SID d'il y a cinq ans, c'est dire si je suis un dino), et que le Gcc est également *vieux* : gcc version 4.0.3 (Debian 4.0.3-1). C'est un peu génant, mais pas plus que si j'avais un Unixware 1.x :) Donc, en avant... Voyons, dans un ordre approximatif, les problèmes que j'ai rencontré:

alloca.h
Sur la machine ancestrale citée plus haut, je suis obligé d'inclure ce fichier si je veux utiliser la fonction alloca. Mais ce n'est pas nécessaire dans O44/sparc64. Je n'ai pas (pour le moment) trouvé de solution automatique. Il vous faut donc éditer à la mano le Makefile vers la ligne 31 et commenter la ligne CC_HACKS=-DNEED_ALLOCA_H.
L'emplacement des .h
Par flemme de chercher une autre solution, je les place systématiquement dans /usr/local/include, et le Gcc de l'Open44 ne va pas les chercher à cet endroit là. Tip: export C_INCLUDE_PATH=/usr/local/include dans le ~/.profile.
L'emplacement des .a et .so
Même Gcc, même punition. Après quelques essais rapidement désastreux avec le ld.so.conf, une lecture plus attentive des manpages m'a conduit à une (presque) même solution: export LIBRARY_PATH=/usr/local/lib dans le même ~/.profile.

Bon, j'ai gruiké ça rapidement un dimanche pluvieux, ça marche mais ça n'est peut-être pas orthodoxe. Je vais consulter les experts en fromages pour savoir si j'ai pris le bon chemin.

Optimisations

À priori, il reste pas mal de choses à faire, surtout pour rendre les boucles X-Y plus cache-friendly. Les buffers contenants les images étant organisés en tableaux de lignes, il y a probablement quelques hit/mess à grapiller. D'un autre coté, pour le moment, juste ça marche...

chemins de recherche

Bah, fatigué de devoir recopier mes fichiers .MAP de palette à droite et à gauche, j'ai ajouté une func qui cherche dans quelques endroits. Donc, j'essaye en série:

  1. le répertoire courant.
  2. le rep dans la variable $LIBIMAGE_PATH
  3. le chemin hardcoded: $(DESTDIR)/share/libimage

compilation

La première chose à faire (comme d'hab) c'est d'aller lire le Makefile. Vous y découvrirez quelques options à positionner selon vos gouts. Et un de ces jours, je vais passer au tandem infernal automake/autoconf, si jamais j'arrive à comprendre comment ça marche.

En attendant, les variables à positionner pour l'install sont:

A la compilation, on peut aussi utiliser quelques -DMACHIN=42 pour modifier le comportement de la bib. En phase de mise au point de la bibliothèque, il est capital de détecter les conditions anormales: eg: plotter en dehors de l'image. Donc, avec un -DABORT=1, les conditions anormales génererons un COREDUMP analysable avec gdb, si vous n'avez pas oublié de régler votre ulimit -c à une valeur raisonnable.

alloca.h oui, là, il y a un léger souci. je suis en ce moment en train de tenter d'installer ma libimage dans un OpenBSD, et je ne sais pas quoi faire pour les alloca. (2007-12-30) investigations en cours. Sans compter que le problème va se poser aussi avec NetBSD.

type de données

Bien que tout ce fatras soit codé à la gruik, j'essaye d'introduire un peu de rigueur dans la chose. En particulier, certains noms de paramètres de fonctions vont être normalisés. Ce qui, en fait, ne sert à rien, parce que c'est le codeur qu'il faudrait normaliser.

Les hackeurs trouveront dans le fichier imprime.c une fonction : Image_print_sizeof_structs, qui affiche les tailles des diverses structures utilisées par les rouages internes.

return codes

Il faut regarder les #define dans tthimage.h et la fonction Image_err2str dans msglib.c. Je préfère ne rien mettre ici, parce que j'aurais la flemme de le mettre à jour quand il faudrait le faire... En particulier pour classer les codes d'erreur en fonction de leur gravité.

macros

Elles sont habilement dissimulées dans le fichier tthimage.h, mais je ne leur porte qu'une confiance limitée.

Les outils

Deux dumpeurs de pixels dans dumppix.c. Le premier affiche des trucs en hexadécimal, et le second en ascii. Ne m'en demandez pas plus, je ne suis au courant de rien. Heureusement, il y a un autre package qui contient quelques tools assez performants.

haut de page

Ce qui manque...

Il manque plein de choses dans cette bibliothèque de fonctions, ou dans les outils qui tournent autour. En Octobre 2003, je suis en train de travailler sur un éditeur de fontes 16x24, mais il ne sortira que quand il sera prèt. Nous sommes le 1er janvier 2014, et ça n'a pas avancé d'un pas.