[gwt-contrib] Comment on CodeSplitting in google-web-toolkit
Comment by m.zdila: Hello. This is certainly a nice feature, but one not requiring a monolithic compile would be that just great. Our application is built on top of OSGi. When a new module is added a new menu item appears in the GUI to access that module GUI (under different URL). Currently we must compile each OSGi module with the common Workspace library project and so the common Workspace part is duplicated over the modules and so needs to be loaded together with each module code. This is because of the monolithic build. Much nicer would be a separate Workspace module that just lazy-loads its (OSGi based) dynamic view modules on demand (menu item clicks). Is there any plan to make possible to do it like this? Thanks in advance. For more information: http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by rjand541: OKAY!! For the extreme newbie out there like myself. I may have an answer for you. First: My setup is Ubuntu 9.04 in 64 bit mode, with Eclipse 3.4, GWT 1.6, GAE 1.2 and Java 1.6. I went through everything on these boards and bits and pieces were hidden here and there. My first real issue was this error... Exception in thread main java.lang.UnsatisfiedLinkError: /home/bin/packages/eclipse3.4/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/libswt-pi-gtk-3235.so: /home/bin/packages/eclipse3.4/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/libswt-pi-gtk-3235.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) taha had a similar problem on this page: https://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/25d7c210c6b92e59?pli=1 The solution to which was to simply install a 32 bit version of Java, (Java 1.50) and have eclipse point to it under Properties - Run/Debug Settings - (select your project) - edit - JRE tab. The next error wasn't mission critical, but nonetheless, it annoyed the heck out of me... Gtk-Message: Failed to load module canberra-gtk-module: /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64 This was solved by following the same steps above but instead of the properties tab hitting the environment tab. Then entering a variable called GTK_PATH and setting the value to /usr/lib32/gtk-2.0 That took care of that. Next up was this error... com.google.apphosting.utils.jetty.JettyLogger warn WARNING: failed greetServlet java.lang.UnsupportedClassVersionError: Bad version number in .class file This was solved by our 64 bit cousins on the Mac under this thread http://groups.google.com/group/google-appengine-java/browse_thread/thread/da29f92b3677a1ef Go to properties again, but this time select Java Compiler. Set the compiler compliance level to 1.5. That is it. It should fix your issues if you are in a similar boat as me. I didn't have to ant anything, svn checkout branches or any of that. Even though I did. Multiple times. To make sure i didn't do it wrong. Hope I can save someone some time and thanks to all those that participate on these threads. You are lifesavers! For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by rjand541: OKAY!! For the extreme newbie out there like myself. I may have an answer for you. First: My setup is Ubuntu 9.04 in 64 bit mode, with Eclipse 3.4, GWT 1.6, GAE 1.2, Java 1.6 with the OOPHM plug in for firefox 3.0.11 I went through everything on these boards and bits and pieces were hidden here and there. My first real issue was this error... Exception in thread main java.lang.UnsatisfiedLinkError?: /home/bin/packages/eclipse3.4/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/libswt-pi-gtk-3235.so: /home/bin/packages/eclipse3.4/plugins/com.google.gwt.eclipse.sdkbundle.linux_1.6.4.v200904062334/gwt-linux-1.6.4/libswt-pi-gtk-3235.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) taha had a similar problem on this page: https://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/25d7c210c6b92e59?pli=1 The solution to which was to simply install a 32 bit version of Java, (Java 1.50) and have eclipse point to it under Properties - Run/Debug Settings - (select your project) - edit - JRE tab. The next error wasn't mission critical, but nonetheless, it annoyed the heck out of me... Gtk-Message: Failed to load module canberra-gtk-module: /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64 This was solved by following the same steps above but instead of the properties tab hitting the environment tab. Then entering a variable called GTK_PATH and setting the value to /usr/lib32/gtk-2.0 That took care of that. Next up was this error... com.google.apphosting.utils.jetty.JettyLogger? warn WARNING: failed greetServlet java.lang.UnsupportedClassVersionError?: Bad version number in .class file This was solved by our 64 bit cousins on the Mac under this thread http://groups.google.com/group/google-appengine-java/browse_thread/thread/da29f92b3677a1ef Go to properties again, but this time select Java Compiler. Set the compiler compliance level to 1.5. That is it. It should fix your issues if you are in a similar boat as me. Try it out and everything should pop up fine and appear to be working. Or is it... I guess only time will tell. Thanks to the many that contribute to these boards. For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add ArtificialRescue annotation to compiler
On 2009/06/29 13:40:16, bobv wrote: Ping Ping. http://gwt-code-reviews.appspot.com/46801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: NewParenthesisRemovalOptimization
W00t, thanks Ray! I've been meaning to do something about this list of
peephole optimizations for some time, but you're much more likely to be able
to get through them quickly than I am. The good news is that going through
the entire list gives a 15-20% code size reduction on Hello (roughly
measured by hand). And I don't think any of them are complex.
On Wed, Jul 1, 2009 at 8:10 PM, Scott Blum sco...@google.com wrote:
LGTM, but only if you fix the darn for-each using Object var!
On Wed, Jul 1, 2009 at 7:50 PM, cromwell...@gmail.com wrote:
Reviewers: scottb,
Description:
This patch removes trailing parenthesis from Javascript 'new' operators
if there are no constructor arguments.
new Foo() - new Foo
Please review this at http://gwt-code-reviews.appspot.com/49804
Affected files:
dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
Index: dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
===
--- dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(revision 5638)
+++ dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(working copy)
@@ -583,16 +583,18 @@
_rparen();
}
-_lparen();
-boolean sep = false;
-for (Object element : x.getArguments()) {
- JsExpression arg = (JsExpression) element;
- sep = _sepCommaOptSpace(sep);
- _parenPushIfCommaExpr(arg);
- accept(arg);
- _parenPopIfCommaExpr(arg);
+if (x.getArguments().size() 0) {
+ _lparen();
+ boolean sep = false;
+ for (Object element : x.getArguments()) {
+JsExpression arg = (JsExpression) element;
+sep = _sepCommaOptSpace(sep);
+_parenPushIfCommaExpr(arg);
+accept(arg);
+_parenPopIfCommaExpr(arg);
+ }
+ _rparen();
}
-_rparen();
return false;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Allow @def to be retrieved as a String from CssResource
I added a test to show that the @ClassName annotation works to
differentiate between an @def and a class name accessor.
http://gwt-code-reviews.appspot.com/50804/diff/1/5
File user/src/com/google/gwt/resources/css/ast/CssVisitor.java (right):
http://gwt-code-reviews.appspot.com/50804/diff/1/5#newcode188
Line 188: e.printStackTrace();
On 2009/06/30 21:00:45, bobv wrote:
Remove.
Done.
http://gwt-code-reviews.appspot.com/50804/diff/1/6
File user/src/com/google/gwt/resources/rg/CssResourceGenerator.java
(right):
http://gwt-code-reviews.appspot.com/50804/diff/1/6#newcode1739
Line 1739: if
(String.equals(toImplement.getReturnType().getSimpleSourceName())) {
On 2009/06/30 21:00:45, bobv wrote:
Use JClassType comparison for correctness. This would match
com.foo.String.
Done.
http://gwt-code-reviews.appspot.com/50804/diff/1/6#newcode1740
Line 1740: returnExpr = \ + def.getValues().get(0) + \;
On 2009/06/30 21:00:45, bobv wrote:
The value has to be escaped; see the Generator.escape().
Done.
http://gwt-code-reviews.appspot.com/50804/diff/1/6#newcode1790
Line 1790: // TODO(zundel): make conditional on Strict mode?
On 2009/06/30 21:00:45, bobv wrote:
This condition should always be an error.
Done.
http://gwt-code-reviews.appspot.com/50804/diff/1/4
File user/test/com/google/gwt/resources/client/test.css (right):
http://gwt-code-reviews.appspot.com/50804/diff/1/4#newcode24
Line 24:
On 2009/06/30 21:00:45, bobv wrote:
Revert.
Done.
http://gwt-code-reviews.appspot.com/50804
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT emulation of HTML5/CSS3 features
I'm very much on board with the idea of moving forward on new browser features by emulating them on old browsers wherever possible. This is an important benefit of using tools (code generation, deferred binding, monolithic compilation) to get leverage on this problem. I think the best approach is to consider each such feature separately. They're going to require different approaches (e.g., some can be dealt with entirely in CssResource, but others will likely require the use of specific classes), and some will turn out to be impossible, or practically so (e.g., support for the video tag without a transcoding server to deal with Ogg, H.264, Flash, etc). So for the specific cases described below... CSS Animations: I think we need to actually measure the performance difference before deciding whether it's even worth the trouble. I suspect that there may not be much of one (though of course I could be wrong), given that it has to do the same work, possibly including layout, regardless of how it's specified. And CSS animations aren't as general as programmatic ones. That said, there might be some utility in having CssResource parse them automatically and write the necessary code for you on older browsers (though I haven't assessed the feasibility of doing so). Rounded Corners / DecoratorPanel: Here I think it's going to be a practical necessity to require that a specific class (such as DecoratorPanel) be used. The reason is that, to my knowledge, there is no way to get general 9-box rounded corners without a specific DOM structure. But DecoratorPanel could be modified to take advantage of CSS3 9-boxes on newer browsers. DataGrid: I honestly haven't read enough about this proposal to have any idea whether it makes sense or not. But if it is implemented and offers a substantive advantage, then we should certainly have a look. Some others that might be interesting: Canvas: This is a nasty case, because Canvas cannot be implemented sanely or efficiently on top of VML, which is the only game in IE town. Existing canvas-on-VML implementations notwithstanding -- they have wildly different performance semantics, which is pretty unacceptable in my opinion. SVG: Things are a bit brighter here. There are some things (foreign objects and certain gradient patterns come to mind) that SVG can do, which VML cannot. But a sane navigation of the common features could lead to a quite usable and efficient vector graphics library. There's the existing GWTCanvas that Jaime wrote a while back as a starting point (which uses Canvas rather than SVG), but it appears to me that SVG performance has gotten a lot better since that was written, so it's probably worth reconsidering that approach. HTML5/Gears Database: Geolocation: These shouldn't be too difficult, as applications can be easily made sensitive to their presence or absence. The database/client-side storage APIs may need some cross-browser love, as there are a few different approaches and subtle differences across browsers, but I believe that is manageable. Cross-Document Messaging: I'm pretty sure this can be emulated with window.name hackery. App Cache: This is something we should support at the Linker level. And like the database APIs, an application can be made sensitive to its availability without too much difficulty. CSS Transforms: I think we're pretty much screwed on this front. We could *try* to do translation, but I seriously doubt it's worth the trouble (and would probably cause layout issues, as the semantics are subtly different than left: and top:). But rotation and scale (not to mention arbitrary affine transforms) seem impossible to emulate. audio, video: I'm not terribly bullish on these. audio is at least theoretically supportable using Flash, and I could see something like the SoundManager2 js library taking advantage of it. But video is rife with codec licensing problems that seem unlikely to get resolved any time soon (If anyone wants to debate the ins and outs of codec licensing, let's *please* do so on another thread, because I can tell you from experience that the thread won't converge). And of course, there are probably others I'm not thinking of, so feel free to chime in with ideas. joel. On Wed, Jul 1, 2009 at 1:09 AM, nicolas de loof nicolas.del...@gmail.comwrote: Transparent support for CSS3/HTML5 on all browsers including IE would be a killer feature !+1 2009/7/1 tfreitas tfrei...@gmail.com +1 On Jun 29, 10:24 am, dflorey daniel.flo...@gmail.com wrote: Hi, I've been wondering how GWT should deal with upcoming new features in HTML5/CSS3. There are several areas where functionality that has been implemented in GWT is now also available in the upcoming rendering engines. GWT is creating highly optimized JavaScript and the JavaScript-engines are getting better and better... but: My guess is that for example animations will be smoother when using CSS3 animations instead of JavaScript based
[gwt-contrib] Re: GWT emulation of HTML5/CSS3 features
Another aspect to consider is how to connect an HTML5 feature to the compiler permutations. Right now we have 5 browser permutations, and only the latest versions of these browsers offer support for (some) HTML5 features. Potentially the amount of permutations accumulate significantly if fine-grained HTML5 support is desired. What would be the best approach here? I am trying to setup some GWT API's for these HTML5 features at my gwt- mobile-webkit googlecode project, and I'm still not sure what the best approach is to the problem. You could argue that the amount of permutations is totally unimportant since you can subset just a few of them for testing purposes. What do you guys think? Bart Guijt On 2 jul 2009, at 2 jul, 17:03, Joel Webber wrote: I'm very much on board with the idea of moving forward on new browser features by emulating them on old browsers wherever possible. This is an important benefit of using tools (code generation, deferred binding, monolithic compilation) to get leverage on this problem. I think the best approach is to consider each such feature separately. They're going to require different approaches (e.g., some can be dealt with entirely in CssResource, but others will likely require the use of specific classes), and some will turn out to be impossible, or practically so (e.g., support for the video tag without a transcoding server to deal with Ogg, H.264, Flash, etc). So for the specific cases described below... CSS Animations: I think we need to actually measure the performance difference before deciding whether it's even worth the trouble. I suspect that there may not be much of one (though of course I could be wrong), given that it has to do the same work, possibly including layout, regardless of how it's specified. And CSS animations aren't as general as programmatic ones. That said, there might be some utility in having CssResource parse them automatically and write the necessary code for you on older browsers (though I haven't assessed the feasibility of doing so). Rounded Corners / DecoratorPanel: Here I think it's going to be a practical necessity to require that a specific class (such as DecoratorPanel) be used. The reason is that, to my knowledge, there is no way to get general 9-box rounded corners without a specific DOM structure. But DecoratorPanel could be modified to take advantage of CSS3 9-boxes on newer browsers. DataGrid: I honestly haven't read enough about this proposal to have any idea whether it makes sense or not. But if it is implemented and offers a substantive advantage, then we should certainly have a look. Some others that might be interesting: Canvas: This is a nasty case, because Canvas cannot be implemented sanely or efficiently on top of VML, which is the only game in IE town. Existing canvas-on-VML implementations notwithstanding -- they have wildly different performance semantics, which is pretty unacceptable in my opinion. SVG: Things are a bit brighter here. There are some things (foreign objects and certain gradient patterns come to mind) that SVG can do, which VML cannot. But a sane navigation of the common features could lead to a quite usable and efficient vector graphics library. There's the existing GWTCanvas that Jaime wrote a while back as a starting point (which uses Canvas rather than SVG), but it appears to me that SVG performance has gotten a lot better since that was written, so it's probably worth reconsidering that approach. HTML5/Gears Database: Geolocation: These shouldn't be too difficult, as applications can be easily made sensitive to their presence or absence. The database/client- side storage APIs may need some cross-browser love, as there are a few different approaches and subtle differences across browsers, but I believe that is manageable. Cross-Document Messaging: I'm pretty sure this can be emulated with window.name hackery. App Cache: This is something we should support at the Linker level. And like the database APIs, an application can be made sensitive to its availability without too much difficulty. CSS Transforms: I think we're pretty much screwed on this front. We could *try* to do translation, but I seriously doubt it's worth the trouble (and would probably cause layout issues, as the semantics are subtly different than left: and top:). But rotation and scale (not to mention arbitrary affine transforms) seem impossible to emulate. audio, video: I'm not terribly bullish on these. audio is at least theoretically supportable using Flash, and I could see something like the SoundManager2 js library taking advantage of it. But video is rife with codec licensing problems that seem unlikely to get resolved any time soon (If anyone wants to debate the ins and outs of codec licensing, let's
[gwt-contrib] [google-web-toolkit commit] r5659 - Test for generics resolution.
Author: j...@google.com
Date: Thu Jul 2 07:57:32 2009
New Revision: 5659
Added:
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeParameterLookup.java
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/asm/ResolveClassSignature.java
changes/jat/ihm/dev/core/test/com/google/gwt/core/ext/typeinfo/TypeOracleMocks.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/ResolveGenericsTest.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/TestHandler.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/TestHandler1.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/TestOuter0.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/TestOuter1.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/TestOuter2.java
Removed:
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/asm/ResolveClassTypeVariables.java
Modified:
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/asm/ResolveMethodSignature.java
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/asm/ResolveParameterizedType.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/MockCompilationUnit.java
changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/asm/AsmTestCase.java
Log:
Test for generics resolution.
Modified:
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java
==
---
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java
(original)
+++
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java
Thu Jul 2 07:57:32 2009
@@ -48,7 +48,7 @@
import com.google.gwt.dev.javac.asm.CollectFieldData;
import com.google.gwt.dev.javac.asm.CollectMethodData;
import com.google.gwt.dev.javac.asm.CollectTypeParams;
-import com.google.gwt.dev.javac.asm.ResolveClassTypeVariables;
+import com.google.gwt.dev.javac.asm.ResolveClassSignature;
import com.google.gwt.dev.javac.asm.ResolveMethodSignature;
import com.google.gwt.dev.javac.asm.ResolveParameterizedType;
import com.google.gwt.dev.javac.asm.CollectAnnotationData.AnnotationData;
@@ -65,7 +65,6 @@
import java.util.Collection;
import java.util.HashMap;
import java.util.HashSet;
-import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Set;
@@ -77,51 +76,8 @@
public class TypeOracleMediator {
/**
- * Handles lookup of type parameters, handling a scope stack.
+ * Pairs of bits to convert from ASM Opcodes.* to Shared.* bitfields.
*/
- public static class TypeParameterLookup {
-
-private LinkedListHashMapString, JTypeParameter scopeStack = new
LinkedListHashMapString, JTypeParameter();
-
-public JTypeParameter lookup(String name) {
- for (HashMapString, JTypeParameter scope : scopeStack) {
-if (scope.containsKey(name)) {
- return scope.get(name);
-}
- }
- return null;
-}
-
-public void popScope() {
- scopeStack.remove();
-}
-
-public void pushEnclosingScopes(JClassType type) {
- if (type == null) {
-return;
- }
- pushEnclosingScopes(type.getEnclosingType());
- JGenericType genericType = type.isGenericType();
- if (genericType != null) {
-pushScope(genericType.getTypeParameters());
- }
-}
-
-public void pushScope(JTypeParameter[] typeParams) {
- // push empty scopes to keep pops in sync
- scopeStack.addFirst(buildScope(typeParams));
-}
-
-private HashMapString, JTypeParameter buildScope(
-JTypeParameter[] typeParams) {
- HashMapString, JTypeParameter scope = new HashMapString,
JTypeParameter();
- for (JTypeParameter typeParam : typeParams) {
-scope.put(typeParam.getName(), typeParam);
- }
- return scope;
-}
- }
-
private static final int[] ASM_TO_SHARED_MODIFIERS = new int[] {
Opcodes.ACC_PUBLIC, Shared.MOD_PUBLIC,
Opcodes.ACC_PRIVATE, Shared.MOD_PRIVATE,
@@ -172,13 +128,13 @@
}
private static JTypeParameter[] collectTypeParams(String signature) {
-// TODO(jat): more efficient when signature is null
-ListJTypeParameter params = new ArrayListJTypeParameter();
if (signature != null) {
+ ListJTypeParameter params = new ArrayListJTypeParameter();
SignatureReader reader = new SignatureReader(signature);
reader.accept(new CollectTypeParams(params));
+ return params.toArray(new JTypeParameter[params.size()]);
}
-return params.toArray(new JTypeParameter[params.size()]);
+return new JTypeParameter[0];
}
private static T Class? extends T getClassLiteral(TreeLogger logger,
@@ -583,6 +539,16 @@
}
}
+ private boolean isPrivateEnumConstructor(JAbstractMethod method,
[gwt-contrib] Re: GWT emulation of HTML5/CSS3 features
On 2 juil, 17:03, Joel Webber j...@google.com wrote: Some others that might be interesting: Canvas: This is a nasty case, because Canvas cannot be implemented sanely or efficiently on top of VML, which is the only game in IE town. Existing canvas-on-VML implementations notwithstanding -- they have wildly different performance semantics, which is pretty unacceptable in my opinion. There's also the Gears Canvas (you could get a data: URL out of it and give it in an Image for IE8+) and of course Flash (think Chronoscope ;-) ) and/or Silverlight. SVG: Things are a bit brighter here. There are some things (foreign objects and certain gradient patterns come to mind) that SVG can do, which VML cannot. But a sane navigation of the common features could lead to a quite usable and efficient vector graphics library. There's the existing GWTCanvas that Jaime wrote a while back as a starting point (which uses Canvas rather than SVG), but it appears to me that SVG performance has gotten a lot better since that was written, so it's probably worth reconsidering that approach. And for IE compatibility, Silverlight again (see http://intertwingly.net/blog/2008/01/26/SVG-Shiv and similar articles on Sam Ruby's blog) HTML5/Gears Database: Geolocation: These shouldn't be too difficult, as applications can be easily made sensitive to their presence or absence. The database/client-side storage APIs may need some cross-browser love, as there are a few different approaches and subtle differences across browsers, but I believe that is manageable. It definitely is: http://google-code-updates.blogspot.com/2009/05/gmail-for-mobile-html5-series-common.html Cross-Document Messaging: I'm pretty sure this can be emulated with window.name hackery. Cannot we rather consider this an optional feature, just like database, geolocation and app cache? App Cache: This is something we should support at the Linker level. And like the database APIs, an application can be made sensitive to its availability without too much difficulty. CSS Transforms: I think we're pretty much screwed on this front. We could *try* to do translation, but I seriously doubt it's worth the trouble (and would probably cause layout issues, as the semantics are subtly different than left: and top:). But rotation and scale (not to mention arbitrary affine transforms) seem impossible to emulate. audio, video: I'm not terribly bullish on these. audio is at least theoretically supportable using Flash, and I could see something like the SoundManager2 js library taking advantage of it. But video is rife with codec licensing problems that seem unlikely to get resolved any time soon (If anyone wants to debate the ins and outs of codec licensing, let's *please* do so on another thread, because I can tell you from experience that the thread won't converge). And of course, there are probably others I'm not thinking of, so feel free to chime in with ideas. Drag'n'drop! (using Gears or Yahoo! BrowserPlus as an alternative to browser-native support –if detectable–) And there are a few other things that have been split from HTML5 into their own spec: - Web Workers (optional feature, same as database, geolocation, etc. see above) - WebSockets (using long-polling –eventually in a Worker– for now as no-one implements it) - File API (use Gears or BrowserPlus as a fallback when available) - XMLHttpRequest 2 (progress events and ability to send binary data from the File API; again, Gears could be used to emulate it, BrowserPlus to a lesser extent) - Selectors API (already supported by GQuery) See http://www.w3.org/2008/webapps/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
Did anything come of this? Alex -- does your approach work with GWT 1.6? And, have you decided to contribute this anywhere? I'll understand if you aren't willing, but I figured it can't hurt to ask. jay On May 7, 1:24 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote: Hi Bob, Could you provide some numbers in terms of raw and gzipped before/after bytes? This is the OBF compiled js size of a TypeRacer module before and after instrumentation (raw/gz): 382/118 vs. 505/142 which can be further reduced by using shortened identifiers instead of method name strings (it doesn't make much difference when gzipped, though). In terms of inlining, I've implemented the optimization of not instrumenting simple getters and setters, which are guaranteed not to raise an exception. Everything else will probably not be eligible for inlining. But I do provide an annotation which you can use to exclude your hot methods from instrumentation. I looked at implementing perfect stack traces as an AST visitor, but decided that the size cost, speed cost for inlining, and potential data-leakage for large apps would outweigh the marginal gain of having line-level resolution in deployed apps. I'm not sure if that's necessarily the case. However, the capability you've implemented may very well be sufficient. I'm looking forward to testing out your code when I have more time. Those tradeoffs do make sense for development and QA versions of an app, but there was only a limited amount of time allocated for implementing stack traces. Yes, I can tell you from experience that what I did was pretty hairy and definitely took a good amount of time. There are lots of corner cases to consider when rewriting a Java AST, as you probably know. Just to give a tiny example - you can't insert anything before a super() statement. But at this point I have them all covered. I'm not yet sure if I'll be open-sourcing my code. I need to support my business, which isn't making much from online ad revenue, and I was hoping some of the enterprises using GWT might be happy to pay for my stack trace system. There are a few commercial tools in the GWT space, such aswww.instantiations.com/GWTDesigner, but I'm not sure how successful they are. I'd love to get some feedback from you guys about this idea. I can go both ways at this point. Your approach sounds complementary to the existing implementation. That's what I was hoping. Thanks, Alex On Thu, May 7, 2009 at 9:50 AM, BobV b...@google.com wrote: On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I'm using static code rewriting at the Java source level to maintain a virtual stack. It's actually working out very well so far. Getting surprisingly good results for code size, efficiency, and correctness. Could you provide some numbers in terms of raw and gzipped before/after bytes? Also, how does this interact with method and function inlining? I want to decide whether it's worth the effort to continue developing my system. So my questions are does StackTraceCreator work with all browsers and is your symbol translation system ready to be used? Are there any limitations with your approach? Perhaps there is some area where my technique could provide better information to the programmer? StackTraceCreator is invoked in Throwable's initalizer and will extract as much data as the browser provides. On Mozilla, you'll get a full stack trace. On other browsers it crawls the caller chain, but since the caller chain isn't a proper series of activation records, and there's a limitation on reentrant functions. In the end, it provides method-level resolution. The symbol map file has enough data to cook a respectable StackTraceElement that makes IDE integration not unreasonable. I looked at implementing perfect stack traces as an AST visitor, but decided that the size cost, speed cost for inlining, and potential data-leakage for large apps would outweigh the marginal gain of having line-level resolution in deployed apps. Those tradeoffs do make sense for development and QA versions of an app, but there was only a limited amount of time allocated for implementing stack traces. Your approach sounds complementary to the existing implementation. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5661 - correcting copied branch-info.txt
Author: fabb...@google.com Date: Thu Jul 2 10:49:58 2009 New Revision: 5661 Modified: releases/1.7/branch-info.txt Log: correcting copied branch-info.txt Modified: releases/1.7/branch-info.txt == --- releases/1.7/branch-info.txt(original) +++ releases/1.7/branch-info.txtThu Jul 2 10:49:58 2009 @@ -1,74 +1,11 @@ -branch-info.txt for GWT 1.6 release: +branch-info.txt for GWT 1.7 release: Tracks interactions between this branch and other branches. See: http://code.google.com/p/google-web-toolkit/wiki/ManagingMerges Copies: -/releases/1.6/ was created (r3732) as a straight copy from /trunk/@r3683 +/releases/1.7/ was created (r5660) as a straight copy from /releases/1...@r5659, because adding ie8 was deemed a minor version bump. Merges: -/trunk revisions c3688,c3703,c3700,c3704,c3707,c3715,c3717,c3724,c3725 were merged (r3739) into this branch -/trunk revision c4859 was merged (r4870) into this branch -/trunk revision c4867 was merged (r4871) into this branch -/releases/1.5/@r3630:3863 was merged (r3864) into this branch -/releases/1.6/@r3739:3876 was merged (r3877) into trunk -/releases/1.6/@r3878:3944 was merged (r3945) into trunk, skipping c3878 -/releases/1.6/@r3944:4025 was merged (r4032) into trunk -/branches/1_6_clean_eve...@3936:4088 was merged (r4092) into this branch -/releases/1.5/@r3863:4093 was merged (r4134) into this branch -/releases/1.6/@r4025:4130 was merged (r4142) into trunk, superceding trunk:c4118 -/releases/1.6/@r4130:4147 was merged (r4148) into trunk -/releases/1.6/@r4147:4198 was merged (r4202) into trunk -/releases/1.6/@c4269, c4298, and c4299 were merged (r4314) into trunk; note this is a cherrypick -/trunk revision c4266 was merged (r4321) into this branch -/releases/1.6/@r4198:4268 was merged (r4367,r4368) into trunk -/releases/1.6/@r4269:4297 was merged (r4367,r4368) into trunk, skipping c4269 (already merged, c4314) -/releases/1.6/@r4299:4320 was merged (r4367,r4368) into trunk, skipping c4298, c4299 (already merged, c4314) -/releases/1.6/@r4321:4366 was merged (r4367,r4368) into trunk, skipping c4321 (backmerge from trunk) -/releases/1.6/@r4366:4385 was merged (r4386) into trunk -/releases/1.6/@r4385:4459 was merged (r4488) into trunk -/releases/1.6/@r4359:4490 was merged (r4491) into trunk -/releases/1.6/@c4498 was merged (r4499) into trunk (cherry pick) -/releases/1.6/@r4490:4497,4498:4511 was merged (r4512) into trunk, skipping c4498 (cherry picked above) -/trunk revision c4603 was merged (r4605) into this branch -/releases/1.6/@r4511:4604,4605:4657 was merged (r4659) into trunk, skipping c4605 (backmerge from trunk) -/releases/1.6/@r4657:4658 was merged (r4662) into trunk -/releases/1.6/@r4658:4669 was merged (r4670) into trunk -/trunk revision c4873 was merged (r4878) into this branch -/trunk revision c4889 was merged (r4892) into this branch -/releases/1.6/@r4669:4694 was merged (r4919) into trunk -/releases/1.6/@r4695:4874 was merged (r4919) into trunk, skipping c4695 (1.6-only change) -/releases/1.6/@r4875:4877 was merged (r4919) into trunk, skipping c4875 (different trunk change) -/releases/1.6/@r4878:4891 was merged (r4919) into trunk, skipping c4878 (backmerge from trunk) -/releases/1.6/@r4892:4911 was merged (r4919) into trunk, skipping c4892 (backmerge from trunk) -/releases/1.6/@c4963 was merged (r4970 into trunk (cherry pick) -/releases/1.6/@r4911:4992 was merged (r4993) into trunk, skipping c4963 (cherry picked above) -/releases/1.6/@r5023 was merged (r5024) into trunk (cherry pick) -/releases/1.6/@r4992:5022 was merged (r5065) into trunk -/releases/1.6/@r5023:5064 was merged (r5065) into trunk -/releases/1.6/@r5065:5406 was merged (r5421) into trunk -/trunk revision c5072 was merged (r5407) into this branch -/trunk revision c5194 was merged (r5411) into this branch -/trunk revision c5216 was merged (r5423) into this branch -/trunk revision c5292 was merged (r5423) into this branch -/trunk revision c5287 was merged (r5425) into this branch -/trunk revision c5305 was merged (r5426) into this branch -/trunk revision c5306 was merged (r5427) into this branch -/trunk revision c5320 was merged (r5428) into this branch (this was a mistake, rolled back in r5434) -/trunk revision c5333 was merged (r5429) into this branch -/trunk revision c5398 was merged (r5430) into this branch -/releases/1.6 [r5408:5410 r5411:5422 r5423:5424] was merged into trunk (no changes in these ranges) -/trunk revision c4820 was merged (r5439) into this branch -/trunk revision c5230 was merged (r5440) into this branch -/trunk revision c5347 was merged (r5443) into this branch (removes broken test from c5333) -/trunk revision c5460 was merged (r5461) into this branch (radio button fix) -/trunk revision c5221 was merged (r5520) into this branch (SerializabilityUtil race condition) -/trunk revision c5601 was merged (r) into this branch (misc JSNI
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
Jay, I've been using this code in production since early June. Works well. I'm still using 1.5 for that particular project, but there's no reason it wouldn't work with 1.6, because the code isn't even aware of GWT, so it's agnostic of versions. Not ready to release publicly yet, but if you really want it, email me off-forum. Alex On Thu, Jul 2, 2009 at 12:33 PM, jayjay.gin...@gmail.com wrote: Did anything come of this? Alex -- does your approach work with GWT 1.6? And, have you decided to contribute this anywhere? I'll understand if you aren't willing, but I figured it can't hurt to ask. jay On May 7, 1:24 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote: Hi Bob, Could you provide some numbers in terms of raw and gzipped before/after bytes? This is the OBF compiled js size of a TypeRacer module before and after instrumentation (raw/gz): 382/118 vs. 505/142 which can be further reduced by using shortened identifiers instead of method name strings (it doesn't make much difference when gzipped, though). In terms of inlining, I've implemented the optimization of not instrumenting simple getters and setters, which are guaranteed not to raise an exception. Everything else will probably not be eligible for inlining. But I do provide an annotation which you can use to exclude your hot methods from instrumentation. I looked at implementing perfect stack traces as an AST visitor, but decided that the size cost, speed cost for inlining, and potential data-leakage for large apps would outweigh the marginal gain of having line-level resolution in deployed apps. I'm not sure if that's necessarily the case. However, the capability you've implemented may very well be sufficient. I'm looking forward to testing out your code when I have more time. Those tradeoffs do make sense for development and QA versions of an app, but there was only a limited amount of time allocated for implementing stack traces. Yes, I can tell you from experience that what I did was pretty hairy and definitely took a good amount of time. There are lots of corner cases to consider when rewriting a Java AST, as you probably know. Just to give a tiny example - you can't insert anything before a super() statement. But at this point I have them all covered. I'm not yet sure if I'll be open-sourcing my code. I need to support my business, which isn't making much from online ad revenue, and I was hoping some of the enterprises using GWT might be happy to pay for my stack trace system. There are a few commercial tools in the GWT space, such aswww.instantiations.com/GWTDesigner, but I'm not sure how successful they are. I'd love to get some feedback from you guys about this idea. I can go both ways at this point. Your approach sounds complementary to the existing implementation. That's what I was hoping. Thanks, Alex On Thu, May 7, 2009 at 9:50 AM, BobV b...@google.com wrote: On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I'm using static code rewriting at the Java source level to maintain a virtual stack. It's actually working out very well so far. Getting surprisingly good results for code size, efficiency, and correctness. Could you provide some numbers in terms of raw and gzipped before/after bytes? Also, how does this interact with method and function inlining? I want to decide whether it's worth the effort to continue developing my system. So my questions are does StackTraceCreator work with all browsers and is your symbol translation system ready to be used? Are there any limitations with your approach? Perhaps there is some area where my technique could provide better information to the programmer? StackTraceCreator is invoked in Throwable's initalizer and will extract as much data as the browser provides. On Mozilla, you'll get a full stack trace. On other browsers it crawls the caller chain, but since the caller chain isn't a proper series of activation records, and there's a limitation on reentrant functions. In the end, it provides method-level resolution. The symbol map file has enough data to cook a respectable StackTraceElement that makes IDE integration not unreasonable. I looked at implementing perfect stack traces as an AST visitor, but decided that the size cost, speed cost for inlining, and potential data-leakage for large apps would outweigh the marginal gain of having line-level resolution in deployed apps. Those tradeoffs do make sense for development and QA versions of an app, but there was only a limited amount of time allocated for implementing stack traces. Your approach sounds complementary to the existing implementation. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: GWT emulation of HTML5/CSS3 features
On Thu, Jul 2, 2009 at 8:03 AM, Joel Webber j...@google.com wrote: CSS Animations: I think we need to actually measure the performance difference before deciding whether it's even worth the trouble. I suspect that there may not be much of one (though of course I could be wrong), given that it has to do the same work, possibly including layout, regardless of how it's specified. And CSS animations aren't as general as programmatic ones. That said, there might be some utility in having CssResource parse them automatically and write the necessary code for you on older browsers (though I haven't assessed the feasibility of doing so). It might be useful however to create an animation library that consists of declarative types, as well as custom animation types. If you compose declarative types, you potentially get CSS Animations or SMIL or HTML+TIME (IE), if you include a custom type (uses Java code) in the composition, then you get a pure programmatic fallback. Think of it as a type-safe enumeration pattern, where some types have deferred bindings (CSS Anim, SMIL, or pure JS) and others are just pure-JS. Canvas: This is a nasty case, because Canvas cannot be implemented sanely or efficiently on top of VML, which is the only game in IE town. Existing canvas-on-VML implementations notwithstanding -- they have wildly different performance semantics, which is pretty unacceptable in my opinion. It's possible to use Flash, but in general, performance can't come close to matching HTML5 canvas, not just because IE Javascript is so slow, but also because marshalling/unmarshalling between JS and Flash is slow. A bright spot is Silverlight, since the JS-Silverlight call mechanism is pretty efficient. On the downside, you can't depend on Silverlight. Canvas is also split, since some Canvas impls support text rendering and others do not. SVG: Things are a bit brighter here. There are some things (foreign objects and certain gradient patterns come to mind) that SVG can do, which VML cannot. But a sane navigation of the common features could lead to a quite usable and efficient vector graphics library. There's the existing GWTCanvas that Jaime wrote a while back as a starting point (which uses Canvas rather than SVG), but it appears to me that SVG performance has gotten a lot better since that was written, so it's probably worth reconsidering that approach. Brad Neuberg is actually working on a fairly complete SVG shim for IE using Flash, it appears performance and compatibility are good. audio, video: I'm not terribly bullish on these. audio is at least theoretically supportable using Flash, and I could see something like the SoundManager2 js library taking advantage of it. But video is rife with codec licensing problems that seem unlikely to get resolved any time soon (If anyone wants to debate the ins and outs of codec licensing, let's *please* do so on another thread, because I can tell you from experience that the thread won't converge). There's also the case that doing anything more interesting with video other than playback means accessing frame pixel data, and shipping them from Flash back into the browser would be *VERY* inefficient and slow. -Ray And of course, there are probably others I'm not thinking of, so feel free to chime in with ideas. joel. On Wed, Jul 1, 2009 at 1:09 AM, nicolas de loof nicolas.del...@gmail.comwrote: Transparent support for CSS3/HTML5 on all browsers including IE would be a killer feature !+1 2009/7/1 tfreitas tfrei...@gmail.com +1 On Jun 29, 10:24 am, dflorey daniel.flo...@gmail.com wrote: Hi, I've been wondering how GWT should deal with upcoming new features in HTML5/CSS3. There are several areas where functionality that has been implemented in GWT is now also available in the upcoming rendering engines. GWT is creating highly optimized JavaScript and the JavaScript-engines are getting better and better... but: My guess is that for example animations will be smoother when using CSS3 animations instead of JavaScript based animations. Same about rounded corners/shadows and stuff alike. In GWT you'll typically use DecoratedPanel to implement rounded corners with shadows. But Firefox3.5 and the latest Safari and Chrome releases also support css-based rounded borders and shadows. So my proposal would be to use deferred binding to emulate these features on browsers that do not support the latest features (IE8...) and to use a lightweight css based impl on WebKit/Firefox 3.5. In my example of DecoratedPanel the 9x9 approach should be kept for IE and a null impl with css based rounded corners should be available for Firefox (css have to match the given theme). Animations that come with the standard widgets should also be able to fallback to css based animations when available. I've been also reading some posts about the new datagrid html extension and thought it
[gwt-contrib] NewParenthesisRemovalOptimization
Reviewers: scottb,
Description:
This patch removes trailing parenthesis from Javascript 'new' operators
if there
are no constructor arguments.
new Foo() - new Foo
Now with fixes based on Scott's review, as well as some inline comments
in case future archaeologists after the apocalypse discover this code
and want to know the motivation.
Please review this at http://gwt-code-reviews.appspot.com/47808
Affected files:
dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
Index: dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
===
--- dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(revision 5638)
+++ dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(working copy)
@@ -583,16 +583,19 @@
_rparen();
}
-_lparen();
-boolean sep = false;
-for (Object element : x.getArguments()) {
- JsExpression arg = (JsExpression) element;
- sep = _sepCommaOptSpace(sep);
- _parenPushIfCommaExpr(arg);
- accept(arg);
- _parenPopIfCommaExpr(arg);
+// if an constructor call has no arguments, it may simply be
+// replaced with new Constructor with no parenthesis
+if (x.getArguments().size() 0) {
+ _lparen();
+ boolean sep = false;
+ for (JsExpression arg : x.getArguments()) {
+sep = _sepCommaOptSpace(sep);
+_parenPushIfCommaExpr(arg);
+accept(arg);
+_parenPopIfCommaExpr(arg);
+ }
+ _rparen();
}
-_rparen();
return false;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: NewParenthesisRemovalOptimization
http://gwt-code-reviews.appspot.com/47808/diff/1/2
File dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(right):
http://gwt-code-reviews.appspot.com/47808/diff/1/2#newcode587
Line 587: // replaced with new Constructor with no parenthesis
parentheses (plural)
http://gwt-code-reviews.appspot.com/47808/diff/1/2#newcode588
Line 588: if (x.getArguments().size() 0) {
Possible to call getArguments only once?
http://gwt-code-reviews.appspot.com/47808
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5660 - Creating 1.7 branch from 1.6
Author: fabb...@google.com Date: Thu Jul 2 10:40:03 2009 New Revision: 5660 Added: releases/1.7/ - copied from r5659, /releases/1.6/ Log: Creating 1.7 branch from 1.6 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Issue3796 Patch
Reviewers: ,
Description:
Syntax error due to inlining of numeric literal into jsni function
Java code:
public class Main implements EntryPoint {
private native static String toFixed(double value, int n) /*-{
return value.toFixed(n);
}-*/;
public void onModuleLoad() {
Window.alert(toFixed(42.0, 2));
}
}
Output:
$wnd.alert(42.toFixed(2))
// syntax error 42.toFixed(2) should be (42).toFixed(2)
This patch handles both invocations (42.method()) and name refs
(42.field).
Please review this at http://gwt-code-reviews.appspot.com/47809
Affected files:
dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
Index: dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
===
--- dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(revision 5638)
+++ dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(working copy)
@@ -982,6 +982,14 @@
p.print(CHARS_IF);
}
+ // Issue #3796, inlining of numeric literals can produce illegal JS
+ // expressions. x = 42, x.method() is legal. 42.method() is illegal.
+ // The fix is to add parentheses, e.g. (42).method()
+ private boolean _isWeirdLiteralDot(JsExpression parent, JsExpression
child) {
+return child instanceof JsNumberLiteral (parent instanceof
JsInvocation
+|| parent instanceof JsNameRef);
+ }
+
private void _in() {
p.print(CHARS_IN);
}
@@ -1044,9 +1052,10 @@
boolean wrongAssoc) {
int parentPrec = JsPrecedenceVisitor.exec(parent);
int childPrec = JsPrecedenceVisitor.exec(child);
-return (parentPrec childPrec || (parentPrec == childPrec
wrongAssoc));
+return (parentPrec childPrec || (parentPrec == childPrec
wrongAssoc) ||
+_isWeirdLiteralDot(parent, child));
}
-
+
private boolean _parenPop(JsExpression parent, JsExpression child,
boolean wrongAssoc) {
boolean doPop = _parenCalc(parent, child, wrongAssoc);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] ClientBundle inheritence issues
Reviewers: robertvawter_google.com,
Description:
http://b/issue?id=1958188
Please review this at http://gwt-code-reviews.appspot.com/48805
Affected files:
rg/CssResourceGenerator.java
Index: rg/CssResourceGenerator.java
===
--- rg/CssResourceGenerator.java(revision 5514)
+++ rg/CssResourceGenerator.java(working copy)
@@ -918,10 +918,18 @@
String functionName =
def.getValues().get(0).isIdentValue().getIdent();
// Find the method
- JMethod method = context.getClientBundleType().findMethod(
- functionName, new JType[0]);
-
- if (method == null) {
+ JMethod methods[] =
context.getClientBundleType().getOverridableMethods();
+ boolean foundMethod = false;
+ if (methods != null) {
+for (JMethod method : methods) {
+ if (method.getName().equals(functionName)) {
+foundMethod = true;
+break;
+ }
+}
+ }
+
+ if (!foundMethod) {
logger.log(TreeLogger.ERROR, Unable to find DataResource
method
+ functionName + in
+ context.getClientBundleType().getQualifiedSourceName());
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] ArrayAndObjectLiteralOptimization
Reviewers: scottb, jgw,
Description:
While fixing the other stuff in JsToStringGeneration, this seemed like
an easy one to add, but its effect is close to zero on most GWT code
bases.
new Array() - []
new Object() - {}
See
http://code.google.com/p/google-web-toolkit/wiki/ArrayAndObjectLiteralOptimization
It would only really help if some really bad Javascript programmers
wrote some really bad JSNI code.
Probably not worth committing, but review at your pleasure.
Please review this at http://gwt-code-reviews.appspot.com/47810
Affected files:
dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
Index: dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
===
--- dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(revision 5638)
+++ dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
(working copy)
@@ -570,10 +570,25 @@
@Override
public boolean visit(JsNew x, JsContextJsExpression ctx) {
+JsExpression ctorExpr = x.getConstructorExpression();
+// Implementation of wiki/ArrayAndObjectLiteralOptimization
+if(ctorExpr instanceof JsNameRef) {
+ String nameRef = ((JsNameRef)ctorExpr).getIdent();
+ if(Array.equals(nameRef)) {
+_lsquare();
+_rsquare();
+return false;
+ }
+ else if(Object.equals(nameRef)) {
+_lbrace();
+_rbrace();
+return false;
+ }
+}
+
_new();
_space();
-JsExpression ctorExpr = x.getConstructorExpression();
boolean needsParens = JsConstructExpressionVisitor.exec(ctorExpr);
if (needsParens) {
_lparen();
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] IE Access is denied javascript exception
Many users with IE 6-8 experience trouble loading my site the first time they try to access it. The site either never tries to load or else they get an access is denied error. I have tracked the access is denied error to the maybeCreateGwtFrame method in module.nocache.js. It is being throw on the line 204 ( var doc = win.document;). If the user refreshes the application will load perfectly. What I tried doing is wrapping those lines with a try block then redirecting however it doesn't appear to catch the exception thrown. I also have cut down my initial code from 700KB to 20KB with code splitting thinking that that might ease the situation. All it helped do is get to the exception quicker. (P.S. thank you for code spllitting) Does anyone have any suggestions for me to try? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: ArrayAndObjectLiteralOptimization
On 2009/07/02 20:24:57, cromwellian wrote: Hey, every little bit counts. LGTM. http://gwt-code-reviews.appspot.com/47810 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Improve correctness of UnicodeEscapingTest
Reviewers: jat, Message: Requesting review. Description: Splits UnicodeEscapingTest.testClientToServerBMP() into two methods so that failures are correctly reported. The current implementation will call finishTest() twice, which will desynchronize the junit framework, making failures harder to pin down. Extends the WebKit client-side escaping regex to pass all tests on Safari 4. The tests were failing due to sequences of combining characters not being handled correctly as well as codepoints getting switched out due to normalization. Removes support for Safari2. Please review this at http://gwt-code-reviews.appspot.com/48806 Affected files: M user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamWriter.java M user/test/com/google/gwt/user/client/rpc/UnicodeEscapingTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Improve correctness of UnicodeEscapingTest
LGTM other than removing the Safari2 support.
http://gwt-code-reviews.appspot.com/48806/diff/1/3
File user/test/com/google/gwt/user/client/rpc/UnicodeEscapingTest.java
(left):
http://gwt-code-reviews.appspot.com/48806/diff/1/3#oldcode66
Line 66: private static native boolean isSafari2() /*-{
Don't we still need this? Until we official drop support for Safari2
(and our build doesn't test it), I think we need to keep the test
passing there.
http://gwt-code-reviews.appspot.com/48806
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: ArrayAndObjectLiteralOptimization
There's a few corner cases in which this optimization may change the
meaning of code:
1. Name scoping of builtins using locals/builtins:
var Array = function() { this.toString = function() { return bleh; }
};
x = new Array()
alert(x);
var x = { Array: function() { this.toString = function() { return
bleh; } } };
with (x) {
y = new Array();
}
alert(y);
2. Parameters to constructor:
new Object(1) - wraps the object in the parameter so that it has a
different identity. This shouldn't be modified.
new Array(1,2,3) - wraps the parameters in a new array. This is always
equivalent to [1,2,3] (with the exception of cases that fall under 1
above).
http://gwt-code-reviews.appspot.com/47810
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Improve correctness of UnicodeEscapingTest
On 2009/07/02 20:58:49, jat wrote:
LGTM other than removing the Safari2 support.
http://gwt-code-reviews.appspot.com/48806/diff/1/3
File user/test/com/google/gwt/user/client/rpc/UnicodeEscapingTest.java
(left):
http://gwt-code-reviews.appspot.com/48806/diff/1/3#oldcode66
Line 66: private static native boolean isSafari2() /*-{
Don't we still need this? Until we official drop support for Safari2
(and our
build doesn't test it), I think we need to keep the test passing
there.
We (and just about everyone else) officially dropped support for Safari
2 some time ago. It was uncontroversial when discussed on gwt-contrib.
http://gwt-code-reviews.appspot.com/48806
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Improve correctness of UnicodeEscapingTest
On Thu, Jul 2, 2009 at 5:05 PM, j...@google.com wrote: We (and just about everyone else) officially dropped support for Safari 2 some time ago. It was uncontroversial when discussed on gwt-contrib. Ok -- Eric misinformed me about still running the Safari2 tests. In that case, we should remove its associated regex and the webkit version check that goes with it. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Improve correctness of UnicodeEscapingTest
http://gwt-code-reviews.appspot.com/48806 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: ArrayAndObjectLiteralOptimization
Oh crap. Good point, Matthew. I'm with Ray -- probably not worth it, given
this potential problem.
On Thu, Jul 2, 2009 at 5:36 PM, Ray Cromwell cromwell...@gmail.com wrote:
On Thu, Jul 2, 2009 at 2:02 PM, mmastrac.altern...@gmail.com wrote:
There's a few corner cases in which this optimization may change the
meaning of code:
1. Name scoping of builtins using locals/builtins:
var Array = function() { this.toString = function() { return bleh; }
};
x = new Array()
alert(x);
Ugh, you're right. Trapping this would be kind of tricky. I suppose I could
keep track of any vars in scope that shadow Array/Object. There's also the
case where
an insane person modifies the global Array ($wnd.Array = ...) Would be nice
if it implicity invoked Array's prototype constructor.
var x = { Array: function() { this.toString = function() { return
bleh; } } };
with (x) {
y = new Array();
}
alert(y);
This one is easy. GWT's Javascript parser does not support 'with'. It's
banned.
2. Parameters to constructor:
new Object(1) - wraps the object in the parameter so that it has a
different identity. This shouldn't be modified.
new Array(1,2,3) - wraps the parameters in a new array. This is always
equivalent to [1,2,3] (with the exception of cases that fall under 1
above).
This case can be handled.
Given the complexity of tracking variable shadowing vs the benefit this
patch provides, I'm not sure it's worth it. For example, in Showcase,
there's only a single call to new Array() in the entire output.
-Ray
http://gwt-code-reviews.appspot.com/47810
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Issue3796 Patch
Wow, you're right! I never thought of trying that. I'll leave it to Scott
whether he wants me to change this in favor of saving a character, since the
implementation would have to be hoisted out of the parenCheck stuff, and
this problem occurs very rarely.
-Ray
On Thu, Jul 2, 2009 at 2:50 PM, Ian Petersen ispet...@gmail.com wrote:
On Thu, Jul 2, 2009 at 12:53 PM, cromwell...@gmail.com wrote:
Reviewers: ,
Description:
Syntax error due to inlining of numeric literal into jsni function
Java code:
public class Main implements EntryPoint {
private native static String toFixed(double value, int n) /*-{
return value.toFixed(n);
}-*/;
public void onModuleLoad() {
Window.alert(toFixed(42.0, 2));
}
}
Output:
$wnd.alert(42.toFixed(2))
// syntax error 42.toFixed(2) should be (42).toFixed(2)
This patch handles both invocations (42.method()) and name refs
(42.field).
I think you can solve the same problem by inserting a space between
the ending digit and the period, which would save you one character
per instance if I'm remembering my JS syntax correctly.
Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Reduction of JavaScript class declarations.
Having a function like:
function d(){
return function(){};
}
... class declarations like:
function Foo(){}
... could be reduced to:
var Foo=d()
... reducing compiled code by 5 characters for each declaration.
- Andrés
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Reduction of JavaScript class declarations.
Even more code reduction could be done declaring all vars in the same
place:
function Foo1(){}
function Foo2(){}
function Foo3(){}
... could be reduced to
var Foo1=d(),Foo2=d(),Foo3=d();
- Andrés
On 2 jul, 19:11, Andrés Testi andres.a.te...@gmail.com wrote:
Having a function like:
function d(){
return function(){};
}
... class declarations like:
function Foo(){}
... could be reduced to:
var Foo=d()
... reducing compiled code by 5 characters for each declaration.
- Andrés
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: NewParenthesisRemovalOptimization
On Thu, Jul 2, 2009 at 12:14 PM, cromwell...@gmail.com wrote: Reviewers: scottb, Description: This patch removes trailing parenthesis from Javascript 'new' operators if there are no constructor arguments. new Foo() - new Foo Now with fixes based on Scott's review, as well as some inline comments in case future archaeologists after the apocalypse discover this code and want to know the motivation. Had a pretty random thought on the way to the bathroom: new Foo().bar() is equivalent to (new Foo).bar(). Is it equivalent to new Foo.bar()? I would expect not. Does that matter? Does the compiler generate code that looks like new Foo.bar() with your patch in place? Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: NewParenthesisRemovalOptimization
On Thu, Jul 2, 2009 at 3:23 PM, Ian Petersen ispet...@gmail.com wrote: Had a pretty random thought on the way to the bathroom: new Foo().bar() is equivalent to (new Foo).bar(). Is it equivalent to new Foo.bar()? I would expect not. Does that matter? Does the compiler generate code that looks like new Foo.bar() with your patch in place? The compiler (the code-gen JsToStringGenerator part) has a precedence checking routine for handling this. If you do new Foo().bar, if will replace it with (new Foo).bar. Since the JsInvocation (new operator) is supposed to bind tighter with the JsNameRef in the constructor expression than the 'bar' name ref is to the new. -Ray Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Best practice to implement Command Pattern RPC
Hi All,I am trying to implement command pattern RPC as discussed in google io Best Practices For Architecting Your GWT App : http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkit...http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkitBestPractices.html After trying a lot I am still not able to get it working. Can any one share the working source code of Command Pattern RPC. Regards, Thanks. Allahbaksh --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Reduction of JavaScript class declarations.
Of course, if we go with the idea of hoisting Java constructors into the JavaScript constructor, that stops working. Speaking of which, we don't have to limit it to just classes with one live constructor... two different JS constructors can share the same prototype object. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5663 - Roll back r5662. The overlay of WeakMapping is confusing the apicheck-nobuild target.
Author: r...@google.com
Date: Thu Jul 2 19:58:31 2009
New Revision: 5663
Removed:
trunk/user/src/com/google/gwt/core/client/WeakMapping.java
trunk/user/src/com/google/gwt/user/rebind/rpc/ClientDataSerializer.java
trunk/user/src/com/google/gwt/user/rebind/rpc/JdoDetachedStateClientDataSerializer.java
trunk/user/src/com/google/gwt/user/server/Base64Utils.java
trunk/user/src/com/google/gwt/user/server/rpc/impl/JdoDetachedStateServerDataSerializer.java
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerDataSerializer.java
trunk/user/super/com/google/gwt/user/translatable/com/google/gwt/core/
trunk/user/test/com/google/gwt/core/client/WeakMappingTest.java
trunk/user/test/com/google/gwt/user/server/Base64Test.java
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
trunk/user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamWriter.java
trunk/user/super/com/google/gwt/emul/java/lang/Object.java
trunk/user/test/com/google/gwt/core/CoreSuite.java
trunk/user/test/com/google/gwt/user/RPCSuite.java
Log:
Roll back r5662. The overlay of WeakMapping is confusing the
apicheck-nobuild target.
TBR: bobv
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
==
---
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
(original)
+++
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Thu Jul 2 19:58:31 2009
@@ -1949,7 +1949,6 @@
specialObfuscatedIdents.put(finalize, fZ);
// Object fields
-specialObfuscatedIdents.put(expando, eX);
specialObfuscatedIdents.put(typeId, tI);
specialObfuscatedIdents.put(typeMarker, tM);
Modified:
trunk/user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java
==
---
trunk/user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java
(original)
+++
trunk/user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java
Thu Jul 2 19:58:31 2009
@@ -16,7 +16,6 @@
package com.google.gwt.user.rebind.rpc;
import com.google.gwt.core.client.UnsafeNativeLong;
-import com.google.gwt.core.client.WeakMapping;
import com.google.gwt.core.ext.GeneratorContext;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.typeinfo.JArrayType;
@@ -47,8 +46,6 @@
* fully qualified type names everywhere
*/
public class FieldSerializerCreator {
-
- private final static String WEAK_MAPPING_CLASS_NAME =
WeakMapping.class.getName();
private final JClassType serializableClass;
@@ -351,13 +348,6 @@
writeEnumDeserializationStatements(serializableClass.isEnum());
} else {
writeClassDeserializationStatements();
-
- for (ClientDataSerializer serializer :
ClientDataSerializer.getSerializers()) {
-if (serializer.shouldSerialize(serializableClass)) {
- sourceWriter.println(WEAK_MAPPING_CLASS_NAME + .set(instance,
- + \ + serializer.getName() + \,
streamReader.readString()););
-}
- }
}
sourceWriter.outdent();
sourceWriter.println(});
@@ -465,14 +455,6 @@
writeEnumSerializationStatements(serializableClass.isEnum());
} else {
writeClassSerializationStatements();
-
- for (ClientDataSerializer serializer :
ClientDataSerializer.getSerializers()) {
-if (serializer.shouldSerialize(serializableClass)) {
- sourceWriter.println(streamWriter.writeString((String)
- + WEAK_MAPPING_CLASS_NAME + .get(instance, \
- + serializer.getName() + \)););
-}
- }
}
sourceWriter.outdent();
Modified:
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
==
---
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
(original)
+++
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
Thu Jul 2 19:58:31 2009
@@ -250,13 +250,6 @@
}
private static boolean fieldQualifiesForSerialization(Field field) {
-// Check if the field will be handled by a ServerDataSerializer; if
so, skip it here.
-for (ServerDataSerializer serializer :
ServerDataSerializer.getSerializers()) {
- if (serializer.shouldSkipField(field)) {
-return false;
- }
-}
-
if (Throwable.class == field.getDeclaringClass()) {
/**
* Only serialize Throwable's
