Present Perfect


Picture Gallery
Present Perfect

booq bags

Filed under: Life — Thomas @ 13:11


At home, close to the toilet because I've needed it about 20 times over two hours yesterday evening, and a bunch more this morning. Sigh.

With such a low energy level I decided to go through some of my pending tasks, picking out low-hanging fruit. That's one of the situations in which a GTD system pays off - those wasted days of low-energy where you basically want to execute simple mechanic tasks on some list without needing to do the thinking of which those tasks are in the first place.

One of those tasks is to replace my venerable booq backpack that I got right after moving to Barcelona more than 5 years ago. It has served me well, with a few minor problems along the way (the felt on the carrying handle tearing for example, now replaced with awesome-looking gaffa tape), and now recently the zipper started tearing, which could be fixable but would just take way too much time.

I'm sure there might be just as good or better bags from other brands, but in our 21st century ecosystem we vote with our cash, so I'm going to buy another booq backpack. (If you are looking for a new bag or backpack, I recommend you give them a look. I have no idea how many people ended up buying one over the years on my recommendations, I hope there are many.)

This time I went with the BOA 3M without the Vyper sleeve. The Vyper sleeve looks awesome and cool, but basically my laptop sleeve from the previous Booq backpack still works fine, and has a top pocket (in which I store 2 USB drives, a network card, some pens, earplugs, some spare batteries) and a back pocket in which I can slide documentation, so that sleeve on its own actually works really well as a light bag just for the laptop.

The sleeve might be a problem by the time I get my next laptop though, because I doubt there will be any more 14 inch 4:3 laptops around by that time. For now it will serve me just fine.

These backpacks don't come cheap (I just paid 185 euros including shipping from Germany) but given the durability of my previous backpack, which I've basically used daily for 5.5 years, I have no doubt the pack will be worth the money.

My only real gripe with my previous backpack was the fact that I would get a sweaty back at the end of my 30 minute walk/metro ride to work. The BOA should be slightly better for that, though I guess all backpacks (except the ones with metal wire frames that lift the pack off your back) make you suffer from a sweaty back.

Looking forward to walking around with my new bag soon ! One task knocked off the list.


Filed under: Python — Thomas @ 14:43


Is python's matplotlib and pylab just a twisty little maze of global variables and mass imports, making it impossible to learn your way around by introspection ? Or is it me ?

I am getting lost in the difference between Axes, figure()'s and plot()'s...

I'm sure this would all make more sense to me if I could recall my vague Matlab knowledge from university.

git merge conflict

Filed under: Hacking — Thomas @ 11:42


For every positive experience with git there's still more than enough negative ones to balance out.

Today, I got into the situation where I was updating my gstreamer modules and one of them was apparently still in conflict. Unhelpfully, git just says:
You are in the middle of a conflicted merge.

without telling you what to do about it.

Googling revealed lots of people in the same situation, and git reset --hard would work. It looks like that would throw away my changes though. Of course that's one way out of the conflict.

I want to know what the other way is - the one where you get a change to merge conflicts.

Apparently the conflict was in a generated config file, so naively I deleted it because I wanted to check out that file again from the repository (probably an svn-ism that stuck with me). I know that in this case I don't actually need to be able to merge my changes, but I would like to know what would have been the correct way to get out of this situation.

Here's what I tried before I gave up and did a reset:

[gst-git] [thomas@level gst-plugins-ugly]$ git pull --rebase
You are in the middle of a conflicted merge.
[gst-git] [thomas@level gst-plugins-ugly]$ git diff
diff --cc win32/common/config.h
index 18dbcc4,abf941a..0000000
deleted file mode 100644,100644
--- a/win32/common/config.h
+++ /dev/null
[gst-git] [thomas@level gst-plugins-ugly]$ git checkout win32/common/config.h
error: path 'win32/common/config.h' is unmerged
[gst-git] [thomas@level gst-plugins-ugly]$ git reset -- win32/common/config.h
win32/common/config.h: locally modified

git bisect

Filed under: GStreamer,Hacking — Thomas @ 16:46


Today I finally had a reason to be happy about GStreamer having switched to GIT.

I added actual encoding support to my CD ripper this weekend. I'm only supporting lossless encoding for now. Sadly, in practice it seems the FFMpeg ALAC encoder crashes, and the wavpack one hangs for me, so I'm left with .wav (meaning no compression) or .flac

And then today I realized that some of my encoded .flac files had a strange bug in them. I wasn't sure where it was coming from, but some of my encoded files didn't play with mplayer, gave an error when using flac -d, but still worked completely fine with GStreamer and totem.

I first tried to find a different file from the GStreamer media testsuite to reproduce the symptom. south.mp3 and benow.mp3 owrked fine, but sugar.ogg reproduced the problem.

I also tried it with my installed version (0.10.8, while git master is at and that worked fine.

So that gave me two points to bisect inbetween.

Then I read up on git bisect, and started playing with it. It isn't particularly nice to do by hand; most checkouts change enough of the autotools files that it has to rerun them most of the times. Then configure changes win32/common/config.h which generates a local change. The common submodule also gets in the way. I got away with just compiling the flac plugin with make -C ext/flac before each test, so that sped up things. But there's definitely potential for human error.

Basically, you start by doing git bisect start; git bisect bad; git checkout (known good commit); git bisect good

This will leave you somewhere in the middle between the bad and the good commit. Rebuild, do your test, then either type git bisect bad or git bisect good based on the test result. Repeat until you're at the last commit.

That helped me find where the bug happened (see the bug report).

Of course I wondered immediately if I could automize this, since I wanted to make sure that the same commit broke my original files and I do not want to do that manual bisection again...

It turns out you can; that's what git bisect run is for.

So, given the following two shell scripts:



git submodule update

make -C ext/flac

# rebuilds can touch these files leaving you with local changes
git checkout win32/common/config.h

gst-launch -v filesrc location=/home/thomas/gst/media/medium/sugar.ogg ! oggdemux ! vorbisdec ! audioconvert ! audio/x-raw-int,width=16,depth=16 ! flacenc ! filesink location=test.flac
flac -d test.flac -f
# flac -d exits with 1 when it fails
exit $?

and bisect.sh:


git bisect start
git bisect bad
# 0.10.8 release
git checkout c186d67f40827be349f97d810a45243c874b73f7
git bisect good
git bisect run ./test.sh

I can now just run ./bisect.sh and it will do the whole process automatically.

Try it if you're curious on a checkout of gst-plugins-good. Change test.sh to point to your sugar.ogg file (which you can get from GStreamer's test repository).

At the end, the output should show something like:
df707c666433a78d3878af6f055698d5756226c4 is first bad commit
commit df707c666433a78d3878af6f055698d5756226c4

The 'run' command really is what makes the bisection useful for me. Now, back to bug fixing....

« Previous Page