Geek Goodies: Interstella 5555 (aka Daft Punk’s Discovery album)

A few years ago, I was watching Cartoon Network’s “Toonami”, and they had a special music videos night. I was very impressed by what I saw. Two groups leapt out at me: Gorillaz (“Get The Cool Shoe Shine!”), and Daft Punk (“More than ever, hour after hour, work is never over”). I eventually bought the albums and found Daft Punk’s work to be pretty good, Gorillaz’s to be okay.

Fast forward to today. I’m browsing through the local used music/movies store, and I come across “Interstella 5555” in the house music videos section. The subtitle is “The animated house musical.” As I am a casual fan of anime, I thought, “Okay, this is interesting.” Then I looked at the bottom of the cover, and saw some very familiar anime faces, from Daft Punk’s music videos.

I was pretty happy. Twenty bucks was a bit much to pay for twenty minutes of video, though, I thought. Then I saw the back cover – 65 minutes. In other words, the whole Discovery album as anime! The best part is I found another copy, used, for only thirteen bucks.

I never expected I’d get to see these anime music videos again. This is, for me, an instant collector’s item. You might think this is a cult item, but hey, we are human after all. 🙂

Article: Linux’s Legal World After SCO

by Pamela Jones of Apparently Linux is ready for the business world. I particularly like the quotes on page six, including this gem:

No FOSS developer would ever pretend that a browser was part of an operating system, for example.

And this:

People Know Now that You Can Make Money with GPL Software

Now if only it was ready for the desktop… 😉 I wonder if Asa would like to update his opinion…

The Mac Mini pays off

About twelve hours ago, I was asked to expedite a patch for the Gecko 1.8 branch. Since I usually don’t play around on the branch, this wasn’t quite trivial. On my personal Windows box, I had uninstalled MSVC++ 6 several months ago, so that option was out. Ditto for my corporate Windows box (which never had it installed in the first place).

On my Linux operating system, I successfully compiled and ran a 1.8 branch build. Unfortunately, being rusty with gdb and ddd, this proved useless in terms of diagnosing the problem. If I knew how to debug in Linux properly, loading the right libraries and setting the breakpoints, I’d’ve had no problem.

So I switched to the Mac Mini I bought a couple weeks ago. Again, I successfully checked out, compiled, and ran the 1.8 branch build. I followed the instructions on using XCode at devmo, and got a little confused when they talked about Project Builder in the same sections (without giving me the rest of the details on XCode use). When I realized XCode and Project Builder were two different products entirely, it became relatively easy to set the breakpoints in running code and hit them – which led to me finding the cause of the problem I was looking for.

Ultimately, it turned out the problem I was researching wasn’t really applicable to the 1.8 branch. But that’s irrelevant. With relatively little trial and error, and the docs available on, I was able to debug the problem as I understood it at the time. I can truthfully say that this is the first time I was able to use the Mac Mini to hack something that would have been problematic to do on another operating system – without being an expert at every stinkin’ little detail.

Now if only I could figure out the other little details, like why the “end” button doesn’t take me to the end of a textbox line… or how to switch by keyboard from ChatZilla to another window in the parent application (SeaMonkey, Firefox)…

UPDATE: Wow, I really asked some dumb newbie questions in the previous paragraph, didn’t I? I got so many responses just on that… 🙂

IDL pre-processing

IDL pre-processor Perl script and a text/plain version.

Following up on my previous post, here is evil, nefarious scheme number 692. Sample .mozconfig:

. /cygdrive/m/configs/sm-debug.mozconfig
ac_add_options --disable-mailnews
ac_add_options --disable-composer
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../nav-sm-debug
mkdir -p ${OBJDIR_CONFIG}
echo "
export:: idl-preprocess
\$(PERL) /cygdrive/m/ \$(XULPPFLAGS) \$(DEFINES) \$(ACDEFINES) --srcdir=\$(srcdir)
.PHONY: idl-preprocess

This allows me to take a file and create a foo.idl file from it. Two known bugs in it: foo.idl must exist before you call it via the Makefile rule above, and you really can’t risk compiling more than one build at a time over the directory must live in (lest conflicting #ifdef macros take effect).

Why, you might ask, would anyone in their right mind want to preprocess IDL? One of the big goals of IDL is to make sure your interfaces are clearly defined, and preprocessing clutters it up.

I answer: because I want to preprocess C++ and chrome files using the same flags. But I want to do it locally only, in my development tree.

Basically, I’m combining a lot of ongoing work into a “supertrunk” tree (evil, nefarious scheme number 691), which I’ll use to develop a lot of Web Forms 2 code concurrently. When I’m ready to create a patch, I’ll make a complete copy of this tree and use preprocessing (of IDL, C++ and chrome) on the copy to get rid of the code that isn’t relevant to that patch.

This also allows me to develop code which depends on other code which awaits reviews. In other words, I only create a new tree when I absolutely have to. Plus, conflicts when I update (after a checkin) become somewhat more manageable.

Note that I don’t recommend this script be checked into’s repository. One of the big reasons I wrote this IDL preprocessor was to avoid mixing up UUID’s for each change to the interface. Consider:

#casedef FOO
[scriptable, uuid(e78e4889-d21d-442b-b89f-ab757f40458d)]
[scriptable, uuid(6438d086-68a4-4938-a781-b88f674f3eb1)]

There’s no way in the world I’d want to see that in a patch for code. I use the switchdef structure so that when I go from one patch to another, I’ll ultimately get a different UUID for each patch to the same IDL file – which is perfectly reasonable. But I don’t see any reason to have code like this ifdef’d in’s repository. This is just to help me out on my local tree.

Missing OSCON: No regrets

This year I decided early on not to attend OSCON 2006. I enjoyed the last four OSCON’s, and simply decided I didn’t want to go to this one.

In hindsight, that was an excellent decision.

Don’t get me wrong, OSCON is a blast. It is a pinnacle of the open-source community, and well worth the price of admission. I have no doubt I’d have enjoyed myself very thoroughly and learned a lot by going again. The main reason I didn’t want to go was I needed a break.

So I’m taking a break from OSCON, away from tech heaven… and I’m having another blast working on another self-appointed Mozilla task: Web Forms 2.0.

My motivation is a bit narrow – a lot of the functionality in WF2 will also be useful for Verbosio. But by my beginning to implement it, Firefox trunk and SeaMonkey trunk will pick up a sizable boost in HTML form capabilities. Some of these I’ll borrow from other XUL toolkit improvements (such as the date/time pickers Neil Deakin just blogged about), while other things XUL toolkit will itself inherit from my work.

I also just figured out an old trick (old enough to where CVS blame’s log comment says “Free the lizard”), not well documented.

Here’s a sample .mozconfig file:

# Include another .mozconfig, so we do everything incrementally
. /cygdrive/m/configs/nav-sm-debug.mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../ifdeftest
mkdir -p ${OBJDIR_CONFIG}
echo "MOZ_WEB_FORMS = 1

What do these do? They turn on MOZ_WEB_FORMS for #ifdef’ing code in Makefiles, compiled code, and chrome.

In other words, through a simple .mozconfig file, I can selectively activate specific preprocessor flags. This can be very useful (if I don’t abuse it, of course). I’m already dreaming up nefarious schemes for this new ability… muahahahaha…

UPDATE: Fixed a small bug in the .mozconfig above.

XUL Widgets 0.4.0 released

So what’s new this time around?

  • There are now separate CVS tags for Gecko 1.8.0.x and Gecko 1.8.x. This means different XPI packages and XULRunner tarballs for each.
  • Flat XPI’s will update to flat XPI’s in the future, as opposed to jarred XPI’s.
  • One minor bug fix to textbox.xml for validation.

Branch tags are listed under src/data/ in the XUL Widgets repository.

The purpose of this branching is to allow trunk-based and Gecko 1.8.x-based XUL Widgets extensions to line up more with their respective bases. For example, if trunk has implemented a XUL Widgets extension, there’s no need to keep that extension on XUL Widgets’s trunk. Also, new features which could not be supported on Gecko 1.8.0.x branch may now be included for trunk-based and possibly Gecko 1.8.x-based XUL Widgets packages.

The best part about this is that XUL Widgets now supports Gecko 1.8.x and trunk builds. I didn’t fully realize it before, but the packages for XUL Widgets were previously restricted to only the Gecko 1.8.0.x series.

If you installed the flat chrome edition of XUL Widgets, please uninstall version 0.3.x before installing version 0.4.x. If you update directly, the update service will return a jarred chrome edition instead.

Your test results and feedback are most welcome!

Alex Vincent's ramblings about Mozilla technology, authoring, and whatever he feels like.