Category Archives: Stuff

Visualizing Stuff

build matrices for arbitrarypushlog

Posted on by

A TraceMonkey Push

As I mentioned in my teaser on rich thunderbird mozmill logs, in order to get the build logs and provide failure clustering you already have to do most of the stuff tinderboxpushlog does.  One of the key things is summarizing the builds in a way that is useful, where the definition of “useful” probably varies a lot between users.

While Thunderbird has an extremely boring set of build types (build, xpcshell, mozmill), my first take on summarizing them was no good.  While fixing it, I decided to feature creep (out of my hobby time allocation) and see if I could create a presentation that could handle the prolific Firefox and TraceMonkey trees.

A Firefox Push

While I am not going to claim it’s perfect, I like it.  It’s probably also important to caveat that not all Tracemonkey builds are categorized.  The mobile talos runs identify themselves by a completely different set of names from the desktop ones, and there’s not really room for columns for that.  Additionally, some builds cite a revision for “mobile-browser”, but we ignore that extra meta-data.  Although the design was intended to handle Thunderbird’s repository where each build is a tuple of “comm-central” and “mozilla-central” revision used, we really need to have that tuple for every build in the tinderbox tree, and TraceMonkey is not providing it.  (We could kick builds without the info to the “outer” push as an enhancement.)

A Thunderbird (well, comm-central) push.

As a gesture of friendship to non-Thunderbird trees, we now also process mochitest and reftest logs, although I’m failing to surface some of the details retrieved in the UI.

Anywho, you can see arbpl in action for yourself at arbpl.visophyte.org.  It cron scrapes every 5 minutes.  The error recovery logic is not production-grade yet; the scraper can fall victim to partially written tinderbox JSON files on the tinderbox server, which means that some trees might not see updates for longer than that.  And various other things may go wrong too.  The client does not auto-refresh or use Socket.IO or anything.  If you want to run your own, hit github.  If you want to read the source, you should probably hit github too, because the production serving mode is reasonably optimized and crams all the JS into a single (gzipped) file.

some practicality comes to visophyte town

Posted on by

In a nod to making useful visualizations, the marker infrastructure has been beefed up. The linear mapper now has reasonable heuristics to use pretty round numbers. And the time mapper has all sorts of time ranges under its belt.

weather vis demo, year time range

While I have thoughtfully left out units, there is now at least a chance of someone guessing that the above is a graph of the high, average, and low temperatures for somewhere in some year. Maybe someone really fancy could narrow it down by figuring out when the various inconsistent holidays fall and the overall temperature trends. But I’ll spoil the fun; it’s Dulles, VA in 2006! Thanks to a CF6 ‘Preliminary Climatology Data’ parser/’data feed’ we have a limitless* source of data which is only good for examples. Also, thank you weather.gov.

weather vis demo, june

This one is just the month of June. The non-intuitive numbers are ISO weeks. Overkill demands the ‘rulers’ that provide the date ranges eventually be capable of visualizing data themselves**, but for now they just derive their colors from primitive theming support which is also new.

I should probably note that I have begun to push my bzr repository to this server (/rev_control/bzr/visophyte) simply because I can’t think of a reason not to. The visophyte code proper is LGPL v3, but examples are MIT/X11 (though they need to be more explicitly labelled as such). That said, the code is still in an aggressive state of flux and I suggest no one even bother looking at it. Simply put, I keep adding features as needed, and the waves of non-backwards-compatible constraint/feature propagation often need to ripple through the entire codebase. And when I say ripple, I mean ripple; it’s not instantaneous.

* For the purposes of this asterisk, limitless still involves limited cutting and pasting. The parser likes to read files, not interwebs.

** Although I am likely to use such functionality to render the rulers useless and somewhat gaudy, there are sane possibilities too.