LinLog

After six months of silence, here's a random "I'm writing this so I don't have to keep Googling it" post.

The "no whammy" game show was called "Press Your Luck". According to Wikipedia, it was hosted by Peter Tomarken and featured announcer Rod Roddy, in case anybody cares that much.

That just jumped into my head again as I was merging my private dev branch in Subversion back to trunk. For some reason - probably a version mismatch between clients and the server, which is only on 1.4 - we've been getting a lot of tree conflicts on merge. So this morning I found myself watching the merge progress saying, "No conflict, no conflict, no conflict, STOP!"

I hate upgrading Ubuntu, because every time I upgrade, something breaks. Sometimes it's small things, sometimes not so small. For instance, the last time I tried upgrading to a newer version of KDE 4, I ended up irreparably borking the installation and just switching to GNOME. (And by "irreparably", I mean messing it up bad enough that I had neither the time nor inclination to repair it.) Interestingly, the change was much less disruptive than I thought. Apparently I just don't care that much about desktop integration anymore. Chalk it up to switching back and forth between platforms all the time.

Anyway, this time the breakage was in the permission fixing script for my Sansa e280 MP3 player. The short version is that when the script ran mattrib -h to clear the "hidden" attrbiute on a directory, it just printed out the mattrib usage message, despite the fact that there was no error in the command syntax. After all, the same script had been working flawlessly for over a year in Ubuntu 8.10 and 9.04.

Well, after an hour or two of messing around and fruitless Googling, I finally stumbled upon the answer. It turns out that in the build of mtools 4.0.10 that ships with Ubuntu 9.10, the option to remove the hidden attribute has changed from -h to -H. Of course, the usage message still says -h and the man page still says -h, but it's -H that actually works. So, basically, I lost an hour of my life because somebody, whether in upstream of the package maintainer in universe, screwed up and forgot to update the documentation.

Anyway, I did my duty and filed a bug report. We'll see if anything comes of it. I'm sure it's not a high priority, though - if the Google results are any indication, I'm about the only person in the world who uses mattrib on a regular basis anymore.

I finally got around to fixing my MP3 player this weekend. I have a Sandisk Sansa e280 running the Rockbox open-source firmware replacement. Despite being a little light on capacity (8GB internal flash plus 2GB for the non-HC microSD slot), I like it a lot. However, recently the headphone jack had gotten very loose. If I jiggled the jack a little, the sound would cut in and out. After a while, it reached the point where I had to pull the cord at just the right angle to maintain enough contact to listen to anything.

Fortunately, this turned out to be relatively easy to fix. I found some instructions on the abi forum, along with links to pictures. It took a little time, but I got the headphone jack working like new again.

The main problem I had was prying up the plastic headphone jack. The plastic part is only held to the board by the metal contacts, which are soldered on. So you can just lift it off to get to the contacts themselves. However, I didn't want to use too much force to pry up the plastic, lest I break one of the contacts or crack the board. After fiddling around with it for a while, I decided to try the opposite route, taking advantage of the fact that you can see the top of the contact poking through the plastic. So, rather than pulling on the plastic, I held onto the plastic part and held the board up off the table. Then, I pushed down on the top of the contacts with a pin and they slid out without too much effort. So I bent the contacts in a bit and put small pieces of a rubber band behind the to try to prevent them from bending in the future. Then, to get the plastic back over them, I gently pushed on the top of the contacts with a straight screwdriver to guide them back into the channels in the jack.

Worked like a charm! I listened to my Sansa all day today and didn't have the sound cut out once. I was starting to fear I'd have to get a new MP3 player. And while the Sansa View and Sansa Fuze look nice enough, and have high-capacity microSD slots, Rockbox isn't stable on them yet. And frankly, Sandisk's native firmware isn't that great. If nothing else, I just like that Rockbox lets you use both database and file system navigation. Not to mention those handy plugins and the extra media formats.

OK, I'm not crazy! At least, not for the reason I thought.

I was playing with adding some dependencies to my Selenium PHPUnit tests. See, PHPUnit 3.4 has this handy little test dependency feature, the @depends annotation. It's basically a PHPDoc comment that includes a test name. You add that to a test and, if PHPUnit hasn't run the dependency yet, it skips the current test.

Well, I'm working on Windows. And every time I added an @depends to a test, PHPUnit would skip it. Even if the dependency had run! Even on the example from the documentation! I thought I was losing my mind.

However, it turns out that it's a known bug in PHPUnit. Basically just a line ending issue. The bug ticket has a 2 character patch that fixes it, or you can just save your files with UNIX line endings. Go figure.

Update: Wow, talk about weird timing. It turns out this issue was fixed in PHPUnit 3.4.1, which was released the day after I posted this.

Here's a weird little "feature" I came across the other day. It seems that Selenium discriminates between spacing in source and rendered HTML. I suppose this shouldn't be that surprising, but I just hadn't thought to account for it.

Here's what happened: I was writing a Selenium test case using PHPUnit's Selenium extension and I kept getting a failure on a simple assertTextPresent() call. I checked the page manually, and the text was definitely there. I selected the text and right-clicked to try the assertion in Selenium IDE, and it worked there. Then I tried copying the expected string out of my PHP test case and checking that in the IDE, and that's where it failed.

The only difference: one extra space in the PHP string. The real kicker is that that space is present in the page source. But when I stopped to think about it, it make perfect sense. Selenium interacts with the page through the DOM, and multiple spaces get rendered as one in HTML. The source is irrelevant - it's the rendered code that counts. I'll have to remember that for next time.