Musée des horreurs informatiques - Page 52

(ah ?)

squalyl > attends que ça t'arrive, tu rigoleras moins

(Ca m'est arrivé une fois avec un dd, persuadé que le disque système était sda alors que c'était sdb. Et une fois avec un del *.* au mauvais endroit dans un bon vieux DOS quand j'étais collégien et que j'avais la charge officieuse des ordinateurs du CDI... clavier en qwerty, je voulais faire B: puis del *.*, sauf que j'ai fait B. [puisque j'étais en qwerty], et del *.* [puisque je l'ai tapé avec le pavé numérique]... résultat, j'ai effacé tout ce qui était à la racine sur A: [donc tout un programme et ses sauvegardes]).
(Et les deux fois, j'ai dû faire peu ou prou la même tête que Grü)

(oh !)

Zerosquare (./1524) :
J'aimerais être d'accord tellement c'est énorme, mais pour avoir vu certaines choses et lu certains témoignages, je peux pas l'affirmer avec certitude.

Franchement ça ne m'étonnerait pas tant. Dans le monde du javascript c'est juste hallucinant ce que tu trouves. Je ne sais pas ce qu'on enseigne aujourd'hui dans les universités de Software Engineering, mais le Javascript semble être un repaire de gens qui n'ont suivi aucun cours, et qui sont super pragmatiques (genre regardez comme on arrive simplement à faire une super appli web qui génère des millions). Comme la réalité leur donne raison (alors qu'avant ça ils étaient considérés comme des branques), leur ego prend un méga coup, et difficile d'y faire quoi que ce soit. Je pense sincèrement que c'est perdu, on ne reviendra pas en arrière, parce que même si t'es un bon ingénieur comme moi, en codant même en TypeScript pour faire gaffe, tu perds petit à petit tes capacités (qui sont inutiles, vu que la fiabilité globale de ton code sera toujours limitée par celle des frameworks externes, et honnêtement il n'y en a virtuellement aucun qui te permettrait de passer un examen d'entrée d'une université ; et en plus tu sais que tu réécriras tout dans moins d'une année avec le prochain gros framework alors pourquoi s'emmerder ?).

Raison de plus pour que tu te BARRES DU DÉV WEB AVANT QUE CE SOIT TROP TARD !!!
()

Nil (./1533) :
(Ca m'est arrivé une fois avec un dd, persuadé que le disque système était sda alors que c'était sdb. Et une fois avec un del *.* au mauvais endroit dans un bon vieux DOS quand j'étais collégien et que j'avais la charge officieuse des ordinateurs du CDI... clavier en qwerty, je voulais faire B: puis del *.*, sauf que j'ai fait B. [puisque j'étais en qwerty], et del *.* [puisque je l'ai tapé avec le pavé numérique]... résultat, j'ai effacé tout ce qui était à la racine sur A: [donc tout un programme et ses sauvegardes]).
(Et les deux fois, j'ai dû faire peu ou prou la même tête que Grü)

Ca m'est jamais arrivé, mais parce que je check toujours un nombre honteux de fois même quand je suis déjà 100% sûr ?

Zerosquare (./1536) :
Raison de plus pour que tu te BARRES DU DÉV WEB AVANT QUE CE SOIT TROP TARD !!!
()

J'ai reçu une offre pour pas mal plus de thune que maintenant et je crois que j'aurais à faire du C++ (apparemment des libs pour des jeux console), ça me plairait probablement plus ouais. La réalité c'est que j'ai refusé/saboté un peu tout ce que je pouvais avoir jusqu'à maintenant parce que j'ai pas envie de bosser dans un bureau ?

Je me rappelle avoir eu un mini-orgasme la dernière fois que j'ai codé en C++, notamment juste sur mon roxxor tool. C'est incroyable de penser que certaines parties du code que j'ai écrit ont plus de 18 ans, et pourtant elles sont plus pertinentes que jamais. Du coup quand je code là-dessus ça donne une telle satisfaction, tu peux tellement mettre même des jours pour coder une feature (et honnêtement ça ne prend que marginalement plus qu'en Javascript, et toutes les contraintes ont généralement un sens sur le terme -- te permettent de te rendre compte de problèmes dans ton design, dans ton expression du problème…), vu l'impact qu'elle a ça reste super cheap.

Tu es sur la bonne voie, continue

Me fait penser que l'autre jour, mon game production manager est venu vers nous et a dit "il y a un problème. Le jeu sort dans 1 mois mais il y a un gros memory leak". Jeu en Javascript donc hein.

Après investigation, effectivement à chaque partie 30 Mo sur les 33 Mo qu'alloue notre app sont leakés. Si on joue longtemps on leake 30 Mo de plus par 3 minutes. Le javascript est un langage garbage collecté hein, donc aucun problème non ? Pourquoi s'emmerder. Ben la réalité c'est que ni le moteur qu'on utilise (PlayCanvas) ni notre code ne suit aucun des principes de base de gestion de la mémoire, comme par exemple se poser la question "à qui 'appartient' cet objet, quel est son cycle de vie ? avec qui peut-il interagir, qu'est-ce qu'il se passe avec les informations qui transitent, combien de temps est valide l'état", etc. et donc ouais pas de miracle, tout est leaké avec des références cycliques que Javascript peut pas nettoyer. Concrètement, Javascript est capable de nettoyer les références cycliques car il a un vrai GC, mais il ne peut pas dès qu'il existe une closure référençant un des objets dans le cycle, et en codant en JS typique c'est facile d'avoir aussi des cycles entre ces closures. Bref au final il a fallu revenir au memory management à la C++. Ca n'a peut être pas pris autant de temps, mais ça reste super fragile (il faudrait à minima des tests unitaires pour les memory leaks, et aucun CI ne semble à priori proposer ça). Et quoi qu'il en soit PlayCanvas n'offre juste aucun moyen de nettoyer et on leake un minimum d'1.5 Mo à chaque partie (mais c'est vraiment un minimum, en allant taper dans les variables internes du moteur pour lui forcer à libérer des choses qu'il ne devrait pas garder). Donc oui le Javascript c'est facile à coder, à peu près comme du C++ où tu ne ferais que des new et jamais de delete (essayez, c'est tout à coup surprenamment facile le C++ !), et justement ça tombe bien le résultat est le même en consommation de ressource

A savoir d'ailleurs, c'est pour ça que JS ne fonctionne réellement que dans un contexte serveur, avec des workers (processus) démarrés dynamiquement et terminant avec leur tâche. Pour tout le reste, tout soft JS est amené à planter sur la durée.

Un autre moteur dont je ne saurais cesser de louer les qualités innombrables (le saviez-vous ? il a fallu pas mal de temps à l'humanité pour inventer le chiffre zéro ; le Chinois ne l'avait même pas avant qu'on vienne essayer de les coloniser, ou quelque chose dans le genre). C'est cool, c'est moderne, ça affiche des exemples pris depuis GitHub. Sauf que pour moi dans plus de 70% des cas ils ne s'affichent pas, ça reste comme ça et je dois raffraîchir plusieurs fois la page. Mignon, quand tu considères le moteur, mais quand tu dois l'utiliser…

Ça ne fait que confirmer ma conviction désolante qu'en info, le plus souvent on ne résout pas les problèmes fondamentaux, on se contente de les déplacer et de les planquer (enfin y'a quand même des gens qui bossent sur les problèmes difficiles, mais c'est que dalle face à la masse de ceux qui réinventent une énième fois une roue aussi excentrique que la précédente).

Je crois que tu formules ça très bien en fait. Cacher la merde au chat ; au final en Javascript c'est super facile de faire une pièce énorme de code, en réutilisant les briques (npm, etc.). A priori ça paraît une bonne idée, mais la réalité c'est que tu te retrouves à réinventer la roue sans connaître les implications. Les problèmes sont là, juste cachés derrière un require ou, plus probable, un engrenage de composants maladaptés, qui chacun ne sont pas forcément critiquables (si tu les considères individuellement avec toute l'empathie qu'ils méritent) mais dans un tout cause plus de problèmes que tu ne pourrais imaginer.

Le problème est dans le fait même de réinventer la roue je pense. Soit tu le fais entièrement et tu sais vraiment ce que tu écris (et ça prend des méga plombes, mais au moins tu as gagné quelque chose dans l'histoire), soit tu ne le fais pas, et alors tu essaies de te baser sur du soft existant.

C'est quand même fou, maintenant j'utilise Tiled parce que c'est un standard dans les softs d'édition de maps, mais GBA Graphics que j'ai écrit il y a plus de 15 ans est encore mieux sur un nombre de points fondamentaux du workflow de map edition, mais je vais pas proposer ce soft maison abandonné et utilisé par pratiquement personne de nos jours à mes étudiants. Ca m'énerve, ça m'énerve. Bon au final je l'ai utilisé sans rien dire pour créer mon tileset à partir d'une image que j'ai dessinée, et je dirai au étudiants de créer le leur depuis zéro au lieu de depuis une image (sincèrement c'est fantastique de pouvoir commencer une map à partir d'une image !!!).

le java aussi est garbage collecté... sauf pendant l'exécution de routines JNI (implémentation C ou C++ de méthodes java), ou le GC se déclenche au retour de la VM, donc en géneral c'est pas grave.

sauf quand tu fais un thread dans le code JNI, qui doit exister longtemps. Ds ce cas, le GC ne se déclenche jamais pouir libérer les objets créés ds ce thread, puisque il ne revient jamais dans la VM, et du coup, ben faut gérer toutes les références aux objets java que tu créees a la main, et c'est pas toujours trivial, surtout au début quand t'as pas pigé comment ca se gère.

Tain mais j'en reviens simplement pas comme Phaser peut être à la rue, c'est n'importe quoi de n'importe quoi de n'importe quoi. Tu fais une caméra qui avance de tant, elle n'a pas l'air d'avancer exactement à cette vitesse pour une raison non-documentée. Ensuite tu déplaces le BG à la même vitesse que la caméra pour qu'il reste fixe, mais en fait non il avance dans l'autre sens à 0.5 la vitesse alors du coup je le fais avancer de 50% la vitesse de la caméra pour le rendre fixe (bonjour pour expliquer aux étudiants pourquoi on fait ça comme ça ) et quand on arrive au bout de la map, même s'il devrait y avoir encore de l'espace pour un écran entier, la caméra refuse de scroller donc j'ai dû mettre un espace vide de la taille d'un écran dans ma map pour compenser.

Leur système d'UI ne fonctionne juste pas (faudrait déboguer pour comprendre pourquoi mais j'ai abandonné). J'ai été poster sur le forum en mettant mon projet (trivial) comme exemple et on me dit que c'est probablement parce que j'utilise typescript. My ass, c'est juste pas possible. Au final j'ai fait l'UI en HTML par-dessus mais c'est bien plus compliqué que ça en avait l'air, et ça va être trop compliqué de faire faire ça aux étudiants je pense, donc je vais devoir plonger dans le code source, juste pour un foutu bouton ou deux.

Putain mais sérieusement un débutant sur TI code mieux que ça !

squalyl (./1544) :
le java aussi est garbage collecté... sauf pendant l'exécution de routines JNI (implémentation C ou C++ de méthodes java), ou le GC se déclenche au retour de la VM, donc en géneral c'est pas grave.

sauf quand tu fais un thread dans le code JNI, qui doit exister longtemps. Ds ce cas, le GC ne se déclenche jamais pouir libérer les objets créés ds ce thread, puisque il ne revient jamais dans la VM, et du coup, ben faut gérer toutes les références aux objets java que tu créees a la main, et c'est pas toujours trivial, surtout au début quand t'as pas pigé comment ca se gère.

Ouais je connais ça. C'est super dur et error-prone, mais au moins c'est sérieux (i.e. utilisable). Après je dis pas, je déteste ça aussi, mais c'est du code qui est reconnu comme difficile et que tu n'écris qu'une seule fois.

Le truc commode, quand même, quand on est professionnel, c'est qu'on est pas obligé de comprendre pourquoi ça marche pas. Tant qu'on trouve un hack ou un workaround, tout va bien. Ca doit quand même être une sacrée invitation à la paresse.

Oui alors ça dépend quand même un peu de la situation, les boites peuvent imposer des condition plus ou moins strictes en ce qui concerne la propreté du code et quand tu sais que tu vas avoir a maintenir le code un certain temps, tu as quand même intérêt a ce que ça soit propre.
Mais c'est vrai que dans beaucoup trop de cas on patche en mode dégeu, tant que ça marche.

Brunni (./1545) :
Tain mais j'en reviens simplement pas comme Phaser peut être à la rue, c'est n'importe quoi de n'importe quoi de n'importe quoi. Tu fais une caméra qui avance de tant, elle n'a pas l'air d'avancer exactement à cette vitesse pour une raison non-documentée. Ensuite tu déplaces le BG à la même vitesse que la caméra pour qu'il reste fixe, mais en fait non il avance dans l'autre sens à 0.5 la vitesse alors du coup je le fais avancer de 50% la vitesse de la caméra pour le rendre fixe (bonjour pour expliquer aux étudiants pourquoi on fait ça comme ça ) et quand on arrive au bout de la map, même s'il devrait y avoir encore de l'espace pour un écran entier, la caméra refuse de scroller donc j'ai dû mettre un espace vide de la taille d'un écran dans ma map pour compenser.

Tiens, à tout hasard, as-tu testé Superpowers comme moteur ? A-t-il les mêmes porblèmes ? Ou d'autres bien pires ?
http://superpowers-html5.com/index.fr.html

Folco: Détrompe toi. nous on fait une carte, et on s'oblige a donner une explication logique a tous les bugs qu'on trouve, même quand c'est apparemment quantique et potentiellement du au compilo, et c'est pas toujours simple. Une fois que lales millions de cartes sont dans les poches des clients, t'as pas la chance de pouvoir patcher, donc la release doit être PARFAITE autant que possible.

Ca n'est jamais parfait mais on se donne un temps suffisant pour ne jamais se dire "ah non ce ptit truc boh pas grave on teste pas." nope. on essaye pour vérifier que c'est bon. Et parfois, c'est le test lui même qu'il faut remettre en cause...

autre sujet;

!godmode

Tiens, au passage puisqu'on parle de garbage collector, un de mes collègues (moins technique) est venu me voir tout à l'heure pour un problème de mémoire.
Son script PHP examine un (très gros) fichier XML Du coup comme il ne connaît pas la profondeur des nœuds, il utilise une fonction récursive.
Sauf que ! Voilà en très gros à quoi ça ressemblait.

<?php $foo = maFonction($xml, $noeud); function maFonction($xml, $noeud) { $Objet = new Objet(); // Gros vendor bien complexe $results = []; $children = $Object->getChildren($xml, $noeud); foreach($children as $child) { $results[] = maFonction($xml, $child) } return $results; }
Et qu'après 10 minutes à tourner, le script commence à bouffer plus de 2Go, alors qu'il est loin d'avoir fini, il se contente d'enfler. Il propose d'augmenter la limite mémoire de PHP et le faire tourner plutôt sur un de nos serveurs qui a beaucoup plus de RAM. Mwai... heureusement que je suis intervenu.

faut parser avec SAX pour les gros XML, jamais DOM!

squalyl (./1550) :
autre sujet;

!godmode

Hacker Finds Hidden 'God Mode' on Old x86 CPUsTom's HardwareOld VIA C3 chipsets have an undocumented RISC coprocessor that gives you root access from userland if you simply type in four bytes.

Ha tiens faudrait que je teste ça de retour chez moi, j'ai justement gardé un petit Thinclient avec un VIA 3 chez moi qui me sert pour faire de la musique sous DOS via le port parallèle
Vu que Tom's Hardware est toujours aussi naze niveau citation des sources voici le GitHub du chercheur : https://github.com/xoreaxeaxeax/rosenbridge

<HS> sinon en fouillant sur son GitHub je suis tombé sur un autre de ces projets, un compilo C x86 qui obfusque le code en remplaçant toutes les instructions assembleur par des mov </HS>

./1550 -> mais c'est de la folie pure ce truc !!!

Jonas: J'avais discuté avec le dit xoreaxeax et il a fait d'autres versions de son compilo, en particulier avec "que des add" "que des sub" / rotate / autres ops booléennes et autres, puis il a fait selon mon conseil un randomfucator qui combine au hasard les résultats des autres...

and the randomfuscator just randomly throws crap together: https://t.co/p3WyNnMZHX (HT @angealbertini @f4grx) pic.twitter.com/DsnESKsfsj

— domas (@xoreaxeaxeax) October 1, 2015

squalyl (./1550) :
https://www.tomshardware.com/news/x86-hidden-god-mode,37582.html

Au moins l'accès userspace à ce mode peut être bloqué:
https://github.com/xoreaxeaxeax/rosenbridge/tree/master/lock
https://github.com/xoreaxeaxeax/rosenbridge/tree/master/fix
Le noyau Linux va peut-être faire ça automatiquement bientôt?

Mais c'est complèment dingue que ce soit activé par défaut.

squalyl (./1555) :
Jonas: J'avais discuté avec le dit xoreaxeax et il a fait d'autres versions de son compilo, en particulier avec "que des add" "que des sub" / rotate / autres ops booléennes et autres, puis il a fait selon mon conseil un randomfucator qui combine au hasard les résultats des autres...

and the randomfuscator just randomly throws crap together: https://t.co/p3WyNnMZHX (HT @angealbertini @f4grx) pic.twitter.com/DsnESKsfsj

— domas (@xoreaxeaxeax) October 1, 2015

Ha mais trop bien, j'ai envie de tester de faire quelques crackmes avec

bon par contre ca fait du code spaghetti hein

Plutôt du code spaghetto (au singulier).

plutot UN très long spaghetti parce que y'a quasiment pas de branchements