[Dcmlib] GDCM commit

[Mathieu Malaterre]

> Le pb crucial est maintenant le Write qui n'est pas dans ctest.
> En python, je faisais la chose suivante:
>   * TestWrite gdcmData/source[i].dcm dest[i].raw
>   * md5 dest[i].raw > md5.sig
>   * comparaison de md5.sig avec une signature calcule'e precedement
>     et valide'e.
> Cela permettait de verifier que la "decompression" + le write fonctionnait
> correctement...
> En C++, je n'ai pas acces a md5 de fac,on portable (Win32). Une ide'e ?

Houla je connaissais meme pas l'astuce pour *nix, je demande autour de moi.

> J'en reve depuis longtemps. Un coding style NOW ! On met tout cela
> par ecrit dans gdcm/DEVELOPPER, et on l'adopte en commun ?

ca marche

> J'ai beaucoup de mal a imposer cela a JPR, et je passe un temps fou a
> nettoyer ce genre de choses (a utiliser ostringstream, puis dbg.Verbose).
> Le pb vient du fait que Jean-Pierre n'utilise pas de debugger et fonctionne
> a coup de printf pour debugger. Ensuite ce code n'est jamais nettoye'.
> Je suis donc entierement d'accord pour interdire les printf et autre
> std::cout, mais cela va poser un gros pb a Jean-Pierre qui DEVRA changer
> ses habitudes de travail... Ceci dit emacs + ESC-X gdb fonctionne tres
> bien, merci.
> Note pour JPR: je peux t'apprendre si tu veux. gdb est a mon avis
>   un outil indispensable au programmeur.

Je dois avouer que je suis flemmard, et la plupart du temps je fais des 
assert mais quand je veux dumper mon algo de creation de tetra, il sont 
dumper en texte dans un fichier log.
Si j'ai bien compris le gdcmDebug, on peut s'en servir comme 
cout/printf, il suffit de rajouter un gdcmDebug(-1) au debut de la 
fonction main. Donc si pars inadvertance on commit tout, il n'y qu'une 
ligne a commenter en debut de test/exemple.

J'ai bon ?

> Pas d'objection. On peut garder le mode VTK en interne au fonctions 
> i.e. conserver des choses du genre

La mode VTK est un peu particuliere, je n'ai pas de probleme avec la 
proposition de Benoit.

> FINALEMENT:
>  * Je propose que l'on ECRIVE un coding style leger mais OBLIGATOIRE.
>  * On passe immediatement en feature freeze.
>  * On ecrit une test suite decente en C++.
>  * On nettoie intensivement le code en se tenant au coding style.
>  * On utilise vraiment gdcm/TODO pour noter ce qui doit-etre fait.
>    Quand quelqu'un traite une entre'e, il le signale dans le TODO
>    pour eviter de ce marcher sur les pieds avec une gueguerre des commits.
> 
> Quand je dis ON, c'est NOUS avec JE !

Je suis pour.

> JPR m'expliquait hier, qu'il existe trois fonctions pour parser les
> pixels. Peut-etre y'a t'il des choses vraiment difficiles...

Pour moi gdcmHeader / gdcmFile sont sans doute les classes les plus 
difficiles a ecrire. Tout ca pour dire que dans mon esprit l'interface 
du reader / writer pourraient etre plus simple.
Pour moi un writer a une methode 'Write' et par defaut il ecrit en 
explicitVR. Ainsi au lieu d'une methode par type d'ecriture on peut 
avoir un flag + une methode Write()


genre:
gdcmFile foo;
foo.SetDicomFlag( GDCM_EX_VR )
foo.Write()


> Ah oui, dans le coding style, il faudrait dire les noms de fonctions,
> et membres sont en Anglais, avec des majuscules et porteurs de semantique.
> Exemple:
>   TotalLength et non lgrTotale
>   NewFile et non "niou" (cf Test/PrintDocument.cxx)
> Note JPR: tu sais comme le provisoire devient definitif...


Tiens j'y avais pas pense a celui la, mais c'est vrai qu'une majuscule 
pour le membre et minuscules pour les variables c'st nettement + simple 
a lire. Dans VTK on utilise en plus this->, mais c'est vraiment trop.

> Soit, mais peut-on faire un typedef et ensuite utiliser le meme non partout
> (genre guint16). Je recommande comme nom celui defini proprement 
> par la norme "ISO C99: 7.18 Integer types" et que l'on trouve dans 
> /usr/include/stdint.h (sous Un*x). Microsoft a adopte' cette norme (reuh,
> reuh, reuh, je tousse tres fort en souriant) et donc a terme il n'y aura
> plus de typedef a faire dans gdcmCommon.h...
> En l'occurence le nom canonique semble etre uint8_t !

Excellent

> Bien que mon experience avec cmake soit encore embryonnaire, voila ce
> que je peux en dire:
>  * cela nous evite de gerer les .dsw a la main: rien que pour cela
>    je suis preneur.
>  * je n'ai jamais eu a editer un makefile generes sous un*x, ce qui
>    prouve que les choses sont propres (alors que sous les autotools,
>    il m'a parfois fallu fouiller pour comprendre mon erreur dans un
>    Makefile.am). Mais peut-etre que sans Mathieu, j'aurais du le faire...
>  * l'interface manuelle me semble moins sympa que des flags en ligne
>    de commande passe's a autogen.sh. A chaque fois que je checkout
>    gdcm, je suis force' de modifier les memes choses a la main.
>    J'ai cru comprendre qu'en copiant le bon fichier on pouvait eviter
>    cela mais je ne sais pas faire...

Ca veut dire que j'ai mal ecris mes fichiers CMake :)
Est-ce que tu peux me dire quels flags est-ce que tu edite a chaque fois ?

>  * ctest me semble une tres bonne chose. Je n'ai pas encore regarde'
>    le lien avec Dart. Je devrais. Je ne sais pas encore comment on
>    fait des assert pour une test suite. Il faut que je regarde
>    Test/ShowDicom pour apprendre.

Dart est pas evident a installe, faut voir si Fabrice est motive pour 
l'installer sur tux.

>  * La gestion de SWIG sera sans doute meilleure dans CMAKE 2.0. 
>    Ceci dit, python/distutils est aussi tres le'ge' pour le support
>    de swig, alors que c'est droit devant avec les autotools.
>    Remarque: le fichier gdcmbin/gdcmPython/gdcm_wrap.cxx n'est pas
>              nettoye' par un make clean. C'est regretable, mais
>              ce n'est sans doute pas une limitation de cmake.
>    Je pense que la passage a swig (patche' certes) dans cable, forcera
>    KitWare a un meilleur support de Swig. Wait and see.
>  * Pour l'instal des libs, cela pose un ch'ti pb avec les pythoneries.
>    En particulier il faut adapater les import pour decliner le nom
>    de la .so ou de la .dll a charger (sous Un*x il y a un prefix de lib
>    et pas sous WIn32). Ceci dit, je pense que cela respecte plus la facon
>    unix de faire, et c'est a nous de nous adapter.

Non c'est clairement un bug dans cmake 1.8.3, si tu utilises cmake 2.0.x 
le fichier est efface par un 'make clean' (cf bug report)

>  * La partie python est encore tes largement pe'te'e et difficilement
>    exploitable. Il faut qu'on y travaille, mais Benoit et moi avons souffert
>    sous Win32 en particulier, a cause de collisions de nom entre les dll et
>    les .py (que veut dire import gdcm quand gdcm.dll et gdcm.py existent
>    alors que sous Un*x cette collisision est evite'e avec libgdcm.so et
>    gdcm.py). Plus la dessus plus tard...

Ok c'est vrai que j'ai pas vraiment jouer avec VC++, j'essai de trouver 
du temps pour l'installer sur mon laptop.

> Un bemol tout de meme: c'est Mathieu qui a ecrit tout les CMakefile
> et je ne suis pas certain que tout seuls les choses aient ete aussi 
> simple... (en particulier je n'ai jamais ouvert la doc de CMAKE pour
> essayer de rajouter une fonctionalite': une chose est sure, la doc
> des autotools n'est pas triviale...).
> 
>    Courage Jean-Pierre: il n'y rien de plus dur a bouger que les esprits.
> 	Frog.
> 

Mathieu

Ps: si tous le monde est d'accord (Fabrice aussi) je peux commiter les 
meme scirpt que VTK, du genre:
- Interdit les commit contenant des 'tabs'
-                                    '^M'
-                                   '<<<<<<'
- Verifie que la derniere ligne a un '\n'

Fabrice, si tu veux voir a quoi ressemble ce scritp ils sont dans 
VTK/CVSROOT:

cd VTK
cvs co CVSROOT

@+
Mathieu