Present Perfect

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.

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...

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


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...

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 0.10.15.1) 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:

test.sh

#!/bin/bash

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:

#!/bin/bash

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
Author: (HIDDEN TO PROTECT THE GUILTY)

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

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...

Last week by accident I saw that Patrick Watson was going to play at the Ancienne Belgique. Annoying, because I had no idea even though I'm on the mailing list and regularly check. So I was assuming it was sold out already.

One of the perks of having a gf working at a radio station is that that particular problem can sometimes be solved, though I would've easily gone over there and paid premium scalper price to get in.

And boy, was I glad I did! The concert was simply awesome. Luckily I illegally obtained the new album (after looking for it in 5 record stores in Barcelona and 2 in Belgium, depressing) before the concert, because he opened with 4 cuts from the new album. He nailed Fireweeds, the opener both live and on the album, from the first note. Kristien was duly impressed all through the concert as well.

This week I went Watsonsurfing a little, coming across among other things the scathing reviews on Pitchfork Media, which - Pitchfork tending to be elitist at times - only reinforced my view of the amazing gift this guy has.

I don't quite remember how I got into him in the first place, but the first hook was (I'm annoyed to admit) his voice's likeness to Jeff Buckley's. There's all sorts of singers and bands that I've tried to peg into the Buckley-shaped hole in my heart - the female Buckley (early Heather Nova), the african-american Buckley (early Ben Harper), the Buckley down under (Cordrazine), the local Buckley (Arid), however silly it is to compare. I've gotten tired of reading comparisons to Jeff Buckley.

But it was 'Luscious Life' that drew me in, and it owes more than just a passing resemblance to Jeff Buckley's work. Enough at least to draw me in long enough to discover the other sides to Patrick Watson, the effortless blend of classical influences and incredible vocal range, coupled with excellent songwriting.

Not that I needed more convincing, but today I stumbled upon a Blogotheque takeaway show with Patrick Watson (if you haven't seen blogotheque yet, and you like my kind of music, you're in for a treat - watch great bands trekking through Paris singing their songs in streets, metro stations and trains, apartments, ....).

If you don't have time to watch all of it, then take a minute to check out the fourth part. The band is outside on the street in a small alleyway, some people passing by, and they roped in what looks like a random street accordeon player to join in on their 'Man under the sea'. Around 4:15, the drummer stops banging the garbage bin, the people are softly whispering along with the chorus, and Patrick goes over to the accordeon player, brushes the guy's hand away from the keys, and while the accordeonist keeps pulling and pushing his instrument Patrick's hand start drifting over the keys to go into the song's bridge, two musicians on the same instrument. While doing so he keeps singing through his megaphone.

I'm not sure what Pitchfork where drinking when they claimed Patrick Watson a generic consensus pick, but these videos show that Patrick Watson is about as real as modern music gets. I don't necessarily like all of his songs, but they're growing on me more and more, and last week's concert, even without playing two of my favourites, was spellbinding.

His new album is fighting (equally excellent) Phoenix's new album for airplay on my CD players and computers. 2009 is going to be a good year for the P section of my CD shelf.

Last week by accident I saw that Patrick Watson was going to play at the Ancienne Belgique. Annoying, because I had no idea even though I'm on the mailing list...

While working on morituri I provided some patches to pycdio, the python bindings for libcdio, to handle CD-Text. I was assuming it was the only library or program capable of reading it (turns out I was wrong, cdrdao also extracts it). But those functions weren't wrapped, so I added them. Upstream was using git, so that was another opportunity to test my git workflow across my 3 computers.

Anyway, it was nice to get feedback that said:

Your code has been checked into pycdio. Looks very competently done and is very thorough. Thanks.

For various reasons I won't get into I don't always enjoy the results of coding contributions at work to Flumotion, the project I started. And just as much in the open source world, my contributions aren't necessarily always valued, or treated with the respect I would think they deserve :)

That usually isn't that big of a deal to me, because that's not why I do it, but getting this succint positive remark reminds me that being nice invites being nice. Something I need to remind myself of once in a while to make sure I try and act the same way.

Anyways, a roundabout way of saying I can add another project to my list of projects I've touched.

Meanwhile, on my last plane trip I took the time to autotool morituri. I've finally caved in and went with the familiar, adding a simple frontend command using my python Command class
Another tree is born. Here's the first command's output:
[morituri-trunk] [gst-git] [thomas@ana trunk]$ rip offset find
Trying read offset 0 ...
Trying read offset 6 ...
Trying read offset 12 ...
Trying read offset 48 ...
Offset of device is likely 48, confirming ...

Read offset of device is: 48.

Now, on to ripping and drive selection and TOC caching and such niceties. Someday soon I should be able to actually use this...

While working on morituri I provided some patches to pycdio, the python bindings for libcdio, to handle CD-Text. I was assuming it was the only library or program capable of...