Après septembre et ses 625 mails, voici mon dépilage d’internals@ pour le mois d’octobre 2013, qui est arrivé à un total de 562 messages.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Depuis quelques mois, de nombreuses RFC ont été rédigées, visant PHP 5.6.

David Soria Parra, RM de PHP 5.4 et co-RM de PHP 5.5, a annoncé que, pour s’en tenir au planning prévu, PHP 5.6 devrait sortir en version stable dans 10 mois (c’est une coïncidence, mais cela permettrait à PHP 5.6 d’être inclue dans la prochaine Debian Stable, prévue pour dans 14 mois) — et que les dernières versions sorties avaient montré qu’il fallait environ 5 mois pour stabiliser une version et passer les phases alpha/bêta/RC.

Son mail indiquait qu’il était donc temps de commencer à réfléchir à l’organisation de la sortie de PHP 5.6, ainsi que de penser à trouver un RM pour cette version, afin qu’il ait déjà le temps d’apprendre sur PHP 5.5 — par la suite, plus de précisions sur le rôle du RM ont été données. Après quelques discussions, il est ressorti que les deux RM de PHP 5.6 seront Julien Pauli et Ferenc Kovacs.

En toute fin de mois dernier, Joe Watkins a annoncé avoir commencé à travailler sur la RFC: Nested Classes, qui pourrait par exemple être pratique pour les développeurs de bibliothèques ne souhaitant pas exposer certaines classes censées être utilisées uniquement en interne.

L’idée étant un peu complexe et demandant probablement plus de réflexion, Joe Watkins a fini par se demander si elle n’attendrait pas PHP 5.7, afin de ne pas arriver à une fonctionnalité pas assez réfléchie pour PHP 5.6.

En parallèle, il a annoncé l’ouverture des votes pour la RFC: Anonymous Classes — qui a finalement a été rejetée, avec 23 votes contre pour 9 votes pour.

Michael Wallner a noté que les variables super-globales $_GET et $_POST pouvaient être source de confusion, puisqu’elles peuvent être renseignées plus ou moins indépendamment de la méthode HTTP utilisée (Johannes Schlüter a par la suite fait remarquer que ces noms de variables correspondaient à ce qui est utilisé pour les formulaires HTML). Il a donc proposé de renommer $_GET en $_QUERY, et $_POST en $_FORM ; et, au passage, d’exposer les analyseurs de corps de requête à l’espace utilisateur, et de les déclencher indépendamment de la méthode HTTP utilisée.

Comme l’a rapidement fait remarquer Alexey Zakhlestin, ce renommage de variables casserait la quantité énorme de code les utilisant — mais les deux autres idées seraient intéressantes. Il n’était d’ailleurs pas le seul de cet avis.

Notons tout de même qu’exposer des parsers supplémentaires, si ce choix est retenu, doit être fait avec prudence : comme l’a rappelé Nikita Popov, cette idée a déjà mené à des vulnérabilités dans d’autres langages.

Joe Watkins a lancé un sujet de conversation, où il essayait d’attirer l’attention sur le fait que les assertions de PHP sont assez pauvres — d’ailleurs, est-ce que cela ne serait pas une raison pour laquelle elles sont si peu utilisées ?

Après quelques discussions tournant notamment autour de la levée d’erreur ou d’exceptions, Joe Watkins a annoncé avoir rédigé la RFC: Expectations¹. Avec 50 mails dans la conversation, sans compter les échanges sur la discussion précédente, c’est visiblement le sujet qui a le plus attiré l’attention ce mois-ci.

Les premiers retours ont semblé être plutôt positifs, même si l’introduction d’un nouveau mot-clef expect pourrait causer des problèmes de compatibilité.

Suite à un mail où Derick Rethans faisait remarquer que la RFC n’apportait aucune indication quant à l’utilité de cette proposition par rapport à assert(), il a été répondu que la fonctionnalité aujourd’hui apportée par assert() était peu performante, et qu’elle ne pouvait pas être désactivée facilement en environnement de production, assert() étant une fonction et non une construction langage associée à un opcode. Joe Watkins a aussi apporté en réponse des précisions sur l’aspect erreur vs exception.

Les échanges s’étant fait plus rares en fin de mois, il y a des chances que cette RFC soit ouverte au vote sur les prochaines semaines.

Rowan Collins a proposé de marquer la fonction create_function() comme obsolète, considérant que le gros des usages (mais pas tous) pouvaient, depuis PHP 5.3, être remplacés par des utilisations de fonctions anonymes.

En effet, comme l’a souligné Nikita Popov, passer par create_function() est lent, consomme de la mémoire, et introduit parfois un risque en termes de sécurité.

Cela dit, Pierre Joye a répondu que de nombreuses fonctionnalités des versions récentes de PHP permettent d’écrire du code plus propre que celui que nous écrivions par le passé, mais que ce n’était pas une raison suffisante pour lever des notices partout — d’autant plus que create_function() est assez fortement utilisée, et fonctionne. Dans le même temps, supprimer cette fonction (ce qui est une suite logique, une fois qu’elle a été marquée comme obsolète ; mais ce serait pour PHP 5.7 ou plus, donc dans plusieurs années !) serait problématique pour des projets acceptant encore PHP 5.2 — Ryan McCue a ainsi noté que pour Wordpress, en cas de suppression de PHP, cette fonction devrait être ré-implémentée côté utilisateur (ce qui ne l’a pas empéché, sauf erreur d’interprétation de ma part, de trouver la proposition intéressante).

Nikita Popov a annoncé avoir rédigé la RFC: Exceptions in the engine, dont le but est de permettre la levée d’exceptions depuis le moteur de PHP, et de remplacer certaines Fatal Error par des levées d’exceptions.

Il a ensuite répondu à ceux qui s’inquiétaient des possibles impacts au niveau de la compatibilité entre versions de PHP, en soulignant que, quoi qu’il en soit, une Fatal Error ne correspondait déjà pas à un fonctionnement normal ni souhaité d’un programme. Autrement dit, le seul changement qui serait visible correspond à un cas où un script ne fonctionnait déjà pas.

Plusieurs ont indiqué trouver l’idée extrêmement intéressante, voulant même parfois aller plus loin que le remplacement de seulement quelques erreurs fatales — ce qui serait, pour le coup, un gros changement avec un impact massif en termes de compatibilité.

Dans le même temps, certains ont noté qu’il n’était peut-être pas urgent d’effectuer ce type de modification². Le sujet d’une éventuelle version de PHP 6.x a donc recommencé à surgir : il permettrait de mettre en place, petit à petit, ce type de modifications potentiellement impactantes, tout en ne gelant pas l’arrivée de modifications plus mineures via des versions comme PHP 5.6 et 5.7.

Andrea Faulds a annoncé avoir rédigé la RFC: list() Reference Assignment, qui permettrait d’utiliser une syntaxe de ce type :

$array = [1, 2];
list($a, &$b) = $array;

A la place (comme raccourci, donc) de la syntaxe suivante :

$array = [1, 2];
$a = $array[0];
$b = &$array[1];

Cela aidera sans doute ceux d’entre nous qui travaillent sous Windows : Anatol Belski a annoncé que les builds pour Windows d’extensions PECL étaient maintenant référencés directement depuis les pages de chaque extension (par exemple, pour solr ou pour APC) — et ce pour une centaine d’extensions sur les environs 300 hébergées par PECL.

Benjamin Schneider a proposé d’ajouter une nouvelle exception, InvalidStateException, à l’extension SPL (Guilherme Blanco a répondu qu’elle pourrait être nommée IllegalStateException). Levi Morrison a fait remarquer que la partie exceptions de la SPL n’était pas des plus structurées, et qu’il pourrait être intéressant de mener une réflexion plus approfondie avant d’ajouter une nouvelle classe — il existe d’ailleurs la RFC: SPL Improvements sur le sujet depuis 2011, mais elle introduirait pas mal d’incompatibilités ; une seconde RFC, RFC: SPL Improvements: Exceptions se concentre, elle, sur les exceptions.

De son côté, Lior Kaplan a continué à poster régulièrement ses rapports sur l’état des Pull Requests faites sur le projet PHP.

Daniel Lowrey a quant à lui annoncé avoir rédigé la RFC: TLS Peer Verification. Il n’y a pas vraiment eu de retour autour de cette proposition ni des autres points qu’il évoquait dans son mail ; peut-être sur les prochaines semaines ?

La RFC: Extended keyword support dont j’avais parlé le mois dernier a été ouverte aux votes — et a été rejetée. Il est à noter que plusieurs votants ont expliqué pourquoi avoir voté non — ce qui est une bonne chose.

Yasuo Ohgaki a annoncé avoir rédigé la RFC: Make session_regenerate_id()’s delete_old_session parameter required gracefully, en vue d’améliorer la sécurité des sessions.

Andrea Faulds a implémenté les fonctions apache_request_headers() (aussi aliasée sous le nom plus générique getallheaders()) et apache_response_headers() pour le serveur web de test intégré à PHP. Même si ce serveur web n’est pas Apache, ces deux fonctions permettent de le rapprocher des autres SAPI.

Dmitry Stogov a proposé deux patchs éliminant des copies inutiles de variables dans array_merge() et func_get_args(), rendant par exemple la page d’accueil de Wordpress 2% à 4% plus rapide. Voici deux petites optimisations qui pourraient trouver leur place dès PHP 5.5 ! Dans la foulée, il a aussi proposé un patch qui éliminerait quelques appels au Garbage Collector.

Après le départ d’Anthony Ferrara il y a quelques semaines/mois et le retrait des RFC qu’il avait rédigé, Andrea Faulds a annoncé avoir réouvert la RFC: Constant Scalar Expressions. Peu de réaction pour l’instant, mais peut-être dans les prochaines semaines…

Oh, et pour finir, tant que j’y pense et en sortant un peu du sujet : j’ai profité de ce week-end de trois jours pour lancer une collecte de données, qui devrait me permettre de prochainement publier un article “Statistiques de versions de PHP” — le dernier remontant à janvier, il date un peu, et une mise à jour ne peut que faire du bien !

Et pour finir avec un peu d’auto-publicité : si le sujet vous intéresse, vous pouvez demander à être prévenu lorsque je publierai le livre électronique Développer une Extension PHP sur lequel je travaille régulièrement.

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.

Depuis quelques années, j’ai occasionnellement l’occasion de discuter du sujet du développement d’extensions PHP avec des collègues ou d’autres développeurs (lors d’aperos, de conférences, …), et il ressort souvent de la discussion que le sujet est intéressant, que certains d’entre nous ont envie d’essayer, ne serait-ce que pour le plaisir et par curiosité, mais que l’idée semble effrayante et qu’il y a comme un manque de documentation.

En parallèle, je crois que la première fois où j’ai développé une extension était lors d’une demi-journée organisée par l’AFUP Paris en 2011, où le sujet avait été présenté par Julien Pauli et Patrick Allaert¹, sous forme d’une rapide introduction théorique suivie par une après-midi de pratique — et j’avais trouvé ça plutôt sympa.

Depuis, je n’hésite plus à aller fouiller de temps en temps dans le code de PHP², et je me suis rendu compte que, même si je n’avais pas réellement codé en C depuis une petite dizaine d’années³, j’arrivais globalement à comprendre ce qu’il se passe⁴… Et avec le temps qui passe, ça a de plus en plus titillé ma curiosité ^^

J’ai donc fini par m’y mettre de plus en plus, en commençant par le classique “Hello World!” et en avançant petit à petit, tout en me disant qu’il pourrait être intéressant de prendre quelques notes, et de les partager — ce qui me donne aussi une raison de fouiller plus que je n’en ai parfois besoin sur le coup, rendant l’exercice encore plus enrichissant pour moi.

Résultat, j’ai commencé à écrire ce qui est en train de devenir un livre électronique, en français, à propos du développement d’Extensions PHP : en l’état actuel, 10 chapitres sont rédigés (ils représentent 225+ pages, soit 50,000+ mots), et 5 chapitres supplémentaires sont prévus mais pas encore commencés.

Ce livre sera distribué (en PDF/EPUB/MOBI) par le biais du site Leanpub, et en suivant la logique du Manifesto correspondant⁵, je le publierai alors qu’il ne sera pas encore achevé, et le mettrai ensuite à jour au fur et à mesure de l’écriture des évolutions et chapitres suivants, et/ou des corrections éventuelles.

En attendant cette publication prochaine, vous pouvez dès maintenant signaler votre intérêt et demander à être prévenu lors de la publication du livre : Développer une Extension PHP.

Voici quelques informations sur les sujets couverts par les chapitres déjà rédigés, qui devraient vous permettre de faire vos premiers pas dans le développement d’extensions PHP :

• Création d’une première extension : il s’agit du premier chapitre du livre, qui est reproduit intégralement dans l’aperçu disponible au téléchargement. J’y explique comment créer le squelette d’une première extension, quels fichiers sources sont requis, et quelles structures de données et déclarations sont nécessaires.
• Environnement de développement : ce chapitre montre comment compiler une version de PHP orientée développement d’extensions et quelles sont les informations qu’elle nous apporte. J’en ai profité pour présenter comment configurer Eclipse CDT pour obtenir un environnement de développement avec débugger graphique.
• Écrire une fonction : les fonctions sont au cœur de PHP et de ses extensions. Nous verrons ici, entre autres, comment recevoir des paramètres et retourner une valeur. Ce sujet est abordé au travers de deux chapitres, le second intégrant des concepts supplémentaires, comme la réception de zval en paramètres, les fonctions attendant un nombre d’arguments variable, ou encore le type-hinting.
• zval : les variables de PHP : les variables de PHP sont représentées, en interne, par une structure nommée zval. Ce chapitre nous montrera comment en créer, les lire et les manipuler.
• HashTable et tableaux : la structure HashTable est utilisée par PHP pour stocker un ensemble de données, comme un tableau. Elle est tellement importante pour PHP qu’elle est fréquemment utilisée en interne, et que de nombreuses fonctions permettent de la manipuler.
• Configuration par fichier .ini : le fichier php.ini représente, pour PHP et pour ses extensions, le standard de configuration permettant aux utilisateurs d’influencer sur leur comportement. Ce chapitre présentera comment exploiter au mieux cette possibilité de paramètrage.
• Tests automatisés : vous n’envisageriez pas de développer une extension sans tests automatisés ? Moi non plus !
• Quelques points divers : ce chapitre regroupe quelques points intéressants, mais qui ne méritaient pas à un chapitre à eux seuls, comme la déclaration de variables super-globales, de constantes, ou la personnalisation de phpinfo(). Ce chapitre est lui aussi reproduit intégralement dans l’aperçu disponible au téléchargement.

J’ai prévu d’aborder d’autres sujets, pour lesquels je n’ai pas encore commencé la rédaction.
Je pense en particulier aux points suivants :

• Classes et objets
• Travailler avec les flux
• Développer une extension PHP sous Windows
• Les ressources
• Gestion de la mémoire

Une fois le livre publié, il sera mis à jour au fur et à mesure de la rédaction, entre autres, de ces chapitres — l’ordre dans lequel ils figurent ici n’étant en rien indicatif de leur ordre de rédaction.

Pour vous donner une idée de la vitesse à laquelle j’écris : j’ai commencé à réfléchir à ce projet il y a plus d’un an, mais je n’ai commencé à écrire qu’en février 2013, ce qui représente en gros une moyenne d’un chapitre par mois. Cela dit, j’écris à une allure variable, puisque j’ai fait une quasi-pause de plusieurs mois à un moment, alors que j’ai écrit un chapitre en une semaine et deux week-ends à un autre moment ; et sur les 245 jours écoulés depuis la création du repository hébergeant ce projet, j’ai été actif 80 jours (soit 32.7% du temps).

Après août, second mois des vacances d’été, raisonablement calme avec 451 mails, voici mon dépilage d’internals@ pour le mois de septembre 2013, qui a vu plusieurs discussions animées, et a re-passé pour la première fois en six mois la barre des 500 mails, arrivant à un total de 625 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Johannes Schlüter a rédigé un mail où il a listé les différentes évolutions et versions que PHP a connu depuis PHP 5.2 en 2006 : cela commence à en faire une bonne petite liste, qui font de PHP un langage qui évolue vite depuis quelques années — surtout si on compare son évolution à celles de C, C++, ou JAVA.

Ces évolutions sont une très bonne chose pour la plupart d’entre nous, mais deux problèmes se posent, en termes de maintenance :

• D’une part, les nouvelles versions de PHP ne sont adoptées que lentement,
• Et là où pas mal d’attention est concentrée sur les évolutions, en face, les bugs s’empilent (aujourd’hui, il y a environ 4000 tickets ouverts).

En conséquence, il serait probablement profitable de ralentir un peu le rythme des évolutions pendant quelques mois, pour consacrer un peu plus d’énergie à la maintenance de l’existant — maintenance nécessaire pour assurer la viabilité de notre langage de prédilection !

Stas Malyshev a annoncé avoir mis à jour la RFC: Skipping optional parameters for functions, qui permettrait d’invoquer une fonction sans avoir à spécifier de valeur pour ses paramètres optionnels non situés en fin de liste d’arguments :

// Déclaration de fonction 
function create_query($where, $order_by, $join_type='INNER', 
    $execute = false, $report_errors = true) {
    // ...
}

// Appel sans passer les 3ème et 4ème paramètres,
// qui prendraient leur valeur par défaut, spécifiée
// lors de la déclaration de la fonction
create_query("deleted=0", "name", default, default, /*report_errors*/ true);

Une proposition serait de ne pas du tout spécifier de valeur, plutôt que de réutiliser le mot-clef default, mais cela pourrait nuire à la lisibilité.

Bien sûr, comme l’a fait remarquer Florin Patan (qui n’est pas le seul de cet avis), implémenter une fonctionnalité de paramètres nommés résoudrait aussi ce problème ;-)

Au bout de quelques jours, la discussion s’est essouflée, et n’a pas avancée depuis plus de trois semaines.

Dans la foulée, Nikita Popov a annoncé avoir commencé à travailler sur la RFC: Named Parameters.

Cette idée de paramètres nommés est assez fréquemment évoquée depuis pas mal de temps (c’est une syntaxe qui existe notamment en Python, si j’ai bonne mémoire), et les premiers retours ont clairement indiqués que l’idée semblait intéressante pour beaucoup d’entre nous.

Au niveau des réserves, certains ont noté que cela signifie que les noms de paramètres ne devraient plus être modifiés une fois une bibliothèque publiée, et qu’il ne faudrait pas que cela encourage les développeurs à mettre en place des fonctions prenant trop d’arguments.

Bien sûr, il faudrait s’assurer que cette nouvelle possibilité syntaxique n’a pas d’impact négatif au niveau des performances (à première vue, ça semble correct),

Les discussions ne sont pas terminées, la syntaxe elle-même n’étant pas encore définie, de même que les erreurs pouvant être levées ou même le périmètre fonctionnel précis souhaité — plusieurs éléments de réponse ont été apportés par Nikita Popov dans ce mail. En tout cas, je suis curieux de voir l’évolution de cette propositions sur les prochains semaines !

Joe Watkins a annoncé avoir rédigé la RFC: Anonymous Classes, qui introduit le même type de fonctionnalité que les fonctions anonymes arrivées en PHP 5.3, mais pour des classes.

En copiant-collant un exemple d’idée postée par Michael Wallner, la syntaxe pourrait ressembler à quelque chose de ce type :

$subject->attach(new class implements SplObserver {
    function update(SplSubject $s) {
        printf("Got update from: %s\n" $subject);
    }
);

Bien sûr, cette proposition a levé la question de l’utilité d’une telle possibilité, et des cas d’utilisation correspondant (cette possibilitée est fréquemment utilisée en JAVA, par exemple, où des objet anonymes implémentant une interface peuvent être utilisés comme callbacks). S’est aussi posée la question de la sérialisation/désérialisation d’un objet instance d’une classe non-nommée.

La RFC a été enrichie suite aux discussions, et des ajouts complémentaires comme l’imbrication de classes sont déjà évoqués (mais probablement sous forme d’autres RFC). Je suis curieux de voir l’évolution de ce sujet sur les prochains mois.

D’ailleurs, alors que le mois touchait à sa fin, Joe Watkins a annoncé avoir rédigé un premier brouillon pour la RFC: Nested Classes. Faute de temps, celle-ci n’a pas encore été réellement discutée ; mais là encore, nous verrons dans les prochaines semaines les réactions que le sujet ne va pas manquer de lever !

La RFC: Syntax for variadic functions dont je parlais le mois dernier a été soumise aux votes. Avec 36 votes pour et 1 vote contre, elle est passée !

PHP 5.6 devrait donc supporter la syntaxe suivante (exemple repris de la RFC) :

class MySQL implements DB {
    public function query($query, ...$params) {
        $stmt = $this->pdo->prepare($query);
        $stmt->execute($params);
        return $stmt;
    }
    // ...
}

Ici, la syntaxe ...$params indique que query() est une fonction variadique, et que tous les arguments suivant $query doivent être placés dans le tableau $params.

Bob Weinand a annoncé avoir développé un patch qui permettrait d’utiliser des mot-clefs comme identifiants¹(noms de fonctions / classes, étiquettes, …) ; cela réduirait l’impact de la liste de mot-clefs réservés.

Les retours ont été plutôt positifs dans l’ensemble, nombreux développeurs souhaitant parfois utiliser une partie de ces mots-clefs (comme list, par exemple) ; et les tests effectués n’ont pas mis en évidence d’impact significatif sur les performances. Cela dit, comme l’a souligné Johannes Schlüter, PHP se retrouverait alors avec deux listes de mots-clefs, certains pouvant être utilisés à certains endroits et pas d’autres — ce qui risque de complexifier les choses pour les utilisateurs, par rapport à une unique liste de mots-clefs ne pouvant être employés nulle part.

La modification n’étant pas réellement mineure, et la discussion identifiant plusieurs points sur lesquels plus de réflexion semblait nécessaire, Pierre Joye a finalement proposé qu’une RFC soit rédigée à ce sujet — et donc, Bob Weinand a rédigé la RFC: Extended keyword support.

Gordon Oheim a rédigé la RFC: Automatic Property Initialization, où il proposait qu’une écriture du type suivante :

class Point 
{
    private $x, $y;

    public function __construct($x, $y)
    {
        $this->x = $x;
        $this->y = $y;
    }
}

Puisse être remplacée par une syntaxe alternative, plus courte :

class Point
{
    private $x, $y;

    public function __construct($this->x, $this->y);
}  

Il n’y a pour l’instant eu que peu de retours sur cette proposition, qui a semblé être appréciée, même si la syntaxe peut sembler surprenante — et qu’une autre solution serait d’implémenter la fonctionnalité d’accesseurs qui avait été discutée il y a quelques mois.

Plus ou moins suite au départ d’Anthony Ferrara au tout début du mois, Florin Patan a posté un mail intitulé “Wake up”, où il soulignait le fait que le développement de PHP n’est pas aussi ouvert d’esprit qu’il le pourrait.

Une des premières suggestions qui est remontée évoquait l’idée de passer de la mailing-list internals@ à un forum, qui, possiblement, faciliterait les échanges. Sans surprise, cette idée n’a initialement pas été fort bien accueillie par tout le monde (avec un logiciel de messagerie correct, une mailing-list est utilisable ; à condition que ses membres suivent l’étiquette qui va bien). D’un autre côté, un forum pourrait permettre, par un système de votes, de mettre en évidence les discussions intéressantes, tout en poussant vers le bas les échanges moins constructifs et en permettant d’ignorer plus facilement les posts hors-sujet.

Cela dit, Terence Copestake a peut-être cerné une partie du problème, lorsqu’il a souligné qu’il y avait un conflit entre ceux qui voulaient que PHP reste un langage simple et accessible, et ceux qui voulaient en faire un outil/environnement professionnel complet — les deux visions s’opposant, sans personne pour réellement trancher.

Peut-être faudrait-il aussi que, comme le disait Jordi Boggiano, chacun respire un grand coup avant de répondre à un point qui les a énervé…

En rebondissant sur ce qui s’était dit sur le sujet précédent, Andrea Faulds a lancé un autre sujet de discussion, à propos de cette idée de forum ; une solution mélant hiérarchie et système de votes pourrait d’après lui compléter internals@. Pour éviter de couper les conversations entre ceux utilisant un système et ceux restant sur l’autre, il faudrait une synchronisation entre les deux mécanismes, ou même que la solution de forum agisse comme une surcouche à internals@.

C’était en toute fin de mois dernier, donc je n’en n’ai pas parlé à ce moment là : Johannes Schlüter a fait remarquer que, en l’état, windows.php.net n’était pas des plus utiles (pas à jour, downloads ne passant pas par les mirroirs, …). Après avoir répondu à pas mal des questions posées, Pierre Joye a aussi annoncé que du travail était en cours sur la construction automatique pour Windows des extensions PECL. Un peu dans la même veine, PHP 5.2, qui a atteint son EOL il y a plusieurs années, a été retirée de la page de téléchargements de windows.php.net.

Nikita Popov a annoncé avoir terminé la rédaction de la RFC: Argument Unpacking, reprenant une idée qui existe, par exemple, en Python, Ruby, ou Javascript — et faisant assez logiquement le lien avec la RFC: Syntax for variadic functions, passée un peu plus tôt. Cette RFC est arrivée en fin de mois, et n’a vu que peu de discussions (ce qui est souvent bon signe) ; à suivre dans les prochaines semaines, donc.

Comme sur les mois précédents, Lior Kaplan a continué à poster régulièrement des mails résumant l’activité autour des Pull Requests faites sur PHP.

Suite aux discussions du mois dernier à propos de l’implémentation d’un nouveau serializer, Jakub Zelenka a mis à jour la RFC: Internal Serialize API.

La RFC: Change crypt() behavior w/o salt a été ouverte aux votes. La période de votes n’est pas terminée, mais il semblerait que les choses s’orientent vers la levée d’une notice dans le cas d’un appel à crypt() en omettant le paramètre $salt.

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.

Toutes les fin de mois¹, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

L’apéro du 25 septembre 2013 était un peu particulier, puisqu’il a réuni des développeurs PHP et des développeurs Python, un développeur de chacune des deux communautés présentant son langage aux développeurs de l’autre communauté.

Les slides que j’ai utilisés comme support pour présenter PHP aux développeurs Python sont disponibles en ligne² : Présentation de PHP, pour des développeurs Python.

Les slides utilisés par Arthur Vuillard, qui a fait la présentation inverse, sont eux aussi disponibles : Python pour les dévs PHP.

Au cours de cet article, je vais expliquer comment installer OpenGrok, un logiciel permettant de naviguer dans du code source, et d’effectuer des recherches dessus, depuis une interface web.

Mais pourquoi un indexeur de code-source ?

Il m’arrive fréquemment d’avoir besoin de naviguer dans du code source qui n’est pas actuellement ouvert dans mon IDE ; en particulier, je pense aux situations suivantes :

• Je ne suis pas à mon poste, et je n’ai pas accès à un IDE, ou même au code-source :
  • Par exemple, je veux montrer une portion de code à un collègue (qui peut travailler sur un autre projet que moi, et ne pas avoir sur son poste le code-source de mon projet),
  • Ou je suis en intervention depuis un autre PC que le mien, sans accès au code-source de l’application que je dépanne (autre qu’un vim dans un terminal), et ai besoin de chercher la cause d’une erreur (et sur des centaines de milliers de lignes, grep est parfois quelque peu insuffisant),
• Ou je suis en pleine revue de code sur un diff correspondant à une application autre que celle sur laquelle mon IDE est ouvert, et souhaite voir comment est implémentée une classe que je vois être utilisée,
• Ou encore, je souhaite accéder à une portion de code sur une autre branche de l’application sur laquelle je travaille, mais sans vouloir prendre le temps de checkouter cette branche,
• Voire même, je veux rechercher tous les usages d’une fonction dans le code-source d’un projet que je connais mal — et dont je peux même ne pas avoir pas les sources sur moi.

Dans ces types de situations, j’ai besoin d’un outil qui :

• Comprenne du code-source : il doit être capable de déterminer ce qui est une fonction, ce qui est une variable, une classe, …
• Soit accessible en ligne via un navigateur, puisque je peux ne pas avoir le code de l’application sur le PC que j’utilise à un instant donné,
• Soit extrêmement rapide à répondre !
• Et soit capable d’indexer plusieurs projets, éventuellement sur plusieurs branches Git ou SVN différentes.

J’ai découvert il y a plusieurs années lxr.php.net, qui permet d’effectuer des recherches dans le code source de chacune des branches stables de PHP (et je l’utilise régulièrement lors que je travaille au développement ou debugagge d’extensions PHP !). Il s’agit d’une instance d’un logiciel nommé OpenGrok (les sources sont sur Github), basé sur Lucene, et que j’ai depuis déployé plusieurs fois sur mes machines personnelles ou professionnelles.

Installation d’OpenGrok

OpenGrok requiert quelques composants :

• Une version récente de JAVA (1.6 ou 1.7)
• Un conteneur de servlet (Tomcat, par exemple)
• Exuberant Ctags

Sous Debian “wheezy” 7.1, le tout peut s’installer depuis les repositories officiels :

sudo apt-get install exuberant-ctags tomcat6

Si vous avez la JRE d’Oracle installée (typiquement, parce qu’un autre logiciel la requiert), OpenGrok fonctionnera aussi très bien avec.

En fonction des projets à indexer, il pourra aussi être utile d’installer les clients SVN, git, … qui permettront d’extraire les sources à indexer.

Au besoin, le port d’écoute de Tomcat peut être modifié dans le fichier /etc/tomcat6/server.xml — j’utilise généralement le port 8181 pour mon instance d’OpenGrok, le port 8080 (par défaut) étant souvent déjà pris par un autre logiciel. Pour cela, modifiez le bloc suivant :

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           URIEncoding="UTF-8"
           redirectPort="8443" />

En fonction du port que vous avez choisi, et après éventuel redémarrage via sudo /etc/init.d/tomcat6 restart, Tomcat doit être accessible en HTTP (URL à adapter, bien sûr) :

http://192.168.0.13:8181/

Il ne reste plus qu’à télécharger OpenGrok et décompresser le fichier obtenu :

cd /opt/
sudo wget http://java.net/projects/opengrok/downloads/download/opengrok-0.11.1.tar.gz
sudo tar xf opengrok-0.11.1.tar.gz
sudo rm opengrok-0.11.1.tar.gz
sudo mv opengrok-0.11.1 opengrok

Ensuite, déployons l’application web :

cd opengrok/bin
sudo ./OpenGrok deploy

Puis, redémarrons le serveur :

sudo /etc/init.d/tomcat6 restart

Et enfin, l’interface web d’OpenGrok devrait désormais être accessible, sous l’URL /source/ :

http://192.168.0.13:8181/source/

Ce qui doit donner quelque chose de ce type :

Puisque nous n’avons lancé aucune indexation (cf la date d’indexation au 1er janvier 1970 en bas de la page), le logiciel n’est pour l’instant pas encore très utile, et n’affiche aucun projet.

Indexer du code-source avec OpenGrok

Une fois OpenGrok installé, il faut indexer le code-source au sein duquel vous souhaitez pouvoir naviguer et effectuer des recherches.

Pour cela, le code des projets que vous souhaitez indexer doit se trouver sous un même répertoire ; et l’indexation sera lancée sur ce répertoire. Notez qu’il n’est pas possible de spécifier une liste de branches à indexer pour un projet ; à la place, à vous de cloner le projet autant de fois que nécessaire, et de positionner chaque extraction sur la branche souhaitée (ça demande un peu plus de travail de mise en place des sources à indexer, mais ça offre aussi plus de souplesse — et OpenGrok se concentre sur son rôle : l’indexation).

A titre d’exemple, récupérons vers $HOME/projects les sources de trois projets, et positionnons-nous sur les branches qui nous intéressent :

mkdir $HOME/projects

# Sources de PHP master
git clone https://git.php.net/repository/php-src.git $HOME/projects/php-src

# Symfony 1.4
git clone https://github.com/symfony/symfony1.git $HOME/projects/symfony-1.4
cd $HOME/projects/symfony-1.4

# symfony 2.3
git clone https://github.com/symfony/symfony.git $HOME/projects/symfony-2.3
cd $HOME/projects/symfony-2.3
git checkout -b 2.3 origin/2.3

Ensuite, créons le répertoire que OpenGrok utilisera pour stocker les données résultant de l’indexation (je souhaite pouvoir lancer l’indexation avec le compte utilisateur user, d’où le chown) :

sudo mkdir /var/opengrok
sudo chown user:user /var/opengrok

Et enfin, lançons l’indexation du contenu de $HOME/projects, à l’aide de la commande suivante :

/opt/opengrok/bin/OpenGrok index $HOME/projects

L’indexation peut durer quelques temps, et consommer pas mal de ressources. Pour indexer les sources récupérées plus haut, sur une VirtualBox dual-core à 2GB de RAM (sur un système physique Core 2 Quad à 2.8 GHz, 8 GB de RAM, et SSD), il a fallu environ 5 minutes et demies — mais sur des projets beaucoup plus gros, j’ai déjà vu l’indexation durer plus d’une heure !

Utiliser l’interface web d’OpenGrok pour naviguer dans les sources indexées

Une fois l’indexation terminée, la liste des projets (les sous-répertoires de celui sur lequel l’indexation a été lancée) remonte sous forme d’une liste, en haut à droite de l’interface d’OpenGrok :

Le lien xhref permet de naviguer dans l’arborescence du code des différents projets :

Les champs de formulaire en haut à gauche, quant à eux, permettent d’effectuer des recherches de différents types dans les projets sélectionnés :

• Full Search : pour effectuer une recherche textuelle.
• Definition : pour chercher des définitions de variables, fonctions, …
• Symbol : pour rechercher des utilisations de variables, fonctions, …
• File Path : pour spécifier sous quel chemin rechercher.
• History : pour effectuer une recherche dans l’historique de commits.

Les résultats de recherche sont cliquables, avec de multiples liens :

• H donne accès à l’historique du fichier,
• A donne accès aux annotions : pour chaque ligne est indiquée le commit et son auteur (revient à un git blame ou svn blame),
• D permet d’accéder au fichier brut,
• Cliquer sur le nom du fichier permet de le consulter,
• Et enfin, cliquer sur la ligne de code en partie droite permet d’accéder directement à celle-ci.

Une fois que vous êtes sur un fichier, chaque mot-clef, chaque nom de variable, chaque constante, chaque nom de fonction, … tout est cliquable, et permet soit de naviguer vers les définitions (typiquement, pour une fonction ou une variable définie dans le même fichier) ou de lancer des recherches complémentaires.

D’ailleurs : si vous avez cliqué sur un nom de fichier, la recherche sera lancée en utilisant celui-ci comme nom de fichier ; si vous avez cliqué sur nom de fonction, la recherche sera lancée sur la définition de celle-ci ; et ainsi de suite : OpenGrok, lors de sa phase d’indexation, a compris la syntaxe du code-source, et fait donc bien plus qu’un simple grep !

Quelques exemples de recherches et de résultats

Le premier champ Full Text permet d’effectuer une recherche textuelle dans les projets indexés. Je l’utilise parfois pour rechercher, dans les sources de PHP, des définitions de fonctions (qui, fréquemment, sont construites avec une syntaxe de la forme PHP_FUNCTION(nom_de_fonction)) :

Le champ Definition permet de rechercher des définitions (de variables, fonctions, …) correspondant à un motif. Par exemple, si nous saisissons zend_*_parameters dans ce champ, en sélectionnant les sources de PHP comme projet, nous obtiendrons en retour des liens vers les endroits où les fonctions correspondant à ce motif sont définies :

A l’inverse, le champ Symbol permet de rechercher les usages d’un motif (pour une fonction, ses appels ; pour une variable, ses utilisations). Par exemple, en recherchant strlen dans les sources de symfony 2.3, nous obtiendrons un grand nombre de résultats :

Le champ File Path permet de spécifier dans quels chemins rechercher — je l’utilise principalement pour limiter les résultats d’une recherche à un sous-ensemble des sources du projet au sein duquel j’effectue une recherche spécifiée via les autres champs. Par exemple, pour rechercher les utilisations de la fonction strlen() dans les sources de l’extension PDO de PHP, je pourrais utiliser quelque chose de ce type :

Pour finir, le champ History permet de rechercher dans l’historique de commits d’un projet. Par exemple, recherchons la chaîne “bug #55399” (entourée de double-quotes) en utilisant le champ History, sur les sources de PHP. Le résultat obtenu est alors le suivant :

Ces champs peuvent contenir des wildcards comme * pour plusieurs caractères, et ? pour un seul caractère. Ils peuvent bien entendu être combinés, et utilisés pour rechercher sur un seul ou sur plusieurs projets, sélectionnés en partie droite de l’écran.

Pour plus d’informations quant à la syntaxe et aux options utilisables dans les requêtes de recherche, consultez l’URL /help.jsp de votre instance d’OpenGrok :

Quelques conseils, notes, et renvois au manuel formel

Pour finir, voici un peu en vrac quelques conseils et quelques notes — certaines fortement tirées de la documentation, et pas toujours mises en pratique sur mes propres instances d’OpenGrok ^^

Quelques conseils

Comme je le disais un peu plus haut, OpenGrok ne gère pas l’indexation de différentes branches d’un projet, ni la mise à jour de projets depuis votre système de contrôle de sources. A la place, il se concentre sur son boulot : l’indexation. Cela signifie que c’est à vous de mettre en place les projets à indexer, à raison d’un répertoire par projet, en-dessous du répertoire parent de l’indexation.

Pour éviter tout risque d’erreur et automatiser cela, j’ai tendance à utiliser un simple shell-script, qui pull tour à tour les différents projets que je souhaite indexer ainsi que leurs différentes branches, et lance ensuite l’indexation en elle-même.

Sur de gros projets, l’indexation peut durer un bon moment en consommant pas mal de ressources ; j’ai donc l’habitude de lancer ce script d’indexation par cron, la nuit ou le week-end (cela dit, si l’indexation de vos projets est rapide, ça peut aussi tourner pendant une pause café ou entre les midis, et sauver un pingouin en évitant de laisser le PC allumé la nuit).

Les extractions des différents projets et des différentes branches, ainsi que les indexes générés par OpenGrok, peuvent finir par prendre pas mal d’espace disque ; prévoyez donc de les placer sur un disque volumineux — si vous avez un HDD et un SSD, il est probablement peu utile de mettre tout ça sur le SSD ;-)

Aussi : j’ai tendance à indexer une extraction propre de projets, et jamais mon espace de travail courant (qui est souvent positionné sur une branche de développement, pas forcément “propre” au moment où l’indexation est susceptible de se lancer).

Et enfin : en fonction des projets, vous voudrez peut-être récupérer des dépendances externes (par exemple, via composer), ou effacer des fichiers sur lesquels vous n’aurez jamais besoin d’effectuer de recherche (par exemple, des fichiers de données ; ou, des fois, les tests unitaires), avant de lancer l’indexation.

Modifier le répertoire de données

Pour stocker les données d’OpenGrok (résultat de l’indexation) ailleurs que dans le répertoire par défaut /var/opengrok, renseignez un autre chemin via la variable d’environnement OPENGROK_INSTANCE_BASE ; par exemple, pour lancer l’indexation :

OPENGROK_INSTANCE_BASE=/mnt/data/opengrok \
    /opt/opengrok/bin/OpenGrok index $HOME/projects

Considérant que cela changera l’emplacement du fichier de configuration, vous aurez à créer un lien symbolique entre l’emplacement par défaut, et celui que vous venez de spécifier :

ln -s /mnt/data/opengrok/etc/configuration.xml \
    /var/opengrok/etc/configuration.xml 

Plus d’informations sont disponibles dans le fichier README.txt.

Personnalisez la page d’index !

Par défaut, la page d’index d’OpenGrok n’est pas particulièrement jolie — le lien vers xhref est fort utile, mais il manque un élément majeur : un lien clairement visible vers la documentation, la syntaxe à utiliser pour effectuer des recherches un peu poussées.

La page utilisée pour l’instance OpenGrok des sources de PHP est simple, mais plutôt sympa : elle fournit des liens directs vers les arborescences des différentes branches (y compris des moteurs autres que l’implémentation de php.net, comme HHVM), et, surtout, des liens vers la syntaxe à utiliser !

Pour savoir comment personnaliser cette page, cherchez index.html dans le fichier README.txt.