metagoto's blog

HipHop sur github, ca se présente plutôt pas mal. Une petite communauté de forkers travaille à rendre la chose compilable et surtout utilisable par le plus grand nombre (pour le bien de l'humanité?). Scott MacVicar, un des responsables du projet et commiter en chef sur github, semble bien disposé à appliquer les patches et suggestions qui gravitent autour du truc. Ca le fait.

A propos de fork, je viens de mettre le mien à jour. Sans vouloir jouer les caïds (loin de moi cette idée saugrenue ;) je pense que c'est celui qu'il faut puller si vous souhaitez installer le matos sur une machine 32-bit. Car, je le répète, HipHop est 64-bit only, au moins pour un certain temps. De plus, je n'ai rien ajouté ou modifié à l'artillerie de CMake par rapport au code de facebook pour que le wiki officiel concernant la partie installation reste pertinent.

Un conseil: Installer les dépendances à la main, c'est à dire en récupérant les tarballs sur leurs sites respectifs. Ensuite, procédez aux installations avec un --prefix=$HOME/hiphopdep (ou un truc du genre). Le principe est de placer ces dépendances dans un répertoire isolé et ne rentrant pas en conflit avec quelque système de packages que ce soit. De toute manière il vous faut patcher libcurl et libevent, on n'y coupera pas. Une fois que tout est soigneusement installé, bien penser à mettre $HOME/hiphopdep/bin dans votre PATH (si vous avez installé des programmes tels que re2c ou flex) et faire un export CMAKE_PREFIX_PATH=$HOME/hiphopdep avant de lancer CMake. Normalement, ça devrait bien se passer.

Maintenant, à part compiler le bordel, compiler du php et lancer des servers ou des daemons, je n'ai pas encore eu le temps de vraiment me pencher sur ce que fait HipHop et comment ça marche, autre que les généralités librement disponibles.

Avec un peu de chance, je devrai avoir du temps dans les prochains jours pour m'adonner à l'un de mes hobbies, à savoir glandouiller devant des lignes de codes et attendre qu'une idée ou une illumination surgisse comme par enchantement. Elle est pas belle la vie ? ;)

Je rentre du taff (oui je bossais ce samedi), et que vois-je, les sources de HipHop sont dispo sur github! C'est cool. J'ai donc entrepris de tester la bête mais ce ne fut pas sans embuches...

A la base ma machine de jeux est un Macbook Pro 13" avec OSX 10.6. Ayant parcouru le wiki ces jours précédents, je savais que je n'allais pas tenter d'installer le bordel sur OSX à cause de libcap. En effet, imposible d'installer cette lib qui est trop linux-centric. Par contre, sous le coude j'ai un server qui tourne sous Slackware en 32-bit. Un des avantages de Slackware est que si ça merde, alors c'est de notre faute. Cette distrib est très archaïque et c'est la raison pour laquelle je l'ai choisi: j'aime bien quand ça merde ;)

Et ça a merdé quand même pas mal.

Pour les dépendances, pas de problèmes. Bien penser à patcher libcurl et libevent avec les diffs fournis dans le source tree de HipHop. Le plus gros problème a consisté à trouver le lien pour choper les sources de Intel® Threading Building Blocks (Intel® TBB). Un sacré paquet de ®, désolé. Et bien le lien le voila. Prendre le .src.tgz.

Ensuite, il suffit de suivre le wiki, puis on arrive au moment où on lance cmake. Si ça commence à déconner chez vous à partir de là, ne pas hésiter à modifier les fichiers concernés dans le répertoire CMake pour que le système puisse correctement trouver vos librairies. Au préalable, bien penser à définir CMAKE_PREFIX_PATH comme stipulé dans le wiki.

Ensuite, make. Là bison 2.4 générait des erreurs pour cause de grammaires mal formées. Il y a plusieurs oublis de ";" dans divers fichiers y. Les lignes concernées sont indiquées dans les messages.

Le gros du travail ensuite a été de fixer de manière incrémentale (make, erreur, fix, make, ok, erreur, fix, make...) toutes les parties du code qui concerne le 64-bit parce que, en fait, HipHop est 64-bit only à l'heure actuelle. Franchement j'ai passé 3 heures à faire ça. Relancer make à chaque fois. Ca m'a tellement gonflé que de une, mes corrections sont plus qu'hasardeuses, et de deux, je n'ai pas pris soin de glisser des #ifdef/#endif pour conserver le code original et pouvoir jouer avec des defines. Au début, trop optimiste probablement, j'ai pensé que seul util/hash.h était concerné. Une grossière erreur ;) Pour info, une bonne partie des fixes consiste à ajouter le suffix ll aux literals, ainsi que de transformer des ssize_t en long int [1].

Finalement, et là je peux vous dire que je balisais, le linker a paqueté tout ça sans encombre. J'en avais plein le cul. J'ai pushé sur github mes modifs temporaires et d'ailleurs au moment où je rédige ce billet, d'autres forks pour 32-bit sont en cours d'élaborations.

Un echo "hello world, bastard\n" vaut mieux qu'un long discours:

[1]: J'ai repris mes modifs et wrappé les parties concernées entre #ifdef/#endif. C'est censé compiler indifféremment sur 32 ou 64-bit. Mon fork a été mis à jour.

En vrac:

XHP

J'en parlais dans mon billet précédent, et bien c'est chose faite, mes patches ont été mergés dans la branche master du projet sur github. Maintenant quant à réellement utiliser l'extension, là franchement je n'ai rien fait mis à part lancer la tests suite.

HipHop

Toujours dans un autre billet, j'avais émis l'hypothèse que le code source de HipHop ne serait pas releasé de si tôt. J'ai l'impression que ça se confirme. D'une part parce que leur build system et les dépendances sont trop spécifiques à l'environnement de facebook et d'autre part parce que la team semble vouloir releaser un produit en mesure de fonctionner out of the box avec des projets aussi populaires que WordPress ou PHPUnit. C'est pas mal quand même. Si le bordel est capable de faire tourner PHPUnit alors y a de bonnes chances que beaucoup d'autres projets le soient également. Plus d'info dans le wiki ainsi que dans un post de Scott MacVicar sur le google group. Au passage on y apprend que la dernière version de boost est finalement supportée. C'est une bonne nouvelle.

Design du blog

Ce blog arbore un tout nouveau design à la con, je suis d'accord. Je ne pense pas qu'il va rester en place bien longtemps. C'était juste pour tester quelques trucs CSS3 de base. De plus, je n'ai à moitié aucune idée de comment toute cette daube se comporte dans IE et Opera (en fait, si, j'en ai une vague idée).

Parser de tweets

Je me suis enfin remué le cul pour implémenter un parser de tweets pour ce site qui prenne en charge les at, hash tags etc. Bon, c'est du rapidos, OK. En fait je me suis aperçu qu'il n'existe pas vraiment de lib de parsing de tweets en C++. Un de ces 4 je détaillerais le fonctionnement de ce site, notamment comment ça se fait que le backend est en C++.

Beaucoup de choses ont été dites à propos du truc révolutionnaire que facebook nous préparait pour php. Les spéculations sont allées bon train. On a eu droit à du JIT (très en vogue actuellement, notamment grace à LLVM), une réécriture du runtime de php, j'en passe et des meilleurs.

Finalement, l'info officielle est tombée le 2 fev via un post du lead developer en personne, Haiping Zhao. Inutile de vous dire que ce mec là, aux allures très sympathiques par ailleurs, va être soit adulé soit haï par toute la communauté php, du simple rédacteur de templates aux membres les plus influents du PHP Group.

OK. Donc le truc s'appelle HipHop for PHP (lien de github, qui n'existe pas encore à cet instant précis). Je ne vais pas revenir sur ce que l'on apprend à partir du post officiel de Haiping. Pour ça, je vous conseille ces deux billets en fançais ou encore celui là.

Maintenant, que pouvons-nous dire d'autre sur HipHop? Tout d'abord, j'ai comme l'impression que le code source ne sera pas divulgué de si tôt contrairement à ce que l'on pouvait attendre d'après le post officiel (en fait, j'espère que je me goure). HipHop et toute sa suite doit être une usine à gaz, tout du moins sous sa forme actuelle, c'est à dire spécifique à facebook. Voir les interventions de Scott MacVicar et Haiping Zhao ici et ici sur le google group du projet. HipHop utilise CMake comme build system. SCons ça l'aurait mieux fait quand même!

Ensuite, comme attendu, toutes les extensions de php (standard et tiers) doivent être réécrites. Haiping dévoile une liste du travail déjà accompli. Un peu plus bas dans cette même thread, on apprend que PDO sera supporté, tout du moins l'interface pour les quelques drivers les plus utilisés. Je n'ose pas imaginer le chantier que ça doit être. Un travail de forçat. Toujours plus bas, il parle d'une extension memcache maison qui devrait également être mise à disposition du public (avide de sensations fortes?).

Pour ceux qui ne dorment plus depuis l'annonce du non support de eval() dans HipHop: lâchez les calments et les somnifères, la fonction est déjà implémentée et fonctionne en partie via HPHPi (l'interpreter). Inutile de dire qu'il vaut mieux s'en passer et qu'il n'a pas fallu attendre HipHop pour ça! Même chose concernant create_function('with literal string'), c'est bon, ça fonctionne.

Autres goodies, et non des moindres car potentiellement très utile: FFI ou comment générer des librairies statiques et dynamiques (.a et .so) à partir de sources php pour un interfaçage avec d'autres langages (apparement avec SWIG). Source. Imaginons que ça fonctionne bien. Putain, ça le fait carrément!

Personnellement, j'attends avec impatience la release du projet, et je suis parfaitement détendu, probablement parce que je n'ai rien à perdre ni à gagner: je ne suis pas un développeur php ;) J'imagine une certaine angoisse latente chez les responsables de frameworks (Symfony, Drupal etc). Est-ce que ça va compiler? Dans quelle proportion va-t-on devoir réécrire notre code? Qui est le connard qui a insisté pour utiliser eval()? J'ai comme l'impression que certaines roadmaps vont subir quelques légers bouleversements...

En tout cas, je note une chose: C++, tu es vraiment le meilleurs ;)