Blackknight a écrit 1234 commentaires

  • [^] # Re: Merci, mais surtout ne nous enflammons pas, en effet

    Posté par  (site web personnel, Mastodon) . En réponse au journal Sortie de HAC. Évalué à 4.

    Je ne l'ai même pas fait exprès !
    C'est trop fort l'inconscient :)

  • [^] # Re: Lout

    Posté par  (site web personnel, Mastodon) . En réponse au journal Redécouverte : Roff. Évalué à 2.

    Super, merci !
    Belle explication !

    Je n'étais pas assez rentré dans les détails donc je te remercie de l'avoir fait.

  • [^] # Re: Lout

    Posté par  (site web personnel, Mastodon) . En réponse au journal Redécouverte : Roff. Évalué à 3.

    Pour moi l'utilisation de XML est rédhibitoire. Même en tant que simple format intermédiaire de sérialisation je suis contre.

    Pas de souci, il est vrai que le rapport signal/bruit n'est pas très bon.
    Le seul avantage par rapport à d'autres formats, c'est qu'il y a une grammaire et que l'on peut donc valider le document.

    Pas besoin d'outils spécialisés.

    Ben soelim, ce n'en est pas un peut-être ? :D

    Quant à XPath, ça ne permet pas que de récupérer les noms de programmes dans le texte mais aussi les noms de programmes mentionnés dans les see also ou en tant que termes d'un glossaire.

    Mais je comprends tout à fait ta préférence pour troff et je ne remets pas du tout ton choix en cause, y a aucun problème :)

  • [^] # Re: Lout

    Posté par  (site web personnel, Mastodon) . En réponse au journal Redécouverte : Roff. Évalué à 2.

    C'est un peu plus verbeux que Troff, mais beaucoup moins que XML (DocBook et consorts)

    Alors, je suis d'accord que Docbook est verbeux en raison du XML mais contrairement aux outils présentés ici, il ne s'agit pas que d'un formatteur.
    En effet, les balises portent une sémantique pour le fond et un peu pour la forme.
    Cela permet notamment d'utiliser sur le source des outils comme XPath pour extraire, par exemple, tous les noms de programmes mentionnés dans le document.

    Mais oui, c'est verbeux et il est parfois compliqué de choisir la bonne balise.

  • [^] # Re: Croiser les index :)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le Tiobe nouveau est sorti. Évalué à 3.

    Oui, j'avais bien compris, je fournissais juste la liste pour faire patienter :)

    Je vais essayer de trouver le temps de faire un journal sur la sortie de la dernière version de HAC.

  • [^] # Re: Croiser les index :)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le Tiobe nouveau est sorti. Évalué à 2.

    pour Ada, langage que j'estime beaucoup (du peu que je connais), j'aimerai bien voir des dépêches LinuxFR nous présentant des applications libres écrites avec (parce qu'à titre personnel ça me fait une belle jambe que ça soit très utilisée par une partie de l'industrie qui ne fait quasi que du propriétaire), mais j'ai peur que ça n'existe pas vraiment.

    Banco ! :)

    Bon, on pourrait commencer par parler de ça.
    Ceci dit, je peux aussi essayer de faire des journaux sur les mises à jour des softs open source existants.

  • [^] # Re: pardon, j'ai ri

    Posté par  (site web personnel, Mastodon) . En réponse au journal Une CVE dans le compilateur rust. Évalué à 3.

    indiquer dans le changelog qu'on recompile avec telle version minimale de Rust.

    Tu peux faire ça dans Cargo ou je me trompe ?

    [package]
    # ...
    rust-version = "1.56"
    
  • [^] # Re: C'est la bibliothèque standard qu'il faut patcher

    Posté par  (site web personnel, Mastodon) . En réponse au journal Une CVE dans le compilateur rust. Évalué à 4.

    seb et Blackknight parlent de la spec ("C++ dit de faire"), Gof parle de l'implémentation ("GCC/Clang fait").

    Bien vu ! Ceci dit, je m'étais plutôt focalisé sur

    dans quasiment tout les langages.

    C'est beaucoup plus général.

    Allez, je trolle :
    Ça veut dire que GCC/CLang ne respecte pas la norme, on ne peut pas les appeler compilateur C++17 ?

    Bon, pour Ada, c'est facile, la notion de lien symbolique n'est même pas précisée par la norme même si on peut l'associer aux special files qui sont normalement effaçables :)

  • [^] # Re: C'est la bibliothèque standard qu'il faut patcher

    Posté par  (site web personnel, Mastodon) . En réponse au journal Une CVE dans le compilateur rust. Évalué à 5.

    Je confirme, c'est bien précisé dans la doc

    The file or empty directory identified by the path p is deleted as if by the POSIX remove. Symlinks are not followed (symlink is removed, not its target).

    et

    Symlinks are not followed (symlink is removed, not its target).

  • [^] # Re: Tu fais ce que tu nous demandes de ne pas faire

    Posté par  (site web personnel, Mastodon) . En réponse au journal Comment j’ai été réduit en esclavage, comment vous m’avez aidé, et les leçons que j’en ai tirées. Évalué à 4.

    Pardon, j'ai pas dû être clair mais quand je parlais de sanctions, je parle de sanctions pénales tel que définies dans le code du même nom.

  • [^] # Re: Tu fais ce que tu nous demandes de ne pas faire

    Posté par  (site web personnel, Mastodon) . En réponse au journal Comment j’ai été réduit en esclavage, comment vous m’avez aidé, et les leçons que j’en ai tirées. Évalué à 4. Dernière modification le 20 janvier 2022 à 15:16.

    Rendre la vaccination obligatoire, ça veut dire sanctionner ceux qui ne le font pas et comment les sanctionner ?

    Concernant la vaccination obligatoire pour les enfants, il n'y a aucune sanction.
    Toutefois, le fait d'avoir facilité la contamination d'autres enfants peut faire l'objet de poursuites.

    Pour éviter les moinssages intempestifs, ceci n'est qu'un fait, pas une opinion.

  • [^] # Re: Cargo.lock affligeant

    Posté par  (site web personnel, Mastodon) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 3.

    Et franchement en étant ni dev RUST ni dev C/C++ je trouve ça beaucoup moins terrifiant que les fichiers boostrap, 1102 lignes, configure.ac, 750 lignes et Makefile, 215 lignes, init.cfg, 764 lignes qui semblent nécessaires à la compilation de la version GNU.

    La différence, c'est que ça, c'est déjà du code, pas des dépendances.
    En plus, c'est du code de build donc si tu veux comparer, il faudrait aller regarder comment est codé le cargo build.

    Au final, tu compares 3000 lignes de code avec un listing de 390 dépendances qui, elles,contiennent aussi beaucoup de code.

    Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.

  • [^] # Re: Croiser les index :)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le Tiobe nouveau est sorti. Évalué à 4.

    Je préfère ne pas donner la place d'Ada dedans, il y en a un qui va nous faire une dépression :-)

    163ème !!
    En même temps, ça compte aussi les issues et il est bien connu qu'en Ada, on n'a pas de bugs :D

    En y regardant mieux, devant au classement, on trouve les langages que sont Svelte (un framework javascript),Zig, BitBake (un langage de build) ou Ballerina
    Du coup, ça ne me fait ni chaud ni froid :D

  • [^] # Re: Cargo.lock affligeant

    Posté par  (site web personnel, Mastodon) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 6.

    Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.

    Bon, je vais faire fi du ton agressif et/ou hautain.
    Par curiosité, j'ai compilé ce code statiquement (hormis pour pthread qui refuse catégoriquement d'être compilé de la sorte) en utilisant la ligne suivante:

     c++ -o server server.cpp /usr/lib/x86_64-linux-gnu/libboost_iostreams.a /usr/lib/x86_64-linux-gnu/libboost_thread.a -lpthread
    

    Résultat, l'exécutable pèse 404Ko et la commande ldd me fournit:

        linux-vdso.so.1 (0x00007fff6e729000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd6dc2d0000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd6dc0ee000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd6dc0d3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd6dbee1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd6dc34f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd6dbd92000)
    

    On voit donc bien que Boost est compilé statiquement.
    Le poids cumulé des deux archives est de 968Ko, le linker a donc bien fait son travail.

    Du coup, comme tu listais aussi Gtk, j'ai fait un petit code en GtkAda qui match le code le plus simple du site gtk-rs.

    with Gtk.Main;
    with Gtk.Window; use GtK.Window;
    with Ada.Text_IO;use Ada.Text_IO;
    With Ada.Exceptions; use Ada.Exceptions;
    
    procedure simple_gtk is
    
       main_window : Gtk_Window;
    
    begin
       Gtk.Main.Init;
    
       main_window := Gtk_Window_New;
       main_window.Set_Default_Size (320, 200);
       main_window.Set_Title ("Hello, World! ");
    
       main_window.show_all;
       Gtk.Main.Main;
    exception
       when Error : others => Put_Line("Ouuupppsss");
          Put_Line (Exception_Information(Error));
    end simple_gtk;

    L'exécutable, compilé avec les infos de debug, pèse, quant à lui, 3.6Mo mais ne peut pas être compilé entièrement en statique, il semblerait que compiler avec Gtk en statique ne soit pas recommandé.
    Le binaire dépend donc finalement de 47 bibliothèques dynamiques.

    Et enfin, à titre de comparaison, j'ai créé le Cargo suivant pour compiler le hello world, mentionné en lien plus haut, en Rust:

    [package]
    name = "simple-gtk"
    version = "0.1.0"
    authors = ["Blackknight"]
    edition = "2018"
    
    [dependencies]
    gtk = { git = "https://github.com/gtk-rs/gtk3-rs.git" }
    
    

    Tout compile bien en release.
    L'exécutable pèse 3.7Mo et dépend de 69 bibliothèques dynamique… Donc finalement, ce n'est pas statique non plus.
    Par contre, la compilation en debug produit un exécutable de… 109Mo avec les mêmes 69 libs.
    Du coup, là, je suis preneur d'informations pour qu'on m'explique la taille !

  • [^] # Re: Cargo.lock affligeant

    Posté par  (site web personnel, Mastodon) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 3.

    Sauf que contrairement à npm, ça compile que les symboles nécessaire et ce de manière statique.

    Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.

    Le fait que tu n'as que peu de dépendances en C/C++ c'est dû au fait que tu n'as pas de réel gestionnaire de paquet pour ces écosystèmes. Au final, soit tu réinvente la roue, soit tu dépend d'une immense librairie type boost. Moue, j'ai jamais été convaincu.

    Carrément d'accord mais en même temps, cela vient aussi en doublon du gestionnaire de paquets de ta distrib.
    Par exemple, en Ada, il y a Alire qui reprend les mêmes idées mais qui vient concurrencer, par exemple, les repos Debian. Du coup, le mainteneur Debian peut se poser des questions quant à la pertinence de son travail.

    A la fin, on est bien content d'avoir un binaire unique qui n'inclus que ce qui est réellement utilisé. C'est plus facile à distribuer qu'un programme C/C++ qui dépend de dll/.so qui sont jamais distribués dans les bonnes versions par les distros.

    Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique… C'était même plutôt la norme il y a de nombreuses années.
    D'ailleurs, même aujourd'hui, rien n'empêche de compiler un code C/C++ en statique et de distribuer le gros binaire.

  • # Croiser les index :)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le Tiobe nouveau est sorti. Évalué à 3.

    J'ai toujours trouvé les stats du Tiobe un peu bizarres et pas seulement parce Ada n'est pas bien classé :)

    Perso, je préfère regarder ça en parallèle du PYPL.

    Il y a bien longtemps, un adaïste mathématicien, Gauthier, avait produit un code Ada pour faire la même chose mais ce n'est plus maintenu… Au moins, on a toujours le code.

  • [^] # Re: Merci

    Posté par  (site web personnel, Mastodon) . En réponse au journal Merci LinuxFr. Évalué à 2.

    Pour l'instant, la situation reste sous contrôle.

    On a connu pire :D
    Et puis, là, c'est fini donc ça devrait aller :)

  • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 3.

    Pour revenir à Ada, sur Gnat, le flag pour le contrôle du débordement des entiers était désactivé par défaut.
    Heureusement cela a changé car pas mal de nouveaux venus pensaient que cela ne fonctionnait simplement pas.
    L'ARM disant que le compilateur devait gérer prendre ce cas, Gnat a été mis à jour pour l'option -gnato soit active par défaut.

  • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 7.

    Ils ne fournissent pas de façon explicite l'implémentation, mais ils savent que c'est faisable et ils expliquent les grandes lignes. Alors que pour Ada il a fallut attendre très longtemps (plus de 10 ans de mémoire) pour avoir un compilateur et encore il a fallut bien plus de temps (30 ans?) pour avoir une implémentation complète.

    Si on regarde cette frise, les deux premiers compilateurs à passer les tests de conformité sont le compilateur de l'université de New York en 1983 et le compilateur pour Vax de DEC en 1984, puis ALSYS en 1987.
    Pour Ada 95, le compilateur Gnat est donc sorti en 1995, comme je l'ai déjà précisé, t celui d'Intermetrics pour le missile Patriot (because le runtime)… On est loin des 10 ans.
    Effectivement pour la version 2012, seul Gnat était prêt rapidement et PTC a sorti sa version 10 d'ObjectAda qui est certifié Ada 2012 l'année dernière.

    Quand tu dis Gnat résout le problème depuis 27 ans, il y a 27 ans son implémentation n'était que très partiel (Il y a 15 ans je lisais des articles expliquant a quel point

    Au risque de me répéter, je veux bien des sources !
    Il y a 27 ans, Gnat passait le test de conformité ACATS pour Ada 95 ce qui en faisait de facto un compilateur Ada 95 complet hors annexes non normatives.

    Je ne suis pas là pour dire qu'Ada est un mauvais langage, mais il faut quand même remettre les choses dans leurs contextes. Et quand pendant 20 ans ou 30 ans un langage est en développement, fermé forcément même si depuis 20 ans il est au point les informaticien s'en sont détourné et il n'a pas fédéré une communauté et se retrouve très discriminé. C'est une question de marketing.

    Donc si j'ai bien compris, tu considères aussi que le C++ est toujours en développement depuis 40 ans, encore plus fermé qu'Ada puisque la norme n'est pas récupérable librement et gratuitement (cf. le site isocpp) ?
    Ce qui est drôle, c'est que j'ai récupéré du code Ada 83 qui date de 1993 et qui se compile encore très bien sur un compilateur moderne… Pas mal pour un langage en cours de développement.

    En dehors de ça, ce qui a fait qu'Ada n'a pas décollé rapidement, c'est simplement que ce n'est pas du C-like mais Pascal-like.
    D'un autre côté, quand on venait du C, faire du C++, c'était simple (au passage, c'est faux sauf à faire du C with classes).
    Pour faire de l'Ada, il fallait apprendre un nouveau langage, de nouveaux concepts et se plier à une rigueur importante.
    Donc c'est chiant, ce n'est pas hackable facilement, on ne peut pas pisser de la ligne facilement sans se faire traiter par le compilo.

  • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 10.

    Les débordements d'entiers bouclent en rust

    Par contre, ce que je n'avais pas vu, c'est la différence de comportement entre le mode debug et le mode release

    The current status in Rust was decided in RFC 560:
    in debug mode, arithmetic (+, -, etc.) on signed and unsigned primitive integers is checked for overflow, panicking if it occurs, and,
    in release mode, overflow is not checked and is specified to wrap as two’s complement.

    Ca, je trouve ça piégeux.

  • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 4.

    sauf qu'en rust c'est un comportement défini).

    En C11 aussi il s'agit d'un comportement défini, tant que l'on parle d'entiers non signés (cf. ).
    Par contre, oui, pour les entiers signés, c'est un undefined behaviour.

  • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 4.

    Il y a aussi autre chose et non des moindre, c'est que si les spécifications ont toujours été assez libre d'accès les compilateurs ont toujours eu un train de retard et sont closed-sources pour les plus complet.

    Vrai en 1983, beaucoup moins à partir de 1995… D'ailleurs Gnat existe depuis cette date, quand le compilateur a passé l'ACATS 95 avec succès.

    En fait Ada est un langage qui ne proposait pas vraiment de solutions techniques. Et au départ, beaucoup de ses spécificités n'étaient pas implémenté fautes de solution techniques.

    Est-ce au langage de fournir les solutions techniques ? Les standards C et C++ ne fournissent absolument de façon d'implémenter le compilateur. D'ailleurs, il y a quelques années, au boulot, pour des raisons de performances, on utilisait ICC (Intel C++ Compiler) en lieu et place de GCC, les deux compilateurs différent dans la génération du code assembleur.

    Aujourd'hui c'est un peu différent car GNAT arrive a un niveau correct (mais derrière les version payantes, et même très chères).

    Encore une fois, je veux bien une source.

    Ceci lui fait un gros handicap marketing, il a une image de langage élitiste, mal fini et cher (un peu comme COBOL). Rust est tout au contraire, open-source, plein de librairies, avec un compilateur open-source…

    Ce dont tu parles date d'il y a plus de 30 ans et il y a un compilateur opensource conforme à la norme depuis 27 ans.
    Par contre, oui, il n'y a pas plein de bibliothèques contrairement à Rust.

  • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 4. Dernière modification le 22 novembre 2021 à 21:48.

    Coder en Ada est bien plus long et complexe que coder en Rust.

    C'est une question de point de vue :)

    A savoir qu'on peut vérifier qu'un programme Ada ne fera pas une boucle infini ou ne fera pas une multiplication qui dépassera la valeur d'un Int. Mais pour arriver a ce résultat, il faut tout dire a Ada.

    Alors si on parle de vérifier, ce sera via du Spark mais sinon, il y a juste à définir des types ce qui n'est pas en soi insurmontable.
    Alors oui, il faut tout dire mais ça documente aussi beaucoup le code.

    Surtout qu'Ada perd un peu en performance par rapport a Rust ou C/C++.

    Source ? Usuellement, on estime que le code Ada est 30% plus lent que le code C et équivalent au code C++, sans retirer les runtime checks sinon, c'est équivalent au C. Mais bon, j'ai pas plus de source :D

  • [^] # Re: License

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 3.

    Oui, bien sûr, il s'agit de Fabien Chouteau.
    Il travaille chez Adacore et est très sympa :)

  • [^] # Re: Perf

    Posté par  (site web personnel, Mastodon) . En réponse au journal la rouille et la comtesse. Évalué à 3.

    Je ne suis pas sûr de bien comprendre mais pour ton exemple de vitesse

    with Ada.Text_Io; use Ada.Text_Io;
    
    procedure Vitesse is
       type Distance is new Positive;
       type Speed is new Positive;
    
       function "*"(Left: Duration; Right: Distance) return Speed
       is
       begin
          return Speed(Left * Positive(Right));
       end "*";
    
       function "*"(Left: Distance; Right: Duration) return Speed is ("*"(Right, Left));
    
       My_Dist: Distance := 12;
       Time : Duration := 1.0;
    
    begin
       Put_Line("Speed = " & Speed'Image(My_Dist * Time));
    end Vitesse;

    Les types Speed et Distance dérivent du type Positive, la multiplication entre deux distances et entre deux vitesses est donc définies.
    Par contre, pour mélanger les types entre eux, je dois préciser de quoi il s'agit et comment doit être fait le calcul.
    Le type Duration est quant à lui un type flottant.