Présents à la réunion, en fonction de l'ordre d'arrivée
Laurent (B),
Théo,
moi,
Richard,
David (L),
Jérôme,
Olivier,
et Éric (glb).
Nous avons mangé de la salade de foie de lapin (il n'y avait
plus de gésiers), des travers de porc, une andouillette et
une bavette. Nous avons bu du pastis, de la vodka,
un diabolo-citron, de la bière blanche et de la Leffe.
C'est la première fois que Laurent assiste à une réunion du
groupe de Paris. Il a participé à la réunion du 9 février
au café après
l'Assemblée Générale,
mais c'était
une réunion de l'association « Les Mongueurs de Perl »
plutôt qu'une réunion du groupe Paris.PM. Idem pour les
réunions en ligne du premier lundi de chaque mois.
Il a déménagé de Grenoble vers la région parisienne
au début de l'année 2008. Auparavant, il était le seul
membre du
groupe Grenoble.PM.
La liste de messagerie avait
plusieurs abonnés, dont certains qui s'abonnent à toutes les
listes de Mongueurs, quel que soit leur emplacement géographique :
Philippe (BooK), Sébastien (Maddingue) et quelques autres.
Ce n'est pas la première fois que Richard vient à une réunion.
Il est déjà venu à
quelques occasions
avant
la conférence
YAPC::Europe 2003
où il
a fourni le Wifi.
[ J'ai relevé également la mention du prénom Richard lors d'une réunion
d'août 2007, mais je ne me souviens
pas s'il s'agit de la même personne.
]
Son problème, c'est qu'il assure un cours d'informatique à Cergy
le jeudi matin à 8 heures. C'est pourquoi il a des réticences
à venir à nos réunions du mercredi soir qui durent assez tard.
Pour une raison inconnue, cette semaine le cours aura lieu
à 9 heures. De plus, avec la grève des transports en commun,
Richard peut se permettre d'arriver à 9 heures et demie.
C'est pourquoi il a pu se permettre de venir à notre réunion.
C'est le retour des
Journées Perl 2008
à Albi.
Pour la partie Perl, parmi les divers points marquants
de cette conférence, il y a eu la discussion
sur les tris,
qui a eu lieu lors du repas
du vendredi soir. Si la fonction de comparaison d'un
tri
renvoie une constante 1, pour prétendre
contre vents et marées que $b est toujours
supérieur à $a, alors le
tri
inverse la liste, un genre de
reverse
en moins performant. Et que se passe-t-il si la fonction de comparaison
renvoie -1 ? Normalement, elle devrait laisser la liste
telle quelle, puisque $a est toujours inférieur à $b.
Vous pouvez essayer avec le script suivant, auquel vous devrez fournir
un paramètre numérique entre 1 et 26 :
Curieusement, il y a un seuil à 17--18, où le tri change de comportement.
L'un des participants à la conférence ne comprenait pas pourquoi il y avait
un seuil. La raison est sans doute la suivante : les tris
en O(n.log n) sont nettement plus compliqués que les tris
en O(n^2). Donc, pour n suffisamment faible, un tri en
O(n^2) est plus performant qu'un tri en O(n.log n). On peut supposer
que des tests ont été faits et que l'on a trouvé que dans l'interpréteur
perl, le moment où le tri O(n.log n) dépasse le tri O(n^2)
est lorsque l'on doit trier 18 enregistrements ou plus. Ou alors,
ce que je n'ai pas fait, on peut lire le source de Perl.
Ou alors, on peut demander à quelqu'un qui sait, tel David qui
résume les messages de la liste P5P.
Il nous explique que dans les anciennes versions, le tri
utilisé était le quick-sort de Hoare
(ou la variante Hoare-Knuth ?). C'est un tri
en O(n.log n) dans le cas général, mais dans le cas
le plus défavorable, il agit en O(n^2). Donc, il a été
question d'adopter un autre algorithme.
Un Perl-5 Porter a étudié la question
et a montré que le meilleur algorithme de tri était
le heapsort.
Puis quelqu'un d'autre a fait remarquer que la pratique
ne suivait pas ce résultat théorique et que, dans la pratique,
il était préférable d'utiliser un
merge sort.
En effet, le
heap sort
accède aux divers éléments du tableau à trier de façon apparamment désordonnée.
Tandis que le
merge sort
accède à des éléments voisins. Donc, le
heap sort
invalidera les caches mémoires de niveau 2 des processeurs, tandis que le
tri-fusion
en tirera partie. Si le nombre de comparaisons
est un peu plus important avec le
tri fusion,
cela provoquera néanmoins une activité inférieure sur le bus de données.
Toujours est-il que l'expérience effectuée avec le
script exposé ci-dessus est foireuse à la base.
La fonction de comparaison doit vérifier un certain
nombre de propriétés mathématiques :
la réflexivité : la comparaison de $x avec $x doit renvoyer
zéro pour signifier l'égalité ;
l'anti-symétrie : la comparaison de $x avec $y
doit donner le résultat inverse de la comparaison de $y avec $x ;
la transitivité : si l'on a $x < $y et $y< $z,
alors on doit avoir $x < $z
Or, le renvoi systématique de la valeur -1 contredit la réflexivité
et l'anti-symétrie.
Lors de la réunion, j'ai repris pour Théo l'explication que
Laurent avait déjà entendue au petit-déjeuner à Albi, sur
le bug
du module
DateTime::Event::Sunrise.
Voici les explications, mais avec des valeurs numériques précises.
Ce module est la conversion d'une
fonction C dans le domaine public
écrite par Paul Schlyter.
À un moment, la fonction sun_RA_dec
calcule la position du soleil en
coordonnées équatoriales
et renvoie donc trois valeurs,
l'ascension droite
et la déclinaison,
exprimées en degrés
et la distance Terre-Soleil, exprimée en unités astronomiques.
Or, les commentaires de ladite fonction C signalent seulement
les deux premières valeurs, ils n'évoquent pas la distance Terre-Soleil.
La distance Terre-Soleil permet de calculer le rayon apparent du Soleil
vu de la Terre. Ce rayon est en moyenne de 0,2666 degrés, avec un
maximum de 0,2711 degrés et un minimum de 0,2622 degrés.
On a besoin du rayon apparent car le coucher du soleil correspond
au moment où le sommet du cercle disparaît à l'horizon.
C'est-à-dire, dans le
système de coordonnées horizontales,
au moment où
le centre du Soleil a une hauteur égale à moins le rayon apparent du Soleil.
Dans la fonction C d'origine, le rayon du Soleil s'appelait sr
(sun radius) et son ascension droite sRA
(sun Right Ascension). Comme les commentaires ne faisaient
pas mention du rayon du Soleil, le Perliste a confondu sr et sRA.
La plupart du temps, l'ascension droite, en degrés, est largement supérieure à 1.
Donc, le rayon apparent du Soleil, résultat du calcul 0.2666 / $sRA
était quasi-nul, ce qui faussait l'heure de coucher du Soleil
en lui donnant une avance de 1 à 3 minutes,
selon la latitude du lieu considéré. Mais le 21 mars, l'ascension droite
vaut une fraction de degré. Donc, le rayon apparent du Soleil était nettement
plus important, ce qui provoquait un retard énorme. En prenant au hasard
quelques couples de longitude et de latitude, j'en ai obtenu un
(longitude 92,33 et latitude 48,83) pour lequel le Soleil était
tellement gros qu'il y avait toujours un bout qui dépassait, donc il
ne se couchait jamais. Et pourtant, ce n'était pas au Pôle Nord ni au Pôle
Sud avec le soleil de minuit.
Dans ce module, il y avait des
tests.
Le problème, c'est que ces
tests
évaluent le lever et le coucher du Soleil uniquement les 19, 20 et 21 juin.
Il utilise de nombreux endroits sur Terre, mais c'est uniquement
des dates au mois de juin. D'autre part, je ne sais pas comment
l'auteur a obtenu les valeurs de test. Je suppose qu'il a lancé le
test sur sa machine et qu'il a considéré que les valeurs obtenues
étaient les valeurs que le module devait fournir. En d'autres termes,
le fichier de test vérifie que les résultats sont identiques
d'une machine à l'autre, pas qu'ils sont corrects. J'ai fait
pareil lorsque j'ai corrigé son module. La bonne solution
aurait consisté à prendre les heures sur un calendrier de la poste
(à condition d'avoir une collection de calendriers couvrant
toutes les régions de la Terre) ou sur des éphémérides.
Ainsi que je l'ai signalé
dans le compte-rendu du mois dernier,
j'ai installé
Bundle::DateTime::Complete.
Or, certains modules plantent au make test.
Dans ce cas,
cpanp
demande s'il faut installer quand même ce module.
Si l'on répond par la négative, il arrête toute installation,
même pour les autres modules du lot, dont la plupart
fonctionnent très bien. Et si l'on répond par l'affirmative,
il installe le module qui a échoué et traite les
modules suivants. Curieusement, l'un des modules qui échoue
aux tests est le module
DateTime::Calendar::Hebrew
qui convertit la date en calendrier hébraïque et qui, pourtant, me
donne entière satisfaction.
Et pourquoi est-ce que je m'intéresse au calendrier hébraïque
et au coucher du soleil ? Parce que tous les matins,
j'aime bien lire ceci :
Revenons sur terre. Richard
s'intéresse, lui, aux coordonnées géographiques des
clients de la société pour laquelle il travaille, pour
savoir à quelle distance ces clients se trouvent
de telle ou telle agence. Cela l'a amené à programmer les
conversion entre les coordonnées Lambert 2 étendu,
utilisées par l'IGN,
et les coordonnées WGS
qui sont celles que donnent les GPS.
À noter qu'il existe en réalité plusieurs systèmes de
coordonnées Lambert 2 pour la France. Il y
en a un pour la métropole et il y en a un pour chaque
département ou territoire d'outre-mer.
En ce moment, le livre de chevet de Richard est la version française de
Perl Best Practices.
Un point qui l'a marqué est la nouvelle méthode pour
définir des objets en Perl, les
« objets inversés ».
Je comprends sa réaction. Nous avons l'habitude de nous représenter
une variable telle qu'un tableau, un hachage
comme un bloc compact de données élémentaires et nous nous attendons
à avoir la même représentation mentale pour une instance d'objet.
Et c'est le cas habituellement, une instance d'objet étant un
hachage « béni » par bless.
Or la méthode des
objets inversés
revient à répartir les attributs d'une instance
dans différents hachages, ce qui fait voler en éclats cette image
mentale d'un bloc compact.
Quelqu'un a demandé à David si les threads
fonctionnaient bien sous Perl. Éh bien pas vraiment.
Si le programme crée des threads trop
nombreux, il arrive un moment où ça foire.
David nous explique que les sources de Perl ont
migré d'un répertoire
Perforce
vers un répertoire
Git.
Et c'est grâce à
Sam Vilain[ le mal-nommé ]
que tout a été migré,
jusqu'au moindre message de commit.
Lorsque des Perl Mongers étrangers font du
tourisme, il arrive qu'ils participent à
une réunion des groupes locaux sur leur itinéraire,
voire qu'ils déclenchent une.
Hélas, comme le déplore David, cela ne
s'est pas fait pour le voyage de
Brian D Foy
ou celui d'Adam Kennedy.
Quelqu'un lui fait remarquer que le voyage d'Adam
est encore à venir, il aura lieu au mois d'août
et, semble-t-il, Adam sera hébergé par Kai.
À l'approche de la réunion, j'ai envoyé un message
sur la liste pour que les connaisseurs choisissent
éventuellement un restaurant. Mon message n'est pas
passé et comme le
site
indiquait le Maldoror depuis la
réunion du mois dernier,
c'est là que nous nous sommes retrouvés.
Cela dit, j'ai envoyé le message à quatre
reprises, ne voyant rien arriver dans ma boîte
électronique. En fait, pour une sombre histoire
de liste noire,
les messages ont été suspendus, sauf un pour
lequel j'ai été averti que le message n'avait pas
été remis à son destinataire. Une chance que j'ai
remarqué cet avis, en règle générale, ce sont
des messages de spam et je les purge sans les lire.
[ En fait, les trois autres envois, pour lesquels
je n'ai pas eu d'avis d'échec, sont arrivés sur la
liste le lendemain de la réunion. ]
En fait, la notion de spam est relative.
Richard évoque un collègue qui souhaite continuer
à recevoir certains messages considérés comme du
spam, mais qui expliquent comment améliorer ses
performances intellectuelles.
Il y a un an,
Orange
(anciennement Wanadoo)
a décidé d'activer gratuitement un
filtre antispam
pour tous ses abonnés, dont je fais partie.
Je relève mon courrier habituellement deux fois par jour,
le matin et le soir. Avant cette activation de l'antispam,
mon adresse visible sur le
Who's who de CPAN
recevait dans les 200 messages par demi-journée.
Après l'activation de l'antispam, je n'ai plus reçu
que les messages légitimes concernant réellement Perl.
Cela dit, au fil des semaines, de plus en plus de spams ont réussi
à traverser les mailles du filet.
[ ...jusqu'à ces jours-ci, où le nombre de spams est redevenu
quasi-nul. Sans doute Orange a-t-il mis à niveau ses règles de filtre. ]
Dans le temps, Richard utilisait
SpamAssassin.
Il a migré vers
ASSP,
qui est nettement meilleur : plus facile à
paramétrer, pratique le grey listing
(méthode qui consiste à demander à chaque serveur
SMTP d'attendre une demi-heure et de renvoyer le
message ; un serveur de messages légitimes
réessayera après une demi-heure de délivrer
ses messages, tandis qu'un serveur de spam
sera passé à une autre cible).
Mais que signifie « ASSP » ?
Cela me fait penser à « AS » pour
« assassin » et « SP »
pour« spam ». Il paraît que
ce n'est pas cela.
En réponse à une question d'Éric sur la surveillance
de nombreuses machines sur un même réseau,
David lui indique un utilitaire,
thcrut
qui émet des paquets IP soigneusement mis au
point pour analyser les machines connectées
au réseau. Les lettres « rut »
signifient « Are you there? ».
Il a été question du marché des noms de domaine.
Jérôme nous dit qu'il a enregistré son nom de famille
avec les suffixes .net et .org,
mais qu'il n'a pas le nom de domaine en .com
et que cela ne lui manque pas. De même,
BPI, l'employeur de David,
ne dispose pas du nom de domaine BPI, mais
est obligé de lui attribuer
le préfixe « groupe »
ou le suffixe « net ».
Récemment, ils
ont reçu un message leur signalant que le domaine
bpi.com était à vendre. Le prix se situe
dans les dizaines de milliers de dollars.
Ils ont répondu en proposant un autre prix en dizaines
de milliers de dollars, avec juste un peu moins de dizaines.
Il existe un site
qui suit les noms de domaine à trois lettres
plus le suffixe. Le plus cher est, vous vous en doutez
peut-être, sex.com, donc le prix est de plusieurs
millions de dollars. Le deuxième est fly.com,
loin derrière, mais encore dans les millions.
Et il y a les délaissés, des sites avec trois consonnes
inusitées qui n'intéressent personne.
Le marché des noms de domaine a produit une activité
dérivée, le parcage de domaines. Dès que l'abonnement
d'un nom de domaine arrive à son terme, un parqueur de
domaine souscrit l'abonnement pour ce nom de domaine
puis le met en vente, avec une plus-value confortable,
au détriment donc de l'ancien propriétaire, s'il cherche
à racheter le nom de domaine.
Il a été question du nom « Altavista ».
À l'origine, ce n'était pas un nom de domaine,
c'était un service fourni par DEC, à l'adresse
http://altavista.digital.com.
Le service ayant acquis de la notoriété, les gens
de DEC ont voulu acheter le domaine
altavista.com,
pour découvrir que le nom de domaine
appartenait déjà à un cabinet d'avocats.
Ce cabinet a accepté de vendre le nom de domaine,
mais à un prix confortable à l'aune de la
notoriété du moteur de recherche.
Ultérieurement, Altavista a introduit un
traducteur automatique, BabelFish, une autre
source de notoriété.
Curieusement, lorsque l'on demande maintenant
http://babelfish.altavista.com/
la requête est redirigée vers
http://babelfish.yahoo.com/
avec la mention de la redirection depuis Altavista.
D'autre part, pour ceux qui ont la flemme de taper les 9 caractères
du nom « Altavista », le site est disponible à l'adresse
http://www.av.com/.
Il a été question des sites montrant des photos prises dans
la rue. Il y a
Paris en photos,
mais aussi les photos de
Voilà
et celles de Google,
qui sont traitées par un logiciel permettant
de les fusionner pour donner l'impression à l'internaute
d'un déplacement virtuel dans la rue.
À un moment, David consultait Internet sur l'iPhone
d'un autre participant. Comme il avait un signal Wifi trop faible,
il a essayé d'obtenir une réception meilleure en
levant le téléphone et en l'approchant de la vitre
qui donne sur la rue. Or, juste devant le restaurant,
il y avait deux clientes qui étaient sorties pour
fumer une cigarette. En voyant le geste de David, elles
ont cru qu'il leur montrait ce qui était affiché sur l'appareil
et elles se sont rapprochées pour lire l'écran.
Est-ce que AIX peut fonctionner sans Perl ? Il semblerait
que non, car certains utilitaires d'administration du
système sont écrits en Perl.
Toujours à propos d'AIX, la version actuelle est la 5.3.
Il y a belle lurette que la 5.1 a été remplacée. Or
certaines banques continuent à utiliser la 5.1, car c'est
la seule version pour l'instant sur laquelle on peut
installer SWIFT,
le logiciel de transferts interbancaires.
David nous parle d'une (mauvaise) méthode de
programmation, la méthode par copier-coller.
Cette méthode permet d'avancer très rapidement
lors de la première écriture d'un programme.
Mais dès que l'on veut corriger ou faire
évoluer un bloc de code qui a subi un copier-coller,
c'est un cauchemar. L'un des collègues de David,
qui a utilisé cette méthode, explique qu'il était
pris par le temps et que c'est pour cela qu'il a
fait des copier-coller sans chercher à factoriser
son code. Pour David, au final, le bilan est
négatif. Quelqu'un fait remarquer qu'il y a
un autre argument en faveur du copier-coller.
Comme la productivité des programmeurs s'exprime
en nombre de lignes de code par jour, la méthode
du copier-coller permet d'obtenir des résultats
très favorables avec cette métrique (mais totalement
injustifiés).
Éric arborait un T-shirt à l'effigie du
SSTIC.
En effet, il a participé à cette conférence.
La conférence se tenait dans une
école de l'Armée de Terre,
située à Rennes. C'est d'ailleurs
là que travaille Anthony, depuis qu'il a
quitté la région parisienne à la mi-2006.
Théo et Olivier, qui sont restés un petit peu à Albi après
la conférence, racontent ce qu'ils ont visité. Il y a notamment le
musée Toulouse-Lautrec
à Albi même
et Cordes-sur-Ciel,
une bastide
dans les environs.
David a signalé à Éric l'existence du
MBTI,
une classification des profils psychologiques selon
quatre critères binaires, ce qui donne 16 catégories. Je rappelle que la
page perso de Larry Wall
mentionne qu'il est un
INFP.
Comme c'est la première fois que je viens au Maldoror
(il y a surtout eu des réunions hérétiques et impromptues
que j'ai toutes manquées), j'ai pu découvrir la décoration.
Certaines affiches ne datent pas d'aujourd'hui. En effet,
en bas à droite de l'affiche, on ne trouve pas la
formule de rigueur « http://www... », mais
son ancêtre,
« 3615 ... ».
Théo me fait remarquer également que les numéros de téléphone n'ont
que huit chiffres.