[gwt-contrib] Change in gwt[master]: fixing mismatch in Double.isInfinite between dev / production
Daniel Kurka has uploaded a new change for review.
https://gwt-review.googlesource.com/2240
Change subject: fixing mismatch in Double.isInfinite between dev /
production
..
fixing mismatch in Double.isInfinite between dev / production
fixes ISSUE 8073
Change-Id: I792a2f2f17e7b4688e5b5d99410f74f34144
---
M user/super/com/google/gwt/emul/java/lang/Double.java
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/user/super/com/google/gwt/emul/java/lang/Double.java
b/user/super/com/google/gwt/emul/java/lang/Double.java
index 5144653..e32f9d2 100644
--- a/user/super/com/google/gwt/emul/java/lang/Double.java
+++ b/user/super/com/google/gwt/emul/java/lang/Double.java
@@ -192,7 +192,7 @@
}
public static native boolean isInfinite(double x) /*-{
-return !isFinite(x);
+return !isFinite(x) !isNaN(x);
}-*/;
public static native boolean isNaN(double x) /*-{
--
To view, visit https://gwt-review.googlesource.com/2240
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I792a2f2f17e7b4688e5b5d99410f74f34144
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: fixing mismatch in Double.isInfinite between dev / production
Thomas Broyer has posted comments on this change. Change subject: fixing mismatch in Double.isInfinite between dev / production .. Patch Set 1: Could you add a test to com.google.gwt.emultest.java.lang.DoubleTest#testDoubleConstants? We also have the same issue in Float.isInfinite(). -- To view, visit https://gwt-review.googlesource.com/2240 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I792a2f2f17e7b4688e5b5d99410f74f34144 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: gwt rebranding
On Saturday, March 16, 2013 1:28:23 AM UTC+1, James Nelson wrote: Thanks @ Rob for notifying branding experts. The consensus from most of the steering committee is that they like the logo as well, and I for one, pretty much agree. Going way out there on a new logo would lose all built up brand identity and is not likely wise. I only posted that messed up example because I thought of the play on G+T = I, but it can only work if it looks clean, and I really don't think there is a way to do so. If anything, an updated logo should look like an upgrade, rather than a rebrand; keep the red toolbox idea, and perhaps spell it out in full, GWT. Too much detail won't scale down well. I do know a typography expert I can ask about some good looking fonts and ways to apply them to a toolbox... If anyone has any comments or suggestions, please feel free to criticize as constructively as possible. :) Let's just use Comic Sans MS :-P -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: fixing mismatch in Double.isInfinite between dev / production
Daniel Kurka has abandoned this change. Change subject: fixing mismatch in Double.isInfinite between dev / production .. Abandoned error -- To view, visit https://gwt-review.googlesource.com/2240 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I792a2f2f17e7b4688e5b5d99410f74f34144 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: gwt rebranding
https://lh3.googleusercontent.com/-pyhhwBZBseY/UUSdBOkq4tI/AFk/F1BBytRaNSw/s1600/jn_gwt_logo_v1.jpg Just had some time and the above logo is the result ;-) I renamed toolkit to toolbox to get a better association to the box icon. The perspective of the box isn't pixel perfect, but I guess its good enough to get the idea. -- J. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: gwt rebranding
Your welcome @ James (although your comment does seem a little disingenuous). And, thank you @ James for helping to build a sense of community. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Static fields on JavaScriptObjects
Hello Everyone, I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? -Daniel -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
Thanks John for clearing this up. This was exactly what I had in mind. I will close the issue AsDesigned, maybe we should document this is little better. -Daniel Am 16.03.2013 um 20:40 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.com wrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? On Mar 16, 2013 1:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Thanks John for clearing this up. This was exactly what I had in mind. I will close the issue AsDesigned, maybe we should document this is little better. -Daniel Am 16.03.2013 um 20:40 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth niloc...@gmail.com wrote: The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. I don't see how you can add clinits on a JSO -- the point is it is a plain JS object under the hood (ignoring all the magic to make it work in DevMode). If you call a method or access a field from pure JS, how can it know to call the clinit? If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? I'm fine with making it an error. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Error while updating commits in gerrit
I am having trouble lately with updating commits in gerrit: Anyone else seeing something like this? kurt@kmac:~/Documents/workspace-mgwt/gwt$ git push origin HEAD:refs/changes/2220 Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (11/11), 902 bytes, done. Total 11 (delta 7), reused 0 (delta 0) remote: Resolving deltas: 100% (7/7) remote: Processing changes: updated: 1, refs: 1, done remote: error: internal error while processing changes java.util.IllegalFormatConversionException: d != com.google.gerrit.reviewdb.client.PatchSet$Id To https://gwt.googlesource.com/gwt ! [remote rejected] HEAD - refs/changes/2220 (internal server error) error: failed to push some refs to 'https://gwt.googlesource.com/gwt' -Daniel -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
Am 16.03.2013 um 22:43 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth niloc...@gmail.com wrote: The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. I don't see how you can add clinits on a JSO -- the point is it is a plain JS object under the hood (ignoring all the magic to make it work in DevMode). If you call a method or access a field from pure JS, how can it know to call the clinit? If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? I'm fine with making it an error. This should be an error. You can easily build a wrapper if you need fields. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Error while updating commits in gerrit
I should add. This seems to happen to all my recent changes once I try to amend them and update the commit in gerrit. -Daniel Am 16.03.2013 um 22:45 schrieb Daniel Kurka kurka.dan...@gmail.com: I am having trouble lately with updating commits in gerrit: Anyone else seeing something like this? kurt@kmac:~/Documents/workspace-mgwt/gwt$ git push origin HEAD:refs/changes/2220 Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (11/11), 902 bytes, done. Total 11 (delta 7), reused 0 (delta 0) remote: Resolving deltas: 100% (7/7) remote: Processing changes: updated: 1, refs: 1, done remote: error: internal error while processing changes java.util.IllegalFormatConversionException: d != com.google.gerrit.reviewdb.client.PatchSet$Id To https://gwt.googlesource.com/gwt ! [remote rejected] HEAD - refs/changes/2220 (internal server error) error: failed to push some refs to 'https://gwt.googlesource.com/gwt' -Daniel -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: gwt rebranding
- http://brandcrowd.com/logo-design/categories/computer_and_networking/ -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: gwt rebranding
Ah ah, love that new acronym: GWT = Gorgeous Web Toolkit/box ;-) (I prefer toolkit to toolbox, it rhymes with GWiT) On Saturday, March 16, 2013 5:32:02 PM UTC+1, Jens wrote: https://lh3.googleusercontent.com/-pyhhwBZBseY/UUSdBOkq4tI/AFk/F1BBytRaNSw/s1600/jn_gwt_logo_v1.jpg Just had some time and the above logo is the result ;-) I renamed toolkit to toolbox to get a better association to the box icon. The perspective of the box isn't pixel perfect, but I guess its good enough to get the idea. -- J. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Error while updating commits in gerrit
On Saturday, March 16, 2013 10:45:31 PM UTC+1, Daniel Kurka wrote: I am having trouble lately with updating commits in gerrit: Anyone else seeing something like this? kurt@kmac:~/Documents/workspace-mgwt/gwt$ git push origin HEAD:refs/changes/2220 Any reason you're not just pushing to refs/for/master and let the Change-Id magic do the rest? https://gerrit-review.googlesource.com/Documentation/user-upload.html#push_replace What you're doing here is deprecated. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: add Class.getSimpleName to gwt emulation
Hello John A. Tamplin, Janek Bogucki, Brian Slesinsky, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/2220 to look at the new patch set (#4). Change subject: add Class.getSimpleName to gwt emulation .. add Class.getSimpleName to gwt emulation fixes issue 3404 Change-Id: I7d4c9c34209f43fdfbf255d0d7ce8ac4bd002390 --- M user/super/com/google/gwt/emul/java/lang/Class.java 1 file changed, 8 insertions(+), 0 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2220 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I7d4c9c34209f43fdfbf255d0d7ce8ac4bd002390 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: James Nelson ja...@wetheinter.net Gerrit-Reviewer: Janek Bogucki jane...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: add Class.getSimpleName to gwt emulation
Daniel Kurka has posted comments on this change. Change subject: add Class.getSimpleName to gwt emulation .. Patch Set 4: some nit picking @James Lets discuss your suggestions in a new review / issue. -- To view, visit https://gwt-review.googlesource.com/2220 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7d4c9c34209f43fdfbf255d0d7ce8ac4bd002390 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: James Nelson ja...@wetheinter.net Gerrit-Reviewer: Janek Bogucki jane...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: add Class.getSimpleName to gwt emulation
John A. Tamplin has posted comments on this change. Change subject: add Class.getSimpleName to gwt emulation .. Patch Set 4: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/2220 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7d4c9c34209f43fdfbf255d0d7ce8ac4bd002390 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: James Nelson ja...@wetheinter.net Gerrit-Reviewer: Janek Bogucki jane...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Error while updating commits in gerrit
Thanks Thomas, somehow pushing directly to the branch didn`t work on other changes I had opened, but now this seems fine. Am 17.03.2013 um 00:14 schrieb Thomas Broyer t.bro...@gmail.com: On Saturday, March 16, 2013 10:45:31 PM UTC+1, Daniel Kurka wrote: I am having trouble lately with updating commits in gerrit: Anyone else seeing something like this? kurt@kmac:~/Documents/workspace-mgwt/gwt$ git push origin HEAD:refs/changes/2220 Any reason you're not just pushing to refs/for/master and let the Change-Id magic do the rest? https://gerrit-review.googlesource.com/Documentation/user-upload.html#push_replace What you're doing here is deprecated. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
If you call a method or access a field from pure JS, you aren't going to
get the JSO implementation -
com.google.gwt.dom.client.Element.removeClassName(String) doesn't exist in
the underlying browser, so we build it in Java, and talk to methods/fields
which *do* exist in the browser. In other cases we dispatch to static
methods that exist elsewhere in GWT. You can't call it from pure JS, so how
it works or what it needs shouldn't be considered when looking at how JSO
should behave and what code should be emitted.
There are many static fields which exist in existing JSOs already, but most
(all?) are final, and are Strings or other primitives, so are already
constants, not just fields. In the linked bug, an array is being kept, and
it isn't initialized in time. I've only found one case of a static field in
a JSO, and the docs suggest that it is optimized for dev mode.
Hypothetically, if Document were subclassed (it isn't final) and get() were
invoked by an instance method (consider referring to another document from
within an iframe), this issue could be tickled if it weren't for that
'optimization':
/**
* We cache Document.nativeGet() in DevMode, because crossing the JSNI
* boundary thousands of times just to read a constant value is slow.
*/
private static Document doc;
/**
* Gets the default document. This is the document in which the module is
* running.
*
* @return the default document
*/
public static Document get() {
if (GWT.isScript()) {
return nativeGet();
}
// No need to be MT-safe. Single-threaded JS code.
if (doc == null) {
doc = nativeGet();
}
return doc;
}
I recognize that the primary intent of JavaScriptObject is to offer a Java
API to a JavaScript object, but there are plenty of cases where that JSOs
are used to achieve other points, or contain logic beyond what might
normally be necessary. Ray Cromwell wrote a post a few years ago that
encouraged using JSOs to 'cheat' the Java type system a bit -
http://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerful-than.html
- these examples don't make use of fields, but it seems a logical next step
to add a little logic to some of these psuedo-categories.
To look at my own use case, GXT extends Element as XElement to allow Java
method calls to cache some values as XElement is used. We've worked around
this by moving those to a static inner non-JSO type - they remain private,
static, and final, and behave as expected with this workaround.
So, with all of this in mind, a change to make this 'as designed' will
warn/error on any static field that is not a) final and b)
String/primitive, and on any static block? Or, can we consider the utility
of the JSO class to be something that is actually meant to be used only
from Java, so we don't care what happens to the underlying JavaScript
object, and how that continues to behave as JS normally would?
On Saturday, March 16, 2013 4:43:13 PM UTC-5, John A. Tamplin wrote:
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
The problem with this answer is that the failure is silent and surprising
for Java developers, and that the optimizations can make it even more so.
If I recall correctly, calling a static method in the same type from an
instance method is not enough to get the static initializer called - an
optimization prunes the clinit.
I have a patch that restores clinits from instance methods, but I'm out
of reach of it at the moment. I haven't made a code review yet in the
interest of adding tests for this case.
I don't see how you can add clinits on a JSO -- the point is it is a plain
JS object under the hood (ignoring all the magic to make it work in
DevMode). If you call a method or access a field from pure JS, how can it
know to call the clinit?
If we do decide that cl units should be pruned, we should stop cutting
them from other newly 'static' methods - at least in that case bit must be
a bug. If not that, then emit a warning?
I'm fine with making it an error.
--
John A. Tamplin
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
