cfx a écrit 358 commentaires

Le plus simple est encore de définir la variable CMAKE_BUILD_TYPE à Debug, ça te fait un "-g -O0", permettant ainsi à Valgrind d'avoir toutes les infos qu'il lui faut (-g) et aucune optimisation (nécessaire pour faire du débug pas à pas).

Tu peux aussi passer CMAKE_BUILD_TYPE à RelWithDebInfo, ce qui correspond à un "-g -O2". Tu auras ainsi la majorité des optimisations gérées par le compilateur. Si ta problématique est d'identifier les fonctions les plus couteuses, c'est probablement la meilleure idée.

Si tu tiens vraiment à un "-g -O1", le plus propre est peut être d'utiliser la configuration RelWithDebInfo cité précédemment, mais en modifiant les variables CMAKE_C_FLAGS_RELWITHDEBINFO et CMAKE_CXX_FLAGS_RELWITHDEBINFO. Mais je ne suis pas convaincu que tu aies besoin d'en arriver là.

C'est également ce que je me suis dis au début, mais après avoir lu un peu les fonctionnalités proposées, c'est un peu plus qu'un simple éditeur : complétion de code, débuggeur node.js et ASP.net, intégration de git. Bon, il manque encore pas mal de choses, mais il faut bien commencer quelque-part.

En plus, c'est assez logique : [cp|mv|ln -s] source destination.

Je ne pense pas que ce soit une question de crédibilité, c'est juste que si tu es développeur Ruby/Python/Js/… et que tu as besoin d'un outil pour t'aider au quotidien à faire du Ruby/Python/Js/…, il y a de grandes chances que tu choisisses de le développer dans le langage que tu maîtrises le plus.

Il y a un coté pratique/logique, mais rien ne garanti que cela aboutisse à la solution la plus adaptée. Chaque langage à ses forces et ses faiblesses, et pour écrire un gestionnaire de dépendances pour le langage X, le langage Y sera peut-être plus adapté. En particulier si le langage X est le C++, j'ai en tête un tas de choses qui sont relativement pénibles à implémenter en C++ alors qu'elles peuvent être pliées en quelques lignes de n'importe quel langage de script.

Est-ce que ta notion de similarité tient compte de la structure XML (est-ce que deux tags qui possèdent les mêmes attributs mais dans un ordre différent sont identiques) ou bien c'est juste en comparaison ligne à ligne ?

As tu essayé développer quelque-chose ?

Qu'entends tu par "moderne" ?

J'imagine que si les vraies licences contiennent une clause du genre "l'auteur ne peut pas être tenu responsable des problèmes liés à l'utilisation de ce logiciel", c'est aussi pour que l'on ne puisse pas coller un procès à l'auteur.

Il n'est rien précisé d'explicite concernant la réutilisation du code. Tu peux en faire ce que tu veux, mais il n'est pas précisé clairement que tu peux l'intégrer à un autre projet, par exemple, ou le modifier.

La WTFPL non plus, pourtant elle est reconnue comme une licence libre. Je suis pas convaincu que "You may use […] anything contained within this project for whatever you want" soit fondamentalement différent de "do what the f*ck you want to".

C'était une façon ironique de faire remarquer que si l'on t'impose le respect d'un texte ayant une valeur juridique, tu dois le respecter, peu importe la langue dans laquelle il est rédigé.

Et surtout ça voudrait dire qu'il y a une palanquée de logiciels libres qui ne sont pas libres hors pays anglophone.

Pourquoi ?

Ce commentaire laisse entendre que si une licence n'est pas disponible en français, il est difficile de lui donner une légitimité vis à vis du droit français. Du coup, que ce passe-t-il pour la majorité des logiciels libres qui ne spécifient leur licence qu'en anglais ?

Licences CeCILL, qui sont disponibles en français et anglais. Ça ne change pas grand chose au problème, il reste un paquet de personnes à travers le monde qui ne sont pas concernées par ta licence.

Ça va, sois pas idiot !

Ça doit être sympa les vacances à l'étranger avec toi : « les enfants, cette année, c'est vol à l'arrachée ».

Il est clair qu'une licence s'intitulant "rien à b." va certainement t'aider vis à vis du droit français.

D'ailleurs, es-tu certain qu'avoir une licence dans la langue du pays joue un rôle vis à vis du droit de ce pays ? C'est un peu comme dire que tu n'es pas obligé de respecter le code de la route à l'étranger parce que ce code n'est pas disponible dans ta langue.

Et surtout ça voudrait dire qu'il y a une palanquée de logiciels libres qui ne sont pas libres hors pays anglophone.

Dans le contexte des années 50 (je ne faisait pas d'informatique à ce moment là !) il n'existait que des programmeurs purs et durs.

Au contraire, je pense (peut-être à tord) qu’à l’époque la plupart des informaticiens était des scientifiques (matheux et physiciens surtout) plus ou moins reconvertis.

Je suis trop jeune pour en attester, mais j'ai déjà entendu la même chose. Ce développeur était aussi le mec en charge d'écrire le programme sur des cartes perforées (le cas échéant).

Lorsque tu vois des masters faire 5 fautes par lignes

Tu sais que si tu fais une licence dans une fac de lettre, tu auras droit à un remise à niveau en grammaire et en conjugaison ? Et d'après quelqu'un qui a "enseigné" ça, à des étudiants bien éduqués et titulaires d'un bac littéraire, c'est affligeant.

Ça n'excuse rien, mais ça permet de relativiser un peu, surtout vis à vis d'étudiants en info qui sont amenés à travailler essentiellement en anglais. Personnellement, je suis pour la mise en place de ces remises à niveau dans les écoles d'ingé, en particulier les écoles d'informatique.

Quant à l'aptitude des écoles d'ingé à délivrer un vrai diplôme d'ingé, cela est évalué régulièrement, au minimum tous les 6 ans, 3 si ta formation présente quelques lacunes (il me semble même que cela peut-être évalué encore plus régulièrement). Et oui, la Commission des titres d'Ingénieurs peut enlever le droit à une école de délivrer un diplôme d'ingé.

Non, s'il est difficile de citer les principaux moteurs de blog statiques, c'est parce ce genre d'outil est assez peu utilisé.

Ajouter deux liens dans une page, oui, si on veux, c'est du traitement, sauf que ça ne demande rien à faire. Comme cela a été dis plus haut, ce que fait ton moteur de blog, c'est trois fois rien pour un développeur. Surtout avec des outils plus adaptés.

Par exemple, si je prend du Ruby, je dois pouvoir lister les fichiers d'un dossier et les trier par ordre alphabétique en 5 lignes de code. Parcourir cette liste et, pour chaque élément, concaténer un en-tête, le contenu du fichier et un pied de page, y intégrer deux liens vers les pages suivantes et précédentes, le titre du blog et quelques pages statiques listées dans un fichier de config, et écrire le résultat dans un autre fichier devrait me prendre 25 de lignes (en étant généreux, et parce qu'il y a un peu de html à stocker quelque-part). Trier la liste des fichiers par année et mois devrait prendre 10 autres lignes, et générer les pages d'archives 25 autres. Ce qui nous fait 65 lignes, que j'arrondis à 150 histoire d'être large. Ce script utiliserait uniquement des fonctionnalités présentes dans la bibliothèque standard de Ruby, j'aurai pu l'écrire de la même façon lorsque j'ai appris le Ruby en 2006, et je pense que dans 10 ans, vu sa simplicité, il fonctionnera toujours. Coté performances, mon script n'aura rien à envier à ton moteur en Fortran, quand bien même il s'agit d'un langage de script.

Vouloir avoir un moteur de blog qui fonctionnera encore dans 50 ans, c'est joli, mais ça ne rime à rien. Le plus important aujourd'hui, c'est d'être capable de faire face au changement. Et mes 150 lignes de Ruby contre tes 4000 lignes de Fortran ont un avantage certain : il sera bien plus facile de les maintenir et de les faire évoluer. De plus, rien de garantit que ton binaire sera encore fonctionnel dans 50 ans. Au hasard, abandon des archis 32 et 64 bits, ou du format d'exécutable Elf.

Je ne remets pas cause ta capacité à écrire du Fortran, je dis juste qu'il y a une faille dans ta logique, et qu'en faisant les choses légèrement différemment, tu pourrais alléger certains traitements. Mes suggestions vont dans ce sens et, je pense, n'altèrent en rien les fonctionnalités que tu souhaites avoir. En particulier, je ne vois pas en quoi cela mettrait à mal la sécurité, pourquoi un rafraîchissement partiel serait plus propice à des "loupés", ou pourquoi cela nuirait à la capacité à pouvoir éliminer à coup sûr un article compromettant.

Ton argumentaire sur la jubilation potentielle de quelqu'un qui aurait demandé la suppression d'un article ne tient pas la rout. Chaque article est identifié uniquement par un permalien, qui est sa date de création. Le principe du permalien, c'est d'avoir un lien permanent, et ce lien, le mec en question, il le connait. Il verra donc que cet article n'est plus disponible, et l'identifiant numérique que tu associes à chaque article n'y change rien.

En plus, cet identifiant te simplifie uniquement la vie pour faire des --edit-post=XXX ou --delete-post=XXX, mais oblige à réécrire l'ensemble des pages à chaque ajout ou suppression d'un article, uniquement pour passer cet identifiant de N à N+1 ou N-1. Je te conseille d'utiliser la date, qui te sert déjà de permalien. Certes, ça t'obligera à taper 14 caractères plutôt que 3 ou 4 pour les commandes précitées, mais ça va t'éviter de regénérer chaque page à chaque ajout ou suppression d'un article : tu as juste à regénérer la page suivante et la page précédente afin de mette à jour les liens "page suivante" et "page précédente" (enfin, si ces pages existent). Quant aux pages d'archives, tu dois juste mettre à jour la page du mois concerné par l'article ajouté/supprimé, ainsi que la page d'archive générale. Ce qui nous donne un maximum de 5 fichiers à écrire (article ajouté, article précédent, article suivant, page d'archive du mois concerné, page d'archive générale).

Certes, il y a des action qui continuent de nécessiter une regénération de l'ensemble des pages (ajout ou suppression d'une page statique, changement éventuel du template contenu dans le binaire). Mais dans ce cas, je te suggère d'ajouter une commande --update-all qui se chargera de cette lourde tâche, mais uniquement lorsque cela sera nécessaire.

Alors oui, cela va complexifier un peu le code du moteur, mais pour des raisons évidentes de performances, ou encore de facilité de débuggage, je pense que cela sera bénéfique.

Dans le contexte des années 50 […] il n'existait que des programmeurs purs et durs. Un ingénieur ou un scientifique devait passer par eux car l'apprentissage de la programmation était vrai métier pas un hobby.

Même en 2015, développeur est un vrai métier ! Je comprend ce que tu veux dire: à l'époque, on n'était pas "développeur du dimanche". Mais "avoir la programmation comme hobby" et "être développeur", ce n'est pas la même chose (et il y a bien trop de personnes qui le pense).

Certes, mais tu n'as pas besoin de tout régénérer à chaque fois que tu postes un article, si ?

Or un blog, qu'il soit statique ou qu'il soit dynamique, doit brasser des tonnes de données.

Faut avoir beaucoup de choses à raconter pour qualifier un blog de "tonnes de données". Il s'agit essentiellement d'IO de quelques centaines (soyons fous, milliers) de fichiers de quelques Ko, il n'y a pas de quoi mettre à genoux une machine.

Certes, on sait que les disques durs standards sont pas super à l'aise sur les IO de petits fichiers, mais ce n'est pas le langage du moteur du blog qui va y changer grand chose : une IO reste une IO. C'est plus de l'ordre d'une bonne stratégie concernant la gestion de ces fichiers (afin de ne traiter que le nécessaire).

Ok, je comprend un peu mieux le fonctionnement global.
En effet, le fait d'avoir un binaire statique qui embarque tout ce qu'il faut est un avantage pour ne pas se retrouver avec un moteur de blog rendu non-opérationnel à cause de mises à jour du système.

Cela dis, ce que je suggérais (hormis le fait de complètement externaliser les feuilles de style et les templates) reste valide. Je suis 100% d'accord avec toi sur le fait qu'obtenir une feuille de style qui fonctionne correctement est une tâche qui demande du temps (surtout quand le webdesign n'est pas son métier). Mais justement, je pense que pouvoir travailler directement sur des fichiers html et css (que la chaîne de compilation traiterait afin de les embarquer dans le binaire) plutôt que sur du html/css à la sauce fortran devrait permettre un certain gain de temps, tout en permettant à un plus grand nombre de se construire un thème perso. Désolé d'insister sur ce point, mais même s'il s'agit d'une tâche chronophage, qui n'en a jamais eu marre du design de son site et a pris du temps pour le retravailler ? Par contre, cela nécessiterai une commande pour pouvoir régénérer toutes les pages.

Si la feuille de style n'est générée qu'à la création du blog, comment cela se passe lors d'une mise à jour du moteur ? La version existante sera conservée, ou bien remplacée par celle embarquée par le moteur ? Si c'est la seconde solution, alors cela oblige à aller modifier les fichiers src/standard_css_X.f08, non ? Ou alors il faut se fusionner manuellement sa version personnalisée avec celle fournie par le moteur ?

Il y a des tas de bonnes raisons de vouloir éditer les templates html : ajouter un bout de script qui fait office de compteur de visite (genre Google WebAnalytics), ajouter des liens vers d'autres sites, ajouter une seconde feuille de style qui introduit certaines personnalisations, ou tout simplement vouloir contribuer à ton moteur de blog.

Est-ce que tu peux détailler un peu plus les fonctionnalités proposées par ton outil qui devraient nous le faire choisir lui plutôt qu'un autre ?

Je l'ai essayé, et il y a certains points qui sont pour moi rédhibitoires, le plus important étant que les templates html ainsi que les feuilles de styles soient écrites en fortran. Pour qui veut bricoler le style des pages, c'est réellement une plaie, d'un point de vue syntaxe mais aussi workflow (obligation de recompiler l'outil).

D'autant plus que pour les feuilles de style, il n'y a, a priori, aucun traitement, c'est juste un copier-coller du css. Je ne connais pas le fortran, mais j'imagine qu'il y a moyen de lire un fichier externe qui serait un simple fichier css. Si tu veux conserver un binaire embarquant tout (pas de dépendances à des fichiers css/html/js externes), je pense qu'il est possible dans ta chaîne de compilation d'ajouter un bout de script qui va lire ces fichiers, coller leur contenu dans une chaîne de caractère que tu peux ensuite utiliser directement en fortran.

Pour les templates html, c'est un peu plus compliqué car il faut insérer des données comme le titre, la langue, et bien sûr le contenu de l'article. Mais là encore, je pense qu'un simple fichier html contenant des tokens (genre "%%TITLE%%", "$LANG" ou n'importe quelle autre syntaxe qui ne serait pas ambiguë) permettant à l'outil de faire un "rechercher et remplacer" (encore, je ne sais pas comment ça se fait en fortran) serait plus pratique.

Sauf que du coup, sortir du fortran pour faire du cat/sed ou remplacer quelques lignes de n'importe quel langage de script, je trouve ça un peu compliqué. Mais comme je le disais au début, là c'est à toi de détailler un peu plus les fonctionnalités de ton moteur de blog.