The tale of the frontend system

I have been having problems with Yamato – the box that runs the tinderbox – for the past weeks. The main issue seem to be the system deadlocking, with in-kernel flush processes for the RAID1 devices stuck in D-state (blocking I/O operation). Among the reasons for this I didn’t exclude (yet) either problems with the hardware or with the PSU; but while experimenting I found one thing was definitely the case: it’s easier if I don’t use Yamato as the system for chat/mail/browse while it runs the tinderbox.

As a partial solution to that, I decided to order a new system to act as a frontend; since I was (and am) actually short of money, I decided to get a system that I could recycle in the future as a replacement for the AppleTV (that is bothering me to have around more and more, I wanted to write about it before, but I haven’t had the chance yet), so I ordered an ION board, with 4GB RAM, and decided to re-use an old HDD of mine (since I have replaced my main work disks last month trying to see if they were the cause of the lockups).

Altogether, the new frontend would have costed me around €300, shipment with UPS included, from the Alternate B2B store (which gives me VAT invoices I need). I ordered it on the second week of December, asking if they could please send it before the holidays, via UPS (since I know UPS usually takes no more than three days to deliver it here; they did a mess last time with the cash-on-delivery payment, but that’s not the point here). They did send it on the 21st, but not via UPS, but with DHL postal service (i.e. not the express courier). I was a bit upset, but it is also true that it costs €25 rather than €50.

On the 28th I call the Italian Post that should deliver the package to know the status of it; standing to the DHL tracking, it arrived fine in Italy on the 24th. The Italian service couldn’t even recognize the tracking number as valid or managed by their service, even though the code from an homologue shipment back in October could still be tracked fine. So they open a report and ask em to call the day after.

On the 29th I call, and I’m told that the shipment arrived in Italy the day before; they keep on stating that it is impossible for DHL to say it arrived on the 24th. I have to call the storage and processing plant in Milan to actually learn what’s going on. Luckily there they have a bit of clue on what’s going on, and they inform me that the package was left in storage at the Malpensa airport since it arrived on the 24th, as their processing only received it on the 28th, at 10pm. The time is indeed strange even for the person I’m talking with. My suspect here is that the package was “lost” in Malpensa, and they started looking for it after my phone call the day before. On the other hand, they ensure me that it was on his way to Venice and it would be delivered the day after.

You guessed right, on the 30th no package arrived; I call again their main call center, and there they tell me that the package is now stopped at a post office; they have no idea as to which, even whether it is a post office in Mestre (the mainland city of Venice) or not, and they cannot tell me why. Uh? Are you freaking kidding me? Okay I start calling the local post offices, or at least try to. The only one actually answering is the one of the town where I live; the woman at the other side of the phone ensures me that no package is ever delivered to post offices unless it was so asked by the receiver, that if anywhere, the package would have been delivered at a given post office in Mestre (the number for which is not published on the phonebook), and provide me with the number of the switchboard for Mestre.

No other post office answered the phone for the whole day; I also tried to call the courier that does the delivery for Poste Italiane here in Italy (SDA, that they bought a few years ago), but there, after the usual hold music, I could hear the phone being picked up, and then hung again. Lovely! I send a disgruntled mail to Alternate and forget about receiving the package before the 3rd.

Fast forward to today (the 8th); the package didn’t reach my house, but today the postman brought a card (that was supposed to be brought on the 3rd, but let’s ignore that for now) that the package is ready to be picked up in Mestre, at the post office that is not on the phonebook, since the 30th. This means that they didn’t even try to deliver it, isn’t it nice when you pay to get something delivered and then they ask you to pick it up the other side of town? No? No, I guess not.

The most ludicrous thing is that on the card, there is the amount to pay for cash on delivery; but added to the €283 of the Alternate invoice, they wrote €10,33 for customs duties. From Germany! There are no customs! I’m paying VAT on the order already, and it’s invoiced to my VAT ID. I also pay extra taxes with Intrastat and they add me customs duties on a parcel coming from within the EU?

So right now I’m still without a frontend system, I have yet to read an answer from Alternate, but I guess they were closed till Monday; I hope they can send me a new shipment for the same order via UPS so that I don’t have to wait another month for it, and while I could use the laptop to work from my bedroom (since I got a cold), I have to keep it here to monitor whether Yamato deadlocks again.

The day the Italian Post (which are private) will go bankrupt, I’ll be happy.

Frontends to command-line or libraries?

I know I’m still convalescing so I should be resting, not thinking about development problems, but this is something that ended up in my mind because I have one thing to absolutely do (scan the release documents from the hospital to send to my GP), and for which I miss an easy interface I could instruct my mother, or my sister, to use.

Don’t get me wrong, I know there are a few SANE frontends, starting from xsane itself, but the problem is that I don’t usually stop at scanimage when I do it from the console. What I usually do is to launch a batch scan to TIFF format, then use tiffcp to join the different TIFF files in a single file with multiple pages, and then use tiff2pdf to convert it to a PDF file, which is opened by any computer I might need to send the data to (and it also is quite smaller than the original TIFF file). Lately, I’ve started trying to add to the chain also unpaper, a tool that removes some of the defects usually found in scanning pages from books (like black borders and similar), which works on PNM (thus requiring a change in the scanning command, and a further conversion later on).

But I don’t want to start fleshing down how to actually write such a tool, or I might actually start writing it right now, which is not what I’m supposed to do while I’m convalescing.

What I want to think about is that here comes one huge debate between writing frontends for command-line tools, which just interfaces with them as process calling, or writing a full-fledged program that interfaces with the low-level libraries to provide similar functionalities.

I already happen to discuss that quite often since xine and mplayer embody the two spirits: xine has its library, frontends interface with that, and a single process is used; mplayer instead has a command interface, and frontends execute a new process for playing videos.

There are of course advantages and disadvantages, one easy to spot disadvantage to xine’s approach is that a crash or freeze in xine results in a crash or freeze of the frontend, which is something Amarok users have been unfortunately familiar with.

In the case of the scanning toolchain, though, I guess it’d be probably easier to use a frontend for the tools, as re-implementing all the different functionalities would be a non-trivial work.

The disadvantages of doing it this way, though, is that you’ll have to make sure that the tools don’t change their parameters between versions, otherwise it’d be a problem to ensure the correct functionality of the tool. Also, the tools need to provide enough options to control with granularity the execution of their task, which is something unpaper actually does, but in turn makes them almost unusable for final users.

I know I’m not going much anywhere with this post, I’m afraid, but I just wanted to reflect on the fact that to have a command line tool designed to be used by frontends, you almost certainly make its syntax so complex that users would fail to grasp the basic concepts, and in turn, you’d need a command line interface to the tool too… which is why there are so many scripts interfacing to ffmpeg for converting videos, I guess.

On the other hand, one can easily write such a frontend using scripting languages, even if it’s graphical, such as with ruby-gtk2 (think RubyRipper).

Now I know why there aren’t many valgrind frontends

valgrind has a very nice way to output information in parseable form for the memcheck (the primary) tool: XML.

You don’t really need a custom parser, you just need to read the correct elements and attributes, and you’re done. The format seems actually to provide enough extensibility so that it can be used for every tool, and so I expected.

Starting from this I decided to start working on a new valgrind frontend, in Ruby. To begin with, I started writing the abstraction, and a test suite so that I could make sure what I wrote was what I was expecting to get.

Unfortunately, when I decided to start adding the support for a second tool, to see that my code was doing the right thing with different tools, I discovered that helgrind does not output XML. Nor does massif.

So it seems that to write a frontend to something more than just memcheck (which is what Valkyrie supported), you’d have to parse the plaintext output, which is quite more difficult.

I suppose this is why Valkyrie stopped at supporting memcheck..

At this point, I suppose that to write an Helgrind frontend I’d have to hack at valgrind itself to add XML output to the tool. I think I’ll try that soon enough.

Frontends and scripting languages

So today I updated my system and seen that the new nmap version features a totally new frontend, written in Python with pygtk. While this bothres me a bit because I had to install the pygtk package with its siblings, I actually find this an interesting and useful change.

I say this because, well, frontends don’t need to be fast or to have a tight memory usage pattern; most of the times, frontends only have to take care of user interaction, and the user interaction is neither cpu, nor memory, nor I/O bound, it’s user bound.

Scripting languages don’t usually suffer from architecture problems, like endianness of variables, or missing definitions or include files moved around; well, the base interpreter does suffer from these problems, but it’s one package instead of every package.

Also, scripting languages usually makes it easier for users to change the frontends if they need, which is certainly an advantage for the part of the program – the frontend, as said – that faces the user.

This made me think about writing a new Valgrind frontend; my language of choice would certainly be Ruby, the problem is: which GUI libraries would I be using?

An year ago I was dead set on Korundum, KDE’s Ruby bindings, but I don’t think this is feasible now. The reason is of course tightly related to the KDE4 development: writing on Korundum makes little sense, considering that the focus is now KDE4, but KDE4 itself is too young to write the frontend using that. Plus there is one big problem with QtRuby: the Qt3 and Qt4 Ruby bindings install the same shared object, with different APIs, making a Qt3 Ruby program incompatible with a system where Qt4 Ruby is installed. And writing the frontend in pure Qt4… I’m not sure about that.

The alternative is to use ruby-gtk2. Even if I don’t like the GTK C interface myself, the Ruby version seems nicer to me. And with Nimbus I can finally stand GTK2 interfaces. I should probably try this out, it might be good enough to go.

Actually, with little work it’s likely that I could write a pure-Ruby abstraction for a valgrind frontend, and then two interfaces, one in GTK2 and one in Qt4. This is another nice part of scripting languages: you usually have the basic set of objects not being part of the libraries used (QString, GString, …) and you can more easily share code between Qt, GTK, NCurses, whatever you want.

So, anyway.. I need something to keep my mind busy tonight, as I’m having some real-life trouble (no, not health trouble, just… love trouble :/), so I’ll probably start tonight to work on something.