Update closure compiler

[gagern]

Downloaded http://dl.google.com/closure-compiler/compiler-latest.zip from https://github.com/google/closure-compiler/wiki/Binary-Downloads.

One problem solved by this is compiling all of the code to a single function; the old closure compiler used to pollute the environment before that with some more symbols, which I wanted to avoid.

[kripken]

Have you run the full test suite on this? Will need everything: core (no arguments), other and browser.

[gagern]

Nope, haven't run any tests so far. I guess I'm too used to projects using Travis or similar, so I'd see test results in the pull request. Will test soon, when I find the time.

[kripken]

Sadly we haven't been able to figure out a way to use Travis. Just building emscripten+fastcomp takes more than the timeout Travis has.

[gagern]

python2 tests/runner.py sanity on plain incoming without my changes already reports 3 failures. Is this just my environment, or is that branch currently in a state where it fails tests? Or are sanity tests the wrong thing to start with, despite what I read there somewhere in the runner sources?

Perhaps you could build fastcomp locally and upload the compiled version somewhere Travis could pick it up. You'd have to update that binary bundle on a regular basis, and the aproach would be terribly ill suited for changes which affect both projects, but better than nothing. Come to think about it, you could probably package the whole (or a truncated) git history in that bundle, so that you can do a git pull to fetch the latest changes, and only have to rebuild targets affected by that. That way you could perhaps get away with only creating new binary bundles after every merge from upstream or so.

[kripken]

sanity passes here. But it is fickle - it's enough if you check core (no args), other and browser, as mentioned earlier.

[kripken]

Regarding travis, we might pull a build from somewhere, but then we'd need to automate those builds, and also we'd get no CI for commits changing those builds, so we'd need our own CI anyhow. Which we do have in the form of http://clb.demon.fi:8112/waterfall , however they aren't fast enough to run every pull request - they can barely keep up with landing stuff ;)

[gagern]

Since the test suites take ages, I'm still not done. core fails the test_the_bullet case for me, but it does so on incoming (@ddc0cdf) as well. Something about no input files being specified to clang. browser fails some tests and errors others, but at least one of those reported in the serial run worked when run by itself. And for reasons unknown, some tests apparently launch Konqueror instead of my default browser Firefox, which might be a problem in its own right. It will still take me some time to work out which of these issues has anything to do with my code, which are sporadic only, and which are present in incoming already. I haven't even tried other so far.

[kripken]

Ok, thanks - I think that's good enough, and we just upgraded the bots to run tests in parallel so we'll get results fast.

[kripken]

Looks good!