If you’re not a bzexport user, and you write patches that are submitted to bugzilla, you’re missing out. Bzexport simplifies that process of getting a patch out of your local machine and into the hands of your reviewer, making you a happier and more productive person.

What’s supported right now:

nsCOMPtr<nsIFoo>

If you print an nsCOMPtr, you’ll see one of two things:
[(nsIFoo*) 0x0]
or
[(nsConcreteFoo*) 0x12345678]

In addition, pretty-printers chain, so if there’s a pretty printer for nsConcreteFoo*, you’ll see that printed instead of just the pointer value. Furthermore, nsRefPtr and nsAutoPtr are also supported, and maybe nsWeakPtr (untested).

nsCString/nsString

It prints the string inline, up to the limit specified by gdb. This probably only works for ascii strings at the moment; the code is a bit of a mess.

nsTArray/InfallibleTArray

You’ll get output along the lines of [0x12345678, 0x12345678] at the moment. Like the smart pointers, each printed element will be pretty-printed if possible.

nsStandardURL*

You’ll see the spec printed. This works wonderfully when you’re looking at an object with nsCOMPtr<nsIURI> foo, where foo is actually pointing to an nsStandardURL object.

Tagged reference counts

You know in cycle-collected objects when the refcount shows you mTagged = 0x8? Yeah, not any more.

PRPackedBool

I found the existing display of mBoolVal = 1 '\001' to be silly.

What’s coming up?

I’ve got a list of things that still need fixing/improving, and I’m open to suggestions/patches.

• Auto arrays – the kinda-sorta work right now, but it looks gross.
• COM/void/observer arrays – don’t work at all
• Hashtables – don’t work at all right now
• Stricter regexes for matching types – things like pointers to arrays are matched by the nsTArray printer right now
• Auto strings – I don’t remember if they don’t work at all or semi-work
• PRUnichar* – doesn’t work.

and so on and so forth. It’s really not difficult to write more printers, and it improves the output of gdb immensely in my opinion. Give it a shot! The instructions for how to set this up can be found in the README file. You’ll need a version of gdb > 7.2 (probably trunk, at the time of writing), since my printers rely on gdb.Type.dynamic_type.

Here’s how it works: I’ve encoded some basic dependencies into a python file (any changes to layout/build, netwerk/build, js/src, etc. require a rebuild of toolkit/library, any changes to layout/ or dom/ require rebuilding layout/build, etc). You pass a list of srcdir directories that have been changed to the script, and it prints out a list of of build commands joined by &&, ie:

$ smartmake ipc/ipdl dom/src/geolocation
make -C objdir/ipc/ipdl && make -C objdir/dom/src/geolocation && make -C objdir/layout/build && make -C objdir/toolkit/library

It’s a pretty dumb tool at the moment, and there are certainly lots of edge cases that don’t actually work correctly. However, I found it useful enough in Europe that when I returned home to a different machine, I missed it. It’s hardcoded for my own setup right now, but I’ll try to make it more general if people are interested (ie. the objdir and cmd variables could be read from a config file). Hit me up with any requests or if you have wonderful ideas for how to improve it.

Update: I’ve genericized it a small amount. Now, you’ll need to create .hg/.smartmake like so:
[smartmake]
objdir: objdir/
cmd: make -C
before the updated smartmake will allow you to continue. Notice that this is per tree, not global. Furthermore, smartmake.py is designed to be used as a tool that outputs a command line – I have a shell alias that pipes its output to sh.

python cancel.py

will be enough to get you going – you’ll be prompted for your username, password, branch and hg revision. The builds displayed also show their state (running, pending or complete) as well, so it’s easier to find what you’re looking for. Let me know if there are more changes you’d like made!

I’m a big fan of the self-serve tool that RelEng provided for people with LDAP access. When I can see a try build going bad, I can cancel all the remaining builds and free up resources, or retrigger completed builds if I want to get extra results. Unfortunately, the server is fairly slow to respond and the UI to perform these actions is clumsy. Luckily, there’s a really simple API available to allow anyone with access to make use of these tools in more traditional (read: non-graphical) means. Allow me to introduce you to a new repo I set up today to make working with the self-serve API easier – self-serve tools. selfserve.py contains simple wrappers for every API point exposed, and some basic documentation of the values returned by most of the calls. cancel.py is an example of a really simple tool that can be built on top of the wrappers to allow for bulk cancellation. Here’s what a session looks like:

[jdm@Phaethon self-serve-tools]$ python cancel.py -u "jmatthews@mozilla.com" -p my5ecureP4ssword123 -r 306838f27b33 -b try
1: Linux x86-64 tryserver leak test build
2: Linux tryserver build
3: OS X 10.6.2 tryserver build
4: WINNT 5.2 tryserver build
5: Maemo 5 QT tryserver build
6: OS X 10.6.2 tryserver leak test build
7: Maemo 5 GTK tryserver build
8: Android R7 tryserver build
9: Linux tryserver leak test build
10: WINNT 5.2 tryserver leak test build
11: OS X 10.5.2 tryserver leak test build
12: Linux QT tryserver build
13: Linux x86-64 tryserver build
14: all
Builds to cancel: 1 3 5
Cancelling Linux x86-64 tryserver leak test build
Cancelling OS X 10.6.2 tryserver build
Cancelling Maemo 5 QT tryserver build

This is just the first cut, but I’m excited not to have to use the web interface any more. Please feel free to add further documentation, or even new tools! I’m excited to see what other people can build with this.

When you see a construct like this, you should be wary:

There’s a common misconception that timers retain an extra reference that is released after they fire. This is false. If a timer is created and stored in a locally-scoped variable and the scope is exited, the timer is at risk of being garbage-collected before the timer fires. To combat this, store a reference to the timer elsewhere – a member of an object that outlives the current scope, a global variable, it doesn’t matter. Do your part – save a timer’s life today.

• My estimating skills are severely underdeveloped
• How to make use of the cycle collector
• How weak references work
• Best practices for XPCOM reference counting
• There’s a confusing thing called nsIClassInfo which I should learn more about, but I know enough to force it to do my bidding for now
• How non-modal prompts work
• The meaning of obscure GCC linker errors like “undefined reference to vtable”
• How to implement an XPCOM object in Javascript
• Implementing XPCOM objects in Javascript frequently results in much more pleasant code than C++

Having said all that, yesterday I got the Fennec geolocation permission prompt to appear when triggered by a content page, and the proper callback was called when I allowed or canceled the request, so I’m confident that I can have a patch up for review by the end of the holiday weekend. Of course, given my track record, that means it might be up by the end of the week.

It turns out that swapping back and forth between the reject and the original in a single window felt was quite inefficient. With these changes, the reject opens up in another window (think emacs terminology here) on C-c r, and I can kill it later with C-x r. This also works better with other modules like uniquify – the code from the previous post would fail when trying to access rejects associated with buffers name “Makefile.in|ipc”. No longer must you suffer the indignity of process! Merging can, and should, be fun! BEHOLD MY WORKS AND DESPAIR.

It wasn’t quite that easy – since Megazeux uses a non-standard configure script, I had to correct a few faulty assumptions. I never figured out the correct way to use

/usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config

instead of the default one, so that got hardcoded somewhere. Also, Megazeux relies on libogg and libvorbis, which haven’t been pushed to the fedora repository yet (packaging limbo ahoy!), but I was able to grab some rpms that the mingw32 packager helpfully left lying around. All in all, a very successful and satisfying experience.