BlaBlubbBlog

sigh Never touch a running system.

However, should you touch it, here is the quick pain relief for Java applications under Intrepid Ibex (aka Ubuntu 8.10). To be honest, I don't know if that is for Java applications in general or just for the specific one I really do use: JabRef. After installing Xubuntu (or Ubuntu and the standard Java Runtime Environment) the program looks like this (click for the whole pain):



That sucks. It only took me 3 hours searching the web (with no real result, actually, seems like that is not a common problem) to finally fix this. This is how it is has to look like (click for the relief):



The difference? The upper one is with the openjdk-6-jre that seems to be the 'preferred' choice as the Java environment for Ibex. The correct, lower one is with sun-java6-jre. And the really annoying thing is: I installed the proper Sun Java stuff right after installing the system, operating under the illusions that it will actually get used.

*Bah*. I certainly have better things to do at the moment.

This is a lesson in how to very subtly break your Ubuntu. I recently removed the Ubuntu TeX installation in favour of having a fresh texlive installation ins /usr/local. That is fairly easy to do and I am quite happy with it. However, when I applied the Ubuntu updates last Monday, two packages (gcc-4.2-doc and gfortran-4.2-doc) failed. I tried to remove and then reinstall them, but that didn't work, well, the removing didn't work in the first place, always a error that a

subprocess returned an error code (1).

Well, I didn't have the time or the inclination to start digging for the error there, the compiler docs are nothing I need regularly, certainly not for gfortran anyways. But then I wanted to install a couple of new packages today and that didn't work, because the messed up gcc-4.2-doc was hanging there in the process and there was no way to deselect it or ignore it.

So I started to look for the problem. You can find a few "don't know what that does, but it fixed it for me" gems out there of people hitting similar problems, albeit for different packages. The problem is actually in install-info, which fails with

install-info: No dir file specified; try --help for more information.

but, well, this gets called somehow in the process of the package management. And this is definitely nothing I want to understand.

At least I finally found the hint to edit the /var/lib/dpkg/info/[brokenpackage].{prerm,postinst} scripts to not call install-info to apply the updates without errors. After looking a bit more, I came across the interesting finding, that the install-info called in the packaging stage is not the install-info that is expected. In fact, the texlive installation put a new install-info in /usr/local/bin, which got executed instead of the one in /usr/sbin. Renaming the faulty one for a moment also solved the problems.

This is nasty. Really nasty. Now I need to check again what I did to the paths.

Soderele. Ist mal wieder eine Weile nicht auf der CGTalk-Front passiert hier. Zeit für die nächste Ausbeute. Insgesamt gesichtet wurden 1100 Bilder (567 2D, 533 3D), wovon letztendlich 39 ausgefällt wurden (21 2D, 18 3D). Ziemlich viel diesmal, ich weiss, aber ich war zu faul, da jetzt zwei Ausbeuten draus zu machen; sind diesmal dann halt ganz einfach mal mehr Sachen zu betrachten. Viel Spaß damit!

Silo is a "mesh and field I/O library and scientific database" which VisIt uses to read in data. As such it is an interesting thing for my data, especially for adaptive mesh refinement (AMR) data. I am torn between two options. Option one: Invent my own file format that does what I want and nothing more, though that will require me to write a plugin for VisIt to actually read the data then. Option two: Produce files that VisIt can read directly but hence enforcing a bunch of dependencies on my code.

In either case it is going to be a pain, so to estimate one side of the pain I was going to play around with Silo a bit. But I keep on not finding the sources, so once and for all (until they change the web site) here is the link: Silo.

Soon. Indeed, indeed:

...is a very useful thing. But it can drive me mad. Especially if it is not doing the same thing in different places. I am used to the standard tab completion of Bash, namely it completes as far as it is unique, then stops and shows after another tab (actually, two) a list of options. Vim, in its standard configuration, does something else, it completes to one of the possibles matches. And then every next tab completes to the next option. I guess it does make sense, as showing a list of options is not really that nice. But anyhow, I drives me mad, so here is how to change the behaviour (in your ~/.vimrc) to what I like:

set wildmode=longest,list

Well. I had planned to get some coding done today. But then, after a hearty breakfast at half past eight (don't ask), I got stuck on finally figuring out that orange Skype symbol that bothered me already the whole week. And in the end I really wasn't feeling like coding anyways this morning. Instead I was planning ahead for a proper tea time this afternoon. And for this I need short bread. One could buy the Walkers things, which are actually quite nice, but somehow they are really expensive. Fear no more, as with the right substances, it is actually easy to make your own:

620 g flour
290 g sugar
290 g starch
500 g (soft) butter
salt (quantity depending on your taste)

Put everything together and knead it until you have a smooth dough. Spread it on a baking tray with baking paper. Now use a fork to make holes in it and then bake it for 30-40 minutes at something like 150 °C. This yields: