Dysfunctional Programming

Breaking news: breakpoints now exist in the debugger. There’s no indication that they exist until execution reaches them unless you look in the console window , but they’re there! Next up: differentiating between active line, current line, and line + breakpoint in the robot editor syntax highlighting. Apart from that, the debugger is now fairly functional – stepping, continuing, and breaking, and most importantly quitting are all zipping along as happy as can be.

1. Replace all of the contributor’s code in one large commit
2. Use none of the original code in the new revision
3. Include thousands of lines of code churn in addition to the multi-thousand line rewrite in the commit
4. Use a commit message like “more changes”
5. Do all of the above with no advance notice whatsoever

Seriously. Who does this? Why? Do some people simply have no concept of proper project management and good development practices? I’ve just lost all of my willpower to keep trying to improve the project because apparently I’ve been maintaining a component that was being replaced without my knowledge! Guh. So frustrating.

Since Mozilla has embraced mercurial, and especially patch queues, with open arms, I get to deal with rebasing patches frequently. There are two ways this can happen – either you set up an external merge tool like meld to handle each conflict, or the rejected changes are dumped in a filename.ext.rej in the same directory as the file being patched. Since I do all of my work in emacs, I’ve finally got around to writing an elisp function to allow me to switch to a reject file from the original quickly and painlessly:

A simple C-c r is all it takes to switch from nsFrameLoader.cpp to nsFrameLoader.cpp.rej in the current buffer, and another C-c r will take me back to the original. Now that’s convenience!

I’m interested in playing around with Dehydra to see whether I can create a pre-review checker, hopefully to lessen the amount of nits that inevitably crop up in any patch submitted on Bugzilla. However, as always, the immediate hurdle is acquiring and building the software involved. Making dehydra from scratch involves building gcc 4.3.x, SpiderMonkey 1.7+, and dehydra itself. The instructions in the dehydra README gave me good, error-less instructions for gcc, and installing SpiderMonkey was nothing more than ./configure ; make ; sudo make install. Building dehydra was a bit hairier; here’s my final sequence of steps:

export CXX=/home/t_mattjo/src/gcc-dehydra/installed/bin/g++
./configure --js-libs=/usr/local/lib --js-name=js_static --js-headers=/usr/local/include/js/
make

Of course, I also had to go into the Makefile and add -lstdc++ because I kept receiving this error while trying to use the generated gcc_dehydra.so (thanks bradh!): /home/t_mattjo/src/gcc-dehydra/installed/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus:
symbol lookup error: ./gcc_dehydra.so: undefined symbol: _Znwj

So after all that, make check almost passes everything. I’m running into the same six errors that Roger Dicke got a few days ago, so I might try digging into that. However! I can hopefully start playing with static analysis soon, and that’s a very exciting prospect.

Update: the treehydra problem is a known regression in Spidermonkey trunk.

I’m working my way through building Rosegarden from SVN on Fedora 12, and thought I would jot down my settings for posterity. My default QTDIR was incorrect for Qt4 (/usr/lib/qt-3.3), which made configure fail. Following a patch in a gentoo bug for the ebuild package, I ran configure with the following inscrutable command line:
./configure --prefix=/usr/local --with-qtdir=$(pkg-config --variable=prefix Qt) --with-qtdir=/usr

It’s been about a year and a half since I last touched on the idea of a Megazeux debugger, and that is far too long! I’ve recently begun an internship with Mozilla working on the Electrolysis project, which is a continuation of the work I’ve been doing in a volunteer capacity for the past few months. This has inspired me to restart my Megazeux debugger project, with the key difference that the debugger is run in a separate process. I’ve spent a few days hacking this into a working state, and users of my debugger (namely me) are now able to choose a robot to watch inside of Megazeux, and a completely new application window appears displaying the robot editor and the watched object’s code. With this architecture, the parent process (mzx) simply informs the child (mzxdbg) which line is currently being executed, and the user can happily scroll around inside the robot and do things like place break points. Theoretical break points at this point, but they’re coming. Just you wait.