3 octobre 2012

bin/recent

11:21 - Code

For quite some time the access to recent files has been put forward in GNOME, it happened even more so in 3.6 with a "Recent Files" view in Files (née Nautilus), that makes use of a new recent files backend in gvfs.

This is all very nice but my daily activities still involve a lot of command line usage, and I didn't find any way to mark as recents the files I receive via mutt, the text files I create in vim, the pictures I resize with ImageMagick, etc. That always bothered me at the moment I wanted to access those files, but then I just copied a copy of the file to a scratch directory I had bookmarked, and went on with my work.

Until yesterday, as I finally decided to fix that, and quickly put together recent, a command line utility that just puts the file it gets as argument in the recent files list. It's very simple, uses GFile and GtkRecentManager, and the code is located there: recent.c. It's so simple I guess many others wrote something similar, but here you have, perhaps it will be useful.

21 octobre 2009

An evening with threads

9:52 - Code

I noted on Monday how I have been working on jack mixer recently; to be honest I didn't do much work up to now, replacing some widgets, adding a preferences dialog, easy stuff.

But as I am starting to use it seriously I realized it didn't scale well, I would add five channels and it would burn CPU and memory in a terrific manner. Without much investigation I decided it was caused by the polling for MIDI events, and set out to fix this.

Well, jack_mixer is written in Python and C, Python for GUI stuff and C for jack and computer intensive stuff, and it turned out it's not possible to call back from a C extension to Python code, when using SWIG, so I got to write a manual binding, easy enough, and I got it feature complete quite fast, gaining good looking code along the way, from here:

mixer = jack_mixer_c.create("test")
print "Channels count: %u" % jack_mixer_c.get_channels_count(mixer)
channel = jack_mixer_c.add_channel(mixer, "Channel 1", True)

to there:

mixer = jack_mixer_c.Mixer("test")
print "Channels count: %u" % mixer.channels_count
channel = mixer.add_channel("Channel 1", True)

All was left was to replace the polling by a callback system, and it worked, then it crashed, randomly. And I realized I stepped in the dreaded thread country.

There is the main thread, it's Python, and PyGTK, but then there are threads created by jack, and the callback is called from one of them, from jack thread to Python, where the Global Interpreter Lock reigns, to PyGTK, where you should do everything in a single thread.

After much reading and pestering I believe I reached a working state doing the following things:

  • calling gtk.gdk.threads_init();
  • enclosing the extension PyObject_CallObject call (which calls a Python function from C) between PyGILState_Ensure() and PyGILState_Release();
  • emitting a gobject signal from the Python callback;
  • calling the GTK stuff from a function connected to that signal.

With all of that in place I can now turn knobs and push faders all I want, without crashing.

Unfortunately it didn't address the performance issue, which was in fact much simpler (some widgets were invalidated every 60ms, as their "value changed" computation was wrong).

Lessons learned (again): 1) don't jump to conclusion on the cause of performance issues, 2) it's possible to tame threads.

29 mai 2008

Le retour de Stamina

11:37 - Code

J'en suis arrivé à rêver cette nuit à une émission radio où les ennuis s'accumulaient jusqu'à me voir un rien irrité quand je découvrais qu'il n'y avait qu'un micro pour trois personnes, irritation qui se transformait en totale lassitude quand une note était passée signalant qu'on s'était trompé dans les dates, qu'il ne devait pas y avoir d'émission ce soir-là...

Et je me dis qu'il y a peut-être moyen d'y voir l'influence des problèmes récurrents rencontrés à la radio ces dernières semaines, même si d'un autre ordre, principalement en rapport avec le système de diffusion automatisée (par la suite simplement référé par l'appellation « nonstop »).

Coccinelle sur façade

Bruxelles, 20 mai 2008

Le logiciel libre, c'est super cool, ça veut notamment dire qu'on peut adapter le logiciel à nos besoins particuliers et en corriger les bugs nous-mêmes. Malheureusement ça ne se fait pas d'un coup de baguette magique...

On a commencé à utiliser soma il y a plus de deux ans, j'y ai corrigé certains bugs flagrants (ah ah, pas moyen de programmer quoique ce soit pour le 31 du mois, avec un message d'erreur affirmant presque qu'il n'y a jamais que 30 jours dans un mois) et ai ajouté certaines fonctionnalités par la bande (modification dans sa manière de stocker les logs, et utilisation de ceux-ci pour générer une archive de la diffusion). Mais l'adapter à notre mode de fonctionnement, assez différent semble-t-il de cette radio italienne où le logiciel a vu le jour, cela a toujours été vu comme une tâche trop importante, alors on a fait avec, contournant des problèmes de manière pas toujours très élégante.

Mais vraiment, tout le monde était quand même assez content des services rendus, jusqu'il y a quelques semaines, où un crash qui n'était arrivé qu'une ou deux fois est devenu bien plus fréquent, me valant appels téléphoniques, « soma est dans les choux », à dix heures du matin comme à dix heures du soir.

Du coup j'ai décidé de prendre un peu de temps pour investiguer, ulimit -c unlimited, exécution depuis gdb, mais que dalle, il y a bien une segfault à un moment, qui entraîne par la suite une boucle infinie consommant le CPU, mais pas la moindre trace laissée et qui pointerait vers la cause.

Page de notes

Notes prises rapidement, la nuit

C'est ainsi que je me suis dit que je devrais sortir de ses cartons Stamina, le logiciel de substitution que j'avais commencé à développer, début 2007, et cette idée qui était très vague, qui aurait pu être très éphémère, elle a terriblement pris forme hier soir, dans les rues vides de Bruxelles la nuit, et une fois rentré chez moi, je griffonnai bien vite mes réflexions.

Reste maintenant à trouver un rien de temps pour implémenter tout ça, mais j'ai remodelé cela pour au plus vite pouvoir arriver à quelque chose, donc j'ai quand même un peu d'espoir et suis prêt à assumer n'importe quelle remarque qui pourrait se faire lors de l'assemblée générale de la radio, ce soir.

15 mars 2008

Pas une prophétie auto-réalisatrice

20:17 - Code

À porter l'oeil sur les projets Mozilla et OpenOffice.org, quantité de similitudes m'apparaissent, la première évidente à tout le monde, il s'agit de deux projets phares de l'open source, cent fois cités en exemple, principalement du fait qu'ils ont énormément d'utilisateurs; utilisateurs qui sont par ailleurs majoritairement également utilisateurs de Microsoft Windows.

Techniquement, d'autres similitudes, une base de code énorme, d'origine propriétaire, et liée, l'utilisation d'outils n'étant pas les standards des autres projets libres (pour les systèmes de build et de traduction, par exemple); aussi l'utilisation d'un toolkit graphique spécifique, et imitant tant bien que mal le « look and feel » d'une application native.

Socialement, trois points : la part qui a toujours été importante de personnes salariées pour travailler dessus, les processus complexe d'acceptation de contributions extérieures, et surtout les processus de décision, d'orientation du projet, eux aussi complexes.

Le projet Mozilla, il a clashé avec Debian fin 2006, et arrivait un commentaire récurrent, « la version que vous distribuez n'est pas la version officielle, vous appliquez des patches qui font qu'elle crashe et vous nous donnez de ce fait une mauvaise image »; ce commentaire, basé sur un argumentaire technique (les patches), a alors été démonté par le mainteneur Debian), ce qui n'a empêché personne de continuer à le répéter, mais bon...

C'est en pensant à cet épisode que je lis, à propos de la version d'OpenOffice.org distribuée par Ubuntu : « Le fait qu'il n'y ait pas d'assurance qualité ni de localisation des fonctionnalités ajoutées sur ces versions les rend très instables et donne une piètre image de notre produit. » (source).

Et ici de ne pas vouloir, dans six mois ou dans deux ans, me souvenir avoir eu raison, en attendant que le splashscreen d'IceOffice disparaisse.

8 mars 2008

Le standard du vendredi après-midi

19:31 - Code

Vendredi après-midi, j'étais au debriefing belge sur le BRM, Ballot Resolution Meeting, sur OOXML, ça n'éclaire pas trop, c'est une tonne de procédures à éclaircir, mais à essayer d'expliquer simplement, je dirais que l'OOXML est le format de document bureautique poussé par Microsoft, qu'il a été proposé pour une standardisation à l'ISO, organisme international qui est responsable de la standardisation d'un peu tout, le code ISBN sur un bouquin, c'est lui, par exemple.

Proposé à cet organisme international, il y avait deux procédures possibles, la procédure normale et la procédure accélérée, cette dernière a été choisie et a donné comme résultat un premier vote en septembre, accompagné de commentaires des différents pays; cela a été suivi par une phase de lecture et d'intégration de ces commentaires pour déboucher il y a deux semaines au Ballot Resolution Meeting, le moment où tous les pays se retrouvaient, à Genève, pour commenter, approuver ou refuser les modifications apportées au standard suite à leurs commentaires.

C'est là que je dois dire que cette procédure accélérée, elle est appelée Fast Track, et qu'après une après-midi de réunion mélangeant français et néerlandais, j'étais content de me retrouver chez un ami à jouer à Cranium.

Cranium, c'est pas compliqué, c'est un mélange de questions de culture générale (genre est-ce que la langue maternelle de Napoléon était le français), de dessins (genre dessinez et faites reconnaitre à votre équipe une barbe à papa, les yeux fermés), de mimes (genre gymnastique prénatale) et cie.

Cela dirigé par un jeu de plateau autour duquel il y a moyen de tourner par l'extérieur, ou par l'intérieur, l'intérieur étant forcément plus rapide, ce qui a valu que je baptise ce parcours de « Fast Track », référence comprise par personne mais adoptée. « Oh, merde, elles passent encore par le Fast Track » étant un peu la lamentation le long du jeu.

Mais là ça s'est éloigné du vendredi après-midi, mais en même temps il y a tellement de trucs confidentiels, secrets ou qu'est-ce ou que sais-je que je ne sais pas ce dont je peux parler.

C'est d'ailleurs selon moi un problème, une procédure de standardisation internationale, qui mériterait de recevoir tous les commentaires éclairés possibles, mais qui se passe derrière des rideaux opaques.

Passons. J'étais au vote de septembre, les différents pays font leurs commentaires, du temps passe, les pays se retrouvent à Genève en février et discutent. Il doit y avoir cent compte-rendus de ce qui s'est passé là, je ne vais pas en rajouter un, surtout que je n'y étais pas, mais donc le chef de la délégation belge, ils étaient deux, fait la lecture de son rapport et est interrompu par son collègue représentant, sur le ton du « ah beinh non, ça c'est pas le compte-rendu objectif, ça c'est l'opinion d'IBM, l'employeur du gars ».

Et c'est là qu'est un peu la merde principale selon moi, en Belgique en tout cas, le sujet de la standardisation du format OOXML est le terrain d'IBM, de Microsoft, de Sun, qui sont trois entreprises qui n'ont quand même pas grand chose à voir avec les intérêts particuliers de la Belgique. Bien sûr il y d'autres intervenants dans le processus, mais ma perception est quand même marquée par la présence très forte de ces entreprises.

Alors oui, c'est un truc que j'avais lu, l'incorporation à la dernière minute de sociétés « Microsoft Partners » à certains comités nationaux, histoire de faire peser le vote dans une direction précise, mais je n'avais réalisé le poids de ça avant, et en Belgique encore je pense que c'est bien moins marqué qu'ailleurs.

Toujours est-il que l'ISO, cet organisme de standardisation, je ne suis dérangé en rien à ce qu'il écoute les intérêts, discours d'entreprises, et qu'il les pèse par rapport aux besoins de la société civile, avec des guillemets autour, mais ce n'est pas le cas actuellement, il me semble, en tout cas sur ce dossier, et les entreprises n'étant pas représentées, il s'agit plus pour elles d'acheter, des guillemets aussi, certains pays pour faire valoir leurs positions.

Vraiment c'est là qu'est le problème, et je ne vais pas être plus doux pour Microsoft sur ce format, que sur le format précédent, poussé par l'OASIS, l'Open Document Format, format qui a quand même été modelé sur la volonté de Sun, et Sun qui est pas foutu de l'implémenter correctement ou totalement (ce qui m'a encore concrètement dérangé il y a moins d'une semaine).

Mais cela n'a pas été le cas, et je ne suis pas sûr de ce que je peux écrire ou pas, alors je vais arrêter ici, me renseigner sur le sujet, et attendre en tout cas le 21 mars où la délégation belge décidera de son vote sur la proposition de standard.