billitch

Bienvenue sur blog de billitch !
Du code, de la noise, et quelques pensées électrogènes...

lundi 13 octobre 2008

CSS Inliner

Récemment Alice et moi avons écrit un modèle de newsletter en XHTML et CSS pour le site BTPinformaTICMartin 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

Hum, mais ça serait pas plus constructif de brûler hotmail, par exemple ? :p

jeudi 9 octobre 2008

Du bon usage de la langue

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

Ouais, c'est un peu comme du OCaml mais en moins bien quoi (attention, là, un trollllllll !!! :) )

Hum et sinon c'est quoi la différence fondamentale entre scheme et lisp (oui je me suis jamais trop plongé là-dedans, je préfère le typage statique) ?

2. Le samedi 11 octobre 2008à03:10, par billitch

bah scheme c'est un vieux dialecte du lisp avant la standardisation du Common Lisp par l'ANSI. C'est resté par-ce qu'il a été utilisé comme support de cours au MIT, mais je crois pas que ce soit très utilisable/utilisé dans des applications réelles

cela dit, pour nourrir un peu le troll, pour faire de la métaprogrammation en OCaml il faut être motivé alors que c'est complètement natif en lisp ("the programmable programming language") =D

3. Le samedi 11 octobre 2008à09:11, par ig0r

Ben ya des labos qui bossent sur scheme : à l'INRIA par exemple, ils font Bigloo (http://www-sop.inria.fr/mimosa/fp/Bigloo/), un compilateur Scheme vers natif, JVM, .NET (encore experimental). Et puis récemment j'ai jeté un oeil à HOP (http://hop.inria.fr/), un langage pour faire des web-applications (comme ils disent).

Niveau performance je connais pas trop, mais j'avais cru entendre que Gambit Scheme (développé au Canada) s'en sortait plutôt bien.

4. Le samedi 11 octobre 2008à14:26, par ig0r

oups, on dirait que mon commentaire précédent a mal été digéré :p

5. Le samedi 11 octobre 2008à15:52, par billitch

ça devait etre un pb avec la syntaxe wiki, corrigé dans la bdd.

mardi 7 octobre 2008

180 000 G sous le champignon

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.

dimanche 28 septembre 2008

Je n'écoute pas

Le monde s'effondre autour de moi, mais je vais bien.

Comme si j'allais lui donner raison, tiens !

1. Le lundi 29 septembre 2008à10:06, par Francwe

c'est pas une raison pour être injoignable!!! :P

2. Le mercredi 1 octobre 2008à17:01, par billitch

C'est faux ! Ça se saurait si j'étais injoignable de toute façon =!

Il faut dire que cette semaine et un peu la précédente ont été sujettes à plusieurs charettes qui m'ont complètement pourri mon emploi du temps (oui l'emploi du temps est bien un concept nouveau pour moi pour ceux qui n'y croyaient plus, mais iCal est une vraie merveille ma foi). Heureusement c'est bientôt fini, malheureusement pas avant le WE qui va pas être de tout repos, au programme : des tests d'images 3D lenticulaires grand format (30x40 cm).. yeepy !

vendredi 26 septembre 2008

Untitled 5


1. Le dimanche 28 septembre 2008à10:32, par c

ça fait un peu penser au theremine

c'est tres tres beau

Intéressante modération

Rodin's Thoughts

Bentley Fuck

Marrant le choix des pubs google sur cette page

mercredi 24 septembre 2008

Le C doit mourir

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.