serge_sans_paille a écrit 269 commentaires

let me douche-check this aspect.

Quand il fait chaud, le meilleur endroit pour réfléchir est certainement la douche froide !

«mais généralisons cette règle » => « mais généralisons cette règle »

Merci !

Phabricator est un outil de revue de code que j'ai croisé par deux fois : il était utilisé par LLVM avant son passage à Github comme l'explique l'ancienne url

Mozilla maintient un fork de l'outil dont le support n'est plus garanti upstream. Un scenario d'usage classique est la soumission de patch à travers un outil en ligne de commande (historiquement arcanist), la relecture de code via une interface web, la possibilité de suivre les différentes révisions d'un patch de manière claire (les commentaires sont attachées à chaque version), de créer des patchset.

Il est possible de créer des règles pour gérer qui revoit un patch en fonction des fichiers touchés etc. Du point de vue utilisateur, c'est un chouette outil. Je n'ai pas d'avis sur la partie administration.

Le billet mentionne std::remove_cv_ref_t mais il fallait bien sûr lire std::remove_cvref_t. Et il manque un espace après le «  ^^!

Journal très agréable à lire, merci beaucoup !

Pour la partie Python, je ne pense pas que son évolution diffère tant que ça de ces prédécesseurs, on commence par la foire à la saucisse, puis on se rend compte que le langage pensé comme un langage de glue est utilisé pour faire des applications complexes, qu'on a besoin de structure, et on colle cette structure (la PEP 484 que tu cites par dessus). Ce n'est pas un hasard si mypy a été développé chez Dropbox.

Au final, la difficulté c'est l'optimisation multi-critère. Un langage est pensé pour un objectif, puis il devient gourmand et veut en remplir un autre. Même pour les Pokemon, c'est difficile d'évoluer !

Merci pour ce journal sorti de l'espace ! On sent la passion transpirer à la lecture de ces lignes, c'est un joyeux mélange de story-telling et de technique, un régal pour les yeux.

Et je ne peux que me sentir bienheureux à pousser mes patchs sur la CI « pour voir » si tout marche bien, quand on voit les précautions à prendre quand on interagit avec du (coûteux ?) matériel qui tourne à un millier de kilomètres au dessus de nos tête.

Tu peux faire semblant que cela n'est qu'un mauvais rêve: about:config puis browser.ml.enable à false, et p'tet activer https://addons.mozilla.org/en-US/firefox/addon/udm14/ .

Puis supprimer les liens sponsorisés dans about:preferences#home

Voire désactiver toute ou partie de la télémétrie dans about:preferences#privacy

Alors oui, les choix ne sont pas aussi engagés que tu l'aimerais, mais au moins, tu as le choix.

Il y a des tentatives en cours (basées sur des dialectes):

• https://clang.llvm.org/docs/BoundsSafety.html
• https://clang.llvm.org/docs/AttributeReference.html#lifetime-capture-by (et ses sœurs)

Et j'adore ces programmes qui viennent d'une époque où la mémoire était une contrainte forte, et ou le traitement par ligne était nécessaire car les fichiers ne tenaient pas en mémoire :-)

Salut Octane.. ou qui ? [0]

Tu sembles rechercher l'émerveillement, celui que beaucoup d'entre nous ont trouvé en alignant leurs premières lignes de code.

À titre personnel, je le trouve aussi en découvrant les jolies constructions des autres. Et cela tombe bien, il y en a beaucoup ! Cela ne conduit pas forcément à des outils, des projets où autre chose de productive, plus souvent à des petits bouts de code lancés dans le terminal pour découvrir, expérimenter, comprendre et finalement atteindre ce petit bonheur de "ooooh, j'ai compris comment ça marche" et pas seulement "ah, ça marche".

Je vais prendre un exemple : je suis tombé (ouille) sur https://clang.llvm.org/docs/BoundsSafety.html . Je l'ai lu, ça m'a plu, alors j'ai compilé la version suggérée de clang, et j'ai observé. Fait des expériences, regardé le code généré, comment l'optimiseur s'en sortait, essayé de piéger l'outil etc. Et je pense avoir finalement bien compris. Et ça m'a plu. C'est ça le sentiment que tu cherchais, non ? Le fait que cela ne rentre pas dans le cadre du contrat qui te lie à ton employeur n'est pas si important.

Un peu comme un biologiste avec sa loupe qui découvre avec ravissement la nature qui l'entoure, tu peux prendre ta loupe informatique et regarder ce qui t'entoure, il y a beaucoup de choses dont on peut s'émerveiller !

À titre perso, j'en ai fait un petit jeu, et quand je trouve un de ces bonbons informatiques, je les transcris dans un petit article. Avant j'en faisais un journal ici, maintenant je le mets dans une petite série "les codes fantastiques" pour GNU Linux Magazine France (p.e. https://connect.ed-diamond.com/gnu-linux-magazine/glmf-271/les-codes-fantastiques-un-zero-pointe, https://connect.ed-diamond.com/gnu-linux-magazine/glmf-268/les-codes-fantastiques-co-vide , https://connect.ed-diamond.com/gnu-linux-magazine/glmf-270/les-codes-fantastiques-rembourrage ça passe en CC by ND après un délai).

C'est un peu hors sujet par rapport à ta question sur l'aspect professionnel, mais peut-être pas tant que ça ?

[0] ceci est un jeu de mot de piètre qualité

Je viens de reporter ça à https://safebrowsing.google.com/safebrowsing/report_phish/
Pour le moment https://transparencyreport.google.com/safe-browsing/search?url=mr.retraits-prbs.com dit que le site est OK, on verra si ça se met à jour dans les heures / jours à venir…

Firefox utilise cette base de donnée pour changer l'affichage des sites de hameçonnage, pour finir avec un truc du genre:

Plus d'info sur https://support.mozilla.org/fr/kb/comment-fonctionne-protection-hameconnage-logiciels-malveillants

Varions les plaisirs : de temps en temps un journal en français, de temps en temps un post en anglais ;-)

La lib rust utilise des fonction interne du compilo, par ce que des choses sont pas possible.

c'est beaucoup le cas pour la bibliothèque standard C++ également

C'était bien ça. Juste un petit bonbon syntaxique sans prétention :-)

>>> class a(*{++a},a=a--a): {}

template void foo(T) = delete;

Punaise ! Ça je ne connaissais pas dans ce cadre là, uniquement sur des fonctions membres. C'est super intéressant, merci  iniment. C++11 en plus.

Python n'étant pas vraiment un langage compilé (bien qu'il y ait une étape de compilation avant l'exécution hein), il était hors jeux.

En fait ma remarque fait écho à une intuition courante comme quoi « si on retire un #include et que ça compile toujours, alors cet include est inutile ». Un corollaire de mon example est que non.

Dison qu'on a pas le même bon sens.

je viens de relire le journal, et à aucun moment il ne mentionne l'avis de l'auteur :-)

C'est vrai qu'on pourrait avoir une fonction constexpr qui prend les chaines en entrées et renvoie un tableau initialisé et les offsets, ce serait plus maintenable :-)

Petite fierté personelle : krita utilise xsimd depuis https://github.com/KDE/krita/commit/70863966699379856e7fa08d0d8fc2aee4342c29 pour la vectorisation de certains algos. Le commentaire du commit fait chaud au coeur :

This brings Arm support to our backend for Free(tm).

J'ai mesuré, on est de l'ordre de 10^-6 secondes pour l'import de typing

Tiens tiens, une connaissance, salut, ça fait plaisir :-)

C'est la solution que j'ai utilisée au final, mais ce n'est pas très satisfaisant intellectuellement. C'est du typage graduel quoi Gradual_typing.

Bien tenté ;-)

En l'absence d'indication, on peut aussi imaginer que les déclarations soient globales, ce qui rend l'ensemble nettement plus intéressant (à défaut d'être complètement utile) et produit le code suivant, même en -O3 (et à juste titre) (cf. https://godbolt.org/z/cYP6j1bsh)

d:
        .quad   a
        .zero   8
b:
        .zero   8
a:
        .zero   4

Finalement, la seule vraie difficulté du quizz est effectivement jetée aux oubliettes, bien joué !

Il n'y a pas d'undefined behavior dans l'exemple si la déclaration a été faite au niveau globale.

La déclaration suivante :

int (*(c(void)))[10]

se lit de l'intérieur vers l'extérieur, en spirale en commençant par le nom de la variable et en commençant à tourner par la droite (tout en mettant un doigt sur le nez et en prononçant très vite l'incantation kerniganetrichie).

La déclaration suivante est valide :

int (*(c(void)))[10] { return 0; }

Très sympathique, cette enquête. Et une prose agréable, merci pour le partage ! Quelques, pistes, qui ne te seront peut-être pas accessibles vu les versions du compilo utilisées :

• comme mentionné dans un autre commentaire, --gc-sections est un drapeau de l'éditeur de lien qui permet de dégager les symboles non référencés et non exportés, à combiner avec -ffunction-sections.

• à défaut, on peut utiliser un orderfile qui force un order entres les différents symboles, assurant une meilleur localité du code. On peut le générer par instrumentation, avec dtrace, où (avec un clang "trunk") depuis les informations de profiling

• en post-link, on peut réordonner les sections en utilisant les informations de profilage, p.e. avec Bolt.

Si le premier SIGUSR1 est géré avant réception du deuxième SIGUSR1, c'est ok, non ? EN tout cas c'est le comportement que j'observe…