Re: SuperDevMode stuck on compiling

[Chris Gamache]

I know it's poor form to bump one's own thread, but I'm down to the end of my rope:

I'm not sure if this has anything to do with anything, but this is from my nocache.js file, where the error had occurred:

function computePropValue(propName){

var value = providers[propName](), allowedValuesMap = values[propName];

if (value in allowedValuesMap) {

return value;

}

var allowedValuesList = [];

for (var k in allowedValuesMap) {

allowedValuesList[allowedValuesMap[k]] = k;

}

if (__propertyErrorFunc) {

__propertyErrorFunc(propName, allowedValuesList, value);

}

throw null;

}

propName is set to 'remove' and I can't for the life of me figure out where GWT is getting that. It is certainly not in the values array. The script execution fails when it tries to find 'remove' and it is not in allowedValuesMap. Adding to that problem, __propertyErrorFunc is undefined. 

If I remove 

if (__propertyErrorFunc) {

__propertyErrorFunc(propName, allowedValuesList, value);

}

throw null;

it will get to compile. There are other issues beyond that, but at least it will compile. The other problems are for a different thread.

Help!

On Monday, July 9, 2012 3:37:18 PM UTC-4, Chris Gamache wrote:

So I start CodeServer-- that works. Then I fire up a server instance of the GWT app and navigate to the landing page for the module. I hit my bookmarklet and it brings up the module -> compile box. I hit compile. It just stays there. There's no logging output in the CodeServer. Stuck.

I can see from the scripts panel in the debug tools that it has loaded dev_mode_on.js ... I also get an error after I hit the compile button : Uncaught ReferenceError: __propertyErrorFunc is not defined ... Hopefully that looks familiar to someone.

CG

[Thomas Broyer]

On Tuesday, July 10, 2012 11:40:22 PM UTC+2, Chris Gamache wrote:

I know it's poor form to bump one's own thread, but I'm down to the end of my rope:

I'm not sure if this has anything to do with anything, but this is from my nocache.js file, where the error had occurred:

function computePropValue(propName){

var value = providers[propName](), allowedValuesMap = values[propName];

if (value in allowedValuesMap) {

return value;

}

var allowedValuesList = [];

for (var k in allowedValuesMap) {

allowedValuesList[allowedValuesMap[k]] = k;

}

if (__propertyErrorFunc) {

__propertyErrorFunc(propName, allowedValuesList, value);

}

throw null;

}

propName is set to 'remove' and I can't for the life of me figure out where GWT is getting that. It is certainly not in the values array. The script execution fails when it tries to find 'remove' and it is not in allowedValuesMap. Adding to that problem, __propertyErrorFunc is undefined. 

That sure is strange. What does the callstack look like at that point?

[Chris Gamache]

Stopped on that line above when propName == 'remove' here's the call stack:

> console.trace()

  (anonymous function)

  (anonymous function)

  evaluate

  InjectedScript._evaluateOn

  InjectedScript._evaluateAndWrap

  InjectedScript.evaluateOnCallFrame

  computePropValue mymodule.nocache.js:326

  mymodule.__getPropMap mymodule.nocache.js:389

  getBindingParameters dev_mode_on.js:324

  compile dev_mode_on.js:388

  runBookmarklet dev_mode_on.js:414

  (anonymous function) dev_mode_on.js:427

  (anonymous function)

[Thomas Broyer]

On Wednesday, July 11, 2012 3:27:13 PM UTC+2, Chris Gamache wrote:

Stopped on that line above when propName == 'remove' here's the call stack:

> console.trace()

  (anonymous function)

  (anonymous function)

  evaluate

  InjectedScript._evaluateOn

  InjectedScript._evaluateAndWrap

  InjectedScript.evaluateOnCallFrame

  computePropValue mymodule.nocache.js:326

  mymodule.__getPropMap mymodule.nocache.js:389

  getBindingParameters dev_mode_on.js:324

  compile dev_mode_on.js:388

  runBookmarklet dev_mode_on.js:414

  (anonymous function) dev_mode_on.js:427

  (anonymous function)

Are you using any third-party lib? One that would manipulate the Array.prototype?

There's a small bug in the xsiframe linker generated script, rather a "bad practice" than a bug actually: using an Array as if it were an Object first, and using a for…in on it without checking hasOwnProperty; and when combined with the other bad practice of augmenting prototypes, it breaks!

Not really a bug in the generated script, just that it can break relatively easily if there are bugs/bad practices elsewhere.

I just tried it in Chrome dev tools' console:

var values = [];

values['foo'] = 'foo';

values['bar'] = 'bar';

for (var key in values) { console.log(key); }

The above should print "foo" and "bar".

Now, add the following and then start the "for" loop again:

Array.prototype.remove = function() { console.log("remove"); }

(using Array.prototype here, because 'values' is an array; would be true with Obejct.prototype if 'values' had been initialized with "{}")

It'll now print "foo", "bar", "remove".

Should be relatively easy to hack around it: locate __getPropMap in your nocache.js and change the for-loop to add the following "if":

for (key in values) {

  if (values.hasOwnProperty(key)) {

    ...

  }

}

[Chris Gamache]

I am using Ext-Js LGPL via GWT-Ext, and they have indeed modified the Array prototype. Not much I can do about that. I'm stuck there.

I hacked in the modification, and it will get through to compile now. Is there already an issue in the tracker for the xsiframe generator bug/bad practice?

[Thomas Broyer]

On Wednesday, July 11, 2012 5:46:16 PM UTC+2, Chris Gamache wrote:

I am using Ext-Js LGPL via GWT-Ext, and they have indeed modified the Array prototype. Not much I can do about that. I'm stuck there.

I hacked in the modification, and it will get through to compile now. Is there already an issue in the tracker for the xsiframe generator bug/bad practice?

I don't know of any, and this __getPropMap seems to only be used for SuperDevMode so it's not surprising that this bug hadn't been discovered yet.

[Chris Gamache]

Posted...  http://code.google.com/p/google-web-toolkit/issues/detail?id=7513 

Thank you for all your help!

[Ajax]

A note on bad practices leading to frail code...

Calling values.hasOwnProperty will likely be fine if the values object only ever comes from generated gwt code,

but from experience elsewhere, I always try to do Object.prototype.hasOwnProperty.call(values, prop);

Obviously if anyone wrecks .hasOwnPropety, they can't honestly expect support,

but for objects created with Object.create(null), there will be no Object prototype and .hasOwnProperty won't exist.

Not really relevant to this bug, but for the sake of promoting good practices, I thought I'd mention it.