Debian java packaging and jclassinfo

I've become more and more interested in packaging Java programs recently, and I find that it is not easy for several reasons:

• There are at least half a dozen java implementation, some free, others non-free, with slightly different standard libraries. I find it all very confusing and error-prone.
• A fair amount of Java packages depend Sun's Swing graphical user interface, and some others depend on Sun's XML parsing (at least as I understand it); they must therefore go to contrib
• Java programs need script wrappers, often rather ugly, even more hackish and definitely not reusable/reused
• There is currently no way to find dependencies of a Java package

I've nearly finished to package jclassinfo, a very useful tool that could bring an answer to some of the problems above, by extracting dependency information from class files. With its help, it could be possible to write something like dh_shlibdeps for Java classes. This would bring a real solution to the dependency problem, and possibly help as well for the main/contrib fight. More information later.

On vacation !

Well, I'm finally taking a rest at my parent's house for a few days, before coming back to science, Tioga bugs, ctioga feature requests and various Debian Developer's duties.

I wish a merry Christmas and a happy New Year to anyone reading this that actually does celebrate them (at this time in the year) !

SciYAG has been released !

Finally, I've released SciYAG ! I actually released it quite a few days ago. And it has seen quite some modifications after that (among which a critical bug fix...). Among the new features, let's name a few little ones:

• icons for experiments, directories and groups, adapted from gnome and KDE iconset, all in SVG as I discovered that Qt4 natively deals with SVG icons (great !)
• You can now edit Experiment Groups in the Type view as well
• Some usability fixes, such as shortcuts for commonly repeated things
• It starts to actually look good !

I'm starting to use it heavily for my own work, so it will have to improve fast !

Don't use --rename with dpkg-divert

I was hit by a funny bug I had hard times trying to reproduce on libqt4-ruby. I'll try to make a quick summary of the problem:

• In etch, libqt4-ruby1.8 was conflicting with libqt0-ruby1.8, as they were both providing nearly the same files.
• Soon after etch's release, cohabitation of both libraries was made possible, thanks to upstream work. However, libqt4-ruby continued to provide rbqtapi, that was also in libqt0-ruby1.8. As the one from libqt4-ruby1.8 was actually providing more functionalities than the other one, I decided to use diversions to take over rbqtapi.
• Everything was working fine, until a piuparts check showed that on installing etch version, upgrading to lenny and purging, there was things left... More specifically rbqtapi...

It appeared that the lenny package was diverting its own files from the etch version ! All it took was to remove the --rename option to dpkg-divert. As a conclusion: be wary of --rename ! You most probably don't need it !

SciYAG has a search engine now !

I wanted to release SciYAG not so long ago, but it came to me that it was still missing something to be of real interest: a search engine. It lets you find experiments according to data. Code used is real Ruby code, so you get a pretty good deal of power, and it stays reasonably intuitive.

It starts to feel like SciYAG is really getting ready and interesting ! Now, I'll try it rather heavily, and we'll see if it can stand a heavy use with reasonable performance. I hope so, as I did take care about this (although some improvements can still be expected somehow). Oh, by the way, the gnuplot backend is also available for SciYAG now !

gnuplot-compatibility backend

I used to work a lot with gnuplot. For what matter, I still do. I find it very convenient to write simple models (the one you can solve analytically), especially with the help of gnuplot-mode, a mode for editing gnuplot files and interacting directly with gnuplot, rather more smoothly than the standard gnuplot interface. But, you might have guessed, I don't like how gnuplot's output looks. After all, that's why I did write ctioga!

So what ? I won't use ctioga for playing with my models, as it has not been designed with interactivity in mind, and will most probably never be (that would somehow defeat it's purpose). But I don't want to do the same work twice, especially if the second time is way more tedious than the first...

So I wrote a new backend, gnuplot, whose job is to feed a file to gnuplot and tweak it so that ctioga gets the data of all the plots. Imagine you have a file biniou.gnu in the spirit of

a(x) = x**2 + 2*x + 1
plot a(x), x**2 - x

Then, you can plot both a(x) and x**2 - x with the following command-line:

ctioga --gnuplot biniou.gnu@1##2

Note that it only takes data ! Style is completely dismissed.

SciYAG is nearly ready !

I haven't been writing for a long time about SciYAG, but it does not mean that I didn't work on it. For what matters, I've been progressing quite a fair bit, to the point that I consider it releasable. Here comes the current features:

• fast display of experiments, including quick selection of several experiments and zooming
• editing of experiment types
• saving the database in the form of a YAML file
• editing type-related experiment "meta-data"
• using experiment groups for meta-data shared across a whole group of experiments (say, same buffer, so same pH values)
• different views of the experiments (type-based, file-based and group-based)

Although this really doesn't make all the features that are planned (see here for a reminder), it makes something I'd qualify as usable.

Actually, the only thing that refrains me from releasing is that I really should come up with a rudimentary documentation before I do so, and I simply don't have the energy/time/will for that now... Some time later (soon, hopefully) ? I really prefer adding some more features !

ImageMagick and photos for ID cards

I had to make some ID card pictures for my daughter, and the public machine that I usually use for that was down this morning. So, I decided that I would simply take a picture of her, arrange that into a 13x10cm picture, and have it developed (along with other pictures). My first intention was to use the gimp for that, but, I never learned how to use it, and I wouldn't have a simple way to do that again should I need to.

So I went for the command-line approach, with the tool montage from ImageMagick. The pictures should measure 35x45mm in the end. I used the following command-line options:

• -tile 3x2 6 small picture fit on the target paper
• -geometry 700x900 the size of an individual image (not the one of the whole montage); it is a multiple of 35x45 and gives a neat resolution in the end
• -border 8%x5% -bordercolor white to add a neat white border around the pictures. The numbers are computed so that the overall picture respects (around) the 13x10 aspect ratio

In short, that gives this:

montage -tile 3x2 -geometry 700x900 -border 8%x5% \
  -bordercolor white Morgane.jpg +clone +clone \
  +clone +clone +clone target.jpg

The +clone just tell montage to reuse the last picture used.

reftex and beamer

Well, I already said that I enjoy working with reftex. It also happens that I'm a beamer fan. Beamer is a great tool for making wonderfully-looking presentations with LaTeX. So, here's a small trick I added in my .emacs configuration file to be able to see frames in the TOC mode of reftex. It is quick, dirty and hackish, but it works:

(add-hook 'LaTeX-mode-hook (lambda ()
  (turn-on-reftex)
  (setq reftex-section-levels 
 (cons '("begin{frame}" . -3) reftex-section-levels))
  ))

reftex-toc like code browsing

I use AUCTeX for typing long LaTeX documents with emacs and I especially appreciate the so-called reftex-toc interactive mode for browsing the table of contents of the document, jumping to the relevant position.

I've been missing for a while something similar for code. While the utility of reftex-toc is somehow limited, because I (and most probably many other people) tend to write textual documents linearly, I write code absolutely not in a linear fashion - so I spend a fair amount of my time looking for where I've written a given function... Until I decided to write a reftex-toc-like code browsing tool. It is based on imenu, which I find not very convenient. It works for Ruby code (within one file, does not work across file boundaries for now - which is probably better), and is really rudimentary, but functional enough. You can download it here. In the hope you might find a use for it...

First days of heavy debian sponsoring

As I've rather recently joined the Debian Games Team, I've taken up a place of sponsor. Rather tedious when you have 80kB/s upload speed to upload several packages of 100M to 250M... I'm always using cowbuilder to build my packages, as I hate to install build-dependencies I will never use... And the benefit is of course to make sure it does build ! I've come up with several gotchas in my recent uploads:

• changelog entries corresponding to never-uploaded versions
• and, a subset of the former, first revisions of a new upstream source skipped

Here are how to feed cowbuilder to work with this properly. First, for simply unuploaded changelog entries:

cowbuilder --build --debbuildopts \
  -vLastUploadedVersion package.dsc

You can check the last uploaded version with rmadison. If the first debian revision was also skipped, you can force a sourceful upload with the following:

cowbuilder --build --debbuildopts \
  "-vLastUploadedVersion -sa" package.dsc

Yet again some improvements in SciYAG

Well, I didn't stop so easily on my enthusiasm of the morning. So I went on. I'll probably seem to repeat myself, but I won't ever say it enough: QGraphicsScene and others are simply fantastic ! I implemented today ticks and a grid for the plot using the neat trick of subclassing QGraphicsView and providing custom handlers for drawBackground and drawForeground - so easy ! As a result, the code for the new plotting system is way more elegant than the old one (and more compact, although file size doesn't show it as it is also significantly more documented). Once again, many thanks to developers at Trolltech for their wonderful work !

SciYAG's new plot system

Today (or rather, yesterday), I started using SciYAG at work. It did prove useful, even in the stage of non-completion in which it was. Great ! However, I found that something was missing sorely: the ability to display several curves at the same time (yes, SciYAG is only pre-alpha software...). A quick look tonight showed me that it was time to change the way plots were implemented. I therefore changed completely the structure to profit from the QGraphicsScene scheme. Attached is a result obtained with the first commit... It looks great ! QGraphicsScene is very easy to use, thanks to the Qt developers.

However, I found out that when I was switching antialiasing on, the rendering time was excessively great for big plots (around a second for 7000 points on my machine). So I decided to use OpenGL rendering. It turns out that it is as simple as this:

format = Qt::GLFormat.new()
format.set_sample_buffers(true)
@plot_view.set_viewport(Qt::GLWidget.new(format))
@plot_view.setRenderHints(Qt::Painter::Antialiasing)

Fantastic, isn't it ??

Total installed size of a debian system

I was curious to know about the amount of space taken by packages on my server, to have an idea of the stress I give to the hard drives when I run debsums on all the packages. I used dpigs and perl to achieve this, being reasonably comfortable with the latter:

dpigs -n 300 | perl -ne 'BEGIN {$total = 0} /(\d+)/; $total += ($1 || 0) ; END { print "Total $total\n"}'

That worked, at least provided that there were less than 300 packages... I later thought about using awk, which is precisely designed for this kind of applications. That actually looks like

dpigs -n 300 | awk '{a += $1} END {print a}'

Better already. But you still need to know the number of packages installed. Well, we could ask dpkg, of course:

dpigs -n `dpkg -l | wc -l` | awk '{a += $1} END {print a}'

ctioga's new options shortcuts

I implemented today something I had in mind for a long time: a way to pass options in a slightly more convenient way to ctioga. I'm thinking mainly about the pain of writing, say,

ctioga --math --math-samples 200 'sin(x)'

when one would rather like to write

ctioga --math --samples 200 'sin(x)'

Starting from SVN revision 637, the latter form is possible. Specifically, when an option is not recognised, ctioga tries the following:

• if it looks like a shortcut, ctioga uses a shortcut
• if it corresponds to an option of the current backend (such as --samples for --math-samples), the corresponding option is used
• failing that, ctioga complains

You can see the beauty of these options in the attached graph, produced by:

ctioga --xpdf --math --samples 200 \
  --cloud --filled 'sin(x)'

Why debsums is your friend

I've recently had troubles with my server. It doesn't hold anything public, but helps me synchronise my data between my working place and home, and serves as a place to save sensitive data (though not the only place). I had serious random crashes, ending up in the server not being able to hold for more than a few minutes alive. Whoah !

I wrote a small script to get the output of sensors and other various data, and I was surprised to see that after a while, it began segfaulting... Quick investigation with gdb showed the culprit to reside in libc6-i686... Funny thing, reportbug also showed the exact same segmentation fault. There you go. I therefore installed debsums, checked the library, and bingo !

vincent@server:~$ debsums libc6-i686
/lib/tls/i686/cmov/ld-2.3.6.so                                                OK
/lib/tls/i686/cmov/libanl-2.3.6.so                                            OK
/lib/tls/i686/cmov/libBrokenLocale-2.3.6.so                                   OK
/lib/tls/i686/cmov/libc-2.3.6.so                                          FAILED

There was a checksum mismatch there... I reinstalled the library, and everything appears to work fine. But, that doesn't explain yet the crashes. I'm just afraid that my hard drives are slowly giving way, which would be very disappointing provided that they are brand new (6 month !) and not heavily used (though, maybe, in a warm environment). I'll check that later on.

ctioga and tick labels

On ctioga's forum, I was asked to provide a way to turn tick labels - which there currently wasn't. But, in fact, the structure was already there. The SVN commit 632 has seen them in. See for yourself the result of

ctioga --xpdf --math --interpolate 'sin(x)' --scale yticks 2.2 --angle xticks 45

As with the title and other friends, options are available, to control the shift, scale and angle of the ticks. However, the color cannot currently be changed this way (this is a Tioga limitation).

Profiling Ruby/C applications

As mentioned in a previous post, the current function for reading plain text datafiles (Dvector::fancy_read) is slow. Really slow. So I decided to switch to a C implementation keeping the same functionalities.

I quickly did a rough translation of the function into C, using basically the same mechanics (and in particular using Ruby regular expressions for parsing), and I was surprised when I found out that I was only winning a factor of around three in the speed of reading. I was even more surprised to see that the reading is O(n²) (reading 100000 lines is around 100 times slower than reading 100 times 1000 lines !). So, I decided I should try my luck with a profiler.

My first step was naively to compile the library with the -pg gcc option, but that didn't produce any output file (although it might have been due to the fact that I forgot to add the switch again for linking). I attributed that to the fact that the whole program should be compiled with the switch, and not only the shared library. So I did write a small C wrapper, compiled it, and ran it. It did produce a gmon.out file, but gprof was unable to give me any interesting information from that. I guess I needed a finer granularity that my own functions, and for that I should have compile Ruby with profiling support. Well. Drop it.

So, I was about to give up when I thought about valgrind. Valgrind also comes with a profiler tool, callgrind. So, I ended up doing the following:

~ valgrind --tool=callgrind ./fancy_read
~ callgrind_annotate callgrind.out.24425| less

The first command runs the program with valgrind, saving data into a file called something like callgrind.out.24425. The second parses this file and displays the number of intructions spent in each of the most significative functions. Here is a extract of the output:

306,777,466  ???:__printf_fp [/lib/libc-2.6.1.so]
226,575,122  ???:0x0000000000041C20 [/lib/libc-2.6.1.so]
121,900,026  ???:0x00000000000805F0 [/usr/lib/libruby1.8.so.1.8.6]
 98,208,889  ???:__strtod_internal [/lib/libc-2.6.1.so]
 90,449,474  ???:0x00000000000482D0 [/lib/libc-2.6.1.so]
 87,300,200  ???:vfprintf [/lib/libc-2.6.1.so]
 84,197,045  ???:ruby_re_search [/usr/lib/libruby1.8.so.1.8.6]
 71,866,550  ???:0x0000000000071D60 [/lib/libc-2.6.1.so]
 65,387,136  ???:0x0000000000071380 [/lib/libc-2.6.1.so]
 62,784,967  ???:0x000000000004A9F0'2 [/usr/lib/libruby1.8.so.1.8.6]
 61,279,027  ???:0x000000000004AC80 [/usr/lib/libruby1.8.so.1.8.6]
 48,357,879  ???:malloc [/lib/libc-2.6.1.so]
 41,915,985  ???:free [/lib/libc-2.6.1.so]
 34,200,000  ???:rb_reg_search [/usr/lib/libruby1.8.so.1.8.6]
 31,432,232  ???:ruby_xmalloc [/usr/lib/libruby1.8.so.1.8.6]

This shows that most of the time is spent displaying the data. Normal, half of my program does only that. Then, a fair amount of time is spent in strtod. Nothing to improve there. Another fair amount is spent in regular expression matching, and then, a significant part of the processing time is actually spent on memory management ! Dreadful ! I guess there's not much more I could do

The conclusion to this is that if you need to profile something, use valgrind. This is much more powerful than gprof !

SciYAG goes on...

Well, work is going on on SciYAG. I added an view to select on the experiment type, and I tried for the first time a little scale up: I brutally imported my ca. 2000 data files into the program. It takes a few seconds to import, but then, it is really fast. Some remarks:

• I'm making very heavy use of the QStandardItemModel Qt class, and it scales up really easily, even with QtRuby. If you plan to make a model/view application in QtRuby, do not subclass QAbstractItemModel! The underlying model/view architecture make many calls to functions of the model, and calls from C++ to Ruby in QtRuby are prohibitive (compared to C++/C++ calls). Rather, fill in a QStandardItemModel, it is likely to work much faster.
• I'm glad it scales up nicely: the navigation between my 2000 data files is very smooth and neat.
• Currently, the function for reading text datafiles is written in pure Ruby, and it is apparently much too slow. I had planned a long time ago to rewrite that in C, and it looks like time has come to do so

wegben and inclusion of manual pages

Funnily enough, I haven't spoken about webgen yet. webgen is a very powerful static website generation tool written in Ruby. It was written with a very good plugin architecture in mind which makes it trivial to extend it.

Most of the sites I maintain (namely, SciYAG's, Tioga's and my former web page, the latter not being maintained anymore) are written using webgen. I recommend you have a look at those sites and at the website of webgen itself, you'd be amazed of the possibilities it offers.

SciYAG's website is making a heavy use of webgen's extension possibilities. I did write plugins for things as various as

• including a thumbnail of an image and a link to it with a code as simple as:

  {linkImage: Electrode_cleaning.png}

• converting automatically ctioga's shell script files into PDF, and converting any PDF into a PNG image with a thumbnail
• having a random image at every page (this really looks great in my humble opinion)
• use SVN information to display the name of the last author
• and many more things

My last addition to this wealth of plugins is a way to include a manual page within a webgen page, so that you profit from the CSS and from the navigation bar. You can get an idea of how it looks there. The source code is available as usual in the SVN repository.

KDE, keyboards and hal

This morning, when I tried to log into KDE (using kdm), I miserably failed several times... What was worse, the Ctrl+Alt+F... keys didn't want to work anymore, so I couldn't login to the console... It appeared that it is linked to a newer version of hal (see bug #442316). Downgrading hal and hal-info did the trick.

SciYAG is going on...

Well, even if I didn't post here, I've kept myself decently busy. The commit that just went into SciYAG's SVN repository sees a new step in the completion of a public release: it is now possible to edit experiment types. Here's a picture of the current dialog box for editing experiment types. It is admittedly not very comfortable yet, but it works. I'll take time to improve it later when that becomes a priority.

Of course, I'll keep you posted about my progresses !

Wodim, genisoimages and pipes

I'm just burning some saves, and I thought that while waiting for the burning process to finish, I could share some of my .zshrc tricks about this... I'm using wodim and genisoimage (Debian tools derived from cdrecord and mkisofs) to burn my disks, and here is what I have in my .zshrc to burn using a pipe:

wodim-pipe() {
    size=`genisoimage -q -print-size $@`
    genisoimage $@ | wodim -tao fs=100M \
        speed=2 dev=/dev/cdrw1 driveropts=burnfree -v \
        tsize=$size's' -multi -
}

With this function, I'm simply using the following code to burn the contents of the saves-server directory, to the saves-18-10-2007 directory on the disk:

wodim-pipe -r -J -root saves-18-10-2007 -joliet-long saves-server 

Hope you'll find this useful !!

A first draft of SciYAG...

After some time, I finally have the first working draft of the upcoming SciYAG ! Admittedly, it currently doesn't do much more than just displaying the entries, but that already is a start, because you can browse pretty fast...

Here are the main things I'll have to focus on over the next days or weels:

• Provide a decent interface to change experiment types and then, most importantly, experience values (that would be under the current window)
• Provide a way to group experiences so they share the same data when that makes sense (when they really share some experimental conditions - when the exact same buffer or temperature or... were used)
• For the first version of SciYAG a year ago, I used QPainter::drawPath for painting my curves, which was fine at that time, but resulted in much hassle and too much Ruby code (much slower than C++). So I need to switch to the new 2D framework, QGraphicsScene/QGraphicsView - which wasn't available when I started back then
• Put back all the navigation features (zoom and the like) that were part of the old SciYAG at one point in the past

As you can see, I have things to keep myself busy... I'll keep you posted here !

Hoorray !

The commit that just got into SciYAG's SVN repository is the first one that actually gets a user interface running ! There is not much, admittedly (just dummy entries for experiments you can't change yet), but, still, it shows that I've made decent progresses in the architecture. I'll keep you posted about future developments !

What I'm waiting for in the NEW queue

The NEW queue is where new Debian packages (packages that install packages which were not before in the Debian archive) are waiting for a short review before being let in. This review is mainly about legal problems, though you can find here a list of the reasons for which a package could be rejected.

It so happens that there are currently some packages which I'm interested in, and too lazy to fetch and build myself:

• Of course, the first one is freecol, which I packaged myself and can't wait for it to become part of the official Debian distribution. (and I guess that will please the original developers as well !).
• Still about games, I'm interested in the lordsawar package, which seems to be a rather neat strategic game as well.
• Finally, I've stumbled upon homebank, which seems to be a really neat personal accounting software. I'm currently using grisbi, which is nice, but doesn't satisfy me somehow. I'll post more about this if I ever come to switch to HomeBank

As a last note, please consider that the links in the list above will eventually (and rather soon) be broken, when the packages have gone out of the NEW queue. They are only here for me to check more easily the status of the aforementioned packages... So, don't go looking for them, and don't complain !

The aurical fonts for LaTeX

I've just been writing some cards for the birth of my daughter, and I've been looking for nice-looking fonts for LaTeX. I'm using the texlive distribution (Debian packages). So I've installed the texlive-fonts-extra package, and I had a quick look at all the pdf files therein:

for f in `dpkg -L texlive-fonts-extra | grep pdf`; do \
[ -h $f ] || xpdf $f; done

The [ -h $f ] || blurb is here to prevent reading the same file twice via a symlink. I found many interesting things, but not that many "fancy" fonts - apart from one package, aurical, that provides neat handwriting-like fonts. Attached is what I obtained with the \Fontlukas command. Hope you'll find this useful !

Blogger and file uploads

I pretty much enjoy using Blogger for this blog. I find it rather comfortable and neat. There is however one point I don't like much, the inability to share files easily. There are many (small) files I'd like to share, such as various configuration files, codes, patches, and the like. After a quick look, it seems that Mediafire is providing pretty nice free service, with a sleek interface. So watch for file downloads there !

Change of plans for SciYAG

Initially, the SciYAG program in the SciYAG project was intended as a direct competitor for the interactive part of gnuplot, while ctioga is definitely a good competitor of the "output" part (get convinced there). I had some part working, with a command-line working exactly as ctioga and some reasonable features.

However, with time, I found that what I'm really missing in my everyday scientific work is not an interactive gnuplot clone. As far as I can tell, gnuplot is jolly good itself for that, and we have a neat home-brewed program called Soas that does the job pretty well, and is tailored to our needs.

So, then, what ? What I really miss is a good program to organise my data. Here is the features I'm missing:

• First, I want to be able to attach meta-data to my datafiles, such as the buffer used for the experiment, the pH values, and so on. All these should be fully customizable on a per-experiment or per-experiment-type basis
• I want to be able to browse quickly to my experiments, sorting them according to their type, their values of their meta-data
• Of course, I'm interested to actually display the data, possibly massively, possibly as a function of some of the meta-data
• I also want to be able to associate series of fits of different kinds to each of the datafiles, and be able to quickly check them (visually, by displaying the fit and the data), and plot the parameters found there as a function of meta-data.
• And more !

This may sound ambitious, but actually, with a great programming language like Ruby, it is fun. A great deal of the architecture is already in place. What I'm currently working on is a way to store all the data. The trick is to make it so it can evolve easily, as I'll be using this program extensively for my own needs, and I don't want to reenter any meta-data already in. A good architecture should also please the lazy in me (which amounts to, say, 95%...) and have me type in only what is absolutely necessary - so most values for meta-data should be shared or guessed.

There is currently no release of SciYAG, though you can chance a look at it's SVN repository. Be sure I'll keep you posted about my progresses on the field !

PDF and included images

A little earlier in the evening, I had to send a document to my parents including pictures. Though the final version definitely should have high-quality pictures, I was forced to see that the version I sent was maybe slightly too big (5MB by email, when the receiver doesn't have a very fast connection, that is painful). After some experimentations with pdftops (from xpdf) and ps2pdf (from ghostscript) that didn't give satisfying results, I tried to use ghostscript directly:

~ gs -sOutputFile=biniou.pdf -sDEVICE=pdfwrite \
  -dCompatibilityLevel=1.4 FairePart.pdf  < /dev/null

What a surprise ! The output did shrink by a factor of 4:

~ ls -lh FairePart.pdf biniou.pdf
-rw-r--r-- 1 vincent vincent 1.1M 2007-10-10 22:56 biniou.pdf
-rw-r--r-- 1 vincent vincent 5.7M 2007-10-10 18:14 FairePart.pdf

A quick check with pdfimages combined with identify shows that all the images kept the same resolution. That must be a question of JPEG conversion, or something of this spirit... Then, another try is to add the -dPDFSETTINGS=/screen option to the command-line:

~ gs -sOutputFile=biniou.pdf -sDEVICE=pdfwrite \
  -dPDFSETTINGS=/screen -dCompatibilityLevel=1.4 
  FairePart.pdf  < /dev/null

Then, output file is minuscule:

~ ll biniou.pdf 
-rw-r--r-- 1 vincent vincent 34K 2007-10-11 00:09 biniou.pdf

The downside is, the output is pretty much ugly (well, you wouldn't have hoped anything good with a win of a factor of 150). Images went down from 2576x1932 to 322x241 or even smaller (depends on the physical size of the image). -dPDFSETTINGS=/ebook gave a slightly better output (for 70K), but still not good for my case... So I tweaked the pdfwrite parameters by hand:

 gs -sOutputFile=biniou.pdf -sDEVICE=pdfwrite \
  -dColorImageDownsampleType=/Bicubic -dColorImageResolution=300 \
  -dDownsampleColorImages=true -dCompatibilityLevel=1.4 \
  FairePart.pdf  < /dev/null

This gave me a pretty nice result. And this also shows that my image resolution was way too big anyway - 300 dpi is probably the best I'll get when printing... and the file produced is still ridiculously small (172K) ! I now start to realize the power of ghostscript, and I thank its authors for it !

Upload and independence !

That's it ! I've finally uploaded freecol to the Debian archives, to the contrib section (as Sun's java is not currently free and is necessary). The freecol folks have been very helpful with sorting out potential copyright and license issue, one of the authors (Stian Grenborgen) actually getting the author of a font to relicense it under the GPL !! The freecol package should be available within a week or two. In the meantime, you can have a look at the NEW queue to see in which position the package is !

In parallel, I'm happy to announce that I've won my independence ! Which also means I'll have quite a lot more free time to work on other things, such as SciYAG, my book or my various research things...

Preliminary packaging for freecol

I've just finished packaging freecol for Debian. There are still important copyright issues, but the main work has been done. It has been placed in the Debian Games SVN repository (see here). What is left now is to clear important copyright issues (essentially one font, placed in data/fonts/ShadowedBlack.ttf). Great !

freecol is dreadful !

Well, weel, I've got so many things to do (like, well, several packages to attend to, three programs to write, a book to write as well, and, last but not least, a family that will see a significant increase in size within a few days ;-)...) - but I just can't help it: I spend a decent portion of my "free time" playing freecol... Well, very good game !

dpatch and svn-buildpackage

dpatch is a simple but reasonably powerful patching system for debian packages. One of the comforts I appreciate greatly with dpatch is the ease with which one can edit patches. The following command lauches a new shell in a copy of the package, and every difference is recorded as patch 56-new-patch.

dpatch-edit-patch 56-new-patch

For those like me who like automatic completion, here is a snippet of my .zshrc to enable automatic completion for dpatch:

dpatch-comp() {
    f=(debian/patches/*);
    f=(${f%.dpatch});
    f=(${f#debian/patches/});
    f=(${f#00list});
    if [[ -n $f ]]; then
        _values 'patches' $f;
    fi;
}
compdef dpatch-comp dpatch-edit-patch svn-edit-patch bzr-edit-patch;

However, the problem with dpatch is that is doesn't play really well with tools like svn-buildpackage, in the case where only the debian diff is handled by the SCM. The following snippets of my .zshrc permits the use of dpatch even in these cases:

svn-edit-patch () {
    patch="$1"
    shift;
    target=`pwd`;
    svn-buildpackage \
        --svn-ignore-new --svn-builder="dpatch-edit-patch $patch $@" \
        --svn-postbuild="cp debian/patches/$patch* $target/debian/patches"
}

bzr-edit-patch () {
    patch="$1"
    target=`pwd`;
    bzr builddeb -w \
        --builder="dpatch-edit-patch $patch && cp debian/patches/$patch* $target/debian/patches" 
}

Just run svn-edit-patch as you would run dpatch-edit-patch. In the hope that someone will find that useful...

Debaday needs entries

The Debian package of the Day blog is looking for contributors, as can be seen in this post. If there are debian packages you use, please consider writing an entry ! Here are my views on the subject:

• It is rather quick - you don't have to write 200 lines. Just write about the way you use it !
• With the statistics page, you'll be able to get an opinion of the impact of your post.
• If you advocate the software well enough, it will gain users, which often implies a gain in quality in the Free Software world (more users means more bug reports, more patches, and possibly more contributors).

Of course, that means you'll need to write a decent entry. But for something you often use and you appreciate, that isn't so difficult. Check out their contribute page.

freecol, a great game

I've recently discovered Freecol, a great GPLed game in the spirit of Civilization, but in my opinion showing more subtlety. So, I've decided to package it for Debian (see the ITP bug 444199). Funnily enough, this triggered quite a few (mostly positive) reactions, and the authors of freecol seem enthousiastic. Great, that will be my first game and my first java package !

Ruby

Well, I couldn't really start a blog without writing a small article about this fantastic programming language, Ruby. It all started when a friend of mine posted a message about the Tioga plotting library.

He said that this library was producing great plots (he saw directly plots made by its creator, Bill Paxton). When I saw this video, I was sincerely convinced !

So then, as the library was only for the Ruby programming language, I started immediately to learn Ruby, using the Pragmatic Programmer's Programming Ruby. I found it an extremely enjoyable experience. Within an hour, I had made my first Ruby script using Tioga. Before the end of the day, I was sending my first bug report to Bill. The following day, I had already started to work on a (very poor at that time) first version of ctioga...

I've gone on working with Ruby ever since... I wrote no less than 9000 lines of code only in the SciYAG project on Rubyforge, not mentioning other projects using Ruby and the countless scripts I have written for my everyday science... Ruby is extremely comfortable to program with. A pure delight !

qtodo, a neat TODO-list manager

I've been looking for a while for a decent hierarchical TODO-list manager... I've looked around at many things, and I have been rather disappointed so far, until recently. I indeed seem to have found what I need with qtodo, which is fairly decent. Among the advantages, let's name a few:

• the format is a slightly improved plain text, which makes it suitable for reading without qtodo
• fairly easy to use
• can manage several TODO-lists at the same time

Development seems to have stopped a year ago though. I might want to try my hand at it, whenever I get some free time - or slightly more crazy than I currently am.

ctioga's new legends

Since release 1.6 of ctioga, the legends had moved away from the graph, and were not anymore aligned with the plot's internal boundaries. It might not seem much, but the look was horrible, and, even worse, a lot of white space was inserted between the legend and the graph. I've just commited a fix to the SVN repository, and it now looks nearly like before 1.6. Great !

Finally...

... I've decided to move away from my old site and old blog (based on Hobix) to switch to more conventional blogs. You're likely to find useful things about Debian, Ruby, Qt4, programs I develop, and you're even more likely to find less than useful things about basically anything.