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 !

A makefile snippet for generaring ray-traced images from pymol

For my research, to create neat images of the molecules I study, I use Pymol. It's free, part of Debian, command-driven, very powerful and it produces really good-looking pictures. Although, admittedly, if you don't buy a subscription, the documentation is rather sparse. I'm using scripts to generate ray-traced pictures, but I can't include the ray command directly in the scripts, as Pymol would not give me the opportunity to change anything before tracing (and things I trace take loads of time...). So I write a ray command, but I comment it out, such as in the following example, cytochrome.pml:

load http://www.rcsb.org/pdb/files/1c6s.pdb
hide everything
show sticks, (resname HEC)
color orange, (resname HEC)
show cartoon
bg_color white
set_view (\
     0.939850032,    0.167392358,    0.297758341,\
     0.336208642,   -0.299271941,   -0.892972171,\
    -0.060366094,    0.939367712,   -0.337551534,\
     0.000000000,    0.000000000, -106.161231995,\
    33.668910980,   -4.749122620,  -24.822664261,\
    -9.742469788,  222.064941406,    0.000000000 )
# ray 800,800

So, to easily generate PNG images from such a file, I wrote the following makefile snippet, that does the job (as demonstrated by the figure on the right, produced by this very snippet ran on the cytochrome.pml file above):

%.png: %.pml
 cd $(dir $<); \
 ray_trace_args=`grep -o 'ray.*' $(notdir $<)| tail -n1 | egrep -o '([0-9, ]+)' | sed 's/ //g' `; \
 pymol -c -d "@$(notdir $<)" -d "cmd.ray($$ray_trace_args)" -g $@

I hope this snippet will prove useful for others. At any rate, it will prove useful for me ! Just for the record, this protein, represented in cartoon view, is called cytochrome c₆ and is one of the proteins implied in the photosynthesis of some organisms.

Emacs mode for machine-readable copyright files !

Quite a fair amount of time has flown since my decision to implement an emacs mode for the proposed machine-readable format for debian/copyright files. A have to admit that I had left that sleeping for quite a long while. But I took my courage, and rewrote nearly everything I had done so far. I'm quite happy with the results, to be truthful. The debian-mr-copyright-mode features:

• syntax highlighting
• a coverage mode show all files in the package, including the ones not covered by the copyright file
• the coverage mode shows which glob matches a given file
• it provides links to visit files and go to the declaration leading to a given label

The aim of this mode is to provide a quick check for uncovered files in a package, and also means to verify if the license of a file is not misrepresented.

The code can be downloaded from the git repository, accessible using

git clone git://git.debian.org/git/users/fourmond/debian-mr-copyright-mode.git

No debian package is available for the time being, although that could definitely change after lenny is out. I hope this emacs mode will help the new format to be widely adopted.