#0 Re : -1 » /* Topic des codeurs [9] */ » Le 02/10/2018, à 10:10
- grim7reaper
- Réponses : 205
@The Uploader: toujours aussi fan de DOS apparemment 
#1 Re : -1 » /* Topic des codeurs [9] */ » Le 23/12/2019, à 01:11
- grim7reaper
- Réponses : 205
Impressionnant!
Ça me fait un peu penser à tycat de Terminology, le terminal de Enlightenment.
#2 Re : -1 » /* Topic des codeurs [9] */ » Le 26/01/2020, à 01:18
- grim7reaper
- Réponses : 205
ha, de l’activité!!
@Elzen : faut que je prenne le temps de lire ça au calme, mais ça semble très intéressant.
@Dafyd : les FILE* sont clairement pas thread-safe en standard (parce que jusqu’a C11 y’avait même pas la notion de thread en standard). Tu entends quoi par thread-safe d’ailleurs?
De base, même en POSIX il me semble (mais si tu as une source qui dit le contraire je veux bien regarder), si tu as plusieurs thread qui écrivent en même temps en sortie tu va avoir un truc tout mélangé.
#3 Re : -1 » /* Topic des codeurs [9] */ » Le 26/01/2020, à 10:46
- grim7reaper
- Réponses : 205
Ha bah en effet, POSIX garanti que les FILE* soient thread-safe (à un certain degré : ça ne garanti que l’atomicité d’un appel, pas plus), tiens je l’ignorais.
Mais comme tu dis, ça limite la portabilité (le support POSIX de Windows était partiel la dernière fois que j’avais regardé (il y a longtemps), et je ne parle pas de l’embarqué).
Cela dit, si les plateformes que tu vises ont flockfile/funlockfile (peut-être que Windows l’a??) alors tu peux peut-être utilisé ça au lieu des mutex.
#4 Re : -1 » /* Topic des codeurs [9] */ » Le 26/01/2020, à 13:16
- grim7reaper
- Réponses : 205
Et pour Windows : https://docs.microsoft.com/en-us/window … i-lockfile
Le truc de Windows je me demande si c’est pas plutôt un équivalent flock que flockfile, mais j’ai lu en diagonale.
#5 Re : -1 » /* Topic des codeurs [9] */ » Le 26/01/2020, à 16:50
- grim7reaper
- Réponses : 205
@Dafyd : ouais, je ne sais pas ce que tu fais exactement mais j’étais en train de me demander si t’avais vraiment besoin d’I/O en parallèle.
En effet, avoir un thread dédié au I/O et les autres qui poussent leur résultats me semble plus simple/commun.
#6 Re : -1 » /* Topic des codeurs [9] */ » Le 27/01/2020, à 21:27
- grim7reaper
- Réponses : 205
Pour chaque client, le serveur instancie un thread qui ouvre un socket pour garder le lien avec le client.
C’est peut-être un peu lourd ça, un thread par connexion.
Bon certes, tu devrais pas avoir des milliers de connexions, mais en général on préfère quand même les I/O non bloquantes pour ça (avec un thread qui fait du select/kpoll/…)
#7 Re : -1 » /* Topic des codeurs [9] */ » Le 28/01/2020, à 23:36
- grim7reaper
- Réponses : 205
@grim
Je vais me renseigner sur la méthode que tu mentionnes, je ne la connais pas. Est-ce portable ?
Ni plus ni moins que les thread je dirais (encore que, depuis C11 y’a les threads dans la stdlib, mais bon la dernière fois que j’ai regardé Windows ils supportaient pas C99, donc C11…).
poll et select c’est du POSIX 2001 il me semble, mais après chaque OS à son mecanisme plus efficace (mais sur le même principe) : epoll pour Linux, kqueue pour BSD, …
(Et désolé Grim, j'te rajoute encore un pavé de plus à lire :-°)
J’avance, j’avance.
Voilà quelques remarques sur ce que j’ai lu pour l’instant :
J'envisagerais bien d'en ajouter un de plus qui permette d'afficher sur la sortie standard si le nombre de lignes est inférieur à la taille du terminal et de passer sur less dans le cas contraire, mais ça m'embête un peu parce que l'action attendue pour passer d'un fichier à l'autre ne serait du coup pas forcément toujours la même, donc pas glop niveau cohérence…
Comme "less --quit-if-one-screen"?
(Notez que, en vrai, vous pouvez mettre autant de - que vous voulez, zéro compris, pour les options, mon parseur commence par les virer).
Tu veux dire que je peux écrire "midote single"? Comment il sait que "single" c’est une option et non pas un nom de fichier à ajouter à la playlist?
Le daemon a besoin de python3-psutil pour lire les arguments des autres commandes (requis).
Si tu as seulement besoin de ça, il suffit pas de lire "/proc/PID/cmdline"?
Ça éviterai une dépendance pour si peu.
#8 Re : -1 » /* Topic des codeurs [9] */ » Le 29/01/2020, à 13:15
- grim7reaper
- Réponses : 205
C'est en partie pour ça que j'ai mis une option « then=FILE », qui permet d'échapper un nom de fichier qui aurait sinon été reconnu comme une option.
Ha, oui le --then sert à ça, bien vu.
Tiens d’ailleurs vu la description que tu en fais, j’ai l’impression que tu as fait un parser maison.
argparse te convenait pas?
Ah beh oui, ça a l'air tout à fait faisable, il faut juste que je trouve le caractère séparateur pour parser ça comme il faut.
un NUL ASCII, \0
/proc/[pid]/cmdline
This read-only file holds the complete command line for the process, unless the process is a zombie. In the latter case, there is nothing in this file: that is, a read on this file will return 0 characters. The command-line arguments appear in this file as a set of strings separated by null bytes ('\0'), with a further null byte after the last string.
D'un autre côté, /proc est spécifique au noyau Linux, non ?
Oui et non, y’a énormément de trucs dans /proc sous Linux et y’a pas tout sur BSD, mais y’a quand même un minimum de compat’ il me semble (je viens de tester rapidos sur un FreeBSD et un DragonFly BSD là et j’ai bien cmdline)
Donc tant que les besoins reste basique comme ça, ça devrait aller.
#9 Re : -1 » /* Topic des codeurs [9] */ » Le 31/01/2020, à 22:04
- grim7reaper
- Réponses : 205
Bon j’ai fini de tout lire \o/
Sacré boulot, ça semble bien complet (et complexe par endroits ^^")
En même temps, c'est le seul bout de doc digne de ce nom existant sur ce que je fais actuellement, donc ce n'est carrément pas assez, mais bon.
Ça mériterait même de devenir une vraie doc, dans le repo Git et/ou dans la section Touhy de ton site
À vue de nez, j'ai une source de segfault dans le module image (ça n'a pas l'air systématique, mais comme sencol fait pas mal de traitement d'image (pour les icônes liées au presse-papier ou aux capteurs de température, par exemple), le plantage finit par être quasi-systématique), et je n'arrive pas encore à identifier où précisément pour l'instant. Si quelqu'un veut aider à ça, n'hésitez surtout pas…
Bah si t’a une image/script avec lequel t’arrives à reproduire fréquemment, je veux bien jeter un œil
Pour les submodules Git en effet, ça répond pas à ton besoin (vu que tu veux prendre des bouts de repo), pour ça faudrait que tu découpes le repo communs en repo plus petits.
Pour les venv Python, en effet ça ne gère que les deps Python. Ça peut éventuellement compiler des bouts de C mais ce n’est pas un package manager système (et ce n’est pas son but).
Le gros avantage c’est que ça permet d’avoir plusieurs versions d’une même bibliothèque Python en parallèle.
Typiquement, je crois que tu développes sur Debian, donc tes versions packagées sont «vieilles» et si j’installe les paquets équivalent sur mon Archlinux y’a une chance non-nulle que ça ne fonctionne pas avec ton code 
La solution c’est que je sache quelle version tu utilises, et que je l’installe dans un venv (comme ça, ça ne conflicte pas avec la version packagée par ma distrib’).
Du coup, un requirements.txt ça te serais pas forcément utile (vu que tu développes contre ce qui est packagé chez toi), mais ça peut aider les autres à savoir quoi installer (au lieu de deviner ta version Debian, chercher quelle version est packagée chez toi, …) rapidement
En fait, si tu n'as pas de boucle principale GTK démarrée, mon truc avait l'air de marcher nickel, d'où la difficulté à trouver l'origine précise du souci dans mes tests… par contre, si la boucle principale GTK tourne dans un thread et que j'appelle certaines fonctions de traitement d'images (je n'ai pas poussé jusqu'à identifier lesquelles précisément) depuis un autre, segfault immédiate sur mon jeu de test.
Ha, plus besoin d’aide donc.
Ouais, en général les bibliothèques graphiques aiment bien que leur tambouille restent dans leur thread principal.
Tiens, d'ailleurs, l'un des inconvénient de la dernière version de ma bibliothèque qui utilise des socket dans tous les sens pour faire communiquer les applis entre elles, c'est que j'ouvre des tas de threads, maintenant… Et que je ne les referme pas toujours, d'ailleurs : si par exemple j'ai ouvert une socket DGRAM et que j'ai un thread qui attend des messages dessus, puis que pour une raison ou pour une autre, il m'arrive de devoir effacer le fichier, le thread reste en attente d'un message qui du coup n'arrivera plus jamais…
Toute suggestion pour améliorer ça sera la bienvenue.
Bah le souci c’est que tu fermes pas la socket non?
IIRC, si tu as un processus bloqué en lecture sur une socket et que l’autre bout (qui écrit) appel close, bah celui qui attends des données va être notifié.
Ça marche comme ça en C il me semble (pas de raison que ça diffère en Python) :
RETURN VALUE
Upon successful completion, recv() shall return the length of the message in bytes. If no messages are available to be received and the peer has performed an orderly shutdown, recv() shall return 0. Otherwise, −1 shall be returned and errno set to indicate the error.
Sauf que, comme souvent avec la XLib, ça a l'air compliqué, et je peine à trouver de la doc' compréhensible (voire de la doc' tout court). Donc, si quelqu'un a des pistes, je prends smile
Le gros de la doc’ ce sont les pages de man, sinon y’a des vieux bouquins sur la Xlib (je dois avoir quelques un en PDF qui traîne sur mon disque).
Y’a ce site aussi (je me souviens l’avoir utilisé pendant mes TP de Xlib ^^).
c'est typiquement un cas où refaire un parseur était aussi, voire plus simple que d'en utiliser un existant :-°
Je peux comprendre si le truc supporte pas ce que tu veux faire.
Mais sinon c’est plus pratique d’utiliser un truc standard (surtout si tu veux des regards/contributions externes, ça diminue le coût d’entrée).
(je te laisse me confirmer la compatibilité si tu as du *BSD sous la main, ce qui n'est présentement pas mon cas)
Nope, y’a pas ça sous BSD.
FreeBSD :
% ls /proc/curproc/
cmdline ctl dbregs etype file fpregs map mem note notepg osrel regs rlimit statusDragonFly BSD :
% ls /proc/curproc/
cmdline ctl dbregs etype file fpregs map mem note notepg regs rlimit status#10 Re : -1 » /* Topic des codeurs [9] */ » Le 02/02/2020, à 21:23
- grim7reaper
- Réponses : 205
Par contre, si tu veux m'aider à trouver l'origine d'erreurs cryptiques, il y a le souci de midote sus-mentionné. Mais je n'ai pas encore identifié de moyen de le déclencher à coup sûr, donc bon.
Ouais, ce genre d’erreur est très chiant à comprendre, surtout si t’arrives pas à le reproduire 
Et puis, a priori, les trucs que j'utilise sont plutôt stables… en tout cas, je ne me souviens pas de masse de trucs qui ont changé de fonctionnement depuis que je taffe là-dessus. Mais si tu repères des incompatibilités, signale-les moi, je tâcherai de commencer à tenir une liste à jour
Ok, je te dirais si j’ai des soucis en testant.
En revanche, pour les SOCK_DGRAM pour lesquels il n'y a pas de client à l'autre bout (il n'y a que le prog qui ouvre la socket qui attend des messages), et pour le thread qui attend la connexion de clients sur une SOCK_STREAM, soit il n'y a rien, soit je ne sais pas comment on vérifie ça.
Ha oui sur de l’UDP c’est peut-être chiant.
Tu peux pas utiliser du TCP à la place?
Au pire, si tu es coincé avec l’UDP on pourrait imaginer que t’envoie un dernier message "goodbye" quand le thread émetteur se termine.
Arf… pour l'environnement, je m'en fiche un peu, je ne m'en sers pas pour l'instant. Par contre, pour le cwd, tu sais s'il y a un autre moyen de le récupérer ?
J’ai regardé vite fait et soit tu lances une commande via subprocess et tu parses la sortie…, soit c‘est relou (faut taper sur une fonction C depuis Python).
Vaut peut-être mieux rester avec psutils du coup…
#11 Re : -1 » /* Topic des codeurs [9] */ » Le 04/02/2020, à 10:47
- grim7reaper
- Réponses : 205
– quand je laisse tourner sencol longtemps (avec tous les capteurs actuels actifs, je n'ai pas encore cherché lequel en particulier causait ça), ça finit au bout d'un temps aléatoire par me faire une stack overflow irrécupérable au chargement d'une image,
Y’a des stack overfow en Python oO?
– des trucs dans gemetic semblent parfois avoir quelques petits soucis de mise à jour (par exemple, j'affiche une horloge dans un coin, il arrive qu'elle reste coincée sur une heure donnée alors que le reste continue de marcher correctement, de manière aléatoire),
– parfois, sans que je sache si c'est le même souci plus généralisé ou pas, gemetic s'arrête complètement de fonctionner, plus rien ne se met à jour graphiquement et les clics n'ont plus aucun effet.
Ça ressemble à un thread qui se bloque ça, nan?
Ouaip, mais d'un autre côté, je n'veux pas que n'importe quelle appli extérieure puisse arrêter le thread non plus
Bah TCP ou UDP, c’est possible hein.
Sauf à faire communiquer tes process avec un protocole authentifié et chiffré, ça me semble définir à empêcher.
Après, je pense que c’est un faux problème, y’a pas de risque que ça arrive par erreur (et si c’est voulu, y’a d’autre moyen de tuer le thread/process de toutes façon )
D'ailleurs, à ce sujet, je viens d'ajouter le dépôt pour Catapult (c'est un chouette nom de lanceur, non ?
Ouais, d’ailleur KDE3 avait Katapult
(c'est possible, non, avec inotify, de repérer les tentatives d'accès à un fichier ?)
T’entends quoi par là?
Je pense pas que tu puisses être notifier sur un accès de fichier qui n’existe pas (si c’est ça la question).
#12 Re : -1 » /* Topic des codeurs [9] */ » Le 04/02/2020, à 21:26
- grim7reaper
- Réponses : 205
Beh on dirait. D'un autre côté, il y a des langages où ce n'est pas possible ? Il y a des langages spécialisés pour la récursivité, mais il y a toujours une limite de taille de pile, non ?
Alors oui dans l’absolu c’est possible partout.
Après en Python je ne pense pas (sauf bug de l’interpréteur), car il fait beaucoup de chose sur le tas.
un StackOverflow c’est un crash violent comme une segfault quoi.
Autant j’ai déjà vu des MemoryError ou des RecursionError en Python (voire des segfault quand j’appelle du C depuis Python), autant une stack overflow pas encore (d’où ma surprise).
D'un autre côté, cette doc a l'air de dire que c'est mieux de laisser un thread attendre un message qui n'arrivera jamais plutôt que de chercher à interrompre ça, non ?
Il y a une différence entre interrompre un thread (ce qui me fait penser au "cancel", qui lui est souvent problématique) de l'extérieur et "le thread s'arrête de son plein grè car il a reçu un message 'salut'".
Après effectivement, si y'a des chances que tu reçoivent des données plus tard sur cette socket ça fait sens de le laisser poireauter.
Là je pensais qu’on était dans un cas où on nous parlera plus jamais.
Arf, mince. Je vais devoir renommer ça « trebuchet » pour désambiguer ?
Ça serait pas déconnant
J’ai découvert qu’il y avait une espèce de guerre trébuchet vs catapulte similaire à tab vs space ou Vim vs Emacs
Genre ici ^^
#13 Re : -1 » /* Topic des codeurs [9] */ » Le 06/02/2020, à 08:16
- grim7reaper
- Réponses : 205
Edit : ah, bah, j'ai fini par l'avoir ^^
Ho, en effet!
C’est bien la première fois que je vois ça ^^
Je pensais que t’aurais toujours une RecursionError propre avant ça.
Mais gars disait
The recursion limit is just a guard to limit the likelihood of a stack overflow, but if you allocate large objects on every stack frame, you can still overflow.
C’est peut-être ton cas ici.
Où alors c’est le code C de GTK qui crash et ça remonte jusqu’a Python (plus probable).
(En parlant de crash violents : d'après le collègue spécialiste dudit langage avec qui j'ai donné quelques cours au semestre dernier, en C#, il ne serait pas possible de récupérer d'une division par zéro ?
)
Bah en C c’est impossible aussi (sur des entiers du moins, encore qu’en POSIX y’a moyen de moyenner mais c’est un terrain miné).
Par contre je ne connais pas du tout C# mais ça semble possible.
c'est tout à fait possible de connecter la socket d'abord, puis de supprimer le fichier, puis de continuer à envoyer des choses qui sont bien reçues).
Je pense que c’est comme les fichiers, tant qu’il est ouvert il est pas réellement supprimé (même si tu rm, il existe toujours dans le kernel/sur le disque, juste tu ne le vois plus).
Ça peut-être utile des fois (annuler un rm mal placé) et des fois c’est chiant.
Sinon, on vient de me suggérer de partir plutôt sur les lanceurs de fusée. En anglais, ça s'appelle « Launch Vehicle » (pas forcément très cool à utiliser), mais aussi « Carrier Rocket ». Du coup, je me dit que « crocket » pourrait être un nom sympa, qu'en dites-vous ? ^^
Ouais , «crocket» c’est pas mal (même si je pense pas que beaucoup de gens feront le rapprochement ^^).
#14 Re : -1 » /* Topic des codeurs [9] */ » Le 04/03/2020, à 12:36
- grim7reaper
- Réponses : 205
Edit : commité entre temps, par contre j'ai quand même eu une belle stack overflow quand même hier soir, donc ç't'assez déprimant
Ha, chiant.
Mais si c’est plus rare c’est déjà ça de pris.
Oui, mais, C n'a pas de mécanisme natif de try/catch, à ma connaissance⁽¹⁾.
Autant, une stack overflow, je peux comprendre, mais qu'une division par zéro ne puisse pas être interceptée de cette façon-là, ça me semble étrange. Mais bon
Doit y avoir moyen de faire des trucs avec SIGFPE et/ou longjmp, mais je pense que c’est pas fiable du tout.
Mais bon, comme je donnais dans mon lien ça semble gérable en C# en tout cas (le contraire serait surprenant en effet).
Comment on s'y prend, pour l'annulage de rm, tiens ? Ça pourrait m'être utile de temps en temps :-°
Annuler est peut-être pas le bon mot, mais si le fichier est encore ouvert par un programme, tu vas trouver le fd dans /proc/<PID>/fd/<FD> et tu peux le cat/cp pour récupérer son contenu.
(j'envoie un caractère \5 pour dire au programme de vérifier si son fichier est toujours là ou pas, dites si vous voyez plus approprié comme message).
EOT: \4
mais le thread qui attend les connexions, pour sa part, reste vraisemblablement à attendre éternellement (ce n'est pas un recv() mais un listen(), mais je n'sais pas interrompre ça non plus).
C’est bloquant le listen? Me semblait que c’est le accept qui l'était.
shutdown devrait faire le taf pourtant.
Il y a quand même « Carrier Rocket » écrit en toutes lettres comme titre de la fenêtre, donc c'est possiblement affiché par le gestionnaire de fenêtres
Ouais donc ça aide à la compréhension, en effet ^^
Quelqu'un aurait des infos là-dessus ou sur une bibli à utiliser à la place ?
Je ne connais pas d’alternative, et une rapide recherche n’a rien donné.
Tu l’utilisais pour faire quoi?
Edit : question subsidiaire, vu que grim a du *BSD sous la main
/dev/sd* pour les disques durs (c'était /dev/hd*, avant, non ? Pourquoi ça a changé ?),
/dev/mmcblk* pour les cartes SD,
/dev/sr* pour les CD/DVD,
/dev/fd* pour les disquettes (enfin, si ça existe encore, ces machins
/dev/loop* utilisé pour le montage des images disques (il me semble).
Par contre, il me semble (vagues souvenirs de Debian GNU/kFreeBSD ^^) que ça varie selon les noyaux, donc vous sauriez où on peut trouver une liste, ou si non, me dire ce que ça donne chez vous comme noms ?
Pour le sd vs hd c’est la différence entre SCSI (sd) et IDE (hd) (cf. ici)
Les loop device c’est utilisé pour le montage de disque en effet, mais pas uniquement.
Les *BSD que j’ai sous la main ce sont des serveurs remote donc jpeux pas vraiment vérifier pour lecteur CD ou disquette mais en gros j’ai vu du da* et du ada*.
Ça semble correspondre à ce que je vois là.
(1) Ce qui me fait penser que j'avais à une époque un T-shirt (malheureusement plus utilisable) avec la mention :
while(!succeed=try());Il y a d'autres langages que le C où ça marche, vu que try est un mot-clef réservé à peu près partout ailleurs ?
Ruby et Perl je pense (pour rester dans de la syntaxe C-like).
#15 Re : -1 » /* Topic des codeurs [9] */ » Le 14/09/2020, à 14:52
- grim7reaper
- Réponses : 205
Salut Laërte,
Est-ce que tu aurais un exemple minimal & compilable qui reproduit le problème (genre un programme qui lit un fichier, le compresse et qui à le bug que tu rencontres)?
Sinon, quand il y’a des variables qui changent de valeurs magiquement comme ça, c’est souvent signe de corruption mémoire (buffer overflow, …).
Tu as essayé de lancer Valgrind sur ton programme?
#16 Re : -1 » /* Topic des codeurs [9] */ » Le 14/09/2020, à 23:24
- grim7reaper
- Réponses : 205
Alors Valgrind c’est un outil très pratique pour déboguer des erreurs assez difficile à comprendre.
C’est un logiciel qui peut faire pas mal de truc, mais sa fonctionnalité la plus connue c’est de vérifier l’utilisation de la mémoire.
En gros, il surveille toutes les allocations/déallocation de mémoire, et aussi tout les accès mémoire (lecture et écriture).
Grâce à ça, il peut détecter tout un tas d’erreurs, du genre utilisation de mémoire déjà libérée ou lecture en dehors d’une zone allouée, qui sont difficile à étudier car une petite erreur peut changer le comportement du programme 1000 lignes plus loin, et pas de façon systématique ^^"
Ça s’utilise aussi simplement que :
valgrind ./mon_binaireDu fait de son fonctionnement interne, ça ralenti de beaucoup la vitesse d’exécution (mais c’est rarement un souci sur de petits programmes).
De nos jours, il a des mécanismes dans clang et gcc quifont peu ou prou la même chose : il faut les activer à la compilation, et ils ont un impact moindre sur les performances.
Si tu veux plus de détails sur comment ça fonctionne sous le capot, j’avais écris un article sur le sujet (autopromo )
#17 Re : -1 » /* Topic des codeurs [9] */ » Le 20/09/2020, à 00:52
- grim7reaper
- Réponses : 205
si je fais un free(fprop), est-ce que ses attributs dirname et fname sont aussi libérés, j’en doute, bref, c’est pas top.
Comme tu t’en doutais, la mémoire des attributs ne sera pas libéré.
En générale, quand on a des structures de ce genre il est pratique de faire deux fonctions : une qui alloue les ressources pour la structure (create_bzfile, alloc_bzfile, …) et une qui fait la libération (free_bzfile, destroy_bzfile, …)
Sinon, strcpy est une fonction assez dangereuse.
Comme tu connais la taille de la string dans le cas présent, tu pourrais utiliser memcpy.
Ou sinon, si tu code en POSIX, tu peux utiliser strdup.
qu’est-ce que vous me conseilleriez comme structure de données pour ce genre de problème?
Une liste chaînée éviterai les realloc à répétition, mais bon y’a pas de solutions miracle : en C tu finis souvent par te recoder ton type string, ton type array, … (où tu utilises une bibliothèque qui le fait pour toi).
#18 Re : -1 » /* Topic des codeurs [9] */ » Le 09/01/2022, à 21:27
- grim7reaper
- Réponses : 205
Up.
Oui c’est nul, mais ça m’amuse.
Tiens un revenant!
Tu t’es mis au Python? 
#19 Re : -1 » /* Topic des codeurs [9] */ » Le 05/02/2022, à 14:06
- grim7reaper
- Réponses : 205
Ha ça, y’a plus l’intensité des débuts ^^"
Mais oui, il vit encore xD
Moi je suis plutôt à fond sur le Rust en ce moment.
#20 Re : -1 » /* Topic des codeurs [9] */ » Le 12/08/2023, à 10:15
- grim7reaper
- Réponses : 205
Tiens, jcrois pas que j'en avais parlé ici mais j'ai enfin fait mon premier vrai projet Open-Source: une réimplémentation de H3 (le système de grille globale discrète inventé à Uber à la base) en Rust.
Et avec de bien meilleures performances en plus
J'ai aussi fait un algo de compression maison.
Le Rust c'est bon, mangez en!
#21 Re : -1 » /* Topic des codeurs [9] */ » Le 16/09/2023, à 21:30
- grim7reaper
- Réponses : 205
On dirait vaguement du C++, mais en bien fait.
Y'a un peu de ça ouais.
Perso j'y retrouvais les bon côtés du C et du Haskell mais sans les mauvais (bon le langage a aussi ses défauts on va pas se mentir)
En tous cas, ça a tout pour devenir un langage de référence pour les décénies à venir.
C'est pas trop mal parti, pas mal de gros acteurs sont en train de s'y mettre à divers degré donc c'est bon signe pour la pérennité.
#22 Re : -1 » Lecture fichier Csv » Le 21/11/2018, à 07:37
- grim7reaper
- Réponses : 63
Salut sylpard,
Je pense que pour aider les gens qui souhaitent t’aider ça serait pas mal de faire un message qui résume ton besoin, parce que là c’est fourni au compte-gouttes à travers plusieurs messages et c’est difficile à suivre (personnellement j’aimerai bien essayer de t’aider, mais je n’arrive pas à comprendre le comportement voulu).
Un bon début serait de fournir:
- un exemple de fichier d’entrée (avec des fausses données si besoin)
- un exemple de fichier de sortie voulu, correspondant au fichier d’entrée
- les paramètres que prends ton programmes (ce qui n’est pas codé en dur donc)
- une liste des contraintes supplémentaires (commencer la lecture à la 2e lignes, etc.)
Si tu pouvais fournir ça, je pense que ça aiderait beaucoup les participants de la discussion 
#23 Re : -1 » [résolu] récupérer l'heure UTC en Python3 » Le 15/11/2018, à 20:50
- grim7reaper
- Réponses : 8
Salut Petit Lynx,
Ça peut se faire très facilement avec le module datetime de Python.
>>> from datetime import datetime
>>> dt = datetime.utcnow()
>>> dt
datetime.datetime(2018, 11, 15, 18, 49, 24, 762305)
>>> dt.year
2018
>>> dt.month
11
>>> dt.day
15
>>> dt.hour
18
>>> dt.minute
49
>>> dt.second
24
>>> dt.microsecond
762305#24 Re : -1 » Linus Torvalds a besoin de repos ? » Le 28/09/2018, à 11:46
- grim7reaper
- Réponses : 11
Pour rebondir sur le sujet, Linus à envoyé un email aux journalistes de la BBC, l’article est ici (en anglais).
En gros il dit qu’il a toujours préféré se concentrer sur l’aspect technique parce que c’est ce qui l’intéresse (alors que l’aspect humain, moins).
Et c’est pas seulement une question d’intérêt, mais aussi à cause des discussions autour de ces sujets:
- au niveau technique c’est facile d’avoir des critères objectifs (Le code est plus rapide? Gère plus de cas? …) du coup ça dérive moins souvent en discussions sans interminable.
- au niveau humain, bah ça finit souvent avec deux camps qui se gueulent dessus et s’invectivent sans fin, sans s’écouter (donc même pas une discussion au final…)
C’est pour ça qu’il est resté en dehors des discussions sur le code de conduite (ça dérive facilement et deviens rapidement une perte de temps (pas productif)).
Ce qui l’a fait changer d’avis récemment, c’est qu’il a remarqué que son approche du « Au diable le politiquement correct/langue de bois» était aussi beaucoup utilisé par des groupes homophobe, transphobe, mysogyne, nazi, … et qu’il ne veut pas se retrouver associer à eux à cause de ça.
Donc en gros il va essayer d’être plus poli (via un filtre sur ses emails apparemment ) mais il ne va pas se mettre à accepter du code pourri juste pour que l’auteur se sente bien (ni s'excuser du fait d'être un homme blanc hétéro).