Nicholas Clark est un type très marrant : il arrive avec un sourire jusqu'au oreilles et un sombrero mexicain et ne départira ni de l'un ni de l'autre durant les trois jours de YAPC.
Son talk est consacré aux techniques d'optimisations de Perl.
Les premières méthodes sont évidemment d'utiliser XS ou Inline.
Il conseille aussi de recompiler son Perl avec plus d'options
d'optimisation (par exemple -O2 ou -Os, ainsi que les
options d'architecture -march=YOURCPU) et moins d'options
de debug (-g et les defines de debug). Autre possibilité,
utiliser une autre version de Perl plus ancienne ou plus récente
suivant les fonctionnalités dont on a besoin et la vitesse
d'exécution constatée. (Selon certaines personnes, la branche
5.005 et en particulier la version 5.005_04 offrirait ainsi
les meilleurs compromis performances/fonctionnalités.)
Il rappelle que l'ajout d'optimisations ne doit évidemment
pas casser le code existant ou introduire de nouveaux bugs, et
conseille donc d'utiliser Test, et de mettre en place des
tests de régression avancés.
Il parle ensuite de techniques d'optimisations : comment trouver
quoi optimiser. Il conseille pour cela Devel::DProf et Devel::SmallProf qui permettent respectivement de faire du
profiling de manière globale ou ligne par ligne. Il conseille de
tricher avec Devel::DProf en découpant une grosse fonction
comportant plusieurs boucles imbriquées en autant de sous-fonctions
(en partant des boucles extérieures vers les boucles intérieures).
Il conseille ensuite d'utiliser Benchmark pour tester les
différentes versions d'un même code pour vérifier de manière
expérimentale laquelle est la plus rapide car l'intuition peut
souvent s'avérer trompeuse (ainsi tr/// est souvent plus
rapide qu'on ne le croit par exemple).
Il montre ensuite comment on peut voir l'arbre des instructions
généré par Perl (-MO=Terse) et fait remarquer le coût des boucles. ``Loops are bad''. Il montre sur un exemple comment
remplacer une boucle basée sur un while et des regexp par
pack().
Quelques trucs en vrac :
Devel::Size pour voir la taille mémoire des objets;
/\G.../gc pour
les regexps;
AutoLoader et d'AutoSplit.
Il parle maintenant de l'importation et rappelle que c'est un
mécanisme intrinsèquement lent puisque Exporter est écrit en
Perl et utilise eval "". Il conseille donc (côté module) de ne
pas coder de grosses listes @EXPORT et (côté utilisation d'un
module) de n'importer que ce qu'on utilise. Il donne un exemple
avec POSIX.
Conseil intéressant : il montre comment utiliser Memoize pour
stocker le résultat d'une fonction. Évidemment, c'est à réserver
pour les fonctions dont le calcul est non-trivial (et plutôt du
type calculatoire; de fait il donne un exemple avec une fonction
de Fibonacci). Il indique que le cache peut même être stocké sur
disque.
Quelques techniques générales d'optimisations :
grep /machin/ sort @list en sort grep /machin/ @list
Sur l'utilisation des hashes, il conseille de vérifier la qualité
des clés de hashage, et éventuellement de les rendre plus courtes
avec pack().
Pour la transmission de données entre processus Perl il rappelle
qu'il est idiot de parser les données en Perl et conseille d'utiliser
Data::Dumper et eval ou Storable.
Il y a eu une référence à Acme::Buffy pendant ce talk :-)
MJD prévient d'abord qu'il a raccourci ce talk à la demande des organisateurs car ils ont souhaité qu'il présente aussi son multi-talk Twelve Views.
Le plan de son talk ainsi que quelques slides sont présents sur sont site web : http://perl.plover.com/yak/tricks/
About globs
MJD explique d'abord certains mécanismes internes de Perl.
Il commence avec les stashs, qui sont les structures
internes reliant les variables à leur valeur. À chaque entrée
de la table des symboles (à chaque nom) correspond un stash,
et chaque stash possède sept ``points d'attache'' qui correspondent
chacun à un type : scalaire ($), liste (@), hash (%),
code (&), filehandle et format. Et le septième points
d'attache est le typeglob (*), qui permet d'accéder à
tous les types d'un coup.
Cela permet de faire des aliases entre les variables, soit de manière globale :
*foo = *bar; # $foo et $bar pointent vers la même valeur
# de même que @foo et @bar, %foo et %bar, etc
soit de manière spécifique à l'un des types :
*foo = \$bar; # $foo et $bar pointent vers la même valeur
# mais pas @foo et @bar
MJD présente encore quelques astuces bien sioux et passe à la partie suivante.
AUTOLOAD
Il rappelle les bases de ce mécanisme très utile de Perl qui
permet de charger voire de créer des fonctions à la demande.
Il rappelle ensuite la forme magique de goto, qui contrairement
à un appel de fonction classique n'effectue aucune opération
de sauvegarde sur la pile mais remplace la fonction courante
par la fonction qu'on invoque.
Il expose ensuite comment utiliser AUTOLOAD et le goto
magique pour générer automatiquement des accesseurs de manière
efficace.
Enfin il présente NEXT.pm, un module complètement fou de
Damian Conway, qui permet de faire quelque chose de semblable
à AUTOLOAD mais sur plusieurs niveaux de classes afin de
gérer le multi-héritage. (Regarder le schéma à
http://perl.plover.com/yak/tricks/samples/slide094.html
pour mieux visualiser la chose). Quelqu'un du public demande
si cela gère les cas où A dérive B qui dérive de C
qui dérive de A (oui c'est circulaire). MJD est interloqué
et fait remarquer qu'il n'est même pas capable de représenter
ça au tableau, et encore moins de comprendre comment Perl (ou
même un humain) pourrait faire fonctionner une telle chose :
par où commencer la résolution de nom ?
Pour plus d'informations sur NEXT.pm, consulter sa page de
manuel (NEXT.pm est inclus en standard dans Perl 5.8).
Source Filters
MJD présente enfin rapidement les filtres de sources
Filter::Util::Call et Filter::Simple, des
modules diaboliques qui permettent de modifier le code source
du programme avant sa compilation. Il donne comme exemple un
filtre qui décode un source écrit en ROT-13.
À noter que ces monstruosités^Wmodules font aussi partie
de la distribution standard de Perl 5.8.
Il s'amuse ensuite à nous montrer comment écrire un programme qui ne compile que les jours de pleine lune.
Dans ce talk, MJD nous parle de 12 points divers et variés sans rapport particulier entre eux voire même sans rapport direct avec Perl.
system() ou les backticks c'est mal parce que ça
prendrait trop d'instructions. Il fait remarquer que certaines
choses sont plus compliquées à programmer en pur Perl qu'avec
quelques commandes shell bien utilisées. Il rappelle que Perl est
un langage de glu et qu'un programme simple et lisible est préférable
(et moins sujet à erreur).
Text::Template parce qu'il n'y a pas
eu de version dans les N derniers mois. Il se demande pourquoi
les gens ne semblent pas comprendre qu'il ne fait pas de nouvelle
version pour la bonne et simple raison que ce module est parfait.
Il indique le coupable de ce lamentable état d'esprit : Microsoft
(le public est déchaîné).
Text::Template.
Beaucoup de personnes lui demande de rajouter telle ou telle
fonctionnalité et lui répond que ce serait tout aussi simple pour
eux de créer une sous-classe de Text::Template et d'ajouter la
ou les fonctionnalités qu'ils veulent.
Il suppose que cette répugnance provient d'une lacune dans la documentation : il faudrait que les auteurs de modules et de classes indiquent une API qui devrait rester stable au fil des versions, afin d'établir un genre de contrat moral avec les programmeurs.
;-)) contre
les gens qui disent aux newbies de mettre use strict sans leur
expliquer ce que cela signifie.
Une note amusante : il se rend compte au milieu de la présentation qu'il a oublié de copier certains des fichiers (MJD n'a pas de portable mais en a emprunté un à un des organisateurs) et se prend des erreurs 404 (fichier non trouvé). Il cherche un peu, puis réclame un portable avec la connexion réseau. Un type avec un portable sous Win se propose, mais son réseau ne marche pas. MJD déclare forfait et passe au point suivant.
perldoc perlfunc) est négative. Son conseil : donner
la réponse et indiquer où trouver des informations complémentaires.
;-)
Il montre plusieurs des dessins (qui sont très drôles) et commence à discuter le plus sérieusement du monde des fautes d'orthographes et du choix des messages et des dessins servant à les représenter. Le public est mort de rire.
Là encore lorsqu'il veut cliquer sur un des dessins MJD se rend compte qu'il ne l'a pas copié non plus. Il réclame encore une fois un portable. Quelqu'un lui donne un portable sous GNU/Linux. Ca marche ! Tonnerre d'applaudissements pour le pingouin !
MJD se connecte sur son site et après avoir entré une URL ``secrète'' et tapé un mot de passe (on entend des ``ooh'' dans la salle) trouve enfin les fichiers qui lui faisaient défaut. Il affiche l'image qu'il propose d'envoyer aux extraterrestres. Re-tonnerre d'applaudissements.
En bref, personne ne sait ce que c'est mais beaucoup de monde croit dur comme fer à sa propre définition.
Robin nous expose dans ce talk l'intérêt d'utiliser l'API SAX par rapport à DOM.
Il commence en expliquant que bien que DOM et SAX soient toutes deux des APIs basées sur des arbres, leur implémentation est assez différentes et conduit à des consommations mémoire très différentes. En particulier, SAx est plus économe que DOM dont la plupart des implémentations chargent tout le document XML en mémoire.
Il oppose ainsi les APIs ``push'' (comme SAX) aux APIs ``pull'' (présentes dans le framework .NET de Microsoft) en indiquant que le contrôle que le programmeur croît conserver par l'utilisation d'une API pull (où le programmeur va extraire les données) est une illusion.
Dans le cas d'une API push, les données sont fournies au programme au fur et à mesure de la lecture du document XML, qui ne voit donc ces données que par fragments. On parle alors plutôt de filtre. L'intérêt est qu'on peut alors facilement chaîner plusieurs filtres les uns à la suite des autres, comme on peut chaîner des commandes Unix dans un pipe (ça c'est la comparaison qui m'a permit de comprendre le fonctionnement général, c'était bien vu Robin).
Le gros avantage de cette programmation événementielle est qu'un filtre est plus facile à écrire car on peut ne conserver que la partie qui nous intéresse, en laissant tomber le reste. Reste qui pourra être traité par le filtre suivant.
Robin présente ensuite XML::SAX::ParserFactory qui permet
de sélectionner automatiquement le ``meilleur'' parser SAX
disponible sur le système, avec en dernier recours un parser
en pur Perl. Pour comparer, c'est un peu comme si on pouvait
faire du DBI sans devoir indiquer le driver de base de données.
Il présente enfin XML::SAX::Machines, qui est un module
comprenant quelques filtres bien utiles comme les étonnants
XML::Filter::Tee et XML::Filter::Merger qui permettent
respectivement d'envoyer des événements SAX à plusieurs
processeurs et de fusionner plusieurs flux SAX en un seul !
Merci à Robin Berjon pour avoir corrigé mes erreurs concernant les APIs.
Ce talk consiste principalement en un ensemble de règles de bon sens de développement.
Le code doit être écrit pour le mainteneur, car c'est le mainteneur
(que ce soit soi-même ou une autre personne) qui devra relire le
code six mois plus tard pour corriger d'éventuels bugs ou ajouter
des fonctionnalités. En conséquence, Uri recommande de nommer
les choses (variables, fonctions, objets, etc) de manière appropriée,
de sorte que ce soit compréhensible. Éviter donc les $foo,
@bar et autres $pipo{$machin}.
Il donne aussi le conseil suivant sur les commentaires : les commentaires doivent indiquer pourquoi le code fait telle ou telle chose. Écrire
$a += 1; # add 1 to $a
est inutile et ne sert à rien.
Il indique aussi que programmer du code spaghetti aboutit à la confusion et recommande donc de programmer du code lasagnes ! En effet le code est organisé en couches réalisant des fonctionnalités spécifiques et communiquant par des interfaces.
En résumé :
Uri présente ensuite quelques exemples autour des contextes
d'exécution. Il fait un rappel sur wantarray() et montre
qu'outre les contextes scalaire et de liste, elle renvoie aussi
undef en contexte vide. Il conseille d'utilise Want.pm, qui
offre plus de possibilité que wantarray().
Il y a aussi toute une discussion autour de l'utilisation des here-documents. Uri essaye de convaincre quelqu'un dans le public qui pense que les here-docs c'est pas bien que, oui, les here-docs c'est bien. L'argumentation porte en particulier sur les problèmes d'indentation que cela implique.
Ce talk est comme son nom l'indique consacré à la détection de virus en Perl.
Il présente d'abord File::Scan, un module qui permet de scanner
les fichiers et d'y détecter d'éventuels virus. Pour Peter, le module
est sympa mais est insuffisant en production puisque les signatures
de virus ne sont disponibles qu'une ou deux semaines après la
publication de ces signatures chez les éditeurs commerciaux. Et
évidemment il ne dispose pas d'un support commercial.
Il présente ensuite SAVI qui est un module s'interfaçant avec le
logiciel Sophos Antivirus via la bibliothèque libsavi. L'intérêt
est que Sophos est disponible gratuitement en version d'évaluation
pour une large variété de systèmes (Windows, Unix, Linux, Mac,
VMS, etc). Si on achète la version complète on dispose alors d'un
support commercial. (Néanmoins je connais des personnes qui
refusent d'utiliser Sophos parce que le PDG de cette boîte serait
un scientologue).
Il explique ensuite les méthodes de base pour écrire son propre anti-virus pour emails en exposant les principaux mécanismes de fonctionnement de ces virus. En effet les virus de mails sont pour la plupart basés sur l'exploitation de failles dans les logiciels. Bien que les virus doivent forger des mails semblant valides, ils contiennent nécessairement l'exploit en clair dans le corps de l'email, qu'on peut donc intercepter grâce à Perl.
A vrai dire ce talk était un peu décevant car il a juste présenté des techniques assez générales, connues depuis longtemps et sans montrer d'exemple en Perl.
Marty nous présente en trois slides une méthodologie de
développement basée sur le système suivant : avant d'écrire
le code, quand on sait ce qu'il doit faire, on écrit les tests
correspondants, seulement ensuite on écrit effectivement le
code, et on exécute make test pour vérifier que cela fonctionne.
Le principe est donc que les tests constituent le design fonctionnel
du code. L'écriture du programme est terminée quand tous les
tests réussissent.
Dans ce talk Philip nous expose un cas d'utilisation de Perl comme simulateur de RFC 1086.
Il explique d'abord ce que c'est : une passerelle TCP/IP - X.25. Sa boîte avait un logiciel en C++ qui marchait au-dessus de X.25 et qui envisageait d'utiliser un système de ce genre. Pour tester quels changement il aurait à effectuer dans le code C++, il a décidé d'écrire ce simulateur.
La difficulté résidait dans le fait qu'il devait gérer trois connexions simultanément.
_____________ _______________ | | <------------------ | <--\ /--> | | | incoming data | \ / | | X.25 based | | (X) | | application | ------------------> | / \ | | | control connection | <--/ \--> | | | | TCP-IP / X.25 | | | ------------------> | gateway | |_____________| outgoing data |_______________|
Il a alors décidé d'utiliser les threads de Perl 5.6, et montre quelques unes des fonctionnalités offertes par Perl.
Il montre d'abord comment on peut partager des données (ici
des variables) entre threads grâce à threads::shared :
use threads::shared;
my $data : share;
Il montre ensuite comment créer une queue ``thread-safe'' avec
Thread::Queue : on peut ainsi ajouter des données dans cette
queue depuis un thread et en lire depuis un autre :
use Thread::Queue;
my $queue = new Thread::Queue;
# thread A:
$queue->enqueue("hello the world");
# thread B:
print $queue->dequeue;
Il montre enfin comment créer un sémaphore avec Thread::Semaphore.
use Thread::Semaphore;
my $sem = new Thread::Semaphore;
# create threads...
$sem->down;
# do stuff....
$sem->up;
Il conclue en expliquant que son simulateur n'a servi à rien car sa boîte a finalement décidé d'utiliser une autre solution, mais il était content car il avait pu découvrir les threads en Perl.
Ce talk est destiné à nous présenter le module Devel::Cover,
dont le but est de déterminer de manière pratique la couverture
de code.
La couverture d'un code est la partie du code qui est exécutée
au cours d'un ensemble d'instances d'exécution. En clair, ce
module permet de vérifier si le code contient des parties mortes
ainsi que de vérifier quelles sont les parties les plus exécutées
(utile pour déterminer quelles sont les parties à optimiser).
Cela ressemble donc un peu à Devel::DProf mais en utilisant
un système de profilage différent (basé sur la surcharge des ops
de l'interpréteur Perl) et surtout en fournissant en sortie un
rapport en HTML permettant de suivre l'exécution du code par
ligne, par branche et par boucle.
L'utilisation de Devel::Cover est aussi simple que ça :
$ perl -MDevel::Cover program.pl
$ cover -report html
Un aspect dommage est que Paul a tendance à traîner en longueur
sur son exemple alors que plusieurs personnes (dont moi-même et
Arnaud) trépignent d'impatience en se demandant s'il va montrer
le Makefile.PL permettant de lancer un make test avec
Devel::Cover (ce qui constitue une technique fabuleuse pour
vérifier que les tests font s'exécuter tout ou partie du code).
Il s'excuse en disant qu'on lui avait déjà posé la question à
Munich, qu'il n'avait pas pu la fournir et que là il avait oublié
ce qu'il fallait ajouter à Makefile.PL pour avoir make cover.
Il parle ensuite de CPAN Cover, un projet dérivé qui consiste
à exécuter un make cover sur tous les modules du CPAN.
Pour certaines raisons, ce talk a attiré beaucoup de personnes qui, venant en avance, ont débarqué dans celui de Guillaume Rousse Yet another Perl biology toolkit. Désolé Guillaume.
Jos a en effet présenté vingt modules (ou pseudo-modules) en prenant comme thème de présentation le Seigneur des Anneaux :
Neuf furent donnés aux Hommes mortels,
Sept aux Nains avides d'or,
Trois furent protégés par les Elfes,
Et l'Unique, le Maître Anneau, forgé par Sauron.
Les modules n'ont en réalité pas grand-chose à voir avec les Elfes ou les Anneaux, mais l'idée est amusante et surtout Jos était un bon orateur.
Sur tous les modules qu'il a présenté au pas de charge, je n'en ai retenu que quelques uns :
Devel::Peek qui permet de voir les structures internes de l'interpréteur Perl;
File::Chdir qui permet de gérer automatiquement le répertoire courant;
Config::Auto, un module de gestion de fichiers de configuration;
Hook::Scope qui permet d'avoir l'équivalent de BEGIN et END
mais au niveau scope (c'est-à-dire au niveau des blocs);
Hook::LexWrap, un module de Damian Conway qui fait quelque
chose de similaire mais au niveau des fonctions si j'ai bien compris;
Scalar::Utils qui permet de stocker plusieurs valeurs différentes
(un entier ET une chaîne) dans une même variable;
Dans ce talk aussi Nick Clark a réussi à parler de Acme::Buffy :-)
C'est un Dan Sugalski complètement fracassé par le voyage en avion qui nous présente Parrot en commençant par expliquer en quoi l'interpréteur Perl5 actuel est un vrai merdier. En effet, Perl5 est le résultat de 9 ans de patches successifs pour ajouter un ensemble de fonctionnalités qui n'avaient pas été prévues au départ car cela n'existait pas à l'époque : on pense tout particulièrement au support des threads et d'Unicode.
Des tas de personnes ont donc proposé des patches en disant ``cela ne coûte qu'1% du temps d'exécution''. Mais les patches étant acceptés, les pourcentages se sont additionnés pour ralentir de manière sensible l'interpréteur Perl. (Raison pour laquelle Nick Clark indiquait qu'un moyen potentiel d'accélérer un programme était d'utiliser une ancienne version de Perl.)
Perl6 se base sur une machine virtuelle (VM) totalement nouvelle, Parrot. Cette machine virtuelle a été conçue en utilisant les dernières avancées en matière des techniques de VM, de théorie de compilation et de conception des CPUs (ces domaines étant très liés). Le projet est ambitieux mais on espère ainsi que cette VM évoluera de manière plus douce sur la décade à venir.
L'autre ambition de Parrot est que cette VM soit suffisamment générique pour servir de base d'exécution à d'autres langages comme Ruby ou Python.
Dan expose ensuite la véritable raison qui l'a décidé à programmer Parrot : jouer à Zork nativement. (Zork était un jeu d'aventures en mode texte).
En effet, Parrot offrira nativement bon nombre de fonctionnalités très intéressantes comme le support de bytecode portable (semblable à Java ou Python) et un garbage collector (GC) natif de bien meilleur qualité que celui de Perl5 (le GC de Parrot sera de type mark and sweep, comme celui de Lisp).
Ce qui nous amène à un point essentiel dans le développement de Parrot : le défi que Guido von Rossum a lancé à Dan Sugalski, à savoir que selon Guido, Parrot ne sera pas capable d'exécuter Python plus rapidement que CPython (l'interpréteur Python écrit en C) d'ici le prochain OScon. L'enjeu est le lancer de tarte à la figure du perdant, d'où l'orthographe spéciale de Python durant tous ces talks, ``Pie-thon''.
Dan a expliqué qu'il a toutes les chances de se trouver du bon côté de la tarte car Parrot est ou sera bientôt capable de charger n'importe quel type de bytecode : Python, Zork et même Java !
Dans un anglais quelque peu hésitant, Leo nous explique les bases de la programmation en Parrot.
On peut d'ores et déjà programmer en PIR, Parrot Intermediate
Representation Language, qui est un genre de macro-assembleur
à base de registres typés avec support des espaces de noms.
Ce langage est ensuite traduit par IMCC en PASM, l'assembleur
Parrot, qui est ensuite compilé en PBC, Parrot Bytecode. Ce
dernier est chargé par la VM par mmap() (une fonction de
chargement de fichier rapide) et après quelques transformations
(comme la gestion de l'endianness) est exécuté.
Leo présente ensuite quelques points qui permettent à Parrot d'être très rapide :
Là je dois reconnaître qu'il m'a un peu embrouillé dans ses explications et je ne pas trop compris ses arguments, mais une comparaison avec les vrais CPUs indique qu'une taille fixe égale à un multiple entier de mots machine permet de se simplifier la vie lors des calculs d'adresses (là encore voir l'opposition entre les CPUs RISC et x86). Cela permettrait aussi plusieurs optimisations pour la DOD et le GC.
$foo = "hello world";
$bar = $foo;
Habituellement, le contenu de $foo est copié dans un nouvel
espace mémoire qui sera pointé par $bar. Avec COW, $bar
pointe vers l'espace mémoire de $foo, et ce n'est que si on
modifie la valeur de l'une ou l'autre des variables qu'un
nouvel espace mémoire est créé. Ce mécanisme fonctionne pour
tous les types d'objets natifs car c'est nécessaire pour la
gestion des continuations.
Cette fonctionnalité semblait particulièrement intéresser certaines personnes du public qui avaient posé la question à MJD lors de son talk ``Tricks of the Wizard''. Le mécanisme sera par la suite mis en scène par Nick Clark lors de son lightning talk.
Leo expose ensuite quelques uns des différents run cores disponibles dans Parrot. Si j'ai bien compris, les run cores sont les coeurs d'exécution de Parrot, mais comme ils n'étaient pas sûr de savoir quel mécanisme serait le plus efficace, ils ont développé plusieurs run cores : Fast Core, Goto Core, Slow Core, et des combinaisons. Leo montre le Fast Core avec cet extrait de code C :
while(PC) {
PC = ((INTERP->op_func_table)[*PC])(PC,INTERP);
}
Un ange passe et semble aussi dubitatif que le public face à ça.
Leo explique ensuite que Parrot dispose d'un sous-système JIT (Just-In-Time) disponible pour plusieurs architectures (x86, PowerPC, Sparc, ARM, Alpha).
Pour rappel, un système JIT (aussi dit de recompilation dynamique), permet de transformer le bytecode en code natif pour le CPU de la machine hôte. C'est ce qui permet à Java d'avoir des vitesses d'exécution à peu près acceptables.
Leo nous montre le résultat d'un benchmark qu'il avait lancé au cours de son talk; c'est un truc calculatoire écrit en Perl et en Python. Les temps d'exécution sont lamentables, à peine 2 ops par seconde en Perl et 1 op par seconde en Python. ``Times are rounded up!'' précise Leo. Il exécute le même en Parrot : quelques secondes, soit presque 800 ops par secondes (son PowerBook tourne à 800 MHz..)
Après cette démonstration, Leo conclut sur le système JIT en indiquant que comme a pu le constater, on peut arriver à exécuter jusqu'à 1 instruction Parrot par cycle CPU ! Évidemment, c'est surtout valable pour les instructions ``simples'' (ou du moins disponibles dans le CPU), mais c'est néanmoins assez impressionnant.
Sa présentation terminée, quelqu'un dans le public demande à Leo de montrer ce qu'il utilise pour ses ``slides'' (du texte affiché dans un terminal qui efface l'écran et défile quand il appuie sur une touche) : ``Parrot of course!''. Il montre le code PIR qu'il a utilisé pour son talk, qui doit faire moins d'une cinquantaine de lignes. Nouvelle salve d'applaudissements.
Merci à Stéphane Payrard pour ses corrections et précisions.
Le talk de Leon est consacré aux petits langages déjà disponibles au-dessus de Parrot.
Il commence par expliquer ce qu'il entend par ``petit langage''. Sa définition est que c'est un langage spécialisé pour une tâche donnée dont la syntaxe est compacte jusqu'à la rendre complètement hermétique pour qui ne ``parle'' pas ce langage. En clair, un petit langage est ``insane''.
Il donne des exemples pour montrer qu'on est entourés de petits langages : regexp, awk, sed, bc, nroff, pic...
Il parle ensuite des langages qui ont été implémentés au-dessus de Parrot.
:-)
Quelqu'un demande si on peut exécuter deux instances sur un même ``source'' pour faire un bot-war. Leon répond que non car c'est compliqué mais pas impossible. Il précise que Jérôme Quelin est le responsable de l'implémentation de ce langage sur Parrot.
Marty commence par nous dire お早うございます [ohayô gozaimasu],
c'est-à-dire ``bonjour'' ^_^
Le titre de son talk est 混合語. Par bonté d'âme il nous donne l'écriture en furigana こんごうご [kongôgo] et explique le sens de ce mot : il désigne la création d'un nouveau langage par mélange et contamination de deux ou plusieurs autres langages. Selon lui, c'est l'idée fondamentale derrière Perl6.
Il explique que Matz (diminutif de Yukihiro Matsumoto) voulait créer le meilleur langage de programmation. Il a donc volé un grand nombre de fonctionnalités à Perl afin d'écrire Ruby.
Marty insiste (comme avant lui Dan Sugalski) sur le fait que Perl6 a démarré dans le but de contrecarrer la concurrence que Ruby risquait de faire à Perl. Larry a d'ailleurs déclaré à plusieurs reprises l'admiration qu'il a envers Ruby. Mais cette admiration ne l'a pas empêché de chercher un moyen de renouveler Perl afin qu'il reste supérieur à Ruby (et évidemment à Python...).
La première solution a été de voler à Ruby les fonctionnalités qui risquait d'attirer les programmeurs :
-> s'écrit maintenant .
Mais cela signifiait malgré tout rester derrière Ruby en terme d'innovation, ce qui aurait été insuffisant. Larry a donc décidé de voler les ``fonctionnalités'' de la langue maternelle de Matz, le japonais, grâce à ses talents de linguiste.
Marty commence alors à étayer sa théorie en montrant que Larry a commencé à apprendre le japonais il y a deux ans, peu de temps avant de lancer le projet Perl6. On sait aussi que Larry a fait quelques voyages au Japon et qu'il chante la musique de Totoro ! Par ailleurs Simon Cozens parle couramment japonais et Marty ajoute que plusieurs hackers de Perl6 sont en train d'apprendre le japonais ou du moins s'y intéressent de près.
Il apporte comme preuve le fait qu'on puisse dès maintenant écrire du Perl en japonais dans le source (depuis 5.8 et le support d'Unicode) :
my $封 = "お早う";
print $封, "ヲルヅ";
Vous aurez reconnu (!) le code :
my $foo = "ohayô";
print $foo, "world";
(ok, je sors... :-)
Marty essaye ensuite de nous présenter les fonctionnalités du japonais que Larry a décidé de reprendre pour Perl6 comme la concision et l'utilisation intensive du contexte. Pour nous convaincre il fait répéter à la salle des phrases en japonais : ``les deux canards sont dans le jardin'', puis ``le crocodile a mangé les deux canards dans le jardin''. Il nous explique ainsi que le japonais a ceci de particulier qu'il fait une grande utilisation du contexte courant du dialogue, ce qui permet d'éviter beaucoup de mots redondants (comme les pronoms, les articles, les locutions).
Il rappelle aussi que les japonais sont très friands d'abréviations formées en ne conservant que deux ou trois syllabes d'une expression. Par exemple, au lieu de perdre du temps à parler de ``word processor'', un japonais dira ヲプロ [wopro]. (Autres exemples, le nom de la société de jeux Sega vient de Service Game, et celui du célèbre Comiket de Comics Market.)
Puis il nous raconte quelques anecdotes de son périple en tant que 外人 [gaijin] au Japon où il s'est laissé abusé par cette notion de contexte si particulière.
Enfin il conclut en nous recommandant de faire une recherche sur le web sur ``Larry Wall'' et ``Japanese'' et de prendre peur. Peut-être fait-il allusion à l'un des articles suivants ?
Laissant la salle interrogative, il termine par 有難うごさいます [arigatô gosaimasu], ``merci beaucoup''.
Dan expose l'état actuel de Parrot, ce qui marche, ce qui ne marche pas. Il est globalement content même si plusieurs parties reste encore en chantier (l'implémentation actuelle de Parrot est thread-safe mais la gestion des threads est à écrire) et reste de toute façon motivé pour avancer rapidement car 1) il veut jouer à Zork, 2) il veut lancer la tarte sur Guido (et pas l'inverse) !
Arthur explique comment la société Fotango (par ailleurs l'un des sponsors de YAPC::Europe) a donné son accord à ses développeurs pour commencer le portage de Perl5 sur Parrot afin d'assurer une meilleure transition pour le passage de Perl5 à Perl6. Le nom du projet est Ponie, l'acronyme de Perl On a New Internal Engine.
Bien que le projet commence à peine, les grosses difficultés sont connues à l'avance : Perl5 utilise toujours son GC basé sur le comptage de référence alors que Parrot possède un GC bien plus efficace de type mark and sweep (marquage et effacement (?)); Perl5 et Parrot ont chacun leur système de gestion de l'UTF-8.
Par contre Arthur pense que les threads devraient poser moins de problèmes.
Greg nous explique pourquoi il n'a pas voulu faire de talk cette année : il faut choisir un sujet, ce qui est compliqué; résultat il n'arrive pas à se décider de quoi parler, et si jamais il sait de quoi parler il doit alors prépare le talk mais comme ça le stresse il n'arrive pas à se concentrer et doit quitter son ordinateur, ce qui l'empêche de faire des trucs amusants. C'est donc la raison pour laquelle il a décidé de ne pas faire de talk, afin de rester sur son ordinateur à découvrir des trucs amusants, et nous livre ainsi en vrac les résultats de ses découvertes.
Jabber - Il aime bien Jabber car il peut s'envoyer des messages instantanés ou des messages à durée de vie plus longue pour savoir s'il a du mail ou monitorer d'autres trucs.
CVS - Il a découvert qu'on pouvait ajouter des trucs dans un serveur CVS pour qu'il envoie des mails automatiquement quand quelqu'un committe quelque chose, et a découvert encore mieux : comment envoyer des messages Jabber lors d'un commit; comme ça sa boîte aux lettres n'est pas remplies de mails dont il n'a que faire mais il est quand même averti quand quelqu'un a touché au code pendant qu'il s'est absenté.
Il parle encore de quelques autres trucs puis on lui annonce que son temps est écoulé et il est surpris d'avoir déjà terminé son talk qui n'en était pas un car il avait encore plein de choses à dire.
Pendant que la salle se remplit au fur et à mesure, MJD se prépare à diriger les lightning talks. Il déballe d'abord un chronomètre et une petite sonnette, puis ouvre un grand carton d'où il sort son célèbre gong.
Nick décide de nous expliquer de manière très visuelle comment
fonctionne le Copy-on-Write avec l'aide de quelques londoniens
donc Leon Brocard, chacun représentant une variable scalaire.
Nick débute avec Leon qui pointe vers une valeur de chaîne
(imprimée sur une feuille qu'il déplie), ``Buffy'' (ce qui ne
surprend personne :-)). Puis il montre ce qui se passe quand
d'autres variables pointent vers cette chaîne, et que certaines
d'entre elles sont modifiées.
Jonas montre comment construire une petite calculette en utilisant CamelBones http://camelbones.sf.net/. CamelBones, développé par Sherm Pendley, est un pont entre Perl et Objective-C permettant de construire des applications Cocoa (l'API graphique et applicative de Mac OS X). Après une rapide présentation de CamelBones, il montre comment on crée une application avec ProjectBuilder et InterfaceBuilder.
*TING!* MJD vient de faire sonner les 4 minutes.
Jonas essaye d'accélérer mais se mélange un peu les pinceaux et n'arrive pas à faire fonctionner sa calculette.
*GONG!* MJD lui signale que son temps est écoulé.
Rafiq explique dans ce talk que dans certaines secteurs,
comme les finances, les éditeurs logiciels tendent à
écarter les langages comme Perl pour tout rassembler
autour d'API écrites en C. Mais Perl a la possibilité
de s'en sortir grâce à Inline::C, qui permet d'utiliser
de manière simple et rapide du code C en Perl, sans
devoir développer une interface XS. Rafiq montre un
exemple de vieux programme Perl qui a pu être facilement
mis à jour de cette manière.
Christophe s'interroge sur l'avenir de Perl/Tk qui n'a pas été mis à jour depuis longtemps bien que le développement de Tcl/Tk ai récemment repris et qu'une version majeure soit sortie.
Il termine en remontrant les exemples qu'il avait présenté
lors de talk sur Tk::Zinc.
Tim propose dans ce talk que les développeurs Perl, maintenant qu'ils ont pris l'habitude d'écrire des séries de tests unitaires, devraient aussi apprendre à créer et maintenir des interfaces d'utilisation stables et cohérentes entre elles. Cela rejoint en partie ce qu'exprimait MJD dans son mini-talk The failure of subclassing on CPAN.
Il propose ainsi que les fonctions remplissant des buts
similaires portent le même nom. Il ne prône toutefois pas
un cadre psycho-rigide propre à d'autres langages dit
orientés-objets mais plutôt une convention, de manière
similaire à celle d'appeler new() la fonction de création
des objets. Un point sur lequel il insiste par contre est
que les interfaces devraient rester le plus possible
stables afin de ne pas dérouter l'utilisateur du module.
Mark présente le module Test::DatabaseRow qui permet
d'écrire des tests sur les données présentes dans une
base de données. Les possibilités du module sont assez
étendues et outre la simple comparaison, on peut aussi
vérifier les valeurs avec des expressions régulières.
Ettore arrive comme beaucoup d'autre avec son portable et le branche. Une partie du public, constatant avec effroi que ledit portable tourne sous Windows, commence à siffler et à huer. MJD calme les esprits et Ettore explique comment Perl lui a permit de créer un système permettant à une université de gérer les notes des étudiants de manière plus simple. Avec comme contraintes intéressantes que tout le parc informatique, serveurs compris, était 100% Windows, et qu'il fallait sortir des fichiers Excel et Word.
Ettore explique que la saisie se fait au travers d'un CGI
qui entre les notes dans une base MS-SQL via DBI, puis
que d'autres programmes vont ensuite extraire ces notes et
grâce aux modules Win32::OLE et SpreedSheet::WriteExcel
vont générer les fichiers Word et Excel désirés. Le système
a permit de gérer les notes de 8 fois plus d'élèves en 6
fois moins de temps.
Le public l'applaudit très chaleureusement pour cet exemple d'utilisation de Perl dans un environnement pourtant si peu approprié.
Philippe arrive un portable qui semble un peu vieux mais néanmoins toujours vert (puisque sous GNU/Linux), et démarre sa présentation en mode texte (semblable à celle utilisée par Leopold Tötsch).
Philippe commence par expliquer en anglais qu'étant donné que ce YAPC se déroule à Paris, il fallait quand même bien qu'il y ait une présentation en français. Puis il embraye en français pour parler de l'hypothétique organisation d'un French Workshop, similaire à ce qui s'est fait en Allemagne.
Pendant ce temps, son programme de présentation manifeste sa surprise devant ce changement de langue et décide, semble-t-il de son propre chef, d'occuper le public anglophone en lui racontant des blagues. En français.
``Quelle est le nom de l'Étoile polaire''
``Eléonor''
L'ensemble du public, les Frenchies en premier, n'écoute déjà plus du Philippe mais reste suspendu aux jeux de mots de son programme. Lui-même a d'ailleurs du mal à rester sérieux confronté à ses facéties (surtout les blagues Carambar).
Maîtrisant à peine son fou rire, il décide de rappeler à son programme qui est le patron et commence à le réprimander. Ce dernier fait la tête et décide de bouder, mais continue finalement à s'exprimer à la place de Philippe, qui renonce, décidément incapable d'en placer une.
[ manque ce que le programme racontait à la fin ]
La salle est en délire, le public fait un triomphe plus que mérité à Philippe. Les quelques personnes qui n'applaudissent pas sont celles qui, portables sur les genoux, décrivent la scène sur IRC. MJD vérifie que, malgré les apparences, cette présentation a bel et bien duré moins de cinq minutes.
Quelqu'un demande à voir le programme utilisé. Philippe explique qu'il avait fait une première présentation mais qu'il l'a perdue suite à un crash et a donc codé à toute allure ce petit morceau de code (une vingtaine de lignes), qui ne fait qu'afficher des slides pendant des durées déterminées, son petit PowerPoint en quelque sorte. Quelqu'un crie ``bloatware!''. Le public applaudit une nouvelle fois Philippe pour cette éclatante preuve de supériorité sur Microsoft, rejoignant Leopold Tötsch dans la catégorie ``j'ai écrit une visionneuse de moins d'un kilo-octet''.
Piers présente de manière originale quelques idées sur les bonnes méthodes de management : en les chantant !
Après avoir terminé sa chanson et pendant que le public l'applaudit, il se rend compte que MJD regarde intensément la liste des LTs. Il fait alors signe au public d'arrêter de l'applaudir et recommence à chanter. Entendant cela, MJD relève la tête d'un air surpris et commence à sonner du gong pour signaler que le talk est achevé.
Gabor est venu présenter le groupe de Perl Mongers d'Israel, dont le symbole est une mante religieuse, d'où le titre de sa présentation. En effet, ce groupe très actif a organisé en début juillet le premier YAPC::Israel. Il remercie au passage MJD de s'être déplacé pour le premier YAPC dans cette région du monde, qui n'a duré qu'une journée. Il espère réaliser un YAPC de deux jours l'année prochaine.
Il change ensuite entièrement de sujet et présente des résultats d'une étude quantitative des groupes de mongueurs par rapport à différents critères.
Considérant que la liste de diffusion constituait le cœur des groupes de mongueurs, il conclue que London.pm et Paris.pm sont les deux plus actifs groupes de mongueurs, ce qui satisfait pleinement le public.
Hendrik présente un langage de programmation, qu'il a appelé Beatnik (son propre pseudonyme, et il s'excuse pour ce manque d'originalité) qui a comme particularité d'être basé sur les règles du Scrabble. En effet cela consiste à utiliser des mots dont la valeur est la somme des valeurs des lettres, en utilisant les valeurs usuelles du Scrabble. Celles-ci variant d'une langue à l'autre, il indique que cela implique de préciser la langue utilisée, un même mot n'ayant pas la même valeur dans deux règles différentes.
Il termine en montrant un programme, une pleine page remplit de mots, qui est évidemment un ``hello world''. MJD semble admiratif devant cet exemple assez étonnant.
Jaap présente le Zoidberg Perl Shell http://zoidberg.sf.net/, qui est comme son l'indique un shell écrit en Perl. Il précise qu'il est actuellement suffisamment avancé pour que lui-même s'en serve au quotidien et montre quelques unes de ses fonctionnalités.
Ronan semble avec ce talk vouloir lancer un bon gros troll un peu baveux en expliquant pourquoi ``Perl sucks'' et ``Ocaml rocks'' concernant leur manière respective de gérer les objets.
Fort heureusement personne ne réagit face à ses affirmations.
Peut-être parce que personne ne sait ce qu'est Ocaml ni à quoi
ça sert ;-)
Uri rappelle que WWW::Mechanize est un bon module qui est
très utile.
Continuant à prodiguer des conseils de bonne conduite, Tim expose cette fois le cas des wikis et du problème de navigation qui peut découler d'une mauvaise présentation. Il présente quelques approches pour améliorer cette situation.
Earle présente un projet basé sur un wiki dont le but est de fournir un genre de guide touristique ouvert, écrit au fur et à mesure par les personnes qui connaissent les endroits afin de donner les informations les plus précises. Il permet aussi de répondre à des questions cruciales comme ``quels sont les bars situés à moins de 300 mètres de tel lieu ?''.
Open Guides - http://www.openguides.org/
La vente aux enchères est dirigée comme il se doit par l'ineffable Greg McCarrol, qui présente infatigablement les livres, t-shirts et autres objets mis en vente. Il est assisté par Uri Guttman, Philippe Bruhat et quelques autres personnes pour la distribution aux acheteurs.
Projeté sur le grand écran derrière Greg un iBook a été branché
avec en fenêtre de premier plan le canal IRC du YAPC. Quelques
personnes dans la salle transmettent en temps réel les enchères,
voire dans certains cas avec un peu d'avance, ce qui ne manquera
pas de déstabiliser Greg :-)
Parmi les objets en vente, on trouvait des livres donnés par
O'Reilly (Programming Perl, Programmation en Perl,
mod_perl, Programmation avancée en Perl)
et par Pearson (le fameux Object Oriented Perl de Damian Conway,
Data Munging with Perl, Network Programming with Perl).
Certains titres étant en français, cela nous donne l'occasion
d'entendre Greg massacrer notre belle langue :-)
Seront aussi vendus des autocollants signés par Larry Wall, un animal en baudruche réalisé par Piers Cawley, des t-shirts de différents groupes de mongueurs dont le dernier exemplaire du t-shirt ``Perl is my bitch'' qui sera finalement acheté par Philippe à prix d'or. Seront par la suite mis aux enchères la caleçon de MJD, acheté par Elaine Ashton, puis le soutien-gorge d'Elaine, acheté par Leon Brocard !
Un moment fort fut quand Philippe revint avec son portable et présenta un tableau encadré, l'image originale projetée à l'écran. La partie droite est une photo de Greg McCarroll, la partie droite un bloc de code Perl assombri dont certains caractères (comme gmc) sont en gras. Il explique que c'est le résultat final d'un pari qu'il avait lancé à XXX lors du précédent YAPC et donne le tableau encadré à XXX Premier concerné dans cette affaire, Greg met Philippe au défi de lancer son programme, et parie qu'il ne marchera pas. Philippe parie le contraire. Le pari est mis aux enchères et fini par monter jusqu'à plus d'une centaine d'euros.
Greg met fin aux enchères et Philippe lance son programme. Celui-ci efface l'écran et affiche sur la première ligne de son terminal une suite aléatoire de caractères qui défilent comme l'affichage d'un aéroport. Greg se moque de Philippe, qui ne bronche pas. Le premier caractère se fige sur la lettre ``G'', puis après un moment le second sur la lettre ``r'', et ainsi de suite jusqu'à afficher la phrase :
Greg McCarroll is my bitch
Tonnerre d'applaudissements pour Philippe qui démontre là encore sa maîtrise du terminal et des programmes assombris.
Le clou de la vente reste néanmoins la décision du changement de la langue des sites web des deux premiers groupes de mongueurs, London.pm et Paris.pm. Les anglais commencent en faisant quelques offres pour que l'anglais soit la langue choisie, ce qui n'emballe personne. Puis Marty Pauley décide d'organiser une mutinerie et crie qu'il veut passer les sites en japonais. Quelques personnes le suivent et une petite bataille commencent entre les nipophiles et les anglophiles.
Ces derniers remportent par leur supériorité numérique et les choses auraient pu en rester sans Paul Makepeace qui propose 600€ pour passer la page en espéranto. Stupeur dans la salle, mais Greg se reprend et harangue les londoniens pour qu'ils surenchérissent. Quelques autres personnes soutiennent Paul mais les anglais semblent encore gagner par leur nombre. Mais Paul renchérit à plus de 700€ et commencent à attirer de plus en plus de monde dans son camp. Les anglais essayent de tenir bon, mais Marty décide de transférer son offre en faveur de l'espéranto.
Lorsque la barre des 1000€ est dépassée, certains anglais commencent à pâlir, sentant que la victoire pourrait leur échapper. Greg, abasourdi par la teneur que prenaient les événements, essaye même de dissuader Paul et ses supporters : ``Do you realize that you are offering more than thousand euros to change the main page of the biggest two Mongers groups to Esperanto???'' Mais la majorité du public est maintenant contre l'idée d'utiliser encore et toujours l'anglais comme langue commune.
Quelqu'un ayant rapidement développé un CGI pour garder le compte des enchères amène son portable à la tribune. Uri prend en charge la mise à jour des résultats. Constatant que le français n'a reçu aucune offre, quelques personnes font des offres symboliques, sachant que cela reste hors de portée. D'autres offres sont aussi proposées pour le ``Chief Sweden''. Mais la guerre entre l'anglais et l'espéranto reprend pour la dernière bataille, qui après des trahisons dans les deux camps s'achève sur la victoire incontestée de l'espéranto pour 1371€.
Le public est en délire, sauf quelques anglais qui font triste mine et se demandent pourquoi le monde est si injuste.
Enchaînant rapidement, David Landgren remercie les orateurs et participants, cite les sponsors qui ont financé ce YAPC et annonce que le prochain YAPC::Europe se déroulera à Belfast.
Copyright (C)2003 Sébastien Aperghis-Tramoni <sebastien@aperghis.net>