Quel est l'intérêt ? De ce que j'en connais, Git est un logiciel de gestion de version ; or, dans la page dédié à fwtchrq, il y a les liens vers un dépôt Mercurial hébergé sur Savannah contenant les sources de fwtchrq…
L'ennui avec les noms de logiciels, comme avec les noms de domaines d'ailleurs, c'est que, si vous arrivez à en trouver un qui soit assez court, évocateur, joli (quoique l'on puisse entendre par ce terme ; la prononçabilité, par exemple), facile à retenir, etc., et bien, il y des chances que ce nom, ou une forme proche, soit déjà utilisé. Le risque existe alors d'avoir un jour à le changer, avec tous les désagréments que cela implique (modification de tous les documents comportant ce nom), sous peine de risquer un conflit avec une quelconque entité qui utilise un vocable qui présente, ne fût-ce que vaguement, des similitudes avec le nom en question pour désigner l'un de ses produits. C'est déjà arrivé à plus d'un logiciel.
Par ailleurs, je référence mes logiciels sur différents sites, à l'instar, par exemple, de xppq, qui est référencé sur Savannah et Freshcode, pour ne citer que ces deux-là. Pour pouvoir référencer son logiciel sur l'un de ses sites, il faut lui affecter un identifiant unique, et il est pratique alors d'utiliser le nom même du logiciel, comme cela est visible dans les URL ci-avant, plutôt que d'avoir à en trouver un autre, et à devoir se le rappeler, pour chaque site pour lequel cet identifiant est déjà utilisé.
fwtchrq n'est pas le premier logiciel (et, j'espère, pas le dernier non plus) libre que je développe. Et je n'ai pas envie, à chaque fois que j'entreprends de développer un nouveau logiciel, de perdre des heures à chercher un nom qui soit assez court, évocateur, joli, facile à retenir, etc., puis à devoir vérifier qu'il, ou une forme proche, ne soit pas déjà utilisé, découvrir qu'il l'est déjà et avoir à en chercher un autre je ne sais combien de fois, tout en n'ayant jamais la certitude d'avoir poussé mes recherches suffisamment loin pour avoir définitivement écartée l'épée de Damoclès.
Bref, les noms de mes logiciels semblent peut-être biscornus, mais c'est le prix à payer pour avoir une probabilité raisonnablement forte de n'avoir jamais à les changer…
J'ai implémenté un tel système dans mon framework ; j'en ai parlé dans ce journal.
Le système a un peu évolué depuis ; la courte description sur cette page est plus à jour.
L'implémentation en question n'est pas disponible en tant que bibliothèque dédiée, mais les sources étant accessibles, ça peut peut-être quand même être utile…
Je suis actuellement en train de développer une application web, ma première en AJAX, et j'ai bien entendu rencontré le problème des inputtime/date non implémentés, mais j'ai pu m'en accommoder. Par contre, il y a un autre bug, qui, lui, m'embête bien car je ne vois absolument pas comment le contourner. Et celui-là, en plus d'être apparemment au point mort (plus de trois ans sans nouveau commentaire !), est antédiluvien (il date de 2001 !). Donc, j'ai une application web qui tourne sur tous les navigateurs modernes (y compris Safari), sauf IE (pour autant qu'on puisse encore le qualifier de moderne), Edge (à priori à cause d'un bug qui lui fait exécuter, sans raison, un script en boucle, mais il devrait y avoir moyen de le contourner) et donc, hélas, Firefox…
Quand on achète un ordinateur avec Windows et des crapwares préinstallés, qu'on le reformate pour réinstaller Windows, évidemment sans les crapwares, ou pour installer un autre OS, n'est-ce pas comparable au fait d'aller sur un site web bardé de publicités avec un bloqueur de publicités ?
Je me faisais cette réflexion parce qu'il semble y avoir justement une prise de conscience de certains des acteurs de la publicité sur Internet de leurs abus dans le domaine, et ce suite à la généralisation des bloqueurs de publicités. Peut-être que les responsables des crapwares auront un jour une démarche similaire, pour autant qu'il soit concevable qu'il puisse exister des crapeware respectueux de l'utilisateur, tout comme des publicités non intrusives…
J'ai moi-même installé squirrelmail sur mon serveur, et cela n'a pas été sans mal, ceci pour dire que mes connaissances sont assez limitées dans le domaine, donc ce qui suit est peut-être erroné. Cependant, pour ce que je crois en avoir compris de son fonctionnement, mis à part si on lui demande d'afficher toute la liste des courriers d'une boîte et que ceux-ci soient vraiment nombreux, je ne vois pas trop pourquoi squirrelmail poserait problème, vu que ce n'est pas lui qui gère directement les courriers.
Avec certaines distributions GNU/Linux, le format de stockage de courriers est mbox par défaut, un format dans lequel plusieurs courriers sont stockés dans un seul et même fichier. Donc, avec une boîte mail de 1 Go, on peut se retrouver avec un fichier de la même taille contenant tous les courriers de cette boîte. On peut aisément imaginer que la manipulation d'un tel fichier, notamment pour accéder à un courrier en particulier, puisse prendre un certains temps.
En ce me qui concerne, le format mbox posait problème pour la sauvegarde des courriers. A chaque nouveau courrier qui arrivait dans ma boîte, je me retrouvais à devoir sauvegarder l'ensemble de tous les courriers, même ceux déjà sauvegardés, puisque tous étaient stockés dans un seul et même fichier (mes sauvegardes s'appuient sur rsync). C'est pour cela que je suis passé au format de stockage de courrier Maildir, avec lequel chaque courrier est stocké dans un fichier qui lui est propre, ce qui a évidemment résolu mon problème de sauvegarde. Maildir ou mbox, ce n'est pas squirrelmail qui gère cela, mais le serveur SMTP (enfin, je crois, et sans doute que le serveur IMAP doit aussi être configuré en conséquence). Face à un problème comme le tiens, je vérifierais d'abord le format de stockage des courriers, parce que si c'est mbox, il y a de fortes chances que le problème vienne de là, et changer de webmail ne le résoudrait en rien.
Il y a quelques années de cela, j'ai eu exactement le même problème avec une machine d'une connaissance fraîchement installée (la machine, pas la connaissance, encore qu'elle venait d'emménager) à partir des CD-ROMs officiels (je ne sais par contre plus de quelle version de Windows il s'agissait), et que j'avais directement branchée sur une box pour réaliser les mises à jour de sécurité. J'ai dû la reformater, la réinstaller totalement, et procéder aux mises à jour de sécurité en prenant soin de la connecter à Internet via mon serveur GNU/Linux, faisant office de pare-feu matériel, pour qu'elle soit fonctionnelle. Bref, il semblait que cette version de Windows, telle que fraîchement installée à partir des CD-ROMs, comportait des failles à l'affût desquelles de nombreux bots circulaient sur Internet, failles heureusement comblées par les mises à jour de sécurité, mais encore fallait-t-il pouvoir les installer avant que ces bots ne puissent entrer en action…
Ceci dit, cela me surprendrait qu'une version somme toute assez récente de Windows ne soit pas conçue pour faire face à ce genre de situation, et, qu'en outre, de nos jours, les dispositifs conçus pour offrir un accès à Internet ne soient pas, par défaut, configurés pour préserver les machines qui y sont connectées de ce genre de mésaventure, mais sait-on jamais…
Mon but n’est pas d'utiliser à tout prix des technologies web. Il se trouve que HTML5, typiquement une techno web, est un bon candidat pour remplacer XUL, que je voulais abandonner pour les raisons citées dans le journal. Par contre, j'utilisais déjà C++ avec XUL (alors que, tout comme avec HTML, l'usage est également d'utiliser JavaScript), et cela fonctionnait parfaitement, donc je n'avais aucune raison de passer à JavaScript.
C'est juste qu'avec HTML, je pouvais ajouter des éléments et attributs maisons (les fameux xdh-... et data-xdh-... du journal) qu'il était facile de traiter avec des outils DOM classiques, alors qu'avec le JSON-like de QML je ne pouvais pas (ou je n'ai pas trouvé comment) faire la même chose.
Au final, c'est surtout, comme indiqué à la fin du journal, la perspective de pouvoir avoir un seul et même code (C++ qui plus est) pour la version web et la version native d'une application qui m'a fait préférer HTML à Qt et consorts.
Les premières lignes de ce qui est devenu le frameworkEpeios datent d'il y a plus de quinze ans. Les domaines d'application de ce framework, et par conséquent le nombre de ligne qui le compose, n'ont cessé de s'accroître depuis. Rédiger la documentation correspondante représenterait une tâche titanesque pour une personne seule, sans compter, le framework évoluant sans cesse, le temps qui serait nécessaire rien que pour la tenir à jour.
J'utilise quotidiennement ce framework, et cette absence de toute documentation ne m'a jamais dérangé (le fait que c'est moi qui l'ai développé n'y est sans doute pas étranger), aussi préfère-je consacrer mon temps au développement et à l'amélioration de ce framework, plutôt qu'à la rédaction d'une documentation qui ne me serait d'aucune utilité. Si je le mentionne systématiquement lorsque l'un de mes logiciels (c'est-à-dire tous) se base sur ce framework, c'est parce que cela a certaines implications pour le logiciel en question. Par exemple, cela implique qu'il soit multi-plateformes et multi-architectures, qu'il possède un mécanisme spécial de gestion des arguments, que j'ai décrit dans ce journal, lorsque c'est un utilitaire en ligne de commande, qu'il utilise une registry interne rempli par un fichier de configuration…
Ceci dit, il y a cela fort (fort) longtemps, j'avais écrit un début de documentation. J'en ai retrouvé la trace durant mes investigations à l'occasion de la rédaction de ce commentaire. Apparemment, j'en avais même écrit plusieurs versions (voir ici et ici). Je n'ai pas relu, donc je ne garantis rien quant au contenu…
Ce ne sont pas des acronymes, simplement des assemblages de quelques lettres issues de l'intitulé (anglais) du logiciel concerné. La dernière lettre n'a pas de signification particulière.
Par exemple, lorsque l'on travaille sur plusieurs partitions en même temps, on a tendance à les travailler dans un certain ordre, pour être sûr de n'en oublier aucune. Ce faisant, on risque de mettre en place une sorte de réflexe pavlovien.
Ainsi, supposons qu'après avoir travaillé une partition A, relativement facile, on travaille systématiquement la partition B, avec laquelle on rencontre des difficultés. Même si on ne se focalise pas sur ces difficultés, après avoir travaillé A, notre subconscient peut nous faire aborder la partition B de manière moins sereine, parce qu'il sait que la partition qui suit A est systématiquement plus difficile. Avec dpkq, comme les partitions ne se suivent pas dans le même ordre d'une session à l'autre, ce genre d'appréhension inconsciente ne peut se mettre en place.
D'autre part, les segments concernant les partitions que je rejoue régulièrement pour ne pas les oublier sont assez nombreux ; il me faut plusieurs jours pour en faire le tour. dpkq me permet de n'en oublier aucun, bien que je ne les joue jamais dans le même ordre, sachant que dpkq ne pioche jamais deux fois le même segment si tous les autres n'ont pas été piochés au moins une fois.
Quant aux fiches elle-mêmes, il faut savoir qu'une fois que j'ai déchiffré une pièce, je la connais par cœur, donc je ne recours plus qu'exceptionnellement à la partition. La fiche me montrant une image de la partition, avec les numéros des mesures à travailler dans le cadre de cette fiche, cela me suffit à me remémorer la partie à travailler (comme mentionné, je joue par cœur, donc sans l'inconfort d'avoir à suivre la partition sur la tablette). Si j'ai un trou de mémoire, la consultation de la fiche me permet généralement de le combler.
Au final, une fois travaillées, je peux ranger mes partitions, au lieu de les empiler sur mon piano/orgue pour les avoirs toujours à portée de main… D'un autre coté, si je n'ai que rarement besoin des partitions pour ces pièces, c'est aussi parce que dpkq me permet de me les remémorer de manière régulière, systématique et exhaustive…
Je n'étais pas réellement "passé" sous Linux à cette époque, puisque ma machine de travail était toujours sous Windows, mais j'avais installé Linux sur une de mes anciennes machines pour en faire un serveur Web. J'avais un temps envisagé d'y installer Windows NT, mais la machine en question n'était pas assez puissante. J'ai donc opté pour Linux, dont un ami possédait des CD's d'installation (InfoMagic), bien que je ne l'avais jamais utilisé auparavant (mais j'avais déjà eu affaire à des machines sous UNIX). A priori, l'installation s'est déroulé sans problème (du moins, je ne me souviens pas d'en avoir rencontrés), sachant que, mis à part les composants de base, la machine n'était équipée que d'une carte Ethernet (outre l'alimentation, le câble Ethernet était d'ailleurs le seul autre câble branché sur cette machine). Ainsi, grâce à Linux, et un arrangement avec mon FAI de l'époque qui m'a permis de bénéficier d'une IP fixe, j'ai pu auto-héberger mes premiers services Internet. C'était en 97.
De ce que je comprends, xppq est un transformateur XML, un peu comme xslt. Il utilise une partie de son code pour parser ses arguments.
Je ne dirais pas transformateur, dans la mesure où c'est une toute approche que XSLT, déjà par le fait que tout ce qui est relatif aux directives xpp est directement dans le fichier à traiter, et non pas dans un fichier à part, comme avec XSLT…
Je me demande par contre si "pp" veut dire "pull parser".
pp a la même signification dans xppq que dans cpp, à savoir PreProcessor. En fait, xppq est conçu pour être à XML ce que cpp est au C/C++.
De toute manière, je ne savais pas ce qu'est un pull parser, mais, pour ce que j'en ai compris, xppq implémente bien un parser de ce type…
Je suis d’accord, est-ce que ça remplace getopt ? J’ai aussi l’impression que ça veut reprendre la gestion des fichiers de conf en donnant une approche à la base de registre…
En effet, cela ne remplace pas seulement getopt, mais prend effectivement en charge la gestion des fichiers de configuration. C'est dû à l'utilisation du framewok Epeios, avec lequel le point d'entrée du logiciel n'est pas le classique main(...) ou équivalent (qui est en fait défini par le framework), mais une autre fonction, (SCLTOOLMain(...), en fait, pour des application en ligne de commande). Lorsque cette dernière est appelée, les fichiers de configurations sont déjà chargés, et les arguments de la ligne de commande sont déjà traités, la registry ayant été remplie en conséquence.
Bref, c’est flou.
Comme écrit précédemment (en fait dans un commentaire plus bas), la rédaction de documentation n'est, hélas, pas mon fort (c'est un métier)…
Si je comprend bien, tu poses xppq en « concurrent » de solutions comme getopt ou autre moyen de facilement gérer des paramètres en ligne de commande.
Pas tout à fait. xppq, c'est juste un préprocesseur XML. J'ai écris ce journal pour signaler que c'est le successeur de feu xppq, et j'en ai profité pour parler de ce nouveau système de gestion des arguments de la ligne de commande, car c'est le premier utilitaire que je publie qui l'implémente. Mais comme tous les autres utilitaires que je publierais seront, à l'instar de expp, basés sur le framework Epeios, ils implémenteront également ce système de gestion des arguments de la ligne de commande. xppq n'est pas plus lié à ce système que ne le seront ces autres utilitaires.
Ceci dit, j'ai effectivement codé ce système pour remplacer celui que j’avais précédemment codé et qui présentait de très fortes similitudes avec getopt. Dans ce sens, ce système peut effectivement être vu comme un concurrent à getopt.
Donc, c'est un outil (lib ?) plus à destination d'un développeur que d'un utilisateur, même si de par son design, l'utilisateur a la possibilité aussi de changer des trucs ?
Non, même pas. Pour l'instant, j'ai juste parlé de ce système pour le faire connaître, et j'en ai parlé en conjonction avec xppq pour mettre en évidence que ce n'est pas juste un concept, mais qu'il en existe bel et bien une implémentation fonctionnelle.
Actuellement, il n'existe pas de bibliothèque, en tant que telle, dédié à ce système. Ce système n'existe qu'en tant que fonctionnalité du framework Epeios. Mais il est bien entendu envisageable d'isoler le code dédié à ce système pour le mettre à disposition sous forme de bibliothèque indépendante. C'est en partie pour éventuellement susciter ce genre de démarche et pour en juger l'opportunité que ce journal a été écrit.
Et donc, ce fichier de configuration, il doit accompagné le logiciel distribué ? Il se situe où dans l'arborescence du système ? Chez l'utilisateur ou au niveau système ? Et le logiciel, il contient quoi comme type de code pour « utiliser » les paramètres ? Il dépend de ta lib ? C'est une lib ou pas en fait ? xppq est utilisé plutôt ? Comment il fait le lien avec le code du logiciel ? process c'est un exécutable classique ? qui dépend d'une lib xppq pour quand même lire les valeurs des arguments ?
Comme écrit plus haut, xppq n'est lié à ce système que parce qu'il est basé sur le framewok Epeios. En l'état, pour mettre en œuvre ce système de gestion des arguments de la ligne de commande, c’est tout le framework qu'il faut mettre en œuvre, ce qui implique une approche du développement en C++ (qui est le langage dans lequel est codé le framework Epeios) en particulier et du développement en général qui sort des sentiers battus.
Bon, tu vois, j'ai pas tout compris, c'est pas clair pour moi :)
Ça ne m’étonne pas ; je n'ai jamais été très doué pour écrire de la documentation…
Question bonus : pour moi la différence entre paramètre et argument, c'est que le paramètre c'est ce que tu déclare une fois pour toute en disant « ceci est un paramètre de mon programme » et un argument c'est une instantiation d'un paramètre dans une utilisation particulière : « j'appelle mon programme avec ceci comme argument (sous-entendu pour un paramètre particulier) ».
C'est comme ça que tu le vois ? J'ai l'impression que non puisque tu appelles « arguments » ce que tu mets dans le fichier de configuration alors que ce ne sont pas des arguments selon la définition que j'en ai… Ton avis ? :)
Mon emploi de l'un ou l'autre terme est plus une question de feeling que le fruit d'une véritable réflexion. Je pense que, pour l'idée que je m'en fais, ces deux termes sont assez interchangeables…
Juste pour préciser qu'une machine équipée d'un processeur sans VT-d n'est pas nécessairement impropre à faire tourner des VM. Ainsi, j'ai une machine animée par un i7-3770K (sans VT-d donc) sur laquelle VMware Player et Virtual Box tournent sans (presque) aucun problème…
Une machine équipée d'un i7-4770K, qui a des caractéristiques similaires à ceux du i7-3770K en termes de virtualisation, pourra donc probablement également faire tourner des VM…
C'est sous MS-DOS, pour ceux qui ne connaissent pas. Autant ln -s ne me pose aucun problème (il faut dire que je l'utilise souvent qu'avec un seul argument), autant je suis toujours obligé de m'y reprendre à plusieurs fois avec mklink pour trouver la bonne option à utiliser, bien que j'affiche systématiquement la page d'aide, ne fût-ce que pour retrouver le libellé des options…
Bon, ça ne va pas parler à grand monde, mais cet antagonisme Word/LaTeX me fait penser à un autre, celui de Finale/Lilypond.
Je n'ai jamais écrit de document pour LaTeX, mais, paraît-il, le langage de Lilypond est similaire à celui de LaTeX, et les logiciels du genre Finale s'apparenterait plutôt à Word, de par leur coté WISIWYG. Je mentionne Finale parce que je l'ai un temps utilisé, mais je pense que tout ce que j'écris à son propos dans ce texte pourrait s'appliquer à ses autres concurrents WISIWYG, comme Sibelius, par exemple.
Autre similarité. Pour ce que j'en sais, LaTeX se base sur TeX, ce dernier ayant été développé pour produire des documents de meilleures qualités (plus jolis) que ceux produits par les outils disponibles à l'époque de sa genèse. Or, Lilypond a été développé exactement pour la même raison. Lilypond, dont les auteurs avaient préalablement travaillé sur MusiXTeX, dont le but était de produire des partitions musicales en s'appuyant sur… TeX !
Ayant un temps utilisé Finale, je suis passé à Lilypond surtout à cause de la qualité des documents produits (qui n'ont absolument rien à envier aux partitions produits par les plus grandes maisons d'éditions), mais également, il me faut bien l'avouer, parce que Lilypond est gratuit.
Ceci dit, saisir une partition dans Lilypond est assez rébarbatif, cependant, à mon goût, bien moins que d'avoir à placer les notes sur une portée avec la souris (même s'il est possible d'utiliser un clavier MIDI, reste quand même la saisie des rythmes).
Pour rendre l'utilisation de Lilypond plus facile, j'ai développé un petit utilitaire avec lequel je saisis (à savoir à l'aide d'un clavier MIDI) d'une part la mélodie, sans tenir compte du rythme, puis j'ajoute le rythme, pour, au final, obtenir un fichier XML décrivant la mélodie et les rythmes associés. Ensuite, j'applique une transformation XSL sur ce XML, pour obtenir un fichier Lilypond, fichier que j'édite ensuite avec Frescobaldi (une surcouche à Lilypond), pour ajouter les nuances et autres annotations nécessaires.
Cette manière de travailler me convient parfaitement. Or, cela n'a été est rendu possible par le fait que le format Lilypond est du pur texte. Étant donné la nature du format des ses documents, ainsi que de ses fonctionnalités (du moins à l'époque quand je l'utilisais), je ne crois pas qu'il m'aurait été possible de mettre en place une méthodologie de travail similaire en utilisant Finale.
Il est clair que pour écrire une partition de quelques lignes, cela serait sans doute plus rapide avec Finale. Mais pour un projet un tant soi peu conséquent, Lilypond (en conjonction avec les outils cités ci-dessus) reste pour moi le logiciel le plus adapté, parce qu'offrant plus de souplesse, et me permettant ainsi d'être plus productif. Mais il paraît que certaines des plus grandes maisons d'éditions de partitions musicales utilisent Finale.
Si je devais émettre une hypothèse, ce serait que le problème des logiciels comme (La)Tex, ou Lilypond, c'est que les personnes les ayant développés l'ont fait avant tout pour eux-mêmes, pour répondre à leurs propres besoins. Or, le profil de ces personnes, notamment vu leurs antécédents de développeur (ce qui les a certainement poussé à utiliser un format texte), n'est de loin pas le plus répandu. Leur philosophie de travail, celles des outils qu'ils ont l'habitude d'utiliser, ne sont pas ceux de la majorité des utilisateurs auxquels sont destinés des produits comme Word ou Finale.
Il y a à peu prés 15 ans, comme je m'étais acheté un nouvel ordinateur, j'ai décidé de recycler mon ancienne machine en serveur internet. J'avais envisagé d'y installer Windows (NT 4.0 à l'époque, si je ne m'abuse), mais elle n'était pas assez puissante. C'est à cette occasion que j'ai installé ma première distribution GNU/Linux, que je connaissais déjà, mais que je n'avais jamais utilisé. Depuis, je n'ai jamais cessé de m'auto-héberger.
Il me semble que j'avais déjà quelques pages Web hébergées par mon FAI, et je me rappelle plus la raison pour laquelle j'ai décidé de mettre en ligne mon propre serveur Web, toujours est-il que j'avais développé peu après une application Web codée en C++, et qu'aucun FAI à l'époque (et de nos jours encore me semble-t-il) n'acceptait d'héberger une application codée en C++. Du coup, le fait d'avoir mon propre serveur internet m'a permis de mettre cette application en ligne.
J'ai connu quelques mésaventures, comme un piratage de mon serveur au travers d'une faille du serveur DNS. Depuis, je n'ai plus jamais installé de serveur DNS sur ma machine :-) (et je suis plus attentif aux alertes de sécurité de ma distribution). J'ai également perdu mon nom de domaine de l'époque, parce que l'adresse e-mail que j'avais donné comme adresse de contact pour mon domaine n'était plus valide au moment de le renouveler (bon, ce n'est pas directement lié au fait de m'auto-héberger, mais cela s'inscrivait quand même dans ce contexte). Mais sinon, mis à part la phase initiale d'installation, qui est certes chronophage, mais que je trouve sans difficultés particulières, je ne consacre que quelques minutes par semaine (généralement pour lancer les mises à jour suite à une alerte de sécurités) à la maintenance de mon serveur…
A l'époque, je ne pense pas qu'il y avait possibilité pour un particulier de louer un serveur dédié, du moins à un tarif raisonnable (je n'avais pas cherché non plus), donc je n'avais guère le choix. De nos jours, vu les tarifs, si je continue de m'auto-héberger, c'est plus par habitude que pour d'autres raisons, qu'elles soient financières, techniques ou autres…
En fait, j'avais regardé http://fr.wikipedia.org/wiki/CMake et m'était arrêté à : [CMake] est comparable au programme Make… (et cela correspondait à ce que je croyais savoir de CMake). Il est vrai que la description qui en est faite dans la suite de l'article présente de fortes similarités avec ce que réalisent mes scripts.
Ceci dit, l'avantage de ma démarche, c'est que je parvenais au résultat désiré juste en utilisant des outils qui n'étaient très familiers, et un fichier dont j'avais la maîtrise totale du contenu (modulo la structure due à l'utilisation de XML) et de sa signification. Mais ce qui est un avantage pour moi, parce que j'ai développé ces scripts, n'en serait pas un pour une tierce personne…
On peut trouver un exemple de 'Project.xml' à cette adresse : http://hg.savannah.gnu.org/hgweb/epeios/file/tip/tools/expp/CLI. Le Makefile situé à la même adresse a d'ailleurs été généré à partir de ce 'Project.xml'. On peut trouver d'autres 'Project.xml', et les Makefile correspondants, disséminés un peu partout dans ce même dépôt.
Les XSL ne sont par contre pas hébergés sur un dépôt.
D'après ce que j'en sais, cmake est similaire, dans son usage, à make, donc utilisé pour la compilation. Or, je ne lance pas mes scripts pour compiler le logiciel, mais pour générer les fichiers permettant cette compilation. La compilation proprement dite se fait à l'aide d'outils traditionnels (Visual Studio, make…). Donc, je ne pense pas que l'on puisse qualifier mes scripts de 'cmake-like'. Ils seraient plutôt, toutes proportions gardées, 'automake-like'.
Concernant Visual Studio, la dernière version est capable d'utiliser tel quel ou de convertir les fichiers issus de certaines précédentes versions. Cependant, j'ai modifié mes scripts lorsque j'ai changé de version, et ce ne devait pas être bien compliqué, car la seule chose dont je me souvienne, c'est d'avoir modifié le contenu de l'attribut qui semble correspondre à la version de Visual Studio. En tout cas, après modification de la valeur ce cet attribut ('ToolsVersion'), Visual Studio acceptait le fichier généré par mes scripts tel quel, sans demande de conversion.
Je n'ai jamais utilisé C::B…
Pour ma part, pour chacun de mes logiciels, j'écris un fichier XML, nommons-le 'Project.xml', dont c'est moi qui ai décidé de la signification des balises et attributs qu'il contient. Il y a ainsi quelques balises descriptives (nom du logiciel, numéro de version du logiciel, auteur…), et de nombreuses autres plus techniques (nom et localisation des fichiers sources, options de compilation…). Grâce à un ensemble de scripts et de fichiers XSL que j'ai développés, je génère, à partir de ce 'Project.xml', les fichiers '.vcxproj' et '.vcxproj.filters' qui permettent de compiler le logiciel à l'aide de Visual Studio, ainsi que le Makefile qui permet de compiler le logiciel sous Cygwin avec G++ et MinGW, ainsi que sous GNU/Linux et MacOS.
Lorsque je veux, par exemple, ajouter/enlever/modifier un option de compilation, je ne passe pas par l'interface de Visual Studio, ni ne modifie le Makefile, mais modifie uniquement 'Project.xml', puis relance les scripts pour régénérer les différents fichiers.
J'envisage, dans un futur proche, d'offrir la possibilité d'utiliser Clang sous Windows pour compiler les logiciels que je développe. Et bien, pour cela, il suffira que je modifie les scripts et les fichiers XSL, sans toucher aux différents 'Project.xml', pour que les Makefile générés prennent automatiquement en charge Clang. Pas besoin de modifier manuellement tous les Makefile pour cela.
Je gère ainsi chacun de mes projets à partir d'un seul et unique fichier 'Project.xml', dont j'ai la totale maîtrise du contenu, puisque qu'il n'est destiné à être traité que par des outils que j'ai moi-même développé. Bien entendu, il a fallu développer ces différents scripts et fichiers XSL, ce qui m'a pris au final bien moins de temps que je ne le pensais, ayant l'habitude de travailler avec XML/XSLT, mais depuis que ces dernier sont écrits, je n'ai plus eu à modifier de Makefile ou équivalent, ni à me replonger dans la documentation de Visual Studio, ou de GNU make, ou d'un quelconque autre outil similaire…
[^] # Re: Tu pourrais pas mettre un dépôt Git ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Publication de la première version de fwtchrq.. Évalué à 10.
Quel est l'intérêt ? De ce que j'en connais, Git est un logiciel de gestion de version ; or, dans la page dédié à fwtchrq, il y a les liens vers un dépôt Mercurial hébergé sur Savannah contenant les sources de fwtchrq…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Publication de la première version de fwtchrq.. Évalué à -2.
L'ennui avec les noms de logiciels, comme avec les noms de domaines d'ailleurs, c'est que, si vous arrivez à en trouver un qui soit assez court, évocateur, joli (quoique l'on puisse entendre par ce terme ; la prononçabilité, par exemple), facile à retenir, etc., et bien, il y des chances que ce nom, ou une forme proche, soit déjà utilisé. Le risque existe alors d'avoir un jour à le changer, avec tous les désagréments que cela implique (modification de tous les documents comportant ce nom), sous peine de risquer un conflit avec une quelconque entité qui utilise un vocable qui présente, ne fût-ce que vaguement, des similitudes avec le nom en question pour désigner l'un de ses produits. C'est déjà arrivé à plus d'un logiciel.
Par ailleurs, je référence mes logiciels sur différents sites, à l'instar, par exemple, de xppq, qui est référencé sur Savannah et Freshcode, pour ne citer que ces deux-là. Pour pouvoir référencer son logiciel sur l'un de ses sites, il faut lui affecter un identifiant unique, et il est pratique alors d'utiliser le nom même du logiciel, comme cela est visible dans les URL ci-avant, plutôt que d'avoir à en trouver un autre, et à devoir se le rappeler, pour chaque site pour lequel cet identifiant est déjà utilisé.
fwtchrq n'est pas le premier logiciel (et, j'espère, pas le dernier non plus) libre que je développe. Et je n'ai pas envie, à chaque fois que j'entreprends de développer un nouveau logiciel, de perdre des heures à chercher un nom qui soit assez court, évocateur, joli, facile à retenir, etc., puis à devoir vérifier qu'il, ou une forme proche, ne soit pas déjà utilisé, découvrir qu'il l'est déjà et avoir à en chercher un autre je ne sais combien de fois, tout en n'ayant jamais la certitude d'avoir poussé mes recherches suffisamment loin pour avoir définitivement écartée l'épée de Damoclès.
Bref, les noms de mes logiciels semblent peut-être biscornus, mais c'est le prix à payer pour avoir une probabilité raisonnablement forte de n'avoir jamais à les changer…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Ça peut peut-être aider...
Posté par Claude SIMON (site web personnel) . En réponse au message lib pour parser les options (command-line & config-file). Évalué à 1.
J'ai implémenté un tel système dans mon framework ; j'en ai parlé dans ce journal.
Le système a un peu évolué depuis ; la courte description sur cette page est plus à jour.
L'implémentation en question n'est pas disponible en tant que bibliothèque dédiée, mais les sources étant accessibles, ça peut peut-être quand même être utile…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Autre bug bien embêtant (du moins pour moi) non résolu...
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Firefox ? 42 !. Évalué à 1.
Je suis actuellement en train de développer une application web, ma première en AJAX, et j'ai bien entendu rencontré le problème des input time/date non implémentés, mais j'ai pu m'en accommoder. Par contre, il y a un autre bug, qui, lui, m'embête bien car je ne vois absolument pas comment le contourner. Et celui-là, en plus d'être apparemment au point mort (plus de trois ans sans nouveau commentaire !), est antédiluvien (il date de 2001 !). Donc, j'ai une application web qui tourne sur tous les navigateurs modernes (y compris Safari), sauf IE (pour autant qu'on puisse encore le qualifier de moderne), Edge (à priori à cause d'un bug qui lui fait exécuter, sans raison, un script en boucle, mais il devrait y avoir moyen de le contourner) et donc, hélas, Firefox…
« Smart IoT Crafting » : l'IoT pour tous
[^] # ...comme pour le web (commercial) ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Logiciels pré-installés : actualité. Évalué à 3.
Quand on achète un ordinateur avec Windows et des crapwares préinstallés, qu'on le reformate pour réinstaller Windows, évidemment sans les crapwares, ou pour installer un autre OS, n'est-ce pas comparable au fait d'aller sur un site web bardé de publicités avec un bloqueur de publicités ?
Je me faisais cette réflexion parce qu'il semble y avoir justement une prise de conscience de certains des acteurs de la publicité sur Internet de leurs abus dans le domaine, et ce suite à la généralisation des bloqueurs de publicités. Peut-être que les responsables des crapwares auront un jour une démarche similaire, pour autant qu'il soit concevable qu'il puisse exister des crapeware respectueux de l'utilisateur, tout comme des publicités non intrusives…
« Smart IoT Crafting » : l'IoT pour tous
# Est-ce vraiment squirrelmail le problème ?
Posté par Claude SIMON (site web personnel) . En réponse au message Changer de webmail. Évalué à 7.
J'ai moi-même installé squirrelmail sur mon serveur, et cela n'a pas été sans mal, ceci pour dire que mes connaissances sont assez limitées dans le domaine, donc ce qui suit est peut-être erroné. Cependant, pour ce que je crois en avoir compris de son fonctionnement, mis à part si on lui demande d'afficher toute la liste des courriers d'une boîte et que ceux-ci soient vraiment nombreux, je ne vois pas trop pourquoi squirrelmail poserait problème, vu que ce n'est pas lui qui gère directement les courriers.
Avec certaines distributions GNU/Linux, le format de stockage de courriers est mbox par défaut, un format dans lequel plusieurs courriers sont stockés dans un seul et même fichier. Donc, avec une boîte mail de 1 Go, on peut se retrouver avec un fichier de la même taille contenant tous les courriers de cette boîte. On peut aisément imaginer que la manipulation d'un tel fichier, notamment pour accéder à un courrier en particulier, puisse prendre un certains temps.
En ce me qui concerne, le format mbox posait problème pour la sauvegarde des courriers. A chaque nouveau courrier qui arrivait dans ma boîte, je me retrouvais à devoir sauvegarder l'ensemble de tous les courriers, même ceux déjà sauvegardés, puisque tous étaient stockés dans un seul et même fichier (mes sauvegardes s'appuient sur rsync). C'est pour cela que je suis passé au format de stockage de courrier Maildir, avec lequel chaque courrier est stocké dans un fichier qui lui est propre, ce qui a évidemment résolu mon problème de sauvegarde.
Maildir ou mbox, ce n'est pas squirrelmail qui gère cela, mais le serveur SMTP (enfin, je crois, et sans doute que le serveur IMAP doit aussi être configuré en conséquence). Face à un problème comme le tiens, je vérifierais d'abord le format de stockage des courriers, parce que si c'est mbox, il y a de fortes chances que le problème vienne de là, et changer de webmail ne le résoudrait en rien.
« Smart IoT Crafting » : l'IoT pour tous
# Bots malveillants ?
Posté par Claude SIMON (site web personnel) . En réponse au message Des virus chez lenovo. Évalué à 4.
Il y a quelques années de cela, j'ai eu exactement le même problème avec une machine d'une connaissance fraîchement installée (la machine, pas la connaissance, encore qu'elle venait d'emménager) à partir des CD-ROMs officiels (je ne sais par contre plus de quelle version de Windows il s'agissait), et que j'avais directement branchée sur une box pour réaliser les mises à jour de sécurité. J'ai dû la reformater, la réinstaller totalement, et procéder aux mises à jour de sécurité en prenant soin de la connecter à Internet via mon serveur GNU/Linux, faisant office de pare-feu matériel, pour qu'elle soit fonctionnelle. Bref, il semblait que cette version de Windows, telle que fraîchement installée à partir des CD-ROMs, comportait des failles à l'affût desquelles de nombreux bots circulaient sur Internet, failles heureusement comblées par les mises à jour de sécurité, mais encore fallait-t-il pouvoir les installer avant que ces bots ne puissent entrer en action…
Ceci dit, cela me surprendrait qu'une version somme toute assez récente de Windows ne soit pas conçue pour faire face à ce genre de situation, et, qu'en outre, de nos jours, les dispositifs conçus pour offrir un accès à Internet ne soient pas, par défaut, configurés pour préserver les machines qui y sont connectées de ce genre de mésaventure, mais sait-on jamais…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: NW
Posté par Claude SIMON (site web personnel) . En réponse au journal De l’utilisation des technologies web dans une application native.. Évalué à 4.
Mon but n’est pas d'utiliser à tout prix des technologies web. Il se trouve que HTML5, typiquement une techno web, est un bon candidat pour remplacer XUL, que je voulais abandonner pour les raisons citées dans le journal. Par contre, j'utilisais déjà C++ avec XUL (alors que, tout comme avec HTML, l'usage est également d'utiliser JavaScript), et cela fonctionnait parfaitement, donc je n'avais aucune raison de passer à JavaScript.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Qt, QML
Posté par Claude SIMON (site web personnel) . En réponse au journal De l’utilisation des technologies web dans une application native.. Évalué à 2.
C'est juste qu'avec HTML, je pouvais ajouter des éléments et attributs maisons (les fameux
xdh-...etdata-xdh-...du journal) qu'il était facile de traiter avec des outils DOM classiques, alors qu'avec le JSON-like de QML je ne pouvais pas (ou je n'ai pas trouvé comment) faire la même chose.Au final, c'est surtout, comme indiqué à la fin du journal, la perspective de pouvoir avoir un seul et même code (C++ qui plus est) pour la version web et la version native d'une application qui m'a fait préférer HTML à Qt et consorts.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: adéquation
Posté par Claude SIMON (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 10.
F3, c'était électrotechnique. Le BAC électronique, c'était F2…
(grabataire, peut-être, mais pas encore sénile… :-))
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Epeios framework?
Posté par Claude SIMON (site web personnel) . En réponse au journal dpkq, un piocheur de données.. Évalué à 1.
Les premières lignes de ce qui est devenu le framework Epeios datent d'il y a plus de quinze ans. Les domaines d'application de ce framework, et par conséquent le nombre de ligne qui le compose, n'ont cessé de s'accroître depuis. Rédiger la documentation correspondante représenterait une tâche titanesque pour une personne seule, sans compter, le framework évoluant sans cesse, le temps qui serait nécessaire rien que pour la tenir à jour.
J'utilise quotidiennement ce framework, et cette absence de toute documentation ne m'a jamais dérangé (le fait que c'est moi qui l'ai développé n'y est sans doute pas étranger), aussi préfère-je consacrer mon temps au développement et à l'amélioration de ce framework, plutôt qu'à la rédaction d'une documentation qui ne me serait d'aucune utilité. Si je le mentionne systématiquement lorsque l'un de mes logiciels (c'est-à-dire tous) se base sur ce framework, c'est parce que cela a certaines implications pour le logiciel en question. Par exemple, cela implique qu'il soit multi-plateformes et multi-architectures, qu'il possède un mécanisme spécial de gestion des arguments, que j'ai décrit dans ce journal, lorsque c'est un utilitaire en ligne de commande, qu'il utilise une registry interne rempli par un fichier de configuration…
Ceci dit, il y a cela fort (fort) longtemps, j'avais écrit un début de documentation. J'en ai retrouvé la trace durant mes investigations à l'occasion de la rédaction de ce commentaire. Apparemment, j'en avais même écrit plusieurs versions (voir ici et ici). Je n'ai pas relu, donc je ne garantis rien quant au contenu…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Ya pas à dire, tu aimes le q
Posté par Claude SIMON (site web personnel) . En réponse au journal dpkq, un piocheur de données.. Évalué à 2.
Ce ne sont pas des acronymes, simplement des assemblages de quelques lettres issues de l'intitulé (anglais) du logiciel concerné. La dernière lettre n'a pas de signification particulière.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Flux des sessions de travail ?
Posté par Claude SIMON (site web personnel) . En réponse au journal dpkq, un piocheur de données.. Évalué à 5.
Par exemple, lorsque l'on travaille sur plusieurs partitions en même temps, on a tendance à les travailler dans un certain ordre, pour être sûr de n'en oublier aucune. Ce faisant, on risque de mettre en place une sorte de réflexe pavlovien.
Ainsi, supposons qu'après avoir travaillé une partition A, relativement facile, on travaille systématiquement la partition B, avec laquelle on rencontre des difficultés. Même si on ne se focalise pas sur ces difficultés, après avoir travaillé A, notre subconscient peut nous faire aborder la partition B de manière moins sereine, parce qu'il sait que la partition qui suit A est systématiquement plus difficile. Avec
dpkq, comme les partitions ne se suivent pas dans le même ordre d'une session à l'autre, ce genre d'appréhension inconsciente ne peut se mettre en place.D'autre part, les segments concernant les partitions que je rejoue régulièrement pour ne pas les oublier sont assez nombreux ; il me faut plusieurs jours pour en faire le tour.
dpkqme permet de n'en oublier aucun, bien que je ne les joue jamais dans le même ordre, sachant quedpkqne pioche jamais deux fois le même segment si tous les autres n'ont pas été piochés au moins une fois.Quant aux fiches elle-mêmes, il faut savoir qu'une fois que j'ai déchiffré une pièce, je la connais par cœur, donc je ne recours plus qu'exceptionnellement à la partition. La fiche me montrant une image de la partition, avec les numéros des mesures à travailler dans le cadre de cette fiche, cela me suffit à me remémorer la partie à travailler (comme mentionné, je joue par cœur, donc sans l'inconfort d'avoir à suivre la partition sur la tablette). Si j'ai un trou de mémoire, la consultation de la fiche me permet généralement de le combler.
Au final, une fois travaillées, je peux ranger mes partitions, au lieu de les empiler sur mon piano/orgue pour les avoirs toujours à portée de main… D'un autre coté, si je n'ai que rarement besoin des partitions pour ces pièces, c'est aussi parce que
dpkqme permet de me les remémorer de manière régulière, systématique et exhaustive…« Smart IoT Crafting » : l'IoT pour tous
# InfoMagic ... et les joies de l’administration système.
Posté par Claude SIMON (site web personnel) . En réponse au sondage En quelle année êtes-vous passé(e) à GNU/Linux (ou autre système libre) ?. Évalué à 1.
Je n'étais pas réellement "passé" sous Linux à cette époque, puisque ma machine de travail était toujours sous Windows, mais j'avais installé Linux sur une de mes anciennes machines pour en faire un serveur Web. J'avais un temps envisagé d'y installer Windows NT, mais la machine en question n'était pas assez puissante. J'ai donc opté pour Linux, dont un ami possédait des CD's d'installation (InfoMagic), bien que je ne l'avais jamais utilisé auparavant (mais j'avais déjà eu affaire à des machines sous UNIX). A priori, l'installation s'est déroulé sans problème (du moins, je ne me souviens pas d'en avoir rencontrés), sachant que, mis à part les composants de base, la machine n'était équipée que d'une carte Ethernet (outre l'alimentation, le câble Ethernet était d'ailleurs le seul autre câble branché sur cette machine). Ainsi, grâce à Linux, et un arrangement avec mon FAI de l'époque qui m'a permis de bénéficier d'une IP fixe, j'ai pu auto-héberger mes premiers services Internet. C'était en 97.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Un truc pas clair
Posté par Claude SIMON (site web personnel) . En réponse au journal xppq, ou une autre approche de la gestion des arguments de la ligne de commande.... Évalué à 1.
Je ne dirais pas transformateur, dans la mesure où c'est une toute approche que XSLT, déjà par le fait que tout ce qui est relatif aux directives xpp est directement dans le fichier à traiter, et non pas dans un fichier à part, comme avec XSLT…
ppa la même signification dans xppq que dans cpp, à savoir PreProcessor. En fait, xppq est conçu pour être à XML ce que cpp est au C/C++.De toute manière, je ne savais pas ce qu'est un pull parser, mais, pour ce que j'en ai compris, xppq implémente bien un parser de ce type…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Un truc pas clair
Posté par Claude SIMON (site web personnel) . En réponse au journal xppq, ou une autre approche de la gestion des arguments de la ligne de commande.... Évalué à 1. Dernière modification le 03 juin 2015 à 17:47.
En effet, cela ne remplace pas seulement getopt, mais prend effectivement en charge la gestion des fichiers de configuration. C'est dû à l'utilisation du framewok Epeios, avec lequel le point d'entrée du logiciel n'est pas le classique
main(...)ou équivalent (qui est en fait défini par le framework), mais une autre fonction, (SCLTOOLMain(...), en fait, pour des application en ligne de commande). Lorsque cette dernière est appelée, les fichiers de configurations sont déjà chargés, et les arguments de la ligne de commande sont déjà traités, la registry ayant été remplie en conséquence.Comme écrit précédemment (en fait dans un commentaire plus bas), la rédaction de documentation n'est, hélas, pas mon fort (c'est un métier)…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: un seul, vraiment ? :-)
Posté par Claude SIMON (site web personnel) . En réponse au journal xppq, ou une autre approche de la gestion des arguments de la ligne de commande.... Évalué à 3.
Salut !
Pas tout à fait. xppq, c'est juste un préprocesseur XML. J'ai écris ce journal pour signaler que c'est le successeur de feu xppq, et j'en ai profité pour parler de ce nouveau système de gestion des arguments de la ligne de commande, car c'est le premier utilitaire que je publie qui l'implémente. Mais comme tous les autres utilitaires que je publierais seront, à l'instar de expp, basés sur le framework Epeios, ils implémenteront également ce système de gestion des arguments de la ligne de commande. xppq n'est pas plus lié à ce système que ne le seront ces autres utilitaires.
Ceci dit, j'ai effectivement codé ce système pour remplacer celui que j’avais précédemment codé et qui présentait de très fortes similitudes avec getopt. Dans ce sens, ce système peut effectivement être vu comme un concurrent à getopt.
Non, même pas. Pour l'instant, j'ai juste parlé de ce système pour le faire connaître, et j'en ai parlé en conjonction avec xppq pour mettre en évidence que ce n'est pas juste un concept, mais qu'il en existe bel et bien une implémentation fonctionnelle.
Actuellement, il n'existe pas de bibliothèque, en tant que telle, dédié à ce système. Ce système n'existe qu'en tant que fonctionnalité du framework Epeios. Mais il est bien entendu envisageable d'isoler le code dédié à ce système pour le mettre à disposition sous forme de bibliothèque indépendante. C'est en partie pour éventuellement susciter ce genre de démarche et pour en juger l'opportunité que ce journal a été écrit.
Comme écrit plus haut, xppq n'est lié à ce système que parce qu'il est basé sur le framewok Epeios. En l'état, pour mettre en œuvre ce système de gestion des arguments de la ligne de commande, c’est tout le framework qu'il faut mettre en œuvre, ce qui implique une approche du développement en C++ (qui est le langage dans lequel est codé le framework Epeios) en particulier et du développement en général qui sort des sentiers battus.
Ça ne m’étonne pas ; je n'ai jamais été très doué pour écrire de la documentation…
Mon emploi de l'un ou l'autre terme est plus une question de feeling que le fruit d'une véritable réflexion. Je pense que, pour l'idée que je m'en fais, ces deux termes sont assez interchangeables…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Echange perdant ?
Posté par Claude SIMON (site web personnel) . En réponse au message Echange intel i7-477* contre i7-4770k. Évalué à 1.
Juste pour préciser qu'une machine équipée d'un processeur sans VT-d n'est pas nécessairement impropre à faire tourner des VM. Ainsi, j'ai une machine animée par un i7-3770K (sans VT-d donc) sur laquelle VMware Player et Virtual Box tournent sans (presque) aucun problème…
Une machine équipée d'un i7-4770K, qui a des caractéristiques similaires à ceux du i7-3770K en termes de virtualisation, pourra donc probablement également faire tourner des VM…
« Smart IoT Crafting » : l'IoT pour tous
# C'est pourtant simple...
Posté par Claude SIMON (site web personnel) . En réponse au journal lns: ln -s pour les étourdis. Évalué à 3. Dernière modification le 16 avril 2015 à 14:31.
…c'est l'inverse de
mklink… :-)C'est sous MS-DOS, pour ceux qui ne connaissent pas. Autant
ln -sne me pose aucun problème (il faut dire que je l'utilise souvent qu'avec un seul argument), autant je suis toujours obligé de m'y reprendre à plusieurs fois avecmklinkpour trouver la bonne option à utiliser, bien que j'affiche systématiquement la page d'aide, ne fût-ce que pour retrouver le libellé des options…« Smart IoT Crafting » : l'IoT pour tous
# Finale vs Lilypond, même combat ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Word vs TeX. Évalué à 9.
Bon, ça ne va pas parler à grand monde, mais cet antagonisme Word/LaTeX me fait penser à un autre, celui de Finale/Lilypond.
Je n'ai jamais écrit de document pour LaTeX, mais, paraît-il, le langage de Lilypond est similaire à celui de LaTeX, et les logiciels du genre Finale s'apparenterait plutôt à Word, de par leur coté WISIWYG. Je mentionne Finale parce que je l'ai un temps utilisé, mais je pense que tout ce que j'écris à son propos dans ce texte pourrait s'appliquer à ses autres concurrents WISIWYG, comme Sibelius, par exemple.
Autre similarité. Pour ce que j'en sais, LaTeX se base sur TeX, ce dernier ayant été développé pour produire des documents de meilleures qualités (plus jolis) que ceux produits par les outils disponibles à l'époque de sa genèse. Or, Lilypond a été développé exactement pour la même raison. Lilypond, dont les auteurs avaient préalablement travaillé sur MusiXTeX, dont le but était de produire des partitions musicales en s'appuyant sur… TeX !
Ayant un temps utilisé Finale, je suis passé à Lilypond surtout à cause de la qualité des documents produits (qui n'ont absolument rien à envier aux partitions produits par les plus grandes maisons d'éditions), mais également, il me faut bien l'avouer, parce que Lilypond est gratuit.
Ceci dit, saisir une partition dans Lilypond est assez rébarbatif, cependant, à mon goût, bien moins que d'avoir à placer les notes sur une portée avec la souris (même s'il est possible d'utiliser un clavier MIDI, reste quand même la saisie des rythmes).
Pour rendre l'utilisation de Lilypond plus facile, j'ai développé un petit utilitaire avec lequel je saisis (à savoir à l'aide d'un clavier MIDI) d'une part la mélodie, sans tenir compte du rythme, puis j'ajoute le rythme, pour, au final, obtenir un fichier XML décrivant la mélodie et les rythmes associés. Ensuite, j'applique une transformation XSL sur ce XML, pour obtenir un fichier Lilypond, fichier que j'édite ensuite avec Frescobaldi (une surcouche à Lilypond), pour ajouter les nuances et autres annotations nécessaires.
Cette manière de travailler me convient parfaitement. Or, cela n'a été est rendu possible par le fait que le format Lilypond est du pur texte. Étant donné la nature du format des ses documents, ainsi que de ses fonctionnalités (du moins à l'époque quand je l'utilisais), je ne crois pas qu'il m'aurait été possible de mettre en place une méthodologie de travail similaire en utilisant Finale.
Il est clair que pour écrire une partition de quelques lignes, cela serait sans doute plus rapide avec Finale. Mais pour un projet un tant soi peu conséquent, Lilypond (en conjonction avec les outils cités ci-dessus) reste pour moi le logiciel le plus adapté, parce qu'offrant plus de souplesse, et me permettant ainsi d'être plus productif. Mais il paraît que certaines des plus grandes maisons d'éditions de partitions musicales utilisent Finale.
Si je devais émettre une hypothèse, ce serait que le problème des logiciels comme (La)Tex, ou Lilypond, c'est que les personnes les ayant développés l'ont fait avant tout pour eux-mêmes, pour répondre à leurs propres besoins. Or, le profil de ces personnes, notamment vu leurs antécédents de développeur (ce qui les a certainement poussé à utiliser un format texte), n'est de loin pas le plus répandu. Leur philosophie de travail, celles des outils qu'ils ont l'habitude d'utiliser, ne sont pas ceux de la majorité des utilisateurs auxquels sont destinés des produits comme Word ou Finale.
« Smart IoT Crafting » : l'IoT pour tous
# Ma propre expérience, bien que pas très instructive...
Posté par Claude SIMON (site web personnel) . En réponse au journal Mon retour d'expérience sur l'auto-hébergement. Évalué à 4. Dernière modification le 20 novembre 2014 à 09:34.
Il y a à peu prés 15 ans, comme je m'étais acheté un nouvel ordinateur, j'ai décidé de recycler mon ancienne machine en serveur internet. J'avais envisagé d'y installer Windows (NT 4.0 à l'époque, si je ne m'abuse), mais elle n'était pas assez puissante. C'est à cette occasion que j'ai installé ma première distribution GNU/Linux, que je connaissais déjà, mais que je n'avais jamais utilisé. Depuis, je n'ai jamais cessé de m'auto-héberger.
Il me semble que j'avais déjà quelques pages Web hébergées par mon FAI, et je me rappelle plus la raison pour laquelle j'ai décidé de mettre en ligne mon propre serveur Web, toujours est-il que j'avais développé peu après une application Web codée en C++, et qu'aucun FAI à l'époque (et de nos jours encore me semble-t-il) n'acceptait d'héberger une application codée en C++. Du coup, le fait d'avoir mon propre serveur internet m'a permis de mettre cette application en ligne.
J'ai connu quelques mésaventures, comme un piratage de mon serveur au travers d'une faille du serveur DNS. Depuis, je n'ai plus jamais installé de serveur DNS sur ma machine :-) (et je suis plus attentif aux alertes de sécurité de ma distribution). J'ai également perdu mon nom de domaine de l'époque, parce que l'adresse e-mail que j'avais donné comme adresse de contact pour mon domaine n'était plus valide au moment de le renouveler (bon, ce n'est pas directement lié au fait de m'auto-héberger, mais cela s'inscrivait quand même dans ce contexte). Mais sinon, mis à part la phase initiale d'installation, qui est certes chronophage, mais que je trouve sans difficultés particulières, je ne consacre que quelques minutes par semaine (généralement pour lancer les mises à jour suite à une alerte de sécurités) à la maintenance de mon serveur…
A l'époque, je ne pense pas qu'il y avait possibilité pour un particulier de louer un serveur dédié, du moins à un tarif raisonnable (je n'avais pas cherché non plus), donc je n'avais guère le choix. De nos jours, vu les tarifs, si je continue de m'auto-héberger, c'est plus par habitude que pour d'autres raisons, qu'elles soient financières, techniques ou autres…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . En réponse au journal Retour aux sources. Évalué à 1.
En fait, j'avais regardé http://fr.wikipedia.org/wiki/CMake et m'était arrêté à : [CMake] est comparable au programme Make… (et cela correspondait à ce que je croyais savoir de CMake). Il est vrai que la description qui en est faite dans la suite de l'article présente de fortes similarités avec ce que réalisent mes scripts.
Ceci dit, l'avantage de ma démarche, c'est que je parvenais au résultat désiré juste en utilisant des outils qui n'étaient très familiers, et un fichier dont j'avais la maîtrise totale du contenu (modulo la structure due à l'utilisation de XML) et de sa signification. Mais ce qui est un avantage pour moi, parce que j'ai développé ces scripts, n'en serait pas un pour une tierce personne…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . En réponse au journal Retour aux sources. Évalué à 1.
On peut trouver un exemple de 'Project.xml' à cette adresse : http://hg.savannah.gnu.org/hgweb/epeios/file/tip/tools/expp/CLI. Le Makefile situé à la même adresse a d'ailleurs été généré à partir de ce 'Project.xml'. On peut trouver d'autres 'Project.xml', et les Makefile correspondants, disséminés un peu partout dans ce même dépôt.
Les XSL ne sont par contre pas hébergés sur un dépôt.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . En réponse au journal Retour aux sources. Évalué à 2.
D'après ce que j'en sais, cmake est similaire, dans son usage, à make, donc utilisé pour la compilation. Or, je ne lance pas mes scripts pour compiler le logiciel, mais pour générer les fichiers permettant cette compilation. La compilation proprement dite se fait à l'aide d'outils traditionnels (Visual Studio, make…). Donc, je ne pense pas que l'on puisse qualifier mes scripts de 'cmake-like'. Ils seraient plutôt, toutes proportions gardées, 'automake-like'.
Concernant Visual Studio, la dernière version est capable d'utiliser tel quel ou de convertir les fichiers issus de certaines précédentes versions. Cependant, j'ai modifié mes scripts lorsque j'ai changé de version, et ce ne devait pas être bien compliqué, car la seule chose dont je me souvienne, c'est d'avoir modifié le contenu de l'attribut qui semble correspondre à la version de Visual Studio. En tout cas, après modification de la valeur ce cet attribut ('ToolsVersion'), Visual Studio acceptait le fichier généré par mes scripts tel quel, sans demande de conversion.
Je n'ai jamais utilisé C::B…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Gestionnaire de projets
Posté par Claude SIMON (site web personnel) . En réponse au journal Retour aux sources. Évalué à 3.
On n'est pas obligé de subir le XML des autres.
Pour ma part, pour chacun de mes logiciels, j'écris un fichier XML, nommons-le 'Project.xml', dont c'est moi qui ai décidé de la signification des balises et attributs qu'il contient. Il y a ainsi quelques balises descriptives (nom du logiciel, numéro de version du logiciel, auteur…), et de nombreuses autres plus techniques (nom et localisation des fichiers sources, options de compilation…). Grâce à un ensemble de scripts et de fichiers XSL que j'ai développés, je génère, à partir de ce 'Project.xml', les fichiers '.vcxproj' et '.vcxproj.filters' qui permettent de compiler le logiciel à l'aide de Visual Studio, ainsi que le Makefile qui permet de compiler le logiciel sous Cygwin avec G++ et MinGW, ainsi que sous GNU/Linux et MacOS.
Lorsque je veux, par exemple, ajouter/enlever/modifier un option de compilation, je ne passe pas par l'interface de Visual Studio, ni ne modifie le Makefile, mais modifie uniquement 'Project.xml', puis relance les scripts pour régénérer les différents fichiers.
J'envisage, dans un futur proche, d'offrir la possibilité d'utiliser Clang sous Windows pour compiler les logiciels que je développe. Et bien, pour cela, il suffira que je modifie les scripts et les fichiers XSL, sans toucher aux différents 'Project.xml', pour que les Makefile générés prennent automatiquement en charge Clang. Pas besoin de modifier manuellement tous les Makefile pour cela.
Je gère ainsi chacun de mes projets à partir d'un seul et unique fichier 'Project.xml', dont j'ai la totale maîtrise du contenu, puisque qu'il n'est destiné à être traité que par des outils que j'ai moi-même développé. Bien entendu, il a fallu développer ces différents scripts et fichiers XSL, ce qui m'a pris au final bien moins de temps que je ne le pensais, ayant l'habitude de travailler avec XML/XSLT, mais depuis que ces dernier sont écrits, je n'ai plus eu à modifier de Makefile ou équivalent, ni à me replonger dans la documentation de Visual Studio, ou de GNU make, ou d'un quelconque autre outil similaire…
« Smart IoT Crafting » : l'IoT pour tous