Here and there.

Other than that I got a pretty usable answer for my question here.

Wow, I really like the lilypond community. :)

Long time no blog, mainly because I'm pretty busy with real life.

So yesterday I got an answer on the asciidoc list about how to do C++ source hilighting that works with html and pdf output as well. The problem is that source-highlight (used for html) and docbook have a different name for this crappy language.

The solution was to do

:cpp: cpp

Which says "if docbook, then c++ otherwise cpp", and then I can just use

----
code
----

Yay!

It isn't exactly there yet, but it's in their queue. :)

The m8r guy asked me to link it in the doc, but I'll wait till it's at least part of experimental (or maybe better till it's part of contrib).

We hit this bug after I upgraded asciidoc on the server where we build the Frugalware documentation, luckily I just had to backport the given patch from hg and it now works fine.

I like how responsible the upstream (Stuart) is. Asciidoc is not bug-free, but as long as one provides simple reproducers, he quickly fixes bugs, yay! :)

So I was playing with iSCSI, and the tricky part was that I shared out a block device to a Windows one and the silly OS created a partition table on it, but the block device was an LVM LV. So it was like /dev/mapper/foo-lvol0, and of udev did not create /dev/mapper/foo-lvol0p1, so it was hard the mount.

Next example about hacking Frugalware is useful, we had this problem while generating the USB installer image as well, the trick was to mount /dev/mapper/foo-lvol0 with -o offset=32256, and this works generally as long as the partition table is an old PC one (so it's not an MS dynamic disk or anything).

Okay, so this was a bit tricky, I was about to give it up, but then after 2 hours of RTFMing I got the solution. ;)

The goal was to emulate jdk1.3 with openjdk.

The first trick is to enable the binfmt_misc handler of qemu, as you'll need jre1.3, and the self-extractor of it is an i386 code. pacman -S qemu, service qemu start should do it.

The rest is just a Makefile, something like this.

It was tricky to figure out the right options for the postprocessor (as I was using an odbms) options as well, but that's not a so interesting problem anyway.

I just got an audio CD and they wanted me to grab it (copy+compress to mp3). I think last time I did so about 8 years ago? :) Those days I used xfce and I used first grip then I wrote a perl script that used lame, cdparanoia, mp3info and cdlabelgen (it lacked cddb support).

Of course I did not maintain my script so it stopped working with the updated upstream tools, so I was searching something simple, like grip but preferably a qt/kde one.

When I inserted the audio CD, it offered to compress it, it started KAudioCreator. And yes, the usual kde quality, it just worked. :)

I just got my freedesktop.org git account, since ooo-build is moving there from svn.gnome.org. The interesting part is account maintainance - basically I had to submit my gpg key and as long as I gpg-sign my messages, I even can change ssh keys via email, automatically. That's nice, but the reply to my messages are weird - they are gpg-encrypted, but not in a way mutt can automatically decrypt.

They note in the wiki that they borrowed the account admin system from Debian - problem located. :P

Snip. When I created the tmp libwpd-java homepage, I used hilight in asciidoc documents to color Java code. The syntax used to be:

[java]
source~~~~
foo
source~~~~

Now I needed this feature again and it seems that the recommended (required?) syntax is something new (tested with c++ only, as I needed that one):

[source,cpp]
----
foo
----

So we just got a Java task at the uni and I wanted to see what can I do on Frugalware-ppc about it, in case I build openjdk from hg.

The result is quite surprising, it works very well.

My only big problem is that it has a totally different build number, currently they are at 1.6.0b14, while the binary version is at '6 update 13', and till the source versioning schema does not match the binary one, I would not use it in a production environment.

It also seems that packaging this would take a hell of time (and even after it's done, maintaining it would be time-consuming as well), so in case they would publish prebuilt binaries, I could live with that. I just found some bin tarballs on the archlinuxppc ftp site - mailed them about them (if they just mirror it or where is the build script), but no response so far.

Okay, I learned something new, you can have a special pointer type in C++ which is not really a pointer at all.

So let's say you have a Foo class with a lot of void foo(int param); methods. Then you can have a "pointer" type 'int (Foo::*)(int)' which is in fact a pointer to Foo and it has an offset about what function does it point to.

And given that it contains an address and an offset as well, you can't cast it to void*, like you can do so with real pointers.

I had to look up the Bjarne book since I didn't really know about this at all... ;-)