281 lines
10 KiB
HTML
281 lines
10 KiB
HTML
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<title>libimage: les regles du programmeur</title>
|
|
<link rel="stylesheet" type="text/css" href="libimage.css">
|
|
<meta name="generator" content="Cuisse de Pintade à l'ail, Riz, Morgon">
|
|
<meta name="keywords" content="libimage, coding style, Boudet, tontonth">
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<h1><a name="top">en vrac pour les codeurs...</a></h1>
|
|
|
|
<p align="center"><tt>dernière mise à jour: 3 janvier 2014</tt></p>
|
|
|
|
<p class="menuhaut">
|
|
[<a href="README.txt">README</a>]
|
|
[<a href="image77.html">fortran</a>]
|
|
[<a href="img-essais.html">essais</a>]
|
|
[<a href="#porting">porting</a>]
|
|
<br>
|
|
[<a href="#bugs">bugs</a> et <a href="BUGS.txt">BUGS</a>]
|
|
[<a href="#projets">projets</a>]
|
|
[<a href="#compilation">compilation</a>]
|
|
[<a href="#types">types</a>]
|
|
[<a href="#return">return codes</a>]
|
|
<br>
|
|
[<a href="#lacunes">les manques</a>]
|
|
[<a href="#optimize">Optimisations</a>]
|
|
[<a href="#outils">outils divers</a>]
|
|
</p>
|
|
|
|
<h2><a name="utsl">Use the sources, Luke</a></h2>
|
|
|
|
<p>
|
|
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
|
|
<i>vrac</i>...
|
|
</p>
|
|
|
|
<p>
|
|
On peut <a href="img-marquage.html">marquer</a> une image.
|
|
Il existe quelques <a href="#macros">macros</a> pour abstraire
|
|
certaines choses, mais ce n'est pas très fini.
|
|
</p>
|
|
|
|
<h2><a name="bugs">les bugs</a></h2>
|
|
|
|
<p>
|
|
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:
|
|
</p>
|
|
<pre class="code">
|
|
foo = Image_alloc(bla...);
|
|
Image_tripote(foo, bar);
|
|
Image_DeAllocate(foo);
|
|
free(foo); <b>/* ne pas oublier ça... */</b>
|
|
</pre>
|
|
<p>
|
|
A ce moment, les zones mémoires contenant les pixels de l'image sont rendues
|
|
au gestionnaire de mémoire, <b>mais</b> l'en-tête du descripteur d'image est
|
|
encore <i>malloc-é</i>. Il convient donc de rajouter un <tt>free(foo)</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
<b>Xv n'affiche pas les TGA fabriqués par Libimage ?</b>
|
|
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 <i>workaround</i> est simple:
|
|
il faut ajouter <tt>Image_set_comment(img, "");</tt> avant
|
|
d'enregistrer le fichier afin d'enlever le commentaire.
|
|
Je pense même qu'il y a un truc dans le Makefile.
|
|
</p>
|
|
|
|
<p><b>le flag 'modified' du descripteur d'image est mal géré.</b>
|
|
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.</p>
|
|
|
|
<p>
|
|
Par contre, le fait que certaines fonctions ne semblent pas finies n'est
|
|
<i>pas</i> un bug. C'est un 'undocumented feature'. Et qu'il manque la
|
|
documentation, c'est le <i>lazzy effect</i>.
|
|
</p>
|
|
|
|
|
|
<h2><a name="projets">les projets</a></h2>
|
|
|
|
<p>
|
|
Début 2007, j'ai découvert que le compilateur <tt>g77</tt> était un
|
|
produit en fin de vie, et que les Linux récents avaient de plus en plus
|
|
tendance à préférer <tt>gfortran</tt>. Il est donc probable que
|
|
<a href="image77.html">l'interface</a> actuelle soit mise à l'écart
|
|
et remplacée par un équivalent plus moderne.
|
|
</p>
|
|
|
|
<h2><a name="porting">le portage</a></h2>
|
|
|
|
<p>
|
|
Merci au généreur donateur d'une <i>Sun U5</i> grace auquel j'ai enfin pu
|
|
finaliser l'adaptation
|
|
du machin à une autre architecture que le trop commun <i>i386</i> sous Linux,
|
|
en l'occurence un processeur <i>UltraSparc</i>, tournant sous <i>OpenBSD 4.4</i>.
|
|
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.
|
|
</p>
|
|
<p>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 <a href="http://dinorama.fr/">dino</a>),
|
|
et que le Gcc est également *vieux* :
|
|
<tt>gcc version 4.0.3 (Debian 4.0.3-1)</tt>. 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é:
|
|
</p>
|
|
|
|
<dl>
|
|
|
|
<dt><tt>alloca.h</tt>
|
|
<dd>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
|
|
<tt>CC_HACKS=-DNEED_ALLOCA_H</tt>.
|
|
</dd>
|
|
|
|
<dt>L'emplacement des <tt>.h</tt></dt>
|
|
<dd>Par flemme de chercher une autre solution, je les place systématiquement
|
|
dans <tt>/usr/local/include</tt>, et le Gcc de l'Open44 ne va pas les
|
|
chercher à cet endroit là.
|
|
Tip: <b><tt>export C_INCLUDE_PATH=/usr/local/include</tt></b>
|
|
dans le <tt>~/.profile</tt>.
|
|
</dd>
|
|
<dt>L'emplacement des <tt>.a</tt> et <tt>.so</tt>
|
|
<dd>Même Gcc, même punition. Après quelques essais rapidement désastreux avec
|
|
le <tt>ld.so.conf</tt>, une lecture plus attentive des manpages m'a conduit
|
|
à une (presque) même solution:
|
|
<b><tt>export LIBRARY_PATH=/usr/local/lib</tt></b> dans le même
|
|
<tt>~/.profile</tt>.
|
|
</dd>
|
|
|
|
</dl>
|
|
<p>
|
|
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 <a href="img-outils.html#porting">bon</a> chemin.
|
|
</p>
|
|
|
|
<h2><a name="optimize">Optimisations</a></h2>
|
|
|
|
<p>À priori, il reste pas mal de choses à faire, surtout pour rendre les
|
|
boucles X-Y plus <i>cache-friendly</i>. Les buffers contenants les images
|
|
étant organisés en tableaux de lignes, il y a probablement quelques
|
|
<i>hit/mess</i> à grapiller. D'un autre coté, pour le moment, juste
|
|
ça marche...
|
|
</p>
|
|
|
|
<h2><a name="path">chemins de recherche</a></h2>
|
|
|
|
<p>
|
|
Bah, fatigué de devoir recopier mes fichiers .MAP de
|
|
<a href="img-couleurs.html#palettes">palette</a> à droite et à gauche,
|
|
j'ai ajouté une func qui cherche dans quelques endroits. Donc, j'essaye
|
|
en série:
|
|
</p>
|
|
|
|
<ol>
|
|
<li> le répertoire courant.
|
|
<li> le rep dans la variable <tt>$LIBIMAGE_PATH</tt>
|
|
<li> le chemin <i>hardcoded</i>: $(DESTDIR)/share/libimage
|
|
</ol>
|
|
|
|
<h2><a name="compilation">compilation</a></h2>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
En attendant, les variables à positionner pour l'install sont:
|
|
</p>
|
|
|
|
<ul>
|
|
<li><tt>DESTDIR</tt>: /usr/local
|
|
<li><tt>HTML_DIR</tt>: /usr/local + le répertoire html recevra les pages
|
|
que vous êtes en train de lire.
|
|
<li><tt>SHARED_FILES</tt>: $(DESTDIR)/share/libimage contiendra les fichiers
|
|
de fontes et les colors maps.
|
|
</ul>
|
|
|
|
<p>
|
|
A la compilation, on peut aussi utiliser quelques <tt>-DMACHIN=42</tt>
|
|
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:
|
|
<i>plotter</i> en dehors de l'image. Donc, avec un <tt>-DABORT=1</tt>,
|
|
les conditions anormales génererons un <small>COREDUMP</small> analysable
|
|
avec gdb, si vous n'avez pas oublié de régler votre <tt>ulimit -c</tt>
|
|
à une valeur raisonnable.
|
|
</p>
|
|
|
|
<p><b>alloca.h</b> 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 <tt>alloca</tt>. (2007-12-30) investigations
|
|
en cours. Sans compter que le problème va se poser aussi avec NetBSD.
|
|
</p>
|
|
|
|
<h2><a name="types">type de données</a></h2>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<ul>
|
|
<li><b>pr100</b> Seuil de probabilité pour un choix randomatique. Une valeur
|
|
comprise entre 0 et 99. Exemple: le
|
|
<a href="img-povhf15.html#bruit">bruitage</a> des HFs.
|
|
</ul>
|
|
|
|
<p>Les hackeurs trouveront dans le fichier <tt>imprime.c</tt> une fonction :
|
|
<i>Image_print_sizeof_structs</i>, qui affiche les tailles des diverses
|
|
structures utilisées par les rouages internes.
|
|
</p>
|
|
|
|
<h2><a name="return">return codes</a></h2>
|
|
|
|
<p>
|
|
Il faut regarder les <i>#define</i> dans <tt>tthimage.h</tt> et la fonction
|
|
<a href="libimage.html#messages">Image_err2str</a> dans <tt>msglib.c</tt>.
|
|
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é.
|
|
</p>
|
|
|
|
<h2><a name="macros">macros</a></h2>
|
|
|
|
<p>
|
|
Elles sont habilement dissimulées dans le fichier <tt>tthimage.h</tt>, mais
|
|
je ne leur porte qu'une confiance limitée.
|
|
</p>
|
|
|
|
<h2><a name="outils">Les outils</a></h2>
|
|
|
|
<p>
|
|
Deux dumpeurs de pixels dans <tt>dumppix.c</tt>. 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
|
|
<a href="img-outils.html">package</a> qui contient quelques <i>tools</i>
|
|
assez performants.
|
|
</p>
|
|
|
|
<p class="HDP"><a href="#top">haut de page</a></p>
|
|
|
|
<h2><a name="lacunes">Ce qui manque...</a></h2>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<!-- ------------------------------------------------ -->
|
|
<p class="footer">
|
|
Bon courage à tous, et n'oubliez pas de regarder
|
|
<a href="http://la.buvette.org/cv.html">qui</a> a pondu ce kluge,
|
|
et en est presque fier...
|
|
</p>
|
|
|
|
</body>
|
|
</html>
|