Deuxième réunion au Café Indiana
Un historique de toutes nos réunions
Comme le mois précédent, nous sommes allés
au Café Indiana, juste à côté de la Taverne
République. Nous avons mangé des nachos,
des enchiladas, un autre plat
à consonance latino-américaine, des burgers,
des fondants au chocolat et des tartes aux pommes, avec ou
sans glace. Nous avons bu de la bière et un
Blue Lagoon.
-
Alors que le mois précédent a vu la sortie d'un
film
et d'un
livre
dans la série
Harry Potter,
il n'en a quasiment pas été question lors de la réunion.
La seule fois où le nom a été prononcé, c'est pour
citer BooK, qui aurait écrit sur la liste P5P ou sur IRC :
La magie, c'est pour Harry Potter, ce n'est pas pour Perl !
Ce qu'il voulait indiquer par là, c'est que lorsque la machine
virtuelle Perl exécute un opcode, l'essentiel
de son activité consiste à tester les nombreux bits indiquant
si telle ou telle fonction « magique » est associée
aux opérandes de l'opcode, avant
de savoir s'il faut effectuer le boulot de la façon la plus simple.
Or, cette façon la plus simple est également la plus commune.
Vous comprenez bien que ce n'est pas comme cela que l'on
obtient une exécution optimale du programme.
-
Richard nous a décrit un problème mais j'avoue que je n'ai
pas pu le reproduire lors de la rédaction de ce compte-rendu.
Il cherchait à créer un hachage à partir de la liste de ses
clés. Il a donc essayé :
%hachage = map { $_ => 1 } @liste;
et chez lui, cela ne fonctionne pas. Mais chez moi,
cela fonctionne. En revanche, le code suivant :
%hachage = map { ($_, 1) } @liste;
fonctionne pour lui (et pour moi). À noter qu'en s'inspirant
du paragraphe suivant, on pourrait utiliser :
@hachage{@liste} = (1) x @liste;
-
David évoque les
slices
de hachages.
Par exemple, en partant du hachage :
( cle1 => valeur1, cle2 => valeur2, cle3 => valeur3 )
on peut obtenir le hachage suivant :
( cle1 => nouvelle_valeur1, cle2 => valeur2, cle3 => nouvelle_valeur3 )
en codant simplement :
@hachage('cle1', 'cle3') = ('nouvelle_valeur1', 'nouvelle_valeur3');
ou mieux
@hachage(qw/cle1 cle3/) = (qw/nouvelle_valeur1 nouvelle_valeur3/);
En revanche, si l'on veut transformer le hachage
( cle1 => { k11 => v11, k12 => v12 },
cle2 => { k21 => v21, k22 => v22, k23 => v23})
en
( cle1 => { k11 => v11, k12 => v12 },
cle2 => { k21 => nouv21, k22 => v22, k23 => nouv23})
c'est beaucoup moins élégant. Il faut écrire :
@{$h2{cle2}}{qw/k21 k23/} = qw/nouv21 nouv23/;
Une horreur, dès le deuxième niveau !
-
Richard évoque un autre point qui l'a étonné en Perl, les
intervalles
(ranges). En contexte de
liste, ce n'est pas mystérieux, un intervalle donne la liste
des éléments entre la borne inférieure et la borne supérieure.
En contexte scalaire, un intervalle ne se comporte pas du
tout comme une liste en contexte scalaire. Je tente d'expliquer
que les intervalles en contexte scalaire servent essentiellement
à faire des tests à l'intérieur d'une boucle. Au début,
on teste la borne inférieure de l'intervalle. Tant que ce
test est « faux », l'intervalle s'évalue à « faux ».
Lorsque ce test est « vrai », l'intervalle s'évalue
à « vrai » et il teste la borne supérieure au lieu
de la borne inférieure. Il reste à « vrai » tant que le test
de la borne supérieure est « faux », puis l'intervalle passe
à « faux » lorsque le test de la borne supérieure est
« vrai ». Si la borne est un nombre, c'est le
numéro de ligne « $. » qui lui est comparé.
Si la borne est une expression régulière, c'est « $_ »
qui lui est associé. Voici un exemple où, de façon inhabituelle,
on n'utilise pas l'intervalle dans un test :
# Range en contexte scalaire
while (<DATa>) {
chomp;
my $x = /trois/..6;
my $y = "-$x-";
printf join ' ', $., $_, $y, "\n";
}
__DATA__
un.....
deux...
trois..
quatre.
cinq...
six....
sept...
Ce qui donne :
1 un..... --
2 deux... --
3 trois.. -1-
4 quatre. -2-
5 cinq... -3-
6 six.... -4E0-
7 sept... --
Et un autre exemple avec deux expressions régulières :
# Range en contexte scalaire
while (<DATa>) {
chomp;
my $x = /x/../t/;
my $y = "-$x-";
printf join ' ', $., $_, $y, "\n";
}
__DATA__
un.....
deux...
trois..
quatre.
cinq...
six....
sept...
huit...
qui a pour résultat :
1 un..... --
2 deux... -1-
3 trois.. -2E0-
4 quatre. --
5 cinq... --
6 six.... -1-
7 sept... -2E0-
8 huit... --
-
David évoque de nouveau
une question dont il avait discuté avec moi,
à savoir si l'on a réellement besoin des sigils
en Perl. Il trouve que cela réduit la lisibilité
des sources Perl. Le fait est que cela permet
d'interpoler sans peine une variable dans une chaîne
entre apostrophes doubles, mais on pourrait très bien
envisager que les sigils ne soient
utilisés que dans ce cas-là et qu'à l'extérieur des chaînes
de caractères, on trouve le nom de la variable sans rien
d'autre. Et s'il le faut, pour différencier les
tableaux des scalaires, il serait prêt à préconiser
un genre de
notation hongroise.
Olivier explique que pour ses variables tableaux, il
utilise des noms au pluriel tandis que pour ses variables
scalaires, il utilise des noms au singulier. Par exemple,
@adresses et $adresse. Donc, en enlevant
le sigil, il continuerait à faire la distinction
entre son scalaire et son tableau.
[ Ce qui s'oppose à une
remarque de David
où il disait prendre systématiquement des noms au singulier,
même pour des tableaux.
]
Stéphane s'est fait l'avocat des sigils
mais je ne me souviens plus de la teneur de ses arguments.
En revanche, je me souviens que Stéphane a signalé qu'à
une époque, il n'aimait pas l'usage que
Ruby
faisait des sigils. En Ruby,
cela sert à spécifier s'il s'agit d'une variable
de classe ou d'une variable globale, les variables
sans sigil étant des variables locales.
Pour Stéphane, cela constitue un point de blocage et c'est
pour cela qu'il ne s'est pas plus intéressé à Ruby.
[ Moi, j'aime bien les sigils en Perl. J'ai eu l'occasion de lire
un source C et j'avais du mal à identifier les noms de variable,
justement parce qu'ils n'étaient pas associés à des sigils.
Donc, ce qui constitue une gêne pour David constitue un
avantage pour moi et réciproquement. Et j'ai trouvé
un deuxième argument justifiant les sigils, argument
qui traduit le fait que Perl hérite de shell, mais argument qui
a perdu de la vigueur ces dernières années. À l'époque
où l'utilisation de use strict n'était
pas d'un usage quasi-systématique comme de nos jours,
l'inutilisation des sigils aurait laisser planer
une ambiguïté entre une chaîne sans apostrophes
et une variable auto-vivifiée.
]
-
Éric nous fait part de l'un de ses problèmes actuels,
comment comparer deux fichiers de configuration
écrits en XML. Évidemment, l'utilitaire diff
ne convient pas, car il examine les différences entre
lignes, sans tenir compte des balises d'ouverture
et de fermeture de XML.
David lui propose un utilitaire xml_diff
fourni avec
XML::Twig.
[ Apparamment, XML::Twig propose quelques
scripts utilitaires à titre d'exemples, mais aucun
d'eux n'effectuant de comparaison à la diff.
En revanche, j'ai trouvé un module
XML::Diff
qui semble faire l'affaire.
]
-
Il y a eu quelques moments d'incompréhension entre Olivier et
David à propos de ce sujet. Olivier souhaitait savoir si
l'utilitaire de comparaison était capable de prendre en
compte le fait que, dans certains cas, on peut considérer
que l'ordre des éléments n'a pas de signification. Par
exemple, considérer qu'il n'y a aucune différence entre :
<ensemble>
<element>A</element>
<element>B</element>
<element>C</element>
</ensemble>
et
<ensemble>
<element>C</element>
<element>B</element>
<element>A</element>
</ensemble>
Pour David, c'était possible en SGML où il était possible
de spécifier la relation entre deux éléments par un « ou »
ou un « et », tandis que XML ne connaît que la
concaténation. Mais selon Olivier, il doit être possible
de spécifier dans XML-Schema que ce qui est une concaténation
pour le méta-langage XML doit être interprêté comme un « ou »
sans tenir compte de l'ordre dans tel ou tel dialecte basé sur
XML. J'ai essayé de comparer avec Perl, en supposant qu'un
module implémentant les ensembles se baserait sur les listes
standards. Ainsi, les deux listes :
@liste1 = ('A', 'B', 'C');
@liste2 = ('C', 'B', 'A');
sont différentes, et pourtant les ensembles qu'elles
implémentent sont identiques.
-
Richard a lui aussi des problèmes avec XML. Il utilise un
parser Perl basé sur expat.
Tant qu'il cherche à analyser un fichier XML, tout va
bien. Mais s'il cherche à analyser un texte XML contenu
dans une chaîne de caractères, expat lui envoie
des avertissements. Bien entendu, des avertissements
ne l'empêchent pas de poursuivre le traitement, mais c'est
toujours désagréable lorsque c'est injustifié.
-
Lorsque l'on compare les langages dynamiques,
l'un des gros avantages de Perl est, comme
nous le savons tous,
CPAN.
Par comparaison, les
gemmes de Ruby
sont beaucoup moins fournies.
À l'inverse, il y a un point sur lequel
CPAN est en retard sur les gemmes. Les modules
Perl ont des noms bien terre à terre, comme
Class::DBI.
Tandis que chez Ruby, le module équivalent s'appelle
Active Record.
Ça en jette nettement plus, surtout auprès des
pointy-haired bosses.
-
Lorsque quelqu'un lance un troll sur la comparaison entre
les langages de programmation, la discussion est habituellement
enflammée. Sauf lorsque le trolleur a affaire à la communauté
Perl. C'est ainsi que David a noté une
discussion sur ce sujet
au cours de laquelle quelqu'un a cité une
réflexion de Steve Yegge.
Lorsque le dénommé Steve s'en prend à un programmeur
Perl et lui dit que Perl, c'est laid, le programmeur
Perl approuve, puis laisse la discussion en plan en
disant : « Et maintenant, j'ai du travail
à continuer... »
-
Éric nous rappelle qu'il y a un
sondage sur la communauté Perl.
Le but est de savoir comment est peuplée cette
communauté, est-ce qu'elle est en voie de vieillissement
ou bien y a-t-il un afflux de sang jeune, et autres
questions du même acabit. Le programme de sondage demande
à chacun une adresse électronique, pour vérifier que l'on
ne répond pas plusieurs fois à ce sondage. Mais j'ai posé
la question de savoir
combien de fois Chris Nandor
avait répondu à ce sondage.
-
Lors du hackathon
à Arnhem, Stéphane a transporté la partie Perl de
la bibliothèque de
Liz Mattijsen.
Il est donc bien placé pour dire qu'il existe de
nombreux livres consacrés à Perl. La qualité n'est,
hélas, pas toujours au rendez-vous. En dehors de
Manning
et d'O'Reilly,
les bons livres Perl se font rares. Mais ça existe, comme
Higher Order Perl
chez Morgan Kaufmann Publishing.
-
Pour en revenir à Manning, Nicolas a été un peu déçu par
Objet-Oriented Perl.
Le livre permet de faire le point sur le sujet de la programmation
orientée objet, mais Nicolas n'y a rien appris de nouveau.
En revanche, quelqu'un (Nicolas ou un autre ?) a
beaucoup aimé
Data Munging with Perl
de Dave Cross.
-
Richard s'est développé une fonction de hachage perso, en Perl.
Il ne prétend pas avoir réalisé l'équivalent de
l'algorithme MD5
ou de l'algorithme SHA1
pour des besoins d'authentification. Son but est
tout-à-fait différent. Il a de nombreux fichiers PDF, quelque chose
comme 500 000, dont les noms sont stockés dans une base de données.
Et il doit construire un programme qui récupère l'un de ces
noms dans la base de données et affiche le fichier PDF.
Le problème, c'est que le système de fichiers utilisé digère mal
les répertoires qui contiennent plus de 30 000 fichiers.
Richard a donc décidé de créer des répertoires intermédiaires,
chacun contenant un nombre raisonnable de fichiers.
Comme ces répertoires ne sont pas connus de la base de données
documentaire, Richard est obligé de recalculer à chaque accès
le nom du répertoire et du sous-répertoire en fonction du nom
de fichier. C'est pour cela qu'il a écrit sa propre fonction
de hachage. Le nombre de niveaux de sous-répertoires et le nombre
de sous-répertoires par niveau sont paramétrables. À noter que
Richard avait pensé à utiliser la fonction que l'interpréteur
Perl utilise pour les hachages, mais il a laissé tomber,
car cette fonction varie d'une version de Perl à l'autre.
Quant aux mauvaises performances du système de fichiers,
la faute revient peut-être à la commande ls
qui trie les noms de fichier avant de les afficher.
Richard a-t-il essayé echo * ou ls -u ?
-
Éric s'est décidé à participer à
YAPC::Vienne.
Cela s'est passé dans le vol Moscou-Pékin.
Il a d'abord vu une femme coiffée avec des dreadlocks.
Il s'est dit : « Tiens, elle me rappelle quelqu'un. »
Après quelques instants de réflexion, il s'est souvenu
de la personne à qui cette femme lui faisait penser, c'était
à Thomas Klausner
et il s'est dit que la femme et lui iraient bien ensemble.
Et ensuite, il s'est aperçu qu'il s'agissait effectivement
de la femme de Thomas. Il a donc discuté avec Thomas et
s'est fait convaincre de passer quelques jours à Vienne
à la fin du mois.
-
Rappelons que le
style capillaire des organisateurs
a été proposé aux enchères lors de
YAPC-2006.
Nous ne verrons donc plus
Thomas avec des dreadlocks.
À la place, ce sera une coupe qualifiée
de Mohican ou d'Iroquois comme vous le préférez,
la couleur étant
orange.
HTML 5 - CSS v3
Mongueurs de Paris, le 5 novembre 2024
Copyright © The Paris Perl Mongers, 1999-2024