GNU/Linux Magazine 122

Fidèles à nos habitudes, nous décortiquons la toute dernière version du noyau, cette fois-ci étiquetée 2.6.32. Elle a une importance toute particulière pour deux raisons. D'une part, elle fait suite à une version 2.6.31 jugée légèrement décevante car apportant de nombreux bugs et régressions. D'autre part, il ressort des discussions ayant eu lieu à la Linux Plumbers Conference le 23 septembre que ce noyau 2.6.32 sera probablement utilisé par les prochaines versions de plusieurs distributions ayant un support à long terme, notamment Debian Squeeze et Ubuntu 10.04. Rentrons à présent dans le vif du sujet, en vous souhaitant une bonne lecture pour ce long Kernel Corner.

Qu'il s'agisse de dépister des anomalies dans un code que l'on veut robuste ou de démontrer qu'un prestataire n'a pas respecté l'état de l'art, ou plus simplement pour améliorer la qualité de son projet, il arrive un moment où l'on souhaite faire le point sur la qualité technique globale de son projet. Ce genre de travail nécessite bien évidemment une bonne maîtrise de la technologie utilisée, mais aussi un outillage assez élaboré pour analyser et remonter les potentiels problèmes. S'il existe de nombreuses solutions open source – PMD, Cloc, Findbugs... – pour analyser un projet et remonter ses indicateurs, il reste fastidieux de mettre en place tous ces outils et surtout encore plus laborieux de faire la synthèse des différents résultats obtenus.

Nous entamons ici une série d’articles consacrés au langage PIR, et ce premier chapitre a pour but de le présenter. PIR signifie Parrot Intermediate Representation, qui, comme son nom l’indique, est un langage moins rustique, plus abordable et plus lisible que l’assembleur de base PASM. Tous les programmes présentés ici sont disponibles en téléchargement sur mon site : http://www.dil.univ-mrs.fr/~chris/Documents/progs01.pod.