Blogue à tabac

Le web et la sémantique

2011-05-10T20:36:00.005+02:00

Amis familiers des grands laboratoires d'informatique, cherchez l'erreur...

Gestion de code

2011-01-17T22:55:00.011+01:00

De lecture en lecture sur le web, je me suis récemment débloqué sur une question relative à l'organisation du développement logiciel...

Quand on élabore du code, on a des contraintes contradictoires:

Commiter souvent pour ne pas perdre du code qui marche, ainsi que pour communiquer et faire tester du code en cours d'élaboration.
Avoir une base de code propre pour que les gens puissent récupérer une version récente mais stable du code, et pour que l'historique soit propre.

On pourrait rajouter une dernière contrainte: coder au lieu de procrastiner sur des questions d'organisation de code...
Pour reformuler le second point, il s'agit d'assurer d'une part la qualité du code à un instant donné (ce qui nécessite une distinction entre code expérimental et code stable validé) et d'autre part d'assurer la tracabilité et le suivi du code dans le temps, c'est à dire la lisibilité de l'historique des modifications (principalement pour le code stable). L'objectif est que ce qui constitue moralement une seule modification ne soit pas explosé sur plusieurs commits. En particulier, on ne veut pas des corrections suivant trop souvent un commit hâtif. Avoir un historique propre simplifie la tâche quand on cherche à comprendre un bout de code (voir d'où vient telle partie du code) ou quand on liste les modifications avant de releaser une nouvelle version. Cela simplifie aussi la vie de ceux qui surveillent les modifications du code -- c'est la raison principale de mon obsession pour ce problème car je m'attache à suivre les commits effectués sur liquidsoap, en tout cas ceux qui touchent des modules critiques ou dans lesquels je suis impliqué. En fait, avec un historique propre on a des chances d'avoir plus de personnes qui suivent de près l'évolution du code et sont susceptibles de détecter des problèmes.

Bien sûr, une partie de la réponse est apportée par la notion de branche. Mais cela n'aide pas du tout pour ce qui est de la gestion de l'historique. Sur ce point, on peut essayer de concevoir un système avec plusieurs dépôts: le dépôt expérimental dont le code n'est pas testé et l'historique est fragmenté, et le dépôt stable où le code est propre et les modifications sont regroupées pour avoir un historique clair. Mais cela fonctionne très mal: pour le transport des modifications vers le dépôt stable, il faut développer un nouvel outil; pour le transport dans l'autre sens, il faut faire face à tout un tas de problèmes. En bref, cette solution est nulle car elle nous prive de l'aide des outils de gestion de code actuels.

Au fond il n'y a qu'une solution pour maintenir un historique propre: l'édition d'historique. Comme le nom l'indique, il s'agit de modifier l'historique des modifications après coup: on fait quelques commits, on attend du feedback, on trouve un bug, et quand tout a l'air propre on réduit tout ça en un seul commit bien clair.

Le gros problème c'est que l'édition d'historique peut interférer assez mal avec la gestion de code distribuée: si on a deux copies d'un dépôt, et qu'on change l'historique dans l'un, il devient difficile de suivre certaines modifications relatives à l'ancien historique dans l'autre. J'illustre ceci sur un exemple plus bas, mais l'idée générale est qu'on ne devrait modifier que des parties de l'historique dont personne ne dépendra jamais plus. Cela exclut de travailler avec une branche expérimentale dont on manipule l'historique avant le report des modifications dans la branche stable, car cela désynchroniserait les différents dépôts où l'on continue de travailler dans la branche. Même avec une branche expérimentale par développeur, le développeur ne pourrait plus continuer de travailler dans sa branche après l'édition d'historique. Il n'y a que deux situations où l'édition d'historique est utilisable: soit on parle d'une suite de modifications qui n'ont jamais été publiées, soit on parle d'une suite de modifications publiées mais qui n'auront plus de descendants.

J'étais bloqué à ce stade depuis un moment. J'avais découvert mercurial, l'édition d'historique, la gestion facilitée des branches, les commits locaux, etc. Mais je ne trouvais pas de solution à mon problème. Jusqu'à ce que je lise A Git Workflow for Agile teams qui fait pile ce que je veux. La clé est de vraiment faire PLEIN de branches: une par feature ou bug. Quand on a fini de préparer la modification, au moment d'intégrer les modifications dans la branche principale, on peut éditer l'historique et personne ne touche plus à la branche. Pour penser à ça, il faut vraiment oublier les SCM comme SVN, où gérer une branche est pénible, et être habitué à un SCM distribué, où c'est censé être tout naturel.

Je vous refais la recette, en français et en mercurial... Vous pouvez quand même lire l'article original, qui dit quelques choses en plus, notamment la correspondance entre branches et tickets/issues.

Un exemple

On a Alice et Bob qui bossent sur le même projet. Ils ont tous les deux contribué dans la branche 123-new-feature, chacun un commit. L'historique ressemble à ça:

@  changeset:   3:f3a6c5394605
|  tag:         tip
|  parent:      0:11575ff21a29
|  user:        Alice 
|  date:        Tue Jan 11 15:34:05 2011 +0100
|  summary:     Dummy
|
| o  changeset:   2:c6dc5c92d631
| |  branch:      123-new-feature
| |  user:        Bob 
| |  date:        Tue Jan 11 15:15:26 2011 +0100
| |  summary:     Plus expressif!
| |
| o  changeset:   1:fafdcd7dccf5
|/   branch:      123-new-feature
|    user:        Alice 
|    date:        Tue Jan 11 15:11:40 2011 +0100
|    summary:     Nicer.
|
o  changeset:   0:11575ff21a29
   user:        Alice 
   date:        Tue Jan 11 15:08:58 2011 +0100
   summary:     Initial commit.

Alice et Bob sont satisfaits de leur code, Alice va donc fusionner les deux commits et les passer dans default. On utilise l'option --keep pour ne pas détruire tout de suite la branche. En gros on prend le noeud 1 et ses ancetres, on fusionne, et on recolle la modification résultante sur le noeud 3.

$ hg rebase --collapse --keep --source 1 --dest 3

@  changeset:   4:2bf346072a24
|  tag:         tip
|  user:        Alice 
|  date:        Tue Jan 11 15:15:26 2011 +0100
|  summary:     Plus joli et plus expressif!
|
o  changeset:   3:f3a6c5394605
|  parent:      0:11575ff21a29
|  user:        Alice 
|  date:        Tue Jan 11 15:34:05 2011 +0100
|  summary:     Dummy
|
| o  changeset:   2:c6dc5c92d631
| |  branch:      123-new-feature
| |  user:        Bob 
| |  date:        Tue Jan 11 15:15:26 2011 +0100
| |  summary:     Plus expressif!
| |
| o  changeset:   1:fafdcd7dccf5
|/   branch:      123-new-feature
|    user:        Alice 
|    date:        Tue Jan 11 15:11:40 2011 +0100
|    summary:     Nicer.
|
o  changeset:   0:11575ff21a29
   user:        Alice 
   date:        Tue Jan 11 15:08:58 2011 +0100
   summary:     Initial commit.

A ce stade on peut même carrément virer la branche du dépôt. Les données correspondantes seront alors perdues pour toujours.

$ hg strip 1

@  changeset:   2:2bf346072a24
|  tag:         tip
|  user:        Alice 
|  date:        Tue Jan 11 15:15:26 2011 +0100
|  summary:     Plus joli et plus expressif!
|
o  changeset:   1:f3a6c5394605
|  user:        Alice 
|  date:        Tue Jan 11 15:34:05 2011 +0100
|  summary:     Dummy
|
o  changeset:   0:11575ff21a29
   user:        Alice 
   date:        Tue Jan 11 15:08:58 2011 +0100
   summary:     Initial commit.

C'est tout beau! Mais si Alice a détruit sa branche, cela ne se propagera pas chez Bob. Au contraire, si Alice se synchronise avec Bobe elle récupérerait la branche, qui apparait en fait comme étant nouvelle pour son dépôt qui en a perdu toute trace.

Si on pousse les modifications d'Alice chez Bob (éventuellement vai un dépôt central) la modification numéro 2 va être transmise. La branche 123-new-feature reste dans les autres dépôts -- en d'autres termes l'historique n'est pas lui même versionné. Bob pourrait donc faire d'autres modifications dans la branche, ce qui n'est bien sûr pas trop souhaitable...

# Bob fait une modif (#3) et la commite

o  changeset:   5:2bf346072a24
|  tag:         tip
|  user:        Alice 
|  date:        Tue Jan 11 15:15:26 2011 +0100
|  summary:     Plus joli et plus expressif!
|
o  changeset:   4:f3a6c5394605
|  parent:      0:11575ff21a29
|  user:        Alice 
|  date:        Tue Jan 11 15:34:05 2011 +0100
|  summary:     Dummy
|
| @  changeset:   3:b37a07ad9982
| |  branch:      123-new-feature
| |  user:        Alice 
| |  date:        Tue Jan 11 15:39:38 2011 +0100
| |  summary:     Never enough of that.
| |
| o  changeset:   2:c6dc5c92d631
| |  branch:      123-new-feature
| |  user:        Bob 
| |  date:        Tue Jan 11 15:15:26 2011 +0100
| |  summary:     Plus expressif!
| |
| o  changeset:   1:fafdcd7dccf5
|/   branch:      123-new-feature
|    user:        Alice 
|    date:        Tue Jan 11 15:11:40 2011 +0100
|    summary:     Nicer.
|
o  changeset:   0:11575ff21a29
   user:        Alice 
   date:        Tue Jan 11 15:08:58 2011 +0100
   summary:     Initial commit.

Si maintenant on pousse les modifications de Bob à Alice, on a la situation suivante, où les modifications individuelles de la "vieille" branche sont suivies d'une nouvelle modification...

o  changeset:   5:b37a07ad9982
|  branch:      123-new-feature
|  tag:         tip
|  user:        Alice 
|  date:        Tue Jan 11 15:39:38 2011 +0100
|  summary:     Never enough of that.
|
o  changeset:   4:c6dc5c92d631
|  branch:      123-new-feature
|  user:        Bob 
|  date:        Tue Jan 11 15:15:26 2011 +0100
|  summary:     Plus expressif!
|
o  changeset:   3:fafdcd7dccf5
|  branch:      123-new-feature
|  parent:      0:11575ff21a29
|  user:        Alice 
|  date:        Tue Jan 11 15:11:40 2011 +0100
|  summary:     Nicer.
|
| o  changeset:   2:2bf346072a24
| |  user:        Alice 
| |  date:        Tue Jan 11 15:15:26 2011 +0100
| |  summary:     Plus joli et plus expressif!
| |
| o  changeset:   1:f3a6c5394605
|/   user:        Alice 
|    date:        Tue Jan 11 15:34:05 2011 +0100
|    summary:     Dummy
|
@  changeset:   0:11575ff21a29
   user:        Alice 
   date:        Tue Jan 11 15:08:58 2011 +0100
   summary:     Initial commit.

Pour réparer cela, il faudrait reporter uniquement la modification 5 sur 2. Mais le but est que cela n'arrive pas, si les développeurs sont bien organisés. Par exemple, plutôt que de détruire la branche, il vaut mieux la garder, et utiliser la possibilité de fermer une branche dans mercurial (hg commit --close-branch). On peut imaginer que les très branches sont effacées périodiquement de tous les dépôts, quand il n'y a plus de souci possible.

Rebase sur un ancêtre

De façon pas très uniforme, le rebase de mercurial ne permet pas que la cible soit un ancetre de la source. C'est à dire que si on commence une branche alternative, et qu'on ne fait pas de modification dans la branche principale, on ne peut pas faire de rebase de la nouvelle branche dans la principale. Faire un simple merge ne nous permet pas de fusionner les différentes modifications. Il faut donc utiliser une routine un peu différente.

D'abord on se place dans la branche principale: hg update default. Ensuite, sans changer notre position dans l'historique, on applique sur nos fichiers les modifs appliquées dans l'autre branche: hg revert -r tip --all. Enfin, on commit ces modifications en une fois: hg ci -m "Combined.". Voila, 1 et 2 sont devenus 3:

@  changeset:   3:b29ddaf6c31c
|  tag:         tip
|  parent:      0:11575ff21a29
|  user:        Alice 
|  date:        Tue Jan 11 15:57:58 2011 +0100
|  summary:     Combined.
|
| o  changeset:   2:c0aa9c6feb0a
| |  branch:      123-new
| |  user:        Alice 
| |  date:        Tue Jan 11 15:47:36 2011 +0100
| |  summary:     Two.
| |
| o  changeset:   1:23e96c98b90e
|/   branch:      123-new
|    user:        Alice 
|    date:        Tue Jan 11 15:47:29 2011 +0100
|    summary:     One.
|
o  changeset:   0:11575ff21a29
   user:        Alice 
   date:        Tue Jan 11 15:08:58 2011 +0100
   summary:     Initial commit.

Comme avant on peut se débarasser de la vieille branche avec hg strip 1.

La morale

Je ne sais pas comment tout cela fonctionne dans la durée et à grande échelle. J'imagine que parfois c'est plus compliqué que sur ce petit exemple, mais cela me semble valoir le coup d'essayer. Et ça a l'air de marcher pour des gens.

La question restante est donc surtout: quand et comment se jeter à l'eau avec savonet?

Design III: Liquidsoap tomorrow?

2010-12-17T15:16:00.002+01:00

In the previous post we've seen the problems with the current source at the core of liquidsoap. The point of doing so was to highlight the interest of a more principled design.

We could start with a mathematical notion of stream, but we haven't reached that point yet. As I've illustrated before, sources are inherently interactive objects, which is hard to account for.

Instead, I'll keep the same practical notion of source but do one simplification: we'll work sample by sample. We'll have a #is_ready method that tells whether the source can produce a sample for the current instant. A source is always ready when it is in the middle of a track. And we have the #get method which returns at most one sample, none when the current track ends, and should never be called unless the source #is_ready.

As before, a source is passive by default (it doesn't produce data when not asked to) and caching mechanisms ensure that a source gives consistent answers to several observers. Depending on how/when it is used, a source will generate a stream, possibly undefined at some instants, but otherwise containing samples, metadata and end of track markers. Note that we need more precision than just time to denote a point in such a stream, in order to be able to tell the position relative to end of tracks -- it is possible to have several consecutive end of tracks exactly at the same point in time.

Let us detail caching, which isn't totally trivial. What do we cache: a number N of end of tracks, corresponding to partial #get, possibly followed by a sample. How do we use that cache: for an operator which already had M end of tracks and performs a #get, we return an end of track if M<N, the sample otherwise.

In the current liquidsoap, this M is passed as part of the frame, but there is no way to track which source has produced which end of track. Hence it is possible that M>N, for example in case of a switch which has seen many empty tracks before switching to that source. Even when M<N, it makes it unclear how many end of tracks we should add. I'm not sure whether it is crucial that we keep precise track of who produces which end of track.

What matters is (1) if you listen continuously to a stream, you get exactly all its content and (2) we don't have the first problem with sharing. This is because various operators of a source can only get data at one instant. If I pump it, the source will generate (or find in its cache) an end of track or a sample. It's as simple as this, there's no bad side-effect here. We don't even need to worry about sharing detection, because we can perform caching all the time without changing the stream content -- efficiency isn't an issue for now. (At some point I was worried that sub-instantaneous data is in the cache, i.e. end of tracks, could lead to the same problem as before, but it does not make sense because this data can't be refered to without first generating it: you can't pump a source "after" it has generated end of tracks, you can only pump it, ignore end of tracks, and pump it again.)

For our second problem, we would simply cache the result of #is_ready (rather, rely on the same cache). As with #get, we need to know the number of end of tracks already obtained by the observer to tell him if the source is ready at that precise point.

Some minor remarks:

We can't distinguish a source that is in the middle or just before the beginning of a track. If you don't listen to a source for a while, and the source is ready when you come back to it, there's no way to know if it is about to start something new or if you missed the beginning of the current track. It's never been a problem, I'll assume we can keep living with it.
The implementation of end-of-track notification is still a "partial" #get which may be too ad-hoc. The alternative is to attach an end-of-track tag to the last sample. Looks like a meaningless choice to me.
Note that metadata and end-of-tracks are treated very differently: we never issue a partial #get because of metadata. It corresponds to a view where, end of tracks are "after" the last sample, while metadata is "before" or maybe "inside" samples. We should try to generalize this into a nice notion of event, some being interruptions, some not.
With Samuel, we have explored other design choices. What I present here isn't his favorite, but it's the most convincing to me. It also has the advantage of being fully defined (at least in my mind).

This new model is not revolutionary. But we gained more than it seems. For example, we can now write an operator that takes two sources and sums them, only producing data when both of them are ready, and not pumping any of them when none is ready. The reason is that in the old frame-based design, we can only get data until either the end of a frame or the end of a track. But if one source ends a track, the other will still fill a frame.

Lifting to frames

The real challenge now is to derive an efficient frame-based model that faithfully reflects the simply sample-based model.

I'll start with the biggest problem: sharing. We can't approximate it anymore, or we'll obtain the same problem. Hence I'm going to propose a two-phase pumping: In a first abstract phase we do a dry run of the pumping methods to know who pumps who at what instant. Then we have a precise picture of the sharing and we can do a real run, computing the actual stream content.

This method forbids some source behaviors: for example if a source acts differently based on the actual values of its input samples, it cannot meaningfully take part to the first phase. That would be a problem with a blank detection source. I believe we can relax this enough to get what liquidsoap currently does. The key is to declare some values as "sparse" or "slow", allowing the change of the value (and hence the reaction of the source) to only take place at the end of the frame. For example blank detection would set a flag that only takes effect for the next frame.

For most sources I want to automatically generate the #simulated_get method from a simple #get. This is why compilation is needed now.

Now, I believe I can run that simulation thing. The nice thing is that once I bite the bullet and decide we need this, there's no question about being more modest in other places. In particular, the new #is_ready will be asked not only if a source is ready at a particular point but for how long. This enables a nice frame-based implementation of the precise sum operator described above. Of course, it goes with a #get that takes not only a start but also a stop position.

Plans

There are several things we can do now:

Compile frame-level sources from sample-level sources written in OCaml. This is only about analysing the source, and it does not need be user-friendly. There are a couple tricky analysis to run. For example, a sine source will have a counter decremented at each sample and reset after an end of track, and we'll have to turn this into the natural code for the frame-level sine.
Extend liquidsoap scripts with a notation for sources and compile it down to OCaml objects. We'll have to ensure that the user never sees a type error coming from OCaml, but only errors from us, which should be more readable. The main extra challenge is to run liquidsoap code fast. Some of it can be compiled directly to OCaml but function calls won't match exactly. We'll have to inline or leave some interpreter calls.
Do cross-source optimizations on top of the previous work. If the user writes a sum of sine sources, inline it into a source that computes directly the sums.
Compile to C or even lower level code.

I gave a rather precise proposal of what Step 1 could look like. Still we can discuss some points, try to generalize a few things. My proposition doesn't look as clean as I would like in some places, but it has one great advantage: I'm sure we can program liquidsoap sources with that model, and even do some things currently impossible.

Step 2 presents even more design choices: should users write sources in an OO style like we do? should they work with an explicit notion of time? should time be discrete or continuous?

Design II: Liquidsoap today

2010-12-10T15:11:00.003+01:00

In this post, I will give a high level picture of the current internals of liquidsoap, show a few problems with them. The interested reader can read further details on the design of liquidsoap in our papers. In the next post, I'll finally describe a better future for liquidsoap.

The source protocol

In order to get a minimum understanding of liquidsoap's streaming model, let us consider the following example:

output(fallback([queue,playlist]))

What we want here is to produce a stream either from the playlist or the queue of requests, and output it somehow. The fallback between our two sources only switches from one to the other for new tracks. For example, if the queue becomes available while we are in the middle of a playlist track, we'll keep playing the playlist track, and only switch to the queue for the next track. In order to obtain the expected behavior this means that (when possible) unused sources are (almost) frozen in time: the queue doesn't start playing its request until the fallback asks it to do so. The stream of a source isn't defined in itself, but computed in interaction with the source's environment. Simply put, it's on-demand streaming.

Now what happens concretely. Streaming is clocked, and at each cycle of the clock we produce a frame, which is simply a buffer of samples (audio, video or MIDI) of fixed size/duration. The filling of the frame starts from the outputs: Our output passes the frame to the fallback, which passes it to the source that is currently playing a track, the frame is filled, passed back to fallback, which passes it back to output, which outputs the frame to the world.

Sometimes, it'll be a little different: When the child source of fallback ends its track, it won't completely fill the frame, which gives the opportunity for the fallback to select another source. The newly selected source isn't used right away. Instead, the partial frame is returned to the above operator, in our case the output, which passes it back because all it wants is a complete frame -- the story would be different with nested fallbacks. When the partial frame comes back, its filling is completed by the newly selected source.

We perform that kind of computation by having sources communicate with each other using just a few methods: we mainly have #get for filling a frame and #is_ready for knowing if a source has a ready track (ongoing or not).

All this works smoothly when sources are organized along a tree, i.e., when there is no sharing. But we really want sharing, as seen in the following example:

source = fallback([queue,playlist])
output_1(source)
output_2(source)

This means that at each cycle of the clock, the source will be asked twice to fill a frame with a segment of its stream. Of course, the source should give the same data twice: we don't want to split our stream among the two outputs, one frame each. To deal with this, we have some caching mechanisms in #get. In more details, we create new sources by inheriting from a base class which defines #get as a public method wrapping the virtual private method #get_frame which can be written without thinking about sharing at all.

Problem #1

Caching everything is really costly, so we have to detect when sharing is needed. The problem is that sometimes, it's not easy to tell statically:

output(
  switch([
    ({am},fallback([queue,am_playlist]),
    ({pm},fallback([queue,pm_playlist])]))))

Here it looks like the queue is shared, but in fact the first occurrence can only be used in the morning (am), the second only in the afternoon (pm). While we could try to detect some of those cases, it is hopeless to catch them all. So we're bound to over-approximate sharing. This has been done, and isn't too complicated, although it does introduce some activation/deactivation methods that must be used carefully, especially when using transitions. This is okay regarding performance, but it has one nasty side effect: the approximation can have an impact on the stream!

The scenario is as follows: Take a source S which looks like it could be used by operators A and B. Now A asks S to start filling a frame from the middle (it happens, cf. the fallback example above) but the source sees that it could be also be used by B, perhaps to fill a frame from the beginning. So S fills in its cache from the beginning, and copies the part of it that starts from the middle in A's frame. But if B never uses S, we'll have modified our behavior for nothing.

Problem #2

An even worse problem is that we implemented some caching mechanism for #get but not #is_ready. Now, it is possible that a source fills its cache, has no new track to produce, and hence declares itself as not ready. Which might not be correct from the viewpoint of an operator that wants to access the data from the beginning of the cached frame. As a result of this weakness, I recently had to allow what should be illegal behavior in some operators that rely quite precisely on the readiness of their sources. Of course, this is a slippery slope.

Next time, I'll describe a simple way to construct a better source protocol from first principles, avoiding those problems, and even getting more expressiveness by the way. On the other hand, it'll have to be compiled. Stay tuned.

Design

2010-12-09T08:42:00.006+01:00

I recently found a good series of articles on LtU, on the Ghosts of UNIX past. The author reflects on some successes and failures of Unix, trying to find patterns. I enjoyed reading the articles, they teach you a few things, and are generally good food for thought.

The first article describes the "full exploitation" pattern, successfully achieved in UNIX with files. The next articles describe various failures of UNIX design, classifying them in "conflated", "unfixable" and "high-maintenance" designs. While I don't have the culture to do the proposed exercises, I tried to relate this to programming language design -- which suprisingly hasn't been done on LtU.

Full exploitation is when you manage to re-use a concept a lot. This is good because it avoids inventing new things: it's hard enough to get a few concepts right. In programming languages, a good first-class notion of functions can be fully exploited to model control, event handlers, lazy computation, etc.
Conflated designs mix up several concepts. This is bad only if the two concepts cannot be separated. Otherwise, it's just syntactic sugar. Object oriented programming comes to mind: Methods are a conflated design, mixing functions and record members. Also, inheritance mixes record extension and dynamic binding -- which makes it hard for people to think about the latter aspect, a very important source of bugs.
Unfixable designs are unfixable designs. This is a bad definition, but sometimes it is hard to say why something is unfixable. Often, this has to do with the wide adoption of the wrong design. Note that conflated designs may often be fixable, essentially by creating ways to access conflated notions in isolation. I'm not sure what's a good programming language example here. Perhaps dynamic binding, probably stuck forever in emacs lisp. (By the way, a fun fact according to Olivier Danvy: dynamic binding was born from exagerated exploitation of a single stack in the implementation of Lisp -- in those old days, people were psyched about stacks and got a bit carried away.)
High-maintenance designs have nothing wrong in themselves but interfere with other things in such a way that requires a lot of care and work in those areas. With programming, various difficult things come to mind: state, concurrency, dynamic binding... Those aspects make it very hard to reason locally about a piece of code. In themselves, state and concurrency are cool, but their interaction leads to many problems.

More than programming languages, liquidsoap was in the back of my mind. But there does not seem to be interesting examples of those patterns in liquidsoap. In fact, it is not an exceptionally good design. It's just a first shot at making an end-user streaming application that is not just one object/tool but rather a system/language for building tools. Liquidsoap introduces an abstract notion of source, which is good, but does not fully exploit it. For instance, blank detection operators are black boxes that encapsulate the computation of the average audio volume, but a more flexible and efficient design would be achieved by isolating the computation of the volume stream as a source, then write operators that act depending on the characteristics of the volume source. Liquidsoap does not have unfixable designs because we give ourselves the liberty to change things when needed. It does have high-maintenance designs: the source protocol is complex, and we've had many bugs because it wasn't properly followed.

Beyond those not-so-good design examples, liquidsoap is broken in several ways. But I'm comfortable to admit it because it works good enough for many people and we know how to fix it. The code name for that exciting new line of work is, quite straightforwardly, Liquidsoap 2.0. Until now, we've been writing sources by hand in OCaml. Liquidsoap users write scripts in our own scripting language, and can only compose sources, never write a new one. In other words, Liquidsoap is an interpreter for a dedicated script language that manipulates an abstract/opaque notion of source. But liquidsoap 2.0 will be a compiler that lets you write sources, and not only compose them, and will produce optimized code. It will be as simple as it is today for beginners, but will enable much more for power users. Importantly, it will allow us developers to not write as much bug-prone code. There is a lot to say about what could be in liquidsoap 2.0, but I'll start with a simple down-to-earth story... next post!

Random.self_init

2010-10-20T15:15:00.008+02:00

Maintenant que je travaille un peu dans le domaine de la sécurité, je pense notamment aux générateurs de nombres aléatoires. Après quelques lectures sur le sujet, je me suis demandé comment fonctionnait le module Random de Caml.

Il y a sûrement beaucoup de choses à dire, mais mon attention a été retenue par un truc simple: self_init initialise le générateur de façon très simple, à partir de l'heure et de l'identifiant du processus, données pour le moins aléatoires. Il faut donc vraiment se méfier de cela si on souhaite utiliser le module Random à des fins cryptographiques. En pratique, le petit bout de code suivant devine assez rapidement la graine générée, en supposant connu l'identifiant du processus (ce n'est pas bien dur à deviner sinon) et en supposant approximativement connue l'heure de l'initialisation:

(** Random.self_init relies on caml_sys_random_seed
  * which returns an int.
  * That integer is sec ^ usec ^ ppid<<16 ^ pid.
  * We try to guess the seed to reproduce the output of
  * the random generator.
  * The PID and PPID are supposed to be known,
  * the time in seconds and micro-seconds is supposed
  * to be known resp. with precision 1s and 1000ms.
  * With that knowledge it's really fast;
  * with less it'd take longer. *)

let gen sec usec pid ppid =
  sec lxor usec lxor pid lxor (ppid lsl 16)

let random _ = Random.int 100

(** Given a leaked sequence of numbers consecutively
  * generated by [random] _immediately after_
  * [Random.self_init], call [k] with seeds that allow
  * to reproduce that sequence. *)
let crack leak k =
  let t = Unix.gettimeofday () in
  let sec = int_of_float t in
  let usec = int_of_float (fst (modf t) *. 1_000_000.) in
  let pid = Unix.getpid () in
  let ppid = Unix.getppid () in
    (* Since we sec and usec are xored, trying sec and
     * sec-1 would be useless: all we'd be doing is
     * flipping a bit that is flipped anyway when
     * enumerating posssible values for usec. *)
    for usec = usec - 10000 to usec do
      let seed = gen sec usec pid ppid in
        Random.init seed ;
        if Array.init (Array.length leak) random = leak then
          k seed
    done

let () =
  let leak,valid =
    Random.self_init () ;
    let leak = Array.init 1000 random in
    let valid = Array.init 5000 random in
      leak, valid
  in
  let k seed =
    let guess =
      Random.init seed ;
      ignore (Array.init (Array.length leak) random) ;
      Array.init (Array.length valid) random
    in
      Printf.printf
        "Guessed seed: %d. Validated: %b.\n"
        seed (guess=valid)
  in
    crack leak k ;
    Printf.printf "Search space exhausted.\n"

Quand on le lance, on a quelque chose comme ça en quelques secondes:

$ ocamlopt unix.cmxa crack.ml -o crack && ./crack
Guessed seed: 262818353. Validated: true.
Search space exhausted.

Il y a diverses variations possible. Ce qui m'intéresse, et qui est encore assez obscur pour moi, c'est la génération (répétitive) de graines à partir d'une partie privée et d'une partie publique, utilisée pour éviter d'avoir des séquences générées identiques (ce qui exposerait à des attaques dans certains cas). A quel point on affaiblit ou compromet son secret, en fonction du générateur utilisé, etc?

Qui me regarde?

2010-08-30T06:38:00.001+02:00

Deux petites histoires un peu angoissantes...

(1) Je suis parti en vacances sur la route dans l'Ouest américain, et comme nous sommes passés par Las Vegas, j'avais cherché sur mon portable des hotels là bas. De retour de vacances, je me suis retrouvé plusieurs fois sur des pages webs quelconques avec de la pub pour des hotels à Las Vegas.

(2) Suite à une mésaventure, je me suis acheté une nouvelle montre. Comme Estelle voulait voir comme elle était belle, j'ai fait une petite recherche d'image sur le web. Et hier, j'ai reçu un mail d'Amazon m'annonçant une promo sur cette marque de montre en particulier.

Je suis pas parano, tout ceci n'est pas dû au hasard? Mais la seule explication serait que google ait vendu la mêche, mais cela suppose aussi que ces sites m'identifient, ce qui va un peu loin...

Edit: En fait, j'ai dû cliquer sur un lien Amazon pour la montre, c'est le plus probable. On est toujours connecté à Amazon, c'est traître.

Liquidsoap: retour aux sources

2010-04-27T21:12:00.002+02:00

Vous savez sûrement que je passe cette année aux Etats Unis et plus précisemment à Minneapolis, Minnesota. Mais savez-vous vraiment pourquoi? C'est dans cet Etat qu'a été inventé le savon liquide! C'est donc logique que je m'isole ici pour me recueillir et bourriner sur liquidsoap le logiciel.

Liens

2010-02-17T18:20:00.003+01:00

Quelques lectures qui se font écho, dans l'air du temps. Je ne m'inquiète pas trop de certaines craintes vis-a-vis d'Internet, du genre "Google nous rend bête, l'homme n'utilise plus sa mémoire, n'écrit plus". Globalement, j'ai grandi avec et je me sens pas trop con. Par contre, je suis plus sensible à d'autres remarques sur la façon dont l'Internet évolue. Ce n'est pas que de la nostalgie, et il ne s'agit même pas seulement d'Internet: la politique, la créativité et la culture, la SF vs. le fantastique et le mystique, le rapport au monde.

Sur Commondreams, The Information Super-Sewer:

“The crowd phenomenon exists, but the hive does not exist,” Lanier told me. “All there is, is a crowd phenomenon, which can often be dangerous. To a true believer, which I certainly am not, the hive is like the baby at the end of ‘2001 Space Odyssey.’ It is a super creature that surpasses humanity. To me it is the misinterpretation of the old crowd phenomenon with a digital vibe. It has all the same dangers. A crowd can turn into a mean mob all too easily, as it has throughout human history.”

Sur écrans.fr, Fuck Google:

Nous utilisons Google, Gmail, Youtube, ses calendriers, documents, cartes, etc. Nous les utilisons comme les WC publics quand nous devons aller pisser ; parce qu’il semble qu’il n’y ait pas d’autre option. Or il existe des alternatives. [...] Web 3.0 : le grand repli sur vos propres serveurs.

Et aussi Le Web, c'est folk:

Les amateurs d’aujourd’hui préfèrent la « fantasy », les elfes et les animaux étranges aux thèmes de science-fiction très populaires au début du Web : « L’idée de construire un vrai futur en ligne a été remplacée par une échappatoire vers un monde imaginaire. » [...] Les usagers sont « autorisés » à télécharger leur production sur de nombreux services différents, ce qu’on faisait déjà il y a quinze ans mais sur son propre serveur. Cette vision cynique des usagers se perpétue, ils sont divertis, mais également exploités en tant que producteurs de contenus et cliqueurs de publicités. Le « nuage informatique » va encore diminuer leur rôle au profit de puissants ordinateurs centralisés. C’est l’opposé de l’idée de peer to peer où les utilisateurs construisaient des systèmes en connectant leurs ordinateurs.

Grant Petersen à propos de sa compagnie de bicyclettes, Rivendell:

Simple things make people feel smart, or at least competent, and complication has the opposite effect. If people feel smart and competent, they’re happy, and happy people are nice to other people, and it all starts or stops with how hard it is to use something.

Pour la route, une brochette d'artisanat:

Super pingouins, un bon vieux site, qui me touche au moins moi pour les bons souvenirs.
Liquidsoap, un outil de streaming surpuissant, développé lentement mais sûrement depuis 2003. C'est du logiciel libre développé en toute indépendance (sauf la pression des utilisateurs), même si c'est hébergé par le monstre Sourceforge. Mais le mieux, c'est les projets plus ou moins fous que les gens construisent avec cet outil! (On devrait vraiment s'occuper de rassembler une meilleure page de liens.)
Dolebraï, qui ne permet toujours pas à la foule de voter pour la musique qu'elle aime (en fait, c'est une feature militante) et qui est bien plus petit que Free Music Archive dans le même esprit.

Quel effet ça fait

2010-02-08T20:04:00.008+01:00

Quelle différence entre a→b→c et a→b→c? Pour le savoir, lisez ce qui suit.

De temps en temps, je regarde un article scientifique, ou un bout de code, et je n'en suis pas satisfait. Un truc me chiffonne, ça peut se réparer, mais ya autre chose qui cloche, et au fond c'est tout bancal, ça n'en finit pas, et il vaut mieux tout remettre à plat. Ceci est arrivé récemment dans liquidsoap avec le module de décodage de fichier. Ce n'est pas intéressant de détailler, il y a juste un point dont je voulais parler. Mais avant, je trouve que c'est important de dire qu'il faut remettre les choses à plat de temps en temps.

Donc, il s'agit de décodage. Première question: qu'est ce que c'est un décodeur? J'ai mis un peu de temps à essayer plusieurs styles, pour finalement décider input -> buffer -> unit, une fonction qui prend en entrée une méthode pour lire des données, et un buffer pour écrire le résultat du décodage, et qui ne renvoie rien mais remplit le buffer un peu plus à chaque fois qu'on l'appelle.

A côté de cette notion très générique on a des notions plus spécialisées comme le type file_decoder = { fill : Frame.t -> unit ; close : unit -> unit }. C'est un enregistrement qui contient une fonction de remplissage de flux (on lui donne une frame (un morceau de flux) à remplir) et une fonction de fermeture/nettoyage où l'on libère les ressources allouées pour le décodage.

Ceci étant décidé, j'écris un bout de code générique qui emballe un décodeur pour construire un décodeur_de_fichier:

let file_decoder filename decoder =
  let input = input_from_file filename in
  let buffer = create_buffer () in
  let fill frame =
    while not_enough_data_in buffer do
      decoder input buffer
    done ;
    fill_frame_from_buffer frame buffer
  in
    { fill = fill ; close = fun () -> close input }

Vous me suivez? Maintenant, j'implémente un décodeur, pour le format MP3 en utilisant la bibliothèque mad:

let create_decoder input =
  let resampler = create_resampler () in
  let mad_stream = Mad.openstream input in
    (fun buffer ->
       let data = Mad.decode_frame_float mad_stream in
       let sample_freq,_,_ = Mad.get_output_format fd in
       let content,length =
         resampler ~audio_src_rate:(float sample_freq) data
       in
         put_audio_in_buffer buffer content length)

PAF! Vous voyez le bug? Je parie que non, en tout cas moi je l'avais raté. J'ai réussi à ne pas être d'accord avec moi même, penser a→b→c ici et a→b→c là!...

Le problème, c'est les effets. En mathématiques, une fonction prend un argument et renvoie un résultat. On ne sait pas comment ça se passe "dedans", en tout cas ça n'interagit pas sur le "dehors", et ça se passe pareil à chaque fois: même entrée, même sortie. En informatique, c'est bien plus compliqué. La fonction interagit avec le monde, elle peut afficher quelquechose à l'écran, elle peut aller chercher un résultat sur internet, dans un fichier, ou simplement dans une case mémoire qu'elle partage avec d'autres fonctions. On est ainsi habitué à avoir tout un paquet de fonctions de type a→b, puisqu'il ne s'agit pas seulement de prendre un objet de type a pour calculer un objet de type b mais aussi potentiellement de se livrer à tout un tas d'interactions avec le monde.

Mon code utilise cela, mais se prend les pieds dedans. Ce qui est joli, c'est que j'ai une "solution". Mais voyons d'abord le problème. Notre décodeur prend un canal d'entrée (input), un canal de sortie (buffer), et est supposé avoir comme effet de lire un peu de données en entrée, de les convertir et les écrire en sortie. Il ne renvoie rien d'utile (unit), tout son interet réside dans l'effet; si on l'appelle un assez grand nombre de fois, on finit par avoir assez de données dans notre buffer -- c'est ce qu'on a fait plus haut. On peut cacher un certains nombres d'informations dans le décodeur, c'était mon intention, par exemple j'y ai alloué un resampler pour convertir les données vers la bonne fréquence d'échantillonage: cet outil doit être (et est bien) crée une fois et une seule pour chaque décodeur.

Ce resampler maintient un état interne, tout comme le décodeur mad (mad_stream). Allouer ces objets est aussi un effet! Mais à quel moment a-t-il lieu? Le type ne l'indique pas: dans input->buffer->unit, après quel argument un effet peut-il avoir lieu? Dans le code de file_decoder j'utilise un décodeur comme si le seul effet était le décodage, qui a lieu une fois qu'on a renseigné l'input et l'output. Mais dans le code du décodeur MP3, pas le choix, je m'autorise un effet entre le moment où on m'a donné l'input et le moment où on me donne le décodeur. Résultat, quand on utilise file_decoder avec le create_decoder MP3, on a un son tout haché, car le décodeur et le resampleur sont reinitialisés sans arrêt, ce qui provoque la perte d'une partie des données mémorisées dans leurs buffers internes.

Ces problèmes sont très vicieux, et sont toujours un sujet de recherche active. Mais concrètement, que peut-on y faire avec les outils d'aujourd'hui? Documenter, espérer que tout le monde se comprend? Pas terrible, j'ai réussi à être en désaccord avec moi-même sur une courte période de temps. Comme d'habitude, ce serait bien si le système de type nous servait de garde fou.

En logique, la notion de focalisation (focusing) est liée à la question des effets. Une formule logique est vue comme un jeu entre deux joueurs: un qui prouve l'autre qui réfute, ou encore, l'environnement qui fournit une entrée (argument) et la machine qui renvoie une sortie (valeur de retour). Les connecteurs logiques sont attribués à l'un ou à l'autre joueur: dans (int*int)→(int*int) c'est d'abord l'environnement qui donne un argument, directement composé de deux entiers; puis la machine calcule un résultat, directement composé de deux entiers. Ici je dis directement, car on ne peut pas demander une réponse partielle à la machine, tout ceci vient d'un coup, une unique réponse à une seule question. La dynamique associée au type int→int→(int*int) est exactement la même: il n'y a pas deux questions à l'environnement, mais une seule, les deux entiers en entrée arrivent d'un coup. Là dedans, les seuls effets ne peuvent donc se situer qu'à l'interface entre les deux joueurs, dans le calcul qui se passe entre une question et une réponse.

Commençons à redescendons sur terre. Pour introduire la possibilité d'un effet, en focalisation, on peut introduire un délai. Par exemple, si on veut une paire d'entiers paresseuse (dont le contenu n'est calculé que si nécessaire), on retarde le calcul des int: (unit->int)*(unit->int). Dans l'autre sens, on peut aussi vouloir retarder le moment où un argument est passé, par exemple avec a->(unit*(b->c))... c'est ce qu'il nous faut!

On la refait avec un délai autour du décodeur, implémenté non pas comme (unit*...) mais plus agréablement avec un type variant:

type decoder = Decoder of (buffer -> unit)
type file_decoder = input -> decoder

let file_decoder filename decoder =
  let input = input_from_file filename in
  let buffer = create_buffer () in
  let Decoder f = decoder input in
  let fill frame =
    while not_enough_data_in buffer do
      f buffer
    done ;
    fill_frame_from_buffer frame buffer
  in
    { fill = fill ; close = fun () -> close input }

let create_decoder input =
  let resampler = create_resampler () in
  let mad_stream = Mad.openstream input in
    Decoder (fun buffer ->
       let data = Mad.decode_frame_float mad_stream in
       let sample_freq,_,_ = Mad.get_output_format fd in
       let content,length =
         resampler ~audio_src_rate:(float sample_freq) data
       in
         put_audio_in_buffer buffer content length)

Le code du décodeur MP3 n'a changé que d'un iota, mais cela suffit à forcer sa bonne utilisation dans file_decoder, c'est à dire à passer l'input une fois pour toute, et ne plus passer que le buffer dans les appels suivants. Vraiment? Non, à vrai dire, on peut toujours se prendre les pieds dedans, ne serait-ce que parce que c'est possible de traduire entre le vieux type de décodeur et le nouveau, en violant ainsi la logique qu'on a tenté de forcer. Mais en pratique, ce petit garde fou pousse à faire naturellement la bonne chose, ou au moins à se poser la question.

Tout est bien qui fini bien. Cette histoire pourrait aussi s'intituler "à quoi diable pourrait bien servir un type variant avec un seul constructeur?" Ou encore, "c'est fou comme de belles idées théoriques ont du sens même en dehors de leur strict cadre théorique."

Pointilleux

2009-09-08T00:50:00.005+02:00

Cet été j'ai (re)bricolé à une petite idée, au début en Caml, puis pour diverses raisons je me suis essayé au flash via HaXe. Bah c'est globalement chouette.

Ce truc n'est qu'un premier résultat, mais il m'a déja pris trop de temps alors je le lâche ici, en guise d'abandon sur la route du retour de vacances. Par contre je me sens pas encore de lâcher le source (relativement court).

Citations

2009-07-17T15:19:00.005+02:00

Je viens de retomber sur des citations que j'avais glanées quand je préparais la rédaction de ma thèse. Finalement je n'en ai mis aucune dans mon manuscript, tout simplement. Mais comme je les aime toujours bien, voici.

Reality is that which, when you stop believing in it, doesn't go away.
Philip K. Dick.

A partir d'un certain moment, il devient simple de comprendre des choses très compliquées; et compliqué de comprendre des choses très simples.
Francis Dannemark, L'hiver ailleurs.

La vie n'est ni simple ni complexe, elle est.
Antoine de Saint-Exupéry, Citadelle, 1948.

Ne parle plus. Ne pense plus. Laisse ta main se promener sur moi. Laisse-la être heureuse toute seule. Tout redeviendrait si simple si tu laissais ta main seule m'aimer. Sans plus rien dire...
Jean Anouilh, Eurydice, 1942.

Quand on n'a rien à dire, comment le dire simplement.
René Etiemble, L'Hygiène des lettres (1952-1967), à propos de Julien Gracq.

Simple ne veut pas dire facile.
John Francis Jr, dit Jack Welch.

Il est toujours aisé d'être logique. Il est presque impossible d'être logique jusqu'au bout.
Albert Camus, Le mythe de Sisyphe, 1942.

Rêver, c'est se choisir soi-même selon une logique chaque fois particulière.
Jean Duvignaud, La Banque des rêves, 1979.

Si la vie réelle est un chaos, en revanche une terrible logique gouverne l'imagination.
Oscar Wilde, Le Portrait de Dorian Gray, 1891.

Illumination

2009-07-16T08:13:00.009+02:00

For some reason, I've found myself implementing bits of a text-mode rogue-like game. In a nutshell, this is a turn-based kind of game where the player moves on a grid which usually depicts a dungeon or a cave. Some cells of that grid/map might contain a wall/rock, in which case the player cannot see or walk through them. All this is rather straightforward to implement, but the computation of what the player sees deserves some attention.

I started thinking of casting rays, but only found clumsy, costly solutions. So I did a little research. Some people (including crawl) actually developed algorithms along these lines for computing what is called a permissive field of view:

A destination square is visible from a source square if there is any unobstructed line from some point in the source square to some point in the destination square.

It's apparently a modern notion of field of view, that has one advantage over older techniques: it ensures symmetry, i.e., if I can see you, you can see me.

The same article on roguebasin points to several algorithms, including the one implemented in crawl. They all seemed unsatisfyingly complicated to me. I eventually came up with a different idea that looks good and ensures symmetry. It might have been considered already and discarded for some of its funny aspects, but those are interested to look at.

The basic idea is to forget about those lines. We are talking about a discrete universe, let's try to make its physics discrete too. Geometrical optics is only a convenient metaphor, that is justified by more elementary principles such as Fermat's:

The path taken between two points of a ray of light is the path that can be traversed in the least time.

This is in fact a definition of a ray of light that we can take literally in our discrete rogue world:

A cell is visible from another if one of the shortest paths between them is unobstructed.

Let's look at a simple example. For now, suppose that the movements are only allowed along the axis (no diagonals):

.# 
@#y
.x.

The player is represented by @, and # are walls/rocks. The cell marked y is not visible: it is at distance 2, there is only one path of length 2 that connects it to the player but it is obstructed. Cell x is also at distance 2, but it is visible since one of the two paths of length 2 that connects it to the player is not obstructed.

A funny thing happens when you consider the traditional rogue movements which include diagonals: cell y becomes visible! Indeed, the light can take a path of length 2 through x.

I would tend to adopt rules where the topology is the same for players and light. Either embrace the diagonal movements but accept the surprising effect on light, or remove them both for the light and the player. I chose the less experimental way for now. But it is also possible to use different topologies for the two entities.

To finish, I will give the last reason why I like this solution: the code is stupid simple. Assuming that the radius of the field of view will always be within a fixed bound, we can compute once and for all the map of shortest paths with their dependencies.

(** The maps will be used to associate
  * the coordinates of the destination of a path
  * to the lists of the coordinates of possible previous step
  * in shortest paths leading to that destination. *)
module M = Map.Make (struct type t = int*int let compare = compare end)

let neighbors (x,y) =
  [ x-1,y ;
    x,y-1 ;
    x+1,y ;
    x,y+1 ]

let shortest_paths max =
  (** Map of distances to the center of the matrix. *)
  let dist = Array.make_matrix (2*max+1) (2*max+1) max_int in
  (** At each step we compute the shortests paths to cells
    * at distance [d=n+1] from those for distance [n]. *)
  let step d paths_n =
    M.fold
      (fun (x,y) _ m ->
         List.fold_left
           (fun m (x',y') ->
              if dist.(max+x').(max+y') < d then
                (* Seen in a previous iteration. *)
                m
              else if dist.(max+x').(max+y') = d then
                (* We already found a path of length n+1,
                 * but we need to keep track of this new one too. *)
                M.add (x',y') ((x,y)::M.find (x',y') m) m
              else begin
                (* First time we see it: first shortest path. *)
                dist.(max+x').(max+y') <- d ;
                M.add (x',y') [x,y] m
              end)
           m
           (neighbors (x,y)))
      paths_n
      M.empty
  in
  let rec aux d frontiers =
    if d=max then frontiers else
      aux (d+1) (step d (List.hd frontiers) :: frontiers)
  in
    List.rev (aux 1 [M.add (0,0) [] M.empty])

Then, it only remains to parse dependencies:

(** Takes a radius (d) and returns a field of view function
  * for that radius. *)
let fov d =
  let frontiers = shortest_paths d in
    (* The field of view function,
     * which takes a function and calls it on each visible cell.
     * The function [f] returns whether a cell is transparent or not. *)
    fun f ->
      let transparent = Array.make_matrix (2*d+1) (2*d+1) false in
        transparent.(d).(d) <- true ;
        List.iter
          (fun frontier ->
             M.iter
               (fun (x',y') deps ->
                  if
                    List.exists (fun (x,y) -> transparent.(d+x).(d+y)) deps
                  then
                    transparent.(d+x').(d+y') <- f x' y')
               frontier)
          (List.tl frontiers)

Hurray to (impure) functional programming! I leave it to you to glue this to whatever testing code you want. I'll finish with "screenshots".

Without diagonal moves, notice that it is possible to see through a wall on a diagonal:

              .
       .      ..
      ..    ##...
     #.. ###...# .
     #..#......##.#
     #.....@......#
     #...##........
     ...#.........
      ###........
        #.......
        ..####.
         .

With diagonal moves, we now have shadows along the diagonals, but we can see around walls placed along the axis:

        ..#..#...
         .......
   .######.....
   ...........
   .##.......
    #.......#
    #.......####   #
    #..........## ..
   .##..##.@....#...
   #...  ##...##..##
   ###    .......###
         ...........
        ............
       .............
      ###...........
        ............
       .##.####.....

Dynamisme=échec

2009-07-15T18:09:00.003+02:00

Petite update sur le post précédent.

Après la dernière modification, je me suis rendu compte que je ne prenais pas la linéarité assez au sérieux dans la version actuelle. J'ai essayé de corriger ça, mais je n'ai pas réussi à concilier linéarité et convivialité du système de types (i.e., pas d'annotation barbare).

La morale est qu'il n'y aura probablement pas de vérification statique du boxing temporel dans liquidsoap 1.0. Ce n'est pas la mort du petit cheval, on a déja une vérification dynamique pour la fallibilité (faite à l'instantiation d'une source). J'espère donc trouver le temps d'implémenter une vérification dynamique du boxing, ce serait largement mieux que le rien actuel.

Mise en boîte

2009-06-04T13:38:00.011+02:00

Depuis un bon moment, liquidsoap dispose d'un langage de configuration/script fonctionnel, fortement et statiquement typé, qui infère des types à la ML, le tout à l'insu de la plupart des utilisateurs. Pour liquidsoap 1.0 nous irons plus loin dans l'utilisation de concepts avancés avec (un peu) de vrai polymorphisme.

J'ai édité ce post deux ou trois dans les jours suivant sa publication. Peut-être que le blog n'était pas le format idéal.

Pourquoi?

Dans une conf liquidsoap, les fonctions sont parfois utiles pour éviter de recopier du code, ou pour spécifier une action à effectuer en réaction à certains évenements. Mais au coeur même de la génération du flux, les fonctions sont utilisées pour représenter les transitions entre pistes audio. (Détails ici.)

Cette même notion de transition pose des problèmes quant à l'écoulement du temps. Actuellement dans liquidsoap, toutes les sources de flux audio évoluent à la même vitesse, cadencées par une unique horloge. Pour calculer une transition entre deux pistes d'une même source, l'opérateur cross doit obtenir en avance le début de la piste suivante, et le combiner avec la fin de la piste en cours. Cela requiert d'accélérer cette source.

L'implémentation actuelle n'est pas une solution: Les opérateurs qui en ont besoin simulent l'action de l'horloge auprès de leur source, afin de l'accélérer. Cela marche souvent, mais il se peut que deux opérateurs lisent une même source à des vitesses différentes. Le résultat est inattendu, à éviter. Notre mission est d'éviter cela statiquement, avant même la construction des sources. Nous allons donc attacher un paramètre au type des sources, qui représentera son horloge, et spécifier dans le type des opérateurs s'ils requièrent des horloges particulières.

S'il est assez facile de bricoler le système de type pour obtenir l'effet désiré, il faut d'abord identifier les concepts "logiques" mis en jeux. J'ai honte, mais ça m'a pris du temps, car j'ai commencé par chercher dans des contrées exotiques alors que c'est assez connu, bien que pointu.

Polymorphisme

Le polymorphisme est la possibilité de former une quantification universelle sur les types. Si on a un objet de type ∀x. x->x, on peut l'instantier en une fonction de type int->int aussi bien que (bool->bool)->(bool->bool).

Dans les langages dérivés de ML, le polymorphisme est limité à une quantification externe. On peut avoir ∀x. x->x mais pas (∀x. x->x)->int->int. Le polymorphisme dans toute sa généralité, par exemple dans le système F, rend en effet l'inférence de type indécidable.

OCaml permet cependant d'aller un peu plus loin. La clé est que la création d'un type polymorphe doit être explicite dans le programme (cf. ce papier), par exemple associée à la création d'un enregistrement. Considérons la signature suivante:

(** Une source associée à l'horloge 'a *)
type 'a src

(** Une fonction qui renvoie une source qu'on peut
* associer à n'importe quelle horloge. *)
type boxed = { c : 'a. unit -> 'a src }

(** Cet opérateur prend une source en boîte,
* cela pourrait être le cross() de liquidsoap. *)
val box : boxed -> 'a src

val leaf : unit -> 'a src (* en gros, single *)
val node : 'a src list -> 'a src (* en gros, fallback *)

Voyons voir ce qu'on peut et ne peut pas faire avec ce système. On peut créer un certain nombre de sources avec leaf () initialement, elles auront le type '_a src: leur horloge est indéfinie, mais pas généralisable. On est content de ne pas voir de 'a src: cela correspondrait à une source qui peut se brancher sur toutes les horloges à la fois, non-sens. (C'est aussi pour cela qu'on n'a pas écrit boxed = { c : 'a. 'a src }, on n'aurait jamais pu construire de boîte.)

On peut passer une source de type '_a src à notre opérateur node, on obtient une autre source à la même horloge '_a. Si on passe deux sources à node, le système de type requiert que leurs horloges soient les mêmes (des inconnues '_a et '_b sont unifiées).

Maintenant, tentons de former des boîtes:

let b = box { c = leaf }
(* Gagné:
* une boîte qui nous donne une nouvelle feuille à chaque fois,
* horloge au choix. *)

let a = leaf ()
let b = box { c = fun () -> b }
(* Raté, erreur de type:
* la source a est de type '_a src,
* la fonction (fun () -> b) est de type unit -> '_a src,
* qu'on ne peut généraliser en 'a. unit -> 'a src. *)

let b =
box { c = fun () ->
let a = leaf () in
node [a;a] }
(* Gagné, on a une boîte qui nous renvoie une source composée,
* dont on peut choisir l'horloge. *)

On tient clairement le bon concept: le polymorphisme assure que l'horloge peut être choisie. En particulier on va pouvoir créer des nouvelles horloges dédiées à certaines sources (et leurs sous-sources). Reste à transférer ce petit exemple en quelquechose d'agréable à utiliser dans liquidsoap.

Liquidsoap 1.0

Actuellement dans liquidsoap, on écrit des choses comme:

music = playlist("list.txt")
backup = single("default.ogg")
source = fallback([music,backup])
transition = fun (a,b) -> ...
source = cross(transition,source)
output.icecast(source)

En collant au style de notre exemple en OCaml, nous devrions réécrire les choses ainsi:

transition = fun (a,b) -> ...
source =
cross(transition, {
music = playlist("list.txt")
backup = single("default.ogg")
fallback([music,backup])
})
output.icecast(source)

C'est trop lourd, et ma solution ne va différer que d'un epsilon du style courant:

music = playlist("list.txt")
backup = single("default.ogg")
source = fallback([music,backup])
transition = fun (a,b) -> ...
source = cross(transition,{source})
output.icecast(source)

Un point clé qui permet cette simplification est qu'on n'a besoin que d'une partie du polymorphisme: on veut la généricité, mais une seule fois. Pas besoin d'une fonction qui à chaque appel pond une source, comme dans l'exemple en Caml. Il suffit d'une seule source, tant que son horloge est générique.

Je pense qu'on ne peut pas se passer aisément du marqueur {source} qui indique qu'on généralise cette source. Il me semble acceptable de demander à l'utilisateur de marquer le coup quand il utilise cette notion complexe. (Par contre il va nous falloir choisir une syntaxe qui ne rentre pas en conflit avec l'actuel {...}, raccourci pour fun () -> ....)

Comment ça marche

J'ai une implémentation en OCaml qui me semble transposable à liquidsoap.

Comment OCaml vérifie-t-il que { c = fun () -> blah } est bien typé? Il introduit une nouvelle variable de type n pour représenter le 'a de 'a. unit -> 'a src, et vérifie qu'on peut donner le type n src à blah.

Nous allons faire la même chose, mais dans le désordre, pour permettre le genre d'écriture promis plus haut. Pour former une boîte (un type universel) sur une source, il faut que son horloge soit encore indéterminée. On vérifie cela en unifiant le type de cette source avec n src pour une nouvelle variable de type n comme OCaml faisait. Et une fois qu'on a ainsi réussit à former une boîte, on affecte cette variable à type à une valeur interdite Boom pour empêcher son utilisation ailleurs. Au lieu de créer les sources dans une zone protégée, on les crée en dehors, et on les y affecte après coup, ce qui rend alors leur horloge dénuée de sens à l'extérieur.

Un difficulté essentielle du polymorphisme vient du fait que pour inférer, on a besoin de savoir quel type universel on forme. Dans le cas de liquidsoap ma solution est très simple: on ne forme que ∀x. x src. On pourrait avoir d'autres types polymorphes, mais chacun aurait son constructeur particulier.

Ces mécanismes fonctionnent bien sur quelques exemples disponibles dans mon code:

ex0 = single ()
ex0 : '_a src # pas de généralisation, c'est comme avec ref

ex00 = let x = single () in {x}
ex00 : 'a. 'a src

ex1 = fun (x) -> cross(x)
ex1 : 'b. ('a. 'a src) -> 'b src

ex4 = fun (_) -> cross({single("blah.ogg")})
ex4 : 'a.'b. 'a -> 'b src

Un exemple plus subtil est ex2 = fun (x) -> {x}, ou la variation ex4 = fun (x) -> cross({x}) qui se rapproche de ex1. Ici une boîte est formée sur l'argument de la fonction, qui doit donc être une source. Ce genre de construction est problématique: la source doit être introduite avant son horloge. En pratique, cela se traduit par l'impossibilité de former le type de la fonction où devrait apparaitre le symbole interdit: Boom src -> 'a. 'a src.

Fouille de documents informatiques

2009-05-05T10:56:00.003+02:00

Ca fait plusieurs fois que je le lis, cette fois-ci d'une source officielle (CNRS), alors je l'écris pour les incrédules:

Il est fermement déconseillé d’emporter à l’étranger des supports informatiques contenant (ou ayant contenu) des données sensibles voire des données privées. Ces supports informatiques (ordinateurs portables, PDA, clés USB, CD, DVD, disques amovibles…) peuvent être perdus, volés ou frauduleusement consultés.
Ils peuvent aussi faire l’objet d’un contrôle par les autorités douanières de certains pays.
C’est le cas notamment aux Etats-Unis où des dispositions réglementaires récentes autorisent les douanes américaines à procéder à la fouille de documents informatiques (Instruction du 16 juillet 2008 « Policy Regarding Border Search of Information »).
Sous certaines conditions, les douaniers peuvent même exiger la consultation en clair de dossiers chiffrés et, si nécessaire, avoir recours à des moyens de déchiffrement.

Le risque concerne bien sûr la vie privée mais aussi des fichiers illégaux, ou dont la légalité serait difficile à justifier auprès d'un douanier...

La vraie vie

2009-03-22T03:10:00.008+01:00

Le regard varie selon l'humeur. Je me suis plutôt bien accomodé de ma situation de visiteur de passage à Pittsburgh. Par exemple, après la morne absence de café à la maison, je me suis mis au soluble: wouahou, carrément mieux que rien quand on a pas envie de sortir pour petit-déjeuner. Mais bon, là je m'en lasse, et ça me fait penser à une chanson d'un groupe d'ici.

(Ici, il y avait une vidéo, mais le lien ne pointe plus sur la bonne alors fuck off.)

Sinon, vous pouvez lire:

Crap art: The creation of art is more important than its consumption.
Watchmen, le livre pas le film, et surtout l'auteur Alan Moore.

Si vous trouvez ce post vide, disons que c'est du micro-blogging, c'est à la mode... (même liquidsoap est dans le coup).

La plus grosse

2009-02-27T22:54:00.005+01:00

Franchement, c'est lourd...

Pour y voir quelquechose, voici la version postscript (ou un GROS PNG).

Queues

2008-12-17T01:43:00.005+01:00

La suite du billet précédent...

Initialement, je me suis mis à Mercurial dans l'idée de mieux gérer mes projets, à commencer par Savonet. J'ai commencé par tester Mercurial sur un projet en solo, où j'utilise des ropes annotées (oui, c'est une réponse lapidaire à un billet précédent) pour écrire proprement un éditeur de texte qui supporte bien l'analyse lexicale et syntaxique du texte (oui, c'est bed). Cela m'avait plu, et inspiré les remarques du précédent billet.

Maintenant, quel interêt a Mercurial pour un projet comme Savonet? Nous avons actuellement un écosystème assez bien foutu autour de notre SVN, dont nous sommes globalement contents. Pas de vrai besoin de décentralisation, ni de super gestion des branches. Les apports de Mercurial seraient en fait: le commit local, les queues de patchs. Je ne parlerai que des queues de patchs car elles permettent grosso modo d'émuler le commit local de toutes façons.

Dans Mercurial, un patch est une modification (révision, changeset...) modifiable. Imaginez faire quelques commits, puis vouloir en fusionner deux ou en modifier un. C'est quelque chose de risqué: si quelqun a déja vos modifications et que vous les modifiez, c'est très dur de se resynchroniser. Mais si les modifications sont restées locales, tout va bien. Et ça peut être très pratique pour éviter de se retrouver avec un historique SVN plein de modifications type "Typo", "Oops, I didn't mean to commit that file" ou encore "Remove debug code" et autres "Fixed the fix".

Les patchs sont gérées dans une queue, d'où l'appellation mercurial queue (MQ). C'est à dire qu'on va avoir une queue de modifications en attente, qu'on peut appliquer à son dépôt, ou annuler de façon très pratique. Par exemple, on va avoir un patch avec du code de debug, un patch avec un correctif, et on peut rapidement enlever l'un ou l'autre pour tester si le correctif a bien l'effet voulu, avec plus ou moins d'informations affichées. Une fois qu'on a un patch bien propre, on peut le transformer en révision normale et la partager avec le monde. Si on a envie de passer à autre chose, on met le patch en attente. Avant, pour faire ça, j'avais plusieurs copies du dépôt Savonet: une pour bosser le système de type, une pour bosser sur le smart cross, etc.

Travailler avec MQ est très intuitif et très pratique. Je me suis donc demandé comment l'utiliser pour Savonet, pour espérer avoir un jour des logs un peu plus lisibles.

J'ai testé hgsubversion pour convertir le dépôt SVN de savonet en Mercurial. Bien qu'expérimentale, cette extension marche bien, et surtout bien plus rapidement que l'import SVN actuellement officiellement inclus dans Mercurial. On obtient un dépôt Mercurial avec tout l'historique SVN, et on peut échanger de nouvelles révisions avec le dépôt SVN. J'ai ainsi pu élaborer un patch, puis le commiter sur le SVN. Par contre, il semble inutile de vouloir partager le dépôt Mercurial et mélanger le versioning Mercurial et SVN, ça pète assez vite. En plus, on perd quelques trucs propres au SVN dans Savonet: l'inclusion de la révision SVN dans la version, et les liens external.

Une autre possibilité est de rester à SVN mais d'utiliser MQ par dessus. Cela implique encore de mélanger le versioning SVN et Mercurial: si on fait une mise a jour SVN, il faut la propager à la main dans le dépôt Mercurial, avant de ré-appliquer éventuellement les patches en queue. Je n'ai pas encore essayé, mais je ne suis pas très optimiste.

Enfin, on peut utiliser les outils de gestion de patches qui ont inspiré MQ, notamment quilt. Je me disais qu'il n'y avait pas tant que ça à perdre, mais ils ne mentent pas dans Mercurial: l'intégration des queues dans Mercurial même fait toute la différence. Il est beaucoup plus pénible de bosser avec quilt: par exemple, il n'a aucun moyen de savoir qu'un fichier est modifié par rapport à sa version SVN, et donc de passer cette modification locale dans un patch. On peut bricoler deux trois trucs, et arriver à ses fins, mais ça reste peu confortable. Au fond, quilt ne m'inspire pas trop, c'est assez rugueux à l'usage, pis... c'est codé en shell.

Bref, il y a encore du boulot pour pousser les développeurs Savonet à tous utiliser un gestionnaire de patches avant de passer une modif sur le SVN. La seule chose claire dans tout ça, c'est qu'on peut déja utiliser ma queue de patches, quel que soit l'outil et la méthode, c'est relativement standard: elle est publiée (sous forme de dépôt Mercurial) sur dolebrai.net. C'était d'abord une queue Mercurial mais je l'utilise désormais via quilt sur des dépôts SVN. Dans les deux cas je partage ainsi des patchs entre mon portable et le serveur: ainsi, je ne salis pas le SVN pour tester sur le serveur une modif en cours d'élaboration.

Gestion de code pour les nuls

2008-12-07T20:02:00.010+01:00

Les programmeurs qui travaillent en groupe ont l'habitude d'utiliser des outils pour contrôler l'évolution de leur code source. Ces outils peuvent en fait être utiles à quiconque travaille sur du texte. Par exemple, j'utilise SVN aussi bien pour développer savonet que pour rédiger des articles à plusieurs, ou ma thèse tout seul. Leur utilité est par contre grandement réduite pour des fichiers comme des images ou du son, mais aussi un document de traitement de texte: c'est un avantage quand on travaille avec LaTeX ou HTML, le document est du texte brut, contrairement aux divers Machin Office.

Un objectif clair quand on travaille à plusieurs est d'éviter les conflits. Monsieur Machin et Madame Bidule font des modifications en même temps, il faut que tout le monde puisse en profiter, si possible fusionner les modifications (si elles portent sur des morceaux de texte différents) et sinon signaler le conflit et permettre de le résoudre manuellement.

Même quand on travaille seul, ces outils sont très utiles car il permettent de suivre l'évolution d'un fichier ("Quand et pourquoi ai-je changé cette ligne?") de récupérer une version précédente, de visualiser les modifications entre plusieurs versions, et bien d'autres choses.

En ce moment, la gestion de version distribuée (DCVS) a le vent en poupe. C'est conceptuellement perturbant pour ceux qui connaissent la traditionelle gestion centralisée. Mais la décentralisation simplifie beaucoup de choses. Notamment, pour commencer à travailler avec un outil centralisé il faut (1) créer un dépôt central puis (2) obtenir une copie de travail de ce dépot. C'est souvent un peu fastidieux. Avec un outil distribué (décentralisé) les dépôts sont partout, attachés à chaque copie de travail. Créer un nouveau dépôt est une opération très naturelle et simple.

J'ai récemment commencé à utiliser Mercurial, ce qui m'a d'abord mené à l'observation ci-dessus. J'ai ensuite découvert d'autres avantages. Mais j'aimerais ici présenter à quel point il est aisé d'utiliser Mercurial pour un usage personnel. Comme pré-requis, il faut cependant savoir un petit peu utiliser le shell. Les personnes visées sont surtout celles qui n'ont jamais utilisé d'outil de gestion de code. Par la suite je présenterai peut être une utilisation plus avancée.

Créer un dépôt

Vous avez un répertoire dans lequel vous développez un projet: un livre, quelques pages, des programmes, n'importe. Pour commencer à utiliser Mercurial, qu'on appelle hg pour faire court (c'est le code de l'élément Mercure en chimie), placez vous dans ce répertoire et commandez simplement: hg init.

Cette commande initialise, dans le sous-répertoire caché .hg, une quantité d'informations dont Mercurial a l'usage. Ce sous-répertoire incarne le dépot, qui va tracer toute l'histoire de (certains de) vos fichiers, et les fichiers avec lesquels vous travaillerez comme avant constituent votre copie de travail.

Le travail comme d'habitude

Ajouter des fichiers au dépôt

Mercurial ne s'occupe pas de suivre un fichier si on ne lui demande pas. Sinon, il suivrait tout un tas de fichiers temporaires, ce qui serait gênant -- dans un contexte ou on partage un dépôt, on veut aussi éviter de tracer des fichiers secrets. Pour commencer à suivre un fichier, on utilise la commande: hg add FICHIER_1 FICHIER_2 ....

Cette commande ne répond rien de spécial, elle prend note, c'est tout. Après cela, vous pouvez continuer de modifier vos fichiers comme avant.

Enregistrer une modification

Quand vous pensez avoir atteint un point critique dans votre travail, fini une partie important, ou sur le point de commencer quelque chose de délicat, ou tout simplement si vous avez envie de sauvegarder votre travail, il faut enregistrer vos modifications: hg commit.

Cette commande va vous demander de saisir un message décrivant la modification. Cela peut paraitre ennuyant mais c'est bien pratique quand on revient plus tard, pour comprendre une modification.

Il est possible de n'enregistrer les modifications que sur certains fichiers: hg commit FICHIER_1 FICHIER_2.

Supprimer un fichier

Quand on veut supprimer un fichier, il faut aussi le dire à Mercurial: hg remove FICHIER. Au prochain commit le fichier sera effacé et Mercurial arrêtera d'essayer de le suivre.

Les nouvelles possibilités

Visualiser les modifications en cours

Un premier avantage est la possibilité de visualiser rapidement les modifications apportées depuis la dernière sauvegarde (le dernier commit). Pour cela: hg diff, ou hg diff FICHIERS si on ne s'intéresse qu'à certains fichiers. Cette commande est bien pratique pour voir où on en est, vérifier que tout est propre avant d'enregistrer et de documenter une modification.

On peut aussi avoir un aperçu du statut de nos fichiers: hg stat (parfois verbeux) ou hg stat -m pour avoir la liste des fichiers modifiés.

Visualiser, visuellement

La commande diff permet aussi de voir les différences entre des versions enregistrées dans le dépot, cf. hg help diff. Il y a deux façons plus conviviales de faire cela, et plus encore. D'abord, hg view qui permet de naviguer dans la liste des révisions et permet de voir les modifications associées à chacune. Plus agréable, hg serve lance un serveur en local sur le port 8000: dans votre navigateur, à l'adresse http://localhost:8000, vous pourrez naviguer dans les révisions et les fichiers, visualiser des différences et des versions passées.

Annuler une modification

Souvent, on se rend compte d'une erreur, avec ou sans l'aide de Mercurial pour comparer aux versions précédentes. Parfois, il est facile de la corriger. Mais ce n'est pas toujours le cas, et on souhaite alors pouvoir tout simplement annuler un ensemble de modifications enregistrées. Pour cela il y a la commande revert.

Tout seul, hg revert --all annule les modifications non sauvergardées, et annule aussi les ajouts/suppressions de fichiers. On peut lui spécifier un ou plusieurs fichiers en particulier, au lieu de --all.
On peut aussi faire hg revert -r -2 [FICHIER ou --all] pour revenir à la version précédente enregistrée, -3 encore un cran avant, etc. La version -1 est la dernière version enregistrée, c'est donc équivalent à ne pas passer d'option -r. Attention, dans tous les cas on perd aussi les modifications non enregistrées.
Finalement on peut utiliser -r REV où REV est l'entier positif désignant une version, telle qu'on peut le lire via hg view/serve/log. Par exemple la dénomination complète d'une version sera 2:26e8052bce45 mais 2 suffit pour la désigner. Même remarque qu'avant: attention, cela supprime les modifications en cours.

Fini

Il y aurait encore beaucoup à dire mais pour une utilisation simple c'est déja largement suffisant. En cas de doute au cours de votre apprentissage, n'hésitez pas à faire une copie sauvegarde de votre répertoire, le dépôt caché dedans sera sauvé aussi.

Exercice

2008-10-13T15:15:00.007+02:00

Il me reste treize jours pour finir de rédiger ma thèse. Pendant ce temps là, pour que je ne sois pas le seul à bosser, voici un petit exercice de prog qui m'est passé par la tête. On peut représenter du texte par le type string en Caml. On veut ensuite représenter du texte annoté, quand les annotations forment un arbre: soit deux annotations sont disjointes, soit l'une est incluse dans l'autre. Pensez par exemple à la grammaire au collège, "sujet" , "verbe", "complément" sont regroupés pour former une "phrase":

Il est aisé de travailler avec ce type. Et il représente exactement ce qu'on veut, il y a bijection. Maintenant, je veux une solution aussi satisfaisante quand les annotations ne forment plus un arbre mais peuvent se recouvrir partiellement. Pensez par exemple à du HTML mal formé: <red>b<b>a</red>b</b>i. Sauf que moi j'ai une utilisation moins crade en tête, mais c'est une autre histoire. Vos idées sont bienvenues, sinon je posterai peut être une solution plus tard...

Je me demande

2008-09-01T07:29:00.003+02:00

Cette nuit je fais un rêve, dont les détails m'échappent forcément déja. De temps en temps, j'essaie de faire quelquechose, et ça foire en faisant un petit boum. La deux ou troisième fois, je me réveille un peu pour réaliser que ce bruit n'est autre que celui de la porte qui claque.

Comment ça marche? Des scientifiques savent peut-être. Je vois deux solutions. Soit le rêve est juste une histoire qui se déroule "toute seule". Alors, la perception de la porte peut créer la tentative d'action -- la causalité se renverse juste. Soit il y a un dialogue, où une partie de mon cerveau projette un rêve que je (une autre partie de mon cerveau) peux influer par mes choix. Dans ce cas, qu'est-ce qui se passe si je n'agis pas dans le rêve, si le bruit ne peut se coller sur aucun élement du rêve? Peut-être la perception est-elle mise en attente un moment, et recrachée (un peu déformée/adaptée) dans le rêve un peu plus tard si une opportunité se présente.

...

Time flies

2008-07-03T14:53:00.008+02:00

Non, je n'écris pas une nouvelle de science fiction sur des mouches qui voyageraient dans le temps. Le temps passe vite, c'est tout. Il est bien rempli. Niveau boulot, un fichier phd.tex et une conférence aux États-Unix suivie d'une visite intense de NYC. Niveau Savonet on a publié la 0.3.7 et annoncé des bières gratuites mecredi en huit au Corcoran.

De son côté Frank a publié la seconde compilation Dolebraï, un peu plus électro que la précédente mais démontrant néanmoins encore une fois la richesse de la scène libre -- à moins que son but soit plutôt d'aider les paresseux mais néanmoins convaincus à trouver les joyaux dans la botte de paille. Il y a quelques morceaux sélectionnés par moi, mais l'envie m'a pris de jouer avec les widgets Jamendo et de vous proposer ici plus de morceaux de ma sélection.

Bien sûr il y a aussi beaucoup de bons artistes absents de Jamendo. Vous pouvez toujours aller voir leurs pages Dolebraï: Peyote Sunrise, Redemption (Baroque Dub Remix), Seeding Time In The Oak Room, I Saw My Lady Weep, Tattoo (Remix), Cutting Tags Off New Pants, Sideburn, etc.

En fait, écoutez toute la compil #2 et faites moi une critique de 1000 mots pour lundi!

Blagues

2008-03-06T09:35:00.007+01:00

En attendant de finir un post passionant sur le polymorphisme dans OCaml, justifions le nom de ce blog...

Ces temps-ci je m'amuse beaucoup des sujets des spams que je reçois. Mon préféré est arrivé ce matin: [SPAM] Are there any side effects? Choix judicieux pour les adresses récoltées sur les mailing-listes de programmation fonctionnelle.

Olivier, l'autre jour dans le RER, m'a fait part d'une autre interprétation obsessive perchée, devant l'affiche formidable de 2^ème sous-sol:

Pour ceux qui ne connaissent pas, ou qui sont moins obsédés: Olivier pensait à Girard qui classifie les 1^er, 2^ème et 3^ème sous-sols de la logique.

OCaml write-only

2008-02-03T22:23:00.000+01:00

J'ai découvert un petit site sympa suite à une annonce sur la Caml-list: Anarchy Golf. Au golf, on fini un parcours en un nombre minimum de coups. Ici, on résout un problème en un nombre minimum d'octets de code. De nombreux langages sont disponibles, dont OCaml.

Le problème annoncé sur la Caml-list laisse rêveur: trouver un Quine qui soit aussi un palindrome. En clair: un programme dont l'exécution affiche le code du programme, et dont le code est un palindrome, i.e. identique qu'on le lise de droite à gauche ou le contraire. Il est assez simple d'écrire un Quine, quel que soit le langage. J'ai écrit un palindrome en Caml, c'est déja un peu plus ardu. Mais satisfaire aux deux contraintes en même temps est décourageant. Alors j'ai perdu mon temps sur d'autres problèmes plus simples, en attendant de voir les solutions à celui-ci (le 08 Février, 01:46:39 heure japonaise).

La contrainte de concision force à faire des choses illisibles. Par exemple, ma solution pour le problème rot13:

let rec(!)?(c=input_byte stdin)x=output_byte stdout[|c;c;65+c mod x;97+(c-6)mod x|].(c/32);!x;;!26

À ce stade vient l'expression consacrée à Perl: ce code est write-only. Et encore c'est assez lisible comparé aux solutions du champion de Golf en OCaml: ksk.

La concision force à faire des choses qu'on ne pourrait qualifier de bonnes pratiques de programmation. Cela dit, il faut en général réfléchir à un algorithme pas trop con pour pouvoir prétendre au podium. Par exemple, même en déployant toutes les ruses de compression possibles, je sentais bien que je n'atteindrais pas les 54 octets de ksk pour écrire un interpéteur Scheme minimal. Après la fin du défi, quand son code a été publié, j'ai pu constater qu'il avait rusé:

print_string[|"3";"24";"5
8
58"|].(-Obj.magic(@)mod 3)

De là à comprendre la ruse, ce n'est pas si simple. Tout repose sur le fait que le code ne doit pas vraiment implémenter un interpréteur Scheme: il suffit qu'il donne les bonnes réponses pour trois entrées différentes, toujours les mêmes. La plupart des participants ont utilisé cette "faille" pour répondre, par exemple m.ukai, classé second en OCaml:

print_string[|"24";"3";"5
8
58"|].(String.length(read_line())-16)

Ici, la réponse est choisie en fonction de la longueur de la première ligne de l'entrée, cette information étant suffisante pour distinguer les tests. La solution de ksk reste incompréhensible: il n'y a aucune instruction de lecture, aucun test dépendant de l'entrée. Pire: si vous prenez son code et le compilez (en natif ou bytecode) vous obtiendrez un programme déterministe (il affiche toujours 3 chez moi).

La clé du mystère ? Exécuté dans la boucle d'interaction ocaml comme le fait la procédure de vérification du Code Golf, ce code a une sortie aléatoire. Selon les exécutions de ocaml ksk.ml, on reçoit la réponse de l'un des trois tests. Le hasard réside dans l'initialisation de la boucle d'interaction, qui fait que l'opérateur de concaténation (@), transtypé en un int par Obj.magic va avoir une valeur grosso-modo aléatoire. Je ne fais que constater, je ne comprends pas.

Mais cela ne répond toujours pas au problème... enfin, pas toujours. Il aura probablement fallu à ksk pas mal de patience pour soumettre et re-soumettre son code jusqu'à ce que le hasard renvoie les bonnes réponses aux bons tests, et le classe premier! Cette solution est vraiment write-only: c'est illisible, et même son exécution laisse à désirer :)

Moi je trouve ça un peu trop immoral, mais il faut avouer que ça respecte les règles du jeu. Et on aura appris quelquechose. C'est moche, mais ça marche.

De la webradio lambda à la λ-webradio

2007-12-10T11:50:00.000+01:00

Un article sur quelques aspects théoriques de la conception de liquidsoap, par Samuel et moi-même, a été accepté aux Journées Francophones des Langages Applicatifs (JFLA08). Sous un titre suivant la tradition blagueuse des JFLA (e.g., Le foncteur sonne toujours deux fois) nous présentons le modèle de flux sur lequel sont construits les opérateurs de liquidsoap, puis formalisons le langage de script propre à notre outil. Ça nous change des articles purement techniques, et ça vous changera de la doc des outils de tous les jours: jetez-y donc un oeil!

Vélo

2007-11-22T23:00:00.000+01:00

Il y a trois ans, mon père m'a légué son vieux vélo de randonnée. J'ai eu envie de le faire retourner en Irlande, puis c'est en Bretagne et aux Pays-Bas que nous sommes partis en cyclotouristes avec Estelle. Malgré notre style très calme (grasses matinées, pauses café et autres douceurs) nous avons pu voir beaucoup de pays. C'est vraiment un chouette genre de vacances, un bon compromis entre la marche et la voiture.

(Sur la photo, moi et le vélo en question, aux Pays-Bas. Au passage, j'ai publié quelques unes des photos de ce voyage sur Flickr.)

En Septembre, un petit soucis technique sur ce vieux vélo m'a décidé à en acheter un nouveau. J'ai passé un bon moment à chercher un vélo qui pourrait le remplacer: léger, rapide, élégant, fonctionnel avec ses portes bagages. Je ne vais pas faire des tartines de ces considérations, de tout ce que j'ai lu et de mon choix final. Toujours est-il que j'ai un nouveau vélo pas mal du tout, que je commence à équiper pour la randonnée, et que ça m'a donné envie de tester le trajet de chez moi à l'École Polytechnique. La distance n'est pas négligeable, avec 20km depuis Montparnasse, mais le parcours presque tout en piste cyclable est très agréable. Plusieurs personnes font cette ballade pour aller au labo, et ils n'ont pas tous l'air de gros stakhanovistes: pourquoi pas moi/vous ?

J'ai mis un petit moment à peaufiner mon trajet. La première fois fut avant les grèves, les deux suivantes pendant: ça tombe bien. Toujours est-il que maintenant que je connais bien la route, j'ai tracé le plan sur Google Maps. Les intéressés cliqueront sur l'image:

Pour finir, quelques liens que j'ai trouvé utiles dans mes recherches.

D'abord les fabricants. Peu font encore de l'acier, pour des raisons économiques déplorables car ce matériau est plus souple donc plus solide, et permet l'utilisation de tubes extrêmement fins donc des vélos beaucoup plus élégants et tout aussi légers qu'en aluminium. Rivendell fait des vélos en acier tout simplement sublimes, mais tellement chers! Surly est plus accessible et son Long Haul Trucker a la côte pour la randonnée, mais reste un gros investissement à mon échelle. Si l'on se résigne à l'aluminium, on découvre quand même de beaux vélos, et on s'aperçoit que Decathlon n'a pas forcément un rapport qualité/prix imbattable (par contre niveau visibilité ils écrasent tout le monde à Paris): par exemple les vélos Trek sont plutôt bien faits et pas aussi chers que le design du site ne le laisse croire. J'ai opté pour le 7.3FX, il n'est pas plus cher que le milieu/haut de gamme Decathlon et correspond mieux à ce que je voulais. Pis quand on le voit, on se dit qu'il vaut son prix :)

Sinon pour la technique du vélo, des anecdotes et des conseil sur le matériel, de l'antique au plus moderne, Sheldon Brown (en anglais) est super bon.

Enfin, n'oublions pas qu'on roule pour voyager. Niveau matériel, deux marques sont omniprésentes: Tubus pour les porte-bagages et Ortlieb pour les sacoches. Le matos est bien foutu (en en voyant aux Pays-Bas j'avais déja commencé à penser à me re-équiper) mais putain qu'est-ce que c'est cher. On pourra admirer des vélos voyageurs bien chargés dans la galerie Fully Loaded Bicycle, du pliant au tandem. Enfin vraiment sur le voyage, le site Crazy Guy on a Bike recense des récits de voyages à vélo (du court au très long) ainsi que de nombreux conseils. Comme très long voyage balisé, la route EuroVelo6 s'illustre avec 4000km de St Nazaire à la Mer Noire par la Loire, le Rhin et le Danube.

Enigmes

2007-11-21T15:33:00.001+01:00

Quand on pose une énigme mathématique, à moitié formalisée, on finit toujours par avoir une réponse type: "on enlève le bandeau qu'on a sur les yeux", "on casse la gueule au bourreau", etc. D'où l'idée de formaliser vraiment, sous forme d'un exercice de programmation... (qui a dit "maniaque" ?)

Un groupe de n prisonniers se trouve en mauvaise posture. Ils vont être mis en file indienne, chaque prisonnier voyant seulement les prisonniers devant lui. Puis on leur mettra sur la tête un chapeau bleu, blanc ou rouge, qu'ils ne peuvent voir. Un bourreau procède alors comme suit: en partant du dernier prisonnier il demande "Quelle est la couleur de ton chapeau ?", et le prisonnier n'a le droit qu'à une réponse, qui doit être une couleur. A la fin, les prisonniers qui ont deviné la couleur de leur chapeau sont épargnés, les autres exécutés. Les prisonniers peuvent se concerter avant l'épreuve sur la stratégie à adopter. Quelle est la meilleure stratégie ?

Voici maintenant l'énoncé complètement formalisé. Un prisonnier est représenté par une fonction qui prend deux listes de couleurs (celles qu'il voit devant lui, celles qui ont été prononcées comme réponses derrière lui), et renvoie une couleur (sa réponse). Dans la liste des réponses précédentes, la réponse du dernier de la file est la dernière de la liste. Trouver une fonction prisonniers qui à un entier n associe une liste de n fonctions/prisonniers telle que le nombre de morts calculé par (execution (prisonniers n)) soit le plus petit possible dans le pire cas. La fonction d'exécution est la suivante:

type couleur = Bleu | Blanc | Rouge
type prisonnier = couleur list -> couleur list -> couleur

let random_couleur () =
  let n = Random.int 3 in
    if n = 0 then Bleu else if n = 1 then Blanc else Rouge

let execution (prisonniers : prisonnier list) =
  let prisonniers =
    List.map (fun p -> p, random_couleur ()) prisonniers
  in
  let rec morts avant = function
    | (p,c)::l ->
        let reponse = p (List.map snd l) avant in
          (if reponse = c then 0 else 1) +
          (morts (reponse::avant) l)
    | [] -> 0
  in
    morts [] prisonniers

Amusez-vous bien, et postez vos réponses dans le langage de votre choix...

Edit: une autre énigme beaucoup plus étonnante, que Florent et Julien m'ont racontée. Vous avez devant vous sur une table 7 pièces côté pile et 19 pièces côté face. Mais vos yeux sont bandés (et vous portez des moufles) de sorte que vous ne pouvez savoir l'état d'une pièce. Tout ce que vous pouvez faire c'est en retourner certaines, autant que vous voulez, et les déplacer. Il vous faut les séparer en deux groupes qui contiennent le même nombre de pièces côté pile.

La solution sera une fonction qui prend le nombre de piles et le nombre de faces (je vous aide bien en généralisant) et qui renvoie deux tableaux de taille piles+faces: le premier indique les indices des pièces choisies, le second indique les pièces qu'il faut retourner. La fonction sera passée à la fonction de test suivantes:

(** Perfect Fisher-Yates shuffle
  * (http://www.nist.gov/dads/HTML/fisherYatesShuffle.html). *)
let randomize a =
  let permute i j =
    let tmp = a.(i) in
      a.(i) <- a.(j);
      a.(j) <- tmp
  in
  let l = Array.length a in
    if l>=2 then
      for i=0 to l-2 do
        permute i (i + Random.int (l-i))
      done

let test nb_piles nb_faces joueur =
  let choix,retourne = joueur nb_piles nb_faces in
  let n = nb_piles + nb_faces in
  let a = Array.init n (fun i -> i<nb_piles) in
  (* Nombre de piles à gauche - nombre de piles à droite *)
  let d = ref 0 in
    randomize a ;
    for i = 0 to n-1 do
      if retourne.(i) then a.(i) <- not a.(i) ;
      d := (if choix.(i) then (+) else (-)) !d (if a.(i) then 1 else 0)
    done ;
    !d = 0

A suivre: les solutions commentées...

Linux Mag

2007-09-08T02:47:00.000+02:00

Bravo à Romain qui est sur la couverture de Linux Magazine ce mois-ci, avec un article sur l'équipe Savonet qui développe un machin appelé Liquidsoap... la suite dans le numéro de Novembre!

Lectures estivales

2007-08-24T02:22:00.000+02:00

Je suis de retour à Paris, après deux semaines à découvrir les Pays-Bas (un pays de hoef) en roulant (à vélo), puis quelques jours de camping dans les Alpes, séjour écourté par la pluie... Je pointerai plus tard des galeries de photos, pour l'instant j'avais envie de coucher quelques notes sur les bouquins sur lesquels je suis tombé, et qui m'ont permis de structurer un peu certaines fascinations.

Matière à pensée

Cela commence avec un ancien prof de philo à la retraite, qui me conseille ce dialogue entre Alain Connes (mathématicien) et Jean-Pierre Changeux (neurobiologiste) pour nourrir "légèrement" ma curiosité en épistémologie.

La première partie du bouquin m'a plu, et en particulier la forme du dialogue, où les idées ne sont pas posées en absolus mais réellement discutées. La question initiale est celle du statut des mathématiques.

Pour Connes les mathématiques constituent une réalité, autre que notre réalité physique, que les mathématiciens explorent, et qui a un caractère universel. Changeux voit plutôt les mathématiques comme un pur produit de l'esprit humain, qui n'aurait pas forcément de sens pour un être inhumain. Bizarrement, Connes admet ouvertement que sa vision plutôt absolue n'est qu'une croyance, alors que Changeux, malgré ses idées très relatives/subjectives, semble penser qu'on peut aller au delà de la croyance en ce domaine.

Deux concepts importants restent indéfinis. D'abord les mathématiques: y a-t-il une seule mathématique ? En tant qu'apprenti logicien je ne peux m'empêcher de penser aux multiples logiques et théories existantes. Comment concevoir une unique "réalité" malgré la possibilité de travailler avec l'hypothèse du continu ou son contraire ? Les énoncés indépendants sont abordés mais la question n'est pas traitée. Plus amusant, la définition de réalité reste en suspens. Pour Connes il y a une "réalité" mathématique car il y a une cohérence de la perception (des objets mathématiques), pour un même individu et d'un individu à l'autre. Pour lui c'est là la définition même de réalité. Changeux objecte alors qu'avec cette définition les hallucinations collectives font partie de la réalité, mais ne propose pas mieux. Et je retombe dans mes considérations Dickiennes...

La seconde partie du bouquin parle du théorème de Gödel, d'intelligence artificielle, de la dissection puis de la mécanisation de l'activité du mathématicien... Cela devient un peu mou et on n'y lit rien de bien excitant ni même nouveau.

Interlude: Le Monde Diplomatique

Cela faisait bien longtemps que je n'avais pas acheté le Monde Diplo, qui me semblait rabâcher les mêmes considérations déprimantes. Le numéro d'Août m'a fait changer d'avis: quasiment tous les articles m'ont semblé intéressants, qu'on y apprenne ou qu'on y trouve une structuration. En particulier Estelle et moi avons été séduits par Chomsky. Quelques uns de ses bouquins nous ont ainsi accompagnés dans les Alpes, mais je dois avouer que je ne m'y suis pas mis.

Juste un petit mot pour Gelnior qui a aussi lu cet été sur les vices "cachés" de notre société "parfaite": toi aussi lis Chomsky tu verras que cela ne s'arrête pas au mode de vie d'un individu et à son choix d'être lisse ou d'insulter les gens.

Le point aveugle

Sous la pluie dans les Alpes, je lisais le premier tome du récent cours de logique de Girard -- j'en avais besoin pour un point technique. Le bouquin couvre bien le sujet des bases aux notions avancées, mais je ne suis pas sûr qu'il faille le conseiller aux débutants pour autant. Par contre c'est un plaisir à lire quand on a déja une vague idée de la totalité du sujet, on apprécie les remarques reliant un concept à un autre, donnant plus de profondeur qu'une présentation académique linéaire. Et il faut admettre qu'on se régale des jugements acérés sur telle idée ou tel mathématicien/logicien -- même si cela semble parfois superflu pour ces derniers. Par contre ça doit être agaçant quand on n'adhère pas aux mêmes idées que Girard...

Si j'en parle ici, c'est qu'en fait le livre m'a fait retomber (presque) par hasard dans les considérations précédentes. Témoin le quatrième de couverture: "Epistémologiquement, le texte rompt avec la sempiternelle polarisation entre réalisme et anti-réalisme, en lui substituant l'opposition entre existence et essence. [...] La logique est-elle antérieure aux phénomènes qu'elle contrôle ?"

En deux mots. Girard évacue la question de la réalité en arguant de ce que tout bon scientifique croit d'une certaine façon en ce qu'il fait. Il se pose une question plus productive: comment fonder la logique en évitant la fuite en avant essentialiste qui va justifier un système par un meta-système, lui même fondé sur un meta-meta-... etc ? Dans le cas de la logique, comment définir la vérité sans faire référence à une notion pré-établie ? Girard reconnait en fait l'impossibilité de cet objectif, affirmant que "la vérité n'a pas de sens". Mais cet aveu est productif, puisqu'il va alors s'intéresser à la cohérence interne des logiques, l'élimination des coupures par exemple.

En fait, je ne suis pas sûr que Girard croie que la vérité n'a pas de sens. C'est plutôt un programme qu'il propose, et qui mène à de très beaux travaux. De même, je ne crois pas à l'idée de réalité consensuelle, mais je trouve que c'est une éventualité des plus amusantes à envisager.

Je n'ai pas encore acheté le second tome du cours, et je ne sais pas quand je trouverai la force de le lire. Mais je sais déja que, du point de vue de la métaphysique de comptoir, ça va continuer à me plaire. Girard y parle de ludique, une nouvelle vision de la logique où tout commence par une notion de jeux sans arbitre, qui se déroulent par consensus entre les deux joueurs. Plus d'absolu pré-établi, tout est subjectif... comme la réalité ?

Et puisqu'on parle de jeux (théoriques), je finirai de nouveau en évoquant mes projets fous de (vrais) jeux qui implémentent fortement cette idée de réalité consensuelle.

Modestement, on peut d'abord partir de l'idée qu'il ne doit pas y avoir d'arbitre, par exemple dans le cadre d'un jeu de stratégie en temps réel. Typiquement, un joueur n'a qu'une information partielle sur l'état des unités de l'autre joueur, e.g. à cause du brouillard de guerre. Au fur et à mesure qu'il acquiert de l'information, le joueur peut vérifier que son opposant n'a pas triché (s'il existe une stratégie qui mène à un état cohérent avec l'information découverte). En l'absence d'arbitre omnipotent, on ne peut pas faire mieux. Du coup, il y a au moins deux façons de jouer. Soit on joue comme d'habitude, en suivant une seule stratégie. Soit on joue au second degré, en ne décidant de sa stratégie qu'au fur et à mesure que l'opposant nous observe -- ce qui implique des choix dans le passé, du point de vue de l'opposant. Clairement, cela offre plus de possibilités puisqu'on attend, avant de faire un choix, d'avoir de l'information par l'observation mutuelle. Mais déja, on a du mal à imaginer l'interface qui rendrait cela praticable pour un joueur humain. Pire, on se demande s'il y a une troisième degré de jeu.

Mais franchement, ce projet là me parait terne par rapport à la richesse de l'idée. Moi ce que je veux, c'est un monde où la réalité serait malléable, où les joueurs habiles se feraient magiciens en imposant leur vision du réel, où peut-être les réalités se feraient multiples en cas de conflit.

Et puisqu'on est dans le doute, je finirai avec une citation de Dick qui va un peu contre cette idée de consensus.

« La réalité, c'est ce qui continue à s'imposer de vous quand vous cessez d'y croire. » -- P.K.Dick

Petite pierre

2007-08-05T11:04:00.000+02:00

Merci à Romain pour l'article Deb-a-Day sur liquidsoap!

Notification de bonnes vacances

2007-07-31T16:22:00.001+02:00

Aujourd'hui est mon dernier jour au labo pour cette deuxième année de thèse. Je vais limite avoir du mal à arrêter de bosser, avec toutes ces questions excitantes qui tournent encore dans ma tête, tous ces trucs à écrire. Pour m'aider à décrocher (hum..) j'ai décidé de passer la journée à coder dans liquidsoap, en me concentrant sur deux-trois trucs chiants et pas du tout glorieux, qui ont trait à l'auto-documentation des fonctions définies dans les scripts liq. Cela devient important à mesure que nous accumulons de petites snippets sympas.

Par exemple, j'utilise liquidsoap pour écouter ma musique, et pour écouter Dolebraï (sur laquelle je mixe les interventions de balbinus sur sa number station). Dans les deux cas j'utilise deux petites fonctions pratiques: je parlerai plus tard de la platine interactive qui permet d'appliquer quelques effets audio, quand elle sera finalisée; l'autre fonctionnalité est un petit hack pour afficher à l'écran les metadonnées du flux joué par liquidsoap.

Le principe est simple: attacher à l'évenement on_metadata une fonction qui exécute la bonne commande. Quelle que soit la méthode, il va tout d'abord nous falloir une fonction pour transformer la métadonnée en chaine de caractères.

# Standard function for displaying metadata.
# Uses "Unknown" when a field is empty.
# @param m Metadata packet to be displayed.
def display_metadata(m)
  artist = m["artist"]
  title  = m["title"]
  artist = if ""==artist then "Unknown" else artist end
  title  = if ""==title  then "Unknown" else title  end
  "#{artist} -- #{title}"
end

OSD (On Screen Display)

OSD est une technologie ancestrale de X. On peut l'utiliser simplement avec l'utilitaire osd_cat qui affiche à l'écran (au dessus de toutes les fenêtres) le texte passé sur son entrée standard. Le problème est que les polices ne sont pas lissées, et qu'il est difficile de trouver une couleur de texte lisible quel que soit le fond au moment de l'affichage. Néanmoins, c'est un début..

# Use X On Screen Display to display metadata info.
# @param ~color    Color of the text.
# @param ~position Position of the text (top|middle|bottom).
# @param ~font     Font used (xfontsel is your friend...)
# @param ~display  Function used to display a metadata packet.
def osd(~color="green",~position="top",
        ~font="-*-courier-*-r-*-*-*-240-*-*-*-*-*-*",
        ~display=display_metadata,
        s)
  osd = 'osd_cat -p #{position} --font #{quote(font)}'
      ^ ' --color #{color}'
  def feedback(m)
    system("echo #{quote(display(m))} | #{osd} &")
  end
  on_metadata(feedback,s)
end

Notify

Notify est une technologie plus moderne émanant de l'intiative freedesktop. Elle est donc disponible avec les gestionnaires de bureau principaux, notamment gnome, kde et xfce. Si ça se trouve on peut même l'utiliser indépendamment du gestionnaire de bureau, mais l'idée ici est que l'intégration permet un comportement plus riche et agréable, ainsi qu'une apparence unifiée. Bref. Encore une fois on a un petit outil simple en ligne de commande: notify-send. Et ce n'est pas plus compliqué à utiliser depuis liquidsoap:

# Use notify to display metadata info.
# @param ~urgency Urgency (low|normal|critical).
# @param ~icon    Icon filename or stock icon to display.
# @param ~time    Timeout in milliseconds.
# @param ~display Function used to display a metadata packet.
# @param ~title   Title of the notification message.
def notify(~urgency="low",~icon="stock_smiley-22",~time=3000,
           ~display=display_metadata,
           ~title="Liquidsoap: new track",s)
  send = 'notify-send -i #{icon} -u #{urgency}'
       ^ ' -t #{time} #{quote(title)} '
  on_metadata(fun (m) -> system(send^quote(display(m))),s)
end

Tout ceci se teste assez simplement. Par exemple, pour faire simple, mettez mes petites fonctions dans un script, ajoutez en dernière ligne un out(notify(playlist("~/ma/musique"))) et c'est parti. Sous Debian les paquets nécessaires sont (liquidsoap et) respectivement xosd-bin et libnotify-bin. Un petit instantané du résultat chez moi:

Et bonnes vacances!

Intello - nombriliste - hippie - réactionnaire

2007-07-24T15:02:00.000+02:00

Depuis déja une semaine je suis de retour d'Allemagne, où je présentais le système que j'ai développé en première année. J'ai surtout pas mal bossé à tous ces exposés que je ne suivais pas, et je suis rentré avec plein d'idées à pousser, c'est assez excitant. J'ai appris ce matin que l'article résultant en gros de mon travail de cette année a été accepté à LPAR. Ce travail me tenait assez à coeur, et le suspens était d'autant plus grand que l'article a d'abord été refusé ailleurs dans des conditions assez frustrantes... En tout cas, j'irai en Arménie en Octobre.

Voilà pour le côté recherche, bien rempli. Côté Savonet, Sam Balbinus et Romain ont l'air de se sentir plus franchement en vacances que moi, et passent pas mal de temps sur le projet, ce qui m'y pousse forcément. On commence à étendre les possibilités d'interaction: à terme on n'aura plus besoin de régler les opérateurs de traitement de son à l'aveugle; ça devrait aussi aider à débuguer des trucs complexes comme la détection de beat; plus marrant, on peut imaginer utiliser liquidsoap comme un backend d'un logiciel de DJ. J'ai forcément été de la partie, pour le bricolage dans les coins sombres de liquidsoap, et puis parce que ça m'amuse bien tout simplement. Mais je n'ai clairement pas été à la hauteur de la frénésie de Sam. Pour sa part, Romain a rédigé un article pour DebADay, auquel j'ai contribué un peu, mais pas aussi vite qu'il ne l'espérait. Dans le même temps il préparait un dossier pour les Trophées du Libre. Et il a pour la troisième fois demandé au projet Icecast de lister liquidsoap parmi les streamers compatibles, avec succès! Notre longue absence me fait bien sentir que la liste est loin d'être exhaustive. N'empêche, c'est une liste de choix, et liquidsoap y sort clairement du lot, ça fait plaisir.

Plus que ma très passagère et très relative baisse d'activité de développement, mon manque d'intérêt pour la communication m'a fait me poser des questions, et nous en avons d'ailleurs un peu discuté avec Romain. Ma première réaction a été de me justifier dans l'absolu. Ce qui m'intéresse, ce n'est pas de maintenir un monument, d'assurer le support utilisateur, la portabilité et la backward-compatibility... toutes ces choses, certes très importantes, ne m'excitent pas. Et ce projet est d'abord et avant tout un hobby, je ne veux pas me laisser entraîner dans une direction qui ne me plait pas. Mais qu'est-ce qui me plait? Ce n'est pas très raisonnable, mais je crois qu'il faut avouer que c'est d'abord "coder". J'aime coder, de l'élégance des petites fonctions à la satisfaction de la maitrise de l'ensemble complexe de modules que forme liquidsoap. Sinon, plus généralement, "développer" une idée qui permette d'atteindre un résultat original, de dépasser les limites actuelles.

En fait, tout est dans la portée du "développement". Ça me fait penser à Philip. K. Dick qui présente, en préface du recueil de ses nouvelles, sa vision de la différence entre nouvelle et roman. La nouvelle lui permet de mettre en scène une idée: on pose le décor, les personnages, dans l'unique but de présenter l'idée principale. Dans un roman, les personnages et l'environnement en général doivent être développés plus en profondeur, ils doivent prendre vie, avoir leur caractère. Selon Dick, l'auteur se retrouve du coup prisonnier de ses personnages, dont la vie propre force l'action. Les deux styles ont leurs avantages et inconvénients. Chacun son truc. Quant à Dick, il a écrit les deux. J'ai bien aimé ses romans, mais je dois dire que je suis soufflé quand je lis ses nouvelles: quasimment chaque histoire met en scène une idée étonnante, déroutante, fascinante! Je parle de Dick plus parce que j'adore le lire que parce que j'aime l'analogie, mais vous l'aurez compris, je me vois plutôt écrire des "nouvelles" que des "romans". L'autre tendance me semble glauque au possible: je pense aux armées de développeurs dans l'industrie, qui implémentent des suites bureautiques, de mornes projiciels ou autres automatisations de tâches administratives... En un sens ils peuvent être fiers de faire tourner le monde. Mais bon, comme dit Alan J. Perlis: In computing, turning the obvious into the useful is a living definition of the word "frustration". (Perlis a écrit un paquet d'Epigrams on Programming, c'est une lecture amusante, et on finit toujours par y lire midi à sa porte.)

Bien entendu, peu de choses étant simples dans la vraie vie, je me suis vite rendu compte que ces réflexions ne sont pas honnêtes. Du moins, elles ne représentent qu'une facette de la réalité. J'ai la tête très occupée par la recherche en ce moment, mais ces choses là fluctuent. Je suis clairement touché quand un utilisateur apprécie liquidsoap, quand Xavier Cazin blogue là dessus chez O'Reilly, etc. Il y a là bien sûr un brin d'orgueil. Plus louablement, je crois qu'un des buts de liquidsoap est de montrer comment des courants d'idées actuellement plutôt enfermés dans le milieu de la recherche peuvent être utiles à tout le monde, développeurs comme utilisateurs. Le fait que le projet marche, et qu'il soit apprécié, et qu'il ait même rallié un brin de contributeurs, constitue un début de succès de ce point de vue... ce n'est peut-être pas tout à fait de la pédagogie ni du militantisme, mais il y a un peu de ça.

Le problème des concours de logiciels libres cristallise bien ces questions. J'ai probablement été le premier à envisager de présenter liquidsoap à tel ou tel concours. J'ai toujours repoussé à une prochaine-version-encore-mieux. Sam a poussé et c'est finalement Romain qui a fait le pas. Le bon côté de la chose c'est qu'on risque d'entrer en contact avec de nouveaux gens intéressants, et probablement tomber sur de nouvelles idées. Le domaine est plutôt petit et on s'adresse à des gens plutôt capables techniquement, nous sommes probablement déja suffisamment référencés pour que les utilisateurs ciblés nous trouvent. Mais peut-être un peu de communication plus large nous fera-t-elle atteindre des applications et des gens auxquels nous ne pensons pas actuellement, et réciproquement. Ces pensées positives ne chassent pas l'idée du côté bizarre de tout ça. Pourquoi concourir à un prix, en euros et en matériel ? On se retrouve à lire dans le topic de #savonet: "TODO: Find what to do with money for the project"! Pour caricaturer, on part d'un projet pour le fun et les belles idées, et on arrive à se demander comment dépenser du blé, en vulgaires consommateurs. Ça m'évoque aussi les grosses compagnies qui n'ont que l'objectif d'être les "premières", oubliant complètement l'interêt du client et de la société. Pas de méprise, ces exagérations ne sont que les spectres caricaturaux d'un doute qui me taraude. Mais je crois qu'il est très important de faire gaffe à ne pas dévier par mégarde des objectifs qu'on se fixe. Pour ne pas se réveiller un jour et réaliser qu'on a perdu du temps et de l'énergie (ou pire) à des choses qui ne nous intéressent pas.

Application

2007-07-18T12:21:00.000+02:00

Je suis en conférence, ce qui me laisse plein de temps pour bosser pendant la plupart des exposés... Bremen est plutôt une jolie ville, le campus est super agréable et il fait beau. Blogger s'est mis à me parler en Allemand. Ici j'ai vu Al. Bundy, pour ceux qui connaissent...

Bon sinon, un petit exemple simple m'est venu pour montrer que l'application en Caml n'est pas aussi simple qu'on le pense en présence d'arguments optionels. L'équation f x y = (f x) y, n'est pas toujours vérifiée. En fait, on n'a pas seulement une notion d'application mais bien une multi-application. Si je parle de ça c'est pour mettre au clair l'origine de la multi-abstraction du langage de script de liquidsoap.

# let f ?(a=false) () = a ;;
val f : ?a:bool -> unit -> bool = 
# f () ~a:true ;;
- : bool = true
# (f ()) ~a:true ;;
This expression is not a function, it cannot be applied
# f () ;;
- : bool = false

Scoop

2007-07-15T11:49:00.000+02:00

Sam et Balbinus ont frénétiquement commencé un nouveau sous-projet au sein de Savonet: SoapLab! Il s'agit d'une application Gtk à deux facettes. D'abord un ingester, premier maillon du futur système IAS cher à Balbinus: il permet de rapidement examiner un fichier de sa playlist, et d'éditer ses caractéristiques, notamment les points de fade-in/fade-out/crossing. Tout cela bien sûr sur n'importe quelle machine, pas forcément sur le serveur de la radio. Soaplab est aussi un éditeur audio, qui importe/affiche/joue/modifie/exporte une onde sonore. Plutôt classique, mais de bonne facture et surtout, re-utilisant tout le matériel développé dans liquidsoap. Je m'en sers notamment pour inspecter la sortie d'une source liquidsoap.

soaplab --editor '
s = sine(duration=5.)
s = fade.in(duration=2.,type="sin",s)
s = fade.out(duration=2.,type="sin",s)
sequence(merge=true,[s,s,s,s,fallback([])])'

On voit ici quatres pistes de la source s, qui émet des pistes de 5 secondes, sinusoïdales à 440Hz, sur laquelle on a rajouté du fading in et out, de type "sinusoïdal". Les autres types dispos sont dans l'ordre: exponentiel, logarithmique et linéaire.

Un type bien

2007-06-27T02:39:00.000+02:00

La fête du ciné se termine. Je n'ai vu que deux films, Boulevard de la Mort et Dialogues avec mon Jardinier. J'ai beaucoup aimé les deux. Ils sont très différents, mais ont cependant un point commun: on sort des deux en réalisant comme les choses simples sont efficaces. Pour le premier je pense à la simplicité de la violence et à celle du ressort "vengeance" qui fait jubiler le public comme rarement. Pour le second il s'agit de la simplicité du retour aux sources, à la nature, au jardinage, s'opposant à la vie urbaine et une création artistique sur-intellectuallisante.

Je ne peux pour ma part me résoudre à la simplicité, et, cherchant de nouvelles lectures, je suis retombé de plus belle sur Philip K. Dick, l'embrouilleur de réalités, avec le volume un (sur deux) de l'intégrale de ses nouvelles. Et, pour changer, je code: j'enrichis le système de type de liquidsoap, et je saisis cette occasion pour écrire un quelques mots sur l'inférence de type.

Pourquoi typer ?

Lors de l'exécution d'un programme, si on ne fait rien pour s'en prémunir, certaines choses absurdes peuvent arriver. Une fonction à binaire peut ne recevoir qu'un argument, on peut se retrouver à additioner un entier et un couple de chaînes de caractères, etc. Il est difficile de prévoir exactement ces problèmes sans exécuter le programme, et cela devient impossible dès lors que le langage devient Turing puissant.

Une première approche consiste à ne rien faire, et laisser le programmeur attendre que l'erreur à l'exécution arrive. C'est litéralement nul, il faut donc donner un nom à cela ("dynamique") et balancer quelques slogans qui font bien ("de toutes façons les tests unitaires sont plus précis que le typage") pour faire bonne figure. La majorité des langages de scripts adoptent cette approche. Selon l'expression absurde à évaluer, une vraie erreur va être levée, ou l'interpréteur va adopter une solution et continuer. Par exemple, si une fonction n'est pas appelée avec tous ses arguments, l'un d'eux pourra avoir la valeur spéciale undefined. Tôt ou tard, cette valeur spéciale posera une vraie erreur (on peut imaginer que l'interpréteur refuse catégoriquement de l'additionner avec quoi que ce soit), et il sera assez difficile pour le programmeur de trouver d'où venait cet undefined, qui aura pu passer de fonction en fonction avant de poser réellement problème. Je ne vais pas en dire plus sur cette approche qui ne fait rien pour le programmeur.

Le typage peut être vu comme une sur-approximation de l'ensemble des comportements qui peuvent arriver. Parfois le typage va donc détecter un problème qui ne peut pas vraiment arriver -- si on écrit une expression absurde dans une branche morte du code. En pratique, ça reste naturel. Quelques exemples rapides: 3 aura le type int; ("trois",3) le type string*int; et la fonction fun x -> x+1 le type int ->int.

Le typage statique consiste à vérifier les types avant l'exécution du programme. Dans certains langages, le programmeur écrit les types de ses variables (C/C++, Java, ...). Cela peut devenir assez lourd. D'autres langages (OCaml, SML...) sont capables de calculer le type le plus général d'une expression, c'est ce qu'on appelle l'inférence. Quand un langage a cette propriété, c'est la panacée: on n'écrit pas les lourdes annotations de type, et on a une vérification statique du code. De plus, aucune information de type n'étant nécessaire à l'exécution, les valeurs sont représentées de façon plus compacte et manipulées de façon plus immédiate, et on obtient des programmes plus rapides.

Le bémol du typage statique inféré, c'est la complexité des messages en cas d'erreur de type. D'autre part, si le système est trop simple, cela contraindra trop le programmeur dans son utilisation du langage. Mais quand on étend le système de type, on complexifie rapidement les erreurs. Il y a là un compromis délicat.

Inférer les types

Comment deviner le type d'une expression? Il suffit de regarder de près, en commencant par les expressions élémentaires et en remontant... Prenons l'exemple de fun x -> x+1.

On commence sur 1, qui a évidemment le type int. Ensuite on rencontre x, dont le type est inconnu. Mais pour que x+1 soit valide il faut bien que x soit un entier. La fonction a donc le type int -> int. Si je la nomme f, on peut maintenant chercher le type de fun y -> f("bla"). On voit qu'on utilise f avec une chaîne comme paramètre au lieu d'un entier, c'est une erreur de type.

Polymorphisme

Une extension simple et qui fonctionne bien est le polymorphisme -- ou l'appelle généricité dans certains langages. Si j'écris fun x -> x, je ne fais aucune hypothèse sur le type de mon argument, et je pourrais utiliser cette fonction sur n'importequelle valeur. C'est possible, OCaml lui donnera par exemple le type 'a -> 'a, qui veut dire pour tout a, a -> a. Exemple moins bidon: la fonction qui retourne une liste ne fait aucune hypothèse sur le type des éléments de la liste, et aura le type 'a list -> 'a list. (Exercice pénible: faites la même chose avec Java...)

Comme inférer ces types ? Il suffit de généraliser sur les variables de type (1) qui ne sont pas instantiées et (2) qui ont été introduites dans la fonction. Quand on type fun x -> x, on vérifie le corps de la fonction sans avoir besoin d'imposer aucune contrainte au type de x, c'est encore une inconnue, que Caml note '_t. L'expression a donc le type '_t -> '_t, qu'on généralisera en 'a -> 'a.

Si par contre je type fun x -> fun y -> x, il faut faire un peu plus attention. Mauvaise solution: la fonction interne a le type '_Ty -> '_Tx, que je généralise en 'a -> 'b, l'expression complète a donc le type '_Tx -> ('a -> 'b), généralisé en 'c -> 'a -> 'b. C'est manifestement faux, car cela veut dire: je prends deux paramètres quelconque et je te renvoie un truc de n'importe quel type.

Si on applique la condition (2) sur l'exemple fun x -> fun y -> x, voila comment cela se passe. La fonction interne a le type '_Ty -> '_Tx, mais '_Tx n'a pas été introduit dans cette fonction interne. On ne généralise qu'en 'a -> '_Tx. La fonction externe a donc le type '_Tx -> 'a -> '_Tx, qu'on généralise en 'b -> 'a -> 'b. C'est correct, cela veut dire: donne moi deux paramètres, je te renvoie un truc du type du premier.

Subtilités avec les références

Encore un petit détail avant de conclure. La liste vide [] peut sans problème avoir un type polymorphe 'a list. Il n'en est pas de même pour une référence ref [], qui doit garder le type '_T list ref, sans généralisation sur '_T. On ne modifie jamais une liste: on en crée une autre qui pointe sur l'ancienne. Et il n'y a aucune problème à ce qu'une liste d'entiers finisse en pointant la même liste vide qu'une liste de chaines. Par contre on modifie une référence, c'est sa raison d'être. Si on utilise notre référence dans l'instruction r := [1] on y range une liste d'entiers cela doit forcer '_T à devenir int. Car si par la suite on utilise un élément de la liste contenue dans la référence, cela ne peut pas être n'importe quoi, ce sera un entier.

Exercice/exemple: vérifier que fun x -> ref [x] a le type 'a -> 'a list ref; que let r = ref [] in (r, fun x -> r := [x]) a le type '_T list ref * ('_T -> unit).

Liquidsoap

Pourquoi j'ai parlé de tout ça ? Ces jours ci, je rafraichis le code de l'inférence de type de liquidsoap. J'ai ces choses en tête et je crois que cela vaut le coup de les présenter. Bien sûr je n'ai pas détaillé tout ce qu'il y avait dans le système de type de liquidsoap. Mais tout ce que j'ai décrit s'y trouve. Ce qui me mène à mon second but: expliquer pourquoi toute cette technologie compliquée est nécessaire dans liquidsoap.

Pour être honnête, ce n'est nécessaire que si l'on accepte le choix des types statiques et inférés dans le langage de script de liquidsoap. Pour moi il n'y a pas photo. Ensuite, on a besoin de fonctions dans le langage pour représenter les transitions. Enfin, nous prévoyons de généraliser liquidsoap, de générateur de flux audio à générateur de flux quelconque, en ajoutant la vidéo dans un premier temps. Pour cela, il faut du polymorphisme: au lieu des objets de type source on aura des objets de type format source où le format pourra être audio, video, etc. avec des informations en fait un peu plus raffinées. Certaines de fonctions actuelles de manipulation de flux, comme le switch() qui passe d'un flux à l'autre, s'étendent naturellement à n'importe quel format. Elles auront donc un type polymorphe. Enfin, si j'ai parlé des limitations de la généralisation pour les références, c'est parce que les types source se comportent pareil.

Le truc chouette, c'est que ça me donne une super excuse pour coder ces trucs que j'adore -- et que je vais enseigner l'an prochain en TP d'un cours de M1 de l'X, au passage. Et même avant l'arrivée du support vidéo, ça rend le langage plus souple et sympa pour un nombre considérable de choses. Mais je ne vais pas me lancer là dedans, c'est assez...

Création

2007-06-15T10:01:00.000+02:00

Je ne code plus trop ces temps-ci, après la release de liquidsoap-0.3.3. Déja, je suis pas mal occupé au labo, et ça porte ses fruits. Mais de toute façon, il faut bien qu'il y ait des périodes moins frénétiques: c'est un projet sans deadline ni client. Aucune raison de se faire du mal pour apporter une amélioration montre en main. Me voilà donc dans une période tranquille, où je me demande plutôt ce que je pourrais faire de créatif à la place.

Mes pensées vont par exemple à ce projet de projet de jeu de piste (ou ARG?) radiophonique, parti de la numbers station de Balbinus... Disséminer des pistes, principalement par le biais de quelques webradios amies, vers les éléments d'une histoire/énigme/univers caché et mystérieux. Mais quelle histoire raconter, quelle idée faire passer? Parler de l'excès de communication, de l'usure des mots? des excès de l'individualisme?

En parlant d'alliance création/technique, je suis tombé sur la ménagerie, un studio d'animation amateur sympathique, qui lie developpement open-source et création d'animations en stopmotion (jetez un oeil à la section studio, par exemple cette surprise..) Chapeau bas!

De façon moins intellectuelle, je me demande si j'accrocherais à des jeux à histoire comme un Final Fantasy ou Castlevania sur DS; et si le EEE PC sortira vraiment en Aout, au prix annoncé et en quantité suffisamment énorme :)

Bientôt deux ans..

2007-06-01T22:46:00.000+02:00

J'anticipe un peu mais le temps passe vite, et en Septembre prochain j'entamerai ma troisième année de thèse. Pour ceux qui ne savent pas, ou pour mémoire, quelques mots sur ces derniers temps.

J'ai bouclé un article que j'aime bien, des observations mignonnes de théorie de la démonstration, dans une logique linéaire dotée de principes d'induction et coinduction. L'article a été soumis à une conférence, et rejeté. Les relecteurs n'étaient pas du domaine et ont décidé que ce n'était pas bien. Je ne vais pas trop m'étendre, le papier retente sa chance à une prochaine conférence sous peu. En plus, celle là m'enverrait en Arménie, c'est plus funky que la Suisse.

Sinon j'ai passé un week-end fatiguant mais fructueux à un workshop à Edinburgh. Les gens s'intéressaient globalement aux mêmes choses que moi, et réciproquement. J'ai pu lier quelques connaissances, et ça m'a remué quelques idées en tête. Il faisait pas beau, mais la ville est très classe dans son rôle froid et solennel. Par contre j'ai pas trouvé le moyen de me faire happer par un pub sympathique, on m'a même déconseillé d'essayer.

Pendant ce temps là Frank était au Canada et Dolebraï a peu bougé. Avant-hier on s'y est remis doucement, et il recommence à alimenter la playlist. J'écoute avec plaisir ses derniers ajouts. C'est très zen, parfait pour l'humeur du moment.

Ooomm...

Pour être honnête..

2007-05-24T14:31:00.000+02:00

J'ai critiqué ici Python et Javascript.. Je vous ai déja dit que Caml aussi avait quelques comportements décevants, à la limite du bug ?

# let f () =
let s = "abc" in
s.[0] <- char_of_int (1 + int_of_char s.[0]) ;
s ;;
val f : unit -> string = <fun>
# f () ;;
- : string = "bbc"
# f () ;;
- : string = "cbc"

Et grosse dédicace à Romain qui se met à OCaml pour de bon!

Sucre

2007-05-18T02:21:00.000+02:00

Déja un mois depuis mon dernier post, il est temps d'en aligner un autre, dans la lignée des notes bien techniques. Le developpement de liquidsoap continue sûrement et plutôt pas lentement. L'API s'étoffe, notamment avec le crossfade intelligent utilisant les intensités relatives des débuts/fins de fichier, et des traitements de son de fou grâce à la libsoundtouch; le format AAC est supporté; nous n'avons presque plus à rougir du support ALSA; la doc devient plus lisible; et une multitude de petits détails s'améliorent. Romain nous pousse à releaser au plus vite, ce qui devrait se faire vu les grands chantiers qui se profilent de nouveau à l'horizon. Pour ma part j'oscille entre l'excitation de voir tout cela si bien tourner, et l'énervement de passer beaucoup de temps à orchestrer ça, corrigeant ou ajoutant du code selon des priorités qui ne sont plus seulement les miennes: tel utilisateur insiste sur un point, tel développeur fait une modification pas forcément judicieuse... et je ne peux m'empêcher de vite intervenir, peut être à tort.

Après la release, ma priorité sera à l'enrichissement du système de type de liquidsoap, avec du polymorphisme et du sous-typage, amenant une simplification de certains opérateurs, et surtout la possibilité de faire cohabiter des sources manipulant différent formats de flux. Après ça, Sam va pouvoir se faire plaisir avec la vidéo... On envisage aussi de généraliser les notions de fade et de crossfade intelligent au delà de la simple mesure de volume: on peut désormais mesurer et changer le BPM d'une source, on se prend à penser à des transitions préservant la continuité du BPM. Voila pour le futur. J'espère parler de typage la prochaine fois, mais pour tout de suite je vous propose encore de l'analyse syntaxique.

Certains sucres syntaxiques semblent tout simples, mais ne rentrent pas dans la sacro-sainte architecture lex/yacc. Par exemple, le preprocessing, qui permet de n'inclure certaines parties du script que quand telle feature est activée: %ifdef FEATURE CODE %endif. Cela ne peut être traité par le parser, ne serait-ce que parce que la construction peut être utilisée à tous les niveaux de la grammaire, ce qui l'alourdirait considérablement. Autre exemple, la notation bien pratique à la Ruby: "Bonjour #{get_name()}!" au lieu de "Bonjour "+get_name(). Ce n'est pas faisable dans le lexer tout seul, et pénible à traiter au niveau du parser, qui en théorie ne dépend pas du lexer.

La solution est d'accepter de s'éloigner un chouilla de l'archi habituelle, en ajoutant des intermédiaires entre analyse syntaxique et lexicale. C'est particulièrement simple en Caml, où un lexer n'est autre qu'une fonction prenant un état (position dans le texte) et renvoyant le symbole suivant dans le flux. On peut donc écrire des fonctions pour enrober le lexer original, afin d'obtenir les notations décrites -- et on simplifie par ailleurs notre lexer en traitant de la même façon les retours à la ligne pour lever les ambiguités dont je parlais la dernières fois. Un petit exemple, le traitement des %ifdef:

(* takes a function of type Lexing.lexbuf->Lang_parser.token,
and returns a function of the same type *)
let preprocess tokenizer =
let state = ref 0 in (* number of nested %ifdef *)
let rec token lexbuf =
match tokenizer lexbuf with
| Lang_parser.PP_IFDEF ->
begin match tokenizer lexbuf with
| Lang_parser.VAR v ->
if feature_enabled v then begin
incr state ;
token lexbuf
end else
let rec skip () =
match tokenizer lexbuf with
| Lang_parser.PP_ENDIF -> token lexbuf
| _ -> skip ()
in
skip ()
| _ -> failwith "expected a variable after %ifdef"
end
| Lang_parser.PP_ENDIF ->
if !state=0 then failwith "no %ifdef to end here" ;
decr state ;
token lexbuf
| x -> x
in
token

Après avoir défini quelques sucres syntaxiques, on utilise tout simplement le lexer étendu expand (preprocess (strip_newlines Lang_lexer.token)) au lieu de Lang_lexer.token. L'exemple complet se trouve sur notre SVN.

Grammaire

2007-04-20T11:54:00.000+02:00

J'ai parlé ici-même, il y a presque un an, d'une petite astuce pour obtenir un langage sans point-virgule dans les séquences, juste un peu whitespace-sensitive, tout en utilisant le générateur de parser (ocaml)yacc. Je suis toujours dans cette optique, car je veux garder cette syntaxe légère, et je crois toujours qu'écrire mon parser à la main est source d'emmerdes au moins à long terme.

Résume de l'épisode précédent: le seul endroit où le retour à la ligne compte, c'est pour distinguer f ; (1,2) de f(1,2). Bien sûr la première expression n'a peu d'intérêt, la séquence ne servant qu'aux effets de bord que f ne fait pas, mais cela ne se voit pas au stage de l'analyse syntaxique. Ma solution a été d'introduire un token VARLPAR qui regroupe la variable et la parenthèse qui la suit si elles ne sont pas séparées par un retour à la ligne.

Second épisode: liquidsoap est en plein boom. Nous avons de nouveaux contributeurs, de nouveaux utilisateurs, on parle de nous, de nouvelles idées sont implémentées, etc.

Une de ces idées est le cross-fading intelligent. Au lieu de passer au cross-fading une fonction de transition qui décrit comment sont combinés les débuts et fins de piste, on y passe une liste de (condition,transition). La condition est une fonction à qui le smart_cross passe les puissances du signal sonore de part et d'autre de la transition. L'opérateur choisit la première fonction de transition dont la condition est validée. On peut ainsi choisir de superposer, fader, en fonction du volume des débuts et fin de piste. Romain a commencé à coder dans utils.liq l'utilisation du smart cross selon la description que mouke de bide-et-musique nous a faite.

Cet opérateur amène le besoin de coder dans notre langage de script des expressions arithmétiques, des comparaisons, etc. Et j'ai donc du étendre la grammaire. Pour faire simple, disons qu'on ajoute *, /, + et -.

Premier conflit: comment distinguer f(x) \n -1 de f(x)-1. Les deux sont naturels, on ne peut en éliminer aucun d'office. A moins d'empêcher le programmeur d'éclater ses expressions arithmétiques sur plusieurs lignes, ce qui est peu naturel et de toute façon difficilement réalisable dans mon cadre.

La solution vient de zmdkrbou, qui me propose de distinguer les expressions closes cexpr et les expressions générales expr. Une expression close peut être utilisée sans ambiguité dans une séquence: pour cela on limite les symboles pouvant apparaitre en tête, i.e. on élimine donc les négatifs -42, qui ne sont présents que dans les expressions générales. On peut obtenir une expression close représentant un négatif en l'entourant de parenthèses. Dans la plupart des règles, on peut continuer à utiliser des expressions générales, mais la règle de séquençage d'expression est restreinte aux expressions closes. Ainsi f(x) - 1, où que soient les retours à la ligne, sera la valeur de f(x) décrémentée de 1. Et on écrira f(x) (-1) (en général sur deux lignes, mais rien n'oblige) pour signifier qu'on évalue f(x) et qu'on retourne -1.

On tient le bon bout, mais l'histoire ne s'arrête pas là, et yacc m'en a fait baver. On a dans notre grammaire la règle (1) expr: cexpr, qui dit qu'une expression close est aussi une expression, et la règle (2) cexpr: cexpr PLUS expr. J'avais laissé un expr à droite du PLUS car l'ambiguité vue ci-dessus n'est présente qu'en début d'expression.

Sachant que l'automate d'analyse syntaxique doit décider de ce qu'il fait en ne regardant qu'un symbole en avant, comment savoir dans la situation cexpr PLUS ... si la cexpr doit être considérée comme une expr, auquel cas on réduit la règle (1), ou s'il faut avancer dans la règle (2) en mangeant de suite le +. L'automate est bête, pour lui une addition peut arriver après une expression générale car une expression générale peut être, en particulier, close. On ne peut le guider qu'avec des priorités, je mets donc une priorité plus faible à la coercion (1) qu'à la règle (2).

Et là, c'est le drame. Les priorités entre l'addition et la multiplication ne sont plus du tout respectées, l'analyseur parenthèse tout à droite comme un sale. On lui donne 2*3+1 il lit 2*(3+1). Après masse de bataille, je m'aperçois que la formulation de la règle (2), bien qu'inambigue, pose problème. On a expr: cexpr PLUS expr | cexpr MULT expr .... Le problème est que l'automate défavorise maintenant la coercion expr:cexpr. Du coup quand il voit le + après le 3 il ne va pas réduire l'expression close 3 en expression pour réduire ensuite l'expression close 2*3. Il va préférer manger le +, ce qui conduit à réduire l'expression close 3+1 en premier.

Au final la règle (2) doit s'écrire cexpr: cexpr PLUS cexpr. Et on n'y perd pas trop. On ne peut plus écrire 3+-1 mais il faut parenthéser en 3+(-1).

La morale: c'est toujours possible d'utiliser le couple lex/yacc pour une syntaxe sans point-virgule, en limitant énormément la sensibilité aux blancs (espace et retour à la ligne), ouf. Par contre l'automate de yacc est bien bête sur une production du type expr: cexpr.

Un jour faudra que je voie si c'est si difficile de ne pas ignorer les retours à la ligne à l'analyse syntaxique, et de les traiter explicitement partout dans la grammaire. A priori c'est lourd, comme il ne compte pas dans la majorité des cas. Mais une astuce n'est pas à exclure..

Libertés

2007-04-05T15:38:00.000+02:00

Ceci est un post en préparation pour Dolebraï...

Je suis tombé récemment sur Diogène, un éditeur de culture libre, qui se pose une question intéressante: Qu'est-ce que les arts libres ? Je rebondis sur leur opinion.

La culture libre est une véritable provocation au système capitaliste du copyright.

Non. Diffuser librement une oeuvre ne veut pas dire renoncer au copyright, c'est à dire à son droit d'auteur. Creative Commons décrit par exemple ses licences comme un moyen de changer les termes de son droit d'auteur, passer du "tous droits réservés" à "certains droits réservés", en offrant au public certaines libertés.

Le copyright est une bonne chose. Il a été instauré pour éviter que les auteurs soient dépossédés de leurs oeuvres et gardent certains droit fondamentaux, auparavant détenus par les éditeurs. Le droit d'auteur a aussi introduit certains droits pour le public, comme la garantie d'utilisation libre d'une oeuvre, la copie privée, le droit de courte citation ou de satyre. De nos jours il faudrait même défendre le droit d'auteur, car les droits des auteurs et du public sont menacés par les majors de la distribution musicale (qui attaquent le droit à la copie privée), voire par la SACEM (qui ne laisse pas la possibilité à ses adhérents de diffuser librement leurs oeuvres).

L’art libre, c’est aussi mettre en oeuvre la philosophie du don, une philosophie à développer aujourd’hui plus que jamais, car le capitalisme a mangé tous les cerveaux (ou presque) de nos contemporains.

Bien sûr. Le don c'est beau. Le partage et l'échange c'est aussi créatif et utile. Et il est vrai que cela devient très important de nos jours, où pour se faire encore plus de gros sous sur la culture, certains poids lourds tentent de la verrouiller de plus en plus.

Les arts libres, c’est de la culture faite par les pauvres, pour les pauvres ! [...] En effet, la philosophie du don ne peut fonctionner que si on accepte de vivre de rien, sans consommer ce qui est payant, donc en ne consommant que de la culture ou des produits gratuits. Cela implique de vivre en grande partie hors du système !

Certainement pas, ni en théorie ni en pratique. D'abord dans les faits, les gens qui produisent et consomment de la culture libre ne sont pas tant hors du système que ça, ce ne sont pas les plus démunis, ne serait-ce que parce que la culture libre passe par le net. Et puis donner ne doit pas vouloir dire accepter de ne rien attendre en échange -- c'est quelquechose qu'on retrouve aussi dans le logiciel libre, où l'on donne en attendant des dons en échange.

De nombreux artistes diffusent librement leur musique parce que c'est la meilleure opportunité qu'ils ont pour être visibles. Cela ne veut pas dire qu'ils n'espèrent pas vivre le leur musique. Cela n'exclut pas non plus que certains envisagent d'abandonner les licences libres s'ils peuvent gagner mieux leur vie ainsi.

Les licences d'art libre sont un moyen ouvert à chacun de diffuser son art, tout en défendant son droit d'auteur, et éventuellement d'en vivre, en se faisant connaître, ce qui permet de faire des concerts, etc. La culture libre c'est aussi un bel idéal, surtout dans le contexte actuel, mais pas seulement.

Re-Paf!

2007-03-30T11:48:00.000+02:00

Il n'y a pas que Toots qui s'amuse aux dépens de ceux qui utilisent son contenu graphique.. un blogueur américain s'est ainsi rendu justice en se payant la tête du sénateur américain qui l'avait spolié.

J'en peux plus

2007-03-22T18:01:00.000+01:00

En fin de semaine dernière j'ai donné un coup de collier pour releaser liquidsoap 0.3.2, merci au passage à Romain qui s'est occupé des releases des librairies associées, et du packaging Debian par derrière. Le but pour moi était de passer ensuite une semaine studieuse à écrire mon article. Impossible.

Lundi nous recevons sur la liste savonet-users un mail de mouke. Je cite car l'archive de la mailing-list est plus que pourrie:

I recently discovered LiquidSoap and it seems it is the streamer I have dreamed of for some months. I am the tech guru of the french webradio "Bide et Musique".

Mouke a déja un clone de Bide et Musique qui tourne avec liquidsoap et songe à distribuer son système de gestion de la programmation musicale. La description qu'il en fait est alléchante, cela ferait un beau compagnon à liquidsoap!

Nous avons de plus en plus de résidents sur le canal IRC #savonet chez freenode. La plupart utilisent liquidsoap pour leur radio underground ou étudiante. Avec l'arrivée de ce mail tous les français se sont excités. J'ai passé la nuit à coder, sur la sortie ALSA et plusieurs autres détails; Samuel s'y est remis aussi et a mis au point un opérateur de renormalisation dynamique du volume; Balbinus s'est laissé pousser à coder un opérateur de compression. Et Mouke interface liquidsoap avec son outil. Quand j'arrive à décrocher je me fais rappeler à l'ordre par masse de questions et remarques. Je vais demander aux admins du labo de me désinstaller xchat...

Mais ce n'est pas tout. Car O'Reilly parle de nous, comme me l'apprend Romain: Une radio scriptable avec Liquidsoap et Savonet. Je n'étais pas au courant, mais je remercie Xavier Cazin, qui avait découvert liquidsoap par hasard il y a un an.

Ce genre de phénomène est exponentiel. Ça va dépoter :)

Pendant ce temps là...

2007-03-16T20:49:00.000+01:00

Pas posté depuis longtemps. Tout va bien, c'est le Printemps. La lumière est belle le soir en retrant de l'école, et l'herbe sent comme une fille qui sort de la douche. Si la bonne recherche c'est d'ouvrir des questions plutôt que d'en fermer, ça ressemble à ce que je fais... J'aurais bien aimé parler de beau code, malheureusement je me suis empêtré dans mes constructions et le temps me manque. Il semble que je doive remettre ça à cet été, où on aura d'ailleurs encore un visiteur codeur pour jouer avec moi. Voici quand même un petit screencast amusant -- mais long à charger:

Meta-moutons

2007-02-25T00:04:00.000+01:00

L'univers est composé d'atomes, eux-mêmes composés de trucs encore plus petits qui régissent leurs interactions. Enfin, c'est le modèle qu'en ont les hommes. Les hommes sont des tas de molécules vivant sur une planète (un autre gros tas de molécules) qu'ils appellent la Terre. Ils ont appris à survivre sur cette planète, et au bout d'un moment se sont mis à faire des choses un peu plus complexes comme compter les moutons, faire du commerce, etc. Viennent ensuite la théorie des nombres et les mathématiques en général. Quel sens donner à ces abstractions ? Comment rattacher ces notions formelles simples aux choses affreusement compliquées qui nous entourent ? Comment délimiter un mouton, avant d'en compter des troupeaux ?

Vous comprendrez que ce train de pensée me mène à remettre en cause toute tentative de donner un sens à notre univers. Et de croire en particulier que toute cette science formelle qui nous fascine et nous fait "progresser" n'est qu'une construction folle, qui nous rend service presque par hasard... Ce genre de métaphysique est loin d'être malsain à mon avis, mais mène facilement à la déprime. Je me trompe peut-être à tout relativiser comme ça. Mais il me semble difficile, dans la position où nous sommes, d'affirmer quoi que ce soit sur le sens du monde ou la vérité des mathématiques.

Une idée loin d'être déprimante sort de tout ça: créer un jeu où les joueurs évoluent selon les règles qu'ils se sont fixés, c'est à dire dans leur propre modèle de la réalité. Bien sûr ce modèle devrait avoir quelque chose à voir avec le modèle réel-dans-jeu pour que ce ne soit pas n'importe quoi -- le lecteur attentif pourra noter ici une faille possible de mon point de vue. Bien sûr aussi, cette réalité serait inconnue. Tout le monde pourrait jouer au physicien dans ce monde, et on pourrait imaginer des joueurs malins qui découvrent des possibilités si folles qu'on les appeleraient magiques.

Bon, ne retenez pas votre souffle car je n'ai malheureusement rien de bien concret...

En attendant...

2007-02-12T19:37:00.000+01:00

Je n'ai toujours pas reçu ma carte Arduino. Je m'en étonne ce matin et on me répond (comme par hasard) qu'elle partira aujourd'hui, problèmes avec un fournisseur, etc. On verra...

En attendant, le jeu Another World a fêté ses quinze ans. Pour l'occasion, l'éditeur nous "offre" une édition spéciale, avec des décors réhaussés (nombre de couleurs augmenté, détails ajoutés) et (enfin) les graphismes vectoriels rendus en haute résolution. Je dis "offre" parce que c'est payant, uniquement disponible pour Windows. Ya certainement plein de gens qu'aimeraient voir la recette de ce mythe. À la place l'éditeur préfère se faire quelques recettes supplémentaires, qui seront probablement ridicules, d'autant plus que la nouvelle édition est déja craquée. Pour ma part j'étais chaud pour payer, mais j'ai voulu tester d'abord si la démo tournait sous Wine. Le non-émulateur fait tourner Warcraft III et WoW, mais.. pas Another World. Ils ont en effet trouvé le moyen d'utiliser les dernières fonctionnalités de DirectX, pour un jeu qui tourne sans problème sur NES ou GBA...

Au final, j'ai ressorti ma ROM GBA, installé VisualBoyAdvance, et re-fini le jeu. C'est assez court quand on se souvient des ficelles -- et (j'avoue) qu'on zieute la soluce une ou deux fois pour ce dont on ne se souvient pas. Mais ce n'est pas pour ça qu'Another World doit être le seul jeu que j'ai fini plusieurs fois. C'est parceque c'est beau (même tout pixelisé) et c'est bien (même si l'histoire est linéaire) et c'est de la balle.

Allez, un petit site marrant au passage: philosophie.ppt.

Art & Technique

2007-01-28T15:52:00.000+01:00

On pourrait croire que je vais me plonger/noyer dans le débat "la programmation est-elle un art ?", et bien non, je ne vais même pas parler de programmation. Ne pas en parler fournit cependant une excuse valable pour y mettre mon grain de sel, j'en profite... Mon avis personnel est que la programmation est une maladie. Plus sérieusement, je pense que cela relève plus de l'artisanat que de l'art, avec tout l'amour du travail bien fait qui est présent dans beaucoup d'autres disciplines, mais une notion de bien fait qui n'existe pas avec l'art, et qui est liée à la fonctionalité du programme. Les poèmes et autres palindromes écrits dans des langages de programmation, n'ont (dans les cas que j'ai rencontrés) aucun intérêt en tant que programmes.

Revenons à nos moutons. Je voudrais parler de Gumstix, Arduino, PureData et Liquidsoap. L'histoire commence il y a bien longtemps avec la panne de notre Nabaztag. Le lapin wifi est une réussite niveau design, mais n'est pas super solide, et les utilisations possibles de l'engin étaient un peu restreintes: il ne communique qu'avec le serveur officiel, certains services sont payants, on ne peut que jouer de courts fichiers sonores. On peut dire que c'était juste assez bien pour que je commence à penser à le remplacer, mais pas assez pour que je sois prêt à débourser 130€, même pour la nouvelle version avec un nombril-microphone. Bref, je me suis mis à chercher un moyen de fabriquer mon propre lapin wifi, si possible en re-utilisant des pièces. Voici deux trois trucs sur lesquels je suis tombé.

Gumstix

Piloter une carte wifi est une chose compliquée, et en plus ça consomme beaucoup. En revanche il semble relativement aisé de bricoler des circuits communiquant via Bluetooth ou Zigbee. Très bien, mais comment faire le lien avec Internet? Il faut un serveur qui y soit branché et communique avec le lapin. Dans un premier temps ce sera mon portable, mais à terme je crois que ce sera un Gumstix bricolé: un micro-PC linux, plus compact tu meurs, et relativement bon marché.

Arduino

A plus court terme il faut un circuit pour contrôler le haut-parleur, les moteurs et lampes du lapin. Le LEGO Mindstorm c'est rigolo, ça pourrait sûrement faire tout ça, mais c'est pas très compact et surtout super cher. Les microcontrolleurs programmables ça fait peur... Jusqu'à ce que je tombe sur le projet Arduino. Il s'agit d'un projet ouvert (code source et spec. matériel distribuées sous licences libres) qui développe des cartes programmables, avec pour cible première des étudiants en art. Ils semblent avoir un truc facile d'accès, qui tourne avec des outils libres (gcc + IDE à eux), supporté par une certaine communauté. A première vue c'est donc une solution à la fois sérieuse (vrai microcontrolleur, qui parle à n'importe quel composant électronique, qu'on peut à terme monter dans un circuit indépendant de la carte) et assez simple d'accès pour laisser un peu de place à la créativité.

J'ai craqué et acheté le starter kit (carte + matos électronique de base) pour 50€, avec pour premier but de piloter un équivalent du nabaztag depuis mon portable. Ensuite je rajoute le streaming audio, la communication sans-fil, et.. qui sait ?

PureData et Liquidsoap

La communauté des bricoleurs sur Arduino semblent utiliser de temps en temps PureData, je me suis donc repenché un peu sur cet outil.

PD (aka Pure Data) is a real-time graphical programming environment for audio, video, and graphical processing. It is the third major branch of the family of patcher programming languages [...]

Bon. Realtime, ça veut rien dire, tout est temps réel avec assez de puissance. J'arrive pas à comprendre ce qu'est Patcher, si c'est vraiment un langage ou une interface graphique. Je sais pas en quoi PD permet de manipuler audio, vidéo et images de façon plus intéressante que le C. Faudrait que j'essaie ça.

Toujours est-il que PD a l'air très prisé pour réaliser des outils interactifs de synthèse et traitement audio. La question est: quelle différence avec Liquidsoap? Le but initial est différent, jusque là je ne me posais donc même pas la question. Mais après tout ce sont deux architectures assez génériques de traitement de son.

La configuration de Liquidsoap n'est pas modifiable à la volée.
Liquidsoap n'a pas d'interface graphique pour composer son script.
Les possibilités d'interaction avec les sources sont limitées (interface telnet).
Liquidsoap a peu de fonctions de synthèse de son, pas de feedback.
On a pas d'entrée microphone stable.

Le premier point est délicat, c'est une modif non triviale que je ne ferais pas de sitôt, mais c'est faisable sans aucun doute. Les points 2-4 requierent encore pas mal de code mais aucune modif bien profonde, rien d'infaisable. Il faudrait bosser sur un protocole expressif et structuré pour interagir avec les sources -- à moins qu'on continue avec le telnet, la source mix() marche plutôt bien comme ça, pilotée depuis la GUI en python. Le point 5 requiert du code et du courage, j'ai aucune envie de me faire chier avec le hardware, mais c'est clairement faisable. Au final, j'ai envie de conclure qu'avec quelques contributeurs motivés pour pousser le projet dans cette direction, c'est faisable.

Mais quel avantage par rapport aux projets existants? Un premier truc qui distingue Liquidsoap d'un paquet de toolkits est que sa notion de flux comporte un notion de piste, ce qui permet d'avoir des opérateurs qui opèrent au niveau de la piste (sélecteurs, transitions entre pistes, etc.). Sinon, l'archi est propre et robuste grâce au typage de Caml. Enfin, ça me semble pas mal d'avoir un démon et un langage de script sous l'interface graphique, même si du coup on a pas d'interface graphique dans un premier temps.

J'en apprendrai peut-être plus aux Rencontres Mondiales du Logiciel Libre 2007 cet été à Amiens. J'ai décidé d'y présenter Liquidsoap! Je guette l'appel à présentations pour le thème multimédia sur leur fil RSS. Pour l'instant seuls les thèmes Communautés et Embarqué ont été appelés: ordre de préférence, organisateurs plus rapides?

Browser shots

2007-01-21T03:03:00.000+01:00

Un petit post pour noter une adresse bien utile: BrowserShots. Ce site gratuit permet d'obtenir des captures d'écran de plusieurs navigateurs sur la page de votre choix. Bien utile pour s'apercevoir que sa page n'est pas complètement portable malgré la validité du XHTML...

Bye bye 2006...

2007-01-02T10:44:00.000+01:00

Bonne année 2007 à tous ! L'année 2006 aura été riche d'évenements, jusqu'au bout: EUCD.info nous apprend en effet que le décret relatif au contournement d'une mesure technique a été publié le 30 Décembre.

Avec la publication de ce décret la lecture d'un DVD avec un logiciel s'appuyant sur un moyen de contournement existant (comme DeCSS, utilisé par de très nombreux systèmes logiciels libres) est donc passible d'une contravention de 4ème classe. Ainsi donc lire un DVD, légalement acheté par exemple, sur un système d'exploitation libre devient un acte passible d'une amende.

Loin de pousser au boycott, je suis quand même content de n'avoir ni offert ni reçu de DVD ce Noël...

Sinon, pour 2007, j'ai migré le blog sur le nouvelle version de Blogger, qui n'est plus en Beta. Je n'ai pas perdu mon modèle, et je vais essayer d'y ajouter l'affichage des catégories/libellés, tant attendues.

Paf!

2006-12-07T16:48:00.000+01:00

Dans la série "les pièges de l'Internet", ne pas pomper bêtement les images des autres. Ou alors mieux vaut les copier sur son site que d'utiliser l'adresse originale. Vous ne voyez pas pourquoi ? Toots a déplacé son petit rasta réutilisé, et l'a remplacé par ... heu ... ça.

Debugging mémoire: quatre jours pour une ligne

2006-12-01T18:19:00.000+01:00

Tout commence par un série de crashs de liquidsoap sur GeekRadio, causés par une pénurie de mémoire. Pendant quatre jours j'ai passé pas mal de temps à émettre des hypothèses, fausses pour la plupart, lire des analyses, mais surtout chercher des outils pour obtenir des analyses plus précises, pour finalement arriver à la fonction respondable et remarquer l'absence évidente d'une unique ligne de code.

La recherche de techniques de debugging aurait du être plus simple, j'ajoute donc un peu d'information utile dans la soupe, au cas où ça peut aider quelqun un jour...

Pour information liquidsoap est un logiciel de streaming audio programmé en OCaml, mais il utilise de nombreuses librairies interfaçant OCaml avec de fameuses librairies C comme Vorbis, Mad ou Shout. Dans un premier temps j'ai soupçonné un problème dans le tas Caml (les valeurs gérées par le garbage collector) pour finir par comprendre que c'était une bête fuite de mémoire dans le tas C (géré par malloc).

Ce n'est qu'à la fin de ce post que vient l'information la plus utile potentiellement. En effet j'y décris quelques techniques de débuguage avec le malloc standard GNU, qui sont peu connues à mon avis mais très pratiques.

exmap

Je ne m'attarderai pas sur cet outil car il est compliqué à mettre en place, puisqu'il repose sur un module du noyau linux. Je soupçonne que la plupart de ce que j'ai appris par gexmap était accessible dans /proc/$PID/maps ou autre. En plus ça m'a induit en erreur. L'outil nous a indiqué que ce n'est pas le tas qui explosait ([heap]) mais la mémoire anonyme ([anon]), et nous avons cru qu'il s'agissait du tas Caml. En fait, j'ai appris plus tard que le malloc() du GNU utilisait mmap() pour les "grosses" allocations ("largement plus" d'une page, soit 4092 octets typiquement), et les régions mmap()ées sont en fait ce qu'on appelle la mémoire [anon]nyme.

/proc/$PID/status

Sous linux ce fichier contient une description de l'état d'un processus. Les champs qui nous intéressent sont: VmSize, la totale de mémoire allouée au processus; et VmRSS, l'espace actuellement occupé par le processus dans la mémoire physique. La première valeur peut excéder la quantité de mémoire disponible, la mémoire allouée mais non accédée n'a en effet pas besoin d'être effectivement présente physiquement.

Mon erreur ici a été de tracer VmRSS, je crois. On obtient un graphe qui grimpe doucement, se stabilise progressivement, puis explose subitement. Je me suis conforté dans l'idée d'un défaut dans le tas Caml en interprétant cela comme un dérapage du garbage collector sur un tas corrompu. On s'aperçoit plus loin que le tas Caml n'a rien à voir là dedans, que le tas C croit progressivement sans raison. L'explosion du VmRSS est peut être dû à un rapatriement en mémoire physique d'un paquet de pages dû à un passage du GC, je ne sais toujours pas vraiment.

ocaml-memprof

Nous avons commencé par chercher un outil pour analyser le contenu du tas Caml. Quelques recherches m'ont mené à ce patch du compilateur initialement écrit par Fabrice Lefessant il y a bien longtemps, adapté et amélioré par je-sais-pas-qui pour ocaml-3.08.3 depuis, et enfin mis-à-jour pour la version 3.09 par Sam. Le patch se trouve donc maintenant ici et la doc là. Il y a peut-être encore quelques erreurs unused variable simples à corriger. La vraie difficulté est de comprendre comment utiliser la bête, la doc n'étant que très minimale.

D'abord, cela ne marche que pour le code natif. C'est marqué dans le README, mais il ne faut pas le rater car du bytecode tournera sans problème, dumpera ses images du tas, mais l'analyseur plantera avec une erreur des moins explicites.

Une fois le compilateur compilé, il faut l'installer. S'il n'est pas installé il ne trouvera pas ses librairies. Pour m'a part j'ai configuré avec --prefix /home/dbaelde/local. Ensuite j'ai écrit une config alternative ~/local/ocamlfind.conf, car j'utilise ocamlfind pour compiler liquidsoap:

ocamlc="/home/dbaelde/local/bin/ocamlc.opt"
stdlib="/home/dbaelde/local/lib/ocaml"
destdir="/dev/null"
path="/usr/lib/ocaml/3.09.2/METAS"

Pour l'utiliser il suffit d'exporter les bonnes variables d'environnement:

export OCAMLFIND_CONF=~dbaelde/local/ocamlfind.conf
export PATH=~dbaelde/local/bin:$PATH

Avec ça la version patchée de caml sera détectée pour les projets n'utilisant pas ocamlfind (toutes les libs de savonet), et ocamlfind l'utilisera aussi (pour liquidsoap).

Il ne reste qu'à lancer le programme Caml, qui fera appel régulièrement à Gc.dump_heap pour écrire un image du tas Caml sur le disque. Attention à ce que l'utilisateur qui lance le programme ait les droits d'écriture dans le répertoire courant, sinon ça plante violemment. Attention aussi à ne pas trop dumper, ça prend de la place. On obtient normalement des fichiers heap.dump.PID.N. On les compile en exécutant heapstats -heaps PID. Et on trace un joli graphe de tout ça avec hp2ps blocks_per_type.PID.hp et hp2ps sizes_per_type.PID.hp. On obtient deux postscript avec les graphes de l'évolution du nombre et de la taille cumulée des valeurs Caml, classées par type.

Pour liquidsoap, le graphe était très stable, aucune trace d'explosion.

GNU malloc

J'ai cherché des outils pointus pour avoir des statistiques sur l'allocation sur le tas C. J'ai trouvé des machins compliqués et d'autres qui ne marchent pas. Pour finalement me rendre compte que le malloc du GNU que j'utilisais déja avait tout ce qu'il me fallait!

Pour les statistiques mallinfo() donne plein d'information intéressante. La mémoire allouée au programme, la partie de cette mémoire qui est encore libre, la mémoire mmap()ée, etc. Ca m'a permis de rayer l'hypothèse de la fragmentation mémoire: en fait GNU malloc se comporte bien malgré l'utilisation frénétique qu'on en fait dans les bindings de Shout et Vorbis. Pour la petite histoire j'ai appellé mallinfo() depuis gcc, à l'aveuglette. Les champs de la structure mallinfo sont documentés dans /usr/include/malloc.h, ce sont tous des int, on peut donc y accéder sur une archi 32bits comme suit:

call mallinfo()
x/1dw $1 # Total space allocated from system
x/1dw ($1+16) # Mmap()ed space
x/1dw ($1+28) # Total allocated
x/1dw ($1+32) # Total free

Autant dire qu'à ce stade d'emmerdements je me sentais mériter d'en finir vite.

Mais la réponse est venue d'une analyse plus fine des allocations, permettant de remonter assez efficacement les fuites, toujours avec le GNU malloc standard. La fonction mtrace() permet en effet de stocker dans un fichier une trace de toutes les opérations mémoire effectuées. Un appel suffit et provoque l'ouverture du fichier indiqué dans la variable d'environnement MALLOC_TRACE, qui est mis à jour à chaque opération. Il prend rapidement beaucoup de place, attention donc.

Ensuite le programme mtrace analyse tout cela, et affiche à la fin les blocs non libérés. Si on lui donne le binaire responsable de la trace, compilé avec -g il associe un numéro de ligne aux allocations, ce qui permet de remonter aux allocations non nettoyées. Dans liquidsoap j'ai ainsi vu que de trop nombreux descripteurs de décodeurs Vorbis étaient alloués, alors que deux tout au plus devraient pouvoir exister à un instant donné. L'info était en fait même un peu plus précise que ça, en tout cas ça a permis d'en finir avec toutes ces histoires!

Pâques en avance..

2006-11-25T13:28:00.000+01:00

Merci Ameline...

Doutes et dégouts

2006-11-23T14:21:00.000+01:00

En ce moment à l'école, des affiches JP Morgan fleurissent. Après les avoir longtemps ignorées, je me suis laissé intriguer et ai lu le message: "Tu vas kiffer spéculer pour nous, tu ne penseras plus qu'à ça, t'en auras les mains qui tremblent. On a un sacré gros paquet de fric à jouer, mais souviens-toi, c'est qu'un jeu, pas vrai ?" Tant d'idéaux m'ont subjugué, j'ai embarqué l'affiche, direction poubelle. A la même époque l'an dernier j'ai déja écrit mon incompréhension et mon rejet des boîtes de finance. Je ne les comprends pas plus qu'avant, je ne les accepte pas plus non plus, ma seule pensée nouvelle est un souvenir de ce que ma maman me disait: On ne joue pas avec la nourriture, pense à ceux qui ont faim...

Je ne comprends pas plus qu'avant. Est-ce bien ou mal ? Ça me parait injuste, mais il n'y a rien d'illégal, pas de vol. Tout le monde consent à rentrer dans ce petit jeu. Pourtant il doit bien y avoir des perdants. Et je ne vois pas qui peut profiter de la spéculation rapide, si ce n'est les spéculateurs. Est-ce mieux de se faire payer à ~~bloguer et geeker~~ faire de la recherche fondamentale en logique ? C'est quand même un investissement à plus long terme, ça a plus de chances de profiter...

Après la seconde guerre mondiale il était établi que tout valait mieux que cette horreur, et un certain nombre de gens ont commencé à construire notre monde, autour du capitalisme, du commerce, de la finance. Certains pays en souffrent, en sont apauvris, mais cela vaut mieux que des guerres et des massacres, non ? J'ai tendance à dire oui, aussi, mais je ne m'étonnerai pas quand les pauvres changeront d'avis si le monde ne change pas assez bien.

Dans ces domaines j'ai des sentiments, mais pas de certitudes, et je ne comprends pas les gens qui en ont.

Qu'est ce qu'un Geek ?

2006-11-23T14:02:00.000+01:00

Comme Gelnior ou ecrans.fr le font remarquer, le geek est à la mode. Je porte pour ma part un tee-shirt #geek de temps à autres mais je n'ai pas l'impression d'être à la mode pour autant: il me semble que le mot change de sens, encore.

Un petit coup d'oeil dans urbandictionary confirme la définition que je connaissais il y a quelques années. Le sens premier désigne des gens décalés qui font un boulot ou se passionnent pour un sujet que le commun des mortels trouve bizarre. Le mot est cependant particulièrement utilisé chez les programmeurs, qui sont bien souvent des geeks par excellence au sens premier du terme. Geek est aussi un synonyme de nerd mais ce dernier terme est plutôt utilisé péjorativement, tandis que le premier est employé comme un terme positif par ceux qui se considèrent geeks.

Actuellement une autre forme de geeks est en train de s'accaparer l'appellation: l'ultra-fan de BD/science-fiction/jeu-vidéo, le mec qui passe aimerait avoir un sabre laser ou des pouvoirs psychiques. Bien souvent il aura aussi la tête fourrée dans son écran d'ordinateur, discutant avec ses compères sur forums ou échangeant des jeux/figurines/BD-collectors, mais il ne s'agit en aucun cas d'un codeur.

Conclusion ? Etre un codeur n'est toujours pas à la mode, et donc vraiment geek. On est des larves obnubilées par des systèmes austères, mais on va pas se laisser piquer nos appellations, bordel!

Debian on Dell D420 laptop

2006-11-12T02:56:00.000+01:00

I recently got a new laptop from the lab. It's a Dell D420, and it came with a Dell flat panel 20" WXGA UltraSharp. Bored with Gentoo, I decided to install a Debian on it.

The Debian CD I had was too old and didn't detect the wifi card, which is bad for a netinstall. So I booted a Ubuntu CD, and everything was detected. But I still wanted a Debian. So I followed this guide to install Debian from the LiveCD. That made the move from Gentoo less sad, looked familiar...

Although I didn't do an usual install, the next steps might be valuable for others, or me later. I installed Debian etch, got a kernel 2.6.17.

Nothing to say about wired network. It worked out of the box.

Sound worked fine as soon as I installed and dpkg-reconfigured alsa-base, ran alsaconf. Related useful packages here were alsa-tools and vorbis-tools. But I guess this is useless for a normal Debian install.

Video was a bit tricky. The video BIOS is broken on these machines. Just install 915resolution and reboot. This tools detects the actual screen resolution at startup and patches the BIOS so that X detects it fine. Problems arise when you plug the external screen: its resolution isn't detected either. The solution I found, which works with or without the external screen, is a bit dirty. Just add the following line at the end of /etc/defaults/915resolution: 915resolution 54 1680 1050 -- assuming you've got a 1680x1050 external screen.

One trouble with wide screens is that mplayer will stretch the videos. To fix this, edit /etc/mplayer/mplayer.conf to set monitoraspect=16:10.

The wifi is the hardest bit. First it depends on whether or not you have a dual core. With a single core you usually get a Broadcom card which requires ndiswrapper.. see other install-notes for that. With a dual core you can't get this card, and you usually get an Intel Pro Wireless: ipw3945. Unfortunately the driver is not free. I followed these notes for the installation of the ipw3945 module and ipw3945d daemon, including the edition of /etc/modprobe.d/ipw3945.

The problem, then, is that when the module is launched during boot, these magic lines are not used, so the daemon isn't started, and the wireless doesn't work. What I did is add a service to reload the module, and wait a bit for the server to initialize correctly. Edit /etc/init.d/ipw3945:

#! /bin/sh

set -e

PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="Intel PRO/Wireless 3945"
NAME=ipw3945
SCRIPTNAME=/etc/init.d/$NAME

# Exit if not root
if [ $(id -u) -gt 0 ]
then
        echo "This script must be run as root."
        exit 99
fi

# Gracefully exit if the package has been removed.
test -x $SCRIPTNAME || exit 0

case "$1" in
  start|restart)
        echo -n "Starting $DESC: $NAME"
        rmmod ipw3945
        modprobe ipw3945
        sleep 3
        echo "."
        ;;
  stop)
        echo "Stopping $DESC: $NAME"
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
        exit 1
        ;;
esac

exit 0

Then add a link so that it starts before networking: ln -s /etc/init.d/ipw3945 /etc/rcS.d/S38ipw3945. Configure eth2, reboot, that's ready.

Pierre blanche

2006-11-08T21:39:00.000+01:00

Un jour à marquer d'une pierre blanche. Je suis en train de gagner ce qui est probablement la dernière bataille de la campagne dans Advance Wars. J'ai fixé un défaut de récursion terminale dans le code de Bedwyr, ce qui nous a enfin permis de calculer notre exemple le plus complexe. Le boulot théorique avance moins mais n'est pas tout à fait au point mort. Mais surtout...

J'ai proposé une depêche linuxfr centrée sur Liquidsoap, présentant Dolebraï et RadioPi. Elle est passée en première page en début d'après-midi, causant un afflux de visiteurs pour les trois projets.

Edit: geotraffic très français sur le wiki de Savonet pendant les 24 heures qui ont suivi le post...

Photos d'Australie

2006-11-01T11:48:00.000+01:00

J'ai enfin uploadé mes photos d'Australie sur Flickr. Vous y trouverez des morceaux de Canberra, en particulier les photos de ma chasse aux kangourous.

Mais la plupart des images sont celles de mon dernier week-end, passé à Sydney: ville, plage, jungle, il y a de tout.

Solutions pour la France

2006-10-21T11:36:00.000+02:00

Hier j'ai été au ciné avec Estelle. On a vu Little Miss Sunshine que je recommande très fort. C'est beau et drôle, un peu dans le genre du C.R.A.Z.Y, très bon aussi mais plus à l'affiche. La première pub m'a fait un choc: crainte, puis grand éclat de rire. Je vous laisse juger...

Pour ceux qui n'ont pas vu les clips UMP starring Sarkozy, je vous laisse chercher. Même format pub, même discours qu'IKEA sur la France, mais le mouvement populiste propose clairement moins de solutions. Pour une France heureuse et dynamique, ne vous trompez pas, votez IKEA.

Au passage on remarquera que les divers clips de l'UMP qu'on peut trouver sur Google Video sont postés fréquemment, ils datent de moins de 5 minutes à l'heure actuelle. L'équipe comm' du parti ne chôme pas, et profite bien des faiblesses de ces systèmes de publication.

J'ai observé le même phénomène sur swik. Il s'agit d'un site qui répertorie des projets open-source, où chacun peut ajouter un projet. J'ai ajouté Liquidsoap en passant, puis constaté avec plaisir qu'il s'afficherait pendant quelques temps en tête de liste sur la page d'accueil, dans la liste des nouveaux projets. Ensuite je remarque que comme par hasard, plusieurs projets connus sont aussi dans cette liste: VLC, Muse, Dynebolic... J'ai vérifié, ces projets sont re-postés sur le site chaque jour. Je ne sais pas qui a commencé cette petite guerre, mais cela pourrit complètement le principe de ce genre de site.

Langages

2006-10-19T09:37:00.000+02:00

Il y a quelques semaines je tombais sur un os en Javascript, et je postais ici-même mon étonnement et ma déception. J'en ai depuis appris un peu plus, et en ai surtout discuté avec mon père, et sur LtU où j'essaie de justifier ma déception... Tout cela appelle à une longue suite, sur JavaScript en particulier et les langages de programmation en général.

Tout d'abord un exemple plus simple révélant le problème dans son ensemble avec Javascript:

var a = 0;
function f() {
// La variable locale "a"
// est déclarée pour le corps de la fonction,
// dès lors qu'une déclaration de "a" a lieu où
// que ce soit dans la fonction, 5 lignes plus bas ici.
a = 1 ;
// Ce n'est donc pas le "a" global qui a été modifié ici.
// Mais pour le savoir il faut lire deux lignes plus bas.
if (false) {
var a = 2 ;
...
}
}
// Ici, "a" vaut toujours 0.

Les concepteurs de JavaScript avaient des priorités et ont préféré ne pas s'embêter avec des portées plus fines que la fonction. C'est un choix qui a aussi été fait dans les premières standardisations du C, mais dans ce cas la déclaration d'une variable ailleurs qu'en début de fonction est tout bonnement interdite, rejetée à la compilation. Dans des versions récentes du C, en C++ ou Java, les déclarations de variable sont autorisées n'importe où et leur portée est restreinte au bloc englobant. En OCaml ou SML, la déclaration de variable let VAR = EXPR in BODY forme un bloc à elle seule, et la portée de VAR est restreinte à BODY.

En gros, j'ai commencer à coder en C, puis ai passé des années avec OCaml. Dans les deux cas j'ai été habituée à des portées de bloc. Avec OCaml on en fait un usage intensif, par exemple en émulant les variables static de C en déclarant une variable locale visible uniquement depuis une certaine fonction:

let compteur =
let n = ref 0 in
fun () -> incr n ; !n
(* "n" invisible après la définition de "compteur" *)

J'ai aussi passé un été à programmer en Emacs Lisp. Dans ce langage la liaison des variables est dynamique. Cela signifie que si une fonction fait référence à une variable n, elle fait référence à la variable n dans le contexte de son exécution (dynamique) et non pas dans le contexte de sa définition (statique). Cela permet certains bricolages mais la plupart du temps cela amène à de mauvaises surprises. Avec l'habitude on évite les mauvaises surprises en évitant de construire des fonctions dans un contexte pour les exécuter dans un autre (c'est dommage), ou on force l'évaluation des variables en question lors de la construction de la fonction (c'est pénible).

De temps en temps j'ai été amené à pratiquer JavaScript, car il n'y a pas le choix pour scripter côté client sur le web. Il m'a aussi parfois été utile d'utiliser Python, pour développer rapidement un petit outil grâce aux innombrables librairies disponibles. Dans les deux cas j'ai été heureux de constater que les fonctions sont des valeurs comme les autres et que la liaison des variables est statique -- on dit aussi que la portée est statique/lexicale. Je me suis réjoui à l'idée que les langages de script se modernisaient, et que j'allais pouvoir m'exprimer librement et richement. J'ai dit autour de moi que JavaScript c'est bien. Et je connais un mec qui utilise JavaScript comme son langage de tous les jours, et qui a voulu participer au concours de prog de l'ICFP avec, parce que en gros c'est statique, propre, fonctionnel.

Eh bien aujourd'hui je modère ce jugement. JavaScript n'est pas si riche, il ne me plait pas tant que ça. Et en plus il autorise des déclarations de variable n'importe où, ce qui induit en erreur les habitués d'autres langages -- et nous sommes nombreux.

Pourquoi poster ce genre de notes ? J'espère sensibiliser autour de moi ceux qui ne le sont pas encore: Il y a de nombreuses subtilités dans la conception d'un langage, et les langages les plus populaires ne sont pas ceux qui ont résolu ces subtilités au mieux. Sur la question de la portée des variables, de nombreux langages offrent une portée statique, plus expressive et moins surprenante d'utilisation. D'un point de vue technique c'est donc possible, et depuis longtemps. Le léger coût que cela a me semble être le genre de chose qu'on oublie volontiers aujourd'hui, dans la mouvance des langages haut-niveau. Le typage est une autre caractéristique importante des langages, et beaucoup de gens n'ont pas idée de ce qui est possible, par exemple en Caml où le typage est statique mais toujours inféré et généralisé automatiquement -- cf mon post récent. Tant que de nouveaux langages, au demeurant attractifs et aux nombreuses qualités, seront développés en ignorant/rejettant ces solutions, elles resteront méconnues. C'est dommage, car les développeurs passent à côté d'une sémantique plus claire, de plus d'erreurs détectées automatiquement dès la compilation, et d'une exécution plus rapide. A défaut de créer moi-même un langage simple et riche, j'aimerais essayer de pousser les autres à aller dans cette direction, dans la mesure de mes possibilités très limitées.

Je conclus sur l'exemple du compteur en Javascript, qu'il nous faut modifier ainsi:

function cree_compteur() {
var n = 0 ;
return (function () { return ++n }) ;
}
var compteur = cree_compteur() ;

C'est pas si dur, mais il vaut mieux le savoir. Fini pour aujourd'hui, je ne traite pas de l'absence de portée de bloc en Python...

PS: J'oubliais de pointer la proposition d'ajouter à JavaScript 2 un nouvel opérateur de déclaration de variables à la portée plus stricte. Pour des raisons de compatibilité, le nouveau let ne remplacera pas l'ancien var.

69j 04h 09m 09s

2006-09-25T08:14:00.000+02:00

Je me suis dit que 69 jours était un uptime satisfaisant pour relancer Dolebraï après quelques modifications mineures dans le traitement des metadatas et la description du flux auprès d'icecast.

Le développement de liquidsoap n'a pas avancé depuis des semaines, autant du côté des bugfixes que des nouvelles features qu'on a en tête. J'ai tenté d'attirer de nouveaux utilisateurs sur notre nouvelle release, mais malgré quelques pics de traffic/downloads je crois que c'est plutôt un échec. Trop compliqué pour les besoins simples de la plupart des gens? Ou alors faut attendre, on est pas pressé..

Mes annonces sur la Caml-list, la liste Icecast (mais on n'est toujours pas dans la liste des clients), et Freshmeat. Visiblement ça s'est répercuté sur un truc inconnu, Softpedia/Linux.

Générateurs

2006-09-19T10:48:00.000+02:00

Ça faisait longtemps que je voulais m'essayer à camlp4, je me suis donné pour exercice d'implémenter des générateurs à la Python -- ce n'est pas nouveau, il me semble avoir déja vu passer ça sur la liste Caml. Le résultat final fait plaisir.

let c = mkseq [-102;1;5;10;33;42;77] ;;
let s = mkseq [1;0;-1] ;;

list_of s*x for x in c if x#even for s in s ;;
= [-42;0;42;-10;0;10;102;0;-102]
list_of x*s for s in s for x in c if x#even ;;
= [-42;-10;102;0;0;0;42;10;-102]
table_of (x,x#even) for x in c ;;
= {77:false;42:true;33:false;10:true;
5:false;1:false;-102:true}

are_all x#even for x in c ;;
= false
is_any s#null for s in s ;;
= true
max_of x#abs for x in c if x#even) ;;
= 102

Comme vous pouvez le voir j'ai orienté objet, car c'est un aspect de Caml que j'essaie d'explorer plus à fond ces temps-ci.

Venons en directement aux conclusions avant de passer aux morceaux de code:

Camlp4 c'est puissant, mais faut tâtonner pour s'en sortir au début, avec un oeil sur le manuel. De façon générale je suis sympathique à l'idée d'un préprocesseur qui s'assume en tant qu'outil de meta-programmation, plutôt que des capacités vicieuses d'introspection.
Les générateurs sont facilement réalisés comme un sucre syntaxique à base de fold. Je ne sais pas pourquoi Python utilise des itérateurs/coroutines, yield & co., peut-être parce que l'utilisation de clôtures n'y est pas efficace. En Caml je ne vois aucun problème à mon approche, rien qui justifierait l'ajout du concept de coroutine ici. J'aime à voir ici une réponse à un post de Guido où il annonce la suppression de map, iter, reduce (le fold de Python) et lambda: pour lui reduce est incompréhensible et inutile, pour moi c'est habituel et fondamental. Là où Guido marque un point c'est qu'ayant cette syntaxe naturelle, je ne suis pas sûr de vouloir utiliser map ou iter directement si j'ai le sucre syntaxique à disposition.
Je suis fan du sous-typage structurel pour les objets dans Caml, mais l'inférence échoue et renvoie des erreurs cryptiques. C'est loin d'être intuitif et j'ai dû sévèrement annoter mes méthodes. C'est encore pire si on essaie d'exprimer le schéma [.. for x in ..] comme une fonction. Il faut alors spécifier le type des objets itérables et générables, et effectuer des coercions explicites vers ces types, ce qui est piégeux à cause de la récursivité du type.
Les listes et autres types de base en OO, c'est moche, surtout quand on imagine ces valeurs omniprésentes se trimballer leur collection de méthodes triviales tout du long.

Pour vous avouer le fond de ma pensée, j'aimerais trouver/écrire un langage de script (au sens de la facilité d'utilisation, pas de l'absence de compilation) typé statiquement avec sous-typage structurel pour des objets et des variants polymorphes à la OCaml, avec une bonne inférence qui rende le tout utilisable par Monsieur Toulmonde. J'aimerais voir ce genre de concept se répandre. Je me doute que le problème de l'inférence n'est pas simple, j'essaierai d'étudier ça de plus près à l'occasion.

Le code

Mon fichier ML définit quelques classes qui pourraient faire partie de la lib standard OO s'il y en avait une -- même si ça fait peur, disons qu'on imagine. À la fin, j'y utilise la notation que je ne définis que plus bas, mais c'est pour présenter le type des méthodes
fold. La longueur vient uniquement du choix OO, et du fait que je définis plusieurs
itérateurs (seq et table) et générateurs (seq, table, max, conjunction et disjunction mais pas iter).

(* Fichier geno.ml *)

class boolean (b:bool) =
object
method in_val = b
method to_s = if b then "true" else "false"
end

class conjunction (b:bool) =
object
inherit boolean b
method add (x:boolean) = new conjunction (x#in_val && b)
end

class disjunction (b:bool) =
object
inherit boolean b
method add (x:boolean) = new disjunction (x#in_val || b)
end

class integer (i:int) =
object
method in_val = i
method to_s = string_of_int i
method times (y:integer) = new integer (i*y#in_val)
method abs = new integer (abs i)
method null = new boolean (i = 0)
method even = new boolean (i mod 2 = 0)
end

class max (i:int) =
object
inherit integer i
method add (x:integer) = new max (max i x#in_val)
end

class ['a] seq (l:'a list) =
object
method add x : 'a seq = new seq (x::l)
method fold : 'b. 'b -> ('b -> 'a -> 'b) -> 'b =
fun x0 f -> List.fold_left f x0 l
method to_s =
"[" ^ (String.concat ";" (List.map (fun s -> s#to_s) l)) ^ "]"
end

class ['k,'v] table (l:('k*'v)list) =
object
method add x : ('k,'v) table = new table (x::l)
method get k = List.assoc k l
method fold : 'b. 'b -> ('b -> 'k -> 'b) -> 'b =
fun x0 f -> List.fold_left (fun acc (k,v) -> f acc k) x0 l
method to_s =
"{" ^
(String.concat ";" (List.map (fun (k,v) -> k#to_s^":"^v#to_s) l)) ^
"}"
end

let mkseq l = new seq (List.map (fun i -> new integer i) l)
let print x = Printf.printf "%s\n%!" x#to_s
let ( * ) x y = x#times y

let _ =
let c = mkseq [-102;1;5;10;33;42;77] in
let s = mkseq [1;0;-1] in

print (list_of s*x for x in c if x#even for s in s) ;
print (list_of x*s for s in s for x in c if x#even) ;
print (table_of (x,x#even) for x in c) ;

print (are_all x#even for x in c if x#even) ;
print (is_any s#null for s in s) ;
print (max_of x#abs for x in c if x#even)

Maintenant je définis l'extension de syntaxe qui traduit les constructions type générateurs vers la bonne recette à base de fold (ce qu'on parcourt) et add (ce qu'on construit).

(* Fichier pa_geno.ml *)

open Pcaml

let genseq = Grammar.Entry.create gram "genseq" ;;

EXTEND
genseq: [
[ "for" ; x=patt ; "in" ; c=expr ; gs=genseq ->
fun body -> let g = gs body in <:expr<
(fun acc -> $c$#fold acc (fun acc $x$ -> $g$ acc))
>>
| "if" ; test=expr ; gs=genseq ->
fun body -> let g = gs body in <:expr<
(fun acc -> if $test$#in_val then $g$ acc else acc)
>>
| -> fun body -> <:expr< (fun acc -> acc#add $body$) >> ]
] ;
END ;;

EXTEND
expr: BEFORE "expr1" [ "genexpr" NONA
[ "list_of" ; fx=expr ; gs=genseq ->
let g = gs fx in <:expr< $g$ (new seq []) >>
| "table_of" ; fx=expr ; gs=genseq ->
let g = gs fx in <:expr< $g$ (new table []) >>
| "are_all" ; fx=expr ; gs=genseq ->
let g = gs fx in <:expr< $g$ (new conjunction True) >>
| "is_any" ; fx=expr ; gs=genseq ->
let g = gs fx in <:expr< $g$ (new disjunction False) >>
| "max_of" ; fx=expr ; gs=genseq ->
let g = gs fx in <:expr< $g$ (new max 0) >>
]
] ;
END ;;

Enfin pour compiler le tout:

>camlp4o pa_extend.cmo q_MLast.cmo pa_geno.ml -o pa_geno.ppo
ocamlc -I `camlp4 -where` -c -impl pa_geno.ppo
camlp4o ./pa_geno.cmo geno.ml -o geno.ppo
ocamlc -I `camlp4 -where` -c -impl geno.ppo
ocamlc geno.cmo -o gen

Pour afficher la traduction du fichier ML par le préprocesseur, c'est camlp4o ./pa_geno.cmo pr_o.cmo geno.ml et on y lit que max_of x#abs for x in c if x#even devient:

c#fold (new max 0) (* for x in c *)
(fun acc x ->
if x#even#in_val then (* if x#even *)
acc#add x#abs (* x#abs *)
else acc)

Je suis sûr que ça change vos perspectives pour la journée :p

Netvibes

2006-09-15T03:30:00.000+02:00

Toutes mes données ne sont pas chez Google, mes flux RSS préférés ainsi que quelques notes et TODO list sont sur ma page d'accueil Netvibes, la startup française à la mode. Et quand je décide de trainer sur MSN c'est désormais dans mon browser via Netvibes, grâce au module Meebo.. Oublions les problèmes de vie privée que tout cela pose, en tout cas c'est cool.

Récemment j'ai ajouté le module Daily Cartoons, je découvre Dilbert, Reality Check, ou encore Pearls Before Swine. Je ris, parfois jaune:

Portées de variables

2006-09-12T03:58:00.000+02:00

Encore un post de geek: devinerez-vous le résultat du petit bout de code suivant?

var bla = ["oof","rab"] ;
var fun = [] ;
for (var i in bla) {
// i varie de 0 à 1
var inside = 2*i ;
fun[i] = function () {
return (inside+"-"+bla[i]) ;
} ;
// (2*3)+"-"+"a" == "6-a"
}
alert("La reponse est: "+fun[0]()+"...") ;

Et le résultat du suivant?

Lancer le test?

A priori vous vous êtes trompés, et ce n'est pas votre faute mais celle du langage.

L'expérience fonctionne aussi en Python, ça me déçoit de ces deux langages, je pensais que les problèmes de liaison de variables y étaient joliment résolus, comme l'exemple avec une fonction le montre.

Mais qu'est-ce qui se passe, en fait ? Avec une boucle, une seule instance des variables "i" et "inside" est crée, elle persiste d'une étape de l'itération à l'autre. Du coup au moment où on évalue la fonction fun[0], "i" et "inside" ont leur dernière valeur, respectivement 2 et "rab". A la limite pour "i" on dira que c'est spécifié comme cela, mais pour "inside"? La variable est déclarée dans la boucle! Si on veut avoir une variable persistant d'une itération à l'autre, on la déclare hors de la boucle. De même si on veut pouvoir accéder à "i" après la fin de la boucle. Si ce n'est pas l'effet voulu il est naturel de déclarer dans la corps de la boucle, et on voudrait bien que cela change quelquechose!

Edit: la "suite" de cette note est ici.

Strong typing doesn't have to suck

2006-09-11T03:52:00.000+02:00

Au détour de conversations je suis tombé aujourd'hui sur cet article. L'article dresse une très brève histoire des langages de programmation, et des systèmes de type. Les programmeurs des débuts s'arrachent les cheveux, confondant les adresses de nombres avec celles de chaînes. Ils inventent les systèmes de type de C/Pascal/etc: statiques (vérification à la compilation, plus d'information de type à l'exécution) et forts (une variable d'un certain type ne peut contenir de valeurs d'un autre type). Ces systèmes sont peu expressifs et somme toute mal foutus, ce qui mène à deux nouvelles évolutions. La puissance des machines aidant, on invente d'un côté les langages interprétés avec leurs systèmes de type dynamiques (le contenu d'une variable peut changer de type) très en vogue de nos jours. Mais le typage statique n'est pas mort, il a évolué dans les ML et Haskell: plus expressif, il relève de vraies erreur de programmation, et ne requiert pas d'annotations de la part de l'utilisateur. Conclusion: le typage fort ne suce pas forcément des ours.

L'intéret de la présentation est qu'elle s'adresse à un large public de programmeurs, et non pas à des gens qui connaissent déja un ML. Des exemples simples de code sont donnés pour expliquer et motiver. Bref, je pense que ça peut intéresser un paquet de gens: ceux qui ne connaissent pas ML, et peut-être ceux qui en sont dégoutés; ceux qui en ont marre du typage dynamique, ou des annotations de type, et ceux qui ne le savent pas encore.

Malheureusement ce n'est pas un guide introductif à ML, et je n'en connais pas que je puisse recommander. Si seulement OCaml était simple à apprendre, le monde saurait..

Voyage en Australie, en chiffres

2006-09-06T02:48:00.000+02:00

Je suis bien arrivé en Australie. Parti dimanche à 23h15 de Paris, je suis arrivé à Singapour à 17h45 heure locale. Pour la première fois j'ai eu droit à des turbulences, mais j'ai même pas eu peur, fort de la statistique d'Estelle: un homme qui passerait toute sa vie en avion aurait plus de chance de mourir de vieillesse que d'un accident -- pour les problèmes de santé liés à la bouffe et aux nuits dans un fauteuil, on sait pas.

Quand je suis reparti à 19h50 pour Sydney, il faisait déja bien nuit. Après un second vol à 10000m d'altitude et 1000km/h, notre avion est descendu vers l'Océanie et une vitesse d'aterissage de 300km/h. Je suis arrivé à 05h10 sur le sol Australien, et mon passage aux douanes n'a pris que 10 secondes. La température extérieure est de 11°C, contre 30°C à Singapour: de ce côté là de l'équateur on se refroidit en descendant au Sud, et c'est la fin de l'hiver.

A 7h00 je quitte Sydney (4 200 000 hab) pour Canberra (325 000 hab, capitale de l'Australie, 20 000 000 hab) à bord d'un tout petit avion mu par ses hélices, et peuplé de costards et tailleurs. Je ne lis pas le journal Australien qu'on m'a proposé, la couverture me suffit pour bien rigoler quand je pense à la remarque du Lonely Planet: contrairement au cliché les Australiens ne sont pas des aventuriers chasseurs de crocodiles, etc.

La fin du premier épisode de cette histoire se termine à mon arrivée à Canberra à 7h50 heure locale, mardi matin. A ce moment là il est 23h50, mardi soir en France. Cela fait donc 24 heures que je suis parti, et pas beaucoup moins d'heures en vol, ce qui fait mal à mon karma par rapport à la dernière fois où je l'ai calculé.


PAR CATÉGORIE   HECTARES GLOBAUX
ALIMENTATION  1.4
TRANSPORTS  0.8
LOGEMENT  0.6
BIENS ET SERVICES  1.5
VOTRE EMPREINTE TOTALE  4.3
 
EN COMPARAISON, L'EMPREINTE ECOLOGIQUE MOYENNE
DANS VOTRE PAYS EST 5.3 HECTARES GLOBAUX
PAR PERSONNE.

IL Y A 1.8 HECTARES GLOBAUX PRODUCTIFS PAR PERSONNE
DANS LE MONDE. SI TOUT LE MONDE VIVAIT COMME VOUS
ON AURAIT BESOIN DE 2.4 PLANETES

Ah.. vous vouliez des photos d'où j'habite, des paysages et tout ? Patientez.

Photos de Norvège

2006-08-30T23:27:00.000+02:00

Estelle a mis en ligne une galerie de photos sur notre voyage en Norvège. Dans le même temps nous avons commencé à uploader les mêmes photos sur Flickr. Mais la limitation à 20Mo/mois nous a vite calmés. Sinon Nico a pris de très belles photos aussi, mais il les a pas encore mises en ligne. Voici une petite sélection et un bref résumé.

Nous sommes partis de Bergen, en bus, pour rejoindre Lavik, d'où nous avons voyagé en bateau vers Balestrand puis Flåm, profitant bien du paysage dans un fjord: en gros collez au dessus de la mer toutes sortes de trucs sans rapport, alpages helvètes, flancs escarpés pyrénéens, etc. Ensuite, cinq jours de rando jusqu'à Finnse puis Fossli, qui nous ont révélé des paysages encore très changeants, avec un glacier et ses alentours désolés à notre point culminant, 1700m... Prenant l'alibi de la blessure de l'un de nous, nous avons coupé court à la rando, et sommes retournés en bateau de Kinsarvik à Utne, puis bus pour Bergen, visitant au passage un autre fjord magnifique par un temps magnifique lui aussi.

Pour finir, trois-quatre jours à visiter Bergen n'ont pas été de trop. Deuxième ville de Norvège, cela reste petit, et très mignon. Balades dans les rues et parcs, chouette musée notamment pour l'art moderne, pique-niques au poisson et autres curiosités culinaires, pintes dans un bar blindé d'étudiants fraîchement rentrés, points de vues et nombreuses pauses café.. Pour finir, visite à l'aquarium: ils ont des pingouins Gentoo!

Malheureux lapin

2006-08-28T11:07:00.000+02:00

Un post pour se plaindre un peu du Nabaztag, un lapin Wifi conçu par la boîte française Violet. Pour noël dernier j'ai offert pino à ma copine, et nous avons joyeusement accueilli ce lapin-sapin multicolore. Pendant des mois il nous a réveillés, dit la météo, quelques messages occasionnels, puis quelques nabazcasts, entre deux séances de tai-chi.

Au bout d'un moment une de ses oreilles s'est mise à grincer. Estelle a contacté Violet, on lui a gentillement proposé un échange, sans formalités, directement à leur siège. L'endroit est rigolo, petit, plein de lapins partout.. arrivés là-bas pino ne grince plus, mais on nous propose quand même un nouveau lapin dans une nouvelle boîte. Jusque là, super. Arrivés à la maison on branche le nouveau pino, et peu après il se fige, une oreille bloquée, grognant. Régulièrement, l'oreille se bloquera, bloquant tout le programme avec. Nous l'avions donc l'éteint.

Un ami m'a dit qu'il avait eu le même problème, que Violet lui avait expliqué que c'était devenu fréquent pendant la grosse chaleur, et que c'était en effet passé depuis que le temps s'est rafraichi. Du coup nous avons rallumé le nouveau pino, et n'avont plus constaté le problème pendant deux jours. Mais hier, il était éteint. On le débranche, rebranche, rien n'y fait, pino est mort. Peut-être que ce n'est qu'un problème d'alim, mais ça commence à faire beaucoup pour un joujou de 100€ à moins de 10 mois de vie. À suivre.

Liquidsoap 0.3.0

2006-08-27T18:46:00.000+02:00

Je sors touuut doucement du rythme vacances. J'ai enfin publié la version 0.3.0 de liquidsoap, qui était prête depuis presque un mois. J'attendais la fin des vacances pour pouvoir répondre aux questions d'éventuels utilisateurs. Pour commencer, j'ai annoncé la nouvelle sur la caml-list. Pour la suite, freshmeat, icecast, linuxfr, etc.

Avec cette version riche en nouveautés et longuement peaufinée, j'espère voir arriver une belle vague de curieux. Dans tous les cas, je ne vais pas coder dans liquidsoap pendant un moment, ce qui est parfait pour ma rentrée. En Australie, ce sera boulot ...et Nintendo DS -- oui j'ai craqué -- New Super Mario et Advance Wars ne me décoivent pas -- non j'ai pas encore testé DSLinux.

Retour de våcånces

2006-08-22T08:51:00.000+02:00

Retour définitif de vacances après deux semaines en Norvège. Pays magnifique, même si on se lasse après deux autres semaines de camping, et une nourriture un peu morne et carrément sucrée. Pour les photos de notre randonnée et visite de Bergen, vous attendrez encore un peu..

Je me remets doucement dans le bain de la vie quotidienne, avec quelques tâches administratives à boucler avant mon départ à Canberra pour le mois de Septembre. Pour se consoler de la fin des vacances on est allé faire un petit saut à République, et je me suis enfin offert Viewtiful Joe 2. Ca fait un moment que je le reluque, et je suis pas déçu pas le super style cartoon et le gameplay déjanté.

En réalité je suis encore plus atteint que ça, et je pense être dans une vraie période d'addiction au jeu, à moins que ce ne soient juste les gadgets.. Toujours est-il que je bave (de nouveau) sur la DS. Une des raisons est que Nicolas m'a rejoint et poussé dans ce penchant, et que je justifie l'idée de ce caprice de plus par tous les temps de transport que j'ai, en RER et aussi très bientôt en avion avec 24h aller pour l'Australie -- quoi de mieux pour tester la légendaire durée de vie des batteries de la DS.

Pour me venger, j'y rajoute une dose, avec un petit tour des jeux qui me branchent. Evidemment il y a le nouveau Super Mario Bros, et l'inévitable Mario Kart. Forcément, je lorgne aussi l'opus DS de Viewtiful Joe, qui exploite complètement le stylet. Une bonne valeur pour le solo dans les transports semble être Advance Wars, ou Age of Empires. La DS n'étant pas zonée, on peut tranquillement tenter l'import, avec notamment Jump Superstars, un jeu de baston où les héros des grands mangas (One Piece, DBZ, Naruto, etc.) s'affrontent, dans un style Smash Bros. Les captures sont alléchantes, mais c'est en japonais.

Par contre, Metroid me botte pas tant que ça, malgré sa grosse utilisation du stylet, surtout depuis que j'ai vu une vidéo d'une DS Lite avec le deuxième écran niqué après trop de jouage brutal à ce jeu. Je me passerait probablement des programmes d'entrainement cérébral et autres. Et bof sur les genre de RPG mignons comme Animal Crossing et Harvest Moon. Mais je me laisserai surement tenter par Zelda, quand il sortira.

Niveau bidouille, pas grand chose. Malgré la possibilité d'upload de code via Wifi, cela semble compliqué de lancer son petit code fait maison. Je n'espère pas hacker comme c'était le cas avec le Palm, mais c'est peut-être dommage de ne pas pouvoir avoir de developpement par des particuliers ou petites teams indépendantes. Par contre, une bidouille qui a l'air de marcher (ya pas de raison) c'est tunneler le traffic Wifi de l'engin pour jouer à plusieurs avec des DS distantes. En effet beaucoup de jeux ont un mode Wifi local, mais tous ne sont pas supportés par le service Nintendo sur Internet. Enfin, Opera devrait sortir en Octobre son browser pour la DS. Mais toujours aucune application type organizer sous le soleil.

Voila, dans ta gueule Nico.

Petite note pour finir. Quelques problèmes récents m'ont amené à découvrir le nouveau Blogger beta. On n'y fait plus son template HTML à la mano, un cliquodrome est disponible. Du coup, j'ai peur de devoir bosser pas mal pour récupérer mon template actuel, si c'est possible. Mais la bonne raison de migrer c'est l'ajout des catégories, enfin! A suivre.

Sinon cette année je vais donner deux TPs, l'un en Caml sur un sujet cool, l'autre en Java, plus bateau. Toujours est-il que j'ai donc enfin "appris" Java. Entendez par là que j'ai fait un HelloWorld et deux trois broutilles de plus en me basant sur ma connaissance du C++. Comme prévu je trouve ça verbeux et pas sexy du tout. J'ai été surpris par la faiblesse du null qui a n'importe quel type. Unique pensée positive, je vais pouvoir bricoler un peu avec les API Google en Java: Blogger, Calendar, Map...

[AO]mbre

2006-07-28T23:36:00.000+02:00

Commencé peu avant la semaine en Bretagne, j'ai désormais fini le premier cycle des Princes d'Ambre, de Roger Zelazny. Je vous laisse trouver un résumé décent ailleurs. Mon appréciation: c'est bien. Le style m'a fait tiquer par moments, d'autant plus que le traducteur change d'un des cinq tomes à l'autre. Classé SF, ce n'en est pas complètement, et heureusement ce n'est pas complètement non plus de l'Heroic Fantasy, j'aurais pas aimé.

J'ai aimé la façon avec laquelle on rentre dans l'histoire, en suivant le héros, terrien amnésique, découvrant progressivement la réalité fantastique. Ensuite, l'intrigue est bien conçue, ça complote dans tous les sens, ça rebondit et le suspens est captivant.

L'élément SF, ce sont les univers parallèles, les Ombres, entre lesquelles les personnages principaux savent évoluer. Ils forcent les probabilités pour modifier leur environnement au fur et à mesure de leur voyage, glissant petit à petit d'un monde à l'autre, transformant au détour d'une route de montagne la végétation pour se retrouver quelques lacets plus loin sur un sentier côtier. Ils ne peuvent aller vers ce qu'ils ne connaissent pas, et vont d'autant plus vite d'une ombre à l'autre qu'ils connaissent d'intermédiaires. Tout ça devient trop simple et faux quand on avance dans la série, mais cela m'a séduit et je me suis démandé si l'on pourrait créer un jeu autour de ce principe. Mais que faire quand deux personnages font glisser différemment leur environnement? Tout ça, tout ça.

Pour revenir aux bouquins, après les cinq tomes du cycle de Corwin, j'entame le cycle de Merlin. On m'a dit que c'est lassant, je verrai.

KerCycloTour

2006-07-28T22:38:00.000+02:00

De toute évidence, j'avais besoin de vacances -- cf. mon dernier post par exemple. Pour commencer, je suis parti une semaine à vélo en Bretagne avec Estelle. Bref récit sans photos pour l'instant.

Jour 1. Train annoncé en retard à la gare, nous n'avons pas le temps de démonter les vélos sur le quai. Jouer au mécano dans un couloir de TGV se révèle être assez pénible. Quelques heures plus tard on remonte tout à Brest, et on prend la route, sur des pistes cyclables qui font plaisir. Le camping visé est plein, mais on trouve de la place à celui de Portez. Par rapport à l'Irlande c'est pas cher, et le terrain et les équipements sont tip-top.

Jour 2. On longe toujours la côte vers l'Ouest, en passant par la pointe St Mathieu. On remonte ensuite au Nord en se perdant au passage en essayant de prendre des petites routes. Par la suite on deviendra meilleurs à ce jeu là, ou apprendra à se contenter des départementales, assez calmes finalement. Le trajet se termine très près de la côte, en passant par Porspoder, c'est très joli. Pour la nuit le camping de Landunvez nous accueille. Il fait chaud et le dénivellé pénible se confirme: ça monte et ça descend sans arrêt. Les noms des bleds sont distrayants: Kergollo, Kerdéniel, Kervoulou, Kerourien, etc.

Jour 3. Toujours par les petites routes on rejoint Lampaul-Ploudalmézeau, le mignon St-Pabu puis Lannilis. A ce niveau nous avons le malheur d'emprunter la grosse D13 pour rejoindre Plouguerneau. Nous arrivons stressés et fatigués au Camping de la grève blanche, à St Michel, Plouguerneau. Un office du tourisme sur la route nous a fourni le guide très utile des campingséde Bretagne. Il y en a vraiment beaucoup, ce qui nous a tout du long évité le camping sauvage, auquel la Bretagne semble peu propice. On a sûrement été plutôt chanceux de ne pas trouver trop de campings complets sur la route.

Jour 4. On boucle la boucle d'un coup en redescendant droit au Sud vers Brest. Après avoir longé agréablement l'Aber Wrach, on repasse à Lannilis, Coat Meal, les Trois Curés. Route tranquille. L'entrée dans Brest est pénible, surtout qu'en suivant les panneaux "Brest Ports" on se retrouve embarqués sur une grosse artère et super déportés à l'Est vers Guipavas. La route est soit-disant amménagée pour les vélos: en fait on nous laisse le trottoir dont personne ne voudrait, caillouteux et irréguliers, puis carrément le maigre espace entre la glissière de sécurité et les taillis mal taillés. On descend finalement sur le port pour se consoler avec une bière et embarquer dans la navette pour Camaret. On se fixe au Camping municipal, spacieux sympa et bon marché, pour quatre nuits.

Jour 5. Enfin posés, on se repose ? Non, on part pour une petite boucle vers la pointe des Espagnols. La route est jolie, le point de vue final pas si formidable, mais le tout est carrément sportif. Le soir nous nous offrons un plateau de fruits de mer pour bonne conduite spartiate. C'est cher mais délicieux, il y en a plein, du bon crabe, de belles huitres, miam. Deux ombres: pas de coquillages ce jour-ci, comblés par un excès de langoustines, et un pain moyen en quantité insuffisante. On découvre le lendemain à l'office du tourisme l'existence d'un label de qualité pour les plateaux de fruits de mer qui aurait garanti contre ces deux inconvénients. Deux restaurants du port, à peine plus chers, l'avaient. Le prochain plateau sera encore meilleur!

Jour 6. Notre navette pour Ouessant est annulée, on part vers le Cap de la Chèvre à la place. Encore une fois, de belles côtes, il y en a marre! Mais c'est joli, surtout la plage de l'Ile Vierge qu'Estelle me fait découvrir. Splendide et bien cachée, donc pas trop peuplée.

Jour 7. Mauvais temps annoncé, nous n'avions rien prévu. En fait il fait beau, et on part tester la plage du Veryarch. Courte baignade, petites piqures de vive pour tous les deux. On suit le GR à pied pour aller à Camaret. La navette pour Ouessant n'est toujours pas réparée, on décide de rentrer un jour plus tôt, dès le lendemain. Dîner à la bonne creperie Rocamadour, un rhum intéressant à la rhumerie, et une petite stout au pub d'à côté, à écouter des musiciens probablement trop expérimentaux pour leur public en vacances.

Jour 8. On met les vélos dans le bateau. Arrivés à la gare nous sommes agréablement surpris d'être autorisés à rentrer en avance sur le quai pour démonter les vélos. Mais on nous envoie au bout du train où on ne trouve pas notre voiture. En fait elle était en queue, à l'autre bout. On perd notre avance pour démonter les vélos, ce qui se fait dans l'urgence. Le contrôleur refuse ensuite qu'on les case dans un fourgon vide dont nous avait parlé le conducteur du train. Le fourgon reste vide tandis que nos deux vélos, rejoints par un autre en cours de route, encombre le passage. Nous devons les déplacer dans les gares où le quai est à droite pour laisser les gens circuler. Arrivés à Paris on remonte une dernière fois les vélos, affronte la circulation. Une douce froide plus tard, posés sur un vrai lit, ça va mieux :p

La morale. Le vélo en Bretagne, c'est chouette. Mais pas encore idéal, avec un gros point noir au niveau du train. Apparemment les nouvelles rames en cours de construction devraient être équipées pour transporter des vélos non démontés. Ce serait déja le cas des Thalys, qu'on testera peut-être l'an prochain.

LICS submission

2006-07-04T20:15:00.000+02:00

Dr. Simon, assisted by PhD students David and Andrew recently submitted a paper at the Lazy Idle Computer Scientist 2006 Conference: Balloons considered harmless. Here is a short abstract.

We study the categorical structure of balloons and the container behaviour they get when blown. This structure implies some simple observations, which however haven't been explored yet as far as we know: ballons can be nested in several ways. See below the representation of f(g,h) and the triple nesting f(g(h)) -- a spectacular performance by Dr. Simon.

Then we point out that the notion of blowing a balloon is self-dual, as demonstrated on the picture of Andrew "blowing" a balloon from the outside, and can be generalized smoothly to the filling of a balloon with anything, as demonstrated by Andrew blowing ballons with his crazy ideas.

More trivial uses of the balloons-as-containers paradigm include storage of useful items, like whiteout, money, water, ice tea cans, mobile phones, pens, and so on -- we let the reader guess in which balloon is which item.

More serious applications shall be explored. For example a balloon can be used as a security device allowing one to know that nobody has used his mouse -- however, some details need to be worked out as limited interactions with the mouse are still possible.

Another interesting application is the levitation of balloons. By embedding an magnetic device instead of the usual Helium in a balloon, we've been able to have it fly. Two efficient techniques to initiate the process have been developped. This involves a new theory of which the basic principles and properties are sketched below.

DADVSI (suite..)

2006-06-30T20:17:00.000+02:00

Aujourd'hui a été votée la loi sur le Droit d'Auteur et les Droits Voisins dans la Société de l'Information, telle qu'écrite par la CMP. EUCD.info a réagi immédiatemment, et fournit aussi un résumé des péripéties en anglais.

On peut aussi lire le long compte-rendu de la journée à l'Assemblée Nationale pour un rappel des principaux problèmes -- et pour voir les auteurs de la loi s'auto-glorifier. Pour ma part j'y remarque un passage sur la procédure d'urgence:
M. le Ministre - [...] Dois-je rappeler que si le Gouvernement, ces derniers dix-huit mois, a déclaré six fois l’urgence, le gouvernement de Lionel Jospin, dans le même laps de temps, l’avait déclarée dix-huit fois ? Que ceux qui nous font ce reproche aient donc un peu de mémoire ! (Applaudissements sur les bancs du groupe UMP)
M. Patrick Bloche - Il n’y avait pas de ministre parjure dans le gouvernement Jospin !
A mon avis la procédure était avant utilisée pour ce pour quoi elle est faite: quand une loi doit passer vite mais ne fait pas débat. L'opposition critique plusieurs fois par la suite la procédure en ce sens, et ne sont pas contredits.

Je n'ai pas grand chose à rajouter, c'est triste sur le fond et la forme. Mais tout ça n'est probablement pas fini. En attendant, la Prejudice Map va devoir changer ce pour quoi les français sont connus: politique de bas-étage soumise aux lobbys, lois absurdes et répressives.

Moi

2006-06-29T00:45:00.000+02:00

Finalement je suis pas si mal comme mec. D'après Earth Day Footprint je suis un gros parasite mais moins que les autres:

CATÉGORIE HECTARES
ALIMENTATION 1.3
TRANSPORTS 0.5
LOGEMENT 0.6
BIENS ET SERVICES 1.2
VOTRE EMPREINTE TOTALE 3.6

EN COMPARAISON, L'EMPREINTE ECOLOGIQUE MOYENNE DANS VOTRE PAYS
EST 5.3 HECTARES GLOBAUX PAR PERSONNE.

IL Y A 1.8 HECTARES GLOBAUX PRODUCTIFS PAR PERSONNE DANS LE MONDE.
SI TOUT LE MONDE VIVAIT COMME VOUS ON AURAIT BESOIN DE 2 PLANETES.

Sinon je me suis rendu compte que dans la recherche, yavait pas que les étudiants pour procastiner -- comme nous l'apprend si bien PhD Comics (que je ne lis malheureusement plus régulièrement depuis qu'ils ont supprimé leur flux RSS). Aujourd'hui on a discuté à quatre pendant trois heures, je peux vous dire qu'on a caressé un paquet d'idées impressionant, et vous garantir que le quart sera exploité au maximum. Cela dit ça me parait normal. On pourrait faire ça, ouais mais est-ce que c'est vraiment intéressant, tiens au fait vous avez vu que ça ressemble à ça, et dis donc comment t'expliques ça, heu avec tout ça on se décide pas sur la question initiale, ouais bon, etc.

Icelandair

2006-06-27T11:41:00.000+02:00

J'ai trouvé cette photo sur Flickr qui montre bien un genre de paysage bizarre qu'on peut voir défiler depuis un vol Icelandair vers le Nord des Etats-Unis -- yen a toute une variété.

Des cadences

2006-06-26T22:23:00.000+02:00

Une semaine chargée s'annonce avec un invité et un afflux de boulot conséquent. Parfois il faut s'y mettre, mais j'en ai marre de bosser par ci par là sans publier. Je veux pas faire l'obsédé de la publi, mais il m'en faudra tôt ou tard, et c'est embêtant de regarder en arrière ce qu'on a fait sur un an et de ne voir que des brouillons éparpillés. Bon j'exagère, on a significativement avancé sur Bedwyr, c'est déja ça.

Sans Geek Radio, liquidsoap se fait la main sur Dolebraï la radio libre. Quelques segfaults bizarres restent à étudier, c'est nouveau et peut-être lié aux metadatas crados de la playlist -- il faut toujours un coupable. Toujours est-il que Savonet va bientôt publier un paquet de paquets, ça va faire du bien de sanctionner tout ce boulot aussi.

En dehors de ça, Dolebraï n'avance pas beaucoup. Pas de nouvelle musique, pas de système de gestion des playlists à l'horizon.. Comme j'ai dit j'ai largement de quoi m'occuper, je vais pas m'investir corps et âme pour mettre le tout en place, et voir un peu comment les choses évoluent. Le temps n'est pas élastique, dit mon papa, et j'en ai marre d'avoir l'impression de passer mes journées à geeker.

Par contre j'écoute beaucoup de musique ces temps-ci, en vue d'enrichir les playlists. En particulier je m'essaie à la conso de podcasts. Je teste PeaPod pour télécharger les nouveautés sur mon Palm. J'avais d'abord envisagé de faire un script Ruby minimal mais in `_parse'.../format.rb:253: [BUG] Segmentation fault... Agacé par cette nouvelle démonstration violente d'instabilité je me suis tourné vers Python et le module feedparser qu'a l'air assez nickel. Pour finalement découvrir PeaPod qui est construit sur ces outils. J'ai dû fixer un petit problème avec les URLs mal encodées de certains feeds et j'en ai profité pour noter que le code est pas tout joli joli.. menfin si ça marche je serai content. J'attends de voir comment ça marche à long terme.

J'ai été étonné de la facilité avec laquelle on trouve des podcasts qui diffusent de la musique Creative Commons. Pour ce que j'ai écouté ce matin la qualité est au rendez-vous, en particulier Revolution (pas ratable sur google) avec en prime une vraie voix de speaker à passer la nuit avec. Tout ça contraste avec l'absence manifeste de webradios diffusant de la musique libre. Peur des problèmes légaux, difficulté technique, ou préférence des auditeurs pour le podcast ? Je pense que les deux premiers points sont vrais, mais le second me taraude quand même... reste-t-il beaucoup de gens pour bosser/glander en écoutant la radio ? Dans les transports on écoute la FM, ou des podcasts. Au bureau, on écoute rien. Le soir, on regarde la télé, joue, regarde un film, aucun intérêt pour un fond sonore discret pendant que la tête travaille.

Au final, le podcast et la webradio sont sûrement complémentaires. Enfin, j'espère. Pistes pour Dolebrai: avoir un podcast des nouveautés dans la playlist, et diffuser les émissions des bons podcasts comme Revolution ?

DADVSI et démocratie

2006-06-24T13:32:00.000+02:00

Je rappelle ici brièvement l'histoire du projet de loi DADVSI, je recommande la lecture des articles d'EUCD.info pour plus de détails, et la suite des évenements.

Il y a quelques mois le ministre de la culture RDDV propose le projet de loi DADVSI (Droit d'Auteur et Droits Voisins dans la Société de l'Information), et le fait passer en procédure d'urgence, dans le style musclé de notre gouvernement de merde. Le sujet fait moderne mais le contenu est assez conservateur: grosse peur du téléchargement libre, du piratage, volonté de contrôle des internautes, et grosse peur des puissantes maisons de disque qui tentent de réfréner un mouvement qui les force plus ou moins à changer de modèle commercial..

Plus précisemment le texte propose: de nouveaux moyens de sanctionner le piratage, une modification du droit d'auteur enlevant notamment au client le droit à la copie privée, une obligation pour les logiciels d'échange de données (appréciez le flou de l'appelation) de se doter de DRM (Digital Rights Management, verrou logiciel sur les données), des sanctions plus lourdes pour le cassage de ces verrous... Les consommateurs sont effrayés, les auteurs et utilisateurs de logiciels libres aussi. Les DRM sont par essence des procédés non publiés, ils seraient inopérants sans ça -- dans le monde du logiciel, on peut tout copier, c'est comme ça. Du coup les fichiers achetés en ligne ne fonctionnent que sur un nombre restreint de balladeurs. Exemple type: la musique achetée sur l'iTune Music Store ne peut être écoutée que sur un iPod. Evidemment, tout le monde casse les DRM pour écouter sa musique comme bon lui semble, la FNAC a même diffusé à une époque des instructions dans cette direction.

Bonne surprise lors de la lecture à l'Assemblée Nationale. Bon nombre de députés se sont emparés du sujet, dans l'opposition mais aussi à l'UMP, et se sont informés des risques des DRM pour la concurrence, l'interopérabilité, ainsi que des risques pour les logiciels libres. Les débats sont électriques, et au final la loi ne ressemble plus vraiment au projet initial, avec notamment une brêche laissant la porte ouverte au projet de licence globale du PS, et un amendement imposant l'interopérabilité des DRM, ce qui a fait très peur à Apple.

A ce stade le ministre est déja fustigé par bon nombre de députés, la procédure étant douteuse en plusieurs points -- je passe les détails. Il promet de lever la procédure d'urgence en cas de désaccord majeur entre les deux chambres. Malheureusement, la lecture au Sénat inverse la tendance, supprime l'exigence d'interopérabilité et met en danger les auteurs de logiciels libres. Surprise, c'est même un amendement PS.

On appelle le ministre a lever l'urgence comme promis, il n'en fait rien. On passe donc à la case CMP (Commission Mixte Parlementaire): douze députés et sénateurs doivent régler le différent. Les députés et sénateurs sont triés sur le volet, les dissidents écartés. Et ils arrivent carrément avec 55 nouveaux amendements sous le bras. Les membres de l'opposition voient rouge, demandent un délai pour étudier ces amendements, et quittent la réunion face au refus du président. Inutile de dire que le texte est désormais alarmant.

Petite lueur d'espoir, tout n'est pas fini. Les deux chambres doivent encore voter le texte, mais ne peuvent plus le modifier. J'espère vraiment que l'Assemblé va nous montrer encore une fois que la démocratie en France a son mot à dire, que les députés UMP vont voter en leur âme et conscience au lieu de suivre le groupe et le gouvernement.

Je suis complètement atterré par cette histoire, le manque de sérieux du gouvernement, la prévalence des lobbys sur la démocratie. Il faut voir comment le ministre, en bon élève de notre premier ministre, s'obstinait dans ses magouilles malgré l'indignation des députés. En premier lieu, la procédure d'urgence est une aberration, complètement injustifiée pour un sujet comme celui-ci. La raison invoquée était la nécessité de modifier la loi avant la fin 2005 pour s'aligner sur la loi européenne. Mais j'ai lu récemment que la commission européenne envisageait maintenant de remettre en cause la loi autour des DRM, constatant les risques pour la concurrence. Enfin je suis désolé du manque de couverture du sujet. Rien de visible dans les journaux aujourd'hui au sujet des récents évenements.

Mon monde

2006-06-23T01:46:00.000+02:00

Après avoir cherché à recueillir des infos sur certains endroits que j'ai parfois besoin d'indiquer/recommander aux gens, essayé quelques services décevants, j'ai finalement regardé comment on utilise la Google Maps API.. et c'est facile. Voici donc mon monde.

Autre hack de la soirée: récupérer les nouveautés Jamendo sous forme de playlist. Jamendo propose des flux RSS des nouveaux albums. On préferera un podcast, ou une simple playlist au format texte.. pas de problème:

#!/usr/bin/ruby

require 'xml/libxml'

rss = 'http://www.jamendo.com/fr/?archive_encoding=ogg3&audio_encoding=ogg2'+
'&format=rss2&g=poprock&linkto=playlist&m=backend&num=20&type=albums'

XML::Document.file(rss).find('//rss/channel/item').each do |node|
node.find('link').each do |node|
puts `wget '#{node.content}' -O - 2> /dev/null`
end
end

Compact non ? C'est ma façon de prospecter pour Dolebrai, qui se monte plus que jamais..

Anarchie

2006-06-18T11:55:00.000+02:00

Quelques trucs qui ont retenu mon attention ces derniers temps...

D'abord je recommande à tous de se tenir au courant des évolutions du projet de loi DADVSI, le coup final pourrait se jouer demain et c'est pas joli joli.. Certes ça déprime encore plus sur la politique en France de nos jours et notre gouvernement actuel. Le site EUCD.info, impliqué dans la lutte contre certains aspects préoccupants du projet de loi, est une très bonne source d'information -- et ya un flux RSS dispo pour ne rien rater.

Sinon Geek Radio a été coupée pour cause de grosse chaleur dans la salle des machines. Après 8 jours d'uptime, on sentait bien qu'un pas de plus vers un liquidsoap stable avait été franchi, mais on aurait aimé voir l'uptime monter encore un peu..

En échange une version de test de Dolebraï la radio 100% libre est en place grâce aux serveurs de radio Pi. Compte-rendu de la bièréunion d'avant-hier à propos de cette radio:

Rassembler de la musique, beaucoup plus que maintenant.

Dès qu'on sera sur un serveur où on a de la place, fonctionner en local, en téléchargeant les fichiers, retagués avec des infos de provenance afin de promouvoir la donation à l'artiste original. Ainsi on pourra utiliser l'indexeur bubble de savonet pour créer la BDD.

Site web: strict minimum pour l'instant, puis afficher les morceaux passés, peut-être les playlists, puis permettre le feedback des utilisateurs. Le site sera en Python/Django ou PHP. Sam a proposé Ocsigen..

Liquidsoap: le script sera articulé par plages thématiques identifiées par des jingles de transition, on utilisera aussi des jingles horaires en superposition sur le son, et la coupure de blancs... faut justifier l'outil, quoi :)

On met en place une version de test de la radio sur les serveurs de radio Pi, et du site sur le serveur de Nico.

On migre sur dedibox dès que c'est décent, avec un objectif de rentrer dans les frais de location du serveur sous 5 mois, par donations ou sponsoring.

Finalement obtenir un nom de domaine, installer un serveur mail..

Autres liens en vrac.. HOP, un framework de webdev en Scheme, développé par l'INRIA. LULU un site d'auto-édition: chacun peut s'éditer et y mettre en vente ses livres (et autres) et garder 80% du bénéfice. On y trouve de tout.

Sinon, j'ai lu la morale anarchiste de Kropotkine. J'adhère à la morale, très athée et rationnelle. En gros l'homme a une notion de bien et de mal, naturellement, et les notions imposées par la religion ou la loi masquent la vérité au profit de certains. L'auteur souhaite effacer cette source d'inégalités. Bien sûr il y a une super dose d'utopie derrière ça. D'ailleurs l'auteur ne répond pas à une question. S'il dit bien que l'homme, comme tout animal, a une notion de bien/mal fondée sur la survie de l'espèce, il n'explique pas pourquoi l'homme, il me semble, dérive plus facilement que les autres animaux du chemin du bien. C'est court et ça se lit bien, et j'apprécie beaucoup de voir une morale se dégager malgré l'absence d'élement transcendant. Finalement c'est comme une bonne logique, il suffit d'observer les règles du système pour le comprendre, pas besoin de sémantique :p

Temps de cerveau disponible

2006-06-08T17:12:00.000+02:00

On m'a raconté aujourd'hui comment certaines personnes mal intentionnées réquisitionnent les cerveaux des internautes de façon assez amusante, et moins passive que TF1.

Certains sites, fournisseurs de service mail ou d'espace de stockage en général, ont récemment mis en place des procédures d'enregistrement plus compliquées censées éviter les enregistrements massifs par robots. Le truc du moment c'est les textes déformés, que les humains reconnaissent plutôt bien, et les ordinateurs assez mal. Qu'à cela ne tienne, il existe une parade: plutôt que de s'acharner sur ce difficile problème, on exploite les humains si doués. Voici le système qu'on m'a décrit: le robot commence une inscription, récupère l'image à reconnaitre, attend un gogo sur un site porno, lui réclame une inscription avec la même image à reconnaitre, et utilise sa réponse pour terminer la première inscription. Visiblement ya assez de gogos pour que cela fonctionne.

Même genre d'histoire sur Slashdot, où l'on attaque une entreprise par social engineering totalement passif: rien besoin de savoir, sauf que les employés sont curieux -- et ne font pas la différence entre une image et un exécutable.

Puisqu'on parle de temps de cerveau, je (re-)lis à l'instant comment l'Education Nationale vend celui des petits français à Microsoft: dénonciation de l'APRIL.

Sinon, si vous avez du temps à perdre...

Tes lacets sont des fées

2006-05-29T17:13:00.000+02:00

Café à la main et FIP dans les oreilles, je vais enfin écrire un paquet de trucs accumulés.

D'abord je suis rentré de Minneapolis. J'ai écrit un post sur mon Palm mais je ne sais toujours pas comment le rapatrier sur l'ordi, pas envie de bidouiller. Je vous passe donc le récit d'un voyage plutôt banal, et mon second émerveillement au dessus du Groenland.

Sur le retour j'ai lu Farenheit 451 de Ray Bradbury, et je le recommande chaudement. Roman d'anticipation bien sûr visionnaire, décrivant un monde où les gens ne prennent plus le temps de se parler, de penser, de rêver, mais s'abrutissent à coups d'images, de sons, de vitesse. Le protagoniste est un pompier, chargé de bruler les livres, fauteurs de troubles, de questionnement et de tristesse. Le bouquin ne sombre pas dans une critique trop longue et rabat-joie de cette caricature de notre monde pressé. Il nous appelle au rêve et à l'émerveillement, à une réflexion sur l'homme, tout cela dans ce roman court et bien écrit. Enfin, Bradbury finit sur un note positive, un espoir en l'homme dont on a parfois bien besoin.

Ces deux dernières semaines nous avons amélioré liquidsoap. L'observation des plantages d'une Geek Radio plus stressée nous a permis de corriger plusieurs bugs. On s'approche encore de la stabilité. Le programmation de Geek Radio a aussi gagné en variété, avec des programmes thématiques agréables et bien fournis. Comme je commence à écouter quelques podcasts je me suis dit qu'on pourrait utiliser ces sources de nouveautés sur Geek Radio, passer tous les jours à 22h les dernières nouveautés de tel netlabel ou de tel DJ. Il suffirait d'un petit script à interfacer avec liquidsoap à coups de protocole et callback de diffusion. A l'occasion je ferai ça vite fait en Ruby, les outils sont tout prêts pour un petit frère de bubble.

Pour finir sur liquidsoap, il est encore tôt pour promettre un release proche, d'autant que je ne manque pas de boulot ces jours-ci. Mais on s'approche d'un produit utilisable de qualité. J'ai eu vent via linuxfr du BarCamp Paris du 10 juin. Le concept de non-conférence sans spectateurs (que des acteurs) me plait bien, et je suis tenté de présenter le projet Savonet là bas. Mais ça risque d'être un peu short à préparer.

Enfin je voulais de nouveau pointer le blog des langages de programmation, Lambda The Ultimate. C'est une bonne source de news, regroupant points de vue "académiques" et "pragmatiques". Ces jours-ci on voit un regain d'activité longtemps attendu, avec l'arrivée de nouveaux éditeurs. Aujourd'hui j'ai lu un slideshow (HTML+Javascript) présentant Javascript 2. Ça fait plaisir: tout en restant bien sûr un langage pragmatique, il évolue vers plus de structure, empruntant à Python mais aussi à la programmation fonctionnelle statiquement typée. Cela semble plus que raisonnable pour favoriser l'utilisation de Javascript sur de gros projets.

Un serveur très select..

2006-05-21T22:41:00.000+02:00

Le retour du post geekesque !

Il y a quelques années il me semble avoir lu dans Linux Magazine un article expliquant comment programmer en C un serveur léger et rapide sans threads. Jusque récemment, liquidsoap (qui offre quelques interactions via une interface telnet) utilisait un serveur à base de threads: un thread écoute sur le serveur et accepte les clients, lance un nouveau thread par client pour traiter ses requêtes. C'est mauvais: au bout de 30 clients on a 30 threads, ce qui plombe l'application; et en plus les clients ne sont pas vite servis, la création de leur thread étant coûteuse. J'ai enfin changé ça, en utilisant l'appel système select pour attendre un ensemble d'évenements sur des sockets. C'est ultra simple et ça marche impeccable.

L'article de Linux Mag aurait pu être écrit en Caml au lieu de C: au lieu de fournir un exemple de serveur, on peut en programmation fonctionnelle implémenter un serveur générique se chargeant d'ordonnancer des pseudo-threads représentés par des fonctions. Je vous le livre ici. Accessoirement, j'ai cherché à trouver ce genre de code tout prêt sur le net avant de l'écrire. Peut être que j'épargnerai du boulot à quelqun.

type task =
  | Read    of (Unix.file_descr * (unit -> unit))
  | Write   of (Unix.file_descr * (unit -> unit))
  | Special of (Unix.file_descr * (unit -> unit))

let scheduler init =
  let read    = ref [] in
  let write   = ref [] in
  let special = ref [] in
  let add set a = set := a :: !set in
  let add = function
    | Read    (s,f) -> add read    (s,f)
    | Write   (s,f) -> add write   (s,f)
    | Special (s,f) -> add special (s,f)
  in
  let process set sockets =
    (* Events are triggered on a list of sockets.
     * Execute the corresponding handlers, and remove them from the set. *)
    let f = List.map (fun s -> List.assoc s !set) sockets in
      set := List.filter (fun (s,_) -> not (List.mem s sockets)) !set ;
      List.iter (fun f -> f ()) f
  in
    init add ;
    while true do
      let r,w,x =
        Unix.select
          (List.map fst !read) (List.map fst !write) (List.map fst !special)
          (-1.)
      in
        process read r ;
        process write w ;
        process special x
    done

Pour les curieux le code complet est sur le SVN de Savonet, avec enregistrement et traitement des clients..

Mall of America

2006-05-21T03:57:00.000+02:00

Je cherche des petits cadeaux pour Lucie et Cyrille. Mon maître de thèse m'a signalé qu'une des attractions du coin est Mall of America, le plus grand centre commercial des Etats-Unis. Je me dis que c'est l'occasion de bouger un peu. En plus, pour y aller je visite aussi le tramway, c'est folklo. Sur le retour j'ai même eu droit à un trajet en bus, encore plus folklo avec un conducteur un peu foldingue qui me donnait pas trop confiance sur la destination, et comme compagnons ceux qui n'ont pas assez de pognon pour se payer une caisse.

Mall of America, c'est grand. Trois ou quatre étages de galeries, et au centre un parc d'attraction. Mais putain qu'est-ce que c'est nul. Des magasins de merde, des magasins de pouf... pas l'ombre d'un souvenir ou d'un truc potable à acheter, pas l'ombre d'une librairie décente, une honte vu les proportions de l'endroit. Au bout de deux heures je me casse, me jurant de ne plus écouter mon maître de thèse pour les questions touristiques.

Descendant du tram je décide de trainer en ville, ce qui ne me remonte pas vraiment le moral: le business center est mort comme tout un samedi soir. Au bout de quelques blocs, j'arrive quand même à viser un coin animé et là miracle, je trouve une grande librairie. Des livres, des comics, des DVD, miam. Elle est encore ouverte. Peu après que je rentre une annonce prie les client jeunes de sortir, et demande à ceux qui restent d'être en mesure de justifier leurs 21 ans. Je me dis qu'ils vont ptêtre ramener de la bière et des filles.. Finalement non, et pour me consoler je me suis acheté Jackie Brown. L'ambiance loose de mon séjour, l'hôtel un peu glauque, le centre commercial, les gens mornes, tout ça me fait trop penser à ce film. Et à The Big Lebowski aussi, mais cui-là je l'ai vu ya pas longtemps.

Descendant du bus fou qui me ramène dans mon quartier, je décide aussi d'enfin visiter le liquor shop. Je choisis un simple pack de Corona parmi tout l'alcool qu'on y trouve. A la caisse je saute au plafond devant le prix, doit y avoir au moins 70% de taxes. Et pour faire couleur locale, on me demande ma carte d'identité et m'emballe le pack de bières dans un sac en carton marron. Dernière péripétie: ouvrir les bières sans outil approprié. Je sais que certains font ça avec leurs clés. J'y arrive aussi, mais je me suis salement coupé le doigt au passage...

Quelle aventure, ce voyage.

Trio

2006-05-19T16:58:00.000+02:00

Le créneau chanson française est en place sur Geek Radio. Du coup j'entends "Je me tire" de Tryo. J'ai toujours eu un problème avec cette chanson:
Tire-lui une balle,
ce mec-là t'a fait du mal,
ta vengeance est normale,
l'Etat ne peut pas l'accomplir..

Moi

2006-05-18T04:32:00.000+02:00

Cher lecteur, tu te demandes comment je vais, ce que je mange et si mes selles sont bien formées ? Encore une fois, tu seras servi...

L'applet météo de Minneapolis bat celle de Paris depuis deux jours. Il fait grand soleil ici, c'est très agréable. Je suis de fort bonne humeur, etc. J'ai mangé un bo-bun pas mauvais, des sushis pas super bons, un plat de pâtes délicieux à midi et une pizza chère (pour ici) mais fort bonne aussi ce soir. Je ne vous ferai pas de critique culinaire du genre de sandwich grec au rosbiff qu'ils vendent pas loin d'ici, et je suis sûr que vous me comprendrez même sans avoir vu la photo choquante du truc.

Récemment, j'ai acheté un pot de glace Ben&Jerry's au café. En vrai, le café n'est que le goût de la crème, mais ce serait trop léger de s'arrêter à la crème glacée, trop simple. La glace cache en fait de bons gros morceaux de caramel.. pouah. Mon frigo débloque et a de toute façon laissé fondre le pot de glace dans le compartiment congélo; dans le même temps il glace mes bouteilles d'infâme root beer dans le compartiment normal. Au fait, à ma troisième bouteille de cette boisson (faut bien les finir) j'identifie enfin le goût: Hextril, le bain de bouche...

Dans ma chambre j'ai la télé, pub à gogo en général, et pour le film Da Vinci Code en particulier. J'ai aussi vu un reportage pourri sur l'Opus Dei, et des croyants qui s'insurgent de ce que le livre raconte, mélangeant réalité et fiction en faisant croire aux gens que l'Eglise se fout d'eux... en guise de réponse j'aime bien un truc que j'ai dû lire sur le net: il devrait y avoir un avertissement au début de la Bible comme quoi c'est une fiction. Plus sérieux, j'ai vu Bush raconter qu'il va fliquer plus aux frontières, et j'ai appris qu'un Etat interdit maintenant aux couples non mariés la garde de plus d'un enfant.

J'allais oublier la nouvelle du jour: Gopalan m'a emmené dans un magasin de bouffe assez grand. J'y ai trouvé du beurre de cacahète, des cookies.. et surtout des fruits qu'ont l'air bons ! Mais ce soir je crois que je vais opter pour le microwave pop-corn, plus couleur locale. Parlant de beurre de cacahuète j'ai entendu dans une série télé de fou (mix de Starsky et Hutch et de Laurel et Hardy) un dicton qui me plait beaucoup: life is like peanut butter, some like it chunky, some don't...

Pendant ce temps là, ça bosphore.. C'est super productif de discuter les choses à fond. Quand on creuse des trucs qui paraissent évidents on s'aperçoit qu'il y a des détails délicats à prouver... des détails peut-être un peu chiants, mais à prouver quand même. A force de discussions je me retrouve donc avec une preuve à écrire, une optimisation à programmer, une autre optimisation délicate à concevoir... Ce voyage me fait décidemment bien bosser. Mais afin de me remettre en question comme il se doit, je m'astreins avec regret à bidouiller la radio le soir dans ma chambre ;p

Le temps passe plutôt vite. Déja cinq jours sur dix. Prévoyant mon retour, je me laisse pousser la barbe. Ce week-end je vais faire des UV, m'acheter un turban et apprendre l'arabe, histoire d'avoir des péripéties douanières à raconter sur mon retour, qui sera sinon probablement bien monotone par rapport à l'aller.

Spicy Thai & Dark Apple

2006-05-17T20:32:00.000+02:00

Hier j'ai bouffé dans un petit restau thai. C'était très bon mais très épicé. A part ça j'ai découvert un quartier super sympa. Beaucoup de verdure, des écureuils qui courent et même un petit lapin... des maisons d'étudiant, nommées genre δνε, faudra que je pige un jour. Notes folkloriques du jour: à l'entrée de l'opéra on lit "no guns"... en couverture du botin une pub pour un cabinet d'avocats "call 1-888-NOT GUILTY"...

Dans un registre complètement différent, je suis assez sidéré de la rapidité avec laquelle Apple sombre du côté obscur aux yeux de la foule, son image de marque devenant de plus en plus floue.. En partie la rançon du succès, mais aussi pour de vraies raisons, notamment leur pratiques de vente liée avec les Mac, l'iPod et l'iTunes Music Store, ainsi que leur pression sur les politiques français pour l'impunité des DRMs. Je lis récemment un post super alarmant: ils ferment le source du noyau sous OSX. Le genre de truc qui te fait aimer la GPL, pour sa contamination aux forks. En plus ils envisageraient d'utiliser Trusted Computing, le nouveau nom de Palladium si j'ai bien suivi... Ca pue sévère.

Newline-sensitive parser

2006-05-16T21:08:00.000+02:00

Pour préserver le côté geek de ce blog il faut que je vous parle d'une petite trouvaille qui me plait bien. Les langages comme Python ou Ruby ont réussi à abolir le point virgule. Pour cela leur syntaxe se doit de tenir compte des retours à la ligne, au moins: il faut différencier les deux bouts de code suivants.


# Exemple 1
objet.methode
(1,2)
# Exemple 2
objet.methode(1,2)

Le parser de Python est compliqué par la prise en compte de l'indentation comme délimiteur de blocs. Celui de Ruby devrait être plus simple, mais je peux pas vous dire j'y pige rien. Toujours est-il que jusqu'à hier j'avais pas de solution acceptable pour Liquidsoap, car je voulais coller à l'architecture classique à base de lex/yacc -- simple et donc compréhensible, pour le codeur comme l'utilisateur. Voici la recette pour alléger votre langage sans introduire d'ingrédient dangereux pour la santé.

Au niveau du lexer, on distingue le token VAR (symbole de variable) de VARPAR qui fusionne une variable avec une parenthèse ouvrante séparée par des espaces. Ce sera le seul endroit où un retour à la ligne est distingué d'un autre espacement. Grâce à ce nouveau token on distingue proprement les deux exemples cités plus haut. Mon premier exemple de code apparait au parser comme VAR PAROPEN EXPR COMMA EXPR PARCLOSE, le second comme VARPAR EXPR COMMA EXPR PARCLOSE.

Root Beer & Indian Music

2006-05-16T20:28:00.000+02:00

Je commence pas très bien ma journée d'hier. Petit dejeuner pas super, salle petite et crasseuse, café lavasse et beignets trop lourds. Au lunch, pâtes trop lourdes, trop de fromage, trop de crème. Autour de 17h je décide de me faire un apéro en solo, chips et bière, pour me réconforter avant d'aller voir un concert de musique indienne.

Je connais qu'un magasin de bouffe par ici. Facile de trouver des chips, les paquets sont géants par contre, ainsi que la dip sauce. J'en profite pour embarquer du pop-corn micro-onde, c'est pas mauvais et rien que le regarder gonfler est un plaisir. Et deux pommes, qui s'avèrent par la suite être assez mauvaises. Par contre je trouve pas grand chose niveau bière, juste un pack d'un machin appelé root beer, avec un packaging à l'ancienne. J'ai vite réalisé mon erreur. La root beer n'est PAS de la bière, n'en achetez JAMAIS. Ca ressemble plus à du sirop pour la toux pétillant, ou du dentrifice liquide qui fait roter. Pouah.

Gopalan m'explique dans la voiture, en route pour le concert, que la vente d'alcool suppose l'obtention d'une license, et que la loi du Minnesota interdit de plus la présence de deux points de vente d'alcool à moins de quelques centaines de mètres l'un de l'autre. Faudra que je fasse un tour au liquor shop du coin.

Le concert était super par contre. Ca commence assez traditionnel, mais ça dérape assez vite sur du très inattendu. La musique nord indienne est traditionnellement portée sur l'impro, les mecs en profitent à mort. Le show est axé sur les percussions, qui sont exploitées de façon impressionante, c'en est presque mélodique. Je peux pas en dire beaucoup plus, vous aviez qu'à écouter. Le genre de spectacle capable de bouleverser un point de vue sur les percus... mais moi j'avais déja vu un solo de batterie au parc floral qui reste quand même complètement mythique dans ma tête. A part ça c'était rigolo, la salle était forcément pas mal remplie d'indiens, dont pas mal étaient habillé plus ou moins traditionellement. Je n'ai qu'un aperçu biaisé, mais il me semble que les US c'est quand même pas mal niveau intégration. Bon ils sont en train d'augmenter encore le fliquage à leurs frontières, les causasiens flippent de la montée des hispaniques, parait-il.. mais le jour où on diagnostiquera ça en France, ce sera déja un progrès.

Après j'ai mangé une pizza même pas mauvaise. Ce matin il faisait super beau. Je me suis aperçu que je pouvais prendre mon petit dej sur une terrasse. C'est au dessus du parking, mais c'est le paradis à côté de la salle. Le jet lag s'atténue, je commence à me lever tôt, j'ai plus besoin de me gaver de donuts pourris le matin et je me fais au café dilué. La journée commence bien. Au lunch je me rattrape avec un vrai espresso, qui en plus est pas du tout cher par rapport à Paris, $1.4 soit moins de $2 après les taxes et le pourboire. Bref, je commence à me plaire ici. Mais vivement la cuisine française quand même.

The Next 700 Programming Languages

2006-05-15T05:59:00.000+02:00

J'ai lu récemment The Next 700 Programming Languages, un article de Landin, datant de 1966. Parce que le titre me plaisait bien, et qu'on m'a dit que c'était une référence dans le domain de la conception des langages de programmation. Vu de 2006 ça parait un peu simpliste, mais l'auteur ébauche en réalité des idées très nouvelles et très importantes. Ca me fait réaliser que l'informatique (j'ose pas dire la science, mais je le pense à moitié) avance plutôt par des déplacements lents de perspective que par des découvertes brutales et techniques. Dans cet article, Landin inspire de nombreux langages de programmation modernes, dont Haskell et la famille ML. Il développe un langage abstrait (ISWIM pour If you See What I Mean) réellement de haut niveau, dont le sens est clairement défini. Pour preuve de cela il exhibe des équations exprimant des propriétés simples des programmes, essentiellement des règles de substitution. Je n'en connais pas assez pour l'affirmer vraiment, mais il a tout l'air de lancer l'idée de la sémantique des langages de programmation. Lisez le vous même, voici quelques morceaux choisis.

Landin a l'idée d'isoler l'impératif du fonctionnel, ce qui donnera plus tard les monades de Haskell: The author thinks that the fruitful development to encompass all ISWIM will depend on establishing "safe" areas of an ISWIM expression, in which imperative features can be disregarded.

Il propose d'ailleurs une dénomination que je préfère à "fonctionnel": The word "denotative" seems more appropriate than nonprocedural, declarative or functional. The antithesis of denotative is "imperative".

Moins frappant, mais à mon sens une bonne description des qualités de ML: The special claim of ISWIM is that it grafts procedural notions onto a purely functional base without disturbing many of the desirable properties.

Je trouve qu'il y a beaucoup d'idées là dedans, et en général un bel effort de conception rigoureuse des langages de programmation. Le genre de chose qu'on voudrait voir plus souvent. Perl c'est rigolo, mais je trouve ça de plus en plus tristement antique. Les Perleux diront bien sûr que Perl cherche à être un langage naturel, favorisant la créativité, que c'est de l'art, bla bla. Je dis que la programmation n'est pas un art, mais un artisanat, ce qui n'exclut pas le plaisir du travail bien fait, mais met en avant la finalité. C'est pas de la peinture, c'est plus proche de l'horlogerie.

Les langages pop plus récents (Ruby,Python,Javascript,..) semblent cependant évoluer dans la bonne direction. Ils deviennent plus fonctionnels, et ont une notion de portée lexicale plus claire. Côté Ruby et Python on remarque que la (re-)définition remplace souvent implicitement l'assignation, à l'opposé des variables globales bordéliques de la génération Perl. Cela dit, je suis pas complètement heureux avec ça non plus, je trouve qu'on se fait vite piéger par les définition-par-défaut et on n'arrive plus à faire des assignations là où on le veut.

Voila.. j'avais deux trois trucs à cracher sur la prog :p

En voyage

2006-05-15T04:41:00.000+02:00

Finalement j'abandonne l'idée de trouver un adaptateur SDCard-USB ou une carte wifi pour mon Palm, et je recopie simplement la tartine écrite dans l'avion..

L'aventure commence plus tôt que prévu, dès l'enregistrement à l'aéroport Charles de Gaulle. Je signale que je n'ai pas de visa, étant un simple visiteur de courte durée. L'hôtesse sait que cela suppose aussi que mon passeport ait été émis dans le bon intervalle de temps, mais ne se souvient pas des conditions. De mon côté pas de panique, j'ai vérifié sur le site de l'ambassade et auprès de l'agence de voyage de l'INRIA: il n'est ni trop vieux pour ne pas être optique, ni trop récent pour devoir être biométrique -- ce qui est encore impossible en France de toute façon. L'hôtesse demande à sa chef, qui appelle quelque, qui sait pas. On appelle ensuite la police. Verdict de la PAF: il me faut un visa, je ne peux donc pas embarquer. Je l'ai quand même un peu mauvaise et j'insiste pour qu'ils vérifient, je suis sûr de mon coup, je peux pas sortir un visa de mon chapeau, l'INRIA va l'avoir mauvaise, etc. Coup de bol la police répond plus et un pilote de passage souffle à mon interlocutrice d'aller demander au guichet d'United Airlines. Après poireautage, on m'annonce enfin que je suis en règle. Sans blague. Je procède à l'enregistrement bon dernier. Comment les hôtesses ET les flics peuvent ne pas savoir ce genre de truc, je sais pas..

Je finis les formalités pas particulièrement joyeux, j'ai pas droit à beaucoup d'excuses ou de sourires. Le plus sympa dans l'affaire ça reste le mec qui m'a fouillé, me signifiant d'une mimique que j'avais beau faire sonner la porte, il ferait pas de zèle.

Dans l'avion je commence la lecture de "Da Vinci Code". Je ne trouve pas ça foudroyant niveau suspens, mais ça reste assez efficace. L'intrigue générale est sympa. Dans les détails, c'est agaçant, l'auteur nous propose son interprétation de mythomane du sens de.. tout. C'est douteux au possible, et souvent déja vu. En plus, c'est pas super bien écrit, remplit à coups de platitudes ridicules. J'en dirais pas plus, ça m'a occupé un long trajet d'avion pendant lequel j'aurais pas pu faire grand chose de plus intelligent, et ça ne vaut pas mieux que ça. Le traducteur écrit "bitte" avec deux "t" et ne se trompe peut-être pas, finalement. Faut que je vérifie, ça me bouleverse. Par contre je relève un "acquiT de conscience" bien moche et une traduction un peu trop litérale de climbing: "Avez vous déja escaladé la tour Eiffel ?"

J'ai ensuite changé d'avion après une escale courte à Reykjavik. Malheureusement c'est encore un petit Boeing, assez bruyant donc. Mais le détour par l'Islande vaut le coup. Déja ça coupe le voyage en deux parties de longueur raisonnable. Surtout la vue est impressionante. Le morceau d'Islande que j'ai vu est super aride. Une terre sombre et sèche, de grandes fissures.. sans exagérer, on dirait une bouse de vache géante, séchée et bien plate. Une route et quelques groupes de batiments sur la côte. On doit pas rigoler tous les jours ici, et on doit s'inquiéter de la montée du niveau des océans.

Bon, ça n'est qu'un petit morceau de l'Islance. D'ailleurs en repartant je vois au loin une chaîne de montagnes plutôt imposante. Et surtout, peu après, la banquise ! Plutôt un troupeau avancé d'icebergs pour être honnête. Mais tout de même énormes, à en juger par notre altitude. On croirait presque des nuages, mais c'est bien de la glace.. Iki ikii kik !!! Par la suite j'ai droit à une étonnante variété de mélanges de glace, terre sombre et océan. On survole le Groenland, en fait.

Arrivé à Minneapolis j'ai eu droit à la mythique procédure d'admission aux US. Questionnaire: suis-je un terroriste ? anarchiste ? ai-je collaboré avec les nazis ? Non Monsieur, rien de tout ça. Très bien. Pourquoi je viens aux US ? Je suis thésard en informatique, en visite à l'Université du Minnesota, aux frais de l'INRIA. Bizarrement, ils trouvent ça plus douteux. Il trouvent bizarre que je vende pas de logiciel et ne sollicite aucun financement de la part des US. Ils me le demandent trois fois, et font aussi mine de vérifier que j'étudie bien l'informatique, mais sont vite perdus dans mes explications sur la logique, la vérification de spécifications formelles.. Finalement, je leur propose de demander confirmation au thésard américain qui m'attend à la sortie, ce qui me sauve. Après une attente pas si courte (pendant laquelle les douaniers se demandent s'ils peuvent pas trouver un "crazy test" à me faire passer pour vérifier que suis bien un thésard) on me file mon visa de simple visiteur, après avoir relevé mes empreintes digitales et pris ma photo.

La suite est beaucoup plus monotone. Des voitures partout, hôtel moyen, énorme petit dej à coups de donuts, café dilué à mort, les rues ressemblent à ce qu'on imagine des rues américaines, la nuit les flics et les pompiers jouent avec leur sirène, ya pas beaucoup de restos ou de magasins de bouffe potable dans le coin, on me conseille d'y filer au moins 15% en pourboire aux pauvres serveurs esclavagisés, il y a une bible sur la table de ma chambre d'hôtel... Voila. Peu de compagnie le soir, pour l'instant en tout cas, mais il y a le wifi dans ma chambre :p

Dans la suite de mes aventures, j'essaierai de visiter le plus grand supermarché des Etats Unis, de trouver les transports en commun dans cette grande ville, et surtout d'acheter des fruits.

Loin

2006-05-14T04:21:00.000+02:00

Je suis à Minneapolis. J'ai eu un peu de mal mais ça y est. Par contre j'ai oublié trois trucs. Mon appareil photo, donc pas d'images; mon cable Palm-PC, donc pas moyen d'envoyer le post rédigé dans l'avion; un adaptateur pour prises US, donc pas moyen de m'attarder faute de batterie... une grande aventure à suivre.

The Knight who says Yi

2006-04-26T11:19:00.000+02:00

Heimdall me parle du SummerOfCode Haskell, et me fait ainsi découvrir Yi, un éditeur de texte écrit en Haskell qui prétend être plus dynamique qu'Emacs. L'auteur explique dans un article comment concevoir des applications complètement dynamiques, dans un langage compilé et statiquement typé comme Haskell -- il a aussi conçu le λbot IRC de #haskell selon la même méthode.

L'article ne présente pas un nouveau langage ni même un nouveau compilo, mais une méthodologie de développement qui permet de faire une application reconfigurable à chaud, dans laquelle on peut même changer des morceaux de code à chaud. C'est un peu gros d'affirmer que le résultat est plus dynamique qu'Emacs, on voit sur la fin les limites du modèle quand il aborde les commandes type :map, autant dire qu'il y a pas de jolie solution pour le M-x d'Emacs. Mais au fond, on peut peut-être se passer de ces choses là. Malgré ces excès, l'article est très intéressant et élégant, et surtout casse des idées reçues sur les langages dynamiques. Avoir un langage statique compilé permet aussi de faire plein de trucs "dynamiques".

Tout ça nous ramène à bed, un éditeur écrit en OCaml qu'on avait commencé avec comme idée centrale de faire le procédé de colorisation/indentation de façon plus jolie en adaptant les techniques bien connues de lexing/parsing de façon plus maline que d'hab. Le développement avait bloqué au moment de faire l'éditeur lui-même pour des problèmes de design, et ce genre de lecture est peut-être un pas vers une solution, un jour. C'est plus raisonnable que mon autre scénario de reprise, qui passait par la création d'un langage de prog plus adapté, que la killer-app bed aurait ainsi popularisé en retour comme le premier langage statique dynamique.

En attendant, la fondation Haskell propose un projet Summer of Code sur l'éditeur Yi, il s'agit d'ajouter la colorisation et l'indentation... Je suis curieux de voir ce que ça donne.

XFesse

2006-04-26T00:19:00.000+02:00

À ma gauche le logo d'un vieux projet mort et enterré que je compte pas du tout déterrer. L'ours en slip a même une histoire qui remonte à avant mes premières lignes de code. Et ce n'est pas fini pour lui, puisque sur idée de Romain, il pourrait devenir la mascotte de liquidsoap. À venir...

Un à-venir vraiment proche c'est Xfce 4.4, puisque la beta-1 est sortie il y a quelques jours. J'ai pu goûter au nouveau filemanager Thunar, dont j'avais déja vu les maquettes Python il y a un moment. Cela promettait, et je suis pas déçu du résultat. C'est simple et très efficace, ça fait penser au bon ROX avec quelques nouveautés, et une meilleure intégration aux standards freedesktop notamment pour le thème d'icône. Si j'utilise un filemanager graphique ce sera celui là. En attendant d'installer la totale de la 4.4 on peut jeter un oeil sur la liste de nouveautés d'Xfce et les dernières modifs de Thunar. Dans la foulée je donne aussi sa chance à Xfmedia. Plus délicat que "Google va-t-il réussir à rester no evil ?", on se demandera aussi "Xfce va-t-il réussir à rester ergonomique et rapide au fil de ses évolution ?"... en ce moment, le mien démarre drôlement lentement, mais c'est ptêt de ma faute. Je conseille en tout cas vivement cet environnement de grande qualité, élégant de simplicité, bourré de bonnes idées et toujours en mouvement.

Tant qu'on y est sur les nouveautés, j'ai quitté ma Google homepage pour la plus jolie et plus fonctionnelle page de NetVibes, qui remplit notamment un vrai rôle d'aggrégateur de flux, se souvient et affiche clairement ce que tu n'as pas encore lu.

Autre nouvelle en vrac: ça se confirme, j'ai des visiteurs occasionnels à part vous trois à qui j'ai donné l'adresse de ce carnet, et pas que des visiteurs anodins, cf certains commentaires... J'ai le trac, faut que je me surveille un minimum sur la qualité :p

Retour de vacances

2006-04-22T11:24:00.000+02:00

De retour de vacances, je pourrais vous faire un post sur une pizzeria de Bourg-St-Maurice, une critique du domaine skiable de Tignes/Val d'Isère, ou encore un comparatif crèmes solaires, ce serait encore plus branché que Gelnior. Mais non. Je pourrais aussi ne pas réussir à vous raconter comme le ski c'est bien, le surf encore mieux mais douloureux à en crier, la famille c'est chouette, surtout quand on l'a plus sur les pattes au quotidien mais seulement dans de bons moments comme ça.

Mon appareil photo a accepté de s'allumer la veille du départ. Agréablement surpris je l'embarque. Mais au premier jour de ski il ne marche déja plus. Du coup pas de photo de ma gueule de kéké. Le soleil m'a cramé de façon alarmante. Maintenant je m'effrite comme une tête de beuh dans les mains de Romain.

Voilà voilà, coupure quasi totale pendant une semaine, faut se remettre au rythme normal là. Ecrire un peu pour le labo deux trois pensées de télésiège. Lire toutes les news de geek qui sont tombées pendant mon absence, et chercher à synchroniser mon Palm avec le tout nouveau Google Calendar... La routine revient vite.

Brisez les chaînes .. de caractères

2006-04-13T16:18:00.001+02:00

Tout à l'heure je discutais avec mon père, il me reparle d'un problème qu'il a en Javascript, et me demande si j'y ai repensé. Je réponds légèrement que non j'y ai pas repensé, je vois pas le problème, etc. Il s'acharne. Alors je pose sur papier un schéma de ce que j'ai en tête. Et là tout s'éclaire...

Vous faites du Javascript, en plein coeur de l'action vous avez quelques variables locales bien compliquées, genre une table de hachage, une fonction, des noeuds XML... Et vous voulez programmer une action à effectuer dans 42 secondes, qui devra utiliser ces données.

On pense à setTimeout, qui prend une chaîne S et un entier N, et évalue S après N millisecondes. Problème: la chaîne est évaluée dans le contexte global, dans lequel on ne voit pas les merveilles qu'on a localement, et qu'on ne peut pas non plus facilement encoder dans la chaîne de caractères. Mon papa ne se décourage pas et programme un système permettant de réserver une place identifiée par un entier pour ranger les infos concernées dans une liste globale, et parle ainsi de ces objets en écrivant l'entier dans sa chaîne. Au bout d'un peu de code et de debug, on s'en sort. Et on est fier d'avoir implémenté un petit système d'allocation de mémoire.

Pratiquant plutôt d'autres langages que je qualifierais de plus sains, j'avais en tête que setTimeout prend en paramètre une fonction F et un entier N, et appelle F() au bout de N millisecondes. Cela simplifie le problème, car Javascript lie les variables statiquement, c'est à dire que si dans ma F je parle de x et de n, il s'agit des x et n dans la portée de la définition de F. Du coup pas besoin d'aller faire des micmacs dans une variable globale ou à sérialiser des données complexes. On crée juste une fonction anonyme exécutant le boulot à faire dans 24 heures chrono, le plus naturellement du monde. Et ben figurez vous que le setTimeout de Javascript accepte aussi des fonctions comme je l'imaginais. Happy end.

Morale: un bon design résout bien des problèmes. Vive le fonctionnel, mort à eval(), aux armes, etc.

By the way, Python a relooké son site web. Python.org fait très pro, voire trop. Par contre on ne sait trop que penser de la campagne de comm menée par Python.com...

Radio time

2006-04-07T10:07:00.000+02:00

J'ai passé beaucoup de temps ces derniers jours sur la préparation de mon séminaire thésard. C'est fini, et ça s'est plutôt bien passé. Maintenant je vais me faire plaisir pendant quelques jours en avançant liquidsoap. J'ai fixé des plus ou moins petits bugs, encore un peu changé la syntaxe, je vais finir par uniformiser les nommages dans l'API de scripts, stabiliser les transitions, etc. Deux nouvelles features:


output.icecast(
  mount="prout.ogg",
  # La fonction suivante est appelée pour chaque paquet de metadata.
  # Cela permet de loguer par exemple les fichiers diffusés, pour la SACEM.
  on_metadata =
    fun (m) -> system("echo '"^assoc("initial_uri",m)^"' >> /tmp/appended"),
  # Ici un exemple de requete dynamique assez débile,
  # ça passe le premier fichier valide dans une playslist.
  # Bien sûr chacun mettra ici son propre programme
  # d'ordonnancement de playlist.
  fallback([dyn_request(fun () ->
                          ("zob:ma playlist",
                           get_process_lines("cat "^"/tmp/playlist"))),
            one_file("/usr/share/mrpingouin/mp3/jingle/tue-sa-mort-sam.mp3")]))

OK tout n'est pas clair mais avouez que vous sentez que ça rules :p Bon tout ça ne va pas sans mal et je ne prends pas toutes les précautions nécessaires. Du coup RadioPi était très malade hier soir (plusieurs évanouissements) et les jeunes qui voulaient faire un live ont dû être un peu déçus.

Misc

2006-04-01T22:20:00.000+02:00

J'ai enchainé les petits post anodins et geeks ces temps-ci. Pour me réfréner j'ai décidé d'accumuler plusieurs autres liens dans un seul post, qui est désormais assez plein. Flush.

Les prochaines applications à la mode seront mobiles ? Le Bluetooth offre des possibilités rigolotes, formant ce que certains appellent des Personal Area Networks.. Jouez à Qui est-ce ? avec un inconnu dans le coin, ou partagez des fichiers de façon encore plus incontrôlable que le p2p avec Pocket RendezVous. Romain, la killer-app du futur que tu cherches est sûrement Bluetooth-enabled.

Sinon, j'ai fait une émission très sympa sur RadioPi l'autre soir. On s'est dit qu'il faudrait se préparer pour la prochaine, que ce soit encore mieux. J'ai pas commencé à écrire les textes, mais j'ai trouvé des sites de sons. Allez vous immerger dans deux magnifiques sites de la communauté phonographiste, qui enregistre tout ce qui passe: SoundTransit et SoundScape FM.

Enfin je suis retombé sur un dessin fait avec un nouveau design du blog en tête..

Aha

2006-04-01T14:36:00.000+02:00

Je suis tombé sur un scoop bien chaud ce matin, la sortie de DukeNukem Forever!... J'ai vite réalisé qu'on est le 1er Avril. Drôle aussi: l'ajout de GOTO et COMEFROM dans Php6. Ou encore une bonne blague à la française... qui fâche.

Compilateur Scheme vers C

2006-03-31T16:45:00.000+02:00

Je voudrais pas remplacer Lambda the Ultimate, mais cette présentation expliquant en 90 minutes comment réaliser un compilateur Scheme vers C de moins de 1000 lignes m'a impressioné... Ce n'est probablement pas la méthode de compilation la plus efficace mais ça me semble être une bonne solution pour les paresseux.