Un "pre-challenge" est déjà en ligne. Le début de ce prechall consiste à le trouver! Il vous permettra d'arborer une jolie flamme à côté de votre pseudo.
Je l'ai trouvé plutôt sympathique (mais pour être honnête, pas forcément trivial pour un débutant complet).
Je passe mon tour cette année par manque de temps, amusez-vous bien !
Pour reprendre ce que je disais sur les fonctions en *_or un des exemples que j'avais vu était sur ce type de fonctions:
let file = attributes
.into_iter()
.find(|f| f.name.eq(*filename))
.ok_or(std::io::Error::new(
std::io::ErrorKind::NotFound,
format!("File not found (not in attributs): {}", path.join("/")),
))?;
L'expression passée au ok_or() va être évaluée à chaque fois, y compris quand le résultat était un Ok. Pour s'en prémunir, il vaut mieux par la version ok_or_else qui prend un closure dès que le paramètre d'un ok_or (ou d'un unwrap_or) est non trivial.
Si tu veux t'en convaincre, voici un exemple spécifiquement forgé:
fn main() {
let mut v = vec![];
Some(1).unwrap_or({
v.push("foo");
1
});
Some(1).unwrap_or_else(|| {
v.push("bar");
1
});
println!("{v:?}");
assert_eq!(v, vec!["foo"])
}
Pour apprendre le rust, je le lançais en "pedantic", il faudra quand même trier ce qui est important dans la sortie: cargo clippy --all -- -W clippy::all -W clippy::pedantic.
En lecture (très) rapide, je vois un footgun assez réccurent sur l'usage des adaptateurs en *_or(todo!()) (unwrap_or, ok_or, …): il vaut mieux utiliser les adptateurs *_or_else(|| todo!()) dès que ce que tu veux mettre dans le todo!() a des effets de bords ou fait des allocations. Plus d'infos ici: https://rust-lang.github.io/rust-clippy/master/index.html#/or_fun_call
Rien de bien inventif et assez brutal: on propage le rayon lumineux comme indiqué dans l'énoncé jusqu'à sa sortie du tableau, en mémorisant les couples (x, y, direction de propagation) pour éviter de tourner en rond. Un algo très ressemblant à un bfs…
Pour la partie 2, du "brute-force" basique en testant toutes les entrées possibles.
Sans multithread, ça tourne en 620ms (parsing, partie 1 et 2) sur un seul core de mon Core i7 de 10 ans d'âge.
Je n'avais jamais essayé slint… Quelle horreur niveau nombre de dépendances et temps de compilation… mais ça a le mérite de faire des GUI de manière assez simple à ce que j'en vois.
Ton appli gère très mal les erreurs de générations de QrCode et crash si un problème arrive… Ce qui est ballot quand tu as tapé un très long message! Je t'ai fait une PR pour introduire une gestion très basique des erreurs (Affichage d'un message au lieu d'un crash) qui te permet au moins de conserver le texte que tu as tapé.
PS: Normalement, dans le cas d'usage SMS, l'erreur "data too long" ne devrait pas arriver.
PS2: Je ne serai pas utilisateur de ton logiciel mais j'en trouve le concept sympa et ça m'a permis de découvrir l'existence du crate "qrcode" et de découvrir très rapidement slint.
NOTE: your shell may have its own version of pwd, which usually
supersedes the version described here. Please refer to your
shell's documentation for details about the options it supports.
Le bourne shell, puis ses héritiers dont bash et zsh utilisent tous un builtin. La doc de bash précise
Print the absolute pathname of the current working directory. If the -P option is supplied, the pathname printed will not contain symbolic links. If the -L option is supplied, the pathname printed may contain symbolic links. The return status is zero unless an error is encountered while determining the name of the current directory or an invalid option is supplied.
Syntaxiquement, ça compile (peut-être, j'ai pas testé…).
Et comme avec tout langage (du C, du Python, du rust, du français), on peut balancer des mots qui n'ont ni queue ni tête et chercher le sens à tout ça…
Pour moi, un tel code ne mérite pas de vivre car il n'exprime aucun sens (d'autant que j'entrevois quelques bouts de "UB" qui vont être compilo-dépendant).
Sur ripgrep, exa, fd, … Pas certain de la nécessité de recompiler:
- ce ne sont pas des programmes privilégiés;
- j'ai du mal à voir où il pourrait faire un remove_dir_all
En revanche, je plussois sur l'inconvénient de la compilation statique… et même pire dans ce cas, le fichier 'Cargo.lock' ne référence pas, si ma mémoire est bonne la version de la librairie standard.
il serait peut être intéressant d'y installer emacs. Parait que certains gèrent aussi leur entreprise avec ça..
(troll on) Il y a déjà un dual-boot, pas la peine de rajouter un 3e OS! (troll off)
Si vous comptez "enseigner" du python, vu que vous êtes complètement hors-ligne:
* une distribution avec un lot de paquet pour disposer du minimum (on me souffle anaconda mais j'ai jamais testé…)
*jupyter notebook: pouvoir distribuer des notebooks où tu as un miw "Cours en HTML" avec le code a éxécuter dans ton notebook, pour une matière comme "Introduction au Python", c'est assez confortable!
Tu peux faire cela à l'aide de read. Ci dessous un court exemple: read -p "Qualité : " QUALITY
echo $QUALITY
Pour le choix du langage, tout dépend du niveau de contrôle que tu veux y mettre (ça peut vite être galère en Bash si tu veux contrôler que le fichier existe, que tu n'écrases pas un fichier existant dans la sortie, …).
Je plussoie, c'est clairement au développeur de connaître cette information et de l'indiquer au compilateur.
Si tu appliquais "le pire cas", tu donnerais implicitement du sens à une formulation ambigüe. Si tu es dans un cas où il y aurait seulement une des lifetimes dans la sortie, tu créerai implicitement une contrainte forte sur la durée de vie de tes paramètres --> Des messages d'erreurs cryptiques sur des références qui ne vivent pas assez longtemps seraient remontés par le compilateurs.
Le point problématique est: "sens implicite à une formulation ambigüe".
J'ai acquis un Epson Ecotank ET-2750 il y a 2 ans. C'est un combo imprimante et scanner. Pour le chargeur de documents, il fallait monter un peu en gamme (encore + cher), donc j'ai renoncé.
Elle a survécu à 2 années de Master de Mme et au suivi pédagogique de 2 enfants, ainsi qu'au besoin de coloriages du confinement…
On paie le vrai prix d'une imprimante à l'achat. La vraie différence, c'est le prix de l'encre: un peu moins d'une dizaine d'euro la recharge de 127mL (à multiplier par 4 couleurs) contre les 10€ par couleurs des 5mL des imprimantes à cartouches "intelligentes" qui se déclarent vides au bout de n impressions.
Ma conscience écologique se satisfait aussi du moins de déchets généré par l'absence de cartouches.
Côté support:
- photocopie autonome;
- supportée via Cups sur ma Gentoo pour la partie imprimante en wifi, j'ai jamais réussi pour la partie scanner (généralement, je scanne directement depuis mon ordiphone donc je n'ai pas insisté, je n'ai jamais testé non plus en USB);
- supportée sur les ordiphones Google ou sur ceux de la pomme via une application à installer.
- évidemment, ça marche sous Windows également.
Niveau performance:
- c'est un chameau, j'ai du faire une fois le plein en plus de 5000 pages;
- c'est un peu limite pour la qualité d'impression des photos.
J'en suis plutôt content. L'inconvénient de cette gamme est son prix de départ. En contrepartie, on ne met pas 50% du prix de départ à chaque changement de cartouche.
L'objectif était d'évaluer la distance nécessaire entre des ruchers, sachant que les abeilles volent jusqu'à trois kilomètres.
J'ai remplacé les ruchers par une maison, agrandi le cercle à cent kilomètres et le tour était joué.
Simple curiosité: Tu parles de distance nécessaire entre les ruchers, il y a une raison particulière ?
Je crois qu'il faut un peu démystifié cette image de complexité du Rust.
Il y a un ticket initial de formation et un coût associé de développement un peu plus important lié à une rigueur du langage. Néanmoins, avec un peu d'habitude, tu apprends les bons paradigmes et, par la suite, tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…) ou à tenter de résoudre un obscur problème de concurrence que le caractère nazi t'empêchera de créer.
Je suis persuadé que tu te retrouver dans des situations tout aussi compliquées d'un point de vue dév. avec du C++. Dans le cas de Rust, le compilateur t'oblige à gérer proprement la mémoire et la concurrence. Dans le cas de C++, tu créés un bug mémoire ou de concurrence et tu cherches à le débugger…
Une petite comparaison pour la route:
- des dév. capable d'écrire du Python exécutable, ça se trouve à tous les coins de rue ou presque ;
- des dév. capable de me typer correctement du python, bien architecturé, qui passe les contrôles "qualité" et qui ne me fait pas un usage délibéré du duck-typing à tout va, c'est déjà plus compliqué, ça a un coût (en formation initiale et en dév.)
En tout état de cause, quand tu commences un dév, tu choisis ton langage en prenant en compte les facteurs suivants:
- est-ce que je connais, maîtrise et/ou désire apprendre le langage ;
- quel son les coûts acceptables en dév. / maintenance, etc… ;
- ai-je besoin d'une preuve de concept très rapide (Python?), la performance est-elle importante?
- vais-je mettre le prix pour avoir un truc robuste ou puis-je me contenter d'un script "à l'arrache" sur un coin de table ?
Le cas des extensions python pour un programme écrit dans un autre langage (blender, gimp, …) n'est pas un cas si isolé.
Tu peux avoir une équipe qui s'occupe d'améliorer un programme core où tu veux profiter des avantages du Rust et vouloir exploiter des modules existants ou à développer par des personnes dont la programmation n'est pas le métier (et qui te pondront un Python correcte mais jamais de Rust).
Tu peux aussi avoir une forte dépendance à une librairie exploitable uniquement en Python.
En tout cas, si tu as un soft "avec du vécu", tu ne migres pas en un jour (ni les coders, ni la codebase)
# Pre challenge
Posté par YetiBarBar . En réponse au journal France Cybersecurity Challenge (FCSC) 2024 va commencer. Évalué à 2 (+1/-0).
Un "pre-challenge" est déjà en ligne. Le début de ce prechall consiste à le trouver! Il vous permettra d'arborer une jolie flamme à côté de votre pseudo.
Je l'ai trouvé plutôt sympathique (mais pour être honnête, pas forcément trivial pour un débutant complet).
Je passe mon tour cette année par manque de temps, amusez-vous bien !
[^] # Re: lol ptdr
Posté par YetiBarBar . En réponse au lien L'Armée française publie de mystérieux messages sur X, de quoi s'agit-il ?. Évalué à 1 (+0/-0).
Techniquement, le dernier est mort en 1970 (mais il a été fait maréchal à titre posthume en 1984).
[^] # Re: Clippy est un bon début
Posté par YetiBarBar . En réponse au journal PullRequest d'une application en Rust. Évalué à 1 (+0/-0).
Pour reprendre ce que je disais sur les fonctions en *_or un des exemples que j'avais vu était sur ce type de fonctions:
let file = attributes
.into_iter()
.find(|f| f.name.eq(*filename))
.ok_or(std::io::Error::new(
std::io::ErrorKind::NotFound,
format!("File not found (not in attributs): {}", path.join("/")),
))?;
L'expression passée au ok_or() va être évaluée à chaque fois, y compris quand le résultat était un
Ok. Pour s'en prémunir, il vaut mieux par la versionok_or_elsequi prend un closure dès que le paramètre d'un ok_or (ou d'un unwrap_or) est non trivial.Si tu veux t'en convaincre, voici un exemple spécifiquement forgé:
fn main() {
let mut v = vec![];
Some(1).unwrap_or({
v.push("foo");
1
});
Some(1).unwrap_or_else(|| {
v.push("bar");
1
});
println!("{v:?}");
assert_eq!(v, vec!["foo"])
}
[^] # Re: Clippy est un bon début
Posté par YetiBarBar . En réponse au journal PullRequest d'une application en Rust. Évalué à 3 (+3/-0).
Je plussoie pour clippy.
Pour apprendre le rust, je le lançais en "pedantic", il faudra quand même trier ce qui est important dans la sortie:
cargo clippy --all -- -W clippy::all -W clippy::pedantic.En lecture (très) rapide, je vois un footgun assez réccurent sur l'usage des adaptateurs en
*_or(todo!())(unwrap_or, ok_or, …): il vaut mieux utiliser les adptateurs*_or_else(|| todo!())dès que ce que tu veux mettre dans le todo!() a des effets de bords ou fait des allocations. Plus d'infos ici: https://rust-lang.github.io/rust-clippy/master/index.html#/or_fun_call# Du rust pour ma part
Posté par YetiBarBar . En réponse au message Advent of Code, jour 16. Évalué à 1. Dernière modification le 16 décembre 2023 à 23:00.
Mon code est par ici
Rien de bien inventif et assez brutal: on propage le rayon lumineux comme indiqué dans l'énoncé jusqu'à sa sortie du tableau, en mémorisant les couples (x, y, direction de propagation) pour éviter de tourner en rond. Un algo très ressemblant à un bfs…
Pour la partie 2, du "brute-force" basique en testant toutes les entrées possibles.
Sans multithread, ça tourne en 620ms (parsing, partie 1 et 2) sur un seul core de mon Core i7 de 10 ans d'âge.
[^] # Re: Partie 2
Posté par YetiBarBar . En réponse au journal Advent of Code 2023, day 8. Évalué à 1.
C'est presque vrai…
Dans le cas d'un depart desynchronisé, pour appliquer le crt, il faudrait aussi que les durées des cycles soient premières entre elles…
[^] # Re: customisation
Posté par YetiBarBar . En réponse au journal QRNote pour copier coller du texte de son ordinateur au téléphone. Évalué à 3.
Je n'avais jamais essayé slint… Quelle horreur niveau nombre de dépendances et temps de compilation… mais ça a le mérite de faire des GUI de manière assez simple à ce que j'en vois.
Ton appli gère très mal les erreurs de générations de QrCode et crash si un problème arrive… Ce qui est ballot quand tu as tapé un très long message! Je t'ai fait une PR pour introduire une gestion très basique des erreurs (Affichage d'un message au lieu d'un crash) qui te permet au moins de conserver le texte que tu as tapé.
PS: Normalement, dans le cas d'usage SMS, l'erreur "data too long" ne devrait pas arriver.
PS2: Je ne serai pas utilisateur de ton logiciel mais j'en trouve le concept sympa et ça m'a permis de découvrir l'existence du crate "qrcode" et de découvrir très rapidement slint.
[^] # Re: peut-être une erreur dans le manuel
Posté par YetiBarBar . En réponse au message Un bug dans les shell ?!!!! Mais en fait non (Linux fuck Posix). Évalué à 6.
La page de man à une note:
Le bourne shell, puis ses héritiers dont bash et zsh utilisent tous un builtin. La doc de bash précise
# La syntaxe au sens équivalente n'est pas
Posté par YetiBarBar . En réponse au journal Perles de C. Évalué à 4.
Syntaxiquement, ça compile (peut-être, j'ai pas testé…).
Et comme avec tout langage (du C, du Python, du rust, du français), on peut balancer des mots qui n'ont ni queue ni tête et chercher le sens à tout ça…
Pour moi, un tel code ne mérite pas de vivre car il n'exprime aucun sens (d'autant que j'entrevois quelques bouts de "UB" qui vont être compilo-dépendant).
# Pre-chall
Posté par YetiBarBar . En réponse au journal Concours sur la cyber-sécurité du 21 avril au 30 avril 2023. Évalué à 4.
Un pre-challenge est déjà en ligne, avec à la clef un point bonus (et une magnifique flamme à côté de votre pseudo :-)).
A vous de le trouver (assez facile) et le résoudre (beaucoup moins facile!).
[^] # Re: Binaires statiques et conséquences
Posté par YetiBarBar . En réponse au journal Une CVE dans le compilateur rust. Évalué à 4.
Sur ripgrep, exa, fd, … Pas certain de la nécessité de recompiler:
- ce ne sont pas des programmes privilégiés;
- j'ai du mal à voir où il pourrait faire un remove_dir_all
En revanche, je plussois sur l'inconvénient de la compilation statique… et même pire dans ce cas, le fichier 'Cargo.lock' ne référence pas, si ma mémoire est bonne la version de la librairie standard.
[^] # Re: Autres idées...
Posté par YetiBarBar . En réponse au journal Dual OSchool Free Software Pack. Évalué à 5.
(troll on) Il y a déjà un dual-boot, pas la peine de rajouter un 3e OS! (troll off)
Si vous comptez "enseigner" du python, vu que vous êtes complètement hors-ligne:
* une distribution avec un lot de paquet pour disposer du minimum (on me souffle anaconda mais j'ai jamais testé…)
*
jupyter notebook: pouvoir distribuer des notebooks où tu as un miw "Cours en HTML" avec le code a éxécuter dans ton notebook, pour une matière comme "Introduction au Python", c'est assez confortable!# Faisabilité
Posté par YetiBarBar . En réponse au message Script shell à entrées différentes / interactives ?. Évalué à 1.
Tu peux faire cela à l'aide de read. Ci dessous un court exemple:
read -p "Qualité : " QUALITY
echo $QUALITY
Pour le choix du langage, tout dépend du niveau de contrôle que tu veux y mettre (ça peut vite être galère en Bash si tu veux contrôler que le fichier existe, que tu n'écrases pas un fichier existant dans la sortie, …).
PS: pas d'auto complétion dans l'exemple.
[^] # Re: Pour éviter les comportements non voulus ?
Posté par YetiBarBar . En réponse au message Rust : lapin compris les durées de vie. Évalué à 2.
Je plussoie, c'est clairement au développeur de connaître cette information et de l'indiquer au compilateur.
Si tu appliquais "le pire cas", tu donnerais implicitement du sens à une formulation ambigüe. Si tu es dans un cas où il y aurait seulement une des lifetimes dans la sortie, tu créerai implicitement une contrainte forte sur la durée de vie de tes paramètres --> Des messages d'erreurs cryptiques sur des références qui ne vivent pas assez longtemps seraient remontés par le compilateurs.
Le point problématique est: "sens implicite à une formulation ambigüe".
Pour éviter celà, les règles d'elision interdisent ce que tu décris.
[^] # Re: Chasse commencée
Posté par YetiBarBar . En réponse au journal Chasse aux œufs dlfpienne (édition 2021). Évalué à 1.
Commencée ici aussi.
Trouvé les 11 et 12!
[^] # Re: Pourquoi Rust ?
Posté par YetiBarBar . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 3.
Un "résumé" dans la langue de Shakespeare de "pourquoi pas go" pour moi.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
Dans les grandes lignes, go n'est pas aussi simple qu'il en a l'air, le type safety, ça compte!
Le plus gros point noir reste pour moi les comportements mal définis, votre inconsistants.
[^] # Re: Beaucoup trop vague
Posté par YetiBarBar . En réponse au message "Processus arrêté". Évalué à 1.
Bonjour,
L'erreur "Processus arrêté" est beaucoup trop vague pour qu'on puisse t'aider. Il faudrait un peu plus de matière pour trouver ce qui ne va pas!
Sans plus d'infos sur ce que tu fais, difficile de t'aider pour écarter toutes les pistes qui peuvent "mal se passer".
# Epson Ecotank
Posté par YetiBarBar . En réponse au message Imprimante familiale / support Linux. Évalué à 5. Dernière modification le 19 septembre 2020 à 15:31.
Bonjour,
J'ai acquis un Epson Ecotank ET-2750 il y a 2 ans. C'est un combo imprimante et scanner. Pour le chargeur de documents, il fallait monter un peu en gamme (encore + cher), donc j'ai renoncé.
Elle a survécu à 2 années de Master de Mme et au suivi pédagogique de 2 enfants, ainsi qu'au besoin de coloriages du confinement…
On paie le vrai prix d'une imprimante à l'achat. La vraie différence, c'est le prix de l'encre: un peu moins d'une dizaine d'euro la recharge de 127mL (à multiplier par 4 couleurs) contre les 10€ par couleurs des 5mL des imprimantes à cartouches "intelligentes" qui se déclarent vides au bout de n impressions.
Ma conscience écologique se satisfait aussi du moins de déchets généré par l'absence de cartouches.
Côté support:
- photocopie autonome;
- supportée via Cups sur ma Gentoo pour la partie imprimante en wifi, j'ai jamais réussi pour la partie scanner (généralement, je scanne directement depuis mon ordiphone donc je n'ai pas insisté, je n'ai jamais testé non plus en USB);
- supportée sur les ordiphones Google ou sur ceux de la pomme via une application à installer.
- évidemment, ça marche sous Windows également.
Niveau performance:
- c'est un chameau, j'ai du faire une fois le plein en plus de 5000 pages;
- c'est un peu limite pour la qualité d'impression des photos.
J'en suis plutôt content. L'inconvénient de cette gamme est son prix de départ. En contrepartie, on ne met pas 50% du prix de départ à chaque changement de cartouche.
[^] # Re: Sony's style
Posté par YetiBarBar . En réponse au lien int random() { return 4; /* Good enough. */ }. Évalué à 3.
https://xkcd.com/221/
# HS: Distance entre les ruchers
Posté par YetiBarBar . En réponse au journal Déconfinement - Règle des cent kilomètres. Évalué à 2.
Simple curiosité: Tu parles de distance nécessaire entre les ruchers, il y a une raison particulière ?
[^] # Re: rust
Posté par YetiBarBar . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 1.
Je crois qu'il faut un peu démystifié cette image de complexité du Rust.
Il y a un ticket initial de formation et un coût associé de développement un peu plus important lié à une rigueur du langage. Néanmoins, avec un peu d'habitude, tu apprends les bons paradigmes et, par la suite, tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…) ou à tenter de résoudre un obscur problème de concurrence que le caractère nazi t'empêchera de créer.
Je suis persuadé que tu te retrouver dans des situations tout aussi compliquées d'un point de vue dév. avec du C++. Dans le cas de Rust, le compilateur t'oblige à gérer proprement la mémoire et la concurrence. Dans le cas de C++, tu créés un bug mémoire ou de concurrence et tu cherches à le débugger…
Une petite comparaison pour la route:
- des dév. capable d'écrire du Python exécutable, ça se trouve à tous les coins de rue ou presque ;
- des dév. capable de me typer correctement du python, bien architecturé, qui passe les contrôles "qualité" et qui ne me fait pas un usage délibéré du duck-typing à tout va, c'est déjà plus compliqué, ça a un coût (en formation initiale et en dév.)
En tout état de cause, quand tu commences un dév, tu choisis ton langage en prenant en compte les facteurs suivants:
- est-ce que je connais, maîtrise et/ou désire apprendre le langage ;
- quel son les coûts acceptables en dév. / maintenance, etc… ;
- ai-je besoin d'une preuve de concept très rapide (Python?), la performance est-elle importante?
- vais-je mettre le prix pour avoir un truc robuste ou puis-je me contenter d'un script "à l'arrache" sur un coin de table ?
# Hommage sur arte
Posté par YetiBarBar . En réponse au journal En mai 1981, Kraftwerk sort Computer World. Évalué à 6.
Arte y consacre un hommage.
Diffusion le 29 mai à 22h25 mais également visionnable jusqu'au 8 août ici
[^] # Re: Beurk, écoeurant ....
Posté par YetiBarBar . En réponse au journal Rust et Python associés grâce au C. Évalué à 5.
Le cas des extensions python pour un programme écrit dans un autre langage (blender, gimp, …) n'est pas un cas si isolé.
Tu peux avoir une équipe qui s'occupe d'améliorer un programme core où tu veux profiter des avantages du Rust et vouloir exploiter des modules existants ou à développer par des personnes dont la programmation n'est pas le métier (et qui te pondront un Python correcte mais jamais de Rust).
Tu peux aussi avoir une forte dépendance à une librairie exploitable uniquement en Python.
En tout cas, si tu as un soft "avec du vécu", tu ne migres pas en un jour (ni les coders, ni la codebase)