Marc a écrit 2064 commentaires

Pour installer mes applis, j'utilise Obtainium, qui permet d'aller récup les apk produits et signés par les auteurs originaux.

Je transmet ça à Matt :)

Oui, le fait que ça marche mal sur mobile revient régulièrement, et tu as raison aussi sur la raison qui fait que ça ne bouge pas. Le site repose sur monaco (https://microsoft.github.io/monaco-editor/) et son super mobile, ben voilà quoi :)

Un contournement qui est parfois acceptable est d'utiliser la version /noscript. C'est relativement moche, mais ça a le mérite de fonctionner pour les trucs simples. Après, j'irais pas essayer d'ouvrir le opt-viewer de clang ou un cfg-viewer *<:o)

Trop facile, le fix pour le diff est déjà presque deployé partout. Voilà un exemple: https://c.godbolt.org/z/cYKcsMG6z

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

A noter que libgccjit n'est pas impliqué dans gccrs. Dans gccrs, nous (enfin, surtout eux) réécrivons le frontend, en C++, à partir de rien (ou presque, comme tu as pu l'entendre pendant la présentation).
libgccjit est utilisé pour le projet copain rustc_codegen_gcc qui ajoute un backend gcc au compilateur rustc en utilisant la libgccjit qui ne fait pas vraiment du JIT du tout en fait :)

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.

ça se saurait…

Il y a un mode diff dans compiler explorer.

Oui, mais il est très limité hélas. Et puis il semble surtout cassé à l'heure où j'écris ce message. La bonne nouvelle étant qu'un fix est déjà en train d'être déployé (pas de moi).

Les stats de compiler explorer sont publiques

Oui, depuis cette année.

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

Nous ne supprimons jamais de compilateurs, leurs identifiants ne changent jamais, dans le but de préserver les liens partagés "à vie". Il n'y a aucun moyen mis en place pour supprimer/expirer/éditer un lien partagé. Il existe 2 types de liens: short et full. Le full est une simple sérialisation de la config de l'interface (position fenêtres, position curseurs, taille police, etc) et biensûr du code d'entrée. Nous ne sauvegardons rien concernant un lien "full". Un lien short, c'est simplement un full dont le résultat de la sérialisation est sauvé chez nous et auquel on accède via un lien "minifié".

Pour l'instant il y a une étape de modération des crates, donc même s'il n'y a aucune garantie que ça ne peut pas arriver, c'est un point qui est pris en compte.

Pour la signature des crates, cela sera revu plus tard quand le projet sera plus mature. En plus de demander une attention/expertise particulière, pour l'instant, l'objectif est d'abaisser l'effort nécessaire pour participer.

Oui et non. Parfois tu préfères quand même que ça soit du C, ça reste plus portable que de l'assembleur. Il arrive que de modifier un peu le code C permette à certaines optim de mieux fonctionner… J'ai pas de cas en tête, mais quand tu commences à avoir des boucles, des pointeurs, etc, c'est pas rare que ça freine pas mal le compilateur. Tu peux le constater dans l'assembleur (code sous optimal car manque de connaissance du compilo par ex), ou dans les passe d'optim qui t'informent du pourquoi elles ne font rien. Tu modifies le code (par ex en donnant/corrigeant des info de type, du restrict, changeant l'imbrication des boucles, …) et tu peux voir si ça va mieux. Le but n'est pas toujours de trouver le code C qui donnera le code ASM que tu as en tête. Sans compter que ce code devra être maintenu/porté. Souvent, ça guide aussi vers du code plus propre, plus lisible (j'ai bien dit parfois… parfois, c'est l'inverse).

Et parfois, c'est mieux de faire un bout d'asm, aussi. Je n'ai pas l'impression qu'il existe une solution parfaite à tous les cas :) CE vient aider pour certains cas, pas tous.

Cas particulier: debug de la description cible dans GCC: tu cherches à ce que le backend émette une instruction particulière.. Avoir CE qui te permet de facilement donner des petits coups de tournevis, ça aide à chercher.

PS/Edit: et il n'y a pas que le C non plus, même si on l'oubli un peu.

Quelques cas me concernant:
- tester un bout de code étrange "qui ne devrait même pas compiler" et voir ce que ça donne
- mettre au point une petite fonction isolée
- échanger un bout de code avec qq1
- tester la présence d'un bug dans un compilateur en fonction des version (conformance view est très utile)
- debug du backend de GCC avec la visualisation des sorties RTL. La possibilité de faire des diff permet de "trouver" la version de GCC ou l'option qui va changer le code généré (et pointer vers l'endroit à gratter)
- regarder ce qui sort du frontend Rust de GCC dans la première sortie de l'IR generic
- comparer le code émit pour le même code/compilateur mais avec options différentes
- très pratique pour éplucher/étudier des bugs (le bugzilla de GCC a souvent des liens pointant vers des exemples pour reproduire)

Matt a effectivement fait ça "sur du temps libre"… mais à son travail, c'est pour cela qu'il remercie son employeur de l'époque d'avoir accepté de publier librement le code (yoohoo).
Et s'il est vrai qu'au début, il s'agissait uniquement de voir l'assembleur émit par GCC, maintenant, c'est bien bien plus large:
- IR des compilateurs (tree/ipa/rtl de GCC, LLVM-IR, rustc HIR, GNAT Tree, d'autres) (d'ailleurs, pas besoin de passer -emit-llvm, c'est gérer par l'app qui l'affiche dans une fenêtre à part)
- compilation + édition de lien et affichage du code désassemblé
- exécution (x86_64 seulement sur le site public) du programme
- utilisation d'outils sur le résultat (pahole, readelf, …)
- outils d'analyse (OSACA, LLVM-MCA)

Il y a un mode IDE/Tree qui permet de gérer plusieurs fichiers, le support de CMake, la possibilité de faire des "diff" des sorties, support de bibliothèques (Boost, …), fonction magique permettant de faire #include sur une URL, …

Pour ceux qui sont passés à des claviers alternatifs, comment vivez-vous la cohabitation ?

Plutôt bien, mais j'arrive pas à faire de bépo sur un clavier classique, et je suis incapable de faire du azerty/qwerty sur mes ortholinéaires.

Pour la balade entre boulot/maison, j'ai plusieurs clavier (j'avais 2 typematrix, maintenant j'ai 3 claviers construits à la main).

Par ex, il y a plein de modèle là:
https://github.com/BenRoe/awesome-mechanical-keyboard

https://github.com/help-14/mechanical-keyboard#ortholinear-keyboards
Après à toi de fouiller… et y passer du temps pour la construction :D

Tu peux aussi en construire un. Mes 2 typematrix montrant des signes de fatigue, je me suis lancé dans la construction. Ça a (forcément) pris plus de temps que prévu, mais je pense que ça va dépendre de chacun, de ce que tu veux en retirer (je ne cherchais pas que à remplacer mon clavier). Au final ça donne ça :

https://github.com/dkm/pouetpouet-board

mais tu trouves assez facilement plein de clavier DIY, plus ou moins facile à reproduire chez toi.

Je me permet de mentionner Signal, qui détaille son processus de découverte des contacts:

https://signal.org/blog/private-contact-discovery/

Signal possède aussi depuis peu ce système de stickers, et là aussi c'est intéressant de voir comment ils ont mis ça en place avec les aspects sécurité/vie privée :

https://signal.org/blog/make-privacy-stick/

Dans les archives on retrouves des traces des travaux en 2015:

https://gcc.gnu.org/ml/gcc/2015-08/msg00226.html

Ça fait un moment que ça traîne, mais ça s'est accéléré cette dernière année car les devs en avaient un peu marre que ça tourne en rond, d'où la deadline décidée au Cauldron 2019: https://gcc.gnu.org/wiki/GitConversion

Je ne crois pas pour k9-mail, mais j'ai pas regardé. C'est vrai que c'est juste pas trop utilisable la recherche, je compte pas le nombre de fois où j'ai juste fait autrement…

Pour la localisation, je n'utilise que ça depuis des années, ça marche plutôt bien. Avec UnifiedNlp, j'ai activé le GSM Location Service, que je mets à jour de temps en temps (genre j'ai du le faire 1 fois en 2ans…). J'ai vu qu'il y avait des backend pour le wifi via mozilla ou apple, mais pas voulu tester.

Peut être que parfois ça met du temps à avoir une position précise, mais je ne sais pas s'il s'agit du soft ou du téléphone qui a du mal. Quand je compare avec le même modèle (fairphone2) avec toute la couche google, il y a les même problèmes de temps en temps.

Pour les mot de passe, j'ai password store que je partage entre mes machine via git/ssh. Simple, efficace :D

Si vous avez déjà des présentations de prévues, pourquoi ne pas mettre en ligne un programme même temporaire ?
Vu de l'extérieur, c'est un peu difficile de même savoir si ça nous intéresse…

« FLOSSCon2018 has the most awesome program ever! See rock-star speakers cover the topics of + liste de qqs thèmes un peu vagues», ça n'aide pas des masses, hélas. Si le programme est vraiment «most awesome», ça vaudrait sans doute la peine de donner plus d'indices.

Pas certain de poser un jour de congé en aveugle :)

De toute façon, il y a marqué ça sur le github : «NOTE - This repo has been abandoned in favour of Kort Native!»
Et Kort Native, c'est pour android et iOS. Dommage…

http://www.kort.ch/index_en.html
http://play.kort.ch/

Pas testé, mais ça semble correspondre à ce que tu cherches

Je m'attendais à cette réponse :) Non, je n'ai pas d'idée pour améliorer les illustrations. Je pourrais contribuer, c'est vrai, mais ça ne serait pas mieux. En l'état, je ne suis pas convaincu que ces illustrations apportent au contenu qui se suffit très bien (clair, précis, complet).

…C++ part du principe que les développeur*S* code*NT* …

Merci pour les dépêches, c'est toujours intéressant d'apprendre ces détails :)

PS: je ne suis pas super fan des illustrations de cette série de dépêches…

Ça date de cet été ce cadeau…

Ok, merci pour la précision :). En l'état, ça donne l'impression que le support de GCC 6 est bouclé alors qu'en réalité, c'est une tâche en cours ("Support des prochaines version de GCC" aurait été plus clair par exemple).

C'est pas plutôt gcc 5 dont il s'agit ici ? La version 6 (prochaine version majeur) est en cours de dev depuis très peu de temps.

j'ai toujours mon eee901, acheté dès la sortie du modèle linux. J'ai acheté il y a maintenant qqs année un SSD ~12G (me souviens plus), un Super Talent je crois (je dois pouvoir retrouver la ref, mais c'était globalement assez chers, même à l'époque, à presque 100€ les 12G). C'est le jour et la nuit: les SSD installés de bases sont vraiment des facteurs limitant. Certes, c'est pas une foudre de guerre, mais je n'ai plus que ça comme portable, et ma debian tourne nickel avec sans rien tuner de particulier.

http://www.kalray.eu/news-7/news/kalray-at-embedded-linux-conference-europe-2013-24-25-oct

Quel est le problème avec la AGPLv3 ?