Étiquette : glib

Hé oui, encore CTPL ! Cette fois-ci, je vais présenter brièvement les nouveautés et changements de la version 0.3 qui vient tout juste de sortir.

Avant tout, CTPL 0.3 essai de corriger les erreurs des niveaux précédents¹ versions précédentes, lesquelles exposaient bien trop les entrailles de la bibliothèque². En effet, en voulant faire en sorte que la boucle for traverse une expression plutôt qu’un nom de symbole, je me suis rendu compte qu’il était nécessaire de modifier la structure des tokens, et donc de casser l’API puisque ceux-ci étaient complètement exposés.

Résultat, le principal changement de cette nouvelle version est un grand nettoyage d’été-automne 2010 qui vise à retirer de la vue de l’utilisateur tout ce qui n’est pas réellement utile. Nous nous retrouvons donc avec une API plus propre et, je l’espère, propice aux changements à venir.

Là, vous vous dites (enfin, si vous utilisiez la bibliothèque, vous vous le diriez) « ah mais je vais devoir changer mon code source, c’est trop moche, t’es vraiment trop méchant, je te hais ». Heureusement pour moi (et surtout pour vous), vous n’avez qu’à moitié raison. Oui, il faut changer quelques petites choses, mais rien de bien méchant. Par exemple, il m’a fallu modifier 3 lignes dans GeanyGenDoc pour être compatible avec cette nouvelle version, et il ne s’est agit que d’utiliser les nouveaux noms de deux fonctions. Et puis je vous ai écris un joli NEWS pour vous guider dans cette étape douloureuse (ou pas) donc vous devriez me remercier plutôt que de râler en fait.

Bon, au lieu de faire de l’ironie à trois-francs-six-sous, voici un petit récapitulatif des changements notables (moins soporifique que le NEWS) :

• L’API est plus propre (vive les coups de chiffon !) ;
• la boucle for itère sur une expression, ce qui n’aurait pas grand intérêt sans le changement que vous allez découvrir tout de suite après ;
• les tableaux peuvent maintenant être indexés (oui, foo[42] ça fonctionne) ;

…et d’autres petites choses toutes mignonnes, par exemple que les environnements qui prennent moins de place en mémoire, qu’il y ait enfin une documentation correcte pour les descriptions d’environnement, et bien-sûr quelques corrections de bogues (non, je déconne, il n’y a jamais eu de bogue dans CTPL).

Sur ce, je vous laisse profiter de ce cadeau et m’en retourne à mon silence³.

Notes

1. Oups, les chants d’aventuriers résonnent.
2. Sans rien de gore, ne vous inquiétez pas.
3. Merci Thiéfaine. Pourquoi je dis ça, moi ? C’est même pas vraiment une citation…

J’en parlais récemment, maintenant c’est là : CTPL 0.2 est arrivé !

Finalement, la seule chose retenue pour cette version presque majeure est l’utilisation de GIO comme couche d’IO. Comme j’en parlais dans l’article sus-cité, les risques encourus étaient du travail et un possible ralentissement  : les deux se sont révélés exacts.

Alors oui, cette nouvelle version souffre d’un ralentissement (entre 8% et 19% sur certains templates), mais j’ai décidé, en tant que BDFL (ou pas) de CTPL, que les autres gains valaient cette perte. Car au delà de cette légère perte en rapidité (notons quand-même que 13 secondes pour traiter 135 gros mégas en entrée c’est raisonnable) il y a des gains, le plus évident étant le support de n’importe quel flux GIO : mémoire, fichier, FTP, SSH, HTTP, etc.

Ceci dit, l’utilisation de GIO n’est pas la seule et unique amélioration, même si c’est la seule que j’avais suggéré dans mon article précédant. Voici un extrait choisi des autres nouveauté :

• Messages d’erreur de flux avec indicateur de ligne et de position ;
• Support des constantes entières octales et binaires (on s’amuse) ;
• Représentation allégée de l’arbre de tokens, utilisant entre 20% et 30% moins de mémoire (cool !) ;
• Support des commentaires dans les descriptions d’environnement.

Pour plus de détails, rendez-vous dans le fichier NEWS de CTPL 0.2.

Conclusion

Mais CTPL ne s’arrête sans doutes pas là, et vos rapports de bugs, demandes des fonctionnalités, patches et autres sont toujours les bienvenus !

Ce sera tout pour le moment, je vous remercie de votre attention.

Oui vous avez bien lu, CTPL 0.1.1 vient de sortir. Comme le numéro de version le laisse supposer, c’est une version mineure faisant suite à la 0.1. Au menu : corrections de bugs, dont deux majeurs : stack overflow lors de la destruction d’un très grand arbre de tokens ; et accélération fulgurante de la création de grands arbres.

Quel futur pour CTPL ?

J’ai en ce moment plusieurs idées de ce qui pourrait peupler l’avenir de CTPL, c’est-à-dire de quoi y ajouter ou qu’y changer. Voici quelques unes de ces idées ; je vous invite bien entendu à faire part de vos avis sur le sujet.

Utilisation GIO comme I/O layer

Je penses sérieusement laisser tomber LibMB au profit de GIO, qui dispose d’un module d’I/O en mémoire, GMemoryInputStream et GMemoryOutputStream. Pourquoi ? Hé bien principalement car ceci permettrai de gérer implicitement toutes les sources de données que GIO gère à travers les flux d’entée et de sortie, et ce directement, c’est-à-dire sans forcement charger les données en mémoire (donc utilisation mémoire plus faible pour l’analyse − mais ne rêvons pas : les tokens sont de toutes façons chargés en mémoire).

Pros

• Analyse possible en streaming depuis un fichier (local, distant, tout ce que GIO supporte) ;
• Plus de dépendance sur LibMB, mais sur GIO qui est quand-même plus courant.

Cons

• Nécessite de réécrire une partie de la bibliothèque, en fait tout ce qui interagit directement avec les données d’entrée et de sortie (la sortie devrait être triviale à changer, l’entrée beaucoup moins) plus ce dont j’ai besoin mais qui n’est pas dans l’API GIO (manipulation plus aisée qu’à uniques coups de read()) ;
• Peut-être plus lent (rapport à toute l’abstraction et à GObject) ?

Ajout du support de l’assignation

Haha. Bon, ça j’y penses à moitié, et à moitié pas, particulièrement à cause de ses rares pros et nombreux cons.

Pros

• Ça serait cool.

Cons

• Ça ne sert sans doutes à rien en fait ;
• Il serait sans doutes bien d’avoir un vrai support des scopes avec ;
• Ça nécessite l’un des points suivants :
  1. Que toute assignation soit aussi ajoutée à la sortie ({a = b} ajoute b à la sortie, cool) ;
  2. Faire en sorte qu’un opérateur puisse ne rien retourner (ce qui n’est ni prévu actuellement, ni n’a de sens pour un autre opérateur) ;
  3. Ajouter un moyen pour qu’une partie des substitutions ne se retrouvent pas dans la sortie.

  La première solution est facile à implémenter, mais forcement j’ai un penchant pour la troisième puisque non seulement ça permet de ne pas écrire le résultat d’une assignation dans la sortie, mais aussi de le faire, au choix. Oui, mais comment faire ? Ajouter un nouveau type de bloc ? Ajouter une sorte d’opérateur unaire « ne pas afficher » ? Bof bof…

Ajout des chaînes littérales

Ceci permettrai l’une ou l’autre petite fantaisie comme la comparaison avec des variables de l’environnement ({if foo == "some text"}...) ou de s’amuser à remplir la sortie de « lol » très facilement ({"lol" * 10000}). Pas besoin de longue dissertation sur cette idée-là : ça ne serait sans-doutes pas très utile, et sans doutes pas très complexe à implémenter (BTW, il y a déjà une branche pour ça, même si je ne me souviens plus de son statut exact).

Conclusion

C’est gentil les fonctionnalités, mais il faut peut-être aussi se demander si ça vaut le coup : utiliser GIO me semble assez intéressant, mais les autres idées plus discutables. Qu’en pensez-vous, qu’est-ce qu’il vous serait agréable ou utile de voir venir ?