Oui. Le form peut utiliser GET et POST. Mais dans tous les cas, le passage d'informations via URI était présent avant.
La seule chose que fait <form> c'est de rendre le truc plus facile, à la fois pour ceux qui savent et pour ceux qui savent pas. C'est bien mon propos: l'ajout de form n'a fait que rendre les choses faciles, mais c'était déjà faisable avant. Et le web n'a pas non plus inventé l'interaction sur l'internet.
l interaction n est pas nee avec le web, irc par exemple est plus vieux.
Meme le web permets d etre interactif sans form: passage de params via uri, cookies…
autant j aime pas vraiment le web, autant j y participe (ici, github…), et la simplicite aide les gens a maitriser, en vrai.
la merde,c est le standard "sables mouvants" qu est le web, pilote par celui qui a la plus grosse. Pas la techno.
encore que… a force de tout inclure tous les 2mois, il faudrait penser a garder un truc implementable from scratch, quitte a virer des elements d une version.
le 2nd de S, c est pour "stupid". c est tres mal choisi, parce que faire simple requiert d'etre smart. les gens stupides ne font pas du simple a maintenir.
je pense que tu confonds variables globales (accessibles hors TU) et variables de module.
La seconde est moins pire, et meme ok en mono-thread.
Mais la solution a trop de variables passees,je crois que c est plutot les "types utilisateur": struct en C. Qui rendent la maintenance de l api plus simple, sans etre la panacee
de memoire, cccc affiche en jaune ce qii depasse 50 lignes de code brut, entres autres.
c est une metrique quej essaie de suivre, mais avec la gestion des erreurs, les logs et autres asserts, 50 se depasse vite.
Apres, le code pour (de-)serialiser est une grosse exception, malheureusement.
Oui, j ai oublie le "entres autres".
Je parie que les conflits git sont moins tordus aussi quand on remplace un gros bloc..
j ai aussi deja pense a utiliser ce type de morcellement, mais clairement il faut un outillage qui masque l'info de bas niveau, ou une trop grosse discipline pour moi.
j y avais pense pour, notamment generer automatiquement le header des classes, maintenu a partir d'un graphe.
Je trouve toujours l idee allechante moi.
Vrai, mais C++ permets aussi de faire à la main.
C'est parfois utile, quand par exemple on veut éviter les réallocations et garder la mémoire "en bloc" (fragmentation mémoire). La STL ne fournit par exemple pas de ring buffer.
On pourrait aussi parler, niveau utilité, de la programmation bare metal (pas d'OS pour gérer la ram).
Certains programmes vont aussi implémenter plusieurs "tas", en fonction de la taille des allocations nécessaires ou de l'espérance de vie, pour des raisons de performances.
On est bien d'accord: ce sont des cas exceptionnels. Mais ils existent, sont pour moi uniquement possibles dans des langages bas-niveau, et le sont en C++. Malgré qu'il fournisse aussi des fonctionnalités de haut niveau (RAII, héritage, exceptions, RTTI. La programmation générique me paraît ni haut, ni bas niveau par contre?).
La STL fournit nombre d'abstractions qu'il est désormais recommandé d'utiliser, sauf si tu as un besoin spécifique bien sûr.
Typiquement, la STL est incapable de gérer le besoin spécifique qui est de gérer des handles, tant que c'est pas des pointeurs.
Descripteurs de fichiers UNIX, ID mémoire opengl, ID de fenêtres WIN32… je pense que certaines API que BDD utilisent aussi des IDs.
Elle est pourtant à mon avis un bon example de fonctionnalités génériques, de haut niveau, puisque le contrôle sur la mémoire est au final assez faible quand on l'utilise, au moindre problème ça balance une exception, et il n'existe à ma connaissance aucun outil capable de vérifier que toutes les exceptions ont été traitées, en C++.
Par contre, le langage lui-même est capable de mieux, notamment pour le debug (non, debug la STL c'est pas génial) ou les systèmes ou les exceptions ne sont pas les bienvenues (pour diverses raisons). Cf eastl.
Maintenant, concernant le C++ et le Go, c'est mécanisme de gestion de mémoire sont bien masqués à l'utilisateur. […] En C++ ce n'est pas toi qui appelle tel ou tel constructeur, ni les destructeurs.
Je vais peut être dire une connerie, mais tu veux dire quoi par "un mécanisme à la defer" pour toi ?
De permettre d'enregistrer des actions qui seront effectuées à la sortie de la fonction, typiquement pour éviter la dose de "goto erreur niveauX: fclose( file );"
Ce que la RAII permets, quoi, mais en moins évolué et sans exceptions (qui ne sont pas appréciées par tout le monde).
Il y a l'influence des outils (les fameuses IDE qui font tout un tas de trucs y compris afficher la liste des 170 fichiers dans une encadré en faisant croire que ce sont juste des fonctions –non, pas faux quand t'as une fonction par fichier etc.)
Vu le projet, je doute qu'il soit fait avec un IDE par contre, ou alors y'a des IDEs qui supportent autotools?
L'avantage d'une fonction par fichier, c'est le temps de compilation. Et un éditeur de code qui comprenne le langage peut largement permettre aux gens de naviguer entre les fichiers (le mien est pas config pour ça, mais rien ne l'empêcherait je pense)
Le C++ peut faire les deux, en fait (bas niveau, haut niveau). Après, gcc eux-mêmes utilisaient un garbage collector avant (j'avais vu un article sur lwn.net, qui expliquait qu'ils allaient intégrer du C++ pour réduire ça et donc améliorer les perfs, secoués par le succès alors montant de clang), et pourtant, c'est (c'était?) du C, donc bon…
On peut utiliser le C++ sans la STL, et dans ce cas on doit faire la gestion de la mémoire à la main (encore que, dans ce cas, on code soit-même ses wrappers…).
Parfois même, pas le choix, par exemple si on veut utiliser mmap (qui renvoie -1 et pas 0 en cas d'échec «On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error.») ou, plus parlant compte tenu du journal: dans le cas d'openGL ou dans de vulkan (ça retourne des handles, donc std::unique_ptr peut pas gérer sans intermédiaire).
Mais bon, je suis d'accord que:
Et même dans des langages bas niveau tel que le C, ou haut niveau tel que le C++ ou le Go, ces choses sont masquées.
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
Toujours à ma connaissance en C, il n'y a pas besoin d'empiler manuellement avant d'appeler une fonction, ni de faire l'inverse en en sortant.
Ce qu'il manque au C (selon moi) pour alléger considérablement la charge des développeurs, c'est un mécanisme à la defer (go, je crois?).
Toujours en parlant de jeu vidéo, l'auteur devrais s'amuser un peu avec le langage de script de mindustry, la, il verrait ce qu'est une absence de gestion de la mémoire.
Et toujours à ma connaissance, en C++ les automatismes de gestion de la mémoire, ça se limite à la STL (mais je doute que Rust n'ait pas une lib pour tableaux dynamiques, listes chaînées, dictionnaires, … hein) ainsi qu'à la RAII (idem, je doute que Rust ne permette pas ce genre de choses, d'une façon ou d'une autre).
Comme je l'ai dit plus haut, la STL elle-même n'est pas parfaite, mais c'est bien assez bon dans 99% des cas.
Je me demande a quoi sert cette phrase en fait. Pourquoi dénigrer les autres langages (surtout en intro, ça ne donne pas envie)? Rust n'a-t-il donc pas assez de qualités?
En meme temps le projet est de 2011, avec plusieurs presentations depuis, selon wiki la derniere est de 2016.
Perso, je suis surtout curieux de la taille de la machine en photo, je n ai pas vu l'info. Je me demande aussi quelles sont les capacites des mains, cet aspect n'est pas du tout mis en avant par le peu que j'ai lu.
Le reste, la vision, la voix synthetique, etc, c'est cool aussi mais c'est juste du cpu et des libs au final. Je me permets meme de douter de l'ouverture des licences des-dites libs, sans la moindre preuve, je precise. Sinon, ca ne serai pas un doute.
Utilises clang-format pour générer un code formatté correctement à partir du code a ajouter, fais un diff, et si il y a des différences, tu envoies une erreur. Ensuite, tu places tout ça dans un pre-commit hook ainsi qu'un pre-merge (je suis plus sûr pour le 2nd, mais bref, le hook qui vérifie les patches avant de fusionner, parce que le pre-commit hook est malheureusement uniquement en local et n'est pas cloné à ma connaissance).
Je n'ai jamais utilisé cette technique avec clang-format, qui est sur ma TODO-list depuis perpette, mais j'ai fait exactement ça avec astyle, que j'utilise depuis avant la naissance de clang-format.
Genial! Ca juste marche, merci. Je n ai pas pu tester encore la version iw, parce que par habitude, j ai installe wireless-tools…
bon ca marche parce que j ai une ip et acces au portail mitm, reste a demander la "cle" mais ca devrai le faire.
Contrairement a tes proches, la poste ou la sncf donnent du service a tout le monde (moyennant finances pour la sncf et le courrier pas electronique de la poste). Je doute que ca soit comparable.
Tout à fait.
En fait, tu remarqueras que je ne participle plus vraiment (je serais curieux de voir un histo de mes connexions récentes, pas sûr que ça soit techniquement possible ceci dit).
C'est à peine si je viens voir de temps en temps, en fait. Et je constate que le plus souvent, je me contente maintenant de survoler les titres des liens quand je m'ennuies, et éventuellement aller voir ce qu'ils s'en dit histoire de sourire. Les journaux, je les ignore de plus en plus.
Vu que j'ai pas grand chose à faire au taf en ce moment, je me suis loggué hier, mais je constate que je visite plus facilement (mais ne me suis pas loggué la bas depuis des mois, littéralement, possiblement des années je sais pas) developpez.com (qui pourtant a des contenus "journalistique" de qualité plus que douteuse, mais bon, ça occupe 2minutes).
Je ne vais pas continuer le hors sujet, ça n'a que peu (aucun en fait) d'intérêt.
Bref $WEBSITE_NAME, c'est un peu ce que les utilisateurs en font.
En nombre de journal aujourd'hui sur la page principal, ça reste quand même logiciel/matériel libre qui sont en plus grand nombre
Je serais curieux de voir une liste des titres sur 12 mois, pour le coup. Pour les sujets, ça demande d'ouvrir la chose, donc plus d'efforts, pour peu d'intérêt au final (c'est vraiment une curiosité).
Mais si on devait faire un journal à chaque promesse ou annonce d'un gars médiatisé, LinuxFr.org perdrait tout son intérêt encombré par le bruit.
hum…
Cet argument ne me frappe pas, je sais pas pourquoi…
Ah. Si. Je sais.
Parce que j'ai l'impression que la plupart des discussions causent de politique, bien souvent même pas liée au logiciel libre.
Je suppose que je me trompe, et je finirai donc dans les limbes du -10… ou pas, a chaque fois qu'on dis ça, on se trompe. Advienne que pourra, je m'en tape.
les frameworks "modernes" sont toujours d'immondes bouzes qui nécessitent 2 Go d'installation avant de pouvoir écrire un "Hello, World" en noir sur fond blanc.
C'est parce que tu prends la mauvaise fonte, avec du Comic sans MS, je suis sûr que ça serait moins compliqué, probablement pour ça que c'était tant utilisé quand les DVDs existaient pas encore.
Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est… bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework… bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.
Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.
Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…
Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.
Je suis, ou ai été, sûrement très con, mais en fait, la raison initiale qui m'a fait rejeter hg était… c'est en python. Et j'avais (et toujours en vrai) plus confiance dans les langages compilés qui ont, par défaut, un minimum d'analyse statique.
Je n'ai aucune opinion sur hg en soit, et j'en ai entendu pas mal de bien.
D'un autre côté, je suis content d'avoir fait confiance à un outil codé dans un langage standardisé ISO vue la transition «difficile» entre python 2&3.
Ceci n'est en revanche qu'un détail d'implem. Git commence a avoir un 2nd utilisateur got, qui le rend d'autant plus crédible. À quand un autre outil de versionning assez fiables et simples sur le long terme pour avoir d'autres clients qui émergent (l'inverse du web)?
ne pas se faire envoûter par les sirènes de la programmation facile et les fourre-tout à fonctionnalités (aka bloatwares)
Et je pense que j'ai à peu près mon compte :p
Pour ajouter un peu de contenu, je pourrais par exemple parler de ma vieille machine, parfaitement fonctionnelle, "designed for windows millenium", que j'ai acquise avec 64Mo de RAM (j'ai réussi à trouver de quoi monter à presque 200Mo \o/).
Cette machine flambante neuve dispose même d'un lecteur de bande SCSI, la pointe de la modernité, je vous dit!
Elle marche parfaitement avec une Debian 9, mais je ne pourrais probablement pas la booter avec une debian 11.
Je soupçonne ce fait parce que la dernière fois que j'ai voulu booter une VM qui ait moins de 250Mo de ram, l'initrd faisait partir le système en couille: pas assez de RAM.
Après augmentation de quelques dizaines de megs, plus de problème, et la consommation mémoire mesurée au login était inférieure à 50Mo.
Les gros consommateurs individuels? Le noyau et, surtout, systemd-udevd (le seul composant systemd installé).
Autre chose, si je laissait faire les MàJ, elle finirait avec systemd, plutôt que runit.
Hors, systemd, la dernière fois que j'ai mesuré, avait (de mémoire, presque un an) une empreinte RSS de plus de 30Mio.
À comparer avec "runsvdir + ( runsv + svlogd ) * N + runit" qui ont, liés à glibc, environ 750Kio de RSS (en moyenne). Liés avec musl, ou liés statiquement (ou en utilisant leurs équivalents dans busybox-static), on tombe à 4Kio de RSS par process.
En gros, systemd a, il est vrai, très peu de coût RSS par daemon géré (non mesurable, en fait), mais un coût initial énorme, alors que runit à un faible coût initial, et un gros coût par daemon (entre 8Kio et 1.5Mio, selon qu'on utilise glibc en dynamique ou non). La conclusion, c'est qu'il faut un nombre de daemon élevé (entre 20 et 7500, selon que glibc ou pas) pour que systemd soit à égalité avec runit de ce point de vue.
Sur une machine qui a moins de 200Mio, ça compte. Bon, en pratique, cette machine permets toujours de communiquer via IRC, mails, de faire de la bureautique… les seuls trucs qu'elle ne peut plus faire, c'est accéder au «web moderne» et lancer des jeux (encore que, de mémoire, j'arrivais a y faire tourner wesnoth), donc ça reste une machine d'appoint, au cas ou ma machine de tous les jours soit détruite (ou celle de quelqu'un d'autre, c'est déjà arrivé que je la prête, il avait fallu que j'installe LXDE, c'était amusant aussi ça, tiens).
On peut aussi parler, évidemment, d'ÉtronJS, qui embarque chromium dans chaque «application». Je ne ferai l'insulte a personne de développer ce point sur un point de vue écologique.
En fait, je pense que, bon, pourquoi pas… pour faire un PoC, un prototype, ça peut le faire, mais pour de la prod (en plus ça plante si facilement… je ne compte plus les SIGILL dans mes dmesg, quasi systématiquement liés à ce truc)?
J'ai pris systemd comme example, un peu pour le troll, mais aussi parce que j'ai effectivement mesuré, mais ça s'applique évidemment (et beaucoup mieux) à de nombreux autres logiciels: transmission consomme ~60Mio de RSS, contre le double pour qbittorrent, pour prendre un exemple récemment vu. Kiwix-desktop est un monstre (près de 180Mo), qui ne fait pourtant quasiment que la même chose qu'un serveur HTTP…
[^] # Re: ridicule
Posté par freem . En réponse au lien The ‘Form’ Element Created the Modern Web. Was It a Big Mistake?. Évalué à 2.
Oui. Le form peut utiliser GET et POST. Mais dans tous les cas, le passage d'informations via URI était présent avant.
La seule chose que fait
<form>c'est de rendre le truc plus facile, à la fois pour ceux qui savent et pour ceux qui savent pas. C'est bien mon propos: l'ajout de form n'a fait que rendre les choses faciles, mais c'était déjà faisable avant. Et le web n'a pas non plus inventé l'interaction sur l'internet.# ridicule
Posté par freem . En réponse au lien The ‘Form’ Element Created the Modern Web. Was It a Big Mistake?. Évalué à -1.
l interaction n est pas nee avec le web, irc par exemple est plus vieux.
Meme le web permets d etre interactif sans form: passage de params via uri, cookies…
autant j aime pas vraiment le web, autant j y participe (ici, github…), et la simplicite aide les gens a maitriser, en vrai.
la merde,c est le standard "sables mouvants" qu est le web, pilote par celui qui a la plus grosse. Pas la techno.
encore que… a force de tout inclure tous les 2mois, il faudrait penser a garder un truc implementable from scratch, quitte a virer des elements d une version.
[^] # Re: Bof
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
le 2nd de S, c est pour "stupid". c est tres mal choisi, parce que faire simple requiert d'etre smart. les gens stupides ne font pas du simple a maintenir.
[^] # Re: et les fonctions
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
je pense que tu confonds variables globales (accessibles hors TU) et variables de module.
La seconde est moins pire, et meme ok en mono-thread.
Mais la solution a trop de variables passees,je crois que c est plutot les "types utilisateur": struct en C. Qui rendent la maintenance de l api plus simple, sans etre la panacee
[^] # Re: et les fonctions
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
de memoire, cccc affiche en jaune ce qii depasse 50 lignes de code brut, entres autres.
c est une metrique quej essaie de suivre, mais avec la gestion des erreurs, les logs et autres asserts, 50 se depasse vite.
Apres, le code pour (de-)serialiser est une grosse exception, malheureusement.
[^] # Re: tss tss...
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
Oui, j ai oublie le "entres autres".
Je parie que les conflits git sont moins tordus aussi quand on remplace un gros bloc..
j ai aussi deja pense a utiliser ce type de morcellement, mais clairement il faut un outillage qui masque l'info de bas niveau, ou une trop grosse discipline pour moi.
j y avais pense pour, notamment generer automatiquement le header des classes, maintenu a partir d'un graphe.
Je trouve toujours l idee allechante moi.
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 4.
Vrai, mais C++ permets aussi de faire à la main.
C'est parfois utile, quand par exemple on veut éviter les réallocations et garder la mémoire "en bloc" (fragmentation mémoire). La STL ne fournit par exemple pas de ring buffer.
On pourrait aussi parler, niveau utilité, de la programmation bare metal (pas d'OS pour gérer la ram).
Certains programmes vont aussi implémenter plusieurs "tas", en fonction de la taille des allocations nécessaires ou de l'espérance de vie, pour des raisons de performances.
On est bien d'accord: ce sont des cas exceptionnels. Mais ils existent, sont pour moi uniquement possibles dans des langages bas-niveau, et le sont en C++. Malgré qu'il fournisse aussi des fonctionnalités de haut niveau (RAII, héritage, exceptions, RTTI. La programmation générique me paraît ni haut, ni bas niveau par contre?).
Typiquement, la STL est incapable de gérer le besoin spécifique qui est de gérer des handles, tant que c'est pas des pointeurs.
Descripteurs de fichiers UNIX, ID mémoire opengl, ID de fenêtres WIN32… je pense que certaines API que BDD utilisent aussi des IDs.
Elle est pourtant à mon avis un bon example de fonctionnalités génériques, de haut niveau, puisque le contrôle sur la mémoire est au final assez faible quand on l'utilise, au moindre problème ça balance une exception, et il n'existe à ma connaissance aucun outil capable de vérifier que toutes les exceptions ont été traitées, en C++.
Par contre, le langage lui-même est capable de mieux, notamment pour le debug (non, debug la STL c'est pas génial) ou les systèmes ou les exceptions ne sont pas les bienvenues (pour diverses raisons). Cf eastl.
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
On évite, mais on peut: placement new.
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 2.
De permettre d'enregistrer des actions qui seront effectuées à la sortie de la fonction, typiquement pour éviter la dose de "goto erreur niveauX: fclose( file );"
Ce que la RAII permets, quoi, mais en moins évolué et sans exceptions (qui ne sont pas appréciées par tout le monde).
[^] # Re: tss tss...
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
Comme ici: https://git.skarnet.org/cgi-bin/cgit.cgi/skalibs/tree/src/libstdcrypto
Vu le projet, je doute qu'il soit fait avec un IDE par contre, ou alors y'a des IDEs qui supportent autotools?
L'avantage d'une fonction par fichier, c'est le temps de compilation. Et un éditeur de code qui comprenne le langage peut largement permettre aux gens de naviguer entre les fichiers (le mien est pas config pour ça, mais rien ne l'empêcherait je pense)
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 7.
Le C++ peut faire les deux, en fait (bas niveau, haut niveau). Après, gcc eux-mêmes utilisaient un garbage collector avant (j'avais vu un article sur lwn.net, qui expliquait qu'ils allaient intégrer du C++ pour réduire ça et donc améliorer les perfs, secoués par le succès alors montant de clang), et pourtant, c'est (c'était?) du C, donc bon…
On peut utiliser le C++ sans la STL, et dans ce cas on doit faire la gestion de la mémoire à la main (encore que, dans ce cas, on code soit-même ses wrappers…).
Parfois même, pas le choix, par exemple si on veut utiliser mmap (qui renvoie -1 et pas 0 en cas d'échec «On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error.») ou, plus parlant compte tenu du journal: dans le cas d'openGL ou dans de vulkan (ça retourne des handles, donc std::unique_ptr peut pas gérer sans intermédiaire).
Mais bon, je suis d'accord que:
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
Toujours à ma connaissance en C, il n'y a pas besoin d'empiler manuellement avant d'appeler une fonction, ni de faire l'inverse en en sortant.
Ce qu'il manque au C (selon moi) pour alléger considérablement la charge des développeurs, c'est un mécanisme à la
defer(go, je crois?).Toujours en parlant de jeu vidéo, l'auteur devrais s'amuser un peu avec le langage de script de mindustry, la, il verrait ce qu'est une absence de gestion de la mémoire.
Et toujours à ma connaissance, en C++ les automatismes de gestion de la mémoire, ça se limite à la STL (mais je doute que Rust n'ait pas une lib pour tableaux dynamiques, listes chaînées, dictionnaires, … hein) ainsi qu'à la RAII (idem, je doute que Rust ne permette pas ce genre de choses, d'une façon ou d'une autre).
Comme je l'ai dit plus haut, la STL elle-même n'est pas parfaite, mais c'est bien assez bon dans 99% des cas.
Je me demande a quoi sert cette phrase en fait. Pourquoi dénigrer les autres langages (surtout en intro, ça ne donne pas envie)? Rust n'a-t-il donc pas assez de qualités?
[^] # Re: Précision : Microsoft ne vend plus le Kinect depuis 2017
Posté par freem . En réponse à la dépêche Robot humanoïde libre français : InMoov. Évalué à 4.
En meme temps le projet est de 2011, avec plusieurs presentations depuis, selon wiki la derniere est de 2016.
Perso, je suis surtout curieux de la taille de la machine en photo, je n ai pas vu l'info. Je me demande aussi quelles sont les capacites des mains, cet aspect n'est pas du tout mis en avant par le peu que j'ai lu.
Le reste, la vision, la voix synthetique, etc, c'est cool aussi mais c'est juste du cpu et des libs au final. Je me permets meme de douter de l'ouverture des licences des-dites libs, sans la moindre preuve, je precise. Sinon, ca ne serai pas un doute.
# ben... clang-format, non?
Posté par freem . En réponse au message application de convention d'écriture. Évalué à 2.
Tout est dans le titre.
Utilises clang-format pour générer un code formatté correctement à partir du code a ajouter, fais un diff, et si il y a des différences, tu envoies une erreur. Ensuite, tu places tout ça dans un pre-commit hook ainsi qu'un pre-merge (je suis plus sûr pour le 2nd, mais bref, le hook qui vérifie les patches avant de fusionner, parce que le pre-commit hook est malheureusement uniquement en local et n'est pas cloné à ma connaissance).
Je n'ai jamais utilisé cette technique avec clang-format, qui est sur ma TODO-list depuis perpette, mais j'ai fait exactement ça avec astyle, que j'utilise depuis avant la naissance de clang-format.
[^] # Re: key_mgmt=NONE
Posté par freem . En réponse au message connection wifi insecure. Évalué à 2.
Genial! Ca juste marche, merci. Je n ai pas pu tester encore la version iw, parce que par habitude, j ai installe wireless-tools…
bon ca marche parce que j ai une ip et acces au portail mitm, reste a demander la "cle" mais ca devrai le faire.
[^] # Re: on a le service qu'on paye.
Posté par freem . En réponse au journal La Poste ne distribue plus le courrier et le jette à la poubelle. Évalué à 6.
Contrairement a tes proches, la poste ou la sncf donnent du service a tout le monde (moyennant finances pour la sncf et le courrier pas electronique de la poste). Je doute que ca soit comparable.
[^] # Re: Je ne comprend pas
Posté par freem . En réponse au message connection wifi insecure. Évalué à 2. Dernière modification le 10 mai 2022 à 20:26.
Je pense tomber souvent sur des hotels sans wpa. De ma faible experience sur le sujet, ca semble la norme, en fait.
cela dis peut etre que c est du WPA sans pass, je suis incapable de faire le distinguo entre les deux
[^] # Re: Annonce!
Posté par freem . En réponse au journal Elon musk ouvrirait le code de tweeter ?. Évalué à 2. Dernière modification le 28 avril 2022 à 08:49.
Tout à fait.
En fait, tu remarqueras que je ne participle plus vraiment (je serais curieux de voir un histo de mes connexions récentes, pas sûr que ça soit techniquement possible ceci dit).
C'est à peine si je viens voir de temps en temps, en fait. Et je constate que le plus souvent, je me contente maintenant de survoler les titres des liens quand je m'ennuies, et éventuellement aller voir ce qu'ils s'en dit histoire de sourire. Les journaux, je les ignore de plus en plus.
Vu que j'ai pas grand chose à faire au taf en ce moment, je me suis loggué hier, mais je constate que je visite plus facilement (mais ne me suis pas loggué la bas depuis des mois, littéralement, possiblement des années je sais pas) developpez.com (qui pourtant a des contenus "journalistique" de qualité plus que douteuse, mais bon, ça occupe 2minutes).
Je ne vais pas continuer le hors sujet, ça n'a que peu (aucun en fait) d'intérêt.
Bref $WEBSITE_NAME, c'est un peu ce que les utilisateurs en font.
Je serais curieux de voir une liste des titres sur 12 mois, pour le coup. Pour les sujets, ça demande d'ouvrir la chose, donc plus d'efforts, pour peu d'intérêt au final (c'est vraiment une curiosité).
[^] # Re: Annonce!
Posté par freem . En réponse au journal Elon musk ouvrirait le code de tweeter ?. Évalué à 5.
hum…
Cet argument ne me frappe pas, je sais pas pourquoi…
Ah. Si. Je sais.
Parce que j'ai l'impression que la plupart des discussions causent de politique, bien souvent même pas liée au logiciel libre.
Je suppose que je me trompe, et je finirai donc dans les limbes du -10… ou pas, a chaque fois qu'on dis ça, on se trompe. Advienne que pourra, je m'en tape.
[^] # Re: D'un extrême à l'autre ?
Posté par freem . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 3.
C'est parce que tu prends la mauvaise fonte, avec du Comic sans MS, je suis sûr que ça serait moins compliqué, probablement pour ça que c'était tant utilisé quand les DVDs existaient pas encore.
Hop moi…
[^] # Re: Tu dois pas produire grand chose
Posté par freem . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 3.
Un truc que j'ai vécu.
Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est… bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework… bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.
[^] # Re: Cargo.lock affligeant
Posté par freem . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 4.
Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…
Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.
[^] # Re: Tentative de réponse
Posté par freem . En réponse au journal Effet de bords et PC sans OS ?. Évalué à 3.
Quid des sex-toys connectés, du coup?
[^] # Re: pardon, j'ai ri
Posté par freem . En réponse au journal Une CVE dans le compilateur rust. Évalué à 2.
Ce qui se fait d'ailleurs même pour des softs libres parfois.
[^] # Re: git?
Posté par freem . En réponse au journal Un réseau offline "delay-tolerant" avec NNCP. Évalué à 2.
Je suis, ou ai été, sûrement très con, mais en fait, la raison initiale qui m'a fait rejeter hg était… c'est en python. Et j'avais (et toujours en vrai) plus confiance dans les langages compilés qui ont, par défaut, un minimum d'analyse statique.
Je n'ai aucune opinion sur
hgen soit, et j'en ai entendu pas mal de bien.D'un autre côté, je suis content d'avoir fait confiance à un outil codé dans un langage standardisé ISO vue la transition «difficile» entre python 2&3.
Ceci n'est en revanche qu'un détail d'implem. Git commence a avoir un 2nd utilisateur
got, qui le rend d'autant plus crédible. À quand un autre outil de versionning assez fiables et simples sur le long terme pour avoir d'autres clients qui émergent (l'inverse du web)?[^] # Re: Empreinte environnementale
Posté par freem . En réponse au journal Forlater.email, un service pour lire plus tard. Évalué à 4. Dernière modification le 14 octobre 2021 à 11:41.
Ajoutes:
Et je pense que j'ai à peu près mon compte :p
Pour ajouter un peu de contenu, je pourrais par exemple parler de ma vieille machine, parfaitement fonctionnelle, "designed for windows millenium", que j'ai acquise avec 64Mo de RAM (j'ai réussi à trouver de quoi monter à presque 200Mo \o/).
Cette machine flambante neuve dispose même d'un lecteur de bande SCSI, la pointe de la modernité, je vous dit!
Elle marche parfaitement avec une Debian 9, mais je ne pourrais probablement pas la booter avec une debian 11.
Je soupçonne ce fait parce que la dernière fois que j'ai voulu booter une VM qui ait moins de 250Mo de ram, l'initrd faisait partir le système en couille: pas assez de RAM.
Après augmentation de quelques dizaines de megs, plus de problème, et la consommation mémoire mesurée au login était inférieure à 50Mo.
Les gros consommateurs individuels? Le noyau et, surtout, systemd-udevd (le seul composant systemd installé).
Autre chose, si je laissait faire les MàJ, elle finirait avec systemd, plutôt que runit.
Hors, systemd, la dernière fois que j'ai mesuré, avait (de mémoire, presque un an) une empreinte RSS de plus de 30Mio.
À comparer avec "runsvdir + ( runsv + svlogd ) * N + runit" qui ont, liés à glibc, environ 750Kio de RSS (en moyenne). Liés avec musl, ou liés statiquement (ou en utilisant leurs équivalents dans busybox-static), on tombe à 4Kio de RSS par process.
En gros, systemd a, il est vrai, très peu de coût RSS par daemon géré (non mesurable, en fait), mais un coût initial énorme, alors que runit à un faible coût initial, et un gros coût par daemon (entre 8Kio et 1.5Mio, selon qu'on utilise glibc en dynamique ou non). La conclusion, c'est qu'il faut un nombre de daemon élevé (entre 20 et 7500, selon que glibc ou pas) pour que systemd soit à égalité avec runit de ce point de vue.
Sur une machine qui a moins de 200Mio, ça compte. Bon, en pratique, cette machine permets toujours de communiquer via IRC, mails, de faire de la bureautique… les seuls trucs qu'elle ne peut plus faire, c'est accéder au «web moderne» et lancer des jeux (encore que, de mémoire, j'arrivais a y faire tourner wesnoth), donc ça reste une machine d'appoint, au cas ou ma machine de tous les jours soit détruite (ou celle de quelqu'un d'autre, c'est déjà arrivé que je la prête, il avait fallu que j'installe LXDE, c'était amusant aussi ça, tiens).
On peut aussi parler, évidemment, d'ÉtronJS, qui embarque chromium dans chaque «application». Je ne ferai l'insulte a personne de développer ce point sur un point de vue écologique.
En fait, je pense que, bon, pourquoi pas… pour faire un PoC, un prototype, ça peut le faire, mais pour de la prod (en plus ça plante si facilement… je ne compte plus les SIGILL dans mes dmesg, quasi systématiquement liés à ce truc)?
J'ai pris systemd comme example, un peu pour le troll, mais aussi parce que j'ai effectivement mesuré, mais ça s'applique évidemment (et beaucoup mieux) à de nombreux autres logiciels: transmission consomme ~60Mio de RSS, contre le double pour qbittorrent, pour prendre un exemple récemment vu. Kiwix-desktop est un monstre (près de 180Mo), qui ne fait pourtant quasiment que la même chose qu'un serveur HTTP…