SQLite 3.8.0 : n'ayez pas peur du zéro

Posté par  . Édité par Florent Zara, palm123, Benoît Sibaud et Xavier Teyssier. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
47
13
sept.
2013
Base de données

SQLite, la plus petite des bases de données est sortie en version 3.8.0 le 26 août et est disponible en version 3.8.0.2 depuis le 3 septembre. C'est une base de données qui sort du schéma client/serveur habituel. Elle s'utilise en effet sous forme de bibliothèque, la plupart du temps directement embarquée par les applications.

Logo SQLite

L'incrémentation du numéro de révision mineure de 7 à 8 marque le passage à un nouveau générateur de plan d'exécution.
Celui-ci est sobrement appelé NGQP (next generation query planner) c'est-à-dire générateur de plan d'exécution de nouvelle génération. Ce nouveau générateur est plus rapide et fournit de meilleurs plan d'exécution à vos applications (à l'exception de son utilisation dans Fossil… mais c'est corrigé :o)).

L'autre ajout important est le support des index partiels. Ces index sont construits de la même façon que les index habituels, mais l'ajout d'une condition WHERE à la fin de leur définition vous permet de restreindre la plage de données. Ces index peuvent alors être moins volumineux et réduire les temps de traitement : moins de place, moins d'analyse. SQLite n'utilise pas de résolution sophistiquée pour faire le lien entre requête et index partiel. Il faut donc que les clauses WHERE entre ceux-ci soient les plus proches possible.

Aller plus loin

  • # nosql embarqué ?

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

    Hello, est-ce qu'il existe un base nosql qui s'embarque de la même façon que sqlite ? Un truc qui garanti l'intégrité du fichier, mais dont on se fout un peu du coté "ACID" ?

    C'est histoire de dépasser les 100 transactions par seconde.

    "La première sécurité est la liberté"

    • [^] # Re: nosql embarqué ?

      Posté par  . Évalué à 6.

      À partir du moment où tu veux conserver l'intégrité du fichier, tu n'es pas loin du côté ACID.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: nosql embarqué ?

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

        Oui, mais c'est surtout histoire de résister à une coupure de courant, et un kill -9.

        "La première sécurité est la liberté"

        • [^] # Re: nosql embarqué ?

          Posté par  . Évalué à 7.

          Du coup, il faut faire des fsync tout le temps et c'est ça qui est bien plus limitant qu'autre chose.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: nosql embarqué ?

          Posté par  . Évalué à 4.

          Pour résister à un kill -9 et (plus encore) à une coupure de courant il faut que l'écriture ai été faite physiquement sur une mémoire persistante (disque…) avant de rendre la main à l'application qui a terminé une transaction (lors d'un commit s'il y a des commits). Pour chaque transaction.

          Ça se fait avec fsync, msync ou les équivalent de la libaio si on utilise les i/o asynchrones Linux.

          Ça ne dépend pas du type de base de données ou de stockage (même fichier voire accès disque direct (raw device)). Et en général c'est le facteur limitant lors d'écritures.

          C'est exactement le D de ACID. Donc tu t'en fiches peut-être de ACI mais manifestement pas de D.

      • [^] # Re: nosql embarqué ?

        Posté par  . Évalué à 4.

        Ben non, ça dépend ce que tu appelles intégrité. Tu peux très bien conserver l'intégrité du fichier tout en retardant toutes les écritures d'un nombre arbitraire de secondes : tu conserves alors l'intégrité d'une version légèrement obsolète des données.

        C'est pour ça que ACID comporte 4 propriétés. Tu peux avoir un système qui respecte les 3 premières (ACI) mais pas la durabilité (D), à savoir qu'une transaction n'est pas garantie d'être sur le disque lorsqu'elle est committée.

    • [^] # Re: nosql embarqué ?

      Posté par  . Évalué à 0.

      on se fout un peu du coté "ACID"

      et

      C'est histoire de dépasser les 100 transactions par seconde.

      Je peux me tromper mais il n'y a pas de transaction avec les bases NoSQL.

      Je présume que ce que tu cherche c'est une bibliothèque de sérialisation. Apparemment EET est très performante, mais je ne sais pas ce qu'il en est de sa gestion des erreurs.

      Sachant que de toute manière plus tu garanti l'intégrité du fichier, plus tes performances vont décroitre…

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

    • [^] # Re: nosql embarqué ?

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

      NoSQL n'ayant pas de sens particulier à part être la mode, il faut préciser la question.

      Si c'est une base de donnée clé-valeur, tu as la vénérable BerkeleyDB, ou en plus récent et performant LevelDB.

      • [^] # Re: nosql embarqué ?

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

        LevelDB a l'air pas mal : Environ 5x plus rapide que SQLite.

        "La première sécurité est la liberté"

        • [^] # Re: nosql embarqué ?

          Posté par  . Évalué à 3.

          LevelDB a l'air pas mal : Environ 5x plus rapide que SQLite.

          C'est vite dit ça…
          http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html

          Ça dépend en fait vraiment du type de requêtes. Par exemple en random read il est légèrement moins bon que sqlite.

          • [^] # Re: nosql embarqué ?

            Posté par  . Évalué à 5. Dernière modification le 13 septembre 2013 à 15:05.

            Et en Synchronous Writes (ce qui est la demande, vu qu'il faut résister à un panne de courant), LevelDB est 10% plus rapide que SQLite. Et, il faut noter que ce benchmark n'est pas fait sous Ext4, avec ce dernier, les performances de LevelDB s'écroulent.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: nosql embarqué ?

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

              Et on est autour de 100 op/s, c'est vraiment pas top. A croire que personne n'utilise les db dans ce mode là.

              "La première sécurité est la liberté"

              • [^] # Re: nosql embarqué ?

                Posté par  . Évalué à 3.

                Est-ce seulement possible de faire mieux ? Parce qu'à demander à chaque insert que ce soit écrit sur le disque, on ne peut pas faire plus d'*insert* que le disque n'est capable de supporter. Et avec 100 op/s, on arrive à ce que fait un disque dur classique https://en.wikipedia.org/wiki/IOPS#Examples.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: nosql embarqué ?

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

                  C'est pas faux.

                  Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).

                  Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.

                  Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.

                  "La première sécurité est la liberté"

                  • [^] # Re: nosql embarqué ?

                    Posté par  . Évalué à 1.

                    C'est rigolo tous les trucs que tu crois et que tu dis sur les filesystems et qui en fait son faux.

                    C'est d'ailleurs pour ça qu'on utilise des bases de données d'ailleurs (sql ou pas).

                    • [^] # Re: nosql embarqué ?

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

                      Tu pourrais être plus précis ? Pour la base de donnée, je n'y connais pas grand chose, mais ce n'est pas du tout le cas des système de fichiers.

                      "La première sécurité est la liberté"

                      • [^] # Re: nosql embarqué ?

                        Posté par  . Évalué à 1.

                        Par exemple ta superbe pirouette intellectuelle "la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps" … "les FS protège surtout leurs métadonnées".

                        T'arrives presque à te rendre compte que ton raisonnement est faux. La garantie d'écriture des données avec de bonnes performances n'est pas assurée. Ou au moins aussi lentement que pour une base de données quand elle assure la même chose.

                        • [^] # Re: nosql embarqué ?

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

                          Là, tu racontes n'importe quoi, quand tu règles EXT3 (et 4) pour journaliser les données, tu ne tombes à pas à 100 io/s.

                          "Ou au moins aussi lentement que pour une base de données quand elle assure la même chose."

                          Je ne considère pas qu'un fsync() assure quoique ce soit, il demande une écriture en urgence qui tue beaucoup les performances, alors que bloquer (fdone()) jusqu'à une écriture effective, rendra exactement le même service mais avec de bien plus grande performance globales.

                          "La première sécurité est la liberté"

                          • [^] # Re: nosql embarqué ?

                            Posté par  . Évalué à 3.

                            quand tu règles EXT3 (et 4) pour journaliser les données, tu ne tombes à pas à 100 io/s

                            On parle ici d'écrire à chaque fois.
                            S'il y a écriture à chaque IO, si, c'est aux alentours de 100 écritures par seconde (7200 tr/mn / 60 s = 120 on est là au maxi du maxi lorsque tout est parfait).
                            C'est pour ça que les OS et les systèmes de fichiers utilisent des caches.

                          • [^] # Re: nosql embarqué ?

                            Posté par  . Évalué à 3.

                            Sur un disque 7200 rpm tu montes à peine à 100 write/s. C'est la limite du disque pas du filesystem. Tu peux vérifier ici.

                            Si tu fais un fsync à chaque fois que tu veux le D de ACID sur un filesystem, tu prends minimum 2 io (les données et les méta-données) donc t'as au mieux 50 fsync/s.

                            Pour faire mieux il faut écrire dans un seul fichier de taille constante pour pas modifier ses métadonnées et remplacer fsync par la libaio (comme toutes les bases de données cherchant à faire de la perf le font, justement) et là tu monteras à 100 write/s avec des grosses io, et même au-delà si tu as suffisament d'io, qu'elles sont petites, et qu'elles sont au même endroit sur le disque (ça marche pour un redolog par exemple, absolument pas par contre pour du random un peu partout), parce que tu laisses l'os les agréger, grâce à la libaio.

                            Si tu fais plus, c'est soit que t'as un disque plus performant, soit que tu n'as pas le D de ACID (pour des raisons soft genre ni fsync ni attente via la libaio, ou pour des raisons hard genre ton disque est mal configuré et acquitte les écritures avant de les faire), soit que tu as modifié les lois de la physique. Par comparaison avec les write/s pures du disque, ce que le filesystem peut faire de mieux c'est ne pas les dégrader.

                            • [^] # Re: nosql embarqué ?

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

                              Dans l'absolue, si on se fout des perfs de lecture, on peut imaginer coller les writes dans l'ordre genre journal de transaction, sur un disque qui peut tenir 100 Mo/s, on arrive pas à faire mieux que 100 IO/s ? Si on groupe les writes, cela va plus vite j'imagine ?

                              "La première sécurité est la liberté"

                              • [^] # Re: nosql embarqué ?

                                Posté par  . Évalué à 2. Dernière modification le 21 septembre 2013 à 20:39.

                                Oui, c'est ce que je veux dire par là:

                                et même au-delà si tu as suffisament d'io, qu'elles sont petites, et qu'elles sont au même endroit sur le disque (ça marche pour un redolog par exemple, absolument pas par contre pour du random un peu partout), parce que tu laisses l'os les agréger, grâce à la libaio.

                            • [^] # Re: nosql embarqué ?

                              Posté par  . Évalué à 2.

                              Et tu parle dans des cas où le noyau lance ton application à la place de l'init. Parce que si on va aussi loin dans la tentative d'optimisation, les écritures faites par les autres applications vont te gêner.

                              La page wikipedia ne parle pas du RAID, faire du striping doit améliorer les choses j'imagine.

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

                              • [^] # Re: nosql embarqué ?

                                Posté par  . Évalué à 2.

                                Oui mais quand on parle de perfs brutes sur une base de données, en général sur le serveur qu'on teste il n'y a que le sgbd qui écrit, et sur un disque dédié (genre les logs systèmes sont sur un autre disque).

                                La limite théorique pour n disques en raid 0 strippés c'est n fois la limite d'un disque. Genre 200 iops pour 2 sata 7200. En pratique faut vachement bien tunner la taille des stripe selon le paramétrage du sgbd (ou du filesystem), en alignant avec la taille des blocks en particulier. https://www.google.fr/search?q=redo+log+stripe+size

    • [^] # Re: nosql embarqué ?

      Posté par  . Évalué à 5.

      bah si tu te fous complétement du coté ACID (atomicité, cohérence, isolation et durabilité), ne fait aucun accès disque cela sera le plus efficace !

      • [^] # Re: nosql embarqué ?

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

        Je veux la persistance quand même.

        "La première sécurité est la liberté"

        • [^] # Re: nosql embarqué ?

          Posté par  . Évalué à 2.

          Ben tu écris sur disque toutes les heures, c'est persisté mais t'as pas le D de ACID tout le temps.

        • [^] # Re: nosql embarqué ?

          Posté par  . Évalué à 4.

          Si tu veux la persistance et que tu as en tête les limites physiques des disques durs tu dois te rendre compte que la limite dure est assez basse. Soit tu as un cas d'utilisation très spécifique qui te permet d'aller chatouiller les perfs brutes (dès que les têtes commencent à bouger c'est vite mort), soit tu utilises du matos adapté à des lectures/écriture aléatoire: ssd, iofusion etc.

          Seule solution si on veut pas faire un compromis sur la persistance sans modifier l'archi. Autrement on peut utiliser des techniques types event sourcing, archi distribuées pour être capable de reprendre sans rien perdre en cas de coupure.

    • [^] # Re: nosql embarqué ?

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

      Hello, est-ce qu'il existe un base nosql qui s'embarque de la même façon que sqlite

      Pourquoi pas simplement Berkeley DB ?

      • [^] # Re: nosql embarqué ?

        Posté par  . Évalué à 2.

        On te dit qu'on veut une base NoSQL pas un vieux truc des années 80 ! ;)

    • [^] # Re: nosql embarqué ?

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

      Tu peux désactiver le fsync pour de meilleurs perf de sqlite :
      http://www.sqlite.org/pragma.html#pragma_synchronous

    • [^] # Re: nosql embarqué ?

      Posté par  . Évalué à 4.

      Je ne comprend pas pourquoi tout le monde ici te conseille Berkley DB. Une base de donnée sous AGPL maintenue pour Oracle, et dont je te souhaite bonne chance pour trouver le dépot git/mercurial/svn/cvs.

      KyotoCabinet, les ingénieurs japonais n'ont pas à rougir face aux programmeurs américains:

      • Écris en C++ (c'est le seul mauvais point, TokyoCabinet était écris en C).
      • GPL
      • Bindings disponibles en C, C++, Python, Java, Lua. (Perl et Ruby aussi, mais je sais pas où se placent ces langages pour l'embarqué.)
      • D'un point de vue performance, je n'ai aucune preuve de sa performance. Mais c'est une amélioration de TokyoCabinet (tu peux trouver plein de benchmark qui montrent que TokyoCabinet met un claque à BerkleyDB)
      • Le code source est beaucoup plus facile à trouver que BerkleyDB.

      Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

      • [^] # Re: nosql embarqué ?

        Posté par  . Évalué à 2.

        Écris en C++ (c'est le seul mauvais point, […]).

        On n’est plus vendredi à ce que je sache.

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

        • [^] # Re: nosql embarqué ?

          Posté par  . Évalué à 2.

          C'est pas du troll.

          Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

          • [^] # Re: nosql embarqué ?

            Posté par  . Évalué à 0.

            Parce qu'ils s'y connaissent en programmation ?

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

            • [^] # Re: nosql embarqué ?

              Posté par  . Évalué à -1. Dernière modification le 14 septembre 2013 à 23:43.

              Oui, et pas qu'un peu.

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

          • [^] # Re: nosql embarqué ?

            Posté par  . Évalué à 5.

            Si c’est du troll. N’utiliser que du C induit aussi des désavantages. En C++ il y a plus de vérifications à la compilation, les objets de la bibliothèques standards évitent d’avoir des problèmes de pointeurs invalides, on peut faire de la POO beaucoup plus facilement.

            Si c’était vraiment aussi naze, personne ne l’utiliserait. Et pourtant. C’est que ça répond à un besoin qui n’est pas encore comblé par un autre langage. C’est sûr qu’aujourd’hui je parierais plutôt sur Rust.

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

            • [^] # Re: nosql embarqué ?

              Posté par  . Évalué à 1.

              Je vois ici que le second degrés on a du mal a reconnaître. Dire « c'est pas du troll » et donner un lien vers harmful.cat-v.com, faut quand même y aller. Bien sur que c'est du troll.

              Mais je voudrais répondre sur le C++ vs C. Parce qu'à mon humble avis le C++ est vraiment mauvais.

              Premièrement je ne comprend pas pourquoi on voudrait faire de la POO. Tout le monde dis « il faut faire de la POO », mais personne ne peux m'expliquer pourquoi. Attention, je ne suis pas en train de dire: « il faut faire de la POO », je dis juste que la POO est une mode, comme « il faut une API Rest » ou des choses comme ça. Et dans 80% des cas c'est adapté, mais on ignore ces 20%.

              Pour répondre à ta question, C++ est un très mauvais langage pour faire de la POO:

              • La gestion des exception est très mauvaise. Certaines exceptions peuvent générer des fuites mémoires très difficiles à diagnostiquer.
              • La gestion de l'héritage multiple est très mauvaise. Et c'est pour celà, que dans la majorité des cas, ce qui est présenté comme la killer feature du C++ (comparé à Java), n'est en fait pas utilisé du tout. Java résout le problème avec les interfaces, et plein de gens ont écris que l'héritage multiple était mal. Mais le fait est que la manière dont Dylan a résolu le problème est une très bonne solution ÀMHA. (Elle a été reprise par Python sous le nom de MRO)
              • Très souvent la raison d'utiliser C++, est « c'est plus performant! » Mais personne n'a besoin de cette performance. Qui plus est, il est difficile de faire monter C++ à l'échelle comparé à Java ou Python. Je n'arrive pas à retrouver les messages de devnewton qui explique qu'en général le gain de performance est invisible pour l'utilisateur d'un logiciel. En revanche, pour ce qui est d'une application serveur qui va prendre 100 coup à la seconde, la performance est importante. Mais dans ce cas, il devient difficile de faire monter à l'échelle n'importe quelle application C++.

              Je connais très mal Rust. Je ne peux pas trop juger, mais le fait qu'il ai été influencé par Ruby me suffit à ne pas vouloir jouer avec.

              Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

              • [^] # Re: nosql embarqué ?

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

                La gestion des exception est très mauvaise. Certaines exceptions peuvent générer des fuites mémoires très difficiles à diagnostiquer.

                Certes mais ce problème est connu depuis des années et documenté dans de nombreux livres. Cela fait-il de C++ un mauvais langage ?
                Tous les langages ont leurs pièges et bonnes pratiques pour y échapper.

                Très souvent la raison d'utiliser C++, est « c'est plus performant! » Mais personne n'a besoin de cette performance. Je n'arrive pas à retrouver les messages de devnewton qui explique qu'en général le gain de performance est invisible pour l'utilisateur d'un logiciel.

                C'est sûr ! En termes de jeu, il suffit de regarder Minecraft et de le comparer à Doom3 pour se rendre compte que la perf, ça sert à rien ou alors, c'est juste pour faire joli (ce que n'est pas franchement Minecraft).
                D'ailleurs, il y a encore des gens que ça intéresse les perfs dans le domaine des jeux (cf. ce très bon document sur les pièges de la POO).

                Qui plus est, il est difficile de faire monter C++ à l'échelle comparé à Java ou Python. En revanche, pour ce qui est d'une application serveur qui va prendre 100 coup à la seconde, la performance est importante. Mais dans ce cas, il devient difficile de faire monter à l'échelle n'importe quelle application C++.

                Tu entends quoi par là ? Références ? Exemples ?
                Du coup, si je te comprends, si on veut des perfs pour notre serveur, il faut du C++ mais on ne pourra plus "monter" à l'échelle ? Il n'y a pas de solution alors ? On est condamnés à avoir des serveurs qui gèrent des milliers de connexions mais qui seront lents ?

                • [^] # Re: nosql embarqué ?

                  Posté par  . Évalué à 2.

                  C'est sûr ! En termes de jeu, il suffit de regarder Minecraft et de le comparer à Doom3 pour se rendre compte que la perf, ça sert à rien ou alors, c'est juste pour faire joli (ce que n'est pas franchement Minecraft).
                  D'ailleurs, il y a encore des gens que ça intéresse les perfs dans le domaine des jeux (cf. ce très bon document sur les pièges de la POO).

                  Si ça phrase va peut être trop dans un sens, à mon avis il réagi surtout à un truc qui est vachement lourd avec certain : la performance comme un but en soit. Tu cite Minecraft c'est intéressant malgré des problèmes de performances le jeu a eu un énorme succès, alors que des équivalents probablement bien plus performant n'ont pas su attirer un tel publique. Pourquoi d'après toi ? Minecraft a bénéficier d'une vente forcé ? Il était le premier et a ensuite bénéficier d'un effet réseau ? Il y a eu une campagne marketing de folie ?

                  Rien de tout ça (il a bien bénéficié d'un effet réseau, mais n'est pas le précurseur du genre), il a eu la jouabilité qu'il fallait, il était multiplateforme de base et avait des concepts évolués dans la gestion des matières et de ce qu'on pouvait en faire. Bref au lieu de faire une fixette sur les performances et les chiffres qui n'intéressent apparemment que peu les joueurs (avoir 32 000 blocs dans toutes les directions), le ou les développeurs se sont attachés à d'autres aspects de l’expérience de jeu et ça a très bien marché.

                  C'est le genre de « success story » qui devrait faire réfléchir. Nous, libristes, nous nous attachons énormément à la technique (en quel langage c'est écrit, pourquoi c'est un mauvais langage et que XXX aurait était 1 000 fois mieux) et donc aux qualités techniques des logiciels (« regarde moi mon jeu il est moche mais il consomme que 0.002% de ma RAM et je peux y jouer de manière fluide avec les pilotes VESA »), mais nous sommes bien les seuls. Enfin non il y a aussi des gros geeks non-libristes que ça peut intéressés, mais les utilisateurs finaux, les joueurs, ceux pour qui ont développe des jeux qu'est ce qui les intéressent le plus ?

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

                  • [^] # Re: nosql embarqué ?

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

                    Rien de tout ça (il a bien bénéficié d'un effet réseau, mais n'est pas le précurseur du genre), il a eu la jouabilité qu'il fallait

                    Je suis bien d'accord sur le fait que la jouabilité est bien plus importante que la beauté des graphismes. Il suffit de regarder Tetris bien avant Minecraft.
                    Mais de là à dire que les perfos n'ont pas d'intérêt, il y a un sacré pas.
                    En plus, les exemples à la Tetris ou Minecraft ne sont pas légion non plus !!

                  • [^] # Re: nosql embarqué ?

                    Posté par  . Évalué à 2. Dernière modification le 17 septembre 2013 à 08:50.

                    EDIT: Doublon avec le commentaire suivant.

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

                  • [^] # Re: nosql embarqué ?

                    Posté par  . Évalué à 2.

                    En attendant si je ne joue pas à Minecraft c'est parce que le jeu bouffe toute ma mémoire, comme s'il y avait des fuites de mémoire. J'ai l'impression que c'est mieux depuis quelques versions mais faudrait que je joue pendant une heure ou deux pour voir.

                    Et je suis sûr que le jeu aurait eu encore plus de succès. D'ailleurs les joueurs sont les premiers à se plaindre, surtout pour les gros serveurs.

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

                    • [^] # Re: nosql embarqué ?

                      Posté par  . Évalué à 3.

                      En attendant si je ne joue pas à Minecraft c'est parce que le jeu bouffe toute ma mémoire[…]

                      Tu as l'impression que personne ne joue à ce jeu ? Moi je n'y ai jamais joué, mais je ne remet pas en cause son énorme succès.

                      Et je suis sûr que le jeu aurait eu encore plus de succès. D'ailleurs les joueurs sont les premiers à se plaindre, surtout pour les gros serveurs.

                      Je ne dis pas le contraire, mais si l'auteur avait passé plus de temps à optimiser son jeu au détriment du reste, son jeu serait probablement resté dans la liste des autres jeux du genre.

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

                      • [^] # Re: nosql embarqué ?

                        Posté par  . Évalué à 2.

                        Pas sûr. Après ça dépend de ce qu'on entend par «plus de temps».

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

                  • [^] # Re: nosql embarqué ?

                    Posté par  . Évalué à 2.

                    «regarde moi mon jeu il est moche mais il consomme que 0.002% de ma RAM et je peux y jouer de manière fluide avec les pilotes VESA»

                    Pas vu depuis "Frontier Elite" ça. Univers cohérent entièrement programmé en assembleur. David Braben tu es un génie !

                    ;-)

                • [^] # Re: nosql embarqué ?

                  Posté par  . Évalué à 0.

                  C'est sûr ! En termes de jeu, il suffit de regarder Minecraft et de le comparer à Doom3 pour se rendre compte que la perf, ça sert à rien ou alors, c'est juste pour faire joli (ce que n'est pas franchement Minecraft).
                  D'ailleurs, il y a encore des gens que ça intéresse les perfs dans le domaine des jeux (cf. ce très bon document sur les pièges de la POO).

                  Je pense que le jeux vidéo est le seule domaine où le C++ a encore un peu sa place. Mais beaucoup de développeurs migrent vert le C#, plus de libraries, plus simple, plus Java-teux.

                  Doom3 est un très bon moteur. Mais id Tech 3 était écris en C, et ça ne l'a pas empêcher de fonctionner très bien.

                  Qui plus est, il est difficile de faire monter C++ à l'échelle comparé à Java ou Python. En revanche, pour ce qui est d'une application serveur qui va prendre 100 coup à la seconde, la performance est importante. Mais dans ce cas, il devient difficile de faire monter à l'échelle n'importe quelle application C++.
                  Tu entends quoi par là ? Références ? Exemples ?

                  L'exemple que j'ai en tête serait un très gros serveur de messagerie instantanée qui va se prendre des centaines de coup par seconde. Voilà les problème

                  • Je ne peux pas me permettre de mettre ça que sur un seul serveur. Très peu de datacenter peuvent ce permettent de se prendre ce débit en entrée.
                  • Je met donc plusieurs IP dans l'entrée DNS de mon site. Ainsi, vu que les clients vont prendre une entrée au hasard, et donc faire une sorte de round robin.
                  • Met serveurs ont besoin de communiquer entre eux parceque Alice peux se connecter au serveur A pour envoyer un message à bob sur le serveur B.
                  • Ce qui est le plus cher c'est l'attente. Le serveur attend que la requête soit entièrement reçu, ensuite il répond attend que le client réponde qu'il a bien reçu la requete, etc… Utiliser un thread par client est une mauvaise approche ici, il faut utiliser une boucle à évènement. (C'est pour ça que Nginx est beaucoup plus performant qu'Apache)

                  Bref dans ce cas. Tu va galérer, il te faut de la communication entre tes instance, une approche « asynchrone » au lieu des threads.
                  Tu peux essayer de t'amuser avec asio. Mais je te souhaite bonne chance, si c'est un projet perso ça peux être fun. En entreprise, utilise Erlang ou Python, l'un le supporte directement dans le langage, l'autre a des librairies très puissantes pour le faire.

                  Tu vas me dire, ceci est un cas spécifique. C'est vrai, mais c'est l'exemple que j'avais en tête, qui montre que c'est difficile de faire monter à l'échelle C++.

                  Du coup, si je te comprends, si on veut des perfs pour notre serveur, il faut du C++ mais on ne pourra plus "monter" à l'échelle ? Il n'y a pas de solution alors ? On est condamnés à avoir des serveurs qui gèrent des milliers de connexions mais qui seront lents ?

                  Non. La solution pour avoir des perfs sur un serveur, c'est de faire monter à l'échelle l'architecture, pas le langage. Même si je n'aime pas Ruby et Java; Python, Erlang, Java et Ruby sont des bonne solutions pour ça. (Python a Tornado et Twisted, Erlang a son système de processus léger, je connais très mal les solutions Java, Ruby a Unicorn que je considère plutôt mauvais tout comme Gunicorn en python.)

                  Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

                  • [^] # Re: nosql embarqué ?

                    Posté par  . Évalué à 3.

                    Bref dans ce cas. Tu va galérer, il te faut de la communication entre tes instance, une approche « asynchrone » au lieu des threads.
                    Tu peux essayer de t'amuser avec asio. Mais je te souhaite bonne chance, si c'est un projet perso ça peux être fun. En entreprise, utilise Erlang ou Python, l'un le supporte directement dans le langage, l'autre a des librairies très puissantes pour le faire.

                    Sérieusement… Qu'est-ce qu'il ne faut pas lire. boost::asio juste bien pour s'"amuser" dans "un projet perso" et pas adapté à une utilisation en entreprise ? Pour information, asio est utilisé dans le logiciel gérant les clusters Blue Gene/Q d'IBM. C'est un sacré projet perso, tu ne trouves pas ? Il y a aussi des tout petits projets libres comme la libtorrent et la libbitcoin qui s'appuient sur asio. Enfin, je te laisse consulter la liste des projets utilisant asio et c'est sans compter les dizaines de personnes qui l'utilisent quotidiennement dans un contexte propriétaire et fermé sans en faire la publicité.

                    Quant à ce tu racontes sur le fait qu'on a pas besoin d'avoir un langage performant pour écrire des serveurs parce qu'on peut faire passer à l'échelle l'architecture, scaler horizontalement comme on dit, c'est tellement à la mode, c'est juste n'importe quoi. Whaou, on peut faire du DNS round robin pour répartir la charge sur plusieurs serveurs. Bravo, mais on t'avait pas attendu pour ça. Dans le domaine du web, il y a un facteur 20 entre les frameworks les plus rapides et les frameworks les plus lents sur des tâches simples [1]. Administrer une ferme de 5 serveurs est beaucoup plus confortable qu'administrer une ferme de 100 serveurs. Quand ton architecture pour faire tourner ta jolie application twisted commence à nécessiter un adminsys à temps complet pour la faire tourner, tu réfléchis à la réécrire dans un autre langage. Hacker news est plein d'histoires de personnes en réécrivant leurs applications serveurs dans un langage compilé pour gagner en performance.

                    Oui, une application bien écrite en boost::asio scalera horizontalement aussi bien qu'une application écrite avec netty ou twisted. Oui, ce sera surement plus long à écrire, plus difficile à debugguer qu'une application Java ou Python. Mais ce sera aussi plus rapide, et tu auras un bien meilleur ratio performance/watt. Il y a un facteur 10 en moyenne en temps entre du Python et du C++ sur des tâches calculatoires. Rien que le fait qu'il existe une bonne douzaine de projets visant à accélérer le code Python montre bien qu'il y a parfois un problème de performance avec ce langage (qui par ailleurs offre une excellente expressivité). Bien sur ce serait génial d'avoir un langage aussi expressif que Python offrant les performances du C++, mais ça n'existe pas encore aujourd'hui.

                    Attention, je ne suis pas en train de dire que C++ est la panacée et qu'il faut toujours privilégier la solution la plus performante. Clairement si c'est pour une application web qui évolue tous les mois, vaut sûrement mieux l'écrire en Python. Si c'est le service/api web avec lequel ta start up fait du blé, peut-être que Java est la meilleure solution. Si tu veux écrire un système de stockage distribué performant devant tourner sur cluster, peut-être qu'il faut utiliser du C++. Parfois la performance est importante et le ratio performance/watt ou performance/euros est important.

                    [1] TechEmpower - Web Framework Benchmarks

              • [^] # Re: nosql embarqué ?

                Posté par  . Évalué à 2.

                La POO une mode sûrement. Mais c'est quand même super pratique pour la majorité des programmes un peu complexes.

                • Gestion des exceptions: quel rapport avec la POO?
                • Jamais entendu que c'était une «killer feature», au contraire.
                • Je peux te dire que je la vois la différence. Évidemment pour un jeu le temps de lancement est moins important, mais les applications Java mettent des plombes à se lancer. Pour les applications le temps de lancement est super chiant, et Minecraft est lent dans le jeu. Dans les deux ça me les brise.

                Je connais très mal Rust. Je ne peux pas trop juger, mais le fait qu'il ai été influencé par Ruby me suffit à ne pas vouloir jouer avec.

                Rust s'inspire aussi du Nil, Erlang, Sather, Newsqueak, Napier et dans les influences mineures on a Go, SML, C#, C++, ML Kit, Cylone, Haskell, Python et Ruby.

                Autant dire que l'influence de Ruby est ridicule en comparaison du reste.

                Source.

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

                • [^] # Re: nosql embarqué ?

                  Posté par  . Évalué à 1.

                  Rust s'inspire aussi du Nil, Erlang, Sather, Newsqueak, Napier et dans les influences mineures on a Go, SML, C#, C++, ML Kit, Cylone, Haskell, Python et Ruby.

                  Ce genre d'énumération a tendance à me laisser sceptique. Ça donne une impression de four-tout.

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

                  • [^] # Re: nosql embarqué ?

                    Posté par  . Évalué à 2.

                    Je me disais que tu dirais ça… C’est pas juste un gros mix. Le style est très cohérent, on a de l’inférence de type, on a une structure match qui est un switch mais sans avoir besoin d’utiliser break, qui vérifie et l’oblige à traiter tous les cas possibles:

                    match(3) {
    x if x < 0 => {},
    x if x > 0 => {}
}

                    donne

                    test.rs:2:1: 5:2 error: non-exhaustive patterns
test.rs:2       match(3) {
test.rs:3               x if x < 0 => {},
test.rs:4               x if x > 0 => {}
test.rs:5       }

                    Il n’y a pas de pointeurs «null» mais un type spécial, Option:

                    let x = ma_fonction_qui_peut_renvoyer_null_en_c_ou_un_int();
match x {
   None => { /* On traite le cas où la fonction ci-dessus ne nous a rien renvoyer d’intéressant */ },
   Some(x) if x < 0 => { /* cas où x est inférieur à zéro */ },
   Some(2..3) => { /* On traite le cas de deux à trois*/ },
   Some(x) if x > 0 => { /* travail sur x dans les autres cas */ },
   _ => { /* Tous les autres cas */ }
}

                    Les structures de contrôles sont toutes des déclarations, ce qui permet de faire des choses intéressantes, par exemple en reprenant l’exemple du dessus, on ferait plutôt:

                    let x = match {
   Some(x) => { x }, // pas de ; à la fin donc le «return» est implicite
   None => { /* On renvoie une valeur par défaut */ }
}

                    ou

                    let x = nombre_negatif_ou_positif();
x = if x > 0 { x } else { -x };

                    On a des pointeurs dont l’objet pointé est géré par un ramasse-miette par tâche ce qui fait que l’on arrête pas le programme globalement, mais la plupart du temps on utilise un objet possédé qui a la durée de vie de son pointeur. Il y a aussi un système de référence pour pouvoir prendre en paramètre de manière indifférente l’un ou l’autre pointeur pré-cité.

                    On a des tâches qui permettent la parallélisation vraiment facilement, c’est vraiment facile de les faire communiquer avec des tubes comme en C mais totalement sûr. C’est bien simple, un programme Rust ne peut pas faire une erreur de segmentation a moins d’un bug dans le compilateur ou dans la bibliothèque standard (il est possible d’écrire du code non-sûr — unsafe — pour certaines choses mais il doit être indiqué au compilateur).

                    On a des clôtures, on peut faire des trucs génériques facilement, on a un système léger de macros, un système de formatage de texte aussi puissant que celui de Python. Il n’y a pas de classes, on a des struct sur lesquelles on implante des méthodes, on a des traits (des interface en Java, il y a aussi un concept similaire en Haskell). Le style de déclaration de fonctions ressemble au Python avec annotations.

                    trait Test {
   // le &self indique que ce n’est pas une méthode statique, le ~ sert à indiquer que la str possédée
   fn fonction_de_test(&self, quelque_chose: uint) -> ~str;
}

struct Machine {
    x: uint,
    y: uint
}

impl Machine {
    fn new(x: uint, y: uint) -> Machine {
        Machine {
            x: x *2 + 3,
            y: y - 5
        }
    }
}

impl Test for Machine {
    fn fonction_de_test(&self, liste: ~[int], quelque_chose: uint) -> ~str {
        let x = (self.x - self.y) * quelque_chose;
        for i in liste.iter() {

        }
        x.to_str()
    }
}

fn main() {
    let x = Machine::new(2, 5);
    println!("Résultat: {}", x.fonction_de_test(6));
}

                    (le plus incroyable, c’est que j’ai mis n’importe quoi et que le résultat est… 42)

                    On peut implanter des méthodes et des traits sur des types de base. Les noms des types sont en général bien choisis et courts (vec pour vecteur, to_str() à comparer au ToString de Java).

                    Il est très facile d’utiliser des fonctions de bibliothèques C et d’exporter ses fonctions pour qu’on puisse les utiliser depuis un langage qui peut appeler des fonctions C (c’est à dire quasiment tous).

                    J’ai sans doute oublier des tas de trucs, mais bon je vais arrêter là parce que sinon on y est pour deux heures encore! :p

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

                    • [^] # Re: nosql embarqué ?

                      Posté par  . Évalué à 2.

                      Je me disais que tu dirais ça… C’est pas juste un gros mix. Le style est très cohérent, […]

                      Je n'ai pas dis que le langage était mauvais, juste que je n'aime pas cette façon de présenter. Énumérer 15 langages dans les quels il y a boire et à manger (dans la liste des langages il y a de l'inférence de type, du typage statique classique, du typage dynamique avec duck typing, du non déclaratif, etc).

                      Si l'apport de python c'est le formatage de chaine et l'apport du C# c'est les types option. Je ne vois pas vraiment l'intérêt de les lister.

                      Mis à part ça, ça à l'air très intéressant, mais j'attends que Rust soit stabilisé avant de m'investir dans ce langage. De ce que j'ai compris, pour le moment le langage n'est pas stable (=> il y a des concepts qui peuvent changer). Donc j'imagine que la bibliothèque standard non plus.

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

                      • [^] # Re: nosql embarqué ?

                        Posté par  . Évalué à 3.

                        La présentation était très mauvaise, on est d’accord.

                        Rust ne change presque plus niveau syntaxe, si tu utilises la version git (0.8) tu auras une version qui ne changeras presque pas par rapport à la version 1.0. Le principal travail est de régler des bugs, pour ce que j’ai testé pas tant que ça, et s’il y en a les contournements sont faciles. Le plus gros bug à l’heure actuelle c’est le fait que les opérateurs composé (+=, -=, *=, etc) ne fonctionnent pas et sont donc retirés provisoirement. Personne ne travaille vraiment dessus pour le moment donc ça viendra pas tout de suite, j’ai bien l’impression que ça ne seras réintroduit que la 0.9 ou la 1.0 mais pas avant.

                        Grosso-modo, je pense qu’avant de sortir la version 1.0 il va y avoir beaucoup de travail sur la doc qui est assez complète mais pas forcément à jour (pour la version git, pour l’instantané, 0.7, j’ai l’impression que c’est bien à jour) et surtout pas forcément très pédagogique (c’est à dire qu’une personne qui ne connait pas la programmation ou qui est débutant ne s’y retrouvera pas). Et puis sur le nettoyage de code aussi.

                        Pour moi le principal problème au niveau technique c’est qu’il n’y a pas de binding pour Qt (qui serait soit dit en passant un enfer vu la taille du truc). À priori vu que GTK c’est du C, on peut l’utiliser assez facilement (mais bon j’aime pas GTK), il y a un logiciel sur Github pour générer les bindings pour les trucs gobject, mais en pratique personne ne l’utilise. Pour le reste, Rust a des bindings pour la SDL, la SFML, MongoDB, SQLite, PostGreSQL, OpenGL ES, Cocoa, SpiderMonkey, et encore pleins d’autres trucs.

                        Et puis il y a aussi beaucoup de projets basés sur Rust: rustboot, zero.rs, rust-http et rust-http-client, Servo bien sûr, sprocketnes (émulateur de NES, plutôt preuve de concept qu’autre chose mais fonctionnel pour la majorité des choses), q³ (un «jeu» pas encore terminé, encore bugué (pas testé mais c’est écrit dans le README), mais en gros on prend les cartes de Quake 3, on voxélise et on rend ça entièrement destructible), rust.ko pour écrire des modules Linux en Rust, etc.

                        On a des gros trucs, complexes et qui nécessitent une bonne architecture et de relativement bonnes performances, qui sont basés sur Rust (je rappelle, Servo, le compilateur Rust et la majorité de la bibliothèque standard), techniquement ça fonctionne très bien mis à part quelques cas spécifiques.

                        Pour moi le principal atout de Rust c’est sa communauté, de gens talentueux qui font du travail de qualité, une forte activité sur Github et en dehors, sympas sur IRC ils t’expliquent ce que te ne comprends pas…

                        Bref, Rust c’est juste énorme et j’ai hâte que ça sorte en version 1.0, parce que je suis sûr que pas mal de monde (dont moi) attendent des versions stables pour travailler sérieusement avec. Si avec ça on pouvait avoir des bindings pour Qt ça serait cool (je ne vois pas d’autre gros truc qui manque).

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

              • [^] # Re: nosql embarqué ?

                Posté par  . Évalué à 2.

                je dis juste que la POO est une mode

                C'est quoi une mode ?

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

              • [^] # Re: nosql embarqué ?

                Posté par  . Évalué à 1.

                Je connais très mal Rust. Je ne peux pas trop juger, mais le fait qu'il ai été influencé par Ruby me suffit à ne pas vouloir jouer avec.

                On est pas vendredi, mais j'ai ri.

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

          • [^] # Re: nosql embarqué ?

            Posté par  . Évalué à 3.

            L'un parle d'un éditeur que personne n'utilise et l'autre d'un noyau. C'est sûr que c'est pertinent de généraliser.
            Pour avoir vue des logiciels et des bibliothèques qui font de la POO en C (notamment gtk), tu prends peur.

            • [^] # Re: nosql embarqué ?

              Posté par  . Évalué à 3.

              L'un parle d'un éditeur que personne n'utilise et l'autre d'un noyau.

              Non Linus répond à une question sur git, mais il utilise des arguments qui ne sont pas liés à l'usage dans git ou linux.

              Il est à mon avis de notoriété que Linus exècre les langages objets et que hors du C et du perl pour lui point de salut.

              À mon humble avis faire parler une ou deux personnes comme ça d'un langage ou d'un autre c'est comme faire parler un économiste sur une loi, selon qui s'est ils auront un avis différents (mais toujours très tranché, jamais de demi mesure¹).

              ¹ : il paraît que si l'on est pas abrupte ou qu'on insulte pas son interlocuteur c'est qu'on est qu'un faux-cul qui s'embarrasse des manières et que l'on est pas honnête. Bref si t'es pas violent dans t'es propos c'est que tu n'a pas d'avis et que l'on va t'écraser avec des arguments bétons comme :

              the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

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

          • [^] # Re: nosql embarqué ?

            Posté par  . Évalué à 5.

            Ce n'est tellement pas du troll que le logiciel de Linus pour la plongée (subsurface), migre vers C++ et Qt.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Précision

    Posté par  . Évalué à 8.

    Mon caractère tatillon me permet de préciser que SQLite est un SGBD, et non pas une "base de données" à proprement parler.
    Pour l'anecdote, notons également que SQLite se trouve dans le domaine public :-)

    • [^] # Re: Précision

      Posté par  . Évalué à 1.

      Il a une subtilité qui doit m'échapper là ?

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

      • [^] # Re: Précision

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

        Un SGBD est un logiciel dont son but est de gérer des bases de données et des requêtes vers elles.
        C'est comme différencier une page web de son navigateur qui l'affiche, tu vois ?

        • [^] # Re: Précision

          Posté par  . Évalué à 9.

          Non, c'est comme différencier un serveur Web des pages Web qu'il sert.

          • [^] # Re: Précision

            Posté par  . Évalué à 1.

            On n'y est toujours pas je crois.

            Moi je dirais que ça serait plus que ça serait assimiler un server web au site internet qu'il sert.

            Soyons précis c'est important. L'approximation et les abus de langage ne sauraient être tolérés.

  • # Et le client ?

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

    Bonjour,

    Elle s'utilise en effet sous forme de bibliothèque

    On peut également utiliser sqlite avec son client (sqlite3) fourni, que cela soit de manière interactive ou via des pipes.

    • [^] # Re: Et le client ?

      Posté par  . Évalué à 1.

      On peut également utiliser sqlite avec son client (sqlite3) fourni, que cela soit de manière interactive ou via des pipes.

      LibreOffice est un client OpenDocument ?

      Si tu commences à utiliser sqlite3 (= l'outil en ligne de commande) pour interagir avec une fichier sqlite :

      • soit tu veux juste manipuler le fichier à la main, comme tu utiliserais un tableur pour manipuler une feuille de calcul ;
      • soit tu fais des script shell, et donc sqlite3 est ton interface avec la librairie SQLite ;
      • soit tu es en train de faire quelque chose de la mauvaise manière.

      SQLite is not designed to replace Oracle. It is designed to replace fopen().

      Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

Suivre le flux des commentaires

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