Julien Jorge a écrit 639 commentaires

Je reproduis avec ton bout de code (X=100000000) :

/usr/bin/time --format '%M KB %U s.\n' python2 test.py
3186468 KB 102.19 s.

/usr/bin/time --format '%M KB %U s.\n' python3 test.py
6532 KB 106.72 s.

et si je remplace le os.close(fd) par pass c'est pareil :

/usr/bin/time --format '%M KB %U s.\n' python2 test.py
3186468 KB 4.95 s.

/usr/bin/time --format '%M KB %U s.\n' python3 test.py
6532 KB 4.03 s.

Par contre si je remplace le range() par une boucle while fd != 100000000, ça va mieux :

/usr/bin/time --format '%M KB %U s.\n' python2 test.py
4536 KB 6.26 s.

/usr/bin/time --format '%M KB %U s.\n' python3 test.py
6536 KB 8.55 s.

mais ce n'est pas très pythonic :)

Quand tu dis que tu l'utilises, on parle d'une installation native sur ton ordi principal ? D'une installation dans une VM qui tourne sous un autre OS ?

Perso j'aime beaucoup ce projet et ce qu'il dégage. Ça me rappelle une époque d'informatique simple dans laquelle tout semble facilement appréhendable. Quelque part je me dis que c'est bien qu'il reste de niche, comme ça il reste simple.

P'têt bien qu'une ré-écriture de LinuxFr.org en Python est en cours ?

+1 pour Jean-Doux et le mystère de la disquette molle. Il y a un style assez singulier dans l'humour de ce bouquin, j'ai beaucoup aimé. C'est l'auteur qui avait réalisé Georges Clooney, une histoire vrai.

J'avais travaillé sur un algo de colonies de fourmis sur le problème de set packing, qui, si je me souviens bien, est un cas particulier du sac a dos multidimensionnel où les poids, les coûts, et les capacités sont tous à 1. C'était utilisé il me semble dans une application de planning de transport ferroviaire.

Ça reste une métaheuristique qui ne converge même pas vers un optimum global, donc on se demande toujours si on n'aurait pas eu mieux en cherchant plus. Alors qu'un recuit simulé sur un temps infini ça converge au moins vers un optimum global !

Merci pour cet excellent journal :)

Utilisateur de GNOME depuis une bonne vingtaine d'années j'ai un peu l'impression que l'expérience se dégrade petit à petit au fur et à mesure des refontes et réécritures. En vrac des problèmes rencontrés ces dernières années :

• le sélecteur d'arrière-plan de bureau qui prend toute la RAM tranquillement, jusqu'au gel de la machine. Il semblerait qu'il ouvre toutes les images en résolution originale pour afficher les aperçus.
• la réécriture du visualiseur d'images qui maintenant échoue à charger certains JPEGs. Je ne comprends pas l'intérêt de la réécriture puisque Eye of GNOME fait très bien son job.
• l'obstination de pousser à redémarrer pour les mises à jour quand on veut éteindre. Bien pénible quand le disque est chiffré puisque ça oblige a rester devant l'ordi, alors qu'on voulait justement en finir.
• la fenêtre du terminal qui réduit quand on switche vers le plein écran et en fenêtré.

Je n'aurai pas le courage de patcher tout ça ! Et puis ça va être ingérable sur la durée. J'ai tenté un retour à KDE sans succès, je préfère de loin l'ergonomie de GNOME. Il ne reste plus qu'à être patient :)

Mais je sens bien que je vieillis aussi puisque Debian m'attire de plus en plus :D Surtout dans l'idée d'une Ubuntu sans snap.

J'étais passé à côté de ce commentaire, merci :) Effectivement le travail d'Aryeom est impressionnant.

C'est normal de se faire déconnecter ? Cela vient de chez nous ou du serveur ?

La principale cause de déconnexion est le développeur, qui a tendance à laisser passer des petites erreurs dans le code… Heureusement qu'il les corrige petit à petit. Avec la version 9 fraîchement sortie un joueur sera déconnecté s'il est trop en retard par rapport au serveur. Ça arrive typiquement quand on joue avec quelqu'un à l'autre bout du monde. Les messages du joueurs tardent à arriver au serveur et du coup il prend du retard.

Il y a sûrement d'autres facteurs, par exemple la charge du réseau du joueur, et comme je n'ai pas eu le temps de faire des benchmarks il n'est pas impossible que j'ai aussi du lag dans le jeu, ou d'autres problèmes. Mais la raison principale sera donc le retard :)

Pour ceux qui moinssent, pouvez-vous m'expliquer pourquoi ?

Bien sûr ! Je te refais la découverte de ce journal pour moi.

le résumé ci-dessous à été généré par IA (je ne suis pas très doué pour ce genre d'exercice)

Ouch, je ne le sens pas. Je survole le journal, c'est vraiment mal mis en forme. Bof, mon ressenti en première approche est que c'est bâclé et que l'auteur n'a pas envie de communiquer. Ai-je envie de lire ce que cet auteur n'a pas voulu écrire ? Non.

Oui, j'ai vu depuis que tu as expliqué pourquoi c'était mal mis en forme.

D'une manière générale, l'argument « je ne suis pas très doué » ne me convainc pas. Perso j'en ai vraiment rien à faire de ce qu'une IA peut résumer d'un projet. Tous les articles et commentaires que je vois ces derniers temps qui commencent par un truc du genre « [nom de l'IA] dit : » sont vraiment le zéro de la contribution, quand bien même elles sont exemptes d'erreurs, ce sont pour moi les propositions les plus bénignes et insipides que l'on peut faire. Aucune valeur ajoutée, aucun intérêt, du temps de perdu pour tout le monde.

Moi je viens là pour les gens. Je préfère de loin, de très très loin, lire un journal mal fichu que l'auteur a écrit lui-même, et qui nous parle donc indirectement de l'auteur lui-même, que de lire un texte régurgité par une IA. Si vraiment c'est l'enfer pour toi d'écrire un truc complet et structuré (moi ça me prend des jours d'écrire mes journaux), il y a une meilleure manière d'utiliser une IA en écrivant un brouillon et en lui demandant de le retravailler, petit à petit, en relisant et corrigeant ce qu'elle sort à chaque fois. Comme avec un assistant en fait.

Ça c'est pour extraire l'archive complète. Ce que monsieur Renard souhaite faire c'est extraire un sous ensemble des fichiers de l'archive.

Je suis quasi sûr que ça a fonctionné jusqu'à il y a quelques années, mais plus moyen :(

Je pense que c'est plutôt un langage « homme préhistorique » pour jouer l'idiot face aux gros cerveaux qui ajoutent des tonnes de complexité. J'ai aussi eu bien du mal à lire.

Dans mes premières années j'utilisais le débogueur, puis en TP un encadrant nous a sorti un truc du genre « quand vous êtes dans le débogueur vous ne réfléchissez plus au comportement du programme ». Mince, ça s'est vu.

Bon en fait ne sachant si cela se vérifiait j'ai tenté de moins l'utiliser, et en effet j'ai passé plus de temps à lire le code et à mettre des printf pour voir ce qu'il se passait, et beaucoup moins de temps à me demander pourquoi ça va lire 0xc36eff3b alors que x est localisé en 0xff99ea00 et vaut 0xffffffff.

Maintenant j'utilise le débogueur surtout pour localiser les crashs, mais quand il s'agit de cerner un comportement inattendu c'est du printf. Ce qui est super avec ce dernier c'est que ça se déploie facilement, on peut l'utiliser en remote sans rien ajouter à la machine :D

C'est marrant cette tendance à jeter radicalement le besoin pour une app de placer ses fenêtres. Il existe des apps multi-fenêtres. C'est ainsi, elles existent. Elles font leur job depuis des années, et si elles ne peuvent plus indiquer ou au moins suggérer un positionnement, par exemple pour présenter convenablement au premier lancement, ou bien pour restaurer la disposition choisie par l'utilisateur au lancement suivant, ou bien pour proposer à l'utilisateur de switcher entre plusieurs positions, et bien elles deviennent soudainement pénibles à utiliser.

L'argument de Dave n'en est pas un, c'est juste une affirmation infondée, un dogme qui n'engage que lui. Et David, tu nous parles d'un truc complètement hypothétique, qu'« on peut imaginer », à opposer à la réalité concrète d'applications belles et bien existantes.

Si une app veut faire n'importe quoi avec ses fenêtres, c'est surtout son problème. Et si ce n'importe quoi convient à l'utilisateur, grand bien lui fasse. Je ne vois pas en quoi le gestionnaire de fenêtres devrait se sentir concerné plus que ça, surtout s'il a la possibilité d'ignorer la demande de l'app ou d'y appliquer plus de contraintes.

Vous pensez que vous allez utiliser ça ?

Ça fait des années que j'essaye de l'utiliser en C++ et le résultat est toujours le même, une condition inutilement compliquée qui amène surtout beaucoup de questions. Juste pour réduire la portée d'une variable on se retrouve à se demander pourquoi tout le code est dans le if et quelle est la condition testée au final. Et puis je n'aime pas trop voir des affectations dans les conditions, on se demande toujours si c'est normal, du coup ça gêne le flot de lecture.

S'il faut vraiment limiter la portée d'une variable, ce qui arrive quasiment jamais, je préfère ajouter des accolades :

void foo()
{
  // …
  {
    int num_fired = fire_off(argc);

    if (num_fired != 0)
      // …
  }
}

Le descriptif d'Aim Labs est passionnant. Je n'ai pas tout compris, notamment pourquoi ils devaient faire des substitutions (appending random characters, s->5, a->@), ni pourquoi Copilot s'amuse à interpréter le corps d'un e-mail comme un prompt. Je pensais que le principe était plutôt de lire les e-mails pour faire un corpus.

Voici le nombre de recherches d'adversaire par heure (heure française) :

Rendez-vous à 20 h donc !

Très bonne lecture ! Ça aurait fait un bon journal ;)

L'article est très bien, avec une argumentation solide, mais à mon avis trop orienté perfs. Cette tendance à associer le « vrai » programmeur, qui fait les choses bien avec attention et talent, avec le fait de ce soucier des perfs, de s'inquiéter des accès mémoire, du cache L1, du layout des structures de données, c'est néfaste. C'est tout à fait OK pour des devs de ne pas passer des nuits à optimiser chaque cycle et chaque accès mémoire. C'est même très bien. Ça ne fais pas d'eux des gros fainéants qui livrent des bouses sans s'inquiéter. D'ailleurs je pense que ça lui a été remonté puisqu'il semble avoir ajouté un paragraphe plus modéré par la suite :

Maybe you’ll never write the code that keeps a plane in the sky. Maybe you’ll never push bits that hold a human life in the balance. Fine. Most don’t. But even if you're just slapping together another CRUD app for some bloated enterprise, you still owe your users respect. You owe them dignity.

Si on enlève ce discours il reste l'essentiel que je résumerais au fait qu'on n'arrivera à rien de positif en codant sans comprendre ni même essayer de comprendre.

À mon avis cette promesse d'augmenter la productivité en livrant vite et mal ne sert qu'aux vendeurs d'IA. Pour les clients, les boîtes qui achètent ça, ça se paiera sur la durée, quand il faudra déboguer, corriger, ou optimiser ce code que personne n'a écrit ni même analysé. Mais bon, peut-être que d'ici là la boîte aura été revendue et ça ne sera plus leur problème.

Mouais, je suis un peu dans la même situation que David. Ça fait 20 ans que j'essaye régulièrement de composer sous Linux et c'est toujours l'enfer avec la promesse que demain ça ira mieux. J'ai exactement le même ressenti que David, je configure jack, je branche les 3 connexions qui m'intéressent parmi les dizaines proposées, ça prend une éternité à mettre en place. Ensuite tout ce qui est hors jack ne fonctionne plus, donc pas moyen de télécharger ou d'écouter un sample rapidement… Au final je passe deux heures à faire de la technique plutôt que de faire de la musique :(

Valgrind est très très lent et ne fait pas de multithread. Je pense que là on est plus près d'AddressSanitizer.

Avec le temps j'ai compris que ce qui m'intéressait dans la comm' n'était pas tant les retours de la communauté que l'autocritique et l'introspection. Je recommande grandement à chacun d'écrire sur ce qu'on produit, expliquer comment ça marche, pourquoi c'est fait ainsi, et en particulier d'expliquer les parties dont on est fier, même si c'est un truc banal qui a été déjà mieux fait ailleurs.

Rien qu'à faire cet exercice ça te fera progresser et tu seras content de faire mieux à l'itération suivante. Ensuite, après quelques années tu auras une pile de documents qui l'aideront à mesurer le chemin parcouru. Tu regarderas de vieux trucs en te disant « ah je faisais comme ça à l'époque ? Pas top ! » et tu continueras à travailler ton art en comprenant que ce que ton meilleur d'aujourd'hui te semblera quelconque demain, et que c'est le signe de ton progrès personnel.

Aujourd'hui j'écris des billets de blog sans pour autant les partager. Quand je le fais je prends note des retours avec plus de recul. Ça n'empêche pas que le seul commentaire négatif dans un flot d'éloges me transperce toujours, mais c'est plus facile à gérer qu'avant. Au pire il suffit de fermer l'onglet :)

très rapide et consomme peu de mémoire.

il peut encaisser énormément de routes

Le tout fonctionne très rapidement et peut encaisser beaucoup de requêtes / seconde.

L'idée principale derrière le projet était de créer un outil léger et performant.

Quand on annonce des perfs il faut donner du contexte, des chiffres, et dire à quoi on se compare :)

éteindre son téléphone sans le sortir de son sac ni le regarder

Fastoche, il suffit d'attendre deux jours et hop, il est éteint :)

Aurais-tu une solution pour restaurer le revêtement conducteur aussi ? J'ai le souci avec une vieille télécommande et le nettoyage n'y fait rien. Obsolescence programmée sûrement ; elle a à peine 20 ans.

En collant un bout d'alu sous le bouton ça fonctionne bien, mais je sens que ça va finir par se décoller et me poser des problèmes.

Merci pour les retours :)

Aujourd'hui, on est tombé sur un bug bizarre où une personne reste seule après que les autres aient succombées à des bombes et la partie ne finit jamais même quand cette dernière personne se fait hara kiri. Cela vient encore de m'arriver (vers 21h48 si cela t'aide à retrouver dans les logs)

Je crois que j'ai trouvé la partie problématique. Une partie à 3 joueurs où tout le monde se fait exclure par le serveur pour cause de retard. Effectivement je n'avais pas envisagé ça… Heureusement que la QA est là !