recompile node-browserchannel with advanced optimizations

[wenzowski]

New closure-library optimizations appear to be causing issues with node-bcsocket. Falling back to simple optimizations results in a green test suite but is unacceptably large.

Don't know the closure-library svn tag intended to be used for node-browserchannel compilation, assuming there is/was a published tag at all.

Following node-browserchannel instructions, the patch wenzowski/closure-library@6181ead appears (I think?) to have applied cleanly to latest closure-library wenzowski/closure-library@f26bb31

[josephg]

Fascinating. I wonder if changes in the compiler or the closure library have broken things. And is it the patch or the bcsocket code which breaks it? I last updated the patch at closure-library r2519 - although I may well have last compiled using a more recent version of the closure-library.

If its the patch, it simply fixes some small problems where manually closing connections can leave dangling requests. The requests aren't retried anyway, so mostly its just a problem for nodejs-based clients. I'll dig into it.

[wenzowski]

Same results compiled with patch and without.

[josephg]

Alright - its either a change in the latest closure compiler or closure code. I recompiled using the latest of both a few months ago and it worked fine. I'll play with it....

[josephg]

-> Had a play with this. Turns out its a change in the closure library. r151cc367517746ec52575 from november works, and HEAD doesn't work. The bug is related to eventtarget.js:219:

/** @override */
goog.events.EventTarget.prototype.listen = function(
    type, listener, opt_useCapture, opt_listenerScope) {
  this.assertInitialized_();
  return this.eventTargetListeners_.add(
      String(type), listener, false /* callOnce */, opt_useCapture,
      opt_listenerScope);
};

... The call to add() doesn't get minified (maybe because type annotations are missing?), and there's no add property on whatever object its calling on. There might be more information in the stack trace. For now I'm going to leave this issue open until someone has time to track it down.

Git bisect would do it.

[josephg]

sephsmac:closure-library josephg$ git bisect bad
83c6a0b97bd16e23a8578ddb1a53d8e1a21fb4cf is the first bad commit
commit 83c6a0b97bd16e23a8578ddb1a53d8e1a21fb4cf
Author: Nathan Naze <nnaze@google.com>
Date:   Tue Feb 18 14:39:37 2014 -0500

    Migrate Closure from goog.base to static base class methods.

    Refactoring: java/com/google/javascript/refactoring/examples:googbaseA
    Note: this refactoring currently requires a patch to the compiler so that goog.base isn't rewritten prior to AST inspection.

.. This is from yesterday. The note is quite useful - they probably just haven't re-released the closure compiler since then.

[wenzowski]

The last known working commit of closure-compiler is therefore df47692b1bacd494548a3b00b150d9f6a428d58a.

Note to self: remember, if java -version is not ~1.7 build fails and cryptic stack traces abound.

Closing.