Bloggy

So, in The Beginning, when I was just a young padawan on the Internet, I had been let into a glorious secret: Emulation (not of IBM System/360 machines, but of more important things like the Super NES). Some branching from there led me to zophar.net, a popular emulation site, and their message boards, and also left me with a fascination with emulation.

The attributes of some of the older systems like the NES and Super NES made it fairly easy to capture their music-producing software, since those systems used separate co-processors to handle music effects. NES music would be stored in the NSF format, and SNES music was handled with the SPC format (named after the audio chip used, the Sony SPC700). There were (and still are) specialized plugins on many systems to play these formats (they emulated only the music chip, not the rest of the system).

I’ve been involved on the periphery of some of these things for the past couple of years. (For instance I had written a KFileMetaInfo plugin for KDE 3, and had helped Chris Lee with adding playback support to GStreamer.

One problem with the previous GStreamer solution (which I’ll call gst-spc) is that the underlying playback library, libopenspc, is written in x86 assembly, and has some crash bugs associated with it as well. As well the code has long been orphaned. I’m not really any good at writing emulation code and although I could learn, it would take far too much time for me to do anything useful.

Luckily for me the state of the art has advanced and last year I was pointed to a library called game-music-emu. This library included a very good SPC emulator written in C++, which had been merged into some popular SNES emulators already. Unfortunately it didn’t really have a great build system (using it involved simply copying it into your existing program) so my initial proposal to port GStreamer to use game-music-emu by simply including the source files with GStreamer was rejected. The GStreamer devs preferred to have an external library which could be used (or not) and I couldn’t blame them since in general good OSS projects avoid copying or forking external code.

So I contacted the game-music-emu author (Blargg) asking about the possibility of adding support for building a library, and ended up with commit access and an invitation to do it myself. Hmm.

So I did, and awhile ago I had made a release of “libgme” 0.5.5, working with Blargg has he got free time. My subsequent patch to GStreamer was accepted and since gst-plugins-bad-0.10.14 it has been possible to use libgme to playback many emulated music file types (not just SNES, but others as well).

With that solved I left the issue, but I recently came back to it since I figured out that even after upgrading to gst-plugins-bad-0.10.17 the other day, that gstreamer playback was not using libgme, but the older libopenspc.

At first I thought it was simply my fault, as I’d still had gst-spc installed from years and years ago. Removing gst-spc and libopenspc (just to be double-sure) left me with no SPC playback features. Running gst-inspect confirmed I did not have any gme decoder. WTF.

I then again thought it was my fault because I had installed libgme to /usr/local instead of /usr. So I dutifully wrapped up libgme in an ebuild and installed it. And still nothing. WTF.

I dug into the Gentoo ebuild for gst-plugins-bad and it seems that for whatever reason not all possible plugins are installed. It seems the new installation method is supposed to be that each individual plugin is supposed to have its own ebuild (i.e. gst-plugins-gme), like how Gentoo has split out other packages like KDE into individual ebuilds. Fair enough.

I write another ebuild, and finally hit paydirt:

The Qt example music player playing SPC files

Obviously this does require that you are using the GStreamer backend for Phonon to have this work, otherwise you can just try it in some other GStreamer-using application. (I’d show it in JuK but I’d have to add SPC support to Taglib first)

If you’re interested in the ebuilds I used you can use this Portage overlay, (SHA-512 sum c0ff9aa5413b0c0b14f7c52d5b3ee887edc4e7bf47182e58c21e9c340d8ff7e9). The overlay may or may not work for you, and I don’t even know if overlays are still the “hip” way to do things in Gentoo, but It Works For Me. ;)

Posted by mpyne under Computing Troubles & KDE & Personal & Programming | 3 Comments »

So if you’ve used kdesvn-build to build some of the modules that are hosted on Gitorious then you are probably familiar with an error that always comes up when doing the initial checkout. This error is so famous that every “how to build using kdesvn-build” guide I’ve seen over the past couple of months have mentioned that the clone step for qt-copy would need to be done manually.

A Konversation developer, argonel, noticed the issue the other day and got in touch with me, so I had him strace the output of the (successful) manual run and the (unsuccessful) kdesvn-build run. It wasn’t initially super helpful although it clarified what was going on (the gitorious.org end of the connect was closed on their end for some reason).

That was the conclusion of that, but then I get an email the next day from argonel saying that he’d done more digging, and that it was a known issue which could be worked around by adding the -v flag to git, which forces progress output to be displayed even if the output is redirected. (The issue has something to do with kdesvn-build redirecting the git output, if you run the git command manually but redirect its stdout to a file then you’ll see the clone fail after about 30 seconds as well).

This progress output makes the logged output look really bad, however, so the workaround I ended up implementing in kdesvn-build is to show the progress output on the terminal and redirect the rest (you may actually prefer this as it’s possible to see the progress of the checkout now).

In short, the Great kdesvn-build Git Clone Bug should be fixed. Please test the trunk version of kdesvn-build for me to make sure I got it though!

Posted by mpyne under Computing Troubles & KDE & kdesvn-build | 5 Comments »

Knocked out a few minor kdesvn-build bugs in my free time today (even if I am crazy tired now, maybe they won’t be “bugfixes” when I wake up this morning!)

Specifically:

• Fix multiple subdir log filename breakage
• Make global set-envs apply to every module (regression)
• Generate log/latest/build-status again
• Allow source-dir to be changed per module

In other good news, the documentation styling improvements I was pondering a couple weeks ago were added in time to make 4.4. Speaking of documentation, Burkhard Lück noticed that the /trunk documentation for kdesvn-build was significantly out-of-date compared to the kdesvn-build.kde.org ones (since I did not commit during the freeze), and got the updated docs imported. (And he might be able to backport them for 4.4.1 as well)

Finally if you’re as big a fan of the man and info kioslaves as I am you may have noticed that URLs of the form man:foo (or info:foo, etc.) don’t work in KRunner in the release candidate or betas (bug 221371). I think I have a fix for that which I’ll try to get in before the 4.4 tagging, but if that doesn’t happen then you can workaround by using man:/foo or info:/foo URLs until then.

Posted by mpyne under KDE & Programming & Useful Tricks | No Comments »

Maintaining the documentation for a project is a necessary, but often thankless task.

I’ve been going over the kdesvn-build documentation recently since there were several major changes to kdesvn-build in version 1.10 which I didn’t bother to document.

I’d only scratched the surface of the changes when I got fed up with the output that you get by default with our documentation generators (which is not meant as offense, just the way it is).

So, I took a detour and tried to duplicate my output-finessing feats that I had earlier performed on kio_man, kio_info, and kio_perldoc.

To see what I’m talking about first, consider the following:

• Open up KHelpCenter and look at one of the installed documentation pages. (The specific one doesn’t matter, I’m just referring to styling).
• Now look at the output of running meinproc4 with the kde-web.xsl XSLT stylesheet. (meinproc4 is the tool that KDE uses to convert the DocBook XML source to the output HTML). The kde-chunk-online.xsl output is similar. Remember that logo? :)
• The docs.kde.org output is looking a bit better, but still out of date.
• Finally, the kdesvn-build website has my current results at this time.

Now I am neither an artist nor a web designer but I do think that the output is starting to look better. (The content itself is still mostly out of date but I’ve at least updated the command line options and configuration options tables).

So now my question is, is this something I should work on trying to integrate back (at least for KHelpCenter stylesheets, since that output looks broken to me in the header)? I think our “spit and polish” on our user-interfacing documentation could go a lot way toward making the documentation more pleasant to use. And better yet we are outputting specifically for one of the most advanced HTML engines in the world so there’s no reason for us not to use every useful feature if it makes the output nicer, no?

Oh, I changed the git checkout/update procedure a week or so ago in trunk, if you’re not testing it I would appreciate it if you could test so I can do the next release this upcoming week without me being the only one to use it. ;)

Posted by mpyne under KDE & kdesvn-build | 2 Comments »

So I woke up this morning to notice that my kdesvn-build --refresh-build run from last night had a hiccup somewhere:

The problem was kdelibs failed to install, which meant every subsequent module error-ed out during the CMake process. The problem with kdelibs was related to me having an old library installed in my Qt directory since I hadn’t cleared out my Qt/KDE installation directories first (whoops).

It would be really annoying to have to type out each module to build just to skip the first four that had built right. Luckily I don’t have to do that, instead this sufficed:

$ kdesvn-build --no-src --resume-from kdepimlibs
Script started processing at Sat Dec 12 19:04:24 2009
< <<  Build Process  >>>
Building kdepimlibs (1/21)
        Preparing build system for kdepimlibs.
        Removing files in build directory for kdepimlibs
        ...

The magic here is the --resume-from command line option which skips until the given module in the build process. --no-src is only available since kdesvn-build-1.10, use --no-svn if you haven’t upgraded yet.

Posted by mpyne under Computing Troubles & KDE & Useful Tricks & kdesvn-build | 1 Comment »

Now Konversation has also switched to git.

Peter mentioned it being unfortunate that there was not a way to build Subversion and git modules with the same tool. Except that there is, and has been since October (and even before in the summer if you like unreleased code). kdesvn-build. Yes, I know I still need to rename it, I’ll get to that eventually ;)

Anyways, here’s what I added to my existing kdesvn-buildrc to build konversation:

module konversation
    repository git://gitorious.org/konversation/konversation.git
    branch master
end module

Now one catch is that scripts (including Michael Jansen’s build tool, last I’d heard) seem to have less success running git than doing so at the command line :-(. If you do end up manually cloning the git repository then make sure you’re using the trunk version of kdesvn-build to avoid git errors later.

One possible workaround is to use the HTTP protocol for the repository instead of the git:// version, but that’s less efficient so I’d really prefer to find a way to make git always work from scripts instead.

Anyways, congrats to the Konversation developers on continuing to blaze the git trail for KDE.

Posted by mpyne under KDE & kdesvn-build | 4 Comments »

So it’s been a busy month for me:

At work I’ve qualified as an instructor, qualified as Command Duty Officer (basically the senior-most officer on duty when everyone else goes home for the day), and just today I’ve become the Division Director for my division. Basically it just means way more work (I spent 10 hours at work today…) but on the other hand I’ll eventually get my picture on the posted Chain of Command pictureboard at the entrance. Not sure that’s the best tradeoff ever but that’s the major job I was assigned here for in the first place so onward I’ll go.

My class has a sense of humor. I mentioned yesterday that we always ran out of a particular flavor of coffee creamer first while underway. When I walked into the class today there were two little individual-sized creamers waiting for me. :)

On the KDE front, I sent the KDE.news story about Sheldon’s T-shirt to a friend of mine who watches Big Bang Theory. I’ve switched kdesvn-build in trunk to not use any specific remote alias names for git repositories (since people who already had a repo clone couldn’t just use it with kdesvn-build). Finally I’ve been testing a patch to fix a JuK crash-on-shutdown bug. (My reproducer hasn’t gotten back to me though, so it may end up in trunk with me being the only tester :-/). Oh, Jeff Mitchell and Kubuntu conspired to get support for ASF and MP4 added to JuK (requires taglib 1.6, with support for MP4 and ASF specifically enabled). Still to do is to actually make a new kdesvn-build release, change the kdesvn-build name (I’m accepting reasonable suggestions!), and somehow, someway, eventually port JuK off of qt3support and kde3support.

Last (but certainly not least), on the personal level I’ve been super-busy learning LaTeX so that I could turn in two research papers (due on the same day, THANKS PROFESSORS! :P). Now I have to prepare related presentations (which I’m going to use LaTeX Beamer for).

The most somber assignment deserves its own paragraph: We received the death certificate for Emma in the mail recently. We know as much now as we did when she died; the cause of death is listed as undetermined. I need to find time during the working day to run to various Navy offices to handle the administrative mumbo-jumbo of updating my record of dependents to match. It’s still weird. Every day that I really focus my thoughts on Emma, I still don’t really accept that she’s dead. Not sure when it will finally hit me but I’m not looking forward to that day.

Posted by mpyne under KDE & Navy & Personal & kdesvn-build | 2 Comments »

Another season, another kdesvn-build release.

Big things in this release:

• The run-tests option, as suggested, tested, and improved by David Faure.
• Git support, so that you can build qt-copy and amarok (and more KDE modules if/when they switch). You need to add the repository option and possibly also the branch option to select what code to clone/update. See the sample configuration file for details.
• All KDE 3 support has been removed.
• Various bugfixes.

I expect you may find bugs with the git support, if so please let me know so I can fix. There are sadly still a couple of reported bugs, but the only reason I went and released this was because I had nice people prompting me via e-mail. I will fix them though, I promise. ;)

Now back to my research papers…

Posted by mpyne under KDE & Programming & kdesvn-build | 6 Comments »

Sadly the title doesn’t mean I’ve gotten a job developing software. No, in this case I’ve finally bitten the bullet and joined one of the two major software developer professional organizations here in the US. In my case, the IEEE Computer Society. I suppose I may join the ACM later though.

Anyways, I didn’t actually join because of professional fealty or anything, but more because as a graduate student it’s time to start digging into the resources available in the various published journals and conference proceedings.

On the other hand you in theory get access to other useful things as well. For instance there’s some Safari Books thing that lets you read different computer-related books online. I don’t really find it horribly useful myself since you have to read it through the browser (and I don’t feel like screen-scraping it just to convert to PDF). But at the same time it’s better than nothing at all.

Posted by mpyne under Personal & Programming | No Comments »

As usual, no (coding) progress happens for me unless something else is causing me problems on my system. In this case, I had the opportunity to need to use my library dependency viewer.

Qt is nice enough to link to KIO when run under a KDE desktop, so even though ELF Library Viewer only links to Qt right now, I still get the nice KDE file open dialog. This is 99% of the time a positive feature. But for some reason the dialog was crashing and just having a horrible time handling large directories (like, say, /usr/bin). Worse yet, I couldn’t simply type /usr/bin/foo and click OK, since that isn’t working either. Hmm.

I decided the easiest thing to do would be to add support for opening files passed to the command line of my application (and I was right). Since I was working on it anyways I also ported the build system to CMake (from QMake), and so now it’s possible to install it/make packages/etc.

I’ve placed the updated version on my software page in case anyone’s interested. Obligatory screenshot is the same as two years ago:

Now it’s back to reading research papers all day. :-/

Posted by mpyne under Computing Troubles & KDE & Programming | 2 Comments »