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.

Aujourd'hui j'ai fait un peu d'ajax, c'était bien.

J'ai ouï dire que quelques esprits chagrins laissaient entendre que ce blog était déjà l'abandon. Je tiens à signaler qu'il n'en est rien.

J'ai renvoyé le Seagate à 7200 rpm et je l'ai sagement echangé contre un Western Digital de 250Go à 5400rpm. Je monte le bouzin, les yeux pleins d'étoiles, persuadé de la perfection du résultat et... MERDE IL VIBRE ENCORE. Moins, mais ça fleurte avec la limite du tolerable, du coup je ne sais pas si je vais le garder :'(

Je me demande ce que le disque original a de si spécial..

UPDATE Mon sens de l'observation toujours en éveil ma permis de noter qu'en appuyant très fort sur le mac les vibrations étaient notablement atténuées. Je viens de glisser un bout de carton sous le disque dur et miracle, ça ne vibre plus \o/

RE-UPDATE En remettant la batterie j'avais encore des vibrations. En fait j'ai dû mettre aussi un bout de carton sous le macbouc, au niveau du disque dur. Ce coup-ci, il n'y a vraiment plus aucune vibration ! Si le bout de carton à l'interieur du macbook ne prend pas feu c'est vraiment super !

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.

Puisque personne ne m'a fait de compliments sur la magnifique charte graphique de ce blog, je vais le faire moi-même:

Je trouve ce blog très beau.

Bien souvent, on me demande quel est mon secret pour avoir des xterms si beaux. Et c'est en fanfare que je le dévoile ci-dessous. ça se met dans le .Xdefaults, et ça remplace les 16 couleurs à chier par 16 belles couleurs aux tons voisins mais moins criards. C'est plutôt adapté à un term sur fond fond noir, mais ça passe aussi très bien sur un fond blanc.

XTerm*background:  black
XTerm*foreground:  gray
XTerm*cursorColor: yellow
XTerm*color0:      black
XTerm*color1:      #9e1828
XTerm*color2:      #aece92
XTerm*color3:      #968a38
XTerm*color4:      #8181f1
XTerm*color5:      #963c59
XTerm*color6:      #418179
XTerm*color7:      gray
XTerm*color8:      gray40
XTerm*color9:      #d14b12
XTerm*color10:     #78ce23
XTerm*color11:     #f4af0c
XTerm*color12:     #2b77f2
XTerm*color13:     #cc2a98
XTerm*color14:     #15a5c1
XTerm*color15:     white

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 :'(

La grosse déception du jour c'est que la tentative d'upgrade du disque dur de mon macbouc est une miserable failure. J'ai voulu le gonfler un peu avec un disque à 7200 rpm (seagate momentus 7200.2) en partant du principe qu'une légère augmentation de la température et du bruit ne me génait pas, qu'un petite perte d'autonomie n'était pas un drame, mais par contre je n'avais pas pensé aux possibles problèmes de vibration. Eh oui car un laptop qui vibre c'est extrêmement désagréable, on a l'impression d'avoir en permanence des fourmis dans les doigts, et dieu sait que je n'aime pas les fourmis. Du coup j'ai remis le disque original :'(

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