mardi 18 novembre 2008
(lambda ()
mardi 18 novembre 2008 - Geek
billitch |
Bienvenue sur blog de billitch !
Du code, de la noise, et quelques pensées électrogènes... |
|
1. Le mardi 18 novembre 2008à14:03, par ig0r
2. Le mercredi 19 novembre 2008à16:48, par billitch
|
||
lundi 13 octobre 2008
lundi 13 octobre 2008 - Geek
Récemment Alice et moi avons écrit un modèle de newsletter en XHTML et CSS pour le site BTPinformaTIC où Martin travaille. Malheureusement cette traduction de l'article "CSS and Email, Kissing in a Tree" nous explique que le support des CSS par les différents clients mail de ce monde est très restreint. Notamment hotmail qui ne comprend rien à part les styles en ligne : <tag style="...">. Il faut ajouter à ça que la rédaction du site utilise un éditeur HTML intégré au site et que celui-ci ne permet pas du tout l'inclusion de balise <style> ou de lien vers une feuille de style externe, ou même de balise <head>, bref : rien à part des styles en ligne.
Pas de problème, mon code est du XHTML valide, je suis parti pour écrire un Inliner CSS en Python qui mettra tous les styles CSS en ligne dans chaque balise !
Pour commencer j'ai écrit un parser XML en python grâce à lxml. Ça tient en 5 lignes !
Ensuite pour écrire un parser CSS j'utilise cssutils qui n'est pas encore dans Macports (l'équivalent des ports de BSD sous Mac OS X et Darwin), j'ai donc rapidement écrit un port de cssutils pour Mac OS X.
Ensuite on colle les morceaux ensemble, on parcours l'arbre des balises, ajoutons-y une fonction pour fusionner les styles sans duplication, on corrige l'ordre d'application... Et voilà, on a un Inliner CSS !
|
1. Le lundi 13 octobre 2008à11:49, par ig0r
2. Le mercredi 15 octobre 2008à12:37, par billitch
3. Le dimanche 19 octobre 2008à16:03, par Martin
4. Le mercredi 29 octobre 2008à07:17, par Lubbykko
5. Le vendredi 31 octobre 2008à13:56, par billitch
|
||
jeudi 9 octobre 2008
jeudi 9 octobre 2008 - Geek
J'ai décidé de me mettre au Common Lisp, ce vieux (1960) langage de programmation qui a eu bien du mal à sortir des universités malgré toutes ses qualités (impératif, fonctionnel, orienté objet, compilable, meta-programmable, ...). Il existe de nombreuses implémentations de Common Lisp, et en cherchant la meilleure, je me suis rendu compte qu'il était aussi très rapide (20x plus que les langages interprétés comme Python et PHP par exemple, moins de 2x plus lent que le bon vieux C) dans l'implémentation de SBCL. Je trouve l'utilisation des s-expressions très sexy malgré leur première apparence rébarbative (ie la notation polonaise inversée) c'est d'une concision et d'une clarté irréprochable une fois bien indenté (chose automatique dans un éditeur digne de ce nom, cela dit pour coder du lisp cela a-t-il un sens d'utiliser autre chose que emacs ?).
J'ai aussi découvert le nom de langages récents qui ont l'air très performants : ATS, Clean et Lisaac. D'après le Computer Language Benchmarks Game, ces langages ont des performances comparable au C ce qui me donne envie de les découvrir une fois que j'aurais approfondi le Lisp car ils proposent beaucoup plus que le C. Lisaac est un langage orienté prototype et a pour but de créer le système d'exploitation Isaac. Clean est un langage fonctionnel pur à évaluation paresseuse.
|
1. Le jeudi 9 octobre 2008à19:47, par ig0r
2. Le samedi 11 octobre 2008à03:10, par billitch
3. Le samedi 11 octobre 2008à09:11, par ig0r
4. Le samedi 11 octobre 2008à14:26, par ig0r
5. Le samedi 11 octobre 2008à15:52, par billitch
|
||
mardi 7 octobre 2008
mardi 7 octobre 2008 - Geek
Nicholas Money a utilisé une caméra ultra rapide pour capturer pas moins de 250 000 images par secondes de ces spores peuvent atteindre la vitesse affolante de 88 km/h grâce à une poussée de 180 000 G. Sachant qu'un avion de chasse se limite à une dizaine de G pour ne pas consommer trop de pilotes humains on comprend pourquoi notre expert en champignons l'a nommé le vol le plus rapide de la nature.
|
|
||
mercredi 24 septembre 2008
mercredi 24 septembre 2008 - Geek
Le C est basé sur des standards désuets, et en voici encore une preuve : dans la norme ISO la conversion d'un float vers un int est une troncation de la partie flottante, tout programmeur le sait. Pourtant le FPU fait tous ses calculs dans un autre mode qui arrondit les valeurs, passer de ce mode au mode troncation vide le pipeline du FPU, ce qui fait perdre toute optimisation. Il existe une manière jusqu'à 10x plus rapide de convertir des floats en int en bénéficiant en plus d'un arrondi grace à la fonction lrint(3), comme l'explique cet excellent article de l'auteur de la libsndfile : Faster Floating Point to Integer Conversions.
|
|
||
jeudi 18 septembre 2008
jeudi 18 septembre 2008 - Geek
Pour savoir si une texture va tenir en mémoire, la FAQ d'OpenGL nous propose d'utiliser GL_TEXTURE_PROXY, mais leur technique ne marche pas toujours. Je décris rapidement la technique :
glTexImage2D (GL_PROXY_TEXTURE_2D, level, internalFormat,
width, height, border,
format, type, NULL);
En gros tout est normal sauf target qui devient GL_PROXY_TEXTURE_* et pixels qui est NULL. Inutile de balancer les pixels, on ne fait qu'évaluer la place en mémoire que prendra l'image au format donné. La FAQ nous dit qu'on peut ensuite savoir si ça a marché avec :
GLint width;
glGetTexLevelParameteriv (GL_PROXY_TEXTURE_2D, 0,
GL_TEXTURE_WIDTH, &actual_width);
if (actual_width == 0) {
/* La texture ne tiendra pas en mémoire */
}
Seulement chez moi ça n'a pas marché. Après avoir lancé GDB, je me suis rendu compte que parfois actual_width contient une valeur qui n'est ni 0, ni width ! J'ai donc réécrit le test qui fonctionne beaucoup mieux ainsi :
if (actual_width != width) {
/* La texture ne tiendra pas en mémoire */
}
Pour plus de détails :
|
1. Le jeudi 18 septembre 2008à18:41, par martin
|
||
samedi 30 août 2008
samedi 30 août 2008 - Geek
Je viens de mettre en place un mini serveur OpenID sur mon site pour m'authentifier.
Pour résumer, OpenID est un système de login open-source et décentralisé. Vous créez un compte sur un serveur OpenID, et quand vous vous connectez, tous les sites compatibles vous reconnaissent, sans retaper votre mot de passe. Oui, c'est le futur =)
Le point de faiblesse ? Le serveur : il héberge votre compte et votre mot de passe. Celui-ci pourrait donc se faire passer pour vous auprès d'autres sites (en fait ça n'est pas si simple que ça, mais bon soyons paranos =). De toute façon la solution est simple : je suis désormais mon propre serveur OpenID, grâce à phpMyID il suffit de trois commandes pour devenir son propre serveur OpenID.
Je peux désormais me connecter en tant que http://b.lowh.net/billitch sur pas mal de sites, et vu que Google, Yahoo, IBM, Microsoft et Verisign sont devenus cette année parties prenantes de OpenID je pense que le taux de sites compatibles devrait exploser avant l'année prochaine.
|
|
||
lundi 5 mai 2008
lundi 5 mai 2008 - Geek
Le quatrième élément fondamental des circuits intégrés vient d'être démontré par HP Labs. Le memristor (pour memory resistor) pourrait être une révolution technologique de l'ordre de celle du transistor. Il avait été décrit mathématiquement à Berkeley en 1971, mais cette fois ci HP Labs annonce avoir la preuve de son existence.
Le composant permettrait un nouveau genre de mémoire analogique (et non binaire comme les actuelles mémoires à bascules). Sa résistance dépendrait de la quantité d'électricité l'ayant traversé auparavant. Cela ressemble fortement au comportement des neurones dont les synapses croissent ou diminuent selon le nombre de potentiels qui les ont traversé (c'est l'apprentissage hebbien). On pourrait alors envisager de réaliser des circuits intégrés qui soient de vrais neurones électroniques, tout cela de manière parallèle et asynchrone, et surtout en se passant de conversion analogique/numerique !
Un nouveau type de mémoire est aussi envisageable qui conserverait son état sans consommer d'énergie. Cela est beaucoup plus intéressant que la D-RAM actuelle qui consomme de l'énergie même lorsqu'elle est inactive.
J'imagine aussi qu'il y a des applications colossales pour tout ce qui est signal analogique. Je rêve déjà de processeurs de dynamiques analogiques tenant dans une puce CMS à quelques centimes pièce =)
C'est vraiment une nouvelle donne en ce qui concerne la nano électronique et la modestie des premières prospectives de HP comme fournir des puces qui "accélèrent la reconnaissance faciale" est à mon avis une version très édulcorée de ce qu'on peut envisager avec une telle technologie. Je pense personnellement à d'énormes réseaux de neurones gravés à même le silicium, qui seraient beaucoup plus performants que nos "vrais" neurones dotés de synapses chimiques et donc très lents.
|
1. Le lundi 5 mai 2008à13:48, par billitch
2. Le mardi 6 mai 2008à16:22, par wintermute
|
||