Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Note To Self: Faster Chromium Builds (Updated)

I spend my days in C++ on 32-bit Windows XP in Visual Studio 2005. The build and link times for Chromium are painful on this setup, in part because there has been flakiness with the multi-process build option for VS, in part because the incremental linker which can dramatically speed up builds can run out of memory on some boxes (so is disabled by default), and because Visual Studio steadfastly refuses to give developers any options about how, when, where, and why to rebuild the IntelliSense database. The last one is probably the most intractable. On 64-bit windows, incremental linking is turned on based on the assumption that you'll have lots of RAM on that shiny 64-bit box. Similarly, Chromium builds using multi-process flags under VS'08 since it's known to be less flaky there. It seems I run with the "please hurt me more" configuration.

"Distributed builds!", I hear you scream.

That's not a bad path. For Mac builds, the office's ad-hoc distcc cluster is a godsend (particularly given that my Mac is a lowly laptop). For Visual Studio, there's IncrediBuild, but it has left me wanting a better option. Recently I've just thrown caution to the wind and started over-riding the safety valves on /MP and incremental linking via my ~/.gyp/include.gypi file:

{
  'variables': {
    'msvs_multi_core_compile': 1,
    'msvs_large_module_debug_link_mode': '2'
  }
}

You can get these settings to take effect without updating your repo by running gclient runhooks --force from the top level directory if your Chromium checkout. VS should then prompt you to reload the project (assuming you're using the GUI).

Hopefully this recipe will help others. It has dropped small rebuilds on my system from north of 10 minutes to below 2.

Update: So the real answer, apparently, is to get dual quad-core i7's running Vista 64 under VS 2008. Holy cow, what a world of difference. All hail the Powers That Be for new, awesome hardware!

CSS 3: Progress! (Updated)

I've been in a pretty heated email conversation over the past couple of days regarding how effective (or not) the CSS Working Group has been. I've been pretty brutal in my critique in the past (and much of it still stands), but there's reason to hope.

The best bits are -- not surprisingly -- being driven by the implementers. Apple is in the driver's seat, with major contributions for Animations (including keyframes!), 2D Transforms, 3D Tranforms, and Transitions. Great stuff.

Similarly, David Baron (of Mozilla fame) is editing a long-overdue but totally awesome Flexible Box spec, aka: "hbox and vbox". Both Gecko and WebKit-derived browsers (read: everything that's not IE) supports hbox and vbox today, but using it can be a bit tedious. Should you be working on an app that can ignore IE (say, for a mobile phone), this should help make box layouts a bit easier to get started with:

/* hbox and vbox classes */

.hbox { display: -webkit-box; -webkit-box-orient: horizontal; -webkit-box-align: stretch;

display: -moz-box;
-moz-box-orient: horizontal;
-moz-box-align: stretch;

display: box;
box-orient: horizontal;
box-align: stretch;

}

.hbox > * { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; display: block; }

.vbox { display: -webkit-box; -webkit-box-orient: vertical; -webkit-box-align: stretch;

display: -moz-box;
-moz-box-orient: vertical;
-moz-box-align: stretch;

display: box;
box-orient: vertical;
box-align: stretch;

}

.vbox > * { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; display: block; }

.spacer { -webkit-box-flex: 1; -moz-box-flex: 1; box-flex: 1; }

.reverse { -webkit-box-direction: reverse; -moz-box-direction: reverse; box-direction: reverse; }

.boxFlex0 { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; }

.boxFlex1, .boxFlex { -webkit-box-flex: 1; -moz-box-flex: 1; box-flex: 1; }

.boxFlex2 { -webkit-box-flex: 2; -moz-box-flex: 2; box-flex: 2; }

.boxGroup1 { -webkit-box-flex-group: 1; -moz-box-flex-group: 1; box-flex-group: 1; }

.boxGroup2 { -webkit-box-flex-group: 2; -moz-box-flex-group: 2; box-flex-group: 2; }

.start { -webkit-box-pack: start; -moz-box-pack: start; box-pack: start; }

.end { -webkit-box-pack: end; -moz-box-pack: end; box-pack: end; }

.center { -webkit-box-pack: center; -moz-box-pack: center; box-pack: center; }

I've been using these rules for some time to good effect. You can use them to easily visually center things (for example):

...
...

Or you can use grouping to get nicer form layouts:

It's unfortunate that this stuff is "medium priority", but at least it's moving forward in the WG.

Update: Fixed the examples and rules to use box-pack: center;, per Dave Hyatt's excellent suggestion!

Some Orthodox Heresies

Just back from a long weekend, a couple of things struck me this morning that are evident but not perhaps obvious. Reality always has multiple sides, so in true Jenny Holzer style, please accept (but not entirely) these small web-development truisms:

JS 1.8 Function Expressions: The Opposite of "Good"

JavaScript is crying out for a way to write functions more tersely. I've added my suggestion to the debate, and was vaguely aware that Mozilla had implemented "function expressions". It wasn't until I saw their use in the (excellent) ProtoVis examples that I realized how stomach-churningly bad the syntax for them is. Instead of dropping the word function from the declaration of lambdas, they kill the { } charachters, leaving the big visual turd at the front of the lambda while simultaneously omitting the symmetrical visual aid that allows programmers to more easily spot missing terminators.

Oof.

It'd be one thing of the feature saved enough effort (typing) to justify the confusion, but it doesn't. Bitter syntactic sugar in a language that's already complicated by whitespace issues should be avoided.

Perspective

So after receiving a keyboard-lashing from myself and others regarding some comments he made, Chris has walked a lot of it back and bravely noted where his new perspective conflicts with the old. It takes guts to do that.

My original comments were born of my frustration the internecine strife that seems to follow every discussion about OSS licensing. It's one of the reasons that I was so grateful for Dion's 100-point scale for judging community because it helps put all of this stuff into a perspective that lets you evaluate what's more likely to be good for a broad audience from what's more likely to hurt people along the way. There will always be both individual and corporate involvement in OSS, and both are good things, but neither are unalloyed forces for lightness and right. They've got down-sides. OSS communities and hackers should be honest about them and evaluate them on the merits and likely outcomes. It took me a long time to come to that perspective and it's and one that I'm happy to see Chris weighing. Kudos to him for taking it in stride.

Correction: I wrongly attributed the 100-point scale to Ben instead of Dion. Totally n00b mistake. My apologies.

Older Posts

Newer Posts