Odyce et bibliothèques
clipper
J'ai un petit soucis concernant l'utilisation d'Odyce :
j'essaye d'utiliser la bilioth�que de clipping de polygones GPC
(http://www.cs.manchester.ac.uk/~toby/alan/software/). je l'ai d�j�
utilis�e sans probl�mes dans un programme C. l'int�gration est a priori
simple, puisque il y a juste un include gpc.h
j'ai donc mis
#include "gpc.h"
dans critcl::ccode
A l'execution cependant, j'ai une erreur d'Odyce sur la premi�re
utilisation d'une des fonctions d�finies par gpc.h.
Comment doit on inclure les fichiers h non standard pour qu'ils soient
pris en compte par Odyce ?
Merci
--
Clipper, TCL + C, c'est de la bombe !
Eric Hassold
> Salut ďż˝ tous
>
> J'ai un petit soucis concernant l'utilisation d'Odyce :
> (http://www.cs.manchester.ac.uk/~toby/alan/software/). je l'ai d�j�
> utilis�e sans probl�mes dans un programme C. l'int�gration est a priori
>
> j'ai donc mis
> #include "gpc.h"
>
> dans critcl::ccode
>
> utilisation d'une des fonctions d�finies par gpc.h.
>
> Comment doit on inclure les fichiers h non standard pour qu'ils soient
> pris en compte par Odyce ?
>
> Merci
>
Sous quelle architecture ? quel O.S. ? avec quelle version de Odyce (ou
eTcl) ? Et surtout quelle erreur est rapportee ?
Je n'utilise pas la libraririe GPC, mais comme elle ne se compose que
d'un simple fichier .c et de ses declarations dans le .h associe, j'ai
rapidement fait un essai avec le code suivant, qui valide la
compilation. Il faut bien sur non seulement inclure le "gpc.h", mais
aussi compiler le "gpc.c", pour que son API soit definie (et non juste
declaree). Pour une "demo" (Tk n'est utilise que pour la console, sous
Win32), ce code semble marcher:
set thisdir [file dirname [file normalize [info script]]]
package require critcl
puts "Compilation"
critcl::ccode {
#include <stdio.h>
#include <math.h>
#include "gpc.h"
}
critcl::csources [file join $thisdir gpc.c]
::critcl::ccommand toto {dummy interp objc objv} {
Tcl_SetObjResult(interp,Tcl_NewIntObj(sizeof(gpc_polygon)));
return TCL_OK;
}
puts "sizeof(gpc_polygon) = [toto]"
tkwait window .
exit
sous Win32, ca compile bien le code dans gpc.c, comme l'atteste le
sizeof() utiliser dans la fonction absurde "toto". A priori, vous
devriez donc pouvoir utiliser l'API de cette librairie, a partir de la
version compilee au vol par Odyce, dans le code que vous souhaitez dans
votre commande ccommand, ou tout autre code C dans des sections
critcl::ccode additionnelles.
Ca, c'est pour l'approche compatible critcl. Sinon, les appels direct de
l'API Odyce permettent un meilleur controle des codes compiles, et du
moment ou ils le sont, mais dans ce cas simple (un seul fichier C),
probablement inutile.
Eric
clipper
> clipper a �crit :
>> Salut � tous
>>
>> J'ai un petit soucis concernant l'utilisation d'Odyce :
>> (http://www.cs.manchester.ac.uk/~toby/alan/software/). je l'ai d�j�
>>
>> j'ai donc mis
>> #include "gpc.h"
>>
>> dans critcl::ccode
>>
>> utilisation d'une des fonctions d�finies par gpc.h.
script marche aussi sous Linux, pour un ami. Effectivement, tout va
mieux quand on compile le source avant d'appeler les fonctions.
2 petites questions cependant encore sur Odyce
Y'a-til un moyen de r�cup�rer stdout et stderr dans le code TCL ?
Qu'elle est la limite en m�moire pour Odyce ?
Mon programme sert � "clipper" (j'adore !) un fichier comprenant un
grand nombre de polygone (ligne de cote mondiale) pour en faire une
carte locale. j'utilise les fichiers de donn�es du gshhs, qui existent
en 5 pr�cisions. Pour les 4 premiers niveaux de pr�cision (fichiers
respectivement de 193, 1399, 8067 et 37 520 ko) le programme se termine
correctement. Pour le dernier niveau (fichier de 204462 ko) le programme
se termine mais sans r�sultat. En checkant pendant l'utilisation avec le
gestionnaire de programme, on voit que �a mouline, avec une consommation
m�moire qui augmente. Puis tout s'arr�te.
--
Clipper, qui clippe les polygones.
Eric Hassold
Ils sont rediriges vers les channels stdin et stdout de Tcl. C'est a
dire que sous Windows par exemple, les affichages sur stdout devraient
s'afficher dans la console (a condition de l'avoir rendue visible par un
[console show])
> Mon programme sert � "clipper" (j'adore !) un fichier comprenant un
> grand nombre de polygone (ligne de cote mondiale) pour en faire une
> carte locale. j'utilise les fichiers de donn�es du gshhs, qui existent
> en 5 pr�cisions. Pour les 4 premiers niveaux de pr�cision (fichiers
> respectivement de 193, 1399, 8067 et 37 520 ko) le programme se termine
> correctement. Pour le dernier niveau (fichier de 204462 ko) le programme
> se termine mais sans r�sultat. En checkant pendant l'utilisation avec le
> gestionnaire de programme, on voit que �a mouline, avec une consommation
> m�moire qui augmente. Puis tout s'arr�te.
Ca plante apres etre monte a quel niveau de conso memoire ?
Les references a malloc(), free(), etc... sont mappees sur Tcl_Alloc(),
Tcl_Free(), etc... Il n'y a pas a proprement parle de limite specifique
donc, hormis celle du bianire Tcl lui meme (et bien sur celle de l'OS,
d'autant qu'on est en 32 bits).
A noter quand meme, la compilation du code C effectuee est moins
optimisee que celle effectuee par un "vrai" compilateur. Dans la
majorite des cas, le gain obtenu est deja tellement significatif par
rapport a un code Tcl pur que cela est negligeable. Mais dans ce cas
precis (ou dans tout code dont le temps de traitement est tres long), ca
peut quand meme valoir le coup de basculer vers une precompilation. Pour
info, vous devriez pouvoir generer un .o a partir du code C (par exemple
avec un gcc -O4 sous linux), et utiliser le meme .o ainsi obtenu, aussi
bien sous Win32 que Linux (une autre magie de Odyce). Ne pas generer un
.so ou un .dll, juste un .o (ou .obj sous Win32), la "relocation" se
fera a la volee dans Odyce. Pour faire cela, il faudra cependant
attaquer directement par Odyce et non par l'emulation critcl (et oui, ca
manque de documentation, mea culpa :p).
Eric
clipper
Merci
A ce propos, o� trouver la documentation d'Odyce. Je ne la trouve pas
sur le site d'evolane, et il n'y a que quelques exemples sur les wiki.
j'ai aussi fouiller le r�pertoire evolane dans Program Files, mais je
n'ai rien vu.
En terme de m�moire, cela montait � environ 300 Mo mais je n'�tais pas
en train de regarder au moment o� le programme a stopp�.
Je pense que ce n'est pas un probl�me de compilation puisque le code est
le m�me qu'il s'agisse du fichier faible r�solution ou du fichier haute
r�solution. C'est vraiment � mon avis � l'ex�cution de la fonction de
clipping elle-m�me qu'il se passe quelque chose de bizarre. Cela dit, je
n'ai pas encore r�essay�.
--
Clipper, sur les chemins hasardeux de la compilation dynamique
clipper
Hum, c'est assez �trange, en suivant l'ex�cution du programme avec le
gestionnaire de programme de Windows XP (32 bits), le programme
s'�vanouit d'un coup, aux alentours de 370 000 ko d'utilisation m�moire,
ce qui je trouve n'est pas si �norme que �a.
--
Clipper
Kroc
--
David Zolli