LGTM
http://gwt-code-reviews.appspot.com/1470801/diff/1/user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
File user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
(right):
LGTM
http://gwt-code-reviews.appspot.com/1470801/diff/1/user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
File user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
(right):
Revision: 10409
Author: zun...@google.com
Date: Tue Jun 28 00:45:01 2011
Log: Cherry pick r10407 into GWT 2.4 release branch
http://code.google.com/p/google-web-toolkit/source/detail?r=10409
Added:
/releases/2.4/user/src/com/google/gwt/core/client/ScriptInjector.java
Revision: 10410
Author: zun...@google.com
Date: Tue Jun 28 01:02:19 2011
Log: Use CompilationUnitBuilder.create factory method. Remove unneeded
constructor and make single arg constructor private in
ResourceCompilationUnitBuilder and GeneratedCompilationUnitBuilder.
Patch by:
Committed as r10410
http://gwt-code-reviews.appspot.com/1465801/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Revision: 10411
Author: jbrosenb...@google.com
Date: Tue Jun 28 02:20:50 2011
Log: Enable generator result caching, by default.
This initially will allow caching for ClientBundle and RPC generators.
Other generators can be updated to support caching.
The
http://gwt-code-reviews.appspot.com/1470801/diff/1/user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
File user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
(right):
http://gwt-code-reviews.appspot.com/1463809/diff/1/user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java
File
user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java
(right):
1) I changed the State.maybeX() methods to add their jobs to a
work-queue instead of processing them immediately. I think that should
significantly reduce the stack depth.
2) Requiring a @ProxyFor annotation has also been deferred until after
all types have been scanned. This should prevent
http://gwt-code-reviews.appspot.com/1463809/diff/1/user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java
File
user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java
(right):
On 2011/06/28 15:52:56, bobv wrote:
Regarding the 5926 case, were any of those methods defined in
unchecked proxies
or RequestContexts? I just want to make sure the problem is really
fixed the
first time around.
Unless I missed the warnings, they were correctly checked.
The
http://gwt-code-reviews.appspot.com/1470801/diff/1/user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
File user/test/com/google/gwt/dev/jjs/test/SingleJsoImplTest.java
(right):
On 2011/06/27 15:09:23, zundel wrote:
On 2011/06/08 23:26:58, cromwellian wrote:
Can you help me understand what the hoist fucntions are about?
Normally, virtual methods are declared inline, e.g.
function Foo() {}
_ = Foo.prototype = new ...
_.myMethod = function myMethod(a,b) { code }
What about the case for a DualSimple (e.g. an interface that has both
java and jso implementations). In this case, my fix doesn't allow the
jso to be assigned to an array of DualSimple[]. Is that expected (I'm
guessing not).
Jason
On Tue, Jun 28, 2011 at 2:05 PM, cromwell...@google.com wrote:
I think it should work, Consider how this would cause weird bugs.
Someone has code that works as a SingleJso, but then he imports a
module which provides a Java implementation, and now all of a sudden
he gets ASEs?
On Tue, Jun 28, 2011 at 11:31 AM, Jason Rosenberg
jbrosenb...@google.com wrote:
Agreed, looking into...
On Tue, Jun 28, 2011 at 2:42 PM, Ray Cromwell cromwell...@google.com wrote:
I think it should work, Consider how this would cause weird bugs.
Someone has code that works as a SingleJso, but then he imports a
module which provides a Java implementation, and now all of a
http://gwt-code-reviews.appspot.com/1455802/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/1455802/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/1455802/diff/11003/user/src/com/google/gwt/dom/builder/client/DomStylesBuilder.java
File user/src/com/google/gwt/dom/builder/client/DomStylesBuilder.java
(right):
Looked at the intradiff, looks OK. Will still test tomorrow to make
sure.
Would be best to have unit-tests though, particularly for cases we
*want* to fail!
See http://blog.xebia.com/2009/07/testing-annotation-processors/
(I'd be more than OK to see unit tests being added as a subsequent patch
worth testing new generator version invalidation logic?
http://gwt-code-reviews.appspot.com/1468804/diff/2002/dev/core/src/com/google/gwt/core/ext/RebindMode.java
File dev/core/src/com/google/gwt/core/ext/RebindMode.java (right):
http://gwt-code-reviews.appspot.com/1470801/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Thanks for the explanation. Just one more thing I'm not clear about...
http://gwt-code-reviews.appspot.com/1454806/diff/1/dev/core/src/com/google/gwt/dev/js/JsDuplicateFunctionRemover.java
File dev/core/src/com/google/gwt/dev/js/JsDuplicateFunctionRemover.java
(right):
I can verify that my new tests for dualImpls fail going way back, at
least until last August. The other tests all passed, up until the
Overlay overhaul release this last March.
http://gwt-code-reviews.appspot.com/1470801/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Looking at Array.setCheck() it seems this was never supported. What we
can do is create a Array.setCheckAllowJso() method, and then insert a
call to either setCheck or setCheckAllowJso depending on whether or
not the array element type is a single JSO impl. setCheckAllowJso
would be identical to
25 matches
Mail list logo
