Re: [gwt-contrib] Class literals for JsTypes in superdevmode
I have uploaded the real fix for review at
https://gwt-review.googlesource.com/#/c/12920.
It should fix your situation but could you verify?
On Tue, Jun 9, 2015 at 10:08 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Roberto, if it's any hint to the underlying problem: you're right that
that the class is not reference anywhere else—it is used solely for the
purpose of type coercion.
Chris
On Tue, Jun 9, 2015 at 10:48 AM 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Chris,
My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.
Roberto, Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend
we proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT
Contributors google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals
for interfaces if not referenced during the initial compile might cause
that error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and
start SDM.
1) Now edit class B to add a reference to A.class and recompile with
SDM (do not touch A at this time nor anything that makes it recompile) .
This should work fine because the literals that are referenced but whose
classes where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile.
Here you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com
wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's
template that matches the given id
* with the result coerced to a non-vanilla element type.
Equivalent to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the
list of class literals available in superdevmode. Is this a bug? Any
ideas
for workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it,
send an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
Chris,
My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.
Roberto, Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we
proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals for
interfaces if not referenced during the initial compile might cause that
error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and
start SDM.
1) Now edit class B to add a reference to A.class and recompile with SDM
(do not touch A at this time nor anything that makes it recompile) . This
should work fine because the literals that are referenced but whose classes
where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile. Here
you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's template
that matches the given id
* with the result coerced to a non-vanilla element type.
Equivalent to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the list
of class literals available in superdevmode. Is this a bug? Any ideas for
workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
Roberto, if it's any hint to the underlying problem: you're right that that
the class is not reference anywhere else—it is used solely for the purpose
of type coercion.
Chris
On Tue, Jun 9, 2015 at 10:48 AM 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Chris,
My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.
Roberto, Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we
proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals
for interfaces if not referenced during the initial compile might cause
that error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and
start SDM.
1) Now edit class B to add a reference to A.class and recompile with SDM
(do not touch A at this time nor anything that makes it recompile) . This
should work fine because the literals that are referenced but whose classes
where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile. Here
you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's
template that matches the given id
* with the result coerced to a non-vanilla element type.
Equivalent to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the
list of class literals available in superdevmode. Is this a bug? Any
ideas
for workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it,
send an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we
proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals for
interfaces if not referenced during the initial compile might cause that
error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and start
SDM.
1) Now edit class B to add a reference to A.class and recompile with SDM
(do not touch A at this time nor anything that makes it recompile) . This
should work fine because the literals that are referenced but whose classes
where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile. Here
you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's template
that matches the given id
* with the result coerced to a non-vanilla element type.
Equivalent to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the list
of class literals available in superdevmode. Is this a bug? Any ideas for
workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gk_U85%2B6z1QK9XpAKEXbBJgviBfZ1j0kgE8_pYZsV6Y3g%40mail.gmail.com
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
ok, taking a look On Tue, Jun 9, 2015 at 11:38 AM, 'Roberto Lublinerman' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: I tweaked the code a bit and now it should never output duplicated class literals. @Ray, Could you review the patch? On Tue, Jun 9, 2015 at 10:31 AM, 'Ray Cromwell' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: I don't think it's an issue that blocks since people are most likely to use SDM in uncompiled mode, and the 'error' can always be suppressed and turned into a warning. At best, it might inhibit a const optimization in Closure where it sees the same variable declared/assigned twice I think. On Tue, Jun 9, 2015 at 10:27 AM, 'Roberto Lublinerman' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: SDM expects that classes/interfaces get generated as a whole either all of it or none. As you know, class literals are not really part of the class but they are field in a separate synthetic class). Even SDM (with all optimizations off, no pruning at UnifyAST) if a reference to the class literal is not seen when generating the JS for the class then its class literal field wont be part of the JS for the class. For SDM it could only happen for interfaces (and maybe primitive types) because GwtAstBuilder will synthezise a getClass for each class containing reference to its class literals. The problem is further obscured because we (re)generate an epilogue each time and it contains all the class literals that are referenced from the code that is being recompiled whose classes where not part of the current compile. This serves a purpose in NON SDM where if only the class literal for a class is referenced, the class can be pruned. The only glitch remaining is that in SDM there might be duplicated class literals (but it should not affect the correctness). Is this an issue for Closure? On Tue, Jun 9, 2015 at 9:48 AM, 'Ray Cromwell' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: Chris, My change actually fixed a bug which may have obscured a problem. There were duplicate class literals being generated. So you'd get InterfaceFoo.class twice in the output, and it may be in SDM you'd be covered, but in regular compiled mode you'd get the duplicates which were causing closure compiler issues. Roberto, Maybe this is an issue with ControlFlowRecorder/RapidTypeAnalyzer and interface literals? On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: @Ray, rolling back your change indeed fixed the problem ( https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we proceed? Anything I can do to help? @Roberto, thanks for your suggestion, but I had already tried restarting the code server and clearing the cache. This did not fix things. Chris On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: This might be due to the way we handle class literals. Class literals for interfaces if not referenced during the initial compile might cause that error. The error should go aways if you restart SDM. The offending sequence is 0) Suppose initially you have (interface A, class B and class C) and start SDM. 1) Now edit class B to add a reference to A.class and recompile with SDM (do not touch A at this time nor anything that makes it recompile) . This should work fine because the literals that are referenced but whose classes where not part of this compile will be generated in the epilogue. 2) Now edit class C in any way that does not make B or A recompile. Here you will have an error like the one you described. If you restart SDM at this point it should work. I'll get a fix for this tomorrow. On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: Ooops, wrong pointer (for external users) This one https://gwt-review.googlesource.com/#/c/12311/ On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com wrote: Try rolling back this CL and see if it fixes it ( https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java ) On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote: I'm having trouble referencing a JsType interface when running under superdevmode. I'm trying to pass the JsType as a class reference to a method that uses the class to coerce the results into the expected type: myelement.getCustomStampedElement(dialog, PolymerDialog.class).open(); Unfortunately, in superdevmode (and only in SDM) I get this error: Uncaught ReferenceError:
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
SDM expects that classes/interfaces get generated as a whole either all of
it or none. As you know, class literals are not really part of the class
but they are field in a separate synthetic class). Even SDM (with all
optimizations off, no pruning at UnifyAST) if a reference to the class
literal is not seen when generating the JS for the class then its class
literal field wont be part of the JS for the class.
For SDM it could only happen for interfaces (and maybe primitive types)
because GwtAstBuilder will synthezise a getClass for each class containing
reference to its class literals.
The problem is further obscured because we (re)generate an epilogue each
time and it contains all the class literals that are referenced from the
code that is being recompiled whose classes where not part of the current
compile. This serves a purpose in NON SDM where if only the class literal
for a class is referenced, the class can be pruned.
The only glitch remaining is that in SDM there might be duplicated class
literals (but it should not affect the correctness). Is this an issue for
Closure?
On Tue, Jun 9, 2015 at 9:48 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Chris,
My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.
Roberto, Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we
proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals
for interfaces if not referenced during the initial compile might cause
that error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and
start SDM.
1) Now edit class B to add a reference to A.class and recompile with SDM
(do not touch A at this time nor anything that makes it recompile) . This
should work fine because the literals that are referenced but whose classes
where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile. Here
you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's
template that matches the given id
* with the result coerced to a non-vanilla element type.
Equivalent to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the
list of class literals available in superdevmode. Is this a bug? Any
ideas
for workarounds?
Chris DiGiano
--
You received this message because you are subscribed to
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
I tweaked the code a bit and now it should never output duplicated class
literals. @Ray, Could you review the patch?
On Tue, Jun 9, 2015 at 10:31 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
I don't think it's an issue that blocks since people are most likely to
use SDM in uncompiled mode, and the 'error' can always be suppressed and
turned into a warning. At best, it might inhibit a const optimization in
Closure where it sees the same variable declared/assigned twice I think.
On Tue, Jun 9, 2015 at 10:27 AM, 'Roberto Lublinerman' via GWT
Contributors google-web-toolkit-contributors@googlegroups.com wrote:
SDM expects that classes/interfaces get generated as a whole either all
of it or none. As you know, class literals are not really part of the class
but they are field in a separate synthetic class). Even SDM (with all
optimizations off, no pruning at UnifyAST) if a reference to the class
literal is not seen when generating the JS for the class then its class
literal field wont be part of the JS for the class.
For SDM it could only happen for interfaces (and maybe primitive types)
because GwtAstBuilder will synthezise a getClass for each class containing
reference to its class literals.
The problem is further obscured because we (re)generate an epilogue each
time and it contains all the class literals that are referenced from the
code that is being recompiled whose classes where not part of the current
compile. This serves a purpose in NON SDM where if only the class literal
for a class is referenced, the class can be pruned.
The only glitch remaining is that in SDM there might be duplicated class
literals (but it should not affect the correctness). Is this an issue for
Closure?
On Tue, Jun 9, 2015 at 9:48 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Chris,
My change actually fixed a bug which may have obscured a problem.
There were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.
Roberto, Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend
we proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried
restarting the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT
Contributors google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals
for interfaces if not referenced during the initial compile might cause
that error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and
start SDM.
1) Now edit class B to add a reference to A.class and recompile with
SDM (do not touch A at this time nor anything that makes it recompile) .
This should work fine because the literals that are referenced but whose
classes where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile.
Here you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com
wrote:
I'm having trouble referencing a JsType interface when running
under superdevmode. I'm trying to pass the JsType as a class reference
to a
method that uses the class to coerce the results into the expected
type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
I don't think it's an issue that blocks since people are most likely to use
SDM in uncompiled mode, and the 'error' can always be suppressed and turned
into a warning. At best, it might inhibit a const optimization in Closure
where it sees the same variable declared/assigned twice I think.
On Tue, Jun 9, 2015 at 10:27 AM, 'Roberto Lublinerman' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
SDM expects that classes/interfaces get generated as a whole either all of
it or none. As you know, class literals are not really part of the class
but they are field in a separate synthetic class). Even SDM (with all
optimizations off, no pruning at UnifyAST) if a reference to the class
literal is not seen when generating the JS for the class then its class
literal field wont be part of the JS for the class.
For SDM it could only happen for interfaces (and maybe primitive types)
because GwtAstBuilder will synthezise a getClass for each class containing
reference to its class literals.
The problem is further obscured because we (re)generate an epilogue each
time and it contains all the class literals that are referenced from the
code that is being recompiled whose classes where not part of the current
compile. This serves a purpose in NON SDM where if only the class literal
for a class is referenced, the class can be pruned.
The only glitch remaining is that in SDM there might be duplicated class
literals (but it should not affect the correctness). Is this an issue for
Closure?
On Tue, Jun 9, 2015 at 9:48 AM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Chris,
My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.
Roberto, Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
@Ray, rolling back your change indeed fixed the problem (
https://gwt-review.googlesource.com/#/c/12311/). How do you recommend
we proceed? Anything I can do to help?
@Roberto, thanks for your suggestion, but I had already tried restarting
the code server and clearing the cache. This did not fix things.
Chris
On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT
Contributors google-web-toolkit-contributors@googlegroups.com wrote:
This might be due to the way we handle class literals. Class literals
for interfaces if not referenced during the initial compile might cause
that error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and
start SDM.
1) Now edit class B to add a reference to A.class and recompile with
SDM (do not touch A at this time nor anything that makes it recompile) .
This should work fine because the literals that are referenced but whose
classes where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile.
Here you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com
wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's
template that matches the given id
* with the result coerced to a non-vanilla element type.
Equivalent to Polymer's $ function.
*
* @see
*
[gwt-contrib] Class literals for JsTypes in superdevmode
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog, PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's template that
matches the given id
* with the result coerced to a non-vanilla element type. Equivalent to
Polymer's $ function.
*
* @see
* a
href=https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding;
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the list of
class literals available in superdevmode. Is this a bug? Any ideas for
workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's template
that matches the given id
* with the result coerced to a non-vanilla element type. Equivalent
to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the list of
class literals available in superdevmode. Is this a bug? Any ideas for
workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's template
that matches the given id
* with the result coerced to a non-vanilla element type. Equivalent
to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the list of
class literals available in superdevmode. Is this a bug? Any ideas for
workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7e%3DDigWWWfxi%3DeBt70zU-yMOYzQp2yFLxPo%2Bnq%2BnKfEJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Class literals for JsTypes in superdevmode
This might be due to the way we handle class literals. Class literals for
interfaces if not referenced during the initial compile might cause that
error. The error should go aways if you restart SDM.
The offending sequence is
0) Suppose initially you have (interface A, class B and class C) and start
SDM.
1) Now edit class B to add a reference to A.class and recompile with SDM
(do not touch A at this time nor anything that makes it recompile) . This
should work fine because the literals that are referenced but whose classes
where not part of this compile will be generated in the epilogue.
2) Now edit class C in any way that does not make B or A recompile. Here
you will have an error like the one you described.
If you restart SDM at this point it should work.
I'll get a fix for this tomorrow.
On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:
Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/
On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell cromwell...@google.com
wrote:
Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)
On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano d...@google.com wrote:
I'm having trouble referencing a JsType interface when running under
superdevmode. I'm trying to pass the JsType as a class reference to a
method that uses the class to coerce the results into the expected type:
myelement.getCustomStampedElement(dialog,
PolymerDialog.class).open();
Unfortunately, in superdevmode (and only in SDM) I get this error:
Uncaught ReferenceError:
Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
is not defined
PolymerDialog is declared like this:
@JsType
public interface PolymerDialog {
void open();
}
and getCustomStampedElement is defined like this:
/**
* Returns the element specified in this custom element's template
that matches the given id
* with the result coerced to a non-vanilla element type. Equivalent
to Polymer's $ function.
*
* @see
* a href=
https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
* Polymer automatic node finding/a
*/
T T getCustomStampedElement(String id, ClassT type);
It appears that the PolymerDialog JsType is being left out of the list
of class literals available in superdevmode. Is this a bug? Any ideas for
workarounds?
Chris DiGiano
--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gk_U85%2B6z1QK9XpAKEXbBJgviBfZ1j0kgE8_pYZsV6Y3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
