Lua-interface...

[Pixel]

Bon, il semblerait (au moins 2! whoohoo!) que des gens commencent à se poser la question de comment développer des plugins pour lua-interface. C'est pas forcément une simple affaire, vu que je développe principalement sous linux, mais je vais au moins décrire une façon de faire "windows". Mais je préviens, c'est assez "usine à gaz".


Déjà, il vous faut msys / mingw32, et msysgit. Lors de l'installation de msysgit, spécifiez la troisième option pour les fins de lignes; en clair, vous voulez pas que msysgit touche aux fins de ligne du tout. Il vous faudra aussi gnuwin32, installé dans le path de la machine. En clair:






Ouvrez un shell git dans votre répertoire de travail, (clic droit, hm), et tapez les commandes suivantes:

Code : Tout sélectionner

git clone http://git.grumpycoder.net/Baltisot
git clone http://git.grumpycoder.net/PSX-Bundle
git clone http://git.grumpycoder.net/lua-interface
git clone http://git.grumpycoder.net/lua-modules
git clone http://git.grumpycoder.net/lua-modules-cd-tool
git clone http://git.grumpycoder.net/mogltk

Ensuite, dans un shell msys, allez dans le répertoire de travail, et faites:

Code : Tout sélectionner

wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/bin2c.c
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/Mesa-7.0.3-osmesa-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/freetype-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/ftgl-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/gnuwin32-digested.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/libreadline-static.a.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/mysql-5.0.51b-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/pthreads-w32-2-8-0-release-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/tinyxml-src.tar.gz
gcc -o bin2c.exe bin2c.c
mkdir -p /usr/local/bin
mv bin2c.exe /usr/local/bin
tar xvfz Mesa-7.0.3-osmesa-win32-precomp.tar.gz
tar xvfz freetype-win32-precomp.tar.gz
tar xvfz ftgl-win32-precomp.tar.gz
tar xvfz gnuwin32-digested.tar.gz
gunzip libreadline-static.a.gz
tar xvfz mysql-5.0.51b-win32-precomp.tar.gz
tar xvfz pthreads-w32-2-8-0-release-win32-precomp.tar.gz
tar xvfz tinyxml-src.tar.gz

De là, vous aurez tous les sources nécessaires à la compilation du bouzin.

Donc:

Code : Tout sélectionner

cd Baltisot/lib
./genloadlib.sh > loadlualibs.ii
cd ../../lua-interface
make -f Makefile.mingw32 luac.exe
make -f Makefile.mingw32
cd ../lua-modules
cp ../lua-interface/luac.exe .
make -f Makefile.mingw32
cd ../lua-modules-cd-tool
make -f Makefile.mingw32

*oof*

Logiquement, si tout s'est bien passé, vous avez à peu près lua-interface, et tout ce qu'il faut pour développer des plugins pour lui.

La compilation de http://static.grumpycoder.net/pixel/VP/lua-modules-vp/ est laissée en exercice au lecteur.

--edit--

J'oubliais: ça, c'est pour pouvoir *publier* des dlls compatibles avec ma distribution de lua-interface. Mais la solution visual studio express 2008 qui est présente dans le répertoire lua-interface devrait marcher proprement pour faire du dev. Il faut http://static.grumpycoder.net/pixel/lua ... -win32.zip en plus par contre, et beaucoup de fonctionnalités ne seront pas dispo, mais pour l'usage de base de lua-interface, ça devrait tenir.

[Pixel]

Et sous la suggestion de Bahabulle, j'ai fait une version "light" du software. Le packaging doit probablement manquer quelques dlls, mais ça a l'air de marcher:

http://static.grumpycoder.net/pixel/lua ... -win32.zip


La plupart des modules sont intégrés directement à la dll principale, et j'ai pas activé les modules graphiques et SQL du tout. Le module "cd" est toujours à part pour des raisons de cohésion du code. Tous les plugins développés pour la version full devraient marcher pour la version light aussi.

[Pixel]

Bon... je sais plus trop quelle mouche m'a piqué, c'est parti depuis un délire sur je ne sais plus quoi... bref. Toujours est-il que j'ai rajouté une UI à lua-interface. Enfin, un support pour une UI.

En gros, j'ai joué au boucher avec la librairie IUP (http://www.tecgraf.puc-rio.br/iup/) et j'en ai fait un module pour lua-interface. Les fonctionnalités sont présentes à environ 80%. J'ai giclé tout ce qui prenait de la place, comme le support freefont, jpeg, avi, plot, et la librairie d'icônes built-in.

Bref, c'est compatible Windows, linux, OSX, et c'est présent dans les dernières versions des packages.

Voilà un exemple de ce qu'on peut faire:

http://static.grumpycoder.net/pixel/luapatcher.lua

Ce qui s'affiche comme ceci:

sshot-lua-patcher.png (25 Kio) Consulté 10452 fois

Le multi-threading est aussi géré proprement, comme le prouve cet exemple: http://static.grumpycoder.net/pixel/test-iup.lua


Bref, voilà voilà.

--edit--

Juste pour le fun, voilà ce que ça donne sous linux:

lua-patcher-linux.png (6.03 Kio) Consulté 10383 fois

[Ti Dragon]

Quel homme !

Faut que je pense à inclure tout ça sur la T.R.A.F, moi... Chuis *un peu* à la bourre.

- Edit -
Evidemment, compte tenu de la taille du fichier et des protections, je ne peux pas mettre la version Win sur le site Je lie au tiens, du coup

[Pixel]

Bon et vu que je suis dans la série des délires, je suis en train de sortir la version 0.8. La grosse différence c'est que je viens d'inclure LuaJIT 2.0-beta1 dans le bouzin. Ça m'a pris un peu de temps, mais ça semble tourner.

Logiquement, tout devrait fonctionner comme avec les versions précédentes. Maintenant, toute la VM Lua a été changée. C'est censé être 100% identique à l'ancienne, juste en beaucoup plus rapide, mais après...


Donc si Jes et Bahabulle pouvaient tester un peu pendant que je vais prendre quelques heures de sommeil; je sais que Jes a essayé dernièrement le patch MMX4 - le réessayer avec cette nouvelle version pourrait être intéressant, surtout de comparer le temps que ça met (si ça marche). Et pour Baha, pareil: j'aimerais bien savoir ce que ça donne avec ToD.

Cette nouvelle version est située ici: http://static.grumpycoder.net/pixel/lua-jit/ - je la déplacerai à l'endroit habituel dès qu'il y aura eu assez de tests pour confirmer que ça marche bien. De plus ça permet d'avoir toujours l'ancienne version sous la main pour pouvoir comparer les temps d'exécutions. J'ai quelques applis au boulot qui utilisent lua-interface et qui sont assez gourmands en CPU et en features. Je ferai les gros tests d'intégrité cette semaine.

--edit--

Et vu que Baha est encore une fois parti en coup de vent, j'ai trouvé le bug qui l'affectait dans son pcall, et je l'ai corrigé dans la dernière version.


--edit2--

Et concernant les performances, je me suis amusé à relancer le script pour dumper entièrement VP.

Avant:
real 12m29.977s
user 5m19.124s
sys 6m18.820s

Après:
real 10m14.160s
user 3m18.476s
sys 6m11.787s


L'utilisation mémoire était identique. Bon score au final, même si c'est les I/O qui prennent le plus de temps.

[BahaBulle]

Et vu que Baha est encore une fois parti en coup de vent, j'ai trouvé le bug qui l'affectait dans son pcall, et je l'ai corrigé dans la dernière version.

T'avais qu'à pas me violenter et répondre avant

J'ai pas chronométré de façon aussi précise que toi mais avec mon script actuel et l'insertion de 174 fichiers, j'ai gagné environ 2 minutes.

[Pixel]

Okay. Dans tous les cas, c'est vraiment les I/O qui tuent les scripts de manipulation d'iso. D'ailleurs, dans ton cas, je me demande si la compression est bien utile. Est-ce qu'elle sert vraiment ? Je veux dire, le lzss a vraiment des taux de compression pourris. Est-ce qu'il ne serait peut-être pas plus sage de la laisser tomber, et de court-circuiter le code de décompression pour le transformer en memcpy ? Quelle taille ferait l'iso si tes modifs n'étaient pas compressées ?

Ou au pire, je peux te mettre en place le code qui va compresser en UCL, comme ce que j'ai fait avec VP. C'est carrément plus rapide que tout ce que tu peux faire en compression de ton coté

Dans tous les cas, j'en conclue que la version JIT ne t'a pas explosée à la figure ?



Sur un autre sujet, j'ai rajouté du code dans lua-interface-light: maintenant quand on le lance via double-clic, il affiche cette fenêtre:

lua-interface-light.png (14.2 Kio) Consulté 10294 fois

Si on clique sur "Command Line", ça donne directement un prompt, l'équivalent de l'option -i. Si on sélectionne un fichier .paq à lancer et qu'on clique sur Ok, il va chercher dans ce .paq le fichier "archive_main.lua", et va tenter d'exécuter la fonction "archive_main" sans aucun argument. Le compresseur de .paq est gracieusement fourni par Jes.

[Jes]

D'ailleurs, dans ton cas, je me demande si la compression est bien utile. Est-ce qu'elle sert vraiment ? Je veux dire, le lzss a vraiment des taux de compression pourris. Est-ce qu'il ne serait peut-être pas plus sage de la laisser tomber, et de court-circuiter le code de décompression pour le transformer en memcpy ? Quelle taille ferait l'iso si tes modifs n'étaient pas compressées ?

LZ, un taux de compression pourri Mais bien sûr T'as une idée de la place qu'occuperait les fichiers de VP si on supprimait juste la couche LZ, en laissant le RLE? Plus d'un giga Comme n'importe quelle autre méthode de compression, le LZ est très efficace sur des données hautement redondantes comme les graphismes ou les textes de script. A moins qu'il ne reste plusieurs centaines de mos libres sur le CD, je vois mal comment il pourrait s'en passer

[Pixel]

Sauf que je parle de ne pas compresser que les fichiers qui sont modifiés par le patch. Et ça, ça augmente le tout que de très peu.

Et, oui, LZSS a un taux de compression pourri pour des performances assez horribles, ou en tout cas, les 95% des implémentations faites par les game programmers. La seule implémentation de compression type LZSS qui est valable que je connaisse est UCL, justement.

[Jes]

Sauf que je parle de ne pas compresser que les fichiers qui sont modifiés par le patch. Et ça, ça augmente le tout que de très peu.

Et, oui, LZSS a un taux de compression pourri pour des performances assez horribles, ou en tout cas, les 95% des implémentations faites par les game programmers. La seule implémentation de compression type LZSS qui est valable que je connaisse est UCL, justement.

Tu mélanges un peu tout là. Au départ, tu compares un fichier pas compressé du tout avec son équivalent compressé en LZ: dans ce cas, il est parfaitement faux de dire que le taux de compression est, en moyenne, négligeable. Après, on peut comparer le taux de compression du LZ avec d'autres algorithmes, mais là encore, la supposée infériorité du LZ reste à démontrer. Celle-ci ne dépend pas seulement de l'implémentation (je parle ici de la variante et du schéma exact retenu) mais aussi de la méthode de parsing du fichier d'entrée. Et en la matière il y a un éventail de possibilités. Au final, je ne pas sûr du tout que le LZ fasse si pâle figure face à d'autres algorithmes sensé être optimaux, comme Huffman ou le codage arithmétique

Et concernant les performances en terme de temps d'exécution, il n'y a strictement rien à redire La décompression est *naturellement* très rapide. Le temps de compression quant à lui dépend entièrement de la façon dont est implémentée la recherche de chaînes dans la fenêtre glissante, de nouveau c'est une pure question d'implémentation. Mais intrinsèquement, il est clair que le LZ n'est *pas* lent. On ne pourrait expliquer la popularité de DEFLATE dans le cas contraire

PS: Quoiqu'il en soit, je comprends pas bien pourquoi tu conseilles à Baha de ne pas recompresser ses fichiers alors-même que le goulot d'étranglement - et c'est pas la première fois qu'on en parle - se situe au niveau des accès au disque dur. Il va gagner quoi, 10% de temps d'exécution?

[Pixel]

Tu mélanges un peu tout là. Au départ, tu compares un fichier pas compressé du tout avec son équivalent compressé en LZ: dans ce cas, il est parfaitement faux de dire que le taux de compression est, en moyenne, négligeable. Après, on peut comparer le taux de compression du LZ avec d'autres algorithmes, mais là encore, la supposée infériorité du LZ reste à démontrer.

Ceci est discuté en long en large et en travers par les travaux de Jean Loup Gailli et Markus Oberhumer. Je te laisse lire leurs papiers.

Celle-ci ne dépend pas seulement de l'implémentation (je parle ici de la variante et du schéma exact retenu) mais aussi de la méthode de parsing du fichier d'entrée. Et en la matière il y a un éventail de possibilités. Au final, je ne pas sûr du tout que le LZ fasse si pâle figure face à d'autres algorithmes sensé être optimaux, comme Huffman ou le codage arithmétique

Le schéma a une énorme importance sur le taux de compression. Et sur un texte de 2 ou 3 Ko, un schéma comme celui de ToD ne fera pas vraiment d'effet, surtout que ledit schéma est destiné à du graphisme.

Et concernant les performances en terme de temps d'exécution, il n'y a strictement rien à redire La décompression est *naturellement* très rapide. Le temps de compression quant à lui dépend entièrement de la façon dont est implémentée la recherche de chaînes dans la fenêtre glissante, de nouveau c'est une pure question d'implémentation. Mais intrinsèquement, il est clair que le LZ n'est *pas* lent. On ne pourrait expliquer la popularité de DEFLATE dans le cas contraire

La décompression, oui. La compression, non. Tu as regardé le code de Baha à ce sujet ? Et je parle bien de LZSS, pas des variantes genre LZW qui ont une optimisation naturelle due à leur nature de dictionnaire.

PS: Quoiqu'il en soit, je comprends pas bien pourquoi tu conseilles à Baha de ne pas recompresser ses fichiers alors-même que le goulot d'étranglement - et c'est pas la première fois qu'on en parle - se situe au niveau des accès au disque dur. Il va gagner quoi, 10% de temps d'exécution?

Qu'est-ce que tu en sais ? Son code de compression est une implémentation naïve de LZSS. Au final, on ne sait pas combien il gagnerait en sucrant ce code-là et en faisant juste un memcpy des textes.

[Jes]

Tu mélanges un peu tout là. Au départ, tu compares un fichier pas compressé du tout avec son équivalent compressé en LZ: dans ce cas, il est parfaitement faux de dire que le taux de compression est, en moyenne, négligeable. Après, on peut comparer le taux de compression du LZ avec d'autres algorithmes, mais là encore, la supposée infériorité du LZ reste à démontrer.

Ceci est discuté en long en large et en travers par les travaux de Jean Loup Gailli et Markus Oberhumer. Je te laisse lire leurs papiers.

Bizarrement, ces deux-là ont choisi d'incorporer une variante du LZ dans leurs algorithmes de compression

Le schéma a une énorme importance sur le taux de compression.

Jamais dit le contraire. Mais le schéma a lui seul ne détermine pas complètement le taux de compression atteignable. Le parsing du fichier à compresser introduit un autre degré de liberté. Au final le taux de compression est donc fortement dépendant de l'implémentation. Ces problèmes d'implémentations mis à part, je maintiens que le LZSS est un "bon" algorithme, à tout pointe de vue. Et affirmer le contraire, c'est du troll

Et sur un texte de 2 ou 3 Ko, un schéma comme celui de ToD ne fera pas vraiment d'effet, surtout que ledit schéma est destiné à du graphisme.

Mais si, bien sûr qu'il y aura un effet. Au grand minimum, le fichier compressé obtenu devrait être 30% moins gros (et c'est bien le minimum). Un texte, français ou anglais, est naturellement fortement redondant. N'importe quel schéma utilisé *doit* réaliser une compression substantielle. Par ailleurs je suis curieux de savoir ce qui te fait dire que le schéma choisi convient mieux aux propriétés statistiques des images que des textes

Et concernant les performances en terme de temps d'exécution, il n'y a strictement rien à redire La décompression est *naturellement* très rapide. Le temps de compression quant à lui dépend entièrement de la façon dont est implémentée la recherche de chaînes dans la fenêtre glissante, de nouveau c'est une pure question d'implémentation. Mais intrinsèquement, il est clair que le LZ n'est *pas* lent. On ne pourrait expliquer la popularité de DEFLATE dans le cas contraire

La décompression, oui. La compression, non. Tu as regardé le code de Baha à ce sujet ? Et je parle bien de LZSS, pas des variantes genre LZW qui ont une optimisation naturelle due à leur nature de dictionnaire.

Ah mais, on ne parle pas du code de Baha là, je t'ai bien entendu dire "le LZSS a des performances horribles" non? Alors, mettons de côté le LZW qui descend du LZ78 et qui n'a que peu de rapport avec le LZ77 (LZ77 dont le LZSS n'est qu'une infime variation). Il y a, dans la littérature, tout un tas d'articles discutant du meilleur moyen pour accélérer la recherche de chaînes adéquates dans la fenêtre glissante. En fait, tu as un éventail de solutions possibles pour résoudre le problème: table de hachage, arbre binaire de recherche, arbre suffixe, tableau suffixe... Au final, il a été démontré qu'on peut construire un algorithme de compression LZ77/LZSS de complexité temporelle linéaire (en moyenne) avec la taille du fichier à compresser. Et ce n'est pas que de la théorie. Je reviens sur DEFLATE. Est-ce que tu as à te plaindre du temps d'archivage d'un zip? Ou du temps d'enregistrement d'une image PNG?

PS: Quoiqu'il en soit, je comprends pas bien pourquoi tu conseilles à Baha de ne pas recompresser ses fichiers alors-même que le goulot d'étranglement - et c'est pas la première fois qu'on en parle - se situe au niveau des accès au disque dur. Il va gagner quoi, 10% de temps d'exécution?

Qu'est-ce que tu en sais ? Son code de compression est une implémentation naïve de LZSS. Au final, on ne sait pas combien il gagnerait en sucrant ce code-là et en faisant juste un memcpy des textes.

J'en sais qu'il nous a déjà donné il y a peu le temps de reconstruction de l'ISO sans rien recompresser, et que ça ne laissait pas beaucoup de doutes sur la question

[BahaBulle]

Et sous la suggestion de Bahabulle, j'ai fait une version "light" du software. Le packaging doit probablement manquer quelques dlls, mais ça a l'air de marcher:

http://static.grumpycoder.net/pixel/lua ... -win32.zip

Juste pour dire que ce lien ne fonctionne plus car le nom du zip à changé.

Le nouveau nom : http://static.grumpycoder.net/pixel/lua ... -light.zip

[Pixel]

Ah mais il avait répondu le Jes, j'avais pas vu.


Le schéma de ToD inclue une pré-initialisation du backbuffer avec des data qui sont typiques d'images, comme des rampes et autres répétitions, afin de mieux compresser les images justement. Donc c'est en effet prévu pour les propriétés statistiques des images.


Et pourquoi tu parles de DEFLATE ? Tu es en train de parler d'un algo qui utilise de la *mémoire* pour fonctionner! C'est pas un LZSS! Il y a du huffman dedans, ainsi qu'un dictionnaire dynamique. Ca n'a rien à voir comme méthode. Enfin, au mieux, on peut parler de "lz77 improved". C'est un lz78 en fait à la base. Mais les "lzss" tels qu'on peut les voir dans les jeux sont juste des batards qui ont été grossièrement assemblé à partir de l'idée de "ce que c'est qu'une compression type lz77".

De manière générale, je parle du "LZSS barbare utilisé par les codeurs de jeu vidéo qui veulent pas mettre de la zlib ou acheter une license lzo". La plupart du temps, ils vont se foutre dedans, et provoquer des algos qui sont peu efficaces ou qui ne correspondent pas à leurs besoins.

[Jes]

Le schéma de ToD inclue une pré-initialisation du backbuffer avec des data qui sont typiques d'images, comme des rampes et autres répétitions, afin de mieux compresser les images justement. Donc c'est en effet prévu pour les propriétés statistiques des images.

L'initialisation du buffer ne fait pas partie de ce que j'appelle le schéma. Et si ce n'est que ça ça n'empêche pas une compression substantielle du texte.

Et pourquoi tu parles de DEFLATE ? Tu es en train de parler d'un algo qui utilise de la *mémoire* pour fonctionner! C'est pas un LZSS! Il y a du huffman dedans, ainsi qu'un dictionnaire dynamique. Ca n'a rien à voir comme méthode. Enfin, au mieux, on peut parler de "lz77 improved". C'est un lz78 en fait à la base. Mais les "lzss" tels qu'on peut les voir dans les jeux sont juste des batards qui ont été grossièrement assemblé à partir de l'idée de "ce que c'est qu'une compression type lz77".

DEFLATE c'est LZ77 + Huffman (aucune trace du LZ78 qui comme je le disais plus haut, n'a rien de comparable au LZSS). Et je te parle de DEFLATE pour sa vitesse d'exécution lors de la compression (ça me paraissait pourtant clair). DEFLATE est rapide, alors même qu'il se paie le luxe de rajouter une couche de compression supplémentaire par rapport au LZ77 pur. C'est bien la preuve que le LZSS n'est pas un algorithme de compression fondamentalement lent.

[Pixel]

Je vais formuler autrement: aide Bahabulle dans ce cas à améliorer son algo de compression pour ToD en y mettant les algos de création de dictionnaire de deflate, afin d'améliorer sa vitesse de réinsertion. Ensuite on en reparlera.

[Jes]

Ca c'est ce qui s'appelle botter en touche Mais tu sais, comme le temps d'exécution reste largement impacté par les I/O...

[Pixel]

Voilà voilà voilà voilà.

[Jes]

Ah? T'as changé d'avis alors? Je croyais que la compression LZSS était fondamentalement ultra-lente et plombait tout le temps d'exécution du script de Baha

[Pixel]

Tu viens juste de prouver que j'ai raison. Dans le cas de ToD, le ratio "temps passé" / "gain de place" est tellement élevé que c'est une perte de temps plus qu'autre chose. Baha peut donc largement éviter de recompresser ses textes. Ou bien recoder l'algo complètement pour être efficace, ce qui, avec ton aide étant donné ta large connaissance de deflate, devrait être chose aisée.

[Jes]

Tu viens juste de prouver que j'ai raison.

Alors que depuis le départ je me tue à te dire que tes considérations sur le LZSS sont fausses

Dans le cas de ToD, le ratio "temps passé" / "gain de place" est tellement élevé que c'est une perte de temps plus qu'autre chose. Baha peut donc largement éviter de recompresser ses textes.

Même si c'était vrai, comme c'est pas la compression qui plombe tout le process, à quoi bon vouloir l'éviter? Surtout qu'au final ça implique de court-circuiter la routine de décompression dans le binaire. Berk, berk, berk

Ou bien recoder l'algo complètement pour être efficace, ce qui, avec ton aide étant donné ta large connaissance de deflate, devrait être chose aisée.

Ou toi avec ta large connaissance du n2e Remarque, là ce serait vraiment une perte de temps inutile, dans les deux cas

[Pixel]

Et moi je te dis que tu as tort: la compression dans le cas de la reconstruction de l'iso pour Baha prend obligatoirement un temps non négligeable, au vu de l'algo qu'il utilise. Je ne serais pas surpris du tout d'un boost du temps de reconstruction en virant la compression. Je pense donc sincèrement que c'est à considérer.

Le n2e est une toute autre affaire. Déjà, le temps de compression de l'algo ucl est inférieur aux algos que l'on peut produire, donc de toute façon, rajouter du n2e dans le paté serait un plus au niveau du temps de reconstruction de l'iso. Ensuite, l'algo de décompression existe déjà pour MIPS, et l'inclure serait trivial. Le temps de travail pour effectuer cette modif est lui négligeable comparé au temps de travail pour améliorer l'algo de compression original. Donc, pourquoi pas aussi, si la compression est absolument nécessaire; ce qui, je le répète, ne me semble pas être le cas du tout.

[Happexamendios]

fiouuu !

c'est raide à suivre les débats d'experts...
Complètement lourdé, moi!

on peut pas causer voiture, filles ou picole ?

[Jes]

Et c'est tout ce que tu trouves à dire toi?

[Jes]

Bon, et sinon, puisqu'on me l'a demandé, je mets en ligne mon soft gérant les PAQ:

http://www.bessab.net/jes/paq/paq-1.0-win32.zip

Code : Tout sélectionner

PAQ archiving utility, version 1.0 (Nov 22 2009)
Copyright (C) 2009 Jes, http://www.bessab.com

Usage: paq [action] [paq file] {in/out directory}

  The following actions are supported:

  -l list files in a PAQ archive
  -x extract PAQ archive to the specified directory
  -c create PAQ archive of an entire directory (including its sub-directories)

Toutes les dépendances ont été statiquement liées, ça devrait donc tourner n'importe où sans problème de dll

En espérant que ça serve