une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
Canard lecture
Ha bah je me rappelle qu'il y a un peu plus de 10 ans, mon prof d'info nous disait que pour apprendre à écrire des pilotes, il n'y a pas de cours ni de manuels. Il faut regarder ce qui existe et se débrouiller avec, parfois modifier de l'existant, tellement c'est compliqué.
Apparemment ça n'a pas tellement bougé ?
C'est fait par des hardeux souvent :D
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
Ce qui explique que ce soit codé avec la bite ?
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
Les fameux drivers de Rocco...
Ah bah tiens, ça me rappelle que je viens de passer 6 mois à bosser sur un combo FPGA + hyperviseur bare-metal en x86. Et bah la base de code c'est pas la joie.
Le mec il a bossé seul dessus pendant 6 ans, j'ai jamais vu un truc aussi terrible. Il y a du code mort de partout du coup c'est compliqué de grep dans le code car il y a plein de faux positifs. Les variables sont nommés n'importe comment et ne veulent rien dire (du coup va comprendre que "int zizi = 0xTRUC;" c'est ce que tu veux modifier). Et bien sûr comme c'est du bare-metal ça donne une bonne excuse pour ne pas mettre de tests en place et donc je me mange régression sur régression ("ah bon le driver rezo il march pu ?").
Le truc aussi avec u-boot et Linux pour embarqué, c'est que bien souvent c'est forké et codé à l'arrache par le fabricant de la board avec juste ce qu'il faut pour faire marcher le merdier, et sans jamais se préoccuper de la maintenabilité. C'est forké à nouveau pour chaque board, et le code est copié collé à droite à gauche en fonction des besoins.
Perso, ce que j'avais vu d'u-boot (le vrai source, pas les fork) c'était pas trop dégeux justement. Mais ensuite, chaque driver est maintenu par des gens différents et ne sont pas tous de qualité équivalente (comme Linux, même s'il y a sans doute plus de nettoyage transverse), surtout si c'est spécifique à certaines boards.
Pour illustrer autant Allwinner faisait du code immonde, autant le code de la communauté Sunxi et Bootlin qui tentent d'intégrer le support de leurs cartes dans Linux et u-boot c'était plutot super clean.
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Ouaip ouaip tout à fait, d'ailleurs je me fais un malin plaisir à noter les noms (l'auteur en haut des sources), puis à aller voir leur profil sur Linkedin pour récupérer la photo et l'utiliser sur ma poupée vaudou
J'ai un comportement que je ne comprends pas sur mon programme Qt
C'est un peu le ramasse-merde pour plein de bibliothèques orientées métier que je suis absolument obligé d'inclure sinon rien ne marche.
Et du coup, certaines choses qui devraient marcher ne marchent plus. J'en suis arrivé à mettre ce snippet de code dans le main de l'appli, et voilà ce qu'il donne:
Donc, en gros, seul le lexical cast semble en mesure de traduire des chaines de caractère en double sans faire du rounding silencieux. Manque de bol, dans le code que je reprends (et pas dans le 'main'), c'est que du atofCode:std::string myString = "63.22334455"; double faitCher = std::stod(myString); // 63! double faitCher3 = atof(myString.c_str()); //63! double faitCher2 = boost::lexical_cast<double>(myString); //63.22334455
Je suis assez alarmé par ce comportement que je ne comprends pas. Je vois comment le corriger, mais si les fonctions de la bibliothèque standard marchent quand elles veulent, euh...
Bien évidemment, tout le snippet fonctionne normalement sur un programme "vanilla", comme il le devrait.
Un problème de locale ?
Un define casse couille laissé dans le code par un autre dev ?
Et accessoirement, est-ce que tu es sur que c'est bien un rouding, et pas un cast to integer ?
EDIT : ça ressemble a ton souci : https://stackoverflow.com/questions/...turns-integers
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
C'est juste du cast to integer en fait.
Et effectivement, ça ressemble à un problème de locale vu que "63,28" est converti correctement par tout le monde.
Je ne savais pas que c'était dépendant du locale, et surtout je n'avais jamais l'occasion de le modifier (ni de le voir modifié en loucedé).
C'est courant dans certains code en C de commencer par un set_locale truc pour, justement, faire en sorte que ce soit homogène dans le code.
On m'a contacté pour un poste honnêtement bien payé en région parisienne pour du C++/GPU embarqué avec un profil sénior (donc vous comprenez que j'ai pas trop le profil).
Le chasseur m'a encouragé à diffuser l'offre. Si ça intéresse des gens, me MP pour descriptif complet.
Je précise que je m'assois sur la prime de cooptation, c'est uniquement histoire d'aider des canards en recherche de missions GPU (expérience OpenCL/CUDA, optimisation).
Bah double junior c'est bon aussi du coup ?
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Si z'êtes pas trop gourmands, pourquoi pas
Me MP pour les intéressés, je ne mords pas.
Question aux canards : j'ai un slide de cours que je vais donner et que je retravaille en ce moment.
Celui-ci affirme ceci :
Je suis un brin surpris, j'avais jamais entendu qu'en C<99 on ne puisse pas faire de // . Ou alors sur un C encore plus ancien peut-être, mais je suis quasiment certains d'avoir compilé avec le flag ANSI (équivalent à C 89/90) et des commentaires sur une seule ligne avec // .Code:En C < 99 Commentaires en plusieurs lignes : /* */ Commentaires dans une seule ligne : /* */ En C++ et C > 99 Commentaires en plusieurs lignes : /* */ Commentaires dans une seule ligne : //
Je suis dans l'erreur ?
https://en.cppreference.com/w/c/comment(since C99)
Non c'est bien le cas. Après tu peux avoir des options dans GCC pour qu'il ne bronche pas dessus.
GCC compile par défaut en C89 + extensions GNU (gnu89), il faut ajouter des options pour qu'il devienne strict.
Ha, ce sont les extensions qui font le taf sur cette histoire de commentaire alors ?
Tiens... je me suis mis au Javascript depuis cet été (Typescript/React en fait), et je viens de découvrir un p'tit truc rigolo...
Code:0 * -1 // ça donne -0
"Tout est vrai, tout existe, il suffit d'y croire."
Dieu. (enfin… je crois)
Ca fait jamais de mal de revoir ça
https://www.destroyallsoftware.com/talks/wat
Ha mais JS et les maths, ça ne fait pas bon ménage :D
Essaie aussi de passer un très grand nombre sous forme de string, puis de le convertir en numérique. Sa partie droite (ou gauche, ché plus) sera tronquée si besoin pour tenir dans le type, sans signaler d'erreur.
Je n'ai pas l'exemple précis en tête, mais grosso-modo l'idée c'est que "1000000000" devient en douce 1000000.
On a eu ce soucis en live sur un projet, les lignes de facturations étaient anormalement faibles (mais heureusement ça restait de l'affichage seulement, le backend était sauvé).
Et les flottants aussi, dans ce cas