LGTM
https://gwt-code-reviews.appspot.com/1829804/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/AutoBeanCodexImpl.java
File
user/src/com/google/web/bindery/autobean/shared/impl/AutoBeanCodexImpl.java
(right):
https://gwt-code-reviews.appspot.com/1829804/diff/1/user/src/com/google
Appreciate any further suggestions for cleaning up memory usage. The
additional of Disposable roughly parallels the same use in
JSCompiler's Closure Library. In theory. V8's GC should be good enough
to clean up everything if you just blow away the
Reviewers: skybrian,
Description:
Add experimental GWT.unloadModule() function.
Enable via
Invoke via window.__gwt_activeModules[moduleName].unloadModule().
Attempts to do the following:
1) Cleanup all outstanding non-primitive properties from $wnd
2) Remove all registered event listeners
3) d
LGTM
https://gwt-code-reviews.appspot.com/1830803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/09/14 00:27:24, skybrian wrote:
On 2012/09/13 20:22:43, tbroyer wrote:
> I kind of like the enums as in com.google.gwt.dom.client.Style (also
used in
> SafeStyles), but I'll make the setResponseType(String) public, and
add a
> getResponseTypeString() to the enum.
Oops, I guess I
On 2012/09/13 20:22:43, tbroyer wrote:
I kind of like the enums as in com.google.gwt.dom.client.Style (also
used in
SafeStyles), but I'll make the setResponseType(String) public, and add
a
getResponseTypeString() to the enum.
Oops, I guess I should have responded. I'm fine with it either w
https://gwt-code-reviews.appspot.com/1829804/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/AutoBeanCodexImpl.java
File
user/src/com/google/web/bindery/autobean/shared/impl/AutoBeanCodexImpl.java
(right):
https://gwt-code-reviews.appspot.com/1829804/diff/1/user/src/com/google/web/bi
On 2012/09/13 18:23:04, skybrian wrote:
I don't see any usages of XmlHttpRequest.ResponseType in Google code.
OK, so I'll remove the create(ResponseType).
We could have constants instead of the enum.
I kind of like the enums as in com.google.gwt.dom.client.Style (also
used in SafeStyles), b
On 2012/09/13 18:35:35, manolo.carrasco wrote:
We are using domain interfaces in a couple of projects and finally we
decided to
patch this file to avoid such amount of extra code.
I thought this was a very small piece of code which IMHO fixes an
important
issue, and could be related with this
LGTM after fixing for comment or deciding to disregard it.
https://gwt-code-reviews.appspot.com/1829804/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/AutoBeanCodexImpl.java
File
user/src/com/google/web/bindery/autobean/shared/impl/AutoBeanCodexImpl.java
(right):
https://gwt-code-r
Reviewers: unnurg, jtamplin,
Message:
I've grep'ed in all com.google.web.bindery and didn't find any other
instance.
I also quickly looked into com.google.gwt in case there could have been
similar issues with GWT-RPC or some "shared" code, but didn't find
anything either.
Description:
Synchroniz
We are using domain interfaces in a couple of projects and finally we
decided to patch this file to avoid such amount of extra code.
I thought this was a very small piece of code which IMHO fixes an
important issue, and could be related with this commit, so that is the
reason to suggest the inclus
I don't see any usages of XmlHttpRequest.ResponseType in Google code. We
could have constants instead of the enum.
https://gwt-code-reviews.appspot.com/1830803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Should we kill off the ResponseType enum and just take a String? It's
simpler, and this is low-level, after all.
- Brian
On Thu, Sep 13, 2012 at 11:08 AM, wrote:
>
> https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
> File user/src/com
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
File user/src/com/google/gwt/xhr/client/XMLHttpRequest.java (right):
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java#newcode
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
File user/src/com/google/gwt/xhr/client/XMLHttpRequest.java (right):
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java#newcode
On 2012/09/13 17:16:52, skybrian wrote:
Since this API is essentially just a wrapper around the JavaScript
object and
there's no place to stash the desired response type, adding the setter
and
deprecating create() with a response type seems like the way to go.
Done.
I wonder if we shouldn
I'm not all that familiar with XMLHttpRequest, but every JavaScript
example I can find sets the response type between open() and send(). I
don't understand John's concern about a race condition since it seems
like the request won't be sent until send() is called? I think we should
follow common pr
Well, if you ask me, it can wait the next release.
There's a workaround in the meantime: don't rely on ValidationTool to
generate the Deobfuscator.Builder, generate it yourself by other means. I
wrote such a generator for a project, 'cause we had many
@SkipInterfaceValidation methods (and much work
On 2012/09/13 09:57:02, manolo.carrasco wrote:
RF fails in the case of @ProxyFor pointing to a domain-interface
instead of a
domain-implementation, could you consider to include the patch
https://gwt-code-reviews.appspot.com/1764804/ as well in 2.5?
I think that counts as a new feature instea
Yes - we can put it into rc2 assuming its small and you can get it in today.
On Sep 13, 2012 6:33 AM, "John A. Tamplin" wrote:
> Yeah, just add a synchronized block for now.
>
> John A. Tamplin (android)
> On Sep 13, 2012 8:02 AM, "Thomas Broyer" wrote:
>
>> Found on StackOverflow: http://stacko
Yeah, just add a synchronized block for now.
John A. Tamplin (android)
On Sep 13, 2012 8:02 AM, "Thomas Broyer" wrote:
> Found on StackOverflow: http://stackoverflow.com/q/12403658/116472
>
> We have a critical issue with RequestFactory (AutoBeans actually): we use
> static HashMaps as shared ca
Found on StackOverflow: http://stackoverflow.com/q/12403658/116472
We have a critical issue with RequestFactory (AutoBeans actually): we use
static HashMaps as shared caches without any synchronization!
Short-term fix: because neither ConcurrentHashMap or
Collections.synchronizedMap are emulate
On 2012/09/06 21:11:52, tbroyer wrote:
https://gwt-code-reviews.appspot.com/1712803/diff/2001/user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java
File
user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java
(right):
https://gwt-code-reviews.appspot.com/
On 2012/09/12 21:02:42, jtamplin wrote:
On 2012/09/12 20:47:20, skybrian wrote:
> Hmm, I'm inclined to skip this patch for GWT 2.5. The typo fix at
least makes
it
> work on some browsers...
If I understand Thomas' test results, the getter works properly
everywhere -- it
is the existing set
25 matches
Mail list logo
