Suport technique et veille technologique

LinuxFr.org : les journaux  -  En passant par le FOSDEM, avec mes sabots 🎵

 -  5 février - 

Sommaire

• • • SemVer in Rust [track rust]
    • Writing your own rust linter [track rust]
    • The plan for gccrs [track rust]
    • Proving Performance [track rust]
    • In-Process Isolation for Unsafe Rust [track rust]
    • The Four Horsemen of Bad Rust Code [track rust]
    • foire fouille [track gdb et gcc]

Demat'iNal,

De retour du FOSDEM, je me permets de partager avec toi quelques notes techniques et découvertes glanées au fil des conférences.

SemVer in Rust [track rust]

Chouette présentation sur le semantic versionning. J'ai apprécié le temps passé à décrire les « différences d'appréciation » entre le SemVer strict et celui de Rust. Par exemple SemVer spécifie qu'une version majeur à zéro autorise de casser les APIs, mais la coloration Rust ne le permet pas.

Le but de la présentation était d'introduire semver-checks qui vérifie si un changement de code est correctement reflété dans le numéro de version. Amusant de voir une approche d'analyse du source pour faire ça là ou  se base sur les infos contenues dans le DWARF.

Il y a eu plusieurs exemples de cas subtils qui peuvent casser l'ABI, et c'était particulièrement ludique à voir :-)

Writing your own rust linter [track rust]

Encore une rpésentation d'analyse statique, cool. Il y a un blog post associé pour les curieux. J'ai surtout tiqué sur le fait qu'on pouvait s'insérer au niveau AST ou au niveau AST annoté suivant le type d'analyse à faire, et surtout que ces paquets se basaient sur les API internes du compilo rust, qui n'ont pas de garantie de stabilité ce qui demande un effort conséquent aux mainteneurs

The plan for gccrs [track rust]

Le retour de la vengeance du fils ! Fut un temps où clang défiait gcc dans on pré carré, là GCC vient titiller LLVM sur le terrain Rust. Vu les bénéfices mutuels qu'en ont retiré les deux communautés dans le monde C et C++, espérons que ce sera aussi le cas pour Rust.

Parmi les motivations, outre la pluralité chère à l'Open Source, on trouve le support d'architectures uniquement supportées par GCC.

J'ai particulièrement aimé les problème de bootstrap et les stratégies utilisées pour intégrer le borrow checker de Rust dans gccrs sans avoir à le réécrire.

David Malcolm était dans l'audience, ce qui a conduit à des discussions intéressantes autour de libgccJIT

Proving Performance [track rust]

Pour faire court, ça parle d'un équivalent de timeit pour Rust, divan (excellent jeu de mot ! a comfy bench(mark))

J'ai adoré l'utilisation d'une macro Rust pour spécifier un benchmark à travers une annotation, ça me donne des idées…

In-Process Isolation for Unsafe Rust [track rust]

Présentation plus académique sur l'isolation d'un fragment de code natif pour éviter qu'il ne « bave » sur le reste de l'application en cas d'erreur.

Là encore le système de macro de Rust apporte une couche de vernis syntaxique agréable, mais le corps du boulot se trouve dans la combinaison d'une analyse statique pour déterminer les zones mémoires à isoler avant un appel de fonction, et des mécanisme d'isolation que je ne connaissais pas mais qui semblent décrits dans un article de la présentatrice dont j'ai parcouru la partie « introduction du contexte » avec plaisir.

The Four Horsemen of Bad Rust Code [track rust]

Indépendamment du contenu technique, le présentateur nous a offert une masterclass niveau qualité des supports et de la présentation. Je n'ai pas trouvé de référence vers les sources, mais voilà de quoi vous faire une idée du style graphique.

Sur le fond, la description de plusieurs approche à problème était intéressante, surtout quand on se rend compte que les situations rencontrées se déclinent à volonté sur d'autres langages : ignorance, excessive abstraction, premature optimization et omission.

Oh et l'auteur dit s'être inspiré du One Billion Row challenge que je ne connaissais pas mais dont l'énoncé est amusant :-)

foire fouille [track gdb et gcc]

N'ayant plus de batteries à ce moment, j'ai été moins consciencieux dans ma prise de notes, j'ai donc juste noté des références qui m'ont interpellées. Toutes mes excuses aux présentateurs auxquels je fais donc une piètre hommage dans ces lignes.

• GCC a une config gdb pour positionner facilement des breakpoint à chaque fois qu'un warning est émis, pratique pour les devs de compilo.

• Je n'utilise pas trop les watchpoints de gdb, je devrais, surtout qu'il y a un support hardware

• gdb permet d'afficher élégamment le contenu de certains types si les bon prettyprinter ont été écris, et c'est le cas pour les structures internes de gcc, faudrait que je regarde si on a ça pour les types de base de LLVM. Et l'option /r permet de passer outre si besoin.

• Jeremy Bennett avait une magnifique cravate représentant un circuit imprimé.

• L'implémentation du reverse debugging dans gdb est super amusante à défaut d'être complète. Et

• Il existe une norme Unicode sur les identifiants l'UAX#31

• Le punycode permet de représenter toute chaîne Unicode en ASCII

• Il y a bien plus de monde bossant sur compiler explorer que je le pensait, dont un joyeux français qui moule lui aussi sur DLFP.

• Il y a un mode diff dans compiler explorer.

• Les stats de compiler explorer sont publiques

• Les tiny urls de compiler explorer sont voulues persistantes dans le temps, c'est donc a priori OK de les utiliser dans des rapports de bugs etc

Et une mention spéciale pour le camarade Lancelot Six qui a fait sa première présentation officielle au FOSDEM sur un sujet particulièrement technique !

Commentaires : voir le flux Atom ouvrir dans le navigateur

par serge_sans_paille