Étiquette : programmation

CTPL 0.3

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édents1 versions précédentes, lesquelles exposaient bien trop les entrailles de la bibliothèque2. 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 silence3.

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…

CTPL 0.2

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.

CTPL 0.1.1 et l’avenir

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 ?

6 (bonnes) raisons de programmer en anglais

Salut à toi lecteur1 assidu !

Comment tu as échoué sur cette page, je ne le sais, mais comment je vais essayer de te faire perdre quelques précieuses minutes de ta tout aussi précieuse vie, je m’en vais te le montrer. Suivez le guide…

Je vais donc essayer de trouver 10 6 bonnes raisons pour programmer en anglais. Je m’adresse bien entendu à ces chers développeurs amateurs francophones de nativité ou d’adoption, car je suppose qu’un développeur anglophone ne poussera pas le vice jusqu’à programmer en français… peut-être suis-je naïf, mais je préfère ne pas y penser. Allons-y, c’est parti !

  1. Même si Coluche a judicieusement fait remarquer que « ce n’est pas si des million de mouches bouffent de la merde que je devrais en faire autant », l’anglais est manifestement la langue la plus utilisée dans le domaine de l’informatique. Programmer en anglais vous ouvre donc les merveilleux horizons qu’ouvre l’universalité ; même en anglais approximatif, vous serez toujours plus facilement compris par des anglophones d’adoption (ou pas) qu’en français. Même si vous ne pensez pas montrer votre code un jour à un développeur étranger, sachez que même un développeur francophone sera probablement plus à l’aise à lire un programme écrit en anglais qu’en français, question d’habitude. De plus, ça donne de bonnes habitudes pour les programmes à venir.
  2. Ça vous oblige à peaufiner votre anglais, ce qui n’est sans doutes pas un mal…
  3. La plupart des bibliothèques étant elles-mêmes programmées en anglais, la source sera plus homogène.
  4. Comme l’on profitera de programmer en anglais pour tout traduire en anglais, on se souciera plus volontiers de l’internationalisation, ce qui est une bonne chose.
  5. Aussi belle que soit la langue de Molière, il ne faudrait pas vexer Shakespeare non-plus.
  6. Et enfin, cela vous permettra de conquir le monde !

Et voilà, c’est tout… Si vous avez d’autres bonnes raisons de convaincre les méchants nouveaux apprentis programmeurs de programmer dans la langue de Shakespeare, « lashé vos komz » comme on ne devrait pas dire !

Et pour ceux qui se demanderaient pourquoi 6 et pas 10 bonnes raisons, et bien déjà, je suis un grand rebelle qui fait pas comme les autres (na), et ensuite, je vous renvoie à l’argumentation de CerberusXt (Nioutaik, incultes). Je vous laisse chercher, il aime bien les top-pas-10 alors ça devrait pas être trop dur (même si je viens de passer 3 minutes à ne trouver que celui-ci qui n’est pas celui que je cherche, mais vous n’êtes pas obligés de le savoir, d’abord).

1Ou lectrice, je ne suis pas sexiste (et puis ça risquerait de faire un trou dans le vide de mon audience).

Petite présentation de Vala

Vala est un langage de programmation assez récent (2006) visant à simplifier l’écriture de programmes en C avec la bibliothèque GObject en fournissant une surcouche complète au C ; en utilisant une syntaxe proche de celle du C#.
Le programme Vala sera traduit en C avant d’être compilé par un compilateur C standard, le code résultant étant du C pur utilisant uniquement un lot de bibliothèques supplémentaires.
Cependant, Vala n’est pas vraiment un préprocesseur C puisque il va bien au delà de l’automatisation de l’écriture des classes GObject : il fournit une syntaxe orientée objet complète et une gestion de la mémoire automatique via le compte de référence des objets.

L’avantage majeur de Vala par rapport à d’autres langages orientés objet connus comme le C#, Java ou même le C++ est de n’être qu’une « façon d’écrire du C » : l’ABI est entièrement compatible avec le C. Un autre avantage est une rapidité proche de celle du C pur, bien que la gestion automatique de la mémoire via le compte de références et l’impossibilité d’effectuer certaines optimisations manuelles freine un peu le programme, mais pas de façon significative en général.
De plus, de par sa compatibilité binaire avec le C, il n’est pas étonnant d’apprendre qu’un assez grand nombre de bibliothèques sont disponibles pour Vala, rendant ce langage tout à fait viable.

Comme Vala est traduit en C, il est intéressent de remarquer qu’il est tout à fait possible de combiner des parties écrites en Vala et d’autres en C au sein d’un même programme, et même d’un même objet binaire. De plus, le code généré a une API propre, semblable à la plupart des bibliothèques basées sur GObject, le rendant parfaitement utilisable au sein d’un code C.
Le plus intéressent étant bien sûr de programmer certaines parties sensibles directement en C et de créer une interface pour Vala, chose assez aisée via les fichiers d’API Vala (.vapi).

Du côté obscur, Vala souffre encore de quelques imperfections de jeunesse, comme un manque de documentation pour certaines choses.
De plus, je ne pense pas que soit actuellement un langage de premier choix pour quelqu’un ne connaissant pas le C (il ne tirera pas partie des avantages de compatibilité de Vala) et voulant simplement un langage proposant une syntaxe orientée objet ; car les principaux avantages de Vala se situent justement dans sa compatibilité avec le C et sa rapidité.

Quelques liens