Colorize that build!

If you’ve ever built Mozilla from source or run the unit tests, you’ll know that doing so can generate a lot of console output. When errors happen, it can take a bit of scrolling to figure out exactly what failed, and where. I recently switched to pymake (because it’s sooo much faster), and it generates even more output.

Recently Shawn mentioned he had some magic pixie dust to colorize build output (which I didn’t know was possible on Windows), and I extended what he had to do a bit more. I’m finding it hugely useful, so figured I should share!

First, the pretty picture. This particular example is a bit gaudy, but shows a lot of what it does. The mostly useless nsinstall output (of which there’s a *lot*) is dark blue. Compiler warnings are yellow, errors are red.

Oh, and xpcshell tests benefit too!

To add this to your Windows MozillaBuild environment, just add this stuff to ~/.profile, and then open a new shell window.

There’s probably a lot more that could be done with this (and I’m sure it missed all kinds of interesting cases), but it’s a good, simple start!

Handy trick

If you’re involved with developing on Mozilla, odds are you’ve got at least one or two (dozen? :) profiles for testing. Some used regularly, some created-and-forgotten for one-off testing, some you’ve forgotten what they’re for. And you probably jump through gymnastics with the Profile Manager to create, select, and delete said profiles.

Once upon a time I used to do the same thing, until someone pointed out that there’s a different way to create and select profiles.

Old And Busted:

1) run firefox -P
2) Create new profile
3) Click, click, typeity, click
4) Select new profile
5) Swear, run firefox -P again because you didn’t mean to set that as your default
6) What was I doing again?
7) Oh yeah, test that thing. Quit.
8) run firefox -P
9) Delete profile
10) Lather, rinse, repeat for repeating testing with a clean new profile.

New Hotness:

1) mkdir /tmp/blah (or ~/profiles/blah for more permanence)
2) firefox -profile /tmp/blah
3) rm -rf /tmp/blah

At least for my workflow, I haven’t used the Profile Manager since. (This trick doesn’t depend on Profile Manager at all, so even it was removed at some point this would still work.) Some folks might prefer the Profile Manger for their needs, but this works great for me.

Observations from a Comcast outage.

I use a Comcast cable modem at home… I’ve been satisfied with the service; it’s fast enough for my needs and is generally dependable (brief glitches happen once in a while, which quickly fix themselves). However, for the past two days my modem wasn’t able to connect at all, so for the first time I actually had to call Comcast. A few observations on the experience…

* The first thing you hear when calling 1-800-COMCAST is “This is Shaquille O’Neal, and this is Ben Stein… Thank you for calling Comcast” (in their voices). This is a fantastic way to confuse callers, since it sounds like you’ve dialed a wrong number. Why have a celebrity voice on their number at all? I don’t get it.

* While their phone system routes your call to the right department, you get treated to a completely irrelevant advertisement for their telephony service. These kinds of forced ads piss me off to no end. [See also: long-winded offers you're forced to listen to when activating a new credit card.]

* I was amused that their automated phone service suggested that if I was having problems connecting to the internet, I could get help on their website.

* I dread calling “technical support,” because it usually means wasting time as they run though a standard troubleshooting checklist unrelated to what the actual problem is. To Comcast’s credit, I wasn’t subjected to this and it was an efficient process. The techs were nice, but I wish they had better diagnostic tools — the first two calls resulted in “your cable modem is dead, buy a new one”, and then my “dead” modem started to work the next morning!

* The scripted “I’m sorry you’re having a problem, I can assist you with this issue” phrase techs are required to say sounds really corny when you’ve heard the exact same line on each call. Mix it up a little?

* Dear Apple and AT&T — it’s just days until 20-fucking-10, and I still can’t tether my iPhone to my MacBook for internet access in a pinch? Sheesh.

Be prepared.

How I plan to survive next week’s MoCo all-hands meeting:



3 liters (aka a double magnum or jeroboam) of Stone Brewing’s Double Bastard Ale. Mmmm, I can’t wait. Team Firefox will drink well!

Mega status update

I’m terrible at remembering to send out regular status updates, so here’s a belated list of things I’ve been up to recently in Firefox-land…

* CrashKill. We’ve been making a big push to reduce Firefox crashes. I’ve largely been working with 3rd party crashes (eg bug 519340). Some of these 3rd parties are very responsive and quickly work to resolve the crashes their product is causing, others are… less so. It was surprising to me to find that other software is directly responsible for a huge number of Firefox crashes… Antivirus software, Flash, and malware seem to be the worst.

* Firefox on Tegra. Working on getting Firefox 3.6 running well on Tegra netbooks, and diving into localization issues so we can fully support Windows CE like other platforms.

* Firefox application updater. I mentioned in a previous update that my fix for bug 517102 made the updater 3x faster. I’m working on what should be another big performance and reliability boost in bug 529464.

* Password manager fixes and features. These have been in-flight for a while, but unfortunately didn’t make Firefox 3.6. But I’m pushing to wrap them up in coming weeks and get them into the next release. Notable changes are bug 499417 (refactoring the “master password” code, a first step to bigger changes), bug 499233 (finally killing multiple master password prompts on session restore), bug 465636 (add timestamps to login metadata), and bug 223636 (support automatic login for HTTP Auth).

* Rewriting the Weave’s crypto backend (bug 513798). Last year I rewrote Weave’s crypto code to use NSS (Firefox’s own crypto library) instead of OpenSSL. That’s been working swell, but it’s a binary component, and is a real pain to deal with when making Weave available on other platforms (like all the new mobile devices we’re working with). Dan Witte recently landed JS-Ctypes, which allows JavaScript code to call into native libraries. So now I’m porting the Weave C++ code to JS to take advantage of this.

* Using CSS Transitions in HTML5 video controls (bug 521890). David Baron has added support for the CSS Transitions spec to Firefox trunk, so I took a look at having our HTML5 video controls use this feature. When I implemented the controls for Firefox 3.5, I had to use a pile of JavaScript timers and callbacks to implement the fade and slide effects… CSS Transitions GREATLY simply doing such things. Currently blocked on one issue.

* Performance work. Noticed an issue with Necko not caching protocol handlers well (unknown what the perf impact is yet), looked how often we check perferences at runtime (a LOT, no bug yet), and am starting to look at the impact of all the timers we have firing and how they might be impacting power usage. Also investigating a problem with restoring maximized windows. We inefficiently restore the size, which slows down opening a window on Tegra devices (which generally use maximized windows).

* Got a speedy new Windows 7 desktop, and have been getting it configured and running.

My next big project is finishing up Doorhanger Notifications, which are a critical UI feature for the revamped Firefox 3.7/4.0 themes. Matt Noorenberghe started the implementation this summer as an intern, so I’ll be wrapping that up and making it fit updated designs.

(*phew*)

Sneaky software installs

The Mozilla Plugin Check page was released today, so I loaded it up to see the latest changes. “Looks good,” I thought, and skimmed the list of plugins it displayed for me. Quicktime, Silverlight, Flash, and… Woah, wait.

Silverlight?

On my OS X box? How the fuck did that get there? I sure don’t remember installing it. Grrrr!

A little web searching later, and I found my answer. It’s silently installed with Flip4Mac (a set of Quicktime components to allow playing Microsoft proprietary media formats on OS X), which I had installed a week or two ago to try something, and then promptly forgot about. The installer doesn’t have a word to say about it, unless you click a little “Customize” button on the 5th screen on the install:

That really annoys me. Silent, sneaky software installs are evil, evil, evil.

At least Flip4Mac includes an uninstaller, so I ran that. It’s actually a package, so you’re confusingly prompted to “Select the disk where you want to install the uninstaller software.”, but it was otherwise painless. Now to just restart my browser, check about:plugins, and…

GAHHHH! It’s still there. Their uninstaller uninstalls the Flip4Mac bits, but not the Silverlight plug. Solution:

rm -rf /Library/Internet\ Plug-Ins/Silverlight.plugin/

It’s finally dead, Jim.

Making progress

If you’re running nightly builds of trunk or Firefox 3.6, you may notice a smoother progress bar while installing the nightly updates…

The old progress bar behavior had always seemed a bit odd to me — it would do nothing for a bit, move to about 15% point, and then suddenly finish. I didn’t get around to looking at why it did that until I used the updater on a Windows CE netbook. The device is a lot slower than a normal system, so the unusual progress bar movement could appear frozen for over a minute! That’s really poor UI feedback, so I set about fixing it.

You can read the gory details in bug 517102, but the end result is that the progress bar now tracks progress more accurately, and the updater runs 3 times faster too!

Is the tree REALLY green?

While sheriffing yesterday, I was a bit confused when dbaron asked if I was looking into all the orange. The tree (http://tinderbox.mozilla.org/Firefox/) looked mostly green, except for a handful of earlier Talos oranges. So, yadda yadda, it turns out that most of the test boxes report to a separate tinderbox tree now — http://tinderbox.mozilla.org/Firefox-Unittest/. There are similar splits for the 3.6 and 3.5 trees.

This was probably announced somewhere, but 3 other developers also didn’t know this was the case. So, I figured a blog post was in order.

Tinderboxpushlog already includes both sets of data, and I’ve just updated isTheTreeGreen.com to use both sets as well.

Experimenting with build times

I got a new Windows desktop last week, and was curious if enabling disk compression would have any effect on build times… The theory being that source code compresses well (binaries too, to a lesser degree), so less disk IO should result. The price is more CPU usage, but this is a Core i7 box, so that’s basically free.

Result: Theory Busted.

Without disk compression, a full build took 23 minutes. With disk compression, 24 minutes. [Drive formatted between tests.] I’d guess some combination of not being IO bound plus disk seeks dominate, so compression doesn’t really help and just adds overhead. I also tried disabling “write-cache buffer flushing” to no effect, although I’m curious if splitting my build across two drives will help at all [src on one, objdir on the other; currently it's in a RAID-0 config].

One thing that would be nice is if parallel make worked correctly with Mozilla on Windows. If I build with anything higher than MOZ_MAKE_FLAGS=”-j1″, the build hangs at random (?) places. Seeing as this is a quad-core box (8-core, if you count HT), that makes me all sad and frowny.

Update: Mitch on IRC pointed out bsmedberg’s pymake work. With -j1 it’s about 30 seconds slower, but with -j10 it did a full build in 11 minutes (without hanging like a gmake build did!). Yay! I should also note that until now I’ve been doing Windows builds in a VM, which can take well over an hour to finish.

Ahoy, mateys!

Yarrr! Talk Like A Pirate Day be comin’ up. Ye sprogs that been usin’ isthetreegreen.com for tinderbox status should join the rest of us gentlemen ‘o fortune at me new site, bethetreegreen.com. It even be usin’ a pirate CSS @font-face! Shiver me timbers!