Où il est question de Perl
Un historique de toutes nos réunions
Nous avons mangé des oeufs mayonnaise, des
cheeseburgers, des blue-cheeseburgers, des magrets de canard,
une côte de boeuf et une salade végétarienne.
Nous avons bu de la Kriek, de la Warsteiner,
d'autres bières, de l'Orangina et une margarita.
Les premiers arrivés ont même eu droit à quelques
olives à titre d'apéritif.
-
Les premiers arrivés ont parlé de
Class::DBI.
Ce module permet d'identifier une table SQL
(mySQL,
PG,
Oracle
etc) à une classe objet de Perl. Il faut énumérer les colonnes
dont on a besoin pour créer les attributs d'objet correspondants
et coder quelques méthodes pour lire la table et la mettre à jour.
C'est valable si le programme se contente de quelques tables.
Si le nombre de tables utilisées dans le script est
trop important, il convient alors d'utiliser
Class::DBI::Loader
qui est capable d'aller chercher les méta-attributs de la base
de données et de construire les classes et les méthodes
correspondantes. Laurent a entendu parler de
DBIx::Class
mais il n'a pas installé ce module et il ne peut donc
pas apporter un avis éclairé sur les avantages et
inconvénients de ces deux modules.
-
Audrey
a fait parler d'elle chez les P5P. Rafael nous apprend que
l'interpréteur perl est construit de manière à pouvoir
aisément remplacer le moteur d'expressions régulières standard
par un autre. Audrey a mis à profit cette particularité
dans son module
re::override
qui remplace le moteur Perl par...
PCRE,
le « moteur d'expressions régulières compatible Perl » !
Quel est l'intérêt d'utiliser PCRE ?
Tout simplement que PCRE est réentrant, dans le sens où
l'expression recherchée ou l'expression de remplacement peuvent
comporter du code Perl (avec l'option /e ou la
construction (?{code})).
-
J'ai vaguement entendu quelques-uns comparer
HTML::Template
et Text::Template,
mais comme je suivais une autre discussion intéressante à l'autre
extrémité de la table, je ne pourrai pas en dire plus.
-
Sébastien a demandé s'il existait en Perl un équivalent aux
#ifdef ... #endif de C. La première réponse,
rapide mais peu utile est que cela existe, c'est
l'option -P
de la ligne de commande. La deuxième réponse,
plus dans l'esprit de Perl, est que l'on n'a pas besoin
de cela. Une utilisation fréquente des #ifdef ... #endif
de C concerne des morceaux de code qui sont codés différemment
selon le système cible : une variante pour Linux, une
autre pour FreeBSD, une autre pour Windows, etc.
Avec un langage dynamique comme Perl, il est possible
de faire ce choix à l'exécution avec un if.
Et s'il y a des problèmes de portabilité, on peut
englober le morceau de code problématique dans
un eval,
de façon qu'il ne soit compilé que lorsque le script
est lancé sur la bonne architecture.
-
Sébastien a de bonnes lectures, il est en train de lire
de l'Art de Programmer en Perl.
Il nous demande notre avis sur certains points, comme
le fait de fermer un fichier par un
close
au lieu d'attendre la fin de la portée de définition
de la variable handle de fichier.
David est partisan de la fermeture par close,
parce que cela permet d'introduire une symétrie
dans le script, symétrie qui aide à la compréhension.
Je l'approuve et j'explique même que c'est de cette
façon que je rédige le code du script. Si j'ai besoin
de lire un fichier, le script en cours d'écriture
passe par les étapes suivantes.
Tout d'abord, un script vide, tout au moins en ce qui concerne la
portion de traitement lisant le fichier.
Deuxième étape :
open my $fh, $nom_fichier
or die "ouverture $nom_fichier $!";
close $fh
or die "fermeture $nom_fichier $!";
Troisième étape :
open my $fh, $nom_fichier
or die "ouverture $nom_fichier $!";
while (my $ligne = <$fh>) {
}
close $fh
or die "fermeture $nom_fichier $!";
Quatrième étape :
open my $fh, $nom_fichier
or die "ouverture $nom_fichier $!";
while (my $ligne = <$fh>>) {
my ($util, undef, $uid, $gid, $nom, $homedir, $shell) = split ':', $ligne;
# suite du traitement
}
close $fh
or die "fermeture $nom_fichier $!";
-
Sébastien demande également à quoi correspondent les noms de
fonction commençant par un caractère souligné dans un
module. L'explication
a été confuse au début, à cause du sens ambivalent du verbe
« pouvoir » : être capable ou bien avoir l'autorisation.
Les fonctions dont le nom commence par un souligné sont
des fonctions que l'on n'est pas autorisé à appeler depuis
l'extérieur du module où elles sont définies. Même si ces
fonctions n'apparaissent ni dans @EXPORT, ni
dans @EXPORT_OK, un programmeur est capable de
les appeler en utilisant le nom complètement qualifié,
avec le nom du module et les doubles deux-points.
Mais si tel est le cas, il mérite d'être
rongé par un sentiment de culpabilité permanent
et de ne plus être capable de dormir la nuit du sommeil
du juste.
-
Cette explication est valable pour les modules procéduraux.
Avec quelques adaptations, elle est valable également pour les
modules orientés objet. La différence essentielle est que les
méthodes que l'on a le droit d'utiliser n'ont jamais besoin
d'être déclarées dans @EXPORT ni dans @EXPORT_OK,
et que la syntaxe d'appel utilise une flèche ->
au lieu des doubles deux-points. Mais la convention du
souligné initial est toujours valable.
-
Rafael signale que l'analyseur syntaxique de Perl
prévoit la construction
my sub nom_du_sspgm {
mais pour l'instant, la présence du my
n'a aucun effet sur la portée du sous-programme.
-
Sébastien évoque encore un point tiré de ses lectures.
Au lieu d'utiliser le pragma use constant,
Damian Conway préconise l'utilisation du module
Readonly.
David a un mouvement de recul : encore un module
de Damian ! Non, ce module n'est pas de Damian, c'est
Eric Roode
qui l'a écrit.
Mais, rétorque David, c'est quand même un module
recommandé par Damian, donc un module suspect.
Je lui fait remarquer que parmi les modules recommandés
par Damian, donc suspects, figure
Regexp::Assemble.
-
David a alors expliqué la genèse de son module, pour le bénéfice
de ceux qui n'avaient pas encore profité de ses explications.
Il explique également quelques nouveautés, comme celle-ci :
lorsque l'expression régulière synthétique a trouvé une correspondance,
il est possible de retrouver quelle expression régulière
de base aurait donné elle aussi un résultat positif.
Cette fonction est basée sur une méthode consistant
à semer des miettes de pain, méthode qu'il désigne
sous l'appellation
« Hansel & Gretel »
(et que d'autres auraient appelée « méthode
du Petit Poucet »).
-
David nous parle de ses
résumés de l'activité des P5P.
Il s'est proposé pour reprendre cette tâche
car il voulait montrer que la communauté Perl 5
reste active et dynamique. Les gens mal avertis
ont l'impression que les projets qui ont le vent
en poupe sont
Python,
Ruby,
Perl 6,
alors que cela continue à bouger parmi les
Perl 5 Porters. Et les résumés
sont un élément important de l'activité des P5P.
David cite une personne qui a fait un don à la
Perl Foundation
en mentionnant dans son envoi que c'était
grâce aux résumés des P5P qu'il s'était rendu
compte de l'intérêt du développement de Perl.
David cite également
Michael Schwern,
qui trouvait que la lecture de la
liste des P5P
lui prenait vraiment trop de temps, genre trois heures
par jour, ce qui l'a amené à
se désabonner de la liste
et à se tourner plutôt vers les
résumés de David.
-
Rafael évoque l'époque où c'était lui qui rédigeait
les résumés. Il a abandonné car cela lui prenait
vraiment trop de temps. Surtout, fais-je remarquer,
que sur la fin, il cumulait cette charge de
rédacteur avec la charge de pumpking.
Il signale qu'un P5P a récemment fermé un bug
ouvert depuis 2002 et le P5P a rappelé qu'il avait
appris l'existence de ce bug dans un résumé de Rafael
datant de 2002.
-
Pour en revenir à David, il n'a pas pu se contenter
d'écrire les résumés. De temps en temps, il remarquait
un axe de réflexion ou d'amélioration et il se rendait
compte que personne ne s'en occupait. Et il prenait
cette amélioration à sa charge, se retrouvant alors
parmi les P5P actifs.
-
À ce propos, le jour même, David a soumis un patch
sur la liste P5P. La réaction de Nicholas a été
de constater que
le trafic sur la liste devait être bien réduit,
puisque le rédacteur des résumés
avait trouvé le temps de faire quelques corrections.
-
David a essayé une manip assez curieuse, qui donne un résultat
qu'il n'attendait pas : exécuter un
join
dans lequel le séparateur (le premier argument) est une variable
liée dont la valeur change à chaque lecture, par exemple, une
variable avec une post-incrémentation implicite à chaque lecture.
En codant :
package Incr;
sub TIESCALAR { my $x = 65; bless \$x }
sub FETCH { my $i = shift; chr($$i++) }
package main;
tie my $t, 'Incr';
print "$t and ", join($t, ('-') x 4), "\n";
# où est passé le B ?
il se serait attendu à lire la chaîne A and -B-C-D-.
Éh bien non, il obtient A and -C-D-E-.
Pourquoi ? Et où est passée la valeur B ?
Cela mérite-t-il un rapport de bug ?
Rafael a emprunté un portable avec une carte wifi pour pouvoir
accéder aux sources de Perl et il a répondu à la première question.
La fonction do_join lit une première fois la valeur
du séparateur pour savoir quelle est sa longueur (nombre de
caractères mais aussi encodage UTF-8 ou pas), de façon à
pouvoir allouer la place suffisante pour la chaîne résultat.
C'est à cette occasion que se produit la première incrémentation
et la perte de la valeur B. Je fais remarquer que
d'autres résultats étaient possibles eux aussi, par exemple
D and -C-B-A-, car il existe une clause dans
tous les langages évolués, signalant que l'ordre d'évaluation
des opérandes n'est jamais garanti, sauf dans des cas particuliers
(évaluation en court-circuit des and et des or).
D'autre part, que se passe-t-il si la variable de l'exemple
de David est initialisée à Z et que le FETCH
effectue une incrémentation alphabétique vers AA ?
Dans ce cas, l'allocation se base sur une longueur d'un octet
alors que la valeur de la variable en aura deux, n'y a-t-il pas
un problème ? Rafael me rassure, la préallocation
par do_join est simplement une optimisation préliminaire,
qui n'empêche en rien le contrôle ultérieur destiné à éviter les
débordements de buffer.
-
Rafael évoque la grosse amélioration du moment sur laquelle
il travaille : les variables d'état. En déclarant
state $compteur = 3;
on a l'équivalent de l'instruction C :
static int compteur = 3;
J'ai essayé de faire un peu d'humour en expliquant
que Rafael avait implémenté un filtre de source
pour convertir les déclarations state
en :
my $compteur = 3 if 0;
mais j'ai été traité d'ignare. Pour revenir à des choses
sérieuses, Rafael explique que les déclarations state
commencent à bien fonctionner, il reste quelques cas particuliers
qui posent problème, comme l'utilisation d'une telle variable
dans une clôture que l'on duplique avant que la variable
soit initialisée.
-
Rafael évoque également le plus gros patch qu'il ait soumis
sur P5P : un patch qui insère une ligne de mode
pour le mode Perl de vi et une autre ligne
pour le mode Perl d'Emacs.
-
David rend hommage à Andy Lester qui fait un nettoyage
bien utile dans les fichiers sources de l'interprêteur
perl. Par exemple, il signale qu'une
variable file_ptr est utilisée une première
fois en tant que pointeur sur fichier, puis dans un bloc suivant
en tant que pointeur sur chaîne. Autant fermer la portée
de définition de file_ptr une fois que l'on n'a plus
besoin du pointeur de fichier puis créer une nouvelle
variable string_ptr dans la portée syntaxique
suivante.
-
Un certain nombre de courriers pour l'association
« Les Mongueurs de Perl »
continuent à arriver à l'adresse de David l'ancien président,
au lieu d'être envoyées à l'adresse de D@vid le
trésorier. Les deux David ont profité de la réunion
pour faire parvenir au trésorier le courrier qui
lui revient. D@vid a jeté un coup d'oeil sur certaines
lettres et il a remarqué que l'une d'elles était
addressée à « Les Mangeurs de Perle ».
HTML 5 - CSS v3
Mongueurs de Paris, le 27 juin 2018
Copyright © The Paris Perl Mongers, 1999-2024