Journal fBlog

Posté par (page perso) . Licence CC by-sa
Tags : aucun
12
14
mar.
2015
Ce journal a été promu en dépêche : Moteur de blog fBlog.

Amis lecteurs, vous avez été nombreux à répondre au sondage que j’avais initié sur les pages perso. J’avais un projet de moteur de page perso / blog minimaliste en cours depuis des années et vos réponses m’ont donné un nouvel élan.

Version courte

fBlog est un moteur de blog utilisable par toute personne ayant déjà mis en ligne ses pages Web et possédant des notions de HTML et CSS. Son interface utilisateur est soit la ligne de commande classique ou un mode interactif à la console d'un genre nouveau. Contrairement à la plupart des autres logiciels de ce genre, fBlog est un binaire exécutable. Il est sans dépendance à la compilation mais à l’exécution il requiert quelques commandes externes Posix et un quelconque éditeur de texte. Il s’installe aisément en suivant les instructions sur la console et il est immédiatement fonctionnel sur tout système Linux de base.

fBlog n’est basé sur aucun framework et les pages générées ont toutes à peu près le même source HTML. La personnalisation du HTML des pages est faite par un fichier de configuration où l’on défini le titre, l’introduction, le pied de page, etc. L’aspect des pages générées est entièrement fondé sur la feuille de style externe (qui n’est même pas obligatoire).

fBlog est minimaliste et ne supporte pas les commentaires (ça a permis d’éviter JavaScript et *SQL) ni les catégories. Les billets sont des fichiers texte individuels où le nom de fichier est la date et l’heure de création, le premier enregistrement est le titre et le restant le corps du texte rédigé en HTML (Markdown non supporté).

fBlog est en libre téléchargement depuis SourceForge. Il y a un binaire pour les PC mais il est vraiment facile de le compiler en suivant les instructions. La seule chose dont vous ayez besoin est le compilateur GCC (pas plus vieux que la version 4.7.3) avec l’option gFortran.

Concernant la discussion hébergement à domicile vs hébergement pro vous pouvez tester mes pages en changeant le TLD de « .com » en « .fr ». Tout ce qui est sous le TLD « .com » est chez moi sous modem ADSLv1 alors que ce qui est sous le TLD « .fr » est un miroir chez un hébergeur bien connu.

Liens :
* Sourceforge (site officiel)
* Page perso (HTML sans style)
* Blog de démo (style fBlog standard)

Version longue

Au commencement, c’était une histoire de bateau ! En 2006, je mettais en chantier une coque de voilier pour faire un tour du monde et j’éprouvais le besoin de bloguer sur cette aventure. Aujourd’hui le voilier n’est pas tout à fait terminé, contrairement à ce que j’avais planifié. Mais ça, c’est une autre histoire.

Donc, en 2006, je prospectais ce qui existait en matière de logiciels de blog. (Je n’étais pas totalement novice car j’avais déjà mis en place le site Web d’une association composé de pages statiques, écrites à la main, hébergées sur le compte Free d’un adhérant.) Le logiciel devait répondre à des besoins très précis en matière d’administration : je devais pouvoir tout faire à distance, depuis un cybercafé doté d’une connexion pourrie. Dans le contexte de l’époque, c’était du Telnet avec Putty sous Windows. Le moteur de blog devait être administrable à la ligne de commande. J’ai donc choisi NB (NanoBlogger) ; que j’ai adoré au point de m’y impliquer dans sa traduction et de fédérer quelques utilisateurs francophones.

Mais NB était une horripilante lenteur lorsque il atteignait une centaine de billets. (C’est beaucoup moins vrai aujourd’hui avec la puissance actuelle des machines ; et il y a encore des fidèles qui ont maintenant des centaines de billets.) Donc, juste pour cette question de lenteur, je me suis résolu à écrire mon propre logiciel. Le seul moyen que je voyais était de le programmer plutôt que de le scripter. J’avais pris conscience de la dépendance aux langages interprétés qui oblige à intervenir souvent sur le code lors des nouvelles versions du langages (Bash pour NB).

Concernant le choix du langage capable de générer un binaire, la liste était très courte: il n’y avait pas de Basic (à l’époque) pour Linux ; restait le langage C, Ada et Fortran. Le langage C, j’oubliais vite car j’étais un marin pas un informaticien professionnel. Ada me tentait assez mais Fortran m’a paru plus évident car je m’y était déjà un peu essayé en guise de remplacement du Basic anciennement pratiqué avec MS-DOS. En 2009, j’ai commencé mes premiers pas en programmation Fortran et ça n’a pas été facile.

Ce langage a connu de si profonds changements que les quelques rudiments que j’avais pu assimiler quelques années avant se sont avérés insuffisants. Pour faire bref, la glorieuse époque de Fortran est celle de la version F77 ; laquelle faisait à peu près tout ce que l’on peut faire avec du scripting Bash mais en infiniment plus vite. F77 ne connaissait pas encore les pointeurs, les allocations dynamiques et bien évidement pas les modules et autres facilités du génie logiciel moderne. Il m’a fallu me mettre à jour et ingurgiter des savoirs avec une maigre documentation et absolument aucun exemple à me mettre sous les yeux autres que ceux illustrant la norme. Et aujourd’hui encore, je n’ai pas connaissance d’un source Fortran qui ne soit pas le replâtrage d’un vieux soft écrit en F77 ou F90. Et je ne connais aucun logiciel écrit en Fortran pour faire autre chose que du calcul intensif !

J’ai choisi gfortran qui vient avec GCC et qui profite de la même infrastructure que le langage C. À ce moment là, gfortran couvrait la totalité de la norme 77, la quasi totalité de F90 et F95 et introduisait F2003. Aujourd’hui gfortran commence à introduire la norme F2015 (à partir de GCC-5.0) mais ne couvre pas encore la totalité de F2003 et F2008. Depuis 2009, j’ai eu l’occasion de tester les nouveautés de ce langage et elles ont été nombreuses et intéressantes !

Je dois dire que l’abondance de ces nouveautés logicielles m’a fait perdre beaucoup de temps ! Si j’en étais resté au Fortran 77, je n’aurais eu qu’à faire une traduction du script Bash qu’est NanoBlogger et la messe aurait été dite depuis longtemps. Mais là je me suis trouvé devant plein d’options différentes et je me suis livré à de longs errements. Du genre, module ou pas module ? Et si module, procédures dedans ou seulement des variables communes ? Variables globales à tout le programme ou panachage avec des variables mises en modules ?

Un autre point aussi qui m’a pesé : le « coding style ». Si l’on peut à la rigueur écrire un source F90 à la manière de F77, avec les dernières normes ce n’est plus envisageable : par cause de la longueur des noms des nouvelles procédures intrinsèques et leur cortège d’options. Je me suis créé donc mon propre style, un peu à la manière du langage C. Il y avait aussi le choix de rester dans la concision du style F77 ou la verbosité dorénavant permise par la norme. J’ai fait le choix de la verbosité car je me suis aperçu que c’était plus facile pour me relire plus tard. C’est vraiment là que l’on souffre de ne pas pouvoir lire du code récent écrit par d’autres. Comme je ne me suis pas stabilisé immédiatement en style, j’ai donc eu à réécrire plusieurs fois l’intégralité du code.

En dehors du langage de programmation, j’ai eu à faire d’autres choix qui auraient de toute façon été à faire quelque soit le langage choisi et qui concerne l’ossature du moteur de blog. Le tout premier était de choisir entre une base de donnée interne ou externe. Le choix fut rapide et le même que pour NanoBlogger : pas de base de données externe à la SQL mais des billets saisis sur un fichier plat individuel. Chaque fichier prend pour nom la date et l’heure de création et il est facile d’en faire le tri avec la commande externe « ls ». La création ou modification ultérieure d’un fichier se résume à y faire intervenir un éditeur de texte externe. Comme Fortran peut utiliser la ligne de commande, je pouvais faire comme si je scriptais en Bash.

Le second choix, plus difficile, fut la question linguistique. Devais-je rédiger en français, en anglais ? Devais-je rendre le logiciel facilement adaptable dans une autre langue, le proposer à la fois en français et en anglais ? Dès le départ j’avais dans l’idée de faire un vrai projet, donc l’anglais s’imposait. Je me suis posé la question pendant plusieurs années. Vraiment. Aujourd’hui, j’ai le parti pris de l’anglais comme langue unique mais j’ai fait en sorte que tout se tienne dans le même module de façon à ce qu’un traducteur éventuel puisse ne pas trop souffrir. De toute façon, l’utilisateur de ce genre de logiciel en ligne de commande doit maîtriser un peu l’anglais. Et la base d’utilisateur est très faible au vu du nombre des usagers de NanoBlogger. Se limiter à la sphère française, serait coder pour une poignée d’individus.

Je voulais aussi expérimenter une autre interface utilisateur que la seule ligne de commande mais qui soit compatible avec une session Telnet/ssh. Je ne voulais pas me perdre avec une interface à fenêtres avec ncurses (et surtout pas à jouer avec la programmation mixte !). J’ai donc créé une interface d'un genre nouveau qui fait absolument tout ce que la ligne de commande faisait déjà, un peu comme avec ncurses au niveau des touches à action instantanée (dit-on « hot key » ?) mais en mode ligne plutôt qu'en page écran.

Ceci a eu pour effet d’introduire des tas de bugs qui n’avaient pas de raison d’apparaître à la seule ligne de commande qui fait un traitement linéaire. Autant dire que le seul ajout de cette nouvelle interface utilisateur m’a obligé réécrire quasiment entièrement un code déjà parfaitement fonctionnel à la seule ligne de commande ! Mais bon, maintenant ça marche et c’est joli.

Un autre choix drastique a concerné la partie HTML, CSS et JavaScript. Je n’ai pas voulu m’embêter avec JavaScript (que je n’ai jamais pratiqué) car avec NanoBlogger on arrivait bien à s’en passer. De plus il n’y a pas le support des commentaires qui l’aurait rendu nécessaire. Reste que HTML venait de passer à la version 5 (bang, encore un apprentissage) et que CSS montait aussi à la version 3 (re-bang !). De tous les mois que j’ai pu consacrer à ce projet, je crois que la seule partie concernant les CSS m’a pris la moitié du temps. Contrairement au codage en Fortran, c’est pas fatiguant mais c’est long ! Encore une fois, j’ai pris une option de codage risquée mais qui semble prometteuse.

Avec l'inflation du vocabulaire en HTML 5 il est devenu plus facile d’amarrer du style à toutes ces balises. Au point que j’ai pensé supprimer les balises DIV et faire appel aux pseudo classes en CSS. Ça a marché. Alors j’ai supprimé aussi les balises SPAN par la même occasion ! Encore une fois, ça a marché. Puis ce fut le défi imposé par la dernière mode, les feuilles de style « responsives ». Quelques dizaines d’heures encore plus tard… Ouf !

Au final, le moyen que j’ai trouvé pour réussir le couplage HTML – CSS, ce fut de ne concentrer que sur le seul HTML et de ne faire les CSS qu’ensuite. Aujourd’hui, on a la chance que les navigateurs traitent grosso modo le style par défaut de la même manière. (Comme si, par exemple, votre feuille CSS ne contenait aucun code.) Donc si le code HTML affiché par défaut dans le navigateur suffit à la bonne compréhension du blog, le fichier CSS est juste du bonus. Et le site est compatible pour les navigateurs en mode texte.

J’arrive maintenant au bout de la première étape que je m’étais fixée, celle d’un moteur de blog qui convienne à mes besoins initiaux. Mais comme j’ai déjà bien d’autres envies, il y aura de nouvelles fonctionnalités dans les versions futures de fBlog. Et ce, jusqu’à la version 1.0 . Ensuite, ça ne sera plus que de la maintenance. Le code HTML généré depuis la version présente jusqu’à la future version stable 1.0 ne devrait plus beaucoup bouger. Une feuille de style personnalisée par vos soins aujourd’hui devrait pouvoir supporter les mises à jour sans trop de souci.

Exemples de blogs générés par fBlog :

  • blog du site officiel (style conçu pour se rapprocher de celui de SourceForge) ;
  • mon blog principal (style non modifié livré avec fBlog) portant surtout sur le cinéma ;
  • photo blog ;
  • cargo (style non modifié livré avec fBlog), un blog rétrospectif sur mon ancienne carrière de marin au long cours ;
  • le blog sur mon voilier (celui qui est à l'origine de cette aventure !) ;
  • code de nuit (style ordinausaure), divagations sur l'informatique.
  • # Fonctionnalités

    Posté par . Évalué à 3.

    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.

    • [^] # Re: Fonctionnalités

      Posté par (page perso) . Évalué à 3.

      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.

      Attention, Seul le template HTML est écrit en fortan. Certes fBlog fournit une (et une seule) feuille de style standard qui est générée par un source fortran lors de l'installation mais vous êtes libre d'en créer de nouvelles autant que vous voulez.

      La philosophie de fBlog est d'être personnalisable par la seule feuille de style : on ne touche pas au HTML ! Donc on n'a pas à recompiler le logiciel. C'est le contraire des autres moteurs de blog qui sont personnalisables à la fois au niveau du HTML et du CSS. Quant au JavaScript, la question ne se pose même pas pour un moteur de blog minimaliste.

      Pour résumer, sauf à vouloir modifier la génération du code HTML (par exemple pour y inclure un support des commentaires avec JS), il n'est nul besoin de connaître un seul mot de fortran. Mais pour une traduction de l'interface utilisateur, oui il est nécessaire de rentrer dans le code. Mais ça nécessite que peu de savoir en fortran.

      • [^] # Re: Fonctionnalités

        Posté par . Évalué à 1.

        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.

        • [^] # Re: Fonctionnalités

          Posté par (page perso) . Évalué à 3.

          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 ?

          Quand il y a une mise à jour de fBlog et qu'on installe le binaire dans un répertoire global (/usr/bin), son invocation n'installera pas une nouvelle feuille de style ni aucun autre fichier. Seulement, les feuilles générées suivront le nouveau template HTML qui est codé en dur. Dans la mesure où la mise à jour n'a pas modifié le template HTML, la feuille de style ancienne (personnalisée par vos soins) restera valide et tout se passera bien. Dans le cas contraire, il faudra peut-être adapter la feuille de style.

          Mais, et c'est la grande force de fBlog, ce logiciel peut se compiler en statique. Et cela, une fois fait, il reste opérationnel sur une même machine quelque que soit la version de Linux ou de la libc. Si vous avez un site Web dont vous voulez garder durablement la présentation, je vous conseille de mettre le binaire exécutable dans le même répertoire que celui où vous générez vos pages. Il n'y aucun inconvénient, il n'y a aucun risque à mettre plusieurs versions de fBlog sur une même machine.

          Il y a des tas de bonnes raisons de vouloir éditer les templates html

          Oui, je suis d'accord. Et d'autant plus ayant pratiqué NanoBlogger. Mais le revers de la médaille est de réussir le couplage du HTML d'avec le CSS. Et ça, ça demande énormément de temps, de patience et de compétence. En rigidifiant d'un côté, j'apporte plus de souplesse de l'autre. C'est l'orientation fondamentale de fBlog.

          ou tout simplement vouloir contribuer à ton moteur de blog.

          fBlog est un projet individuel et le restera : je fais des tas de choses dans ma vie et je suis dans l'impossibilité d'assumer une coordination au jour le jour d'une communauté. Cependant j'apprécierai grandement tout rapport de bug ! Et aussi le témoignage d'utilisateurs heureux.

          • [^] # Re: Fonctionnalités

            Posté par . Évalué à 3.

            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.

            • [^] # Re: Fonctionnalités

              Posté par (page perso) . Évalué à 2.

              plutôt que sur du html/css à la sauce fortran

              Attention ! Seul le HTML généré est à la sauce fortran. La feuille de style est strictement en dehors du moteur de blog et totalement apportée (ou rédigée) par l'utilisateur. Si j'ai codé la feuille de style standard dans mon moteur, c'est pour faciliter le packaging du logiciel qui est ainsi en un seul tenant. Cette feuille de style standard est écrite sur un fichier dans le sous-répertoire fBlog/styles seulement lors de l'installation du logiciel. On peut la modifier avec un éditeur de texte ou la copier sur un nouveau fichier ou s'en inspirer pour créer une nouvelle CSS. Si vous supprimez cette feuille de style standard, vous ne pourrez pas demander à fBlog de la recréer. (Il vous faudra créer un nouveau blog dans un autre répertoire et faire un copier-coller de cette CSS.)

  • # les cargos

    Posté par (page perso) . Évalué à 4.

    J'adore ton blog Cargos ! À ma surprise j'ai été captivé par ce défilé de bateaux. Naïvement je croyais que les capitaines restaient plutôt longtemps sur un même bateau. En fait vous en changez tout le temps… Comment ça se passe ? il y a une sorte de répertoire des embarquements possibles ?

    Et j'y ai découvert que tu m'as sans doute transporté vers l'île d'Yeu. Ô fierté de connaître un capitaine! Mes enfants vont être jaloux !

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: les cargos

      Posté par . Évalué à 2.

      Moi qui passe mon permis hauturier en ce moment, j'ai beaucoup aimé aussi. =)

    • [^] # Re: les cargos

      Posté par (page perso) . Évalué à 4. Dernière modification le 14/03/15 à 11:36.

      En fait vous en changez tout le temps…

      La variété des embarquements dépend de deux choses : le nombre de navires dans une entreprise donnée et le statut du marin.

      1. Si une compagnie a plusieurs navires, les marins passeront de l'un à l'autre. Certes le capitaine aura tendance à se spécialiser plutôt sur l'un d'entre eux pour des raisons pratiques mais pas forcément. Et si la compagnie n'a qu'un seul navire, forcément ce sera toujours le même capitaine (ou plutôt deux pour le remplacer pour les congés). Mais beaucoup de compagnies n'ont très peu de navires ; donc ce sera toujours les mêmes à bord.

      2. Le statut du marin (simple matelot ou capitaine) est le même que celui du secteur privé des entreprises terrestres : soit on est en CDD soit on est en CDI.

      En ce qui me concerne, j'ai eu un parcours professionnel chaotique et je suis resté tout au long de ma vie en contrat précaire. D'où la diversité de mes embarquements.

      il y a une sorte de répertoire des embarquements possibles ?

      Ça se passe à peu près comme les pilotes de ligne : il faut obligatoirement les diplômes qui vont bien et ensuite on se débrouille pour trouver un employeur.

  • # Langages

    Posté par (page perso) . Évalué à 3.

    Concernant le choix du langage capable de générer un binaire, la liste était très courte: il n’y avait pas de Basic (à l’époque) pour Linux ; restait le langage C, Ada et Fortran.

    Ces dernières années, j'ai l'impression qu'il y a un regain d’intérêt pour les langages qui compilent du natif (Rust, Go, D, Nim…), et c'est plutôt excitant de voir ce que ça va donner dans l'écosystème du Web. Mais même en 2009 (et même 2006) il y avait déjà bien d'autres langages capables de générer un binaire: C++, Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel…

    • [^] # Re: Langages

      Posté par (page perso) . Évalué à 5.

      Dans mon choix, il faut bien tenir compte de mon passé. En effet, j'ai acheté ma première calculatrice 4 opérations à l'âge de 23 ans alors que mon pain quotidien étaient les tables des logarithmes des fonctions circulaires. Le premier programme que j'ai écrit était en basic sur une calculette programmable, j'avais 35 ans. Quand je suis passé de Windows 95 à Linux, j'avais 39 ans. Et l'ADSL est arrivé chez moi à l'âge de 47 ans. Tout ceci fait que j'ai les lacunes énormes que l'on trouve chez tous les autodidactes.

      En ce qui concerne le C++, sans vouloir troller exagérément et sans l'avoir jamais pratiqué, je subodore que la toute dernière version de gfortran fait presque aussi bien que C++ mais sans douleur. Sincèrement, je ne savais pas que Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel pouvaient être compilés statiquement (et sans runtime ?) sur Linux.

      En ce qui concerne mon choix de Fortran, sa normalisation (et donc sa pérennité) a été déterminante pour moi.

      Il vrai que le langage Go semble avoir la cote en ce moment et on le voit bien dans la liste des moteurs de blog statiques.

      • [^] # Re: Langages

        Posté par (page perso) . Évalué à 3.

        Attention je ne remettais pas en question le choix du langage ; même si le choix est des plus singuliers, ce n'était pas l'objet de mon commentaire.

        Je vois que vous avez surtout l'humilité de l'autodidacte, car je vous rassure, les professionnels ont aussi beaucoup de lacunes !! Des tas de pros se reposent sur ce qu'ils ont appris quand ils avaient 20 ans sans remettre en cause leurs connaissances, donc je n'ai souci avec quelqu'un qui se remet à coder a 50 ans ! :)

        Sincèrement, je ne savais pas que Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel pouvaient être compilés statiquement (et sans runtime ?) sur Linux.

        Pour le runtime, Ocaml, Haskell ou Lisp qui utilisent un Garbage Collector ont un runtime ; en revanche si j'ai bien compris c'est plus le fait que compiler en statique qui vous intéresse plutôt que l'absence de runtime (mais j'ai lu en diagonale), et pour le coup je ne saurais pas vous dire ce qu'il en est (mais Ocaml générant du C, j'imagine que cela doit être possible).

        • [^] # Re: Langages

          Posté par (page perso) . Évalué à 1.

          en revanche si j'ai bien compris c'est plus le fait que compiler en statique qui vous intéresse

          Le principe des langages pouvant tourner éventuellement sous runtime est une chose qui m'intéresse vivement. C'était le cas de QuickBasic qui était un outil fabuleux. Pour l'instant, je me mets (très doucement) à gForth. L'inconvénient de ce type de dispositif est que l'assise est faible : qu'advient-il quand l'équipe des développeurs (ou l'entreprise, ou l'institution) s'en désintéresse ?

          Ce qui m'intéresse au plus haut point est de ne pas avoir à recoder un logiciel quelques années après, parce que le compilateur n'existe plus, que le langage interprété utilise une nouvelle machine ou change ses règles, etc. Ayant eu l'expérience de NanoBloger qui est codé en script Bash, j'ai vu qu'il fallait reprendre le code plusieurs fois par an juste pour en assurer la maintenance. Or, dans mon cas, mon emploi du temps ne me permet pas d'assumer cette maintenance de code. L'avantage des langages compilés (comme C, Ada ou Fortran) est qu'ils ont une sorte de parfum d'éternité.

          • [^] # Re: Langages

            Posté par (page perso) . Évalué à 1.

            L'avantage des langages compilés (comme C, Ada ou Fortran) est qu'ils ont une sorte de parfum d'éternité.

            Oui je comprends ; maintenant cette "éternité" n'est atteignable que pour les logiciels n'interagissant que peu avec le système (comme ici, lire et écrire des fichiers principalement). Ça représente certes bon nombre de nos logiciels d'unixien, mais heureusement qu'on ne se contente de cette classe de logiciel. Et à partir du moment on va se se lier à GTK, Qt, libXML, openSSL, openGL… on peut être certain que 15 ans après notre binaire laissé sur une disquette au fond d'un tiroir ne va plus tourner. C'est frustrant je le concède mais l'idée de logiciels évoluant sans cesse tels des formes de vie me parait tout aussi intéressante que des logiciel figés dans le marbre (ce qui ne m'empêche pas de comprendre votre motivation de ne pas vouloir corriger votre logiciel tous les 2 mois hein).

            En revanche pour NB, autant il ne me viendrait pas à l'idée de coder un logiciel en Bash (déjà qu'un script de 3 lignes…), autant je m'interroge : vos problèmes venaient-ils de changements dans Bash ou dans NB lui-même (auquel cas le langage n'a rien a voir là dedans) ?

            • [^] # Re: Langages

              Posté par (page perso) . Évalué à 2.

              vos problèmes venaient-ils de changements dans Bash ou dans NB lui-même (auquel cas le langage n'a rien a voir là dedans) ?

              Ce qui m'a motivé à écrire fBlog (et je jure que c'est bien la seule raison !) c'était que NanoBlogger commençait à ramer sérieusement quand on dépassait une centaine de billets. Et bien des utilisateurs sont passés à un autre moteur de blog pour cette seule raison. (C'est toujours vérifiable car NanoBlogger est toujours disponible en téléchargement et il est toujours packagé par les grandes distributions.) L'aspect maintenance ne se posait pas car elle était assurée par son auteur (Kevin Wood), je n'avais qu'un rôle mineur de traducteur.

              Sur les machines de l'époque (mono-cœur), ça prenait environ une minute pour générer un centaine de billets. La cause est multiple : un script Bash est forcément lent, déclenche des tas de processus en parallèle et sature le système. Les lectures-écriture des fichiers sont nombreuses et arrive le moment où le système de fichier doit se synchroniser avec le disque dur ce qui amène à de nouveaux processus. Alors ça rame de partout. Mais, aujourd'hui, je suis sûr que Nanoblogger doit tenir mieux la charge avec les processeurs mufti-coeurs et un disque SSD.

              Une autre cause de ralentissement de NanoBlogger est la possibilité de créer des catégories ce qui augmente considérablement le nombre de pages à générer. C'est la raison pour laquelle je n'ai pas voulu de catégories pour fBlog.

              Ceci étant, pour ceux qui écrivent un ou deux billets par mois, NanoBlogger est un bon cheval. Concernant fBlog, j'ai décidé qu'il devait être capable de générer le blog d'un blogueur compulsif sur la base d'un billet par jour pendant 50 ans en moins d'une minute. D'après mes test, fBlog peut le faire !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.