![[lang]](/images/eye.png)
|
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.
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: 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:
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
and bisect.sh: #!/bin/bash git bisect start 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: The 'run' command really is what makes the bisection useful for me. Now, back to bug fixing....
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:
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 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...
Today was not a particularly good day - I woke up with a huge headache around 4, took a dafalgan, went back to bed, and woke up around 8:30, still with a headache. This sort of thing happens once in a while to me, though it happens a lot less since I reduced my disorganization stress a few years ago. Anyways, that's not the point. On days like these, I can only do small incremental changes, which I guess is good for polishing. My brain doesn't let me do much more. So, I finished some loose ends in my ripping code. Here's a file listing of a directory: Notice the first file - it's the hidden track one audio. The .cue file references it properly as well. The metadata is retrieved from MusicBrainz (that got added some night last week), and the files are named according to a template (I'm still not sure I like having the track number in my file names, but a certain site demands it). The files match the AccurateRip database, so this rip is basically as good as you can get with EAC. CDText and ISRC codes also get written to the .cue file (although this particular disc doesn't have CDText). Things still left to be done, in no particular order:
That's quite enough for tonight. Hopefully I feel better tomorrow. |
|||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||