X debug trick

A useful tip I found in work today for debugging deeply embedded stuff. I was in the middle of some Perl tests talking to a PostgreSQL database. The database was created at the start of the test, and dropped at the end of the test, so there was no oppurtunity to see inside it whilst the test was running.

I remembered seeing an X trick in postfix and realised I could do something similiar. So I came up with this.

system "xterm -e psql -d $ENV{DBNAME}";

I put that in my function where I wanted to examine the database. When the line ran, I got a nice new window all ready for me to inspect that database. Needless to say, it quickly revealed the problem in my code…


A useful setup for developing firefox extensions

Finally, after much trial and error, I have something approaching a usable development environment for a firefox extension. It’s based around roachfiend’s helloworld tutorial.

  1. Set up a separate development profile in firefox that you can play around with. The article Setting up extension development environment is a good source for this. I also found this in my ~/.zshrc useful:
    alias firefoxdev="MOZ_NO_REMOTE=1 firefox -p dev -console"
  2. Download roachfiend’s helloworld extension. Extract it into a directory called helloworld.
  3. Inside the helloworld directory, remove the install.js file. It’s only used by older mozilla’s and we don’t care about it.
  4. Inside helloworld/chrome, create a new helloworld directory and extract the contents of helloworld.jar into it. Then remove helloworld.jar.
  5. Edit the install.rdf so that urn:mozilla:extension:file:helloworld no longer has a ”.jar” on the end.
  6. Now we’re ready to import this lot into subversion:
    % cd helloworld
    % svn import $SVNROOT/helloworld/trunk/src
  7. The extension needs to be built and imported into firefox once.
    % zip -9r ../helloworld.xpi *
  8. Start firefox (in your development profile), do File / Open / helloworld.xpi and install. Then quit firefox.
  9. Change into the development profile directory (I chose ~/work/mozdev to make it easy to find. Then replace the installed extension with the one checked out of subversion.
    % cd ~/work/mozdev
    % cd extensions
    % uuid="{9AA46F4F-4DC7-4c06-97AF-5035170633FE}"
    % mv $uuid $uuid.old
    % svn co $SVNROOT/helloworld/trunk/src $uuid
    % mv $uuid.old/uninstall $uuid

    Of course, this will differ if you have a different UUID (in which case don’t forget to update install.rdf!).

  10. You probably want to set a property to ignore that uninstall directory:
    % svn propset svn:ignore uninstall $uuid
    % svn commit -m 'Ignore uninstall.'
  11. Start firefox and check that the extension still works.
  12. You might want to create a symbolic link to get into the directory easily.
    % cd
    % ln -s ~/work/mozdev/extensions/$uuid helloworld

At this point, you have a version of firefox, with access to a full expanded extension, which you can start developing in. Also the extension is inside subversion, so you can keep track of things sensibly. You’ll note that I imported the extension into a directory called “src”—that’s so that I can put a build script and other stuff above it, in case I ever actually get as far as releasing something.

The steps for cvs instead of subversion should be pretty similiar.

Two very good sources of documentation are: mozillazine knowledgebase: Extension development and devmo: Extensions. It seems like they held all the pieces I needed to pull this together even though I wasn’t coherent enough to spot it.


Firefox Extensions

After a bit of research, I’ve concluded that there are many different ways of developing extensions in mozilla / firefox. And they all vary over time. Most of the problems appear to surround the registration of chrome (the actual browser bits as opposed to the content it displays).

Originally, you had to register the chrome by hand. This involved editing the file chrome/installed-chrome.txt in the mozilla application directory (source: Rapid Application Developmen with Mozilla). You also had to develop your application in the same place. This is probably ok if you’re on windows, but it utterly sucks if you’re in Unix as you don’t have permission to do any of this.

Later on, along came firefox with it’s extension manager. This let you easily install extensions into your profile instead of system wide—a blessing for us Unix users, and probably making life easier for windows users too.

Developing under this setup now used install.rdf and chrome.manifest files. I have no idea if you can develop using the “edit+reload” style with this version.

Now, for firefox 1.1, the extension manager has changed again. And it’s all different. Whilst I understand all the reasons for doing so, the lack of documentation about how all this fits together is very annoying for people trying to develop against a stable platform.

But, looking at the docs shows that extensions really should be easier to get going with this new method. I hope.

Of course, all my troubles are probably because I’m using Ubuntu’s version of firefox instead of one of the official builds…



I use bogofilter for spam filtering. However, I’m getting quite unhappy with it. It has a nasty tendency to corrupt it’s db files resulting in messages like this:

bogofilter[9794]: error: the data base file size is only 16 pages
bogofilter[9794]:        below the resource limit. Cowardly refusing
bogofilter[9794]:        to continue to avoid data base corruption.
procmail: Program failure (3) of "bogofilter"
procmail: Rescue of unfiltered data succeeded

Not only that, even when it’s working, it’s not as effective at preventing spam as the system we have at work: dspam. So it looks like I’ll hav to invest an afternoon into learning how dspam works and getting it all set up. I hate being forced into wasting my time at the whim of other people on the Internet.


Firefox Plugin Development

I’ve tried a few times to play with firefox (or it’s parent, mozilla) in order to write a plugins. There’s no shortage of ideas that I could implement… But every time I get stymied at the first step: getting the development environment set up.

This time, I was following Getting started with extension development, which looked like just the ticket for getting going. Everything laid out in nice, easy steps. Except that I can’t make it work. The extension manager plainly refuses to see the extension I have created. And I have no idea why, because there appears to be no logging at all.

I’ve actually purchased two books on mozilla development over the years, but whilst they have good coverage of the innards, they have less than stellar coverage of how to get there.

Whilst I like firefox greatly, I do wish that it was more like Emacs in how it exposes its development functionality. That’s a lot easier to get started with.

Update: Pilot error. I failed to notice the “requires firefox 1.1 or better” notices contained within…



Top top for using irb, the interactive ruby environment. Stick this in your ~/.bashrc or equivalent.

irb --readline -r irb/completion

And now you get nice completion of class and method names inside ruby. Lovely! Just like Python’s rlcompleter.

More info from Why’s Poignant Guide (which could use a few anchor’s).

As a side note, Ubuntu really needs to learn to install a few more Ruby packages by default. It’s missing webrick, yaml, irb, ri, erb and a lot of other stuff that should be standard in ruby 1.8. Grrr. Oh, it’s a bigger problem



I’ve just finished reading Practical RDF for work. My conclusions:

  • RDF/XML makes my brain hurt.
  • RDF still seems a way off being “practical.” I’m with Tim Bray on this one.
  • Some of the frameworks for RDF still look pretty cool. I had a quick play with the Python rdflib and was quite surprised at how easy it was. Jena and Redland also look good.
  • Ontologies seem like a good idea, in the same way that DTD’s (well, RelaxNG+schematron for preference) are a good idea for plain XML. But they’re still way over my head. I’ll have to go back and reread that bit of the book when I’ve got a less fuzzy head.
  • Mozilla’s use of RDF to build treeviews is pretty cool. I must play with that.

On the whole, I’ve learned a bit about how it works, and I can definitely see how it would be useful for some of the things we do at work with a relational database. But it’s a large rearchitecting to do so. Also, the book has let me know how much more I have to explore once I’ve put a bit of groundwork into understanding the basics.



Rake is Ruby’s equivalent of make(1). Martin fowler has just posted an excellent article, Using the Rake Build Language, which explores how it works, using his own site’s build file as a comparison. It also compares it to make and ant. I find it really nice how easily Ruby lets you build your own little Domain Specific Language. It doesn’t necessarily look much like Ruby, but that’s because Ruby really doesn’t have much syntax itself.

It’s worth remembering this introduction because if you play with Rails, then you get a Rakefile thrown in for free.


Perl Best Practices

Yesterday, I was reading Perl Best Practices on the train. I got nearly half way through in three hours. Then I came home and finished it off. I was completely taken by surprise as to both how readable and how incredibly useful it was.

Conway is excellent at explaining not just what is a best practise, but why. He’s certainly got me to reevaluate the way in which I work. The book made me realise that some of the ways in which I code are alright now, but certainly aren’t conducive to easy maintenance of code.

But perhaps the best bit are the sections on OO Perl. Whilst Perl has long been known for having fearsomely weird OO (in fact, Conway wrote the book on OO Perl), in Perl Best Practices, he manages to talk you, very sensibly, through something called “inside-out objects,” which are a great deal more secure than the default Perl way of OO. In typical Conway manner, he starts small, with a simple implementation, then builds on it and builds on it, until you end up with something remarkably useful. And then at the end, he says “of course, you can always download the CPAN module Class::Std to implement all of this for you.” So you’ve got the idea behind the module, but you don’t have to do any work to actually implement it. It’s a bold step, coming up with a radically different Perl OO scheme, but he appears to have done it well. Others have tried and failed, let’s hope he succeeds.