uuuurg

Y'a un truc que j'aime pas c'est de devoir choisir un toolkit graphique et en assumer la responsabilité. C'est pas evident de faire un choix qu'on ne regrette pas, parce que mine de rien ces bêtes là ont tendance à planter leurs racines assez profondement dans le code dès qu'on commence à les utiliser: chacun vient avec ses propres strings plus ou moins unicode, ses propres abstrations de flux d'io (zip, fichier, memoire etc), ses mutex, ses threads, son implémentation des shared_ptr et de quelques structures de données elementaires. Sa propre manière de nommer les fonctions et les classes aussi, et j'aime pas les mélanges, moi mes classes s'appellent CommeCa, et le reste c'est comme_ça.

Un toolkit graphique ça impose aussi ses propres classes d'exception, son code d'initialisation spécifique, parfois même un préprocesseur adapté. Et après il faut peser le pour et le contre, entre celui qui fait tout (y compris des executables de 10Mo minimum, et qui prends 10h à compiler) et celui qui fait peu de choses et pas très bien. Entre celui qui est gpl avec une option proprio à 1500 euros par développeur et par OS, celui qui est lgpl avec 42 dependances, et celui qui est bsd. Il faut aussi peser la perennité du bousin, ça serait ballot de se casse le luc à faire un portage vers un environnement en cours d'abandon, ou bien un environnement qui a fait de mauvais choix techniques. Il faut choisir si on en veut un qui utilise les exceptions ou si au contraire on veut se passer des exceptions. Il faut prendre en compte la portabilité. La qualité de la doc aussi. La qualité du code aussi, parce qu'ils sont plus ou moins testés, plus ou moins buggés. Tout ça c'est pas facile, et quand je vois le code de certaines boites qui sont coincées depuis des années avec des toolkits de "compatibilité" cross-plateforme (une émulation moisie des api macos sous windows, dont l'éditeur n'existe plus) je me dis qu'un mauvais choix peut être cherement payé.

L'heure est grave.

Actuellement mon choix se porte sur Juce dont le domaine d'applications me convient plutôt bien, qui est adapté aux gui de jackies (la démo est assez sympa), et qui est raisonnablement petit (par rapport à Qt, gtk ou wx) sans être ridicule.

Ce soir j'ai appris que les trucs du genre <form action="<?php echo $_SERVER['PHP_SELF']; ?>"> sont non seulement inutiles (le form action="" marche aussi), mais sont aussi exploitables en XSS. J'aurais un peu réflechi et lu attentivement la doc php, je m'en serais peut être douté mais il faut bien avouer qu'elle n'est pas très alarmiste et un peu misleading... je cite: 'PHP_SELF' The filename of the currently executing script, relative to the document root. a ceci près que c'est pas exactement un filename, et que l'utilisateur peut le manipuler comme bon lui semble, comme expliqué ici. Puxor.

J'aime bien cygwin. Un peu d'unix dans un monde de brutes. Y'a quand même deux-trois petits trucs dans la conf par défaut qui me défrisent. Tout d'abord il y a le nom dont la prononciation me semble douteuse. "sailleg-win" ou "sigouine" ?

Il y a aussi le /cygdrive qui préfixe tous les chemins, c'est laid. J'imagine qu'il a une raison d'être, mais c'est laid, et c'est chiant à taper. Et c'est different de msys ce qui peut poser probleme quand on veut utiliser des scripts indifferement sous l'un ou l'autre. Heureusement, on peut corriger ça avec la commande magique que je vais m'empresser de noter ci-dessous parce que j'ai toujours un mal de chien à la retrouver quand je la cherche:

 mount --change-cygdrive-prefix /

Il suffit de la lancer une fois pour toutes, et on accède au disque c: avec /c/ etc. ça poutror. cygwin c'est vraiment bien.

Un autre truc que j'aime pas, et même que je conchie, c'est l'espèce de bouse qui sert de terminal sous windows, ce truc tout moche, non redimensionnable, avec un copier coller anti convivial au possible franchement j'échangerai pas un baril d'xterm contre un container de consoles windows. D'un autre côté j'ai rarement envie de me coltiner le serveur X de cygwin pour lancer un authentique xterm, alors dans ce cas la solution c'est de modifier cygwin.bat pour lancer rxvt à la place d'un bash tout bête.

Donc je remplace

bash --login -i

par

c:\cygwin\bin\rxvt -fn 9x16 -bg black -fg white -sl 2500 -title cygwin -e bash --login -i

Et là miracle, c'est beau, c'est réactif, c'est redimensionnable, y'a une scrollbar, et le copier coller c'est bonheur.

J'essaye de me désintoxiquer de matlab en douceur, alors je me lance dans la convertion de quelques scripts pour qu'ils fonctionnent correctement sous octave. Le premier reflexe c'est de prendre les sources du bouzin et de les compiler, mais

• il y a quand même un bon petit paquet de dépendances
• ça prend des putain de plombes (eh oui c'est du c++) (si on considère qu'une plombe dure une heure)

Comme d'habitude avec les projets libres, c'est un peu le bordel, en fait le bon site pour octave c'est octave-forge , là on a accès à un certain nombre de toolboxes (qui ne fonctionnent que sur la version bleeding-edge), et à des binaires precompilés pour macos et windows.

Comme d'habitude avec les projets libres, la conf par défaut est un peu merdique (oui je pense très fort à emacs): le pager est ultra pénible, le prompt est moche, et chaque écran d'aide est pourri par du bullshit indiquant qu'il y a soit-disant plus d'info dans la doc en ligne et blahblahblah.

Voici donc mon .octaverc, il est tout pourri mais ça rend la ligne de commande d'octave un peu plus conviviale, avec un prompt de jacky en vert:

more off;
PS1('[\033[1;32m]\W[\033[0m] >> ');
debug_on_interrupt(1);
suppress_verbose_help_message(1);

Sinon, pour reprendre la comparaison avec Matlab, j'ai été agréablement surpris par le niveau de compatibilité d'octave -- ça déchire, y compris sur les mex files ! En terme de stabilité c'est pas tout à fait ça, la 2.9.13 que j'ai testé plante quand je fais un dbquit. La rapidité est honorable pour tout ce qui est sous forme de tableaux, mais les boucles sont très lente par rapport à matlab (un facteur 100), pas étonnant puisque matlab a un compilateur jit. Le point noir c'est les graphiques, franchement utiliser gnuplot ça craint, je hais ce truc. Et utiliser imagemagick pour les pcolor et les specgram ça craint encore plus :'(

Pour commencer ce blog en fanfare, j'offre au monde ébahi les fonctions sin_ps, cos_ps, exp_ps et log_ps qui prennent en entrée un petit vecteur de 4 float et recrachent les 4 resultats correspondants, tout ça en un temps bref et avec une précision tout a fait honorable. C'est du SSE1 donc ça marche même sur les vieux athlons et pentium 3, c'est écrit en C avec les fonctions intrinsèques SSE, donc ça compile sans probleme avec gcc, icc, msvc, .. Rien de révolutionnaire, mais ça marche pas trop mal.

C'est ici: http://gruntthepeon.free.fr/ssemath