Suzanne and I are pleased to announce the birth of Madeleine Young Smedberg, born 7 May A.D. 2008 at 12:26 a.m. 7 lbs. 4 oz., 20 inches. All are well.

• In GCC, the “location” of a class declaration is recorded as the position of the opening brace. In pork, the position is the location of the class or struct keyword:

  •class A
    : public B
    , public C
  •{

• Texas A&M offers a Masters degree in Mathematics entirely online.
• Copying dmandelin’s treehydra scripts makes it much easier to figure out how to write my own analyses.
• Lazily creating a deeply nested JS representation of C++ type tree improved the performance of my XPCOMGC finalizer analysis script by 1000% or more, and made the code more readable.

There are lots of hidden corners in the Mozilla build system. I’m starting a little series about some of the cool and unexpected things you can do with it. Of course, the series is mostly going to be “see the document I just wrote on the Mozilla Developer Center”!

First up: myconfig.mk and myrules.mk. Did you know that you can add arbitrary rules and change arbitrary variables in the Mozilla build system without editing your source tree? You can, by simply dropping a myconfig.mk or myrules.mk file in the objdir/config directory. Let’s say you want to define PL_DHASHMETER in all of Mozilla, so that you can then run Mozilla and collect hashing statistics.

Copy the following file to objdir/config/myconfig.mk:

CFLAGS += -DPL_DHASHMETER
CXXFLAGS += -DPL_DHASHMETER

This is not a very impressive example, because you could achieve the same effect by exporting CFLAGS and CXXFLAGS in your environment before configuring. So check out the Mozilla Developer Center article, which has two additional examples adding a new makefile target and altering build rules to save static analysis output to disk.

Brainstorm of possible improvement: load application/app-config.mk and application/app-rules.mk for application-specific build configuration and build rules.

preed’s post about a new owner for the Build & Release module in Mozilla reminded me to announce more officially that I’m handing over ownership of the Mozilla “Build Config” module to Ted Mielczarek (ted on IRC). Ted has been involved with the Mozilla project for a while, and has done great work with the build system, Breakpad, and other projects.

Being owner of several large modules is tough: it’s hard to just keep track of everything that’s changing in Build Config, “the toolkit”, and XPCOM, let alone provide effective leadership. I’m blessed that I can transfer part of that responsibility without fear. It will allow me to focus my efforts more effectively, particularly to lead some of the architectural changes we’re making for Mozilla 2.

Congratulations Ted!

Automatic rewriting uses as much CPU as you can throw at it… a full automatic rewriting pass takes about an hour on this 8-core machine.

In the brave new world of distributed version control, history is no longer linear. It can branch freely, under no central control. But what is perhaps more interesting is that you can merge disparate branches back together. This makes it much easier to do long-term feature work, because it is possible to track a moving target. For the ActionMonkey project, we are following a procedure where all changes are reviewed before they are pushed to the actionmonkey branch. This means that we won’t have a huge blob of changes that need review before they are integrated into mozilla-central.

This creates a new class of problem: how do you perform merges? Is it necessary to review merge changesets with the same rigor as regular changes? How would one actually go about reviewing a merge changeset?

Today, I wanted to update ActionMonkey with the latest changes from mozilla-central. There is enough divergence between ActionMonkey and Mozilla 1.9 that this is not always a simple task: fortunately for me, the only conflicts that required any real merging were fairly simple. I went ahead an performed the merge and did some basic testing. But I really want Jason Orendorff to review my changes for sanity. There is no simple way to see what I actually did:

• Interactive graph of changes
• hgweb view of changes

It isn’t hard to diff this changeset against its mozilla-central parent, or against its actionmonkey parent. But neither of these diffs give you a sense of the real work involved in the merge. What I really want to give to Jason is a static view of a three-way merge as it already happened, highlighting the source locations where I made conflict resolutions or manual changes. Does anyone know if such a tool exists for Mercurial, or for any other distributed version control system?

Because I don’t know of a tool like this, I did the next-best thing: in my checkin comment, I carefully listed every file and function where I made a conflict resolution or manual change. This will at least make it clear in the future where I may have goofed.

Developers were trying to build Mozilla on Windows and having failures 75% of the way through the build process, with error messages about missing headers. Depending on their configuration, any of the headers listed above may have been missing. I know MS tries: this is not malicious breakage on their part, just a side effect of releasing very complex systems. But boy can it be frustrating at times. Right now we’re in a situation where you can’t build Firefox using free tools and only a single SDK, because the newer SDKs don’t have ATL and the older SDKs don’t have wpcapi.h for Windows Vista parental controls.

To fix the problem, you need to install both the Windows 2003 SDK and the Windows Vista SDK. Ted Mielczarek is working on doing a quick release of MozillaBuild 1.2.1 which will support loading multiple SDKs into your build environment. Until then, there are some custom start scripts available.

I also added some configure checks so that we can detect the absence of these header files when you first start building. This will hopefully reduce the pain and wasted developer hours futzing with headers and build environments and trying an hourlong build process again to “see what happens”.

Dear lazyweb,

I would really really love a JavaScript mode for emacs which indented “for each” correctly:

for each(let o in a) {
  // single indent
  process(o);
}

I’d love it enough to buy a 6-pack for the person who made it happen.

I think we must all have OCD. It’s interesting (to me at least) which things I launch from the GUI (firefox, emacs). Is there a way to get the “most-clicked launchers” in gnome?

tchaikovsky.smedbergs.us:~
bsmedberg $ uname -a
Linux tchaikovsky.smedbergs.us 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
tchaikovsky.smedbergs.us:~
bsmedberg $ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
271 hg
148 make
122 cd
44 less
43 rm
35 dir
33 exit
27 cvs
25 svn
18 /builds/gcc-dehydra/installed/bin/gcc

If you want to go drawing complex graphics on the web, you have two basic options: SVG and the HTML canvas element.

My first attempt at the hgweb graphical browser used SVG. Actually, it used an unholy hybrid of SVG and HTML: the revisions themselves were drawn using absolutely positioned HTML. The arrows between the boxes were drawn using SVG. I did this for several reasons:

• only Firefox supports drawing text into canvas elements
• I could use DOM events to do hit-testing and navigation
• you can select/copy/paste text in HTML

Unfortunately, the performance of the first version was not very good, and the code was very complex. I was maintaining several parallel data structures: a JS object graph, and the DOM objects for revisions and arrows. The bookkeeping code to keep data in sync was dwarfing the actual layout logic.

Instead I decided to try using canvas. Sucking out the bookkeeping code and replacing it with a custom drawing code turned out to be much easier than I expected. Now all of the data is kept in a single tree, and layout, rendering, and hit-testing are all blazingly fast.

After getting it basically working, I was able to add additional features in a matter of minutes:

• Collision detection
• Animation when navigating between revisions
• Switched to a vertical layout which provides more information
• Made arrows into curves
• Highlight the “center” node

The disadvantages of this approach are unfortunate:

• Only works in Firefox 3+ (needs the experimental mozDrawText API)
• Impossible to select or copy text

check it out (my development machine, so it may go down at any time) or get the source.

Now I really promise I don’t have any more time to spend on this project. Contributions welcome!