De retour des deux conférences
Un historique de toutes nos réunions
- "Sniper" est en colère. Pendant son absence, le client a demandé
un programme. Comme chez tous les clients, c'est à faire pour l'avant-veille.
Mais là, comme le programme n'a pas pu être fait à temps, l'affaire est
remontée par la voie hiérarchique jusqu'au niveau le plus haut de la maison mère,
et redescendue par la voie hiérarchique de l'employeur de "Sniper".
Le hic, c'est que la mesure adoptée prend le problème par le mauvais côté.
Puisque le programme devait être écrit dans un "langage exotique" (Perl),
dorénavant l'utilisation de tous les langages exotiques est interdite.
Seuls VB et Visual C++ sont autorisés. [ Cela rejoint
l'anecdote
de cette femme, qui s'est fait dérober sa carte bancaire dans une salle de
musculation, et qui a arrêté de faire du sport depuis. ]
- Un sujet qui revient assez souvent, c'est celui des
Perl Monks.
Nous évoquons notamment le cas de
Merlyn
(Randal
dans la vie de tous les jours). Une partie notable des Perl Monks s'obstine à
voter contre Randal, parce que c'est Randal. Donc, en fait, Randal acquiert des
points d'expérience lorsqu'il soumet des articles au site Perl Monks, et il les
reperd lorsqu'il s'absente pour des raisons de congés, et que les gens votent
contre lui.
- Sniper
évoque également le fait que lui-même a progressé de deux
niveaux en très peu de temps, sans rien faire ou presque. En fait, la
progression en points d'expérience dépend de facteurs très nombreux,
et pas seulement de la quantité et la qualité des contributions.
- Eric pose la question qui tue : "En fin de compte, tout bien
réfléchi, ça vous donne quoi, d'avoir des points d'expérience sur Perl
Monks ?"
- Une dernière anecdote sur le sujet : lors de YAPC::Europe, il
a été question de "votebots" (robots permettant d'accéder au site et
de voter, sans intervention humaine). Une fois la conférence terminée,
lorsque
Tim Vroom
a pu se consacrer de nouveau à l'administration de
son site, le sondage a changé, et la question posée était "Avez-vous
déjà écrit un votebot ? Avez-vous l'intention d'en écrire un ?"
- J'ai détecté un bug, qui se manifeste lorsque l'on utilise à la fois
Unicode et les variables @- et @+. Voici un programme
mettant en évidence le problème :
use utf8;
essai("zaabb", qr<(a+)(b+)>);
essai("\x{236a}aabb", qr<(a+)(b+)>);
essai("z\x{236a}\x{236a}bb", qr<(\x{236a}+)(b+)>);
sub essai {
my ($ch, $re) = @_;
$ch =~ $re;
print <<"RESUL"
Sous-chaine : substr(\$_, $-[0], @{[$+[0] - $-[0]]})
Premiere parenthese : substr(\$_, $-[1], @{[$+[1] - $-[1]]})
Deuxieme parenthese : substr(\$_, $-[2], @{[$+[2] - $-[2]]})
RESUL
}
Le résultat devrait être à chaque fois :
Sous-chaine : substr($_, 1, 4)
Premiere parenthese : substr($_, 1, 2)
Deuxieme parenthese : substr($_, 3, 2)
Mais on constate que dans le deuxième et le troisième cas, le début et la
longueur des sous-chaînes sont mesurées en octets, pas en caractères.
Des recherches ultérieures m'ont montré que ce bug existe en 5.6.0 et en
5.6.1, mais qu'il a été corrigé en 5.7.2.
- Je ne sais plus à quel propos Eric a évoqué le module
CGI.pm,
mais j'ai entendu qu'il remarquait que dans ce module, l'appel d'une méthode
était
plus rapide
que l'appel d'une fonction, ce qui est inhabituel, voire unique.
- De nombreux éditeurs de source proposent le coloriage syntaxique.
Le problème, c'est que la syntaxe de Perl est assez compliquée, je
dirais même très irrégulière, et que "seul Perl sait parser du
Perl". Il existe un certain nombre de constructions qui ne sont pas
traitées comme il faut par les éditeurs de source. De plus, quand tel ou
tel éditeur affiche les littéraux, ou les commentaires, en gris clair sur
fond blanc,... Du coup, j'ai décidé que lorsque je visualise un
source Perl
sous
Emacs,
j'utilise le
mode texte.
Cela fait sourire Eric.
- Cela dit, certains (pas moi) ont essayé
Perl-tidy,
et le coloriage obtenu paraît correct.
- La qualité des messages apparaissant sur la liste Paris-PM est très
variable. On trouve des messages illisibles, avec une orthographe et une
syntaxe inexistantes, et on trouve des messages soignés, écrits avec une
orthographe quasiment sans faille. Notamment, D@vid a remonté le niveau de
la liste, même s'il lui arrive d'écrire "blocant" à la place de "bloquant".
- Un autre mongueur fait attention à
l'orthographe, ainsi qu'en témoigne
la réponse à la question de NJ, et l'extrait ci-dessous :
[ exposé de la question ]
>
> Tu me corrige ?
Avec plaisir: s/corrige/corriges/ ;)
- Stéphane s'est remis à son "shellish Perl". Il explique comment il
résoud certaines ambiguïtés lexicales et syntaxiques. Par exemple, un
signe > peut être soit la comparaison de deux valeurs
(comme en Perl), soit une redirection vers un fichier (comme en
shell). Pour choisir, Stéphane a adopté la convention que si le signe
supérieur est suivi d'un blanc, alors c'est la comparaison de deux
valeurs, et s'il n'est pas suivi d'un blanc, alors c'est la redirection
vers le fichier demandé. Je lui fais remarquer que sa convention repose
sur une faille de sécurité. Si le programmeur écrit :
open FICHIER, ">$nom_fic" or die "Impossible d'ouvrir $nom_fic : $!";
et que l'utilisateur fournit le nom de fichier "> titi.txt", alors
le programme ouvrira le fichier sans vider le contenu initial, puisque
l'instruction d'ouverture reçoit ">> titi.txt". Je ne sais pas
comment exploiter cette faille, mais je suis sûr que quelqu'un a trouvé une
application. Pour boucher cette faille de sécurité, il suffit de mettre un
blanc :
open FICHIER, "> $nom_fic" or die "Impossible d'ouvrir $nom_fic : $!";
HTML 5 - CSS v3
Mongueurs de Paris, le 28 juin 2018
Copyright © The Paris Perl Mongers, 1999-2024