Sablés fourrés

Putain, ce blog est à l'abandon, c'est pas cool...

Quelques petits faits explicateurs:

• J'ai pas le temps. Et oui, je travaille (chez GenToyle). Et quand je ne travaille pas, mon temps est prit par diverses activités, certaines étant secrètes
• Ensuite, j'ai pas toujours plein de trucs à raconter. Parce bon, insulter les connards, et les connasses^[1] de la RATP, c'est bien gentil, mais ça serait trop d'honneur à leur consacrer, à ces bouseux
• Je suis en train de vivre l'amour de ma vie, du moment certe. Mais pour une fois, c'est comme dans mes rêves, mais en vrai :-) Bon, allez c'est con, c'est kitchouille, archi lieu commun, megabeauf et un peu bof, mais : "Sylvain je t'aime !^[2]"
• J'ai plus de place sur mon disque dur, donc peu plus mettre de photos. D'un autre coté, mon programme de gestion d'image commence à sentir le moisi, et je sens que je vais devoir en refaire un autre. Un mega bien, qui pourquoi pas, poserait directement les photos sur leapingtiger, histoire d'automatiser un peu le tout. C'est important l'ergonomie !
• Ah, oui, j'ai un peu avancer sur le simulateur d'ascenseur. C'est pas que ça soit interessant, mais au moins, j'ai maintenant une base si je veux "m'amuser"

Sinon, je peux le dire ! Le projet Transcard a pour vrai nom Cepas ! C'est le successeur de la CashCard, un porte monnaie très en vogue là bas. Pourquoi j'en parle ? Parce que H&SK en a parlé sur son site, et que donc, je ne suis plus lié par une clause de confidentialité sur le fait qu'ils ont implémentés la carte. Qu'est ce que Cepas ? Tout les détails

Voila, sinon, tout va bien :-)

En ce moment, j'ai mis en pause CyberRail pour me concentrer sur un autre projet. Le principe est de tester sur un petit projet les techniques qui seront ensuite intégrées dans CyberRail.

J'ai donc commencé à faire un simulateur d'ascenseur. Ce n'est pas le premier puisqu'il y en a eu 4 autres avant (un en basic mode texte, un en basic mode graphique, un en pascal et un en java). À chaque fois, la technique a progressé, mais il manquait réellement quelque chose pour que cela fonctionne bien. Cette fois, j'avais tous les éléments pour faire une application stable et propre.

Lift 2006 est donc écrit en python, à l'aide de Qt pour l'interface graphique. Évidemment, comme tous mes projets actuels, ça fonctionne sous linux. Mais la grande nouveauté, c'est qu'en écrivant en python, avec Qt, je peux également faire tourner le même code sous Windows, en natif !

Il faut néammoins installer quelques petites bricoles pour que cela fonctionne. Il faut donc :

• l'interpréteur python pour windows : Python 2.4.3. L'installation minimale suffit, pas besoin du reste.
• la bibliothèque Qt. À moins que vous n'ayez une license, il faut prendre la version GPL : Qt 4.1.3. À l'installation, il faudra préciser que MinGW doit être installé, c'est une case à cocher. MinGW, c'est le compilateur gcc pour Windows. Pas de panique, tout est automatisé.
• enfin, PyQt 4.0, toujours la version Windows. L'installeur vérifiera que votre python est bien installé. Là encore, la version minimale suffit, pas besoin d'installer la documentation.

Une fois ces trois paquets installés, vous pouvez faire tourner n'importe quelle application pyqt (en licence GPL).

Pour le moment, le code n'est pas prêt à être mis en ligne (question de licence, justement). Donc, si vous voulez tester Lift 2006, envoyez moi un mail.

Toujours aussi peu d'entrée... En fait, en ce moment, je n'ai plus vraiment le temps.

Déjà, je fréquente quelqu'un, et la relation semble partir sur des bases sérieuses, ce qui fait que je suis moins souvent chez moi que d'habitude.

Ensuite, je suis en train de dévelloper la 4ème version de mon simulateur d'ascenseurs. Ya des vagues comme ça... Le point positif, c'est que cette fois-ci, ça semble tourner sans problème (ça rame pas, ça anime plusieurs machines en même temps, bref, ça fonctionne comme un "vrai programme")

Enfin, j'ai eu hier une petite discussion pour savoir si la technique du multi-threading était quelque chose d'efficace. Pour ma part, je pense que c'est approprié dans certains cas (serveurs d'applications). Dans d'autres, comme par exemple des interfaces graphiques (Swing, Qt, MFC), cela ne se justifiait pas : outre la lourdeur que cela apportait en terme de réactivité, ça complexifie la lecture du programme. En effet les programmes multi-threadés sont plus complexes du fait qu'ils doivent gérer des séquences d'exécutions qui sont en général imprédictibles (du fait de la nature de l'ordonnanceur du système d'exploitation). Ça oblige à utiliser des objets comme des sémaphores ou des mutex qui généralement entrainent des interblocages pénibles à résoudre.

La communication entre thread aussi est pénible : passer par une zone de mémoire partagée n'est pas forcément triviale puisqu'il faut mettre en place des systèmes de synchronisation qui, au final, font la même choses que des tubes. On m'a parlé d'arguments de "modernité" (c'est plus moderne de faire des threads, etc). Hmmm, je ne suis pas particulièrement convaincu. La complexification d'un système n'est pas vraiment signe de modernité, surtout quand il faut repasser par derrière et comprendre comment ça fonctionne. Enfin, lorsque l'on voit les divers implémentations des threads, et de toutes les bidouilles auxquelles il faut recourir pour faire fonctionner les choses correctement, je ne suis pas persuadé qu'on ai beaucoup avancé.