Blackknight a écrit 1244 commentaires

Bon, j'arrête cette étalage de cuistrerie.

Ouais parce que je vais pas tarder à porter plainte pour cyber-squattage de journal !!!

Décidément, ce journal recèle de contenus intéressants :)

Trop bien, je plussoie !

L'explication de Wikipedia est même

Le kelvin, n'étant pas une mesure relative, n'est jamais précédé du mot « degré » ni du symbole « ° », contrairement aux degrés Celsius ou Fahrenheit.

Comme dit l'émission :

vous mourrez moins bête mais vous mourrez quand même

Je suis bien d'accord avec toi, la popularité n'est pas la même du tout ;)

Les recherches sur Spark dans les moteurs sont toujours un peu ardues du coup.

Ça explique la montée du score du journal puis sa descente :D

Alors effectivement, après vérification, l'orthographe correcte est SPARK.

C'est parce qu'Ada est insensible à la casse que je n'y pense jamais :)

Après, si je voulais être mauvais joueur, je dirai que SPARK existant depuis la version Ada 83, on peut estimer qu'il y a antériorité et que de toutes façons, on devrait dire Apache Spark ;)

je n'imaginais pas que c'était des morceaux re-assemblés, je pensais plutôt des listes de dialogues tels quels

Ouais, c'est toute la beauté du truc. Ça permet même aux contributeurs de phrases de ne jamais se lasser de la sortie du CBSG.

La version exposée par Gautier est un simple CGI mais si le concept du CBSG te plaît mais que tu as peur de ne pas pouvoir fournir un service de qualitaÿ, il y a une solution pour toi.

Saches qu'il en existe une version permettant de scaler horizontalement très facilement en utilisant des technologies d'avant-garde, c'est le projet Distributed CBSG.

A partir de ça, tu peux balancer de la bullshit à donf

Alors, je peux parler pour le CBSG, ayant pu contribuer à quelques morceaux.

Les phrases entendues en réunion sont manuellement restructurées puis découpées afin que chaque partie soit intégrée dans le corpus adéquat (phrase typiquement CBSG™).
Cela donne donc le code infernal qui se trouve ici.

Du coup, je pense qu'il est possible de créer un fichier de fortune mais il sera assez conséquent compte tenu des cardinalités :D

uniquement 15 taggués ada dont aucune dépêche ;

Si y a des dépêches mais pas beaucoup et la dernière date de 2017 puis 2012.
Par contre, je compte plus que 15 contenus, y a 2 pages complètes.

Plus sérieusement, merci pour ce journal et surtout ce que cela annonce comme prochains journaux, voire, soyons fous, dépêches sur Ada et Spark.

Pour les journaux, j'ai potentiellement deux trois trucs sous le coude qui étaient passés dans les liens mais pour lesquels je pourrais écrire un peu plus de trucs.

Pour les dépêches, il devrait y en avoir une dans l'année assez importante. Il semble en effet que la prochaine version Ada 202X soit en fait Ada 2022.

Je suis, d'ailleurs, assez étonnée que le langage Ada n'ait pas sa propre section sur LinuxFr.

C'est certainement lié au manque de journaux et de news.

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

Super, merci !
Belle explication !

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

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 :)

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.

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.

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.

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"

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 :)

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).

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.

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.

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.

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

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 !

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.