Le retour de Vincent

Un historique de toutes nos réunions

---

Table des matières

• mercredi 9 avril 2025 (précédent)
• mercredi 11 juin 2025 (suivant)
• Tous les comptes-rendus

mercredi 14 mai 2025

La voix du secrétaire (Jean)

Présents à la réunion, en fonction de l'ordre d'arrivée :

• Laurent (B),
• moi,
• Sébastien,
• Emmanuel,
• et Vincent, qui n'était pas venu depuis 2020.

Nous avons mangé des pizzas soleil, Angelina et 3-jambons, ainsi qu'une entrecôte au poivre, une tarte au citron, une tarte Tatin, une mousse au chocolat et un tiramisu. Nous avons bu de l'orangina, un kir, de la bière, un café serré et un déca. Le lemoncello était offert par la maison.

Nous avons parlé de Perl, Internet informatique et points divers.

Perl

• Le Perl Toolchain Summit s'est globalement bien passé. Laurent a vécu (ou commis) quelques anomalies mineures. Par exemple, il était prévu 40 participants et l'hôtel en avait été informé. Une fois toutes les invitations envoyées et toutes les réponses reçues, l'effectif final était d'une trentaine de participants. L'hôtel a été informé de la réduction du besoin d'hébergement. En revanche, rien n'a été signalé pour la restauration et l'hôtel a donc préparé des repas pour 40. D'où la remarque de la direction de l'hôtel,

  Les participants ne mangent pas beaucoup.

• Un point négatif par rapport au PTS de l'an passé, c'est que les salles de travail et la salle de restauration étaient situées sur des étages différents. À Lisbonne, les trois salles étaient au même niveau, ce qui facilitait la communication entre les différents groupes, notamment avec le stand up du début de la journée où chacun pouvait avoir connaissance de ce que les autres faisaient. À Leipzig, les groupes se formaient au petit-déjeûner et ne se mélangeaient quasiment pas pendant la journée.
• Du côté des sponsors; il manque encore la contribution du plus important d'entre eux. Espérons que cela se résoudra rapidement.
• Un incident qui n'a pas eu de répercussions importantes, c'est lorsque Laurent a voulu travailler en direct sur la base de données d'ACT. Il a fait une fausse manip et a détruit le contenu d'une table. Heureusement, il y a une sauvegarde à chaque heure et il a pu ainsi récupérer le contenu légitime de cette table. Pour la prochaine fois, il note qu'il vaut mieux faire les manip SQL à « et quart » plutôt qu'à « moins le quart », la sauvegarde étant plus fraîche.
• Pourquoi ACT utilise-t-il mod_perl ? Parce qu'à l'époque, 2003 ou 2004, il n'existait pas de logiciels tels que Rack pour Ruby et son équivalent Perl, Plack. Et parce qu'Éric a pris une part importante dans l'écriture d'ACT et qu'il était très bien placé pour la connaissance de mod_perl.
• Un point acquis lors du PTS est que la prochaine version s'appellera Perl 5.42 et non pas Perl 42 comme il était prévu.
• À ce moment de la réunion, nous avons eu un trou de mémoire collectif à nous quatre, Vincent n'étant pas encore arrivé. Lors des discussions sur les numéros de version de Perl, il avait brièvement été question d'un mécanisme annuel qui aurait donné « Perl 2025 » par exemple. Sébastien fait remarquer que ce schéma de numéros de version n'est utilisé que pour certains logiciels applicatifs, par pour des logiciels de niveau plus bas, systèmes d'exploitation ou logiciels de développement. Et les trois autres, nous n'avons pas démenti. Or, il existe de nombreux exemples de logiciels dont le numéro de version comporte une année. Côté systèmes d'exploitation, il y a Windows 95, Windows 98, Windows 2000 et les différentes versions d'Ubuntu. Côté langages de programmation, il y a Fortran 66, Fortran 77, Fortran 90, Fortran 95, Fortran 2008, Fortran 2018, Fortran 2023, Algol 60, Algol 68, de nombreuses versions de Cobol depuis Cobol 60 jusqu'à Cobol 2014, Ada 83, Ada 95, Ada 2005, Ada 2012, Ada 2022, C89, C99, C11, C17 et C23. Le seul exemple que j'ai cité est Python 3000, qui est un mauvais exemple car il ne s'agissait pas d'une date cherchant à prétendre que Python avait 994 ans d'avance, c'était une présentation tape-à-l'œil du nouveau numéro de version 3.
• [ Point ne faisant pas partie de nos discussions au restaurant, mais faisant suite au point précédent du compte-rendu ] Certes, on peut arguer qu'il faut faire la distinction entre la spécification du langage abstrait et le compilateur concret et que le numéro de version de l'un évolue indépendamment du numéro de version de l'autre. Toujours est-il que l'on peut trouver un compilateur nommé fort77, un autre nommé algol68g et vraisemblablement quelques autres. Pour en revenir à Perl, au début j'ai lu qu'il n'y avait pas de spécification du langage. Voir par exemple la note en bas de la page 275 de la première édition de Mastering Regular Expressions. Quelques années plus tard, j'ai entendu ou lu que, pour faire plus sérieux, et pour rassurer les décideurs pressés, on pouvait assurer qu'il existait une spécification du langage et que cette spécification était l'interpréteur perl écrit par les Perl 5 Porters. Donc, puisque la spécification de Perl et l'interpréteur perl sont la même chose, et puisqu'il est fréquent que les numéros de version des spécifications soient des années, pourquoi ne pas utiliser les années comme numéros de version de l'interpréteur perl ?
• Vincent a un problème technique. D'après le RGPD les fournisseurs informatiques doivent prévoir une fonctionnalité permettant à leurs clients de récupérer toutes les données qui les concernent dans la base de données du fournisseur. Dans le cas de Vincent, il s'agit d'un pg_dump pour le schéma de la base de données et d'un autre pour les données concernant le client, le tout stocké dans un fichier .tar ou .tar.gz. Le client peut déclencher la génération de ce fichier en cliquant sur un lien dans une application web. Le problème de Vincent est que la génération du fichier est assez lente (pour l'échelle de temps des applications web, c'est-à-dire un temps de réponse d'une trentaine de secondes, là où la coutume est d'avoir un temps de réponse de moins d'une seconde, ou à la rigueur de quelques secondes, mais pas plus). Vincent a essayé system qui ne résoud pas le problème du temps de réponse. Il envisage le module Apache2::SubProcess ou la fonction exec et il nous demande notre avis.
• Outre le module Apache2::SubProcess nous avons envisagé le module AnyEvent et un autre module dont je n'ai pas retenu le nom, mais ces deux modules ne répondent pas plus aux besoins de Vincent que le premier.
• Une façon de procéder consiste à effectuer le pg_dump et le tar dans un programme démon. Lorsque l'utilisateur clique sur le lien de génération de l'archive, l'application web envoie un message d'activation au démon, puis répond immédiatement à l'utilisateur que la génération du fichier est en cours. Ensuite, chaque fois que l'application affiche une nouvelle page ou de nouveaux éléments à l'utilisateur, elle en profite pour demander au démon où il en est, puis en faire part à l'utilisateur avec soit le message « génération en cours », soit le message « génération terminée », plus un lien vers le fichier archive à télécharger. Cette solution est très surdimensionnée par rapport aux besoins de Vincent, car elle est prévue pour traiter plusieurs extractions par jour, alors que dans le cas de l'application de Vincent, il peut s'écouler des mois entiers entre deux extractions.
• Une autre solution consiste à créer un processus d'extraction par fork + exec. L'architecture typique d'un programme créant un processus est

    my $prog = 'extr-client';
    my @arg  = qw(--client=toto --output=/tmp/extrait-toto.tar.gz);
    my $pid  = fork();
    if (!defined $pid) {
      die "Le fork a échoué";
    }
    elsif ($pid == 0) {
      # nous sommes dans le processus fils
      exec($prog, @arg);
      die "Le exec a échoué";
    }
    # nous sommes dans le processus père
    # vaquons à nos occupations
    ...
    # puis à un moment ou à un autre,
    waitpid($pid);
  

  Quelques remarques sur ce squelette de programme.
  • Tout d'abord, je ne l'ai pas testé.
  • Ensuite, interrompre le serveur Apache avec un die juste parce qu'un fork a échoué, c'est un peu brutal.
  • Également, il y a une bizarrerie apparente. D'une part, « on ne revient jamais d'un exec », alors pourquoi le faire suivre d'une instruction ? D'autre part, cette instruction est un die systématique, alors pourquoi faire planter le programme ? En fait, la véritable remarque sur exec est « on ne revient pas d'un exec, sauf si cet exec a planté ». Donc le die est conditionné par l'échec du exec.
  • Enfin, tel qu'il est écrit, le waitpid bloque l'exécution du processus père, ce qui fait réapparaître l'inconvénient que Vincent cherche à éviter. Une autre version de cette fonction, waitpid($pid, WNOHANG) permet au processus père de récupérer la main même si le processus fils n'est pas terminé, mais il faudra penser à faire un ou plusieurs autres waitpid($pid, WNOHANG) par la suite, jusqu'à ce que le processus père détecte l'achèvement du processus fils.
• Comment le processus père (Apache) sait-il que le processus fils (pg_dump + tar) s'est terminé ? En théorie, le processus père devrait effectuer un waitpid comme indiqué dans le squelette de programme ci-dessus. Ce n'est pas réaliste pour un processus Apache. La solution consiste en ceci :
  1. le processus père calcule le nom du fichier en sortie,
  2. le processus père transmet ce nom de fichier dans les arguments du processus fils, par exemple avec

         my @arg = qw(--client=toto --output=/tmp/extrait-toto.tar.gz);
       

  3. le processus père active insère dans le fichier HTML réponse une fonction Javascript qui s'exécute à intervalles réguliers (toutes les cinq secondes, par exemple), qui teste l'existence d'un fichier témoin dont le nom est le nom du fichier principal avec le suffixe .done, c'est-à-dire /tmp/extrait-toto.tar.gz.done. Selon le cas, la fonction Javascript affiche « génération en cours » ou affiche « génération terminée » avec un lien pour télécharger /tmp/extrait-toto.tar.gz.
  4. le processus fils alimente le fichier principal avec le nom demandé en prenant le temps nécessaire,
  5. une fois le fichier principal fermé, le processus fils crée le fichier témoin, dont le contenu est vide et, ainsi que cela a été écrit plus haut, dont le nom est le nom du fichier principal avec le suffixe .done. Il y a plusieurs façons de faire, par exemple :

         touch /tmp/extrait-toto.tar.gz.done
         cat /dev/null > /tmp/extrait-toto.tar.gz.done
       

• [ Point ne faisant pas partie de nos discussions au restaurant, mais faisant suite au point précédent du compte-rendu ] Pour aller plus loin sur la question des fork+exec, notons qu'ils ne sont pas inséparables. On peut envisager d'utiliser fork sans exec en codant dans un même fichier source à la fois le processus père et le processus fils, mais reconnaissons que c'est plus propre de séparer les deux sources. En revanche, utiliser exec sans fork est envisageable. Supposons que vous disposiez d'un utilitaire en ligne de commande, un utilitaire surpuissant avec tout plein d'options et de paramètres que vous avez du mal à retenir. Par exemple, curl (3169 lignes de man) ou rsync (3205 lignes de man). Pour éviter de devoir relire la page de man en totalité chaque fois que vous utilisez rsync vous écrivez un script wrapper (emballage) qui reçoit un éventail réduit d'options, les contrôle, les traduit vers l'éventail élargi des options de l'utilitaire standard et lance cet utilitaire. Le script emballage ne fait plus rien du tout après le lancement de l'utilitaire. Comment lancez-vous l'utilitaire standard ? Par system ? Cela crée un processus fils. Par exec ? Vous évitez ainsi la création d'un processus fils. L'optimisation est peut-être minime, mais ça ne fait pas de mal et c'est intellectuellement gratifiant.

Internet

• Laurent demande si, à notre connaissance, le navigateur en mode texte « line-ksss » (merci de prononcer « à la française » comme s'il s'agissait de Line Renaud) est compatible avec Gitlab. Sébastien et moi lui demandons s'il s'agit de Lynx, le félin (prononcer lin-ksss, comme s'il s'agissait de la plante produisant une fibre textile) ou de Links, l'autre navigateur, voire de Elinks. Laurent avait l'air de ne connaître que Lynx, le félin. Gitlab utilise abondamment Javascript, donc cela exclut Lynx, qui n'a pas d'interpréteur Javascript incorporé. En revanche, les deux autres navigateurs supportent Javascript et sont donc vraisemblablement compatibles avec Gitlab.
• Emmanuel a vu une vidéo comparant le Fanta américain au Fanta européen. Dans le Fanta européen, on trouve quelques ingrédients. Dans le Fanta américain, on en trouve beaucoup plus. Nul doute que ces nombreux ingrédients contribuent à la couleur fluo de la boisson, alors que la variante européenne, sans être terne, est plus discrète. En fait, l'auteur (américain) de la vidéo recherchait simplement du jus d'orange avec des bulles, pas des effets spéciaux visuels. Plusieurs commentaires écrits par des Européens mentionnaient Orangina, donc l'Américain a réalisé une nouvelle vidéo pour comparer Orangina et Fanta. La seule bouteille d'Orangina qu'il a trouvée portait des inscriptions en polonais. Peu importe, le goût de l'Orangina a été pour lui la révélation de la perfection. [ Notons une troisième vidéo, tournée entre les deux présentées ci-dessus, qui compare le Fanta américain pour les couleurs autres que l'orange et le Fanta européen pour les arômes autres que l'orange. ]

Informatique

• Lorsque Vincent a parlé de ses extractions de base de données, nous nous sommes demandés si les fichiers obtenus convenaient à tout le monde, c'est-à-dire s'ils étaient lisibles sur n'importe quelle machine récente. Tout d'abord, Vincent demande un dump en mode caractères, pas en binaire. C'est déjà un point. Mais les machines Windows connaissent-elles le format « tar » et la compression gzip ? J'ai deux réponses contradictoires que je ne peux pas vérifier, faute d'avoir accès à une machine Windows récente. La réponse que j'ai donnée en réunion, c'est que la plupart des applications récentes de compression pour Windows savent traiter les anciens formats, au moins dans le sens de la décompression. L'autre réponse m'est venue à l'esprit seulement à l'occasion de la rédaction de ce compte-rendu et provient de mes souvenirs à l'époque où les machines professionnelles successives que j'utilisais fonctionnaient sous Windows, mais j'avais l'habitude d'installer Cygwin, tar, gzip, zip en mode ligne de commande et quelques autres paquets similaires. Cette réponse, qui est plutôt un élément de réponse qu'une réponse à part entière, c'est que lorsque je voulais récupérer de l'espace disque sur ma machine professionnelle, j'archivais les dossiers à supprimer à la fois en .tar.gz et en .zip avant de les supprimer. Pourquoi créer les archives sous les deux formats ? Simple précaution ou leçon amèrement apprise (puis oubliée) ?
• Nous évoquons les processeurs des années 1980, quand la micro-informatique a pris son essor. À cette époque, les processeurs les plus utilisés étaient le 6502 et le Z80 ou Z80A, une évolution du 8080. Lorsque les constructeurs de micro-ordinateurs ont voulu produire des machines plus puissantes, les adeptes du 6502 se sont tournés vers la gamme Motorola 68000 tandis que les partisans du Z80 ont préféré les 8088 / 8086 et leurs successeurs 80x86.
• Toujours est-il que le 6502 est réapparu récemment, à l'intérieur d'une mini-console de jeu, avec un écran monochrome (mais qui émule les niveaux de gris grâge à une tramage astucieux), les seules concessions à la modernité étant une connexion USB-C et l'utilisation du Blue-tooth pour installer les jeux. Un autre point à noter est que le micro-processeur 6502 est « simplifié » par rapport à ses prédécesseurs des années 1980. En effet, les circuits pour l'addition BCD ont été supprimés. Au fait, BCD = « binaire codé décimal » ou BCD = binary-coded decimal, c'est-à-dire « décimal codé binaire » ?
• L'environnement de développement (SDK) pour cette mini-console est disponible au public. Prévoir une quarantaine de méga-octets. Quelle différence par rapport aux SDK actuels, dont la taille se mesure en giga-octets !

Divers

• Laurent se demande quelles sont les dates du Salon du Bourget. Les journées grand public sont le samedi 21 et le dimanche 22 juin. Les journées pour les professionnels commencent dès le lundi 16. [ J'ai oublié que le vendredi 20 était ouvert au grand public. ]
• En marge du PTS, Laurent a pu visiter Leipzig, guidé par un perliste du cru. Le premier bâtiment notable qu'il a vu est l'ancien QG de la STASI. La ville de Leipzig a été en grande partie remise à neuf à partir de la fin des années 1940 (on se demande bien pourquoi...) mais le style utilisé était plutôt le style du Leipzig historique que le style massif si souvent utilisé en URSS et dans les pays satellites.
• Pour le règlement des fournisseurs du PTS, essentiellement l'hôtel hébergeant l'événement, Laurent a utilisé une carte bancaire. Pas question d'utiliser un chèque, c'est un moyen de paiement très peu utilisé en dehors de la France. Rappelons que lorsque la monnaie unique (euro) a été instaurée pour les pays européens, les instances dirigeantes se sont intéressées aux pièces, aux billets, aux cartes bancaires et aux virements, mais elles n'ont pas jugé nécessaire d'étudier le cas des chèques. Heureusement, de nos jours, l'utilisation des cartes bancaires est bien répandue partout en Europe. Je rappelle une anecdote déjà racontée précédemment à l'époque où l'Autriche ignorait à la fois les chèques et les cartes.
• Nous avons parlé de monnaires étrangères. Sébastien évoque une devise d'un pays d'Amérique latine, pour laquelle il y a d'un côté le cours officiel et de l'autre côté le cours réel. Le but du gouvernement actuel est de faire converger ces deux cours, ce qui améliorera l'économie du pays. Cela me fait penser à un autre pays d'Amérique Latine, Cuba, qui a deux monnaies officielles. Il y a le peso cubain (CUP) pour les autochtones et il y a le peso cubain convertible (CUC) pour les touristes étrangers.