• Avec le télétravail, les réunions présentielles sont concentrées mardi & jeudi, il y a donc moins de participants aux réunions dev@lal
• 4 items proposés à titre indicatif:
  • Make, utilisé par Antoine à l’ordre 0 comme aide-mémoire (la 1ere cible s’appelle help => cibles), utilisé par François aussi pour de la compilation, utilisé par Julius & Julien pour LaTeX et Antoine pour PDFs, par Julius pour beaucoup de choses
  • Versioning en Python: Depuis longtemps, Antoine utilise un paquet (boomversion ?) pour générer ses numéros de version en Python et s’assurer qu’ils soient cohérents à travers le paquet, mais pas sûr de bien le gérer. En python il y a __version__. (En C il y a des techniques à base de define + hash VCS)
  • Antoine a récemment essayé gitlab CI dans SVOM. A essayé docker compose, mais n’avait pas d’image à jour. Donc il s’agit de générer du docker dans docker… Il peut en parler dans un contexte Gitlab au CC.
  • PSPA: François a plein de choses à dire. Des déboires ont eu lieu avec la sous-traitance avec l’entreprise CGI, mais ça a été bien rattrapé et la fin approche. Le résultat s’annonce plutôt satisfaisant pour Antoine.
• Grande nouvelle: La prochaine version de mercurial sera en Python 3

PSPA

• Il y a une partie visualisation d’objets physiques dans PSPA, et CGI avait compris ça comme une visualisation graphique figée. Il s’agissait en fait de visualiser une machine complète avec des éléments interactifs. Cela a mené à une sous-estimation de l’effort par CGI, et donné lieu à un résultat catastrophique assez éloignée des besoins. Ils ont rattrapé le coup en mettant un très bon développeur qui a bien rattrapé le développement en 6 mois. Le LAL a cependant dû prendre certains bouts en charge, comme le contrôleur.
• Maintenant on visualise la machine, on lance les exécutions, on voit la sortie. C’est au LAL d’analyser les résultats, faire des courbes… ce ne sera pas fait par CGI. Comme le code est propre, bien architecturé, avec un découplage frontend/backend en flask, ce sera faisable…
• Grigory: Finalement, est-ce que ça valait le coup de sous-traiter plutôt que d’embaucher en interne?
  • l’expérience est formatrice pour l’équipe, et a permis un transfert de compétences intéressant
  • ça a coûté autour de 32k euros, incluant une analyse ergonomique assez longue avec les gens du DepAcc
  • Christian : remarque que la manipulation d’objets interactive ça existait déjà dans Pinball Construction Set sur l’Apple II
  • Maintenant, SVOM se lance dans Vue.js
  • Grigory se demande si ça servira d’exemple au CNRS pour externaliser le reste de l’informatique plus tard ?
  • Antoine : un poste permanent était impossible à obtenir, et un CDD de prix comparable avait peu de chances de réunir toutes ces compétences et vouloir travailler au CNRS
• Christian : l’externalisation force à exprimer correctement son besoin (Antoine: les ateliers sur l’ergonomie aussi)
  • Pas facile de concilier les besoins du DepAcc, ou même de les faire exprimer.

Makefile

• Les expériences HEP utilisent des systèmes d’exploitation très anciens, donc ils doivent recompiler des versions plus récentes de toute la pile applicative (compilateurs, bibliothèque…) par-dessus. On parle d’externals.
  • Souvent, c’est fait avec d’immenses makefiles, soit directement (cas de Belle 2) soit via une génération intermédiaire par CMake (cas de LCG)
  • Hadrien a dû activer les infos de déboguage dans les externals Belle 2, car c’est aujourd’hui nécessaire pour le profilage de code et en analyser les goulets d’étranglement
    • La faute à l’optimisation -fomit-frame-pointer, aujourd’hui activée par défaut .
  • Mauvaise idée d’activer les infos de déboguage partout, car c’est très coûteux sur certains paquets (ex: clang prend 2x plus de temps à compiler et pèse plusieurs Go en plus)
  • Il a fallu utiliser un hack horrible impliquant l’évaluation paresseuse de variables, la variable automatique $@ et le pattern-matching
  • Conclusion: Make est-il le bon outil?
  • Approches courantes: générer des makefiles (CMake, Meson…) ou plus rarement remplacer entièrement l’outil (Scons…)
  • Permet de simplifier et optimiser l’outil make puisqu’il n’est plus destiné à être directement utilisable par des humains (cf Ninja, tup…)

Adresses électroniques

• un WP a réfléchi sur le changement de nom du futur laboratoire et ses conséquences au quotidien : nouvelles addresses électronique, etc… Antoine Petit a aussi récemment proposé pour la visibilité du CNRS que tous les salariés CNRS  ait une adresse en cnrs.fr
  • Implique un changement de politique dans la gestion du courrier électronique (serveur commun, même pour une simple redirection)
  • Casserait beaucoup de services qui utilisent l’adresse électronique comme identifiant.
  • Officiellement, ça se produirait en septembre
  • Problèmes: doublons à gérer (Christian a rencontré des soucis lors de la transition Labintel -> Reseda dans Atrium)
  • Globalement, les noms sont des identifiants pourris…
  • Problèmes avec l’UTF-8

Consommation d’énergie des langages

• un article est sorti récemment sur le sujet.
  • L’analyse assez critiquable car elle ne prend en compte que la phase d’exécution et pas la phase de compilation, et les machines virtuelles n’ont jamais vraiment été adaptées à cet usage
  • Un compilateur JIT (just in time, qui compile par partie lorsqu’une partie est demandée, et pas tout d’un coup) et un ramasse-miettes font aussi du travail à l’exécution. On compare donc un travail d’exécution pour certains langages, et de compilation+exécution pour d’autres langages (utilisant une compilation JIT)
  • En terme de perfs d’exécution, on peut faire à peu près aussi bien que C++ avec une VM, cf. Sing#/Midori, Unity DOTS
  • Ce serait plus juste de chercher des implems Java optimisées pour la conso d’énergie. Il y a longtemps, on utilisait du java sur téléphone (J2ME), aujourd’hui la machine virtuelle Dalvik transformant le bytecode Java sous android pourrait aussi être testée.

Intégration continue