A praise for TikZ

I have been using xfig for ages to draw figures, and I appreciate it, especially combined with a small script I wrote based on an original idea by Seb Desreux at H&K, fig2ps, that allows painless integration of LaTeX code inside xfig figures.

But recently, it seems that I've hit limitations in xfig. Mainly, if it is great when you want to produce sober figures, whenever you want to do something fancier, including shadings and the like, frustration comes in quickly (since it is purely impossible). I've spent a while looking for a decent alternative, until I had a look again at pgf, which since turned into TikZ. That was amazing. It integrates painlessly within LaTeX and is simply great to work with. Drawing complex diagrams with noes and complex relations between them is trivial. It handles moving the nodes very gracefully, and styling can be done in a CSS-like fashion (though it definitely isn't CSS), which means you can first concentrate on structure and then turn your graph into something nice, while for all the other programs I know, you have to handle both structural and stylistic aspects at the same time.

Sure enough, you need to like the command-driven approach, as mice won't come in too useful here... As a side note, I wanted to express my admiration of Till Tantau's (TikZ's author) mastery of (La)TeX: TikZ can be seen as an interpreter of a simple graphical language written in pure TeX, which is, according to my humble experience with dirty trick in TeX, is simply amazing. Many thanks, Till !

Doxygen for Ruby, first working draft !

Quite some time ago, I complained about the lack of support of Ruby in doxygen, the ultimate code documentation generator (at least for me). Time has passed, and I had some time and motivation to look into it and write a patch. The code is now reasonably mature to be used, altough it still lacks many features, and, most importantly, testing.

That's why I pushed my git-svn private repository to github today, in order to get enough testing to integrate it into mainstream doxygen. It's current features:

• Code structure parsing is complete in principle, it should extract all the classes/method definitions. If not, please use the tracker at github, posting a full example showing the problem.
• It features a rdoc compatibility mode (on by default), in which it parses all comments (outside method definitions) and interprets most of rdoc's markup.
• The inner code parsing and cross-linking is very ineffective for now; most cross-links are currently not performed. This is one thing on which I'd like to work some day... Although you're welcome to have a go at it if you wish !

You can get an opinion of how it looks on the code of ctioga2. The doxygen configuration file can be found there.

ctioga superseded by ctioga2

First, some historical details: some 6 years ago, I discovered Ruby together with Tioga, a great library for producing plots. That immediately resulted in my first Ruby program, ctioga. But as years passed and more features were forced into ctioga, I was compelled to see my initial design mistakes, and think about a complete rewrite.

This is where ctioga2 was born, some time at the beginning of 2009. I completely stopped using the old ctioga a few month after starting to work on ctioga2, but it took ages before I finally came up with a decent enough documentation to release and announce publicly. But now, it's done, and the first public release of ctioga2 is out, still fresh !

Here are a few highlights of the differences:

• For me, it's day and night: adding new commands is painless: I only need to create an object with the appropriate code; registering is done automatically.
• Now, command-line switches also accept options looking like this /option value that allow many small tweaks I had never had the courage to write for the old ctioga as it was way too painful to add new commands there.
• ctioga2 can be driven both from command-line and using command files, in the style of gnuplot, which is the reason why I call it polymorphic.
• More importantly, I finally had the possibility (and more or less compelling reasons, to be found in a paper currently in press) to implement 3D data displays in ctioga2, in the form of color maps (that's what is shown here).
• There are still a few things that could be done by ctioga and that miss from ctioga2, such as histograms. When I have some time and/or motivation...

In any case, you can make yourself an opinion of ctioga2 by looking at the galleries.

Enjoy !

The java packaging nightmare...

... or why I mutilated your java package in Debian

This post is especially addressed to what we Debian Developers refer to as upstream maintainers, that is the people who write/maintain the software that we package for Debian. It is meant to explain why, in some cases, Debian Developers prefer to mutilate your work rather than upload it to Debian Archives in a state that gives it proper credit. And to apologize.

These opinions are my own, but I have a faint feeling that I'm not the only Debian Developer working like that, and that this few words could help soothe the relation betwenn Debian Developers and Upstream Maintainers, which can be quite tense some times...

It happens unfortunately quite often (too often!) that I disable (or don't enable) features in programs I package. Exact reasons vary, but they essentially fall into two categories:

• A feature requires code that does not comply to Debian Free Software Guidelines, which Debian cannot distribute. This is a no-go.
• A relatively minor feature depends on other software that are not packaged yet, and in which I don't have specific interest, which means I would not be able to maintain them properly (or it would require too much packaging work and so on...).

When a program has features which falls in one of these categories, I have two choices: either I give up packaging the software or I give up some of the features... For packages for which I care, obviously the second option looks better from my point of view as a Debian Developer.

Java packages are especially affected by this problem, for a very simple reason. Java is one of the few (I don't say only because I'll probably be flamed to death) programming languages which allows very easy distribution of binary platform-independent libraries, in the form of JAR files. Many projects simply reuse and embed JAR files published for other projects in their own JAR files, often without precise references to where the source code can be found. Packaging a moderately-sized Java application often rely on dozens of embedded JARs, which we need to remove from the packages we build (as Debian does not distribute binaries without sources for many reasons), and for which we need to hunt down the original source code and often packaging the original project, which might pull in yet other dependencies and so on... A true nightmare ! That's why it is so tempting some times to simply drop some of the code, possibly write patches to disable references to removed libraries, and be done with it.

Therefore, I would wish to publicly apologize to any upstream developer I've offended by stripping down apparently carelessly their beautiful software before uploading to the Debian Archives; I hope they now understand why I've done that.

Note to users: it is not because one of the features of your favorite software has been disabled by its (Debian) maintainer that you need to turn away from Debian ! Rather, file a bug report against the package. You'll get the reasons why the feature was disabled, and you have a chance to convince the maintainer to switch it back on.

HADOPI: a great blow to freedom of expression and justice in France

Here I am, utterly disgusted. Last Thursday, around 11pm, two dozens of members of Assemblée Nationale (one of the two parliament chambers in France) voted the infamous law nicknamed HADOPI. Great... For the record, this chamber in principle counts 577 members.

This law is an awful blow to the Internet, the freedom of expression and the legal system in France. The official aim of this law is to put a stop to illegal file-sharing within France. With this law, specially appointed private companies will file accusations saying: this IP downloaded something illegal at this date to a central authority, and this authority will send two warnings before cutting the Internet connection of the alleged illegal downloader for up to a year. You will notice that there is no mention of what the incriminated person allegedly downloaded. There will be no possibility of appeal until the sanction is executed.

This scares the hell out of me.

This spits upon so many aspects of the French legal system that it is honestly impressive... What about the French principle that says that everyone is innocent until proven guilty ? Here, you are declared guilty based on a rather weak evidence (on IP address !), and you'll have to prove your innocence. What about the principle that there needs to be a fair trial before the execution of the sanction ? You'll have to prove you are innocent after the execution, with the additional fun that it will turn almost impossible to prove it. Not to mention the fact that the companies harvesting IP addresses of alleged offenders will have a great deal of access to data you're exchanging; what about privacy ? For the record, this privilege, violating the way justice works in France, had only ever be granted to anti-terrorist cells.

The fun thing is that this law is useless, at least in terms of the its official goal: the day it comes into application, illegal file sharers will encrypt their exchanges or fake their IP addresses, or do whatever else they might want to do to guarantee their anonymity, and no company will ever be able to find out what it is they exchange. I won't even mention the number of false positive of these automatic accusations: many innocent French web surfers will have their connection cut without ever knowing why and without any possibility to fight back.

So, what is the real goal ? Or what will be the use ?

I can only speculate, of course, but it is tempting to think that this law could be used to regulate what is being expressed from France on the web. Someone is saying disturbing things ? Well, easy to shut him/her up: either fake downloads from his/her IP address or bribe a company into filing false accusations, and you'll effectively remove his/her connection while having the opportunity to further discredit the person by publicly disclosing that he/she is such a pirate that their connection was cut... Sounds neat, doesn't it ? In my childhood, teachers kept on saying that France is the country of human rights, but I can't help thinking this is less and less the case[1].

Well. That was a long rant. But I can't keep it inside: this is touching me too much. I'll add that I'm not downloading anything, and I don't have anything a priori against laws which would tend to regulate illegal file sharing. I just don't think that the (small) profits of a few justify spitting upon the freedom and the elementary rights of all people living in France. Further information, in French, can be found there. The full text of the project can be found on the website of Assemblée Nationale.

[1] Please don't get me wrong. There are many countries where life is definitely more difficult than here, and where human rights are constantly scorned upon, which is fortunately not the case here yet.

pdfinfo in centimeters

pdfinfo is one of the utility programs bundled with xpdf that gives useful information about PDF files, including its size. However, the size is written in Postscript points, and I can't say I'm that fluent in this unit to actually know how big that is. So here is a shell function that converts the output of pdfinfo into centimeters. Enjoy !

pdfinfom () {
    pdfinfo "$@" | perl -p -e \
 's#(\d+)\s*x\s*(\d+)\s*pts#(sprintf "%.2f", ($1*2.54/72))." x ".(sprintf "%.2f", ($2*2.54/72))." cm"#e'
}

Weird crash with linux 2.6.26

I've had a rather funny crash for the second time now. It goes like this: the interface is freezing (processing event extremely slowly), it is nearly impossible to do anything (but apparently, everything works, just extremely slowly !). Kernel keep on saying this:

Mar  3 18:56:50 tanyaivinco kernel: [ 2385.443069] hdd: status timeout: status=0xd0 { Busy }
Mar  3 18:56:50 tanyaivinco kernel: [ 2385.443069] ide: failed opcode was: unknown
Mar  3 18:56:56 tanyaivinco kernel: [ 2393.777714] hdd: status timeout: status=0xd0 { Busy }
Mar  3 18:56:56 tanyaivinco kernel: [ 2393.777714] ide: failed opcode was: unknown
Mar  3 18:57:01 tanyaivinco kernel: [ 2398.982260] hdd: status timeout: status=0xd0 { Busy }
Mar  3 18:57:01 tanyaivinco kernel: [ 2398.982260] ide: failed opcode was: unknown

One of the funny things is that this time like the previous one, at the beginning of the problem, there is always this kernel message, for which I could find no documentation:

Mar  3 18:56:35 tanyaivinco kernel: [ 2367.012218] Clocksource tsc unstable (delta = 4686267423 ns)

If anyone ever came across this, or has clue, I'm interested !