libtthimage/Docs/html/img-devel.html

281 lines
10 KiB
HTML
Raw Normal View History

2022-06-26 02:23:53 +02:00
<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, &quot;&quot;);</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>