Je ne sais pas à qui la faute, et franchement je m'en moque. Quelque part, ça me semble pertinent de ne pas appeler apache httpd, puisqu'on pourrait imaginer installer plusieurs httpd sur la même machine.
Mais ils auraient pu utiliser le système d'alternatives (comme pour les éditeurs de texte, émulateurs de terminal, etc) pour fournir un lien symbolique vers le fichier qui va bien.
Ça aurait permis une meilleure généricité, non? Mais je suppose qu'il doit y avoir une raison.
Ce n'est pas faux. Du coup, tu utilises quels outils classiques pour modifier de la conf xml/json? Parce que sed, grep, cut & co, ça me paraît difficilement adapté?
Bien entendu, je n'ai exécuté en pas à pas que quelques itérations, pour l'exemple. Donc, problème résolu?
À noter tout de même pour l'honnêteté intellectuelle, il me semblait qu'il fallait faire appel à des trucs plus retors (à l'époque ou j'utilisais C::B, il me semble qu'il y avait besoin de faire appel à du python. Je n'ai jamais creusé la question ceci dit…), il y à quelques mois. J'imagine que ça ne fonctionne que sur des versions un minimum récentes de gdb donc.
"On doit", contre des "exemples concrets"…
Donnes-moi un outil concret qui accepte ton truc et compile?
Enfin, admettons. Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?
Dans ce cas, vraiment, on à des goûts différents et je doute qu'on puisse se convaincre l'un l'autre.
Quant au format… je vois ton truc, j'ai peur. Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde. Mais nul doute que ton usine à gaz outil qui interprète ça te fournira tout ce dont tu as besoin je suppose?
Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).
Idem, "-DPLUMA_EXPORTS" n'à rien de standard.
Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).
Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé… (aptitude est un exemple).
D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure… je ne vois pas pourquoi ça le serait.
Un truc genre (syntaxe à l'arrache):
Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:
Parceque le langage ou plus exactement les extensions de GCC avaient évolué.
D'où l'intérêt de ne pas utiliser d'extensions. Si ces langages (C et C++) se tapent des procédures assez longues, c'est qu'il doit bien y avoir une raison autre que faire chier à rester immobile, non?
Je serai curieux de savoir combien de codes sources C/C++ d'il y a 10 ans compilent encore avec les compilateurs d'aujourd'hui (y compris les révisions de GCC).
Je serai curieux de savoir combien de codes sources C/C++ standards d'il y à 10 ans ne compilent plus avec un compilateur qui supporte le standard de l'époque (aka: c++98* ou c++03. On à aussi le -ansi.), et donc qui respecte le standard de cette époque. Je ne sais plus laquelle…) récent.
Évidemment, il faut alors se "résoudre" à utiliser les flags qui forcent l'utilisation d'un standard, sinon c'est s'exposer aux emmerdes…
*:
Attention tout de même au standard 98, qui intègre de mémoire une fonctionnalité tellement à la con qu'il n'y à que commeau à l'avoir implémentée --ils avaient d'ailleurs fortement conseillé aux autres de ne pas le faire, la feature en question ayant coûté un refacto massif pour un usage très… parcellaire.-- je ne pourrai pas citer le nom exact de la feature en question: je n'ai appris mes premières notion de C que bien après 98… et donc je ne m'en suis jamais servi.
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite.
Naturellement que les choses peuvent bouger. Et ça ne me pose même pas de problème, en soit. Le problème que les gesticulations de systemd me pose, en fait, c'est qu'il s'agit d'un élément central du système (du moins, il souhaite le devenir, et semble y parvenir…), et que donc on peut légitimement je pense, craindre pour le reste du système du même coup.
Python est, ma foi, un excellent exemple. On m'a parlé d'un code python 2.7 qui ne pouvait être exécuté par un interpréteur 2.8. Pour une version majeure, je peux le comprendre hein, pas de souci, parfois il faut savoir péter les API. Mais habituellement, le numéro de version mineur d'un outil est quand même censé être une garantie qu'un interpréteur plus récent pourra digérer de la même façon si ce n'est mieux un code plus ancien que lui (raisonnablement, on parle d'une différence d'une version mineure ici).
Bien sûr, il n'y à pas que python, si j'en crois apt, lsof dépend soit de perl < 5.12.3 (sur ma machine actuelle) soit de libperl4-corelibs-perl. Au moins pour perl, il y à une lib de compat… maintenant, pour me convaincre que c'est une bonne chose, que de casser la compat descendante, ça risque de ne pas être simple.
Oh, et, bien sûr, dans le cas de python/perl/langage-X il est souvent possible d'installer plusieurs fois l'interpréteur/compilateur/whatever. Dans le cas de systemd, j'ai un gros doute?
Il y en a d'autres. Par exemple, splunk.
J'ai précisé que je ne connaissais que celui de windows… savoir qu'il en existe des exploitables est une excellente nouvelle!
Je n'en connaissais aucune, mais c'est une excellente question, qui mène à ceci:
Compatibility with Windows and Macintosh[edit]
ext4 does not yet have as much support as ext2 and ext3 on non-Linux operating systems. ext2 and ext3 have stable drivers such as Ext2IFS, which are not yet available for ext4. It is possible to create compatible ext4 filesystems for use in Windows by disabling the extents feature, and sometimes specifying an inode size.[20] Another option for using ext4 in Windows is to use Ext2Fsd,[21] an open-source driver that, like Ext2IFS, supports writing in ext4 partitions where extents have been disabled. Viewing and copying files from ext4 to Windows, even with extents enabled, is also possible with the Ext2Read software.[22] More recently Paragon released its ExtFS for Windows which allows read/write capabilities for ext2/3/4.
Mac OS X has full ext2/3/4 read/write capability through the Paragon ExtFS [23] software, which is a commercial product. Free software such as ext4fuse has only read-only support with limited functionality.
Donc, il semble qu'il en existe d'autre, sur d'autres OS.
Accessoirement, il me semble avoir lu qu'il est possible de lire de l'ext4 (jamais testé cependant) en mode dégradé avec des outils lisant ses prédécesseurs? (question rélle)
Et pour finir, ext4 est nettement moins invasif. Je veux dire, quel que soit le système de fichiers de mes partoches, je ne crois pas qu'un seul outil s'en apercevra, sauf ceux dédiés à la gestion des FS.
PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable).
Serait-ce lié au fait que tous les outils dont tu parles interprètent (et donc compilent en JIT) un fichier? Firefox interprète JS, python les .py, mono les je-ne-sais-quoi (.exe?)… avec java, ça donne quoi, même combat?
Il n'existe, à ma connaissance, aucune protection contre ça.
Lancer un serveur X par application :D Je déconne, mais en fait, il y à wayland qui, en théorie, est protégé contre ce problème (c'est un de leurs arguments massue en fait, mais je parle de théorie parce que je n'ai pas vérifié…).
L'équivalent Visual Studio (et il n'y à que le vcxproj, et je n'ai pas viré les sections pour les divers builds comme j'ai fait pour C::B, pour cause de non masochisme):
Je trouve effectivement que Makefile, c'est horrible. Par contre, je trouve CMake très accessible, c'est d'ailleurs en corrigeant un CMakeLists.txt de quelques centaines de ligne en moins de 15 minutes pour générer un .deb, sans le connaître au préalable (juste de nom), que je l'ai adopté.
l'assert est dégagé quand on livre. Contrairement aux exceptions, qui me permettent de logguer avant de crasher fermer violemment en désallouant les éventuelles ressources. Dans certains cas (les std::logic_error et ses filles) ce n'est pas très pertinent, mais quand il s'agit de se fermer après constat d'une erreur dans l'environnement (un fichier vital non trouvé, une entrée "utilisateur" --soyons d'accord: l'utilisateur n'est pas toujours humain…-- foireuse, ce genre de trucs) je trouve plus clair de juste lancer une exception avec un message potable (pour la logguer, c'est assez simple, il suffit de dériver une classe de std::exception, qui loggue automatiquement) que de faire un appel à une fonction pour logguer puis un autre à exit.
le message d'erreur d'une exception est à la possibilité d'être plus parlant. Bon, j'imagine qu'on peut aussi écrire une fonction avec le nom super long et qui renvoie true/false, pour l'emploi dans un assert, mais ça me semble un poil plus pénible.
on peut éventuellement récupérer d'une exception (c'est dégueu, selon moi, mais on me demande parfois de faire de la programmation défensive… à mon corps défendant :/)
Entendons nous bien, encore une fois: quand je lance une exception, ce n'est pas pour que mon programme survive, je ne m'en sers pas comme d'un switch dégueu. Je ne me sers des exceptions que signaler que le programme ne peux plus continuer, et sauver ce qui peut l'être le cas échéant.
Par exemple, imagines un IDE qui, pour une raison ou une autre, à un bug. Si, plutôt qu'utiliser des assert qui imposeront à l'utilisateur d'utiliser un outil en mode déboguage, et donc lent, afin d'avoir des messages d'erreur et qui en plus impliqueront la perte de toutes les données, le développeur utilises des exceptions, alors l'utilisateur peut utiliser une version non débug (plus rapide, moins lourde), avoir un message d'erreur, et en plus récupérer son travail dans l'état juste avant l'anomalie. Ça (peut) évite(r) des sauvegardes automatiques toutes les N minutes, qui seront plus coûteuses.
Après, je t'avoue, je ne maîtrise pas gdb, loin de là (ça ne fait pas longtemps que j'ai abandonné les IDEs) donc c'est possible que ce soit plus intéressant. Mais je viens de faire un test basique, et je ne vois aucun fichier core généré. Tu utilises quoi comme options de compilation (outre le -g, évidemment)?
utilise un simple fichier de configuration (basé sur un format très connu comme json ou xml)
On à des définitions différentes pour deux choses.
1) simple fichier de configuration
2) idéal
Désolé, mais, vraiment, pour être idéal un "simple fichier de configuration" doit être facilement lisible et modifiable par un humain. Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.
Je dirais même plus, les outils basés sur du xml pour la config, me hérissent le poil, et pas juste par principe. J'utilisais un IDE dans le passé. J'en ai même utilisé plus d'un… les uns avec des formats proprios (mais "lisibles" avec un éditeur de texte, les autres avec des formats genre xml/json justement… et force m'est de constater que dès que l'on à plus envie de subir /que l'on ne peut plus utiliser une IHM graphique GTK/Qt/MFC/Whatever, ces choses sont horribles à gérer.
Je ne parlerai même pas de versionner ou differ ce genre d'horreur…
Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.
Ça évite aussi de se taper des bugs très pénibles sans pouvoir changer le composant en un minimum d'efforts, quand ça arrive. Mais c'est vrai que ça nécessite un peu plus de travail pour mettre en place ses outils.
Posté par freem .
En réponse au journal Retour aux sources.
Évalué à 3.
Dernière modification le 29 septembre 2014 à 12:16.
Considérant ça, printf ou un débugger c'est un peu pareil.
Non, un débogueur ne te force pas à recompiler. C'est important quand tu utilises des libs assez lourdes. Et un printf ne te permets pas de lister l'ensemble de l'état de ton programme, et encore moins de revenir en arrière. Choses qu'un dbg te permets.
Mais ça, qu'il soit en ligne de commande (gdb), en ncurses (cgdb), ou graphique (visual, ddd, ollydbg…) ils peuvent tous le faire.
Posté par freem .
En réponse au journal Retour aux sources.
Évalué à 4.
Dernière modification le 29 septembre 2014 à 12:13.
Euh, et sinon, je me permets de rappeler que j'ai écrit cgdb. C'est, franchement, un peu moins inconfortable que gdb, surtout quand on ne connaît ce dernier que de nom. Maintenant, je pourrai m'en sortir un peu, et cgdb reste primitif, mais bon, on fait avec ce qu'on à.
Il existe aussi ddd, plus complet, plus gros, graphique, mais à mon goût dur à prendre en main. Aucun d'eux ne vaut visual studio, qui lui-même n'égale pas vraiment ollydbg (qui, de mémoire, peut afficher le source). Je pourrais également citer quelques ancêtres mais ce serait abusé: windasm, et dans une autre catégorie, softice. Mais ces ancêtres n'ont pas vraiment une IHM des plus modernes…
À mon avis, si linux possède moins d'IHM sympa pour les débuggueurs, c'est pour une raison simple: moins de programmes à reverser (que ce soit pour une raison légale ou pas n'est pas la question) du fait que bien souvent, on à les sources ou ils n'ont pas de prix.
Posté par freem .
En réponse au journal Retour aux sources.
Évalué à 4.
Dernière modification le 29 septembre 2014 à 12:05.
Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.
Et pour ce qui est des structures imbriquées, j'utilise un outil nommé: typedef. Comme ça, c'est tout de suite 1) plus simple à lire et 2) plus court à taper.
Et pour l'auto-complétion, vim s'en sort pas trop mal, excepté c'est vrai, quand j'utilise un framework lourd que je ne connait pas assez. Mais c'est assez rare, et en plus isolé dans une seule "couche" de l'application.
Bon, ça à aussi des avantages niveau ergonomie, si je combine mes terminaux avec un tiling window manager. En fait, sans cet outil, je ne supporterai pas ce mode de fonctionnement et j'utiliserai effectivement un IDE. Mais grâce aux twm, l'IDE c'est mon bureau, et je ne connais pas mieux qu'un twm pour gérer du multi-screen ou pour se passer de la souris, qui est, selon moi, un véritable instrument de torture: c'est lent, peu précis, ça sert à pointer des interfaces qui risquent de changer à la moindre MaJ, et ça nécessite de lâcher le clavier (et les claviers modernes ayant ce foutu pavé numérique, le mouvement de bras n'est pas court).
Perso, c'est quand je passe sur un IDE que je me sens handicapé. Ou avec un gestionnaire de fenêtres classique. Et pourtant, je ne qualifie pas les gens qui s'en servent au quotidien de rétrogrades et non-productifs: j'accepte qu'ils aient une façon de faire différente de la mienne, sûrement plus efficace sur certains points (c'est clair, pour construire une boîte de dialogue, je suis assez emmerdé… par contre, pour switcher entre git, mon source, pondre un script rapide pour tester un truc ou deux, et autres, je pense que ma façon de faire n'est pas mauvaise.
[edit]
Ceci étant dit, il faut admettre que visual à un debugguer qui gère un max.
Bah, les .h(pp) sont inclus plusieurs fois, si tu utilises plusieurs fichiers c(pp) qui l'incluent, ton header sera inclus plusieurs fois (pour un projet donné), et c'est d'ailleurs la principale cause des lenteurs de compilation C++.
Je ne suis pas complètement d'accord (mais en grande partie quand même).
La POO est un vrai paradigme, dans le sens ou le raisonnement est différent de la programmation modulaire plus classique du C (par exemple).
Maintenant, je ne crois pas avoir vu un seul langage réellement OO, et ce, ne serait-ce que parce que de prime abord, l'OS appelle une fonction, et lui passe une liste de chaînes de caractères.
En Java, par exemple, ils utilisent une classe avec une méthode statique pour ça. Pas très pur objet, pas vrai? Si on voulait qu'un langage puisse être réellement pur objet (mais quel intérêt, sérieux?) il faudrait que lors de l'appel du programme on ait une API prédéfinie, genre une classe (et pas une méthode) main, que l'OS instancie en appelant le constructeur, puis dont il appelle une méthode précise (et pas une fonction, comme c'est le cas en Java, parce qu'une méthode statique, c'est bien plus proche d'une fonction dans un namespace, que d'une méthode), et qu'enfin l'OS dés-instancie en passant par le destructeur.
Mais franchement, quel intérêt ça aurait? Les langages "pur objet" me font bien rire, et la façon de faire du C++ (et de bien d'autres langages "bâtards" je pense) est à mon avis la bonne: exposer un certain nombre de façon de programmer, et laisser l'utilisateur faire son truc comme il le veut, en fonction de la situation.
Perso, rien jusqu'a présent n'a réussi à me convaincre que respecter un seul paradigme dans un programme est la meilleure chose à faire pour que le programme soit clair et efficace. C'est même le contraire.
Je te suggère donc un patch, si tu dépends d'une version particulière de boost: find_package(Boost $BOOST_VERSION COMPONENTS $BOOST_COMPONENTS REQUIRED) ;)
[^] # Re: Surprenant, non ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
Qu'est-ce qui te force à utiliser udev?
[^] # Re: Surprenant, non ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 1.
Je ne sais pas à qui la faute, et franchement je m'en moque. Quelque part, ça me semble pertinent de ne pas appeler apache httpd, puisqu'on pourrait imaginer installer plusieurs httpd sur la même machine.
Mais ils auraient pu utiliser le système d'alternatives (comme pour les éditeurs de texte, émulateurs de terminal, etc) pour fournir un lien symbolique vers le fichier qui va bien.
Ça aurait permis une meilleure généricité, non? Mais je suppose qu'il doit y avoir une raison.
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Ce n'est pas faux. Du coup, tu utilises quels outils classiques pour modifier de la conf xml/json? Parce que sed, grep, cut & co, ça me paraît difficilement adapté?
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 5.
Chez moi ça marche.
Source:
Sortie de gdb (enfin, cgdb, mais c'est juste un frontend):
Bien entendu, je n'ai exécuté en pas à pas que quelques itérations, pour l'exemple. Donc, problème résolu?
À noter tout de même pour l'honnêteté intellectuelle, il me semblait qu'il fallait faire appel à des trucs plus retors (à l'époque ou j'utilisais C::B, il me semble qu'il y avait besoin de faire appel à du python. Je n'ai jamais creusé la question ceci dit…), il y à quelques mois. J'imagine que ça ne fonctionne que sur des versions un minimum récentes de gdb donc.
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 3.
"On doit", contre des "exemples concrets"…
Donnes-moi un outil concret qui accepte ton truc et compile?
Enfin, admettons. Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?
Dans ce cas, vraiment, on à des goûts différents et je doute qu'on puisse se convaincre l'un l'autre.
Quant au format… je vois ton truc, j'ai peur. Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde. Mais nul doute que ton
usine à gazoutil qui interprète ça te fournira tout ce dont tu as besoin je suppose?[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).
Idem, "-DPLUMA_EXPORTS" n'à rien de standard.
Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).
Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé… (aptitude est un exemple).
D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure… je ne vois pas pourquoi ça le serait.
Un truc genre (syntaxe à l'arrache):
Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:
Alors, ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
D'où l'intérêt de ne pas utiliser d'extensions. Si ces langages (C et C++) se tapent des procédures assez longues, c'est qu'il doit bien y avoir une raison autre que faire chier à rester immobile, non?
Je serai curieux de savoir combien de codes sources C/C++ standards d'il y à 10 ans ne compilent plus avec un compilateur qui supporte le standard de l'époque (aka: c++98* ou c++03. On à aussi le -ansi.), et donc qui respecte le standard de cette époque. Je ne sais plus laquelle…) récent.
Évidemment, il faut alors se "résoudre" à utiliser les flags qui forcent l'utilisation d'un standard, sinon c'est s'exposer aux emmerdes…
*:
Attention tout de même au standard 98, qui intègre de mémoire une fonctionnalité tellement à la con qu'il n'y à que commeau à l'avoir implémentée --ils avaient d'ailleurs fortement conseillé aux autres de ne pas le faire, la feature en question ayant coûté un refacto massif pour un usage très… parcellaire.-- je ne pourrai pas citer le nom exact de la feature en question: je n'ai appris mes premières notion de C que bien après 98… et donc je ne m'en suis jamais servi.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 0.
Naturellement que les choses peuvent bouger. Et ça ne me pose même pas de problème, en soit. Le problème que les gesticulations de systemd me pose, en fait, c'est qu'il s'agit d'un élément central du système (du moins, il souhaite le devenir, et semble y parvenir…), et que donc on peut légitimement je pense, craindre pour le reste du système du même coup.
Python est, ma foi, un excellent exemple. On m'a parlé d'un code python 2.7 qui ne pouvait être exécuté par un interpréteur 2.8. Pour une version majeure, je peux le comprendre hein, pas de souci, parfois il faut savoir péter les API. Mais habituellement, le numéro de version mineur d'un outil est quand même censé être une garantie qu'un interpréteur plus récent pourra digérer de la même façon si ce n'est mieux un code plus ancien que lui (raisonnablement, on parle d'une différence d'une version mineure ici).
Bien sûr, il n'y à pas que python, si j'en crois apt, lsof dépend soit de perl < 5.12.3 (sur ma machine actuelle) soit de libperl4-corelibs-perl. Au moins pour perl, il y à une lib de compat… maintenant, pour me convaincre que c'est une bonne chose, que de casser la compat descendante, ça risque de ne pas être simple.
Oh, et, bien sûr, dans le cas de python/perl/langage-X il est souvent possible d'installer plusieurs fois l'interpréteur/compilateur/whatever. Dans le cas de systemd, j'ai un gros doute?
J'ai précisé que je ne connaissais que celui de windows… savoir qu'il en existe des exploitables est une excellente nouvelle!
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Je n'en connaissais aucune, mais c'est une excellente question, qui mène à ceci:
Donc, il semble qu'il en existe d'autre, sur d'autres OS.
Accessoirement, il me semble avoir lu qu'il est possible de lire de l'ext4 (jamais testé cependant) en mode dégradé avec des outils lisant ses prédécesseurs? (question rélle)
Et pour finir, ext4 est nettement moins invasif. Je veux dire, quel que soit le système de fichiers de mes partoches, je ne crois pas qu'un seul outil s'en apercevra, sauf ceux dédiés à la gestion des FS.
[^] # Re: grsecurity
Posté par freem . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 2.
Serait-ce lié au fait que tous les outils dont tu parles interprètent (et donc compilent en JIT) un fichier? Firefox interprète JS, python les .py, mono les je-ne-sais-quoi (.exe?)… avec java, ça donne quoi, même combat?
Lancer un serveur X par application :D Je déconne, mais en fait, il y à wayland qui, en théorie, est protégé contre ce problème (c'est un de leurs arguments massue en fait, mais je parle de théorie parce que je n'ai pas vérifié…).
En tout cas, merci pour ce message informatif.
[^] # Re: Non mais oh!
Posté par freem . En réponse au journal Le troll du jour. Évalué à 1.
Tout-à-fait, on devrait faire un front pour imposer une parité homme/femme/trans sur le postage de troll le vendredi!
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je connaissais bt, c'est juste le fichier core que je ne sais (savais? je verrai ça dans l'aprem) générer. Merci bien!
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Pour yaml, je ne sais pas, j'en ai vu vite fait sur wikipedia, je n'en sais pas plus, mais c'est vrai que ça me plaît vachement plus que les autres.
Bah, non, franchement.
Exemple XML réel (code::blocks):
L'équivalent Visual Studio (et il n'y à que le vcxproj, et je n'ai pas viré les sections pour les divers builds comme j'ai fait pour C::B, pour cause de non masochisme):
Et enfin, cmake:
PS: désolé pour le délai avant la réponse, j'ai voulu avoir un truc un peu plus concret…
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je trouve effectivement que Makefile, c'est horrible. Par contre, je trouve CMake très accessible, c'est d'ailleurs en corrigeant un CMakeLists.txt de quelques centaines de ligne en moins de 15 minutes pour générer un .deb, sans le connaître au préalable (juste de nom), que je l'ai adopté.
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je vois 3 différences avec l'assert:
crasherfermer violemment en désallouant les éventuelles ressources. Dans certains cas (les std::logic_error et ses filles) ce n'est pas très pertinent, mais quand il s'agit de se fermer après constat d'une erreur dans l'environnement (un fichier vital non trouvé, une entrée "utilisateur" --soyons d'accord: l'utilisateur n'est pas toujours humain…-- foireuse, ce genre de trucs) je trouve plus clair de juste lancer une exception avec un message potable (pour la logguer, c'est assez simple, il suffit de dériver une classe de std::exception, qui loggue automatiquement) que de faire un appel à une fonction pour logguer puis un autre à exit.està la possibilité d'être plus parlant. Bon, j'imagine qu'on peut aussi écrire une fonction avec le nom super long et qui renvoie true/false, pour l'emploi dans un assert, mais ça me semble un poil plus pénible.Entendons nous bien, encore une fois: quand je lance une exception, ce n'est pas pour que mon programme survive, je ne m'en sers pas comme d'un switch dégueu. Je ne me sers des exceptions que signaler que le programme ne peux plus continuer, et sauver ce qui peut l'être le cas échéant.
Par exemple, imagines un IDE qui, pour une raison ou une autre, à un bug. Si, plutôt qu'utiliser des assert qui imposeront à l'utilisateur d'utiliser un outil en mode déboguage, et donc lent, afin d'avoir des messages d'erreur et qui en plus impliqueront la perte de toutes les données, le développeur utilises des exceptions, alors l'utilisateur peut utiliser une version non débug (plus rapide, moins lourde), avoir un message d'erreur, et en plus récupérer son travail dans l'état juste avant l'anomalie. Ça (peut) évite(r) des sauvegardes automatiques toutes les N minutes, qui seront plus coûteuses.
Après, je t'avoue, je ne maîtrise pas gdb, loin de là (ça ne fait pas longtemps que j'ai abandonné les IDEs) donc c'est possible que ce soit plus intéressant. Mais je viens de faire un test basique, et je ne vois aucun fichier core généré. Tu utilises quoi comme options de compilation (outre le -g, évidemment)?
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
On à des définitions différentes pour deux choses.
1) simple fichier de configuration
2) idéal
Désolé, mais, vraiment, pour être idéal un "simple fichier de configuration" doit être facilement lisible et modifiable par un humain. Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.
Je dirais même plus, les outils basés sur du xml pour la config, me hérissent le poil, et pas juste par principe. J'utilisais un IDE dans le passé. J'en ai même utilisé plus d'un… les uns avec des formats proprios (mais "lisibles" avec un éditeur de texte, les autres avec des formats genre xml/json justement… et force m'est de constater que dès que l'on à plus envie de subir /que l'on ne peut plus utiliser une IHM graphique GTK/Qt/MFC/Whatever, ces choses sont horribles à gérer.
Je ne parlerai même pas de versionner ou differ ce genre d'horreur…
Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.
Ça évite aussi de se taper des bugs très pénibles sans pouvoir changer le composant en un minimum d'efforts, quand ça arrive. Mais c'est vrai que ça nécessite un peu plus de travail pour mettre en place ses outils.
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 3. Dernière modification le 29 septembre 2014 à 12:16.
Non, un débogueur ne te force pas à recompiler. C'est important quand tu utilises des libs assez lourdes. Et un printf ne te permets pas de lister l'ensemble de l'état de ton programme, et encore moins de revenir en arrière. Choses qu'un dbg te permets.
Mais ça, qu'il soit en ligne de commande (gdb), en ncurses (cgdb), ou graphique (visual, ddd, ollydbg…) ils peuvent tous le faire.
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 4. Dernière modification le 29 septembre 2014 à 12:13.
Euh, et sinon, je me permets de rappeler que j'ai écrit cgdb. C'est, franchement, un peu moins inconfortable que gdb, surtout quand on ne connaît ce dernier que de nom. Maintenant, je pourrai m'en sortir un peu, et cgdb reste primitif, mais bon, on fait avec ce qu'on à.
Il existe aussi ddd, plus complet, plus gros, graphique, mais à mon goût dur à prendre en main. Aucun d'eux ne vaut visual studio, qui lui-même n'égale pas vraiment ollydbg (qui, de mémoire, peut afficher le source). Je pourrais également citer quelques ancêtres mais ce serait abusé: windasm, et dans une autre catégorie, softice. Mais ces ancêtres n'ont pas vraiment une IHM des plus modernes…
À mon avis, si linux possède moins d'IHM sympa pour les débuggueurs, c'est pour une raison simple: moins de programmes à reverser (que ce soit pour une raison légale ou pas n'est pas la question) du fait que bien souvent, on à les sources ou ils n'ont pas de prix.
PS: si, j'ai un IDE, c'est mon DE ;)
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 4. Dernière modification le 29 septembre 2014 à 12:05.
Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.
Et pour ce qui est des structures imbriquées, j'utilise un outil nommé: typedef. Comme ça, c'est tout de suite 1) plus simple à lire et 2) plus court à taper.
Et pour l'auto-complétion, vim s'en sort pas trop mal, excepté c'est vrai, quand j'utilise un framework lourd que je ne connait pas assez. Mais c'est assez rare, et en plus isolé dans une seule "couche" de l'application.
Bon, ça à aussi des avantages niveau ergonomie, si je combine mes terminaux avec un tiling window manager. En fait, sans cet outil, je ne supporterai pas ce mode de fonctionnement et j'utiliserai effectivement un IDE. Mais grâce aux twm, l'IDE c'est mon bureau, et je ne connais pas mieux qu'un twm pour gérer du multi-screen ou pour se passer de la souris, qui est, selon moi, un véritable instrument de torture: c'est lent, peu précis, ça sert à pointer des interfaces qui risquent de changer à la moindre MaJ, et ça nécessite de lâcher le clavier (et les claviers modernes ayant ce foutu pavé numérique, le mouvement de bras n'est pas court).
Perso, c'est quand je passe sur un IDE que je me sens handicapé. Ou avec un gestionnaire de fenêtres classique. Et pourtant, je ne qualifie pas les gens qui s'en servent au quotidien de rétrogrades et non-productifs: j'accepte qu'ils aient une façon de faire différente de la mienne, sûrement plus efficace sur certains points (c'est clair, pour construire une boîte de dialogue, je suis assez emmerdé… par contre, pour switcher entre git, mon source, pondre un script rapide pour tester un truc ou deux, et autres, je pense que ma façon de faire n'est pas mauvaise.
[edit]
Ceci étant dit, il faut admettre que visual à un debugguer qui gère un max.
[^] # Re: plop
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Bah, les .h(pp) sont inclus plusieurs fois, si tu utilises plusieurs fichiers c(pp) qui l'incluent, ton header sera inclus plusieurs fois (pour un projet donné), et c'est d'ailleurs la principale cause des lenteurs de compilation C++.
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par freem . En réponse au journal Retour aux sources. Évalué à 4.
Je ne suis pas complètement d'accord (mais en grande partie quand même).
La POO est un vrai paradigme, dans le sens ou le raisonnement est différent de la programmation modulaire plus classique du C (par exemple).
Maintenant, je ne crois pas avoir vu un seul langage réellement OO, et ce, ne serait-ce que parce que de prime abord, l'OS appelle une fonction, et lui passe une liste de chaînes de caractères.
En Java, par exemple, ils utilisent une classe avec une méthode statique pour ça. Pas très pur objet, pas vrai? Si on voulait qu'un langage puisse être réellement pur objet (mais quel intérêt, sérieux?) il faudrait que lors de l'appel du programme on ait une API prédéfinie, genre une classe (et pas une méthode) main, que l'OS instancie en appelant le constructeur, puis dont il appelle une méthode précise (et pas une fonction, comme c'est le cas en Java, parce qu'une méthode statique, c'est bien plus proche d'une fonction dans un namespace, que d'une méthode), et qu'enfin l'OS dés-instancie en passant par le destructeur.
Mais franchement, quel intérêt ça aurait? Les langages "pur objet" me font bien rire, et la façon de faire du C++ (et de bien d'autres langages "bâtards" je pense) est à mon avis la bonne: exposer un certain nombre de façon de programmer, et laisser l'utilisateur faire son truc comme il le veut, en fonction de la situation.
Perso, rien jusqu'a présent n'a réussi à me convaincre que respecter un seul paradigme dans un programme est la meilleure chose à faire pour que le programme soit clair et efficace. C'est même le contraire.
[^] # Re: Trop gros, passera pas.
Posté par freem . En réponse au journal Retour aux sources. Évalué à 9.
Oui, elle n'est pas fermée comme une huître.
[^] # Re: Non mais oh!
Posté par freem . En réponse au journal Le troll du jour. Évalué à 5.
C'est triste ton avis sur sa volonté.
[^] # Re: Non mais oh!
Posté par freem . En réponse au journal Le troll du jour. Évalué à 3.
On dit pas nanique?
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Probable en effet: 1.49 ici.
Je te suggère donc un patch, si tu dépends d'une version particulière de boost:
find_package(Boost $BOOST_VERSION COMPONENTS $BOOST_COMPONENTS REQUIRED);)