jeanas a écrit 185 commentaires

Cargo est parfaitement capable de créer et d'utiliser des librairies dynamiques, mais en gros les seuls qui le font sont ceux qui ont besoin de FFI avec d'autres langages (souvent C, mais aussi tout langage capable de comprendre l'ABI C, comme C++ ou Python).

Déjà, le principe même de vouloir mettre à jour une librairie dynamique sans recompiler ses dépendants est fondamentalement en conflit avec la monomorphisation des génériques, c'est-à-dire le fait qu'une même fonction dans la librairie peut être appelée avec des types différents dans le dépendant, non connus à l'avance, ce qui nécessite de la recompiler une fois par type avec lequel elle est utilisée dans le dépendant. C'est la même chose en C++ avec les templates. Toute tentative de créer une librairie dynamique à l'ABI stable se heurte à ce problème, qui rend le code pas du tout idiomatique parce que les génériques sont partout dans le langage.

Il y a une issue pour ça : https://github.com/rust-lang/rust/issues/69684

Le souci, c'est que les cas simples (comme le mien) sont faciles à implémenter, mais fournir une API qui couvre à peu près bien tous les cas intéressants est beaucoup, beaucoup plus compliqué. Il faut notamment penser à : ce qui se passe quand on rencontre un symlink vers un dossier, ce qui se passe quand on n'a pas les permissions, proposer une manière de limiter la profondeur de recherche, ou de filtrer des dossiers au fur et à mesure qu'ils sont lus (pour éviter de descendre dedans), etc. Donc je peux comprendre que ce soit trop pour la stdlib, même si ça se discute.

Je suppose que dans les 50 lignes produites par l'auteur, il y a plus que ça.

Non, il n'y a vraiment rien de plus que la base de la base (OK, 40 lignes, pas 50) :

useanyhow::Result;
struct WalkDir{
stack: Vec<std::fs::ReadDir>,
}
implWalkDir{
fn new(dir: &Path)-> Result<Self>{
Ok(Self{stack: vec![std::fs::read_dir(dir)?]})
}
}
implIteratorforWalkDir{
type Item=Result<std::fs::DirEntry>;
fn next(&mutself)-> Option<Self::Item>{
macro_rules!iter_try{
($expr:expr)=>{
match$expr{
Ok(x)=>x,
Err(e)=>returnSome(Err(e.into())),
}
}
}
loop{
letSome(top)=self.stack.last_mut()else{
returnNone;
};
letSome(next)=top.next()else{
self.stack.pop();
continue;
};
letnext=iter_try!(next);
ifiter_try!(next.file_type()).is_dir(){
self.stack.push(iter_try!(std::fs::read_dir(next.path())));
}else{
returnSome(Ok(next));
}
}
}
}

C'est juste que les itérateurs sont un poil verbeux, mais rien de très notable.

Il y en a qui ne peuvent plus allumer la lumière chez eux à cause de ça :

https://x.com/bortzmeyer/status/1806760064302072050

(désolé, je n'ai pas trouvé l'info ailleurs que sur X).

Les engins JavaScript modernes sont des monstres d'optimisation JIT. Cette fonction est extrêmement simple et se compile très bien. Il n'y a aucun polymorphisme, aucune branche, juste une boucle et des calculs flottants.

Il faut se garder d'en tirer des conclusions générales sur la performance de JavaScript, vu que la plupart du code réel ne passe pas la majorité de son temps dans des calculs numériques comme ça.

Au passage, voici une manière de ramener le code Python au même ordre de grandeur de performance que C et JavaScript :

import numpy
WINDOW_SIZE = 10_000
def wallis(n):
 a = 1.0
 for i in range(n//WINDOW_SIZE + 1):
 A = numpy.arange(i*WINDOW_SIZE + 1, min((i+1)*WINDOW_SIZE, n) + 1)
 B = 4.0*A**2
 C = B / (B-1)
 a *= C.prod()
 return a*2
print(wallis(10**9))

Je confirme. Mon propre serveur (pour https://lilypond.community) a été en blacklist dès le premier message (pourquoi tant de haine ?) et j'ai dû les relancer de multiples fois et refuser d'accepter plusieurs réponses « désolés, notre bullshit automatisé a déterminé que nous ne pouvions pas répondre favorablement à votre demande » avant d'obtenir le déblacklistage.

Même système (Fedora 40). J'ai cloné ton dépôt et fait sudo dnf install libshumate-devel meson; meson setup build; cd build; ninja. Pas d'erreur, j'obtiens un exécutable qui affiche une jolie carte.

Tu as passé des options particulières à Meson ? Tu as des réglages particuliers de pkg-config ? (env | grep PKG_CONFIG)

Maintenant que l'UE, le Royaume-Uni et le Japon l'ont fait, on peut espérer que d'autres pays suivent, mais quelqu'un sait-il ce qu'il en est aux États-Unis ? Est-ce qu'il y a des velléités dans ce sens ? Est-ce que leurs autorités de concurrence ou je ne sais-quoi observent les mesures des autres pays ? Ou est-ce que c'est simplement impensable dans leur culture ?

Ici : https://mastodon.social/@jwz/112580392962217146

Il existe déjà Minijinja, un clone de Jinja en Rust par le même auteur (Armin Ronacher). Avec la CLI kivabien.

• Meredith Whittaker, présidente de Signal, sur Mastodon : https://mastodon.world/@Mer__edith/112535616774247450
• Patrick Breyer : https://mastodon.world/@Mer__edith/112535616774247450

[Zut, le mot « théorie » dans le titre est une coquille pour « théorique ».]

Dans ce billet de blog, je parle du théorème de Gödel, donc pas vraiment dans le sujet des logiciels libres, mais comme j'ai aussi essayé d'expliquer ce qu'est l'informatique théorique en tant que science, je me suis dit que ça pouvait intéresser ceux qui se demandent ce que peuvent bien faire les universitaires dans les départements d'informatique.

Merci pour ces pistes, je vais regarder ça.

En fait, j'étais surtout inquiet car cette quantité de connexions me paraissait anormale, mais de ce que je comprends de toutes les réponses, c'est en fait courant. L'Internet est encore moins joli que ce que je croyais !

Pour la différence entre TCP et UDP, c'est simple:

• Un paquet TCP entre dans un bar, et commande une bière. Vous voulez une bière ? Oui, je voudrais une bière. Voici une bière.
• Un paquet UDP entre dans un bar, et commande un bière.

Oui, je comprends la différence à ce niveau-là. Mais je ne saurais pas expliquer comment s'agencent les bits d'un message TCP (en fait je ne connais même pas la taille moyenne d'un paquet TCP). Je ne cherche pas des réponses à toutes ces questions ici (je suis en train de me renseigner sur les réseaux en ce moment, de manière générale), je dis juste que j'ai beau être compétent en informatique — surtout du côté théorique — j'ignore plein de choses qui font partie des connaissances de base des gens qui administrent de vrais systèmes et réseaux.

« [Albert] sera également mis au service [...] de la gestion RH des fonctionnaires. »

Pardon ?

C'est un plaisir de lire une dépêche aussi détaillée, en plus bien écrite.

Je suis bien d'accord que c'est un cauchemar que l'État français officialise que les deux seuls compétiteurs possibles sur le marchés des smartphones soient Google et Apple. Pour les autres inconvénients, je n'en avais pas conscience et ça m'incite à me renseigner, merci pour l'info. En tous cas, je parlais plus du principe général que de l'implémentation particulière.

Personnellement, j'ai toujours trouvé l'application GNOME Software atrocement lente au point de l'avoir tout simplement désinstallée à chaque fois. Je désinstalle aussi le démon packagekitd, qui périodiquement se mettait à faire chauffer l'ordinateur en prenant beaucoup de CPU, et dont je suppose qu'il est à la racine de la lenteur de GNOME Software. J'installe tout en ligne de commande avec dnf et flatpak.

Peut-être qu'on va enfin se mettre à déployer à grande échelle des systèmes de cryptographie asymétrique comme PGP ou S/MIME, en les liant à une vraie vérification d'identité comme l'identité numérique certifiée.

Non, pardon, c'est juste moi qui rêve, là. Les mails vont continuer d'avoir une sécurité nulle et on va continuer les « Bonjour, vous avez été classé premier au concours de maître de conférences en cryptographie et nous vous en félicitons. Afin d'organiser votre recrutement, merci de nous envoyer par mail un scan de votre carte d'identité ainsi que le document ci-joint avec une photo de votre signature »...

Je suis tombé sur celui-ci par hasard : https://xkcd.com/1707/

... qui ressort d'une discussion avec un proche, c'est que ce genre de marketing n'est pas à destination des utilisateurs, mais à destination des investisseurs et de la bourse.

C'est drôle, je n'y avais absolument pas pensé, ce qui prouve bien que je n'y comprends rien au monde de l'entreprise.

https://drewdevault.com/2024/04/09/2024-04-09-FDO-conduct-enforcement.html

Réaction du Fedora project leader : https://discussion.fedoraproject.org/t/f42-change-proposal-fedora-plasma-workstation-system-wide/111343/41

En gros : la proposition a très peu de chances d'aboutir telle quelle. Par contre, il se dit ouvert à des propositions pour rendre KDE plus visible aux côtés de GNOME, sans pour autant changer le fait que GNOME est ce que vont télécharger les gens qui n'y connaissent rien et qui cliquent juste sur le premier lien dans le site de Fedora.

Rassurante : https://discuss.python.org/t/cpython-pypi-and-many-python-packages-are-not-affected-by-the-backdoor-of-xz/49873

https://refi64.dev/posts/dont-boycott-wayland.html démonte un certain nombre d'arguments plus ou moins fallacieux dans ce gist au ton excessivement polémique.

Oui, tu as absolument raison, j'aurais dû le préciser. Il y a quand même un certain nombre de cas où le compilateur ne peut pas déduire que l'indice est dans les bornes, comme quand on stocke des indices dans un tableau à l'intérieur d'un autre tableau, mais ce n'est pas si courant.

Par contre, dans le dernier exemple, j'ai l'erreur suivante:

Tu as oublié l'inversion des lignes selected_share = Some(share); et share_size = share_array.len();. Il faut d'abord finir d'utiliser share_array avant d'en transférer la propriété vers selected_share.

Il faut aussi que je m’intéresse plus à la partie unsafe et au lifetime.

La partie « unsafe » n'est pas utile pour 95% de la programmation en Rust. Mieux vaut réserver ça aux experts du langage qui en ont vraiment besoin et qui savent s'en servir correctement (comme les contributeurs à std), parce que c'est compliqué. Écrire du Rust unsafe correct est bien plus difficile qu'écrire du C correct. Il faut une compréhension fine de la sémantique du langage. Armin Ronacher a écrit un post de blog que je trouve intéressant à ce sujet.

Les lifetimes, par contre, font partie des bases du langage.

Sur la partie lifetime, j'ai beau comprendre à quoi cela sert et comment ça marche en théorie, je ne suis pas encore à l'aise avec. (Quand je parlerai de le deviner automatiquement, je pensais à l’élision qui pour le coup n'est pas vraiment du devinage). Je vais creuser un peu plus cette partie.

Je ne sais pas si ça va t'aider, mais pour ma part j'ai compris comment fonctionne le système quand j'ai réalisé les choses suivantes, que je ne trouve pas très bien expliquées dans la plupart des tutoriels.

D'abord, tout le monde parle du borrow checker et comme c'est magique, mais ce n'est pas le borrow checker qui fait tout. Par exemple, cette fonction ne compile pas : fn<'a>(x: &'a str) -> &'static str { x }. Et heureusement qu'elle ne compile pas, vu qu'on ne peut pas prendre une référence valable seulement pendant une durée déterminée et la transformer impunément en une référence valable pour toute l'exécution du programme ! Mais ce n'est pas le borrow checker qui vérifie ça, c'est juste le système de typage. Tout ce que fait le borrow checker, c'est l'inférence des lifetimes implicites à l'intérieur d'une fonction. Il ne remplace pas le système de typage.

En fait, une bonne façon de comprendre les lifetimes, c'est de les voir comme des types fantômes. On peut imaginer une variante du langage qui aurait de l'héritage entre structs (à la programmation orientée objet), et où les références seraient implémentées comme ceci :

struct Ref<T,U>{// correspond à « &'T U »
ptr: *U,// le pointeur vers la valeur de type U
token: T,// un « jeton de validité » de type T
}

Le code

fn convert<'a,'b: 'a>(x: &'bstr)-> &'astr{
x
}

est traduit en quelque chose comme ceci dans ce langage imaginaire :

fn convert<T,UsubtypeofT>(x: Ref<U,str>)-> Ref<T,str>{
letRef{ptr,token}=x;
Ref{
ptr,// ptr est déjà de type *str, pas besoin de conversion
tokenasT,// token est du type U, qui est sous-type de T, donc on peut le convertir en T
}
}

et le code

{// 'a
lets=String::from("foo");
lets_ref=&s;// référence valable pour 'a
{// 'b
lets_ref2=s_ref;// référence valable pour 'b
}
}

se traduit par

{
struct ValidityA;
lets=String::from("foo");
lets_ref=Ref{ptr: addr_of!(s),token: ValidityA};
{
struct ValidityBinheritsValidityA;
lets_ref2=convert::<ValidityA,ValidityB>(s_ref);
}
}

L'héritage entre structs n'existe pas, ma syntaxe struct ValidityB inherits ValidityA est imaginaire, mais tu vois l'idée. (En fait, le sous-typage existe en Rust uniquement à cause des lifetimes.)

Bref, fondamentalement, les lifetimes sont juste des paramètres de type comme les autres. En théorie, rien n'empêcherait que tous les lifetimes soient implémentés via des paramètres de type normaux. Le fait d'avoir une syntaxe différente est surtout une question de lisibilité.