freem a écrit 5019 commentaires

La seule chose que je dit, ce n'est pas qu'il est mal ou stupide ou quoique ce soit d'utiliser un outil externe. Juste, qu'on ne peux pas prétendre faire le boulot soi-même quand c'est un outil qui fait tout à notre place.

Dans le cas du compilo, il ne produit pas du C++, mais du code machine. Son utilisateur fait du C++, le compilo génère un binaire, en code machine. Pas en C++, ou en tout cas pas sur ma machine vu que le processeur ne saurait pas quoi en faire.

En fait, j'ai fini par faire des scripts shell pour placer à peu près. Ca bug à cause du temps, mais ça marchotte. Pour le coup, j'ai posé la question sur la ml d'i3 au sujet de comment résoudre ces bugs, et on m'a répondu que la prochaine version inclue un mécanisme de layout, qui résout donc ce manque de fonctionnalité.
A condition d'utiliser le dépôt git, bien entendu.

A voir, donc.

Mes parents ont croisé une personne sur l'autoroute qui ne pouvais pas redémarrer après avoir changé une roue, ou un truc du genre. Je ne me souviens pas exactement ce qu'ils m'ont dit, mais en gros, le fait est que l'ordinateur de bord nécessitait un coup de valise pour accepter le fait que la panne ait été réparée.

Bref, je ne suis pas sûr que ce soit borderline niveau code de la route: après tout, si la voiture refuse de démarrer si les phares ne marchent pas, et qu'il faut une valise pour faire comprendre à l'ordi de bord qu'ils ont été changés, il n'y a pas infraction au code.

Pour moi, demander à quelqu'un de monter une chaise, ce n'est pas monter une chaire.
De même, pour moi, utiliser un parseur n'est pas parser.

C'est sûr, utiliser une lib, c'est facile. Ou du moins devrait l'être, mais ce n'est pas faire le boulot de la lib. Surtout le vendredi :p

Et c'est aussi ce que propose le format texte fournit avec boost::serialization.

Il n'empêche que tu dois fatalement gérer la différence de version quelque part, dans ton code. Aucune lib ne peut le faire d'elle même.
Le point étant que, de toute façon, boost::serialization n'est pas un format, mais une lib générique permettant de (dé)sérialiser. Il peut utiliser divers formats, dont XML, plus ou moins indiféremment ( sauf que dans le cas d'xml ou json, il faut dans la méthode serialize() indiquer le noms des clés, forcément, chose qui n'est pas nécessaire dans le format texte brut offert par défaut ).

C'est peut-être juste le temps que la pilule passe et que gnome 3 s'améliore.

En même temps, dès que tu ajoutes ou supprimes des données importantes, peu importe la façon d'écrire/lire tes données, soit tu te cantonnes à l'ancien format qui sera donc limité ( pas de possibilités d'exploitation des nouveaux champs, et valeurs des champs supprimés perdues ), soit tu casses la compatibilité, soit tu implémentes un mécanisme de version, chose que boost::serialization fait, de mémoire, pas trop mal.

Et toi, tu fais comment dans ce type de cas ( question réelle, ce sujet m'intéresse ) ?

C'est sûr. Sauf que le modèle est quand même l'un des vrais points forts d'XML, donc, utiliser le fait que le parser ne soit pas trop compliqué en oblitérant une fonctionnalité phare pour dire que ce n'est pas si dur/long/whatever me paraît… douteux.

Sinon, si on parles du simple parsing ( en espérant ne pas me planter et ne pas en oublier trop ):
Il faut être capable de lier à , mais savoir que si on rencontre alors pas de balise fermante.
%XX génère un octet de valeur hexa XX.
%% génère un %.
&foobar; génère le caractère foobar.
" est un délimiteur. ' aussi. Ils peuvent être imbriqués de mémoire.

En terme de coût CPU, je trouve que c'est assez coûteux. Après, je ne nie pas que tous les langages ont des libs plus ou moins bien foutues pour le faire à notre place, mais ça ne veut pas dire que leur implémentation est triviale, surtout quand il y a un besoin de performances.
Un collègue à tenté d'utiliser je ne sais plus quel parseur php, le résultat était misérable en terme de perf, il à donc dû en implémenter un lui-même. Je gage que j'arriverais à faire bugguer le code en question sans trop de souci, en jouant sur les assertions non vérifiées.
Si cet outil php est lent, il doit bien y avoir une raison… ou juste peut-être que mon collègue s'en est mal servi, je n'en sais rien ( je n'étais pas dans la boîte à ce moment, donc je ne connaît pas tous les tenants et aboutissants ).

Excellent article, vraiment.

Il y a juste un point qui ne semble pas apparaître ( l'article est très instructif, mais long, donc j'ai dû accélérer "un peu" ma lecture… ) c'est la génération de lacs et de cours d'eau.

Je suppose qu'il est possible de définir manuellement ou aléatoirement des points de source pour les cours d'eau, et de faire ruisseler le dit cours d'eau en fonction de la pente ( il "suffirait" de regarder toutes les altitudes proches et de générer une érosion plus importante pour le point qui à l'altitude la moins élevée, et ce jusqu'à l'arrivée à un autre point d'eau: océan—niveau 0 --, autre cours d'eau, ou lac ) mais ce qui serait intéressant, ce serait d'être capable de générer des lacs quand le relief forme une cuve.

Peut-être en simulant une pluie:
Pour chaque point d'une zone, vérifier s'il est en contact avec un point plus bas non inondé, et si ce n'est pas le cas, inonder. En répétant l'opération N fois, on pourrait ainsi simuler une pluie de force N, j'imagine?
Du coup, on pourrait imaginer avoir une pluie de force suffisamment élevée pour dépasser le relief sur un point, qui formerait donc une source et génèrerait donc une rivière.

En fait, je n'ai aucune idée de la complexité de ce type de génération et de son implémentation potentielle, et je me demandais si tu as songé à ce détail lors de tes recherches et implémentations?

JSon est moins pire que XML, pour l'usage que la majorité des cas ou XML est utilisé ( c'est à dire sans validation du document ). A choisir entre la peste et le choléra…

Sinon, je préfère le whitespace au javascript, ça à l'avantage d'être reposant pour les yeux :)

En revanche, je le trouve pas si difficile que ça à parser (je n'ai touché du XML qu'en Python, donc peut-être que les autres langages s'en sortent moins bien, je ne sais guère).

Et ton parseur python, il vérifie la validité du document par rapport au DTD qui y est lié?
Ma question, elle revient à dire, est-ce que tu parses du XML standard, ou du XML allégé, comme la plupart des gens le font?

La raison, en gros:
endianness.

XML étant du texte ASCII allégé ( moins les caractères de contrôle, entres autres ), il est facile de déterminer l'endianness. Ajouter à ce point le fait qu'il soit possible de créer des fichiers pour vérifier l'intégrité des données ( DTD ) voire convertir à un sous-format différent, ainsi que le mécanisme de balises qui permets de vérifier un minimum d'intégrité sans le DTD, oui, ce format à des raisons d'être.

Mais, il s'agit d'un format ayant un rôle limité, et maintenant je suis à la limite d'avoir une réaction allergique quand on m'en parle, à force de le voir utilisé pour de la configuration ( apache, code::blocks, par exemple, mais je crois aussi que dbus s'en sert… sigh… ).

s/parfois/souvent

Du moins, souvent sur ma machine avec les logiciels que j'utilise. Pour la configuration.

Oui, parce qu'a mon avis, INI, c'est bien, c'est efficace… pour des config. C'est à dire des fichiers qu'il est agréable et utile de pouvoir modifier à la main, mais qui ont une volumétrie raisonnable.

Pour des fichiers de sauvegarde, je suis d'accord, ce n'est pas adapté. D'ailleurs, un format lisible par l'homme pour ce type d'utilisation ne me semble pas adapté non plus de façon générale. Les soucis étant que, les binaires, c'est pas versionnable, et en plus ça risque de péter en fonction de l'endianness.

Conclusion, j'utilise boost::serialization pour les sauvegardes de données, et boost::program_options pour la configuration ( ce qui me permets en plus de très aisément "configurer" mes outils en tapant la ligne de commande, et d'avoir un "--help" en 3 lignes de code. ).
Mais YAML n'est pas mal non plus :)

• La taille du fichier, on s'en fout pas mal, ça passe très très bien à la compression (c'est du texte très redondant)

Un fichier compressé, c'est un binaire. L'intérêt d'origine d'XML, c'est d'être utilisable sur un réseau sans trop en chier, chose que le texte ASCII ( sur 7 bits, donc ) fait très bien, contrairement au binaire.
Compresser un fichier XML, c'est un non-sens, parce qu'on perd l'un de ses intérêts principaux… mais tout le monde le fait, parce qu'XML c'est verbeux…
Dit autrement, compresser XML, c'est prouver qu'on à pas réfléchit avant d'utiliser d'XML.

• "Les devs ont la flemme d'écrire un parseur" -> "les devs ont l'intelligence de réutiliser des parseurs déja déboggués"

Ou alors, les devs se sont tapé l'écriture d'un parseur XML à la main et on la flemme d'en écrire un autre. Le fait que celui déjà écrit soit débogué est une assertion trompeuse, car les dev ne font pas tous ni toujours des tests unitaires couvrant à 100% leur code.

• La structure hiérarchique imposée par le xml permet de rationnaliser le stockage des données, à définir des noms de champs signifiants, etc.

Certes, mais XML est loin d'être le seul à définir des noms signifiants. En fait, INI le fait aussi. ( vendredi…)

Pour le reste, je te rejoins, oui, le problème c'est bien le dev qui choisit XML… ou plutôt le type qui écrit le cahier des charges du dev ( ça peut être le dev, mais pas toujours ).

Point sur lequel on est d'accord.

Le souci étant, que mettre d'accord des gens, ça prend du temps. Et la, on parle d'utilisateurs de vim, des "barbus" qui ont lutté contre "l'ennemi" emacs sur de nombre de forums, etc etc.
Bref, la moindre tentative d'uniformisation de vim risque d'aboutir à la naissance d'un nouveau standard, en plus d'être longue à mettre en place.

Ton commentaire était plutôt pertinent… jusqu'a cette ligne:

On ne juge pas sans preuve mais vous ne m'empêcherez pas de penser très fort que les grosses boites sont toujours les méchants de l'histoire…

Il faut arrêter de blaguer, la, hein. Peut-être qu'il y à eu un défaut, mais, j'ai un mal fou à imaginer un régulateur de vitesse monter tout seul à 200km/h, si le contact est coupé.

Il y a eu un bug, c'est certain. Reste à savoir où il se plaçait: entre le tableau de bord et la chaise, ou dans l'électronique?

D'un autre côté, l'article ( je n'ai pas lu les sources, j'avoue ) n'indique pas qu'il y ait eu tromperie. Tel que c'est formulé, ça me fait plutôt penser à de la négligence des organisme officiels censé autoriser ou refuser la mise en marché ( euh, ok, la formulation est pas top ).
Pour moi, accepter si on manque d'info, c'est exactement comme configurer un firewall pour qu'il ne refuse que certains paquets, et laisse tout passer par défaut, alors qu'un firewall efficace doit tout rejeter par défaut, et avoir quelques règles qui indiquent quels paquets doivent finalement être acceptés.

Autrement dit, selon moi, de la façon dont est tourné le journal, la faute est partagée entre Toyota pour le code de merde, et la NTHSA, qui aurait du rejeter la bagnole sous prétexte de ne pas avoir eu assez d'informations pour juger, prétexte tout à fait valable selon moi.
Après tout, je ne trouve pas normal de livrer du code impactant sur la vie et la mort des gens, sans livrer de tests unitaires corrects. Dans un tel cas, vraiment, j'insiste lourdement, les 2 organisations sont coupables!

Mais bon, le jugement final n'est ici pas indiqué, et j'ai la flemme de lire les sources, donc peut-être que les jurés en sont arrivé à la même conclusion que moi. J'en doute, cependant…

Effectivement.
D'ailleurs c'est pour ça qu'il n'y a jamais eu de mort… attends… de quoi parle cet article, au fait?

Moui, enfin, C++ est quand même le plus lent à évoluer. Pour faire court, selon wikipedia, en 18 ans, Java à fait l'objet de 8 versions ( qui ne soient pas des bugfix ), python en à une tous les 2 ans, quand C++ en est à sa 2nde version standard, 3 si on compte la bugfix de 03.
Avec le w3c, il ne s'agit pas de standard, mais de recommandations, si ma mémoire est bonne. Recommandations qui ne sont respectées complètement par presque aucun site de ma connaissance. En pourcentage, ça doit donner de l'ordre du 5%, peut-être même moins! ( je pense être très optimiste avec mon 5%… )
Et il ne s'agit pas d'un langage de programmation, mais de description. Quand vim se configure, lui, avec un langage de programmation.

D'un autre côté, je peux comprendre, et accepter, que C++ soit plus long à standardiser.
Je ne voudrais pas que la quantité passe avant la qualité, franchement, donc qu'il ne fasse pas comme Oracle et son Java ou python ou les révisions mineures semblent empêcher d'interpréter des codes faits avec la rev mineure précédente ( lu je ne sais plus où sur ce dlfp ). Ca me va très bien comme ça.
Mais des MaJ plus petites, tout aussi propres et plus fréquentes, ça me ferait bien plaisir tout de même. Il n'empêche, le fait qu'ils en annoncent 1 pour cette année, n'implique pas que les délais seront tenus. Les procédures pour un standard ISO sont certainement nettement plus complexes que d'attendre l'approbation d'Oracle ou attendre qu'une équipe de dev open source accepte une contribution, cas de python. On parle d'un organisme de standardisation international reconnu par de nombreux pays, après tout.
Maintenant, en C++11, on peut toujours compiler du code qui date de 98, je ne suis pas sûr que ce soit le cas de la majorité des autres langages.
A part le langage de config de vim, j'imagine :)

Oui. En même temps, ils avaient prévu de sortir C++11 avant 2010, d'où le nom du draft: C++0x.
Ceux qui inventent des excuses diront qu'on parle d'hexadécimal, mais j'ose espérer que personne n'est dupe.

Entre prévoir et faire, il y a une grande différence.

Après, je suis d'accord: on parle de standard ISO, donc il faut faire les choses bien, ce qui peut prendre du temps. Mais bon, 13 ans ( standardisation en 98 selon wikipedia, bugfix en 03 ) pour une nouvelle version, en info, c'est long.
Mais bon, ça n'empêche pas ce langage d'être mon favori, vu qu'avec les fonctionnalités de base on peut faire déjà énormément, et au moins on a peu de choses qui deviennent obsolètes ( mais ça existe malgré tout, comme auto_ptr ).

Si linux n'était utilisé que par les programmeurs, android n'existerait pas.

Comme je le disais, le problème n'est pas le manque de fonctionnalités de vim, mais le fait que ces fonctionnalités ne sont pas présente à l'installation.

Pas moi qui l'ai dit, que vim manque de fonctionnalités :)

Enfin, si, mais je suis clairement persuadé qu'on peut le transformer en IDE complet… ce qui ne gommera pas ses défauts. Et pour les distrib de vim que tu cites, je ne les connaissais pas ( je n'y connais pas grand chose , il faut dire ), et je testerai. Sauf que… je doute qu'il y ait une intro simple à comprendre, ou qu'ils aient gommé les défauts de vim, dont la config complexe fait clairement partie. Selon moi, du moins.

Et quand on voit le temps que mets le comité C++ à se décider pour une nouvelle norme ( 8 ans pour C++11, si on considère la bugfix 03 comme une norme a part entière… que personne de mémoire n'a entièrement implémentée d'ailleurs ) je doute que ce soit une solution.
Qui plus est, comment trouver un système pour que ce que l'on utilise pas du standard ne coûte rien, comme en C++? ( ce qui n'est pas inclut ni demandé explicitement n'est pas utilisé en C++, donc pas payé. Exceptions, RTTI, ce genre de choses. On peut aussi les désactiver explicitement, mais en théorie ce n'est pas utile. J'ai bien dit théorie, hein? )

C'est sûr, c'est le genre de fonctionnalités qui me manquent personnellement, même sans les avoir essayées. J'ai pu voir des screen qui m'ont fait comprendre l'idée, rien de plus, mais… c'est séduisant tout de même.

Pour le coup, à part que ces layouts sont faits via lua, comment ça marche, en gros? Je me dis que quelque part, peut-être qu'avec des scripts exploitants les IPC d'i3… enfin, je ne sais pas, mais peut-être qu'il y aurait moyen de faire un truc qui sois moins pénible que refaire complètement le layout à chaque démarrage de la machine. Donc, comment qu'ils font, en face? ( parce que j'aime énormément l'idée du fichier de config simple, malgré tout… )

Je suppose qu'il est possible de créer un paquet dépendant de vim et des plug-in que tu souhaites, et les activant automatiquement.
C'est d'ailleurs exactement ce qu'eclipse fait, car sans plug-in cette usine à gaz ne fait juste rien.

Il faut juste trouvé un motivé qui ne craigne pas de récolter l'opprobe générale ( et ça part vite chez les barbus ;) ) en déterminant de façon totalement subjective et personnelle quels plug-ins liés à quelle configuration peuvent rendre vim aussi puissants qu'eclipse.

Sincèrement, si tu oses le faire je te soutien sans condition.

Ça, c'est génial! Merci beaucoup!!!

Oui, je sais, commentaire inutile, mais je tenais à te remercier.