Catégorie : Informatique

LibOCon 2023, Bucharest

I got invited by the Document Foundation this September to the yearly LibOCon, the LibreOffice conference, which took place in Bucharest, Romania, this year.

I have been working on implementing accessibility testing in LibreOffice as part of my day job: the goal was to implement a framework and scenarios for testing the user interface accessibility at all levels. The ultimate goal being to help improve the overall accessibility of the software by simplifying test-driven development as well as avoiding unnoticed regressions.

Joining the LibOCon was a great opportunity to meet face-to-face the people with whom I have been working, getting to know them a little bit better, and talk about some of the work we’re doing or issues we’re facing.

I was also very pleased to see how many talks were targeting accessibility in various forms, from authoring more accessible documents to overall user interface accessibility, and how much developers were aware and concerned.

I’ve had the opportunity to present some of my work, and discuss what’s done, and what’s left to do in the area. I also had the opportunity to attend to a wide variety of talks, diving in areas I’m less familiar with, which is a great way to get an overview and learn about other aspects of the software and the community around it.

Huge thanks to the Document Foundation for inviting me, and to all sponsors for making these events possible. It really was a pleasure to meet everybody, and the organizing team was stellar!

Accessibility at the GTK Hackfest 2020

Old town

The GTK 2020 hackfest took place last January, just before FOSDEM 2020, in Brussels, Belgium. The focus was on GTK4 schedule and pending work, and on the state and future of accessibility in GTK4. I only attended the second half, the accessibility part, which is my job’s focus working at Hypra, a small French company focusing on free and open source accessibility and computer literacy.

I was slightly scared of how the meeting would go at first, because some discussions prior to the hackfest gave an impression that accessibility as not something GTK would keep on supporting and promoting anymore.

There were legitimate concerns about the state of affairs in the technical side of GUI accessibility in GTK and Linux more generally: despite GTK being the most usable toolkit for accessibility users for a long time, the technology leveraging it grew old and didn’t adapt to the environment around it, mostly due to lack of attention and resources. There were also legitimate concerns that some things didn’t actually work so well, which again is mostly due to code aging and lack of resources to keep it current during more than a decade, with only a handful of people working on this on their spare time.

Basically, GUI Linux accessibility was left behind since the mid-2000s and struggled to catch up more and more with new technology replacing other aging ones, and Wayland sounding like it would be the last punch it needed to fall.

Fortunately, the meeting, and most importantly the people attending it, quickly wiped off my fears: GTK developers present were clearly on board and motivated, interested in learning more about a variety of accessibility use cases, and willing to get their hands dirty to build a brighter accessibility future on Linux.

Met GTK, Mutter, AT-SPI, Hypra developers and trainers, and a few other developers relying on accessibility for their day-to-day computer usage. We had a healthy proportion of people actually relying on accessibility every day, and a wide knowledge of usages and needs, allowing to discuss and showcase some of them for everyone’s understanding. This gave a great mix of technical and sociological knowledge about accessibility and lead to relevant and focused discussions on how to shape its future under Linux.

Together, we managed to refine and agree on the tasks needed to move forward, dispatch them and set up a roadmap. Don’t get too excited just yet because there is quite some work ahead of us, but I’m confident we are going in the right direction and will get concrete results in the upcoming quarters.

Even if we’re still greatly under-resourced in the care of accessibility, I’m happy to see things moving again, and hopeful that with a refreshed and consolidated ground this will become a less scary topic and get more attention and resources.

Next step would be to raise awareness to the general developer, and spread knowledge about things to do or not to do at the application level. We discussed this as well and plan to improve documentation and facilitate developer’s work (“make it easier to do it right and harder to do it wrong”), but it will only really spread if accessibility stops being seen as a niche irrelevant to most, and fortunately, you can help with this! Take it seriously, document yourself and spread the word: often only little effort it is required to make things better for everyone once one knows what to do.

A beer to celebrate!

I wish to thank every single one of the attendants for their involvement, commitment and effort in getting things moving again and on the right track. I’d like to especially thank Emmanuele Bassi who was a great interlocutor and who will undertake a large part of the work, and Samuel Thibault for his still unmatched versatility around accessibility topics. But truly everyone was key for making this meeting so pleasant and fruitful, thanks again!

RV350 et XVideo

J’ai installé Debian Squeeze sur un Asus A3000 pour une amie il y a quelques jours, sans anicroches1. Wifi ipw2200 avec le firmware qui va bien (firmware-ipw2x00) ; lecteur de cartes SD ; veille ; accesskeys ; et même un peu de 3D (c’est une 9600M, faut pas rêver non-plus). Tout va bien sans aucune manip, mis à par l’installation du firmware non-libre.

Sauf qu’aujourd’hui, sa propriétaire passant le chercher après quelques jours de vacances, elle l’essaie. Je reste à côté, la laissant s’habituer à GNOME (elle avait Lenny sous KDE 32) et répondant à deux-trois gentilles questions – auxquelles elle aurait répondu elle-même si je n’avais été là d’ailleurs. Jusqu’au moment ou elle essaie de lire un film. Ça fonctionne… presque : l’image saccade.

Comprenez ma petite gêne, mon installation peaufinée trois jours plus tôt3 ne marche finalement pas si bien que ça. Ni d’une ni de deux, mon instinct geek refait surface et commence à chercher. Diagnostique simple : XV ne fonctionne pas, il n’y a donc pour ainsi dire pas d’accélération. Je vérifie, mais oui, la Mobility Radeon 9600 M10 (RV350) est supposée être très bien supportée par le pilote radeon de Squeeze. Continuant posément sur ma lancée, je jette un œil au log de Xorg, qui me le confirme, j’utilise bien radeon mais tout ne se passe pas si bien… cependant, le log est peu explicite sur le problème, et se borne à lister une série de disabled pas spécialement engageants, mais finalement pas si terribles. Après deux-trois essais à feinter Xorg en lui suggérant des options – inutiles – dans un xorg.conf manuel, je me reporte à la source de bien des solutions : internet. Pour une fois il n’est pas très bavard, pas grand chose au sujet d’une RV350 sans XVideo. Qu’importe, quelqu’un, quelque part, suggère d’utiliser fglrx. Je n’ai pas l’habitude d’installer le pilote propriétaire (et soyons honnête, celui d’AMD est loin d’être parfait) là où le libre devrait bien fonctionner, mais puisque ce n’est justement pas le cas, je me prépare à essayer.

Il me faut donc décharger radeon et installer fglrx. Je ne sais pas trop pourquoi, je commence par enlever radeon avant même d’installer fglrx, et bien-sûr de nos jours radeon utilise le KMS et ne peut donc être retiré si facilement – il ne faut pas que le modsetting ait été activé. Je reboot donc (avant même une tentative, qu’on ne me prenne pas pour un manche – j’avoue, c’est uniquement que j’ai déjà donné) et ajoute un petit radeon.modeset=0 sur la ligne de boot du noyau. Ça démarre, sans modesetting donc. Et là, pour une raison que j’ignore encore, je vérifie que XV ne fonctionne toujours pas, peut-être qu’un miracle… et oui, xvinfo trouve maintenant un adaptateur ! Je teste, et encore oui, je n’ai pas rêvé, XVideo fonctionne vraiment.

J’apprends donc que le modesetting empêchait XVideo de fonctionner. Je ne sais toujours pas pourquoi, je ne peux que supposer que c’est un problème de quantité de mémoire – il semble qu’il y ai eu dans les 53M avec et maintenant 64M sans, si je déchiffre le log de Xorg correctement. Quoi qu’il en soit, j’ai maintenant désactivé le modesetting de façon permanente (dans /etc/modprobe.d/radeon-kms.conf), configuré Grub 2 pour définir la résolution des TTY au boot (GRUB_GFXPAYLOAD_LINUX=1024x768 dans /etc/default/grub), et ça fonctionne très bien. Je suis un peu déçu de devoir désactiver le KMS, mais finalement il n’est pas très utile ici, largement moins que XVideo en tout cas.

Voilà, la petite histoire est terminée, bonne nuit les enfants !

Notes

  1. À part pour la WebCam ALi M5603 qui ne semble pas avoir vraiment de pilote pour le moment – le seul que j’ai pu trouver ne semble pas encore être inclus à gspca, n’a pas subi de changement depuis plusieurs mois et semble être relativement ardu à compiler lorsque l’on est un novice des pilotes gspca. Cela étant, la WebCam ne sert pas, j’ai donc arrêté les frais assez rapidement.
  2. Hehe :p
  3. Pas sous ses yeux malheureusement, car pour une raison que j’ignore, le CD de netinstall n’avait pas (plus) les bonnes clés, et qu’elle était pressée – forcement ça calme quand on vous dit que c’est facile, on vous montre, et qu’en fait ça ne marche pas…

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…

Lancement (officiel) de GeanyGenDoc

Hé bien ces temps-ci mon blog croule sous les articles, va falloir que je me calme moi… non ? Bon, je vais donc vous parler de mon dernier né, qui incube quand-même depuis un moment…

Une petite histoire, ça vous dit ?

Une petite histoire… tout commence il y a bien longtemps, du temps où l’année s’écrivait encore 2009. En ces temps reculés donc, et en grand amateur de documentation fraîche et bien formée1, l’idée d’écrire un plugin pour cet EDI2 sympathique qu’est Geany qui faciliterai la rédaction de la documentation d’un code source germa dans mon esprit. Ni d’une ni de deux, je m’attèles à la tâche. Sauf que je me rends compte rapidement que le design de mon plugin est tout sauf le bon. Je voulais quelque-chose d’extensible : c’est on ne peut plus fermé. Je voulais quelque chose qui gère facilement à peu près n’importe quel langage de programmation : c’est tout sauf le cas. Je voulais quelque-chose qui soit à peu près indépendant du format de documentation : que nenni ! J’arrête donc les efforts inutiles, et me penches sur un design plus adapté… mais, et c’est ce qui va me perdre, j’ai quand-même déjà quelque-chose qui fonctionne relativement bien pour mes besoins.

Et donc, le temps passe et j’oublie un peu mon devoir d’améliorer ce design ; et ceci est, je l’avoue volontiers, en grande partie dû au fait que le mauvais plugin fonctionnait trop bien, satisfaisant la majorité de mes besoins. Le temps passe donc, et je ne réfléchis que distraitement à ce nouveau design.

Mais, bien-entendu, arrive un moment où je trouve une idée qui me paraît adaptée — l’avenir nous le dira — et je commences donc à l’implémenter. Mais ha ha, je me heurtes à un léger problème : j’ai besoin d’un moteur de template qui permet d’utiliser des boucles et autres tests. J’ai beau chercher de-ci de-là, rien (en C) ne semble correspondre à mes besoins. Car en plus je suis difficile, et ne veux pas avoir à appeler un programme externe mais préfère une bibliothèque, et si elle permettait de traiter des données directement en mémoire, ça serait encore mieux. Et c’est ainsi qu’est né ce fameux CTPL dont je vous parle tout le temps.

Et donc me voici en train d’écrire CTPL, mettant à nouveau en pause le plugin lui-même. Quelques mois passent tranquillement sans en avoir l’air… et finalement, CTPL arrive à un stade qui semble utilisable.

Me revoici donc à implémenter ce plugin nouveau, chose enfin possible ! Et les choses se passent tranquillement, entre écriture et changement de certaines choses dans CTPL, pour arriver finalement au stade actuel : ça marche plutôt bien, et le design me semble plutôt sympathique.

GeanyGenDoc, enfin !

Et me voici enfin à présenter ce plugin, le simplement nommé GeanyGenDoc.

C’est quoi ?

GeanyGenDoc est sensé faciliter la rédaction de la documentation d’un code source. Son rôle est de préparer le terrain pour recevoir ce qui est vraiment utile, c’est à dire les descriptions et autres explications. Il génères donc, à la demande, un commentaire de documentation vide adapté à ce qu’il documente. Par exemple, il préparera un commentaire de fonction Doxygen en insérant automatiquement la liste des paramètres : il ne reste plus qu’à remplir les descriptions. Évidemment, on peut en faire autant avec les structures, les énumérations, les variables, et cætera.

Les fonctionnalités et le reste

GeanyGenDoc a été conçu pour être à peu près complètement extensible ; ce qui fait que la majeur partie des choses sont configurables :

  • Utilisation de templates définies par l’utilisateur pour les commentaires de documentation ;
  • Règles de documentation définies par l’utilisateur (s’il faut documenter ceci, cela, autre-chose, si c’est en fait le parent qui doit s’en occuper, etc.) ;
  • Utilisation de l’arbre de tags de Geany comme source de symboles, permettant de gérer à peu près tous les langages connus de Geany, et ce sans ajout de code.

J’en oublie sans doutes, mais voici les choses principales. S’il me fallait citer un inconvénient à ce design, je pense que je dirais que son défaut vient de son extensibilité et de sa jeunesse : il faut écrire la plupart des règles de documentation car très peu sont fournies par défaut. Pour le moment il n’y a que GTK-Doc en C qui soit géré plutôt correctement par défaut, et une petite partie de Doxygen. Mais des règles pour d’autres langages ou formats de documentation seront probablement intégrées par défaut au fur et à mesure.

Se procurer GeanyGenDoc

GeanyGenDoc n’a encore aucune version publiée, mais la version de développement se trouve dans le dépôts de plugins de Geany, Geany-Plugins. Amusez-vous, documentez, rapportez des bugs et fournissez des patchs !

Vous pouvez accéder au dépôt avec SVN :
svn co https://geany-plugins.svn.sourceforge.net/svnroot/geany-plugins/trunk geany-plugins

Et même avec Git directement (sans même avoir besoin de git-svn) :
git clone http://git.geany.org/git/geany-plugins

Quelques liens

Notes

  1. Non, je ne suis pas fan, juste que ça collait bien.
  2. Ou pas d’ailleurs, ça ressemble plus sur certains côtés à un simple éditeur, de qui n’est pas pour me déranger.

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 ?

CTPL 0.1

Je ne vous en parlais pas, maintenant c’est là : je viens (enfin, hier) de publier la première version de CTPL !

Qu’est-ce que CTPL ?

CTPL est l’acronyme de C Template (Parser) Library, et c’est… un moteur de templates en C.

Les fonctionnalités/avantages de CTPL sont :

  • CTPL est libre (GNU GPLv3+).
  • CTPL est écrite en C.
  • CTPL est une bibliothèque, et est donc facilement utilisable depuis un programme (C en l’occurrence).
  • CTPL peut traiter n’importe quel tampon mémoire (via libmb), ne nécessitant ni que l’entrée ni que la sortie soit un fichier (ça c’est le vrai truc qui roxx des Pangolins).
  • CTPL a une syntaxe simple.
  • CTPL est (sensée être) portable.

Pourquoi CTPL ?

J’ai écrit CTPL (nofake) car j’avais besoin de parser des templates en C, et ce depuis une bibliothèque, et si possible sans que mes entrées ou ma sortie ne se fassent forcement sur des fichiers ; et malheureusement (ou pas), je n’ai pas réussi à trouver ça. Donc, ni une ni deux, je m’y suis mis.

Je veux essayer !

Ça c’est une riche idée ! Pour essayer, il suffit d’aller sur le site de CTPL, de récupérer les sources (depuis le tarball ou le dépôt Git) et de les compiler : tout ce qu’il faut savoir est expliqué sur le site.

N’oubliez pas de rapporter les éventuels bugs que vous trouveriez, et de me faire part de vos suggestions !

Liens

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).

Trois petites choses… non, quatre.

Hé non, je ne suis pas mort. Déçus ?

Aujourd’hui, je vais parler de quatre petites choses : ma résurrection, et trois de mes petits projets hébergés ici.

Alors non, je n’ai jamais été mort, mais à vrai dire je n’ai jamais trouvé de quoi parler ici qui en vaille la peine. Peut-être vais-je essayer de me poser moins de questions à l’avenir et parler plus de tout et de rien, quitte à passer pour un con de temps en temps − ne vous inquiétez pas, j’ai l’habitude. Voilà, j’en ai terminé avec le primer point, ma résurrection.

Ensuite, les trois petits projets, bien entendu libres.

RMusic

Le dernier né, un petit outil, ou plutôt jouet : c’est un générateur de notes MIDI à partir de données aléatoires (ou pas). Il est fait pour lire quelque chose comme /dev/urandom et être connecté à un synthétiseur quelconque, par exemple ZynAddSubFX, FluidSynth ou ce que vous voulez.

Cette idée qui peut paraître stupide − et je ne dis pas qu’elle ne l’est pas − est partie d’un petit délire d’avant-hier soir, et a engendré ce petit programme tout à fait inutile mais pouvant quand-même générer des trucs sympa si les réglages sont bons.

Si ça vous amuse, vous pouvez aller voir la page dédiée.

LibMB

Ce projet est plus vieux, mais je ne l’avais jamais présenté ici, donc je le fais maintenant. LibMB est une petite bibliothèque (sans blague !?) C fournissant une API semblable à celle de gestion des fichiers C, mais travaillant exclusivement en mémoire. Je l’ai écrite pour de petits parseurs devant travailler sur des données non rattachées à un quelconque fichier dans le contexte de l’écriture de MdownEditor.

Cette bibliothèque n’est pas grosse ni lourde, ne mange pas de pain et est écrite en ANSI C.

LibBNSS

Encore un petit projet, commencé il y a beaucoup plus longtemps que tous les autres, LibBNSS est une petite bibliothèque, ou plutôt un ramassis de fonctions de traitement des chaînes de caractères en C. Les fonctions disponibles sont soit des fonctions manquantes de la norme C mais présentes dans POSIX ou autre norme cool (fonctions de « compatibilité »), soit des fonctions absentes de toute norme connue de moi, mais dont j’ai eu besoin, et qui ne sont pas toujours des plus simples à refaire. Il y a par exemple des fonctions de remplacement de chaîne(s) dans une autre chaîne ou une fonction de nettoyage d’un chemin.

Et voilà, c’est tout pour le moment, mais promis, j’essaierais d’être plus présent à l’avenir.