GNU Make 4.0 extensible

Posté par  . Édité par Benoît Sibaud, palm123, Xavier Teyssier et NeoX. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
36
10
oct.
2013
GNU

Le vénérable ordonnanceur de compilation du projet GNU sort une version 4.0. La possibilité d'écrire des extensions en Guile justifie l'incrément de la version majeure.

La grosse nouveauté de cette version, c'est l'intégration de l'interprêteur GNU Guile permettant d'écrire des extensions make dans ce langage.

Quelques options bien pratiques sont ajoutées :

  • --output-sync groupe la sortie par cible, même lors de compilation parallélisée. D'ailleurs, le parallélisme est maintenant supporté sous Windows ;
  • --trace permet de débugguer les règles en forçant l'affichage de chaque commande exécutée ;
  • Également, une nouvelle fonction native $(file ) permet d'écrire des lignes dans un fichier sans passer par le shell.

En outre, le projet annonce pas moins de 80 bugs corrigés.

GNU Make est un projet à maturité et les nouveautés de cette version concernent surtout le confort. Mais n'est-ce pas justement ce qu'on apprécie dans GNU make ?

Aller plus loin

  • # Ben voyons

    Posté par  . Évalué à 7.

    GNU Make est un projet à maturité et les nouveautés de cette version concernent surtout le confort.

    Hum, le tracing ça n'est pas du confort, c'est le degré 0 du debugging, qu'il soit intégré seulement dans la V4 de GNU make me conforte dans tout le mal que je pense de ce truc.

    • [^] # Re: Ben voyons

      Posté par  . Évalué à 9.

      Ce "truc" a eu le mérite d'exister et d'être utile à un certain nombre de personnes. Ce n'est qu'avec le recul qu'on se demande pourquoi. À une époque, c'était incontournable, une sorte d'expérience masochiste initiatique de geek.

      Je me rappelle de ce sentiment indescriptible quand je me suis rendu compte après des heures de déboggage que les tabs et les espaces étaient interprétés différemment dans le Makefile. Ça doit ressembler à ce que ressent la petite fille quand elle se rend compte qu'il y a un ogre ou une soricère dans la maison en pain d'épice et qu'elle est coincée dedans.

      • [^] # Re: Ben voyons

        Posté par  (site web personnel) . Évalué à 10.

        Je me rappelle de ce sentiment indescriptible quand je me suis rendu compte après des heures de déboggage que les tabs et les espaces étaient interprétés différemment dans le Makefile

        Je pense que c'est arrivé à beaucoup de gens de perdre du temps avec ça. Combien d'heures au total ont été perdues à cause d'une décision un peu débile d'une personne, qui, dans un temps et une galaxie lointaine, a un jour décidé d'utiliser la tabulation pour les commandes dans les makefiles (sans doute la même personne qui avait décidé d'ignorer la dernière ligne du makefile si elle ne se termine pas par un retour chariot). Ca doit se chiffrer en dizaines de millions d'heures. Quelque part cette personne a fait plus de mal à l'humanité que émile louis.

        • [^] # Re: Ben voyons

          Posté par  (site web personnel) . Évalué à 7.

          ignorer la dernière ligne du makefile si elle ne se termine pas par un retour chariot

          Les gens qui utilisent un éditeur de texte correct n'ont pas ce problème.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Ben voyons

            Posté par  . Évalué à 8.

            Les gens qui utilisent un éditeur de texte correct n'ont pas ce problème.

            Sans doute mais ça n'enlève rien au problème de base.

            • [^] # Re: Ben voyons

              Posté par  (site web personnel, Mastodon) . Évalué à -10.

              Ben, il n'y a pas de problème de base. La tabulation indique un bloc de commande.

              Faut-il alors incriminer le point-virgule ? Faut-il supprimer les pointeurs sous prétexte que des générations d'imbéciles ne comprennent pas un concept aussi simple, élégant et puissant ?

              • [^] # Re: Ben voyons

                Posté par  . Évalué à 10.

                En gros, tu ne vois pas un problème qui attriste même le concepteur de make:

                Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.
                -- Stuart Feldman

                En toute franchise, je pense que tu as de la m**** dans les yeux. Utiliser deux caractères visuellement identiques pour des sémantiques différentes, c'est du design foireux qui saute aux yeux. Tu as appris à vivre avec, c'est une bonne chose pour toi, mais de là à nier le problème, c'est du refoulement.

                Après, il y a parfois du design foireux qui peut avoir des effets de bords intéressants, comme le presse-papier multiple sous Linux. Parfois, on peut tellement s'habituer à une absurdité ergonomique qu'on se sent perdu quand elle est corrigée (typiquement, cliquer sur "Démarrer" pour tout faire sauf démarrer l'ordinateur sous Windows).

                Faut-il supprimer les pointeurs sous prétexte que des générations d'imbéciles ne comprennent pas un concept aussi simple, élégant et puissant ?

                Je ne vois franchement pas le rapport entre un concept et une syntaxe foireuse.

                Ceci dit, utiliser * pour déréférencer un pointeur, ça peut commercer à ressembler à une ergonomie douteuse. La signification de "u * v" va dépendre de la déclaration de u, qui peut être dans un autre fichier, ce qui peut rendre le code difficile à comprendre. Rien à voir cependant avec l'utilisation de caractères visuellement indistinguables pour des sémantiques différentes.

                • [^] # Re: Ben voyons

                  Posté par  (site web personnel, Mastodon) . Évalué à -6.

                  Le rapport est que nombreux sont ceux qui ne comprennent pas les pointeurs. Pourtant c'est simple, je n'ai jamais compris ce qu'il y avait de difficile là dedans. Ensuite, il faut juste un peu de rigueur pour écrire du code correct.

                  Là c'est pareil. Sous prétexte qu'un éditeur de texte limité ne montre pas la différence, on se plaint encore et encore sur quelque chose sur laquelle je n'ai jamais trébuché. C'est un peu comme se plaindre que « présentent » et « présentes » ne se distinguent pas à l'oreille : avec le contexte grammatical, il n'y a pas de doute. Ici c'est pareil. Ce qui introduit des bogues, c'est cette manie qu'on certains développeurs à remplacer des caractères utiles par du bruit.

                  • [^] # Re: Ben voyons

                    Posté par  . Évalué à 7.

                    Le rapport est que nombreux sont ceux qui ne comprennent pas les pointeurs. Pourtant c'est simple, je n'ai jamais compris ce qu'il y avait de difficile là dedans. Ensuite, il faut juste un peu de rigueur pour écrire du code correct.

                    C'est pas parce que c'est simple pour toi que c'est simple pour tout le monde.

                    Le reste de ton commentaire c'est un peu de la mauvaise fois: sous prétexte qu'on peut faire compliqué on fais forcément compliqué?

                    Écrit en Bépo selon l’orthographe de 1990

                    • [^] # Re: Ben voyons

                      Posté par  . Évalué à 7. Dernière modification le 11 octobre 2013 à 17:12.

                      C'est pas parce que c'est simple pour toi que c'est simple pour tout le monde.

                      Bah, même pas, je pense que c'est une réaction due à la disparition du souvenir de la difficulté de l'apprentissage. C'est assez facile d'oublier à quel point on a pu bloquer sur des concepts quand on les a appris. Bon, ceci dit, à mon avis, notre ami LupusMic se la joue à fond aussi.Je connais peu de vrais programmeurs qui ressentent le besoin d'expliquer à tout le monde à quel point ils maitrisent les pointeurs :-) Ce genre de comportement est assez fréquent chez les ados ; je l'ai déja expérimenté en trainant sur des forums où j'étais nettement au dessus de la moyenne d'âge : tu demandes une partition de guitare pour débutant, et tu reçois tout un tas de trucs impossibles à jouer, avec en commentaire "essaye sa, C tro fasil pour moi". LupusMic a certainement su rester jeune! :-) J'espère juste qu'il n'enseigne pas et qu'il n'est pas ingénieur, car son incapacité à déceler les problèmes majeurs d'ergonomie et de conception doit rendre la vie impossible a ses utilisateurs.

                      • [^] # Re: Ben voyons

                        Posté par  (site web personnel, Mastodon) . Évalué à -2.

                        Bah, même pas, je pense que c'est une réaction due à la disparition du souvenir de la difficulté de l'apprentissage.

                        Le souvenir que j'ai c'est : « Quoi ? On est 2 sur 25 à comprendre l'arithmétique des pointeurs ? »

                        Ce genre de comportement est assez fréquent chez les ados

                        Je suis un grand enfant, joueur, surtout le vendredi.

                        J'espère juste qu'il n'enseigne pas

                        Détrompe toi, tous ceux qui subissent une formation de ma part en redemande. Ce n'est pas parce que je considère que quelque chose est simple ou évident que ça ne nécessite pas une explication pour les moins subtils d'entre nous. En l'occurrence, pour les pointeurs, du papier, du scotch (ou de la ficelles) et des ciseaux font l'affaire. Pour expliquer un algo de bubble sort, j'utiliserais des boîtes en carton avec des chaussettes, etc.

                        qu'il n'est pas ingénieur

                        Je suis bien pire que ça, un développeur autodidacte (qui est passé par une année de formation à l'AFPA, mais je jouais plus l'assistant que l'élève).

                        car son incapacité à déceler les problèmes majeurs d'ergonomie et de conception doit rendre la vie impossible a ses utilisateurs.

                        En fait, je sais que les utilisateurs sont des imbéciles, donc je fais en sorte que les utilisateurs de mes classes et services aient de la documentation avec des exemples et des tests unitaires.

                        • [^] # Re: Ben voyons

                          Posté par  . Évalué à 0.

                          Le souvenir que j'ai c'est : « Quoi ? On est 2 sur 25 à comprendre l'arithmétique des pointeurs ? »

                          Disons que moi la première c’était Site du Zéro, et comme j’avais pas beaucoup codé à part ça, c’était extrêmement difficile à comprendre. Et puis le temps est passé, et quand j’y suis revenu je comprenais déjà mieux, etc.

                          Donc ça dépend des cas. Une fois qu’on a compris c’est pas si compliqué, mais les pointeurs ça reste quand même assez casse-gueule.

                          Écrit en Bépo selon l’orthographe de 1990

                        • [^] # Re: Ben voyons

                          Posté par  . Évalué à 6.

                          En fait, je sais que les utilisateurs sont des imbéciles, donc je fais en sorte que les utilisateurs de mes classes et services aient de la documentation avec des exemples et des tests unitaires

                          Oui, car la documentation ce n'est que pour les imbéciles. Superbe mentalité…

                          • [^] # Re: Ben voyons

                            Posté par  (site web personnel, Mastodon) . Évalué à 0.

                            Et visiblement tu en es un, puisque tu ne sais pas lire le français. J'ai dis un peu plus haut que je lis la documentation, que c'est l'une des premières choses que je fais, car je sais qu'en abordant un nouvel outil, on est un imbécile. Il ne tien qu'à soi de lire la documentation pour ne pas mal utiliser son éditeur (remplacer des tabs par des espaces) ou un autre outil (confondre espaces et tabulations).

                            • [^] # Re: Ben voyons

                              Posté par  . Évalué à 5.

                              Il ne tien qu'à soi de lire la documentation pour ne pas mal utiliser son éditeur (remplacer des tabs par des espaces) ou un autre outil (confondre espaces et tabulations).

                              C'est une excuse débile. Une scorie peut être documentée, ça n'en reste pas moins une scorie.
                              Avec ce genre de raisonnement, il suffit de documenter les bugs et ça exonère de toute critique.

                              • [^] # Re: Ben voyons

                                Posté par  . Évalué à 3.

                                Qu’entends-tu par «scorie»? J’avoue que le Wiktionnaire ne m’a pas beaucoup aidé.

                                Écrit en Bépo selon l’orthographe de 1990

                              • [^] # Re: Ben voyons

                                Posté par  (site web personnel, Mastodon) . Évalué à -3. Dernière modification le 14 octobre 2013 à 12:20.

                                Sauf qu'en l'occurrence, ce n'est pas une scorie : c'est une fonctionnalité.

                                Tu dois être du genre à considérer que read ou recv est bogué parce qu'il retourne 0 même si le flux c'est pas fermé.

                                • [^] # Re: Ben voyons

                                  Posté par  . Évalué à 3. Dernière modification le 15 octobre 2013 à 14:20.

                                  Sauf qu'en l'occurrence, ce n'est pas une scorie : c'est une fonctionnalité.

                                  Le monsieur ne comparait pas la fonctionnalité à une scorie (le doigt) mais faisait une allégorie en utilisant ton raisonnement (la lune). En clair: une fonctionnalité de merde, même documentée, reste une fonctionnalité de merde.

                    • [^] # Re: Ben voyons

                      Posté par  (site web personnel, Mastodon) . Évalué à -3.

                      Mais bien évidement qu'on ne suit surtout pas le mantra simpliste KISS :o)

                  • [^] # Re: Ben voyons

                    Posté par  . Évalué à 4.

                    Le rapport est que nombreux sont ceux qui ne comprennent pas les pointeurs.

                    Ouais, donc il n'y a aucun rapport.

                    Sous prétexte qu'un éditeur de texte limité ne montre pas la différence

                    Foutaises. Reformule correctement : "Quelques éditeurs de texte spécialisés sont capables de montrer un différence". Ça n'a rien à voir. Les outils Unix de base (less, more, vi, gedit…) ne montrent pas de différence, DONC ça va induire des gens en erreur. Ton éditeur magique qui fait la différence par défaut, on ne sait même pas ce que c'est. De toutes manières, il va te polluer la tronche quand tu édites du code pour les autres langages, puisque tu vas voir des différences là où le compilo n'en voit pas.

                    C'est un peu comme se plaindre que « présentent » et « présentes » ne se distinguent pas à l'oreille : avec le contexte grammatical, il n'y a pas de doute.

                    "On admet que les personnes présentent" ; "On n'admet que les personnes présentes".

                    En fait, tu reproduis le schéma du type qui nie les erreurs de conception. 1) tu nies les erreurs quand tout le monde les voit sauf toi (typiquement, "je sais contourner les bugs parce que je suis plus intelligent que vous, donc ce n'est pas un bug"), et tu nies les problèmes que les autres rencontrent parce qu'il ne t'es jamais venu à l'esprit qu'un tel problème pouvait arriver. J'espère franchement que tu n'es pas ingénieur et que tu ne conçois rien, parce qu'autrement je plains tes utilisateurs.

                    • [^] # Re: Ben voyons

                      Posté par  . Évalué à 1.

                      vi, gedit

                      Ouai enfin c'est l'utilisateur qui a décidé de leur faire faire des expands tab. Donc par défaut avec les outils de base d'unix c'est espace à 1 caractère que l'on tape avec la barre d'espace et la tabulation à 8 caractères de large et qui se tape avec le bouton tabulation. C'est à mon humble avis une différence bien plus significative que oO0°.

                      Je suis d'accord que le design du langage de make est problématique, mais ton argument est faux.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Ben voyons

                        Posté par  . Évalué à 4.

                        Ouai enfin c'est l'utilisateur qui a décidé de leur faire faire des expands tab

                        Relis ce qu'il a dit : « Les outils Unix de base (less, more, vi, gedit…) ne montrent pas de différence ».
                        Le problème n'est pas seulement à l'édition, mais bien à la relecture.
                        Ensuite il est un peu faible d'incriminer l'utilisateur pour un changement de configuration qu'il a effectué un jour (peut-être il y a longtemps) sans se douter que cela poserait problème avec les Makefile.

                    • [^] # Re: Ben voyons

                      Posté par  (site web personnel, Mastodon) . Évalué à -4.

                      Les outils Unix de base (less, more, vi, gedit…) ne montrent pas de différence.

                      cat >> ~/.vimrc
set listchars=eol:$,tab:^ˇ,trail:…,extends:→,precedes:←,nbsp:¿
set list
^D

                      You're welcome.

                      "On admet que les personnes présentent" ; "On n'admet que les personnes présentes".

                      Il manque un verbe dans ta seconde phrase.

                      tu nies les problèmes que les autres rencontrent

                      Je ne les nie pas, je suis tout à fait au fait que les utilisateurs ne lisent pas la documentation et viennent ensuite se plaindre que ça ne marche pas.
                      Quand on utilise un outil, on lit la notice avant. C'est une règle de base que j'ai apprise quand j'étais technicien dans la chimie, c'est un peu une nécessité de survie.
                      En informatique, c'est pareil. Enfin, ça devrait être pareil. Je sais bien que la mode est à supprimer des fonctionnalités, ou les cacher, mais j'ai tendance à considérer l'informatique comme un outil de travail.

                      Pour tes espérances, voir mon précédent message où j'ai répondu à cette vile attaque.

                      • [^] # Re: Ben voyons

                        Posté par  . Évalué à 4.

                        Il manque un verbe dans ta seconde phrase.

                        Non.

                      • [^] # Re: Ben voyons

                        Posté par  . Évalué à 3.

                        Même en connaissant la règle, je ne suis pas sûr qu’on y pense spontanément.

                        Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Ben voyons

                  Posté par  . Évalué à 5.

                  de la m**** dans les yeux […]

                  Ceci dit, utiliser * pour déréférencer un pointeur, ça peut commercer à ressembler à une ergonomie douteuse.

                  Donc si je comprends bien, m**** est un pointeur de m***?

                  -->[]

        • [^] # Re: Ben voyons

          Posté par  (site web personnel) . Évalué à 2.

          d'utiliser la tabulation pour les commandes dans les makefiles

          Il est clair que c'est une énorme boulette MAIS elle aurait pu être corrigée depuis longtemps. Par exemple, il aurait été facile de faire une règle telle que

          s/^\s*->\s*/\t/

          En gros, toute ligne commençant par '->' est équivalente à une ligne commençant par une tabulation. Au bout d'une dizaine d'année, la tabulation aurait petit à petit disparu et un jour, on aurait pu la rendre obsolète. Pas mal d'année de perdus…

          • [^] # Re: Ben voyons

            Posté par  (site web personnel, Mastodon) . Évalué à 0. 

            target:
->@cc -o target.o $(OBJS)

            Oui, évidement, c'est tellement plus lisible et plus rapide à taper que l'ensemble des développeurs auraient… ben n'auraient rien fait.

            • [^] # Re: Ben voyons

              Posté par  (site web personnel) . Évalué à 4.

              Il faut arrêter de tout vouloir optimiser au caractère près et croire que tous les développeurs ne basculeraient pas, pour trois touches, sur un système lisible. De plus, une partie des Makefiles sont crées automatiquement…

              target:
 -> @cc -o target.o $(OBJS)

              Le gros avantage, c'est qu'on voit si c'est dans le même shell ou non…

              target:
 -> @cc -o target.o \
    $(OBJS)
 -> @echo toto

              En plus, pour éviter l'arobase en début de ligne, on pourrait avoir deux types de flèches… Bref, c'est juste une proposition pour avoir un truc plus lisible pour un coût faible.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 5. Dernière modification le 13 octobre 2013 à 23:59.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Ben voyons

                  Posté par  (site web personnel, Mastodon) . Évalué à -4.

                  Oui, ce sont des gens qui n'utilisent pas les outils adaptés, et qui se plaignent de l'inadéquation de l'outil manipulé plutôt que de l'outil manipulant.

                  C'est pathétique.

      • [^] # Re: Ben voyons

        Posté par  . Évalué à -10.

        Je me rappelle de ce sentiment indescriptible quand je me suis rendu compte après des heures de déboggage que les tabs et les espaces étaient interprétés différemment dans le Makefile.

        Ah oui tu parles de quand tu ne connaissais simplement la syntaxe basique de make ?
        Dire qu'un outil est pourri parce qu'on n'a pas fait l'effort de l'apprendre un minimum c'est un peu fort.

        • [^] # Re: Ben voyons

          Posté par  . Évalué à 10.

          On a le droit de dire qu'une syntaxe est pourrie, par exemple GNU make vient d'implémenter l'opérateur d'affectation != pour affecter une variable de shell, c'est une syntaxe pourrie (pour être poli), dans la majorité des langages != ça veut dire "différent de", donc ça va être bien pénible à lire du code avec ça.
          Bon je ne peux même pas taper sur GNU make: ça vient des makefiles BSD cette syntaxe m…

        • [^] # Re: Ben voyons

          Posté par  . Évalué à 10.

          Dire qu'un outil est pourri parce qu'on n'a pas fait l'effort de l'apprendre un minimum c'est un peu fort.

          Ça s'appelle une ergonomie dégueulasse, et je pense que c'est un critère pour dire qu'un outil est pourri. Parfois, il faut aussi arrêter de chercher des excuses aux erreurs grossières de conception. Se cacher derrière RTFM, c'est trop facile.

          Je te vends un robinet où l'eau chaude sort du côté bleu : RTFM!
          Je fabrique une bagnole pour laquelle il faut tourner le volant vers la gauche pour diriger les roues à droite : RTFM!

          Il existe des règles de base d'ergonomie. Il est élémentaire que des expressions visuellement identiques soient sémantiquement identiques ; seul un psychopathe pourrait prétendre le contraire.

          Ah oui tu parles de quand tu ne connaissais simplement la syntaxe basique de make ?

          J'avais configuré mon éditeur de texte pour qu'il remplace les tabs par un nombre d'espaces de mon choix. J'ai ouvert le Makefile, modifié une variable, sauvé le Makefile. Tu percutes pourquoi j'ai mis des jours à débugger le truc? J'aurais RTFM des dizaines de fois que ça n'aurait rien changé. Franchement, je trouve que tu défends l'indéfendable : donner une sémantique différente aux espaces et aux tabulations, c'est une idée tellement conne qu'elle a été réutilisée pour faire une variante du Brainfuck. À part jouer à l'"31337" avec tes potes, ça peut servir à quoi dans le monde réel?

          • [^] # Re: Ben voyons

            Posté par  . Évalué à 1.

            Il existe des règles de base d'ergonomie. Il est élémentaire que des expressions visuellement identiques soient sémantiquement identiques ; seul un psychopathe pourrait prétendre le contraire.

            On a bien les espaces insécables en typographie française… Je pourrais ajouter que quand on fais des fictions interactives sur playfic.com ou avec inform7 sous Windows (si je ne me trompe pas), les espaces ne passent pas…

            Enfin bref, loin de moi l’idée d’excuser une telle ânerie, m’enfin ce ne seront ni les premiers ni les derniers à faire ce genre de bêtise (malheureusement). Mais ça pourrait être changé, il faudrait donc vérifier s’il y a un rapport de bug à ce sujet.

            J'avais configuré mon éditeur de texte pour qu'il remplace les tabs par un nombre d'espaces de mon choix. J'ai ouvert le Makefile, modifié une variable, sauvé le Makefile. Tu percutes pourquoi j'ai mis des jours à débugger le truc?

            Sans chercher à défendre GNU Make, ton éditeur de texte est incapable d’afficher espaces et tabulations différemment?

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Ben voyons

              Posté par  . Évalué à 5.

              On a bien les espaces insécables en typographie française…

              Elles ont la même sémantique qu'une espace traditionnelle pour le compilateur (le lecteur). Et dans l'éditeur de texte, normalement, il y a un artifice pour les faire apparaitre différemment (grisé, ou n'importe).

              Sans chercher à défendre GNU Make, ton éditeur de texte est incapable d’afficher espaces et tabulations différemment?

              Certainement, mais là n'est pas la question ! Évidemment qu'une fois que le problème a été identifié, il est facile de trouver des solutions. Là, le problème était qu'il n'y avait aucun moyen pour un être humain d'identifier la nature du problème.

              On sait tous qu'il existe pas mal de caractères qui ont des glyphes proches, voire identiques: le codage ASCII et le rendu dans les éditeurs de texte ne sont pas bijectifs. Un langage de programmation devant être lisible à la fois par un homme et par une machine, il me semble élémentaire d'utiliser une sous-partie du jeu de caractères qui est clairement bijective. Certaines réactions me donnent l'impression que certains considèrent que c'est la machine qui devrait avoir le dernier mot : l'utilisateur devrait se démerder pour utiliser un éditeur de texte avec une fonction spéciale pour distinguer visuellement des caractères habituellement identiques. C'est un point de vue que j'ai du mal à comprendre : le chef, c'est moi, c'est pas la machine.

              Tiens, je vais concevoir un langage Brainfuck où seule la fonte est signifiante: g g g g g g g . Tu codes dans LibreOffice, tu copies-colles dans vi et tu exécutes. Comment? La machine ne peut pas faire la différence? Pourtant, pour moi, elle est claire! La machine n'a qu'à se démerder. C'est exactement le même processus, sauf que cette fois on donne la priorité à l'utilisateur. Ah oui, ça ne marche pas. Mais c'était pareil dans l'autre sens.

              • [^] # Re: Ben voyons

                Posté par  . Évalué à -2.

                Elles ont la même sémantique qu'une espace traditionnelle pour le compilateur (le lecteur).

                Je te garantie qu'il y a plein de langages qui ne compilent pas avec des espaces insécables en dehors des chaines de caractères.

                Certainement, mais là n'est pas la question ! Évidemment qu'une fois que le problème a été identifié, il est facile de trouver des solutions. Là, le problème était qu'il n'y avait aucun moyen pour un être humain d'identifier la nature du problème.

                On sait tous qu'il existe pas mal de caractères qui ont des glyphes proches, voire identiques: le codage ASCII et le rendu dans les éditeurs de texte ne sont pas bijectifs.

                À part les conneries typographiques genre espaces insécables, je vois pas.

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Ben voyons

                  Posté par  . Évalué à 2.

                  À part les conneries typographiques genre espaces insécables, je vois pas.

                  Si on parle d'unicode (en ASCII il n'y a pas d'espace insécable que je sache) en espacement tu as les espaces fine, normal, demi-cadratin, cadratin, insécables fine et normal qui sont identiques avec une police à taille fixe. Mais tu as aussi des caractères qui sont proches entre les langages (suffisamment pour embrouiller quiconque) et je crois que tu as des caractères qui intègrent leur diacritique et qui peuvent donc être construit soit directement soit en 2 caractères (le caractère de base et le diacritique). Va différencier un « c cédille » d'un « c avec une cédille ».

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Ben voyons

                    Posté par  . Évalué à 4.

                    Si on parle d'unicode (en ASCII il n'y a pas d'espace insécable que je sache) en espacement tu as les espaces fine, normal, demi-cadratin, cadratin, insécables fine et normal qui sont identiques avec une police à taille fixe.

                    Je me cite:

                    À part les conneries typographiques genre espaces insécables, je vois pas.

                    Je voulais donc parler des espaces typographiques en général.

                    Mais tu as aussi des caractères qui sont proches entre les langages (suffisamment pour embrouiller quiconque)

                    Pas dans les polices à chasse fixe en général. De plus, par convention, on utilise l'ASCII pour la syntaxe et les déclarations.

                    et je crois que tu as des caractères qui intègrent leur diacritique et qui peuvent donc être construit soit directement soit en 2 caractères (le caractère de base et le diacritique). Va différencier un « c cédille » d'un « c avec une cédille ».

                    Tu parles des caractères combinant. Je sais pas comment tu fais pour les taper mais par défaut on n'en a pas. Et comme dit au-dessus, on utilise l'ASCII.

                    Écrit en Bépo selon l’orthographe de 1990

                    • [^] # Re: Ben voyons

                      Posté par  . Évalué à 3.

                      Pas dans les polices à chasse fixe en général. De plus, par convention, on utilise l'ASCII pour la syntaxe et les déclarations.

                      D'un autre côté, les polices à chasse fixe ont été désambiguées, justement pour éviter les confusions. L'exemple le plus frappant est O/0, avec les petits machins (barres, points) dans le zéro. Parfois, distinquer les différents types de quotes "`' n'est pas super facile, et certaines combinaisons de caractères peuvent être assez perturbantes (<>, ><, -=>, etc) mais ça n'a quand même rien à voir avec tab et space…

                • [^] # Re: Ben voyons

                  Posté par  . Évalué à 3.

                  Je te garantie qu'il y a plein de langages qui ne compilent pas avec des espaces insécables

                  Échouer à la compilation et sortir un message d'erreur informatif, c'est moins gênant que d'avoir silencieusement un comportement imprévu.

                  • [^] # Re: Ben voyons

                    Posté par  . Évalué à 0.

                    Oui, mais sur le mot d’erreur sur la sortie standard, on ne voit pas le problème vu que les espaces typographiques sont affichées comme des espaces: par un vide.

                    Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Ben voyons

                Posté par  (site web personnel, Mastodon) . Évalué à -6.

                Là, le problème était qu'il n'y avait aucun moyen pour un être humain d'identifier la nature du problème.

                Un être humain équipé d'un cerveau, ayant lu le manuel de make et sachant utiliser son éditeur, peut aisément se douter du problème. Ton éditeur de texte n'est pas adapté à modifier du code, c'est tout.

                l'utilisateur devrait se démerder pour utiliser un éditeur de texte avec une fonction spéciale pour distinguer visuellement des caractères habituellement identiques

                Mais on parle de deux caractères qui n'ont pas du tout le même rendu, mais que certains confondent avec un nombre d'espaces arbitraires.

                • [^] # Re: Ben voyons

                  Posté par  . Évalué à 2.

                  Mais on parle de deux caractères qui n'ont pas du tout le même rendu

                  Ah ouais, t'as raison. Y'en a qui est un petit truc transparent, et l'autre qui est un gros truc transparent.

                  D'ailleurs, c'est tellement frappant qu'on a créé le Whitespace sur la base de ce concept innovant.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 0. Dernière modification le 11 octobre 2013 à 16:43.

                    Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Ben voyons

              Posté par  (site web personnel) . Évalué à 2.

              Je pourrais ajouter que quand on fais des fictions interactives sur playfic.com ou avec inform7 sous Windows (si je ne me trompe pas), les espaces ne passent pas…

              si on rajoute des espaces insécables dans inform7, c'est pris en compte dans le code (pas de retour à la ligne à cet endroit), mais au rendu ça semble être converti en espaces normales. Testé uniquement sous Linux (gnome-inform7).

              « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

              • [^] # Re: Ben voyons

                Posté par  . Évalué à 2.

                Non mais en fait je pensais à l’utilisation des espaces au lieu des tabulations pour indenter le code.

                Tu as réussi à créer un projet? Chez moi ça segfault, je suis obligé de créer le projet avec l’interface en ligne de commande.

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Ben voyons

                  Posté par  (site web personnel) . Évalué à 2.

                  Il n'y a pas vraiment d'indentation obligatoire dans inform7. En revanche, pour les conditions, il y a possibilité d'utiliser soit la forme longue avec "begin" etc, soit la forme courte qui utilise une syntaxe façon python et qui pose problème dès que l'on décale l'indentation, du coup je ne l'utilise jamais.

                  Je crée tous mes jeux depuis l'interface gnome-inform7, mais c'est assez plantogène depuis le temps que c'est sorti, et je n'ai pas le courage d'essayer de tout recompiler. Une nouvelle version ne devrait pas tarder de toute façon.

                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                  • [^] # Re: Ben voyons

                    Posté par  . Évalué à 2.

                    Ah je ne savais qu’il y avait une autre syntaxe, il va falloir que je regarde ça. D’ailleurs je me suis rendu compte que Chromium permettait FACILEMENT de rentrer une tabulation dans une zone de texte, simplement en appuyant sur la touche… (je ne sais pas comment sortir de la zone de texte après par contre)

                    Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Ben voyons

            Posté par  . Évalué à 3.

            Complètement d'accord avec toi ..
            Appliquer ce principe de moindre surprise (le moins de questions on se pose, moins on comprend de travers) à la conception permet un gain de temps énorme à l'utilisation, debug, support…

          • [^] # Re: Ben voyons

            Posté par  (site web personnel, Mastodon) . Évalué à -6.

            Je te vends un robinet où l'eau chaude sort du côté bleu : RTFM!

            En chimie, le robinet d'eau est indiqué par un code couleur vert. Le bleu indique une robinet d'air.

            Je fabrique une bagnole pour laquelle il faut tourner le volant vers la gauche pour diriger les roues à droite : RTFM!

            On appelle ça le contrôle inversé, il y a des gens qui trouvent ça très intuitif.

            J'avais configuré mon éditeur de texte pour qu'il remplace les tabs par un nombre d'espaces de mon choix.

            Si aussi tu fais n'importe quoi. C'est une des raisons qui font que, pour moi, un gars qui considère qu'une '\t' c'est ' ', c'est un branquignole.

            donner une sémantique différente aux espaces et aux tabulations

            En fait, c'est des tabulation horizontales dont nous parlons. Les tabulations verticales ont une sémantique encore différente. Cependant, explique moi à quoi servent les tablulations si elles ne peuvent servir à charrier une sémantique différente.

            À part jouer à l'"31337" avec tes potes, ça peut servir à quoi dans le monde réel?

            Déboguer des Makefiles.

          • [^] # Re: Ben voyons

            Posté par  (site web personnel) . Évalué à 2.

            Franchement, je trouve que tu défends l'indéfendable : donner une sémantique différente aux espaces et aux tabulations, c'est une idée tellement conne qu'elle a été réutilisée pour faire une variante du Brainfuck.

            Je suis bien d'accord. Et c'est tellement con que c'est d'ailleurs un peu un principe de base dans python : si tu remplaces 4 espaces par une tabulation ou l'inverse, ça pète le code. Tellement pratique quand tu récupères du code depuis une page web, tu dois tout réindenter.

            « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 0. Dernière modification le 14 octobre 2013 à 00:06.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Ben voyons

                Posté par  (site web personnel) . Évalué à 5.

                J'espère quand même que tu te rends compte que ça n'a rien à voir : dans l'exemple donné, c'est quand on colle directement dans un terminal.

                Jusqu'à preuve du contraire, peu de gens développent avec l'interpréteur python en mode interactif, ils tapent leur code source dans un éditeur de texte, et ce genre de bidouille révèle directement le code "caché" quand on le colle.

                « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 0. Dernière modification le 14 octobre 2013 à 13:48.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Ben voyons

                    Posté par  . Évalué à 1.

                    Sauf que cette backdoor n'a jamais été intégrée au code officiel du noyau.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Ben voyons

          Posté par  . Évalué à 10. 

          No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the interpretation of a makefile can change drastically on the basis of invisible differences in whitespace.

          Eric S. Raymond, "The Art of Unix Programming"
          http://www.faqs.org/docs/artu/ch15s04.html

      • [^] # Re: Ben voyons

        Posté par  (site web personnel) . Évalué à 1.

        Je me rappelle de ce sentiment indescriptible quand je me suis rendu compte après des heures de déboggage que les tabs et les espaces étaient interprétés différemment dans le Makefile. Ça doit ressembler à ce que ressent la petite fille quand elle se rend compte qu'il y a un ogre ou une soricère dans la maison en pain d'épice et qu'elle est coincée dedans.

        C'est parce que bien avant d'intégrer Guile, Make était une extension du langage Whitespace !
        ---> []

    • [^] # Re: Ben voyons

      Posté par  . Évalué à 2.

      Peuf ! un vrai hacker n'a pas besoin de debugging surtout pour un truc aussi basique ;-)

      • [^] # Re: Ben voyons

        Posté par  . Évalué à 2.

        Quel truc "aussi basique" ? Quand tu fait du makefile GNU (c'est généralement que tu n'a pas le choix, mais passons), tu peut te retrouver à faire des trucs assez compliqués avec des bugs à l'intérieur.

  • # wouhou

    Posté par  (site web personnel) . Évalué à 10.

    La possibilité d'écrire des extensions en Guile justifie l'incrément de la version majeure.

    C'est une formidable nouvelle pour les 3 personnes qui connaissent ce langage !

    • [^] # Re: wouhou

      Posté par  (site web personnel) . Évalué à 7.

      GNU Guile est un interpréteur du langage de programmation Scheme (avec des extensions). Scheme est classé 37e langage dans le Programming Community Index for September 2013. C'est certes moins prestigieux que les 10 premiers (C, Java, C++, Objective-C, PHP, C#, VB, Python, Javascript et Transact-SQL) mais toujours mieux que d'autres (Prolog, D, Tcl, Scala, Haskell, Go, etc.), dont certains plutôt à la mode (Scala et Go par exemple). Certes ça limite le nombre de développeurs.

      • [^] # Re: wouhou

        Posté par  (site web personnel) . Évalué à 10.

        Ça donne une idée de la pertinence de cet index…

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: wouhou

          Posté par  . Évalué à 6.

          On trouve des chiffres plus compatibles avec la mode en corrélant les statistiques de StackOverflow et GitHub.

          • [^] # Re: wouhou

            Posté par  . Évalué à 8.

            Pas mal, cet index basé sur les lignes de code modifiées. La discussion qui me vient est que quand tu changes 4 lignes en Python, la modification sémantique équivalente en C peut aller jusqu'à 20 ou 30, ce qu'on peut pondérer quand on vient comme moi de lire du code Python écrit par les plus gros prolifiques de code Python du monde (en ligne/mois).

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: wouhou

      Posté par  . Évalué à 6.

      le langage est Scheme, Guile est le compilateur/interpreteur.
      Scheme est un dialect Lisp (différent de Common Lisp).

      Guile permettrait (d'après son site web) aussi d'utiliser ECMAScript, Emacs Lisp (et peut-être Lua prochainement).

    • [^] # Re: wouhou

      Posté par  . Évalué à 10.

      Ah ben j'allais demander poliment qui utilise Guile pour de vrai?

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -1.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: wouhou

          Posté par  . Évalué à 1.

          Question suivante : qui joue réellement aux GNOME Games ?

          D'ailleurs, vues leurs dernières évolutions, pourquoi autant travailler dessus alors qu'il reste tant de boulot sur le reste du bureau ? GNOME Music et GNOME Photos me paraissent bien plus prioritaires pour un bureau moderne…

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: wouhou

            Posté par  . Évalué à 3.

            Et bien on attend tes contributions.

            • [^] # Re: wouhou

              Posté par  . Évalué à 10.

              Je défends GNOME dans les trolls, c'est ça ma contribution. Et je peux te dire que c'est pas facile, quand il n'y a que les jeux qui sont finis…

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: wouhou

            Posté par  (site web personnel) . Évalué à 4.

            Je pense surtout que ce ne sont pas les mêmes personnes qui développent ces différents logiciels et que par conséquent tout évolue de manière parallèle.

            Même problématique avec KDE, n'oublions pas que la seule section bien terminée lors de la version 4.0 étaient les jeux aussi.

            • [^] # Re: wouhou

              Posté par  . Évalué à 2.

              Je veux bien, mais il y a une gestion de projet, un comité au-dessus, ils ne peuvent pas gérer les ressources ?
              D'autant que des boîtes comme Red Hat payent des gens pour développer GNOME (plus que sur KDE, en tout cas), ce n'est pas eux qui décident des priorités ?

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: wouhou

                Posté par  . Évalué à 3.

                Je veux bien, mais il y a une gestion de projet, un comité au-dessus, ils ne peuvent pas gérer les ressources ?

                Les "ressources" étant des volontaires, non.

                D'autant que des boîtes comme Red Hat payent des gens pour développer GNOME

                Red Hat vendant du support aux grosses entreprises, s'ils développent GNOME c'est plutôt pour une utilisation type station de travail:
                je pense qu'ils n'en ont rien à faire des jeux, de GNOME Music ou de GNOME Photos..

                • [^] # Re: wouhou

                  Posté par  . Évalué à 3.

                  Les "ressources" étant des volontaires, non.

                  OK. Mais alors à quoi sert le comité, à part faire de la communication ? C'est dommage de faire de la com' pour un produit pas toujours complet…

                  Red Hat vendant du support aux grosses entreprises, s'ils développent GNOME c'est plutôt pour une utilisation type station de travail:

                  J'ai écrit « des boîtes comme Red Hat », il n'y a pas que Red Hat. Il y a aussi Immendio ou Fluendo, par exemple, et il doit y en avoir d'autres qui travaillent sur le côté grand public.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: wouhou

          Posté par  . Évalué à 5.

          Aisleriot (also known as Solitaire or sol) is a collection of card games which are easy to play with the aid of a mouse

          Dire que je ne connaissais pas ce chef d'œuvre ! Un jeu de cartes, qui en plus se joue à la souris… On peut louer la créativité des développeurs GNOME.

          • [^] # Re: wouhou

            Posté par  . Évalué à 9.

            En même temps, installe-toi devant ton clavier et ton éditeur favori, et maintenant essaie de pondre une description courte, accrocheuse et enthousiaste d'un… jeu de réussite…

  • # Guile

    Posté par  (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 10 octobre 2013 à 16:09.

    On va enfin pouvoir jeter ant et l'autre machin en Python qui pue… ah, ça me revient : Scons !

    • [^] # Re: Guile

      Posté par  (site web personnel) . Évalué à 7.

      Il y avait déjà CMake pour remplacer ces horreurs.

      D'ailleurs CMake génère des Makefiles ; on va pouvoir faire des scripts CMake qui génèrent du Makefile Guile qui génère du CMake…

  • # Chouette ! Avec Guile on va pouvoir faire exploser son code…

    Posté par  . Évalué à 10.

    À grands coups de Sonic Boom.

    Je suis déjà dehors ! =======>[ ]

    cd /pub && more beer

  • # Moi j'aime bien

    Posté par  (site web personnel) . Évalué à 3.

    Pour des cas assez simple, je trouve que faire un makefile a du bon, une fois ajouter deux trois commandes, clean, test, fig par exemple, on ne se pose plus trop de question.
    Genre pour faire du latex, tu compiles trois fois ton pdflatex, avec une fois au milieu ton bibtex, je génère également les images avec ipe au passage. Bref, ça roule, ça prends deux minutes en début de document à créer et après, ça me fait gagner vraiment pas mal de temps.

    Vous faites comment pour ceux qui n'aime pas pour "automatiser" un peu le tout ?
    Vous faites des scripts bash ?

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

    • [^] # Re: Moi j'aime bien

      Posté par  . Évalué à 1.

      L'approche de plus en plus utilisée c'est d'avoir un outil spécifique par langage/framework/usage, par exemple pour latex l'excellent latexmk te dispenserais de faire ton makefile, en te permettant de choisir une compilation par pdflatex, par latex+dvips+ps2pdf, par luatex…
      Pour python ya scons (je sais pas si il est bon), pour haskell ya cabal, pour java ya maven, etc.

      • [^] # Re: Moi j'aime bien

        Posté par  (site web personnel) . Évalué à 3.

        scons n'est pas un outil pour python, c'est juste un outil en python, mais il gère la majorité des langages. C'est ce que j'utilise , c'est très puissant , très souple, un peu lent. J'aime la garantie d'avoir tout le temps des builds corrects et le cache integré.

    • [^] # Re: Moi j'aime bien

      Posté par  . Évalué à 3.

      Vous faites des scripts bash ?

      Des alternatives, il y en a des pelles (lire les commentaires est aussi intéressant que la dépêche) :
      https://linuxfr.org/news/petit-%C3%A9ventail-des-outils-de-construction-builder-libres
      (c'est plus tout jeune mais ça n'évolue pas si vite, il manque principalement rake je trouve)

      Donc sans make, il reste ninja, omake et bien d'autres.

      Pour latex, j'essaie de ne plus utiliser de makefile parce que c'est trop long. Tu n'a pas toujours besoin de compiler 3 fois et il faut aller voir la sortie de pdflatex pour le savoir, c'est pas amusant à faire (je ne me souviens jamais de ce que je dois y chercher) donc un outil spécifique c'est agréable (quitte à intégrer celui-ci dans un makefile pour gérer moi-même la compilation des images par exemples).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Moi j'aime bien

        Posté par  . Évalué à 3.

        Au passage, après waf et ninja, j'ai entendu parler de tup dernièrement qui me semble plutôt intéressant.

    • [^] # Re: Moi j'aime bien

      Posté par  . Évalué à 1.

      Comme dit plus haut, pour latex, par bonheur, il existe des outils dédiés. Je crois que je serai au html sinon ( oui, je trouve plus simple de faire du traitement de texte avec html qu'avec un truc comme word… sachant que je me limite à faire des titres, du texte souligné, éventuellement caler une nimage… bref, pas besoin des macros et autres monstruosités qui font la "puissance" de word parait-il).
      Il faut déjà apprendre latex lui-même (ça va encore cela dit) alors devoir se taper make en plus… non merci, vraiment.

      Pour le reste, enfin, surtout le C++ dans mon cas, soit je fait un truc rapide qui prend 2-3 fichiers et je fait un "script" bash (enfin… je tape ma ligne dans le terminal, et si ça passe je l'envoie direction un fichier texte auquel je colle un chmod+x) ou pour les vrais projets, j'utilise cmake, dont le seul défaut que j'aie trouvé est d'avoir une dépendance en dur à emacsen pour une raison que j'ignore (sous Debian du moins). Je n'utilise même pas la GUI de ce machin, la syntaxe étant moins prise de tête.
      L'avantage, c'est que selon mon humeur et ma plate forme, ça me génère un makefile, un vcproj ou … bref, un truc utilisable avec les outils de la plate forme.

      Pas testé les autres alternatives, et je me sens pas l'humeur non plus: j'en ai un qui est simple et qui marche, ça me va. C'est un outil annexe, une contrainte, une plaie, je ne prend pas de plaisir a créer des fichiers de projet moi, seulement à réaliser le projet lui-même. Si je pouvais m'en abstenir, je le ferais d'ailleurs (et non, les IDE ne le permettent pas, pire, il faut souvent ajouter les fichier manuellement 1 par 1… quelle horreur. J'imagine que certains ont réglé ce souci, tant mieux pour leurs utilisateurs, mais pas ceux dont j'apprécie à peu près l'IHM)

    • [^] # Re: Moi j'aime bien

      Posté par  (site web personnel) . Évalué à 3.

      je trouve également que Make va pas trop mal (genre "make pdf, make html etc"), c'est rapide à taper et disponible partout, par contre c'est vrai que c'est pas très souple ni toujours très intuitif.

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

Suivre le flux des commentaires

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