[gwt-contrib] Comment on EngMeeting_2007_01_29 in google-web-toolkit
Comment by gnuyoga: good template for engineering meeting - sree at openbravo dot com For more information: http://code.google.com/p/google-web-toolkit/wiki/EngMeeting_2007_01_29 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: I may have run into an issue with code inlining combined with generics...
Been there, done that. No worries :)
On Thu, Jun 4, 2009 at 7:09 PM, Mark Renouf mark.ren...@gmail.com wrote:
Oh... man. Cancel that!
Y'know it certainly felt like like of those oh darn, I've been
editing the wrong file all along moments, and it was... ugh.
Sorry for the noise, pilot error indeed.
On Jun 4, 6:36 pm, Mark Renouf mark.ren...@gmail.com wrote:
Wanted to check here before creating a ticket. Here's the basic
sitation:
I took liberties with the names, but the structure is basically
unchanged :-)
public class MagicContextT extends HasMagic? {
T magical;
}
class Magical {
MagicContext context = createContext();
void needMagic() {
if (context.magical != null) {
useTheMagic();
}
}
void useTheMagic() {
Style style = context.magical.getElement().getStyle();
set some styles...
}
}
Compile JS output (Pretty mode) for needMagic() looks like this:
style = dynamicCast(this.context.magical, 13).element.style;
Note the lack of a null check?
I've also tried with the null check within the useTheMagic method,
either way it doesn't matter because once it's inlined, it disapears.
Why would this be? Pilot error or compiler bug? I've tripled checked
I'm compiling the correct version, nothing is cached, etc etc.
My current theory is this is some bad interaction between bounded type-
args and inlining?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] slow startup of hosted mode
Hi, Some of the users of SmartGWT have reported slow startup in hosted mode. A user narrowed down the problem to the following call in StandardLinkerContext. outFile.lastModified() = artifact.getLastModified() When changed to outFile.lastModified() artifact.getLastModified(), the startup is normal. http://code.google.com/p/google-web-toolkit/issues/detail?id=3700 Can you guys comment on whether this is a valid change? One other thing that I noticed was that when I moved the resources (skin images) from the public path of my main module (SmartGwt), to a secondary module (SmartGwtXXXSkin), and the user is required to inherit both these modules, the hosted mode startup slowed down a fair bit compared to when he inherited only one module that also had the skins resources. Does this ring a bell? If not, I'll try to dig a little deeper into this and provide more information. Thanks, Sanjiv --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
Did you try it with -server? The server compiler has different thresholds for inlining as well as differing heuristics (it can speculatively inline with a guard). I'm wondering if what you're seeing is really the result of GC. Perhaps by fiddling with GC parameters (pick a really big young generation), you can see if the Iterator allocations are at fault. There is definately a difference between calling Iterator.next() and list.get() With Iterator, you've got double polymorphic dispatch, first to List.iterator(), and then in the returned iterator implementation, a call to AbstractList.get(). Whereas, with List.get() you've got a single polymorphic dispatch, and a better chance that Hotspot might figure out the concrete type and inline it to foo[index]. The downside of course, is you lose for-each as well as slightly higher chance of range overflows. Is it possible to isolate further where this 3% boost comes from, so that rather than chance every instance of Iterator to integer loops, you only need to change the few giving the biggest problems. It's a real shame that the Java collections in this day and age still impose such performance overhead. -Ray On Fri, Jun 5, 2009 at 8:16 PM, Daniel Rice (דניאל רייס)r...@google.com wrote: It would not be easy to force all of these lists to have some particular concrete implementation (FinalArrayList) although some could. I can repeat the analysis with a larger number of runs just to be sure, but the speedup was seen in the context of the actual compiler rather than a microbenchmark, so I believe there is some reality to it. Dan On Thu, Jun 4, 2009 at 11:58 PM, Ray Cromwellcromwell...@gmail.com wrote: This test is invalid due to the way Class Hierarchy Analysis works in Hotspot (similar to type-tightening in GWT). Since you never touch any other List implementations, Hotspot will know that List == ArrayList and all method calls are monomorphic. Try adding a LinkedList to your test and see what happens. In JDK5 this would foul up the optimizations. In a complex case like the compiler, it's bound to pick up other implementations of list, even if it's just Collections.unmodifiableList(). Microbenchmarking Hotspot is never really effective and fraught with problems. You also might want to try the -server JVM flag which sometimes makes a huge difference. -Ray On Fri, Jun 5, 2009 at 6:35 AM, Amit Manjhi amitman...@google.com wrote: I completely agree with Scott here. It's hard to believe that there will be a consistent 3% improvement just by using an explicit index. The change is very much compiler/JVM dependent. And even if there were the case currently, the next compiler/JVM could very easily fix this. Since I was surprised by the result, I wrote up a simple micro-benchmark that repeats this test with Integer lists of varying sizes. I ran it with openjdk and did not see *any* performance difference. I have attached the quick-and-dirty code and included the sample results at the end. Amit = Here are sample results: java -cp . -Xmx1500M com.test.Test iteration with 1000 elements long way: 1, short way: 1 long way: 1, short way: 1 long way: 2, short way: 3 long way: 1, short way: 3 long way: 2, short way: 5 long way: 9, short way: 7 long way: 1, short way: 2 long way: 10, short way: 2 long way: 0, short way: 2 long way: 0, short way: 1 iteration with 100 elements long way: 11, short way: 12 long way: 14, short way: 11 long way: 20, short way: 20 long way: 20, short way: 22 long way: 27, short way: 27 long way: 28, short way: 30 long way: 38, short way: 42 long way: 37, short way: 42 long way: 45, short way: 45 long way: 46, short way: 49 iteration with 1000 elements long way: 124, short way: 124 long way: 125, short way: 125 long way: 280, short way: 262 long way: 282, short way: 262 long way: 349, short way: 345 long way: 348, short way: 344 long way: 529, short way: 499 long way: 566, short way: 663 long way: 530, short way: 508 long way: 530, short way: 508 On Thu, Jun 4, 2009 at 1:58 PM, Aaron Steele eightyste...@gmail.com wrote: Do'h! Yeah, using the name 'ints' probably wasn't a good choice here. Looks like I should re-read Item 56: Adhere to generally accepted naming conventions. :) On Thu, Jun 4, 2009 at 1:09 PM, Alex Rudnick a...@google.com wrote: Yeesh, pardon. That's an ArrayList called ints of Integers, not containing ints. I retract that statement! On Thu, Jun 4, 2009 at 4:04 PM, Alex Rudnick a...@google.com wrote: Sounds like boxing/unboxing overhead, in that case! What if you tried that with an array of native ints? On Thu, Jun 4, 2009 at 3:47 PM, Aaron Steele eightyste...@gmail.com wrote: So item 46 in Effective Java says that there shouldn't be a performance penalty using the nice for loops. But the following test in Eclipse on my machine (MacBook Pro, Intel Core Duo, 2.16
[gwt-contrib] Re: slow startup of hosted mode
Agreed, this comparison looks wrong, though it's not immediately obvious to me how this affects hosted-mode startup (linking the compiled output, I could see being affected). @bob, scott: Any thoughts on this? On Fri, Jun 5, 2009 at 8:14 AM, Sanjiv Jivan sanjiv.ji...@gmail.com wrote: Hi, Some of the users of SmartGWT have reported slow startup in hosted mode. A user narrowed down the problem to the following call in StandardLinkerContext. outFile.lastModified() = artifact.getLastModified() When changed to outFile.lastModified() artifact.getLastModified(), the startup is normal. http://code.google.com/p/google-web-toolkit/issues/detail?id=3700 Can you guys comment on whether this is a valid change? One other thing that I noticed was that when I moved the resources (skin images) from the public path of my main module (SmartGwt), to a secondary module (SmartGwtXXXSkin), and the user is required to inherit both these modules, the hosted mode startup slowed down a fair bit compared to when he inherited only one module that also had the skins resources. Does this ring a bell? If not, I'll try to dig a little deeper into this and provide more information. Thanks, Sanjiv --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Suggestion for OOPHM
So, you may be planning this but I haven't seen it mentioned yet... If you can ship all the browser plugins within the single distro, but also host them through the server in the java side when running GWT apps, Then, when a browser requests a page which requires OOPHM and they don't have it, you could use useragent detection to auto select and trigger the appropriate installation method straight from the hosted mode server (activeX/add-on for IE, .xpi link for Firefox, etc). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
On Fri, Jun 5, 2009 at 10:15 AM, TazmanianD damon.lun...@gmail.com wrote: There is an additional benefit to this optimization that goes beyond speeding up the compiler. It should produce faster Javascript as well. Unless I'm mistaken, using an iterator to iterate over a list requires the creation of a Javascript object to represent the iterator. That object creation can be avoided by iterating over the list by index instead. On Blueprint, we have been avoiding using the nice for...each construct for this very reason. Unfortunately, I don't have any data that suggests just how much of a difference the index instead of iterator makes. Seems like our compiler should be able to do a better job because it has full knowledge of the possible types at the point it is generating code. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
In this case, the code is the GWT compiler itself, so it doesn't get translated ot JavaScript. Dan On Fri, Jun 5, 2009 at 10:15 AM, TazmanianDdamon.lun...@gmail.com wrote: There is an additional benefit to this optimization that goes beyond speeding up the compiler. It should produce faster Javascript as well. Unless I'm mistaken, using an iterator to iterate over a list requires the creation of a Javascript object to represent the iterator. That object creation can be avoided by iterating over the list by index instead. On Blueprint, we have been avoiding using the nice for...each construct for this very reason. Unfortunately, I don't have any data that suggests just how much of a difference the index instead of iterator makes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
I retried with -server, and the difference dropped to about half a percent, which I would say is below even my optimization threshold :-). So I'm inclined to let this go. Dan On Fri, Jun 5, 2009 at 8:38 AM, Ray Cromwellcromwell...@gmail.com wrote: Did you try it with -server? The server compiler has different thresholds for inlining as well as differing heuristics (it can speculatively inline with a guard). I'm wondering if what you're seeing is really the result of GC. Perhaps by fiddling with GC parameters (pick a really big young generation), you can see if the Iterator allocations are at fault. There is definately a difference between calling Iterator.next() and list.get() With Iterator, you've got double polymorphic dispatch, first to List.iterator(), and then in the returned iterator implementation, a call to AbstractList.get(). Whereas, with List.get() you've got a single polymorphic dispatch, and a better chance that Hotspot might figure out the concrete type and inline it to foo[index]. The downside of course, is you lose for-each as well as slightly higher chance of range overflows. Is it possible to isolate further where this 3% boost comes from, so that rather than chance every instance of Iterator to integer loops, you only need to change the few giving the biggest problems. It's a real shame that the Java collections in this day and age still impose such performance overhead. -Ray On Fri, Jun 5, 2009 at 8:16 PM, Daniel Rice (דניאל רייס)r...@google.com wrote: It would not be easy to force all of these lists to have some particular concrete implementation (FinalArrayList) although some could. I can repeat the analysis with a larger number of runs just to be sure, but the speedup was seen in the context of the actual compiler rather than a microbenchmark, so I believe there is some reality to it. Dan On Thu, Jun 4, 2009 at 11:58 PM, Ray Cromwellcromwell...@gmail.com wrote: This test is invalid due to the way Class Hierarchy Analysis works in Hotspot (similar to type-tightening in GWT). Since you never touch any other List implementations, Hotspot will know that List == ArrayList and all method calls are monomorphic. Try adding a LinkedList to your test and see what happens. In JDK5 this would foul up the optimizations. In a complex case like the compiler, it's bound to pick up other implementations of list, even if it's just Collections.unmodifiableList(). Microbenchmarking Hotspot is never really effective and fraught with problems. You also might want to try the -server JVM flag which sometimes makes a huge difference. -Ray On Fri, Jun 5, 2009 at 6:35 AM, Amit Manjhi amitman...@google.com wrote: I completely agree with Scott here. It's hard to believe that there will be a consistent 3% improvement just by using an explicit index. The change is very much compiler/JVM dependent. And even if there were the case currently, the next compiler/JVM could very easily fix this. Since I was surprised by the result, I wrote up a simple micro-benchmark that repeats this test with Integer lists of varying sizes. I ran it with openjdk and did not see *any* performance difference. I have attached the quick-and-dirty code and included the sample results at the end. Amit = Here are sample results: java -cp . -Xmx1500M com.test.Test iteration with 1000 elements long way: 1, short way: 1 long way: 1, short way: 1 long way: 2, short way: 3 long way: 1, short way: 3 long way: 2, short way: 5 long way: 9, short way: 7 long way: 1, short way: 2 long way: 10, short way: 2 long way: 0, short way: 2 long way: 0, short way: 1 iteration with 100 elements long way: 11, short way: 12 long way: 14, short way: 11 long way: 20, short way: 20 long way: 20, short way: 22 long way: 27, short way: 27 long way: 28, short way: 30 long way: 38, short way: 42 long way: 37, short way: 42 long way: 45, short way: 45 long way: 46, short way: 49 iteration with 1000 elements long way: 124, short way: 124 long way: 125, short way: 125 long way: 280, short way: 262 long way: 282, short way: 262 long way: 349, short way: 345 long way: 348, short way: 344 long way: 529, short way: 499 long way: 566, short way: 663 long way: 530, short way: 508 long way: 530, short way: 508 On Thu, Jun 4, 2009 at 1:58 PM, Aaron Steele eightyste...@gmail.com wrote: Do'h! Yeah, using the name 'ints' probably wasn't a good choice here. Looks like I should re-read Item 56: Adhere to generally accepted naming conventions. :) On Thu, Jun 4, 2009 at 1:09 PM, Alex Rudnick a...@google.com wrote: Yeesh, pardon. That's an ArrayList called ints of Integers, not containing ints. I retract that statement! On Thu, Jun 4, 2009 at 4:04 PM, Alex Rudnick a...@google.com wrote: Sounds like boxing/unboxing overhead, in that case! What if you tried that with an array of native ints?
[gwt-contrib] [google-web-toolkit commit] r5512 - Merge trunk r5510 into the 6/2 snapshot branch.
Author: j...@google.com
Date: Fri Jun 5 07:10:36 2009
New Revision: 5512
Modified:
branches/snapshot-2009.06.02-r5498/branch-info.txt
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java
Log:
Merge trunk r5510 into the 6/2 snapshot branch.
Fix incorrect AST generation when setting up calls to class literal factory
methods.
Patch by: bobv
Review by: scottb
svn merge --ignore-ancestry -c5510 \
https://google-web-toolkit.googlecode.com/svn/trunk .
Modified: branches/snapshot-2009.06.02-r5498/branch-info.txt
==
--- branches/snapshot-2009.06.02-r5498/branch-info.txt (original)
+++ branches/snapshot-2009.06.02-r5498/branch-info.txt Fri Jun 5 07:10:36
2009
@@ -14,3 +14,5 @@
/trunk r5505-r5506 was merged into this branch
(CurrencyListGenerator nb locales)
svn merge --ignore-ancestry -r5504:5506
https://google-web-toolkit.googlecode.com/svn/trunk .
+/trunk r5510 was merged into this branch (Fix ICE)
+ svn merge --ignore-ancestry -c5510
https://google-web-toolkit.googlecode.com/svn/trunk .
Modified:
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java
==
---
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java
(original)
+++
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java
Fri Jun 5 07:10:36 2009
@@ -61,8 +61,8 @@
JDeclaredType arrayType = program.getIndexedType(Array);
call.addArg(new JNameOf(info, program, arrayType));
-} else if (type instanceof JDeclaredType) {
- // Add the name of the seed function for non-array reference types
+} else if (type instanceof JClassType) {
+ // Add the name of the seed function for concrete types
call.addArg(new JNameOf(info, program, type));
} else if (type instanceof JPrimitiveType) {
@@ -118,6 +118,8 @@
} else {
assert (type instanceof JInterfaceType || type instanceof
JPrimitiveType);
}
+assert call.getArgs().size() == method.getParams().size() : Argument
/ param mismatch
++ call.toString() + versus + method.toString();
return call;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5513 - - Deprecates the constants in About.java that contain version information
Author: zun...@google.com
Date: Fri Jun 5 07:19:33 2009
New Revision: 5513
Added:
trunk/dev/core/test/com/google/gwt/dev/AboutTest.java (contents, props
changed)
Modified:
trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
trunk/dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
trunk/dev/core/src/com/google/gwt/core/linker/XSLinker.java
trunk/dev/core/src/com/google/gwt/dev/About.java
trunk/dev/core/src/com/google/gwt/dev/GWTMain.java
trunk/dev/core/src/com/google/gwt/dev/SignatureDumper.java
trunk/dev/core/src/com/google/gwt/dev/shell/CheckForUpdates.java
trunk/dev/core/src/com/google/gwt/dev/shell/GWTBridgeImpl.java
trunk/dev/core/src/com/google/gwt/util/tools/ToolBase.java
trunk/user/src/com/google/gwt/junit/GWTDummyBridge.java
trunk/user/src/com/google/gwt/user/tools/WebAppCreator.java
Log:
- Deprecates the constants in About.java that contain version information
in favor of getters in the same class.
- Migrates all internal references to these contants the new getters.
- Migrates version string parsing logic in CheckForUpdates to About. A
new method to return the version as a 3 element array is available.
Review by: scottb,jat
Modified: trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
==
--- trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java Fri
Jun 5 07:19:33 2009
@@ -255,7 +255,7 @@
// Setup the well-known variables.
out.print(headscript);
out.newlineOpt();
-out.print(var $gwt_version = \ + About.GWT_VERSION_NUM + \;);
+out.print(var $gwt_version = \ + About.getGwtVersionNum() + \;);
out.newlineOpt();
out.print(var $wnd = parent;);
out.newlineOpt();
Modified:
trunk/dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
==
--- trunk/dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java
Fri Jun 5 07:19:33 2009
@@ -81,7 +81,7 @@
// Emit the module's JS a closure.
out.print((function () {);
out.newlineOpt();
-out.print(var $gwt_version = \ + About.GWT_VERSION_NUM + \;);
+out.print(var $gwt_version = \ + About.getGwtVersionNum() + \;);
out.newlineOpt();
out.print(var $wnd = window;);
out.newlineOpt();
Modified: trunk/dev/core/src/com/google/gwt/core/linker/XSLinker.java
==
--- trunk/dev/core/src/com/google/gwt/core/linker/XSLinker.java (original)
+++ trunk/dev/core/src/com/google/gwt/core/linker/XSLinker.java Fri Jun 5
07:19:33 2009
@@ -67,7 +67,7 @@
// Setup the well-known variables.
//
-out.print(var $gwt_version = \ + About.GWT_VERSION_NUM + \;);
+out.print(var $gwt_version = \ + About.getGwtVersionNum() + \;);
out.newlineOpt();
out.print(var $wnd = window;);
out.newlineOpt();
Modified: trunk/dev/core/src/com/google/gwt/dev/About.java
==
--- trunk/dev/core/src/com/google/gwt/dev/About.java(original)
+++ trunk/dev/core/src/com/google/gwt/dev/About.javaFri Jun 5 07:19:33
2009
@@ -15,8 +15,8 @@
*/
package com.google.gwt.dev;
-import java.io.InputStream;
import java.io.IOException;
+import java.io.InputStream;
import java.util.Properties;
/**
@@ -24,13 +24,38 @@
*/
public class About {
+ // TODO(zundel): These public constants should be removed some day.
+ // Java inlines static final constants in compiled classes, leading to
+ // version incompatibility warnings.
+ /**
+ * @deprecated use {...@link #getGwtName()} instead.
+ */
+ @Deprecated
+ public static String GWT_NAME;
+
+ /**
+ * @deprecated use {...@link #getGwtSvnRev()} instead.
+ */
+ @Deprecated
public static String GWT_SVNREV;
- public static String GWT_VERSION_NUM;
+ /**
+ * @deprecated use {...@link #getGwtVersion()} instead.
+ */
+ @Deprecated
+ public static String GWT_VERSION;
- public static String GWT_NAME = Google Web Toolkit;
+ /**
+ * @deprecated use {...@link #getGwtVersionArray()} or
+ * {...@link #getGwtVersionNum()} instead.
+ */
+ @Deprecated
+ public static String GWT_VERSION_NUM;
- public static String GWT_VERSION;
+ private static final String gwtName = Google Web Toolkit;
+ private static final String gwtSvnRev;
+ private static int[] gwtVersionArray = null;
+ private static final String gwtVersionNum;
static {
Properties props = new Properties();
@@ -41,18 +66,129 @@
// okay... we use default values, then.
}
-GWT_SVNREV = props.getProperty(gwt.svnrev);
+
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
On Fri, Jun 5, 2009 at 10:23 AM, Daniel Rice (דניאל רייס) r...@google.comwrote: In this case, the code is the GWT compiler itself, so it doesn't get translated ot JavaScript. Right, he was talking about the related problem in user code, and it seems like there we can do better than HotSpot. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5514 - Created wiki page through web user interface.
Author: b...@google.com
Date: Fri Jun 5 07:43:03 2009
New Revision: 5514
Added:
wiki/ImageResource.wiki
Log:
Created wiki page through web user interface.
Added: wiki/ImageResource.wiki
==
--- (empty file)
+++ wiki/ImageResource.wiki Fri Jun 5 07:43:03 2009
@@ -0,0 +1,36 @@
+#summary Compile-time image processing
+
+wiki:toc /
+
+= Goal =
+ * Provide access to image data at runtime in the most efficient way
possible
+
+= Non-goals =
+ * To provide a general-purpose image manipulation framework.
+
+= Overview =
+
+ 1 Define a ClientBundle with one or more ImageResource accessors:
+ {{{
+interface Resources extends ClientBundle {
+ @Source(logo.png)
+ ImageResource logo();
+
+ @Source(arrow.png)
+ @ImageOptions(flipRtl = true)
+ ImageResource pointer();
+}
+}}}
+ 1 Instantiate the ClientBundle via a call to `GWT.create()`.
+ 1 Instantiate one or more Image widget or use with the
[CssResource#Image_Sprites CssResource @sprite] directive.
+
+== `ImageOptions` ==
+The `...@imageoptions` annotation can be applied to the ImageResource
accessor method in order to tune the compile-time processing of the image
data
+ * `flipRtl` is a boolean value that will cause the image to be mirrored
about its Y-axis when `LocaleInfo.isRTL()` returns `true`.
+ * `repeatStyle` is an enumerated value that is used in combination with
t...@sprite` directive to indicate that the image is intended to be tiled.
+
+== Supported formats ==
+`ImageBundleBuilder` uses the Java
[http://java.sun.com/javase/6/docs/api/javax/imageio/package-summary.html
ImageIO] framework to read image data. This includes support for all common
web image formats.
+
+== Future development ==
+ * Add compile-time scaling to images. This would allow a single
high-resolution image to be scaled at compile time to the desired size.
\ No newline at end of file
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Suggestion for OOPHM
An even-crazier setup would be that the locally-installed plugin is just a sled for downloading the actual plugin guts from the server. This way, a single plugin installation could work with different versions of the OOPHM host code. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Suggestion for OOPHM
While this subject is up... Has anyone considered writing the OOPHM client stub as a Java applet and using netscape.javascript.JSObject to deal with the JS references? While it wouldn't support direct field references like the current plugins do, the server-side Jsni class could rewrite those as method invocations (pass either a get, set or unary operator up to the server). Java itself could take care of listening for JSObject destruction: create a weak reference to the JSObject and put that in a reference queue. The plugin already deals with the Browser GC-JVM GC links, so this should just work (hah!). AFAIK, there a is limited amount of magic happening in OOPHM right now, basically boiling down to - field getter/setters - JSObject destruction - Invocation The only possible issue I can think of would be hitting that Window.enableScrolling() bug that killed the previous NPAPI plugin. On 5-Jun-09, at 9:37 AM, BobV wrote: An even-crazier setup would be that the locally-installed plugin is just a sled for downloading the actual plugin guts from the server. This way, a single plugin installation could work with different versions of the OOPHM host code. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] HashMap Optimization: return null for put and remove
I have an idea of an optimization of usages of HashMap. I have recently switched from using the FastStringMap to using a normal HashMap since the performance difference isn't as significant as it once was. However, there is one point where I was able to still make the FastStringMap faster. I overrode the put and remove methods and had them return null instead of performing a get to fetch the current value for the keys. In the vast majority of cases, the client never uses the values returned from put or remove which just wastes the gets to look them up. I tried a test that does 100,000 puts and gets and I have found that my version which returns null in the put is almost twice as fast as the version which does not. If the compiler can devirtualize a variable to a java.util.HashMap and it sees that the return value is not used, could the compilter substitute a different method call to a different version of put and remove that just return null (or perhaps nothing)? If you want to see the details of my tests, you can read the blog post I recently put up regarding our usage of FastStringMap: http://development.lombardi.com/?p=797 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5515 - The updated version parsing code in About.java insists on a 3 digit
Author: zun...@google.com Date: Fri Jun 5 09:02:20 2009 New Revision: 5515 Modified: trunk/dev/core/test/com/google/gwt/dev/shell/CheckForUpdatesTest.java Log: The updated version parsing code in About.java insists on a 3 digit version number. Removed the first tests with only 1 digit version strings. Review by: jat(TBR) Modified: trunk/dev/core/test/com/google/gwt/dev/shell/CheckForUpdatesTest.java == --- trunk/dev/core/test/com/google/gwt/dev/shell/CheckForUpdatesTest.java (original) +++ trunk/dev/core/test/com/google/gwt/dev/shell/CheckForUpdatesTest.java Fri Jun 5 09:02:20 2009 @@ -12,14 +12,8 @@ GwtVersion v1 = new GwtVersion(null); assertEquals(0, v1.compareTo(v1)); -v1 = new GwtVersion(1); -assertEquals(0, v1.compareTo(v1)); -GwtVersion v2 = new GwtVersion(2); -assertTrue(v1.compareTo(v2) 0); -assertTrue(v2.compareTo(v1) 0); - v1 = new GwtVersion(1.2.3); -v2 = new GwtVersion(null); +GwtVersion v2 = new GwtVersion(null); assertTrue(v1.compareTo(v2) 0); assertTrue(v2.compareTo(v1) 0); --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Suggestion for OOPHM
2009/6/5 Matt Mastracci matt...@mastracci.com: While this subject is up... Has anyone considered writing the OOPHM client stub as a Java applet and using netscape.javascript.JSObject to deal with the JS references? Please no java applets. They only recently started working on 64bit linux and I woudn't call them stable. -- Best Regards, Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: slow startup of hosted mode
Since we later use outFile.setLastModified(artifact.getLastModified()), thus ensuring equality, yeah, that = is wrong On Fri, Jun 5, 2009 at 9:45 AM, Joel Webber j...@google.com wrote: Agreed, this comparison looks wrong, though it's not immediately obvious to me how this affects hosted-mode startup (linking the compiled output, I could see being affected). @bob, scott: Any thoughts on this? On Fri, Jun 5, 2009 at 8:14 AM, Sanjiv Jivan sanjiv.ji...@gmail.comwrote: Hi, Some of the users of SmartGWT have reported slow startup in hosted mode. A user narrowed down the problem to the following call in StandardLinkerContext. outFile.lastModified() = artifact.getLastModified() When changed to outFile.lastModified() artifact.getLastModified(), the startup is normal. http://code.google.com/p/google-web-toolkit/issues/detail?id=3700 Can you guys comment on whether this is a valid change? One other thing that I noticed was that when I moved the resources (skin images) from the public path of my main module (SmartGwt), to a secondary module (SmartGwtXXXSkin), and the user is required to inherit both these modules, the hosted mode startup slowed down a fair bit compared to when he inherited only one module that also had the skins resources. Does this ring a bell? If not, I'll try to dig a little deeper into this and provide more information. Thanks, Sanjiv --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
Apropos, http://timepedia.blogspot.com/2008/06/design-patterns-vs-gwt-compiler.html The compiler can do a pretty good job already, and perhaps with some form of escape analysis it can elide the object generation. In the example given, the lifetime of the iterator is the scope of the loop, and as long as it doesn't escape the loop (in most cases it doesn't), we can 'inline' the iterator fields as temporaries in the loop. -Ray On Fri, Jun 5, 2009 at 10:22 PM, John Tamplinj...@google.com wrote: On Fri, Jun 5, 2009 at 10:15 AM, TazmanianD damon.lun...@gmail.com wrote: There is an additional benefit to this optimization that goes beyond speeding up the compiler. It should produce faster Javascript as well. Unless I'm mistaken, using an iterator to iterate over a list requires the creation of a Javascript object to represent the iterator. That object creation can be avoided by iterating over the list by index instead. On Blueprint, we have been avoiding using the nice for...each construct for this very reason. Unfortunately, I don't have any data that suggests just how much of a difference the index instead of iterator makes. Seems like our compiler should be able to do a better job because it has full knowledge of the possible types at the point it is generating code. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Suggestion for OOPHM
On 5-Jun-09, at 10:08 AM, Piotr Jaroszyński wrote: 2009/6/5 Matt Mastracci matt...@mastracci.com: While this subject is up... Has anyone considered writing the OOPHM client stub as a Java applet and using netscape.javascript.JSObject to deal with the JS references? Please no java applets. They only recently started working on 64bit linux and I woudn't call them stable. Fair enough.. :) I haven't had much experience with applets on OSX, so I'm not sure what the state is on this platform either. I've also been playing with a 100% Javascript version of the OOPHM client stub as well, but it's been put on hold now that I've fixed the bug in the binary component that was stopping me from instantiating it from chrome:// documents. It basically uses GWT and some XPCOM bindings that I've generated for our product previously to implement the client side of things. It might be a good alternative to having a binary component for FF, which is by far the browser that requires the most cross-platform compilation. It's no more than a proof-of-concept right now, but if there's interest from others I can share the code and/or work on completing it. Since it's written using GWT, it's just a matter of porting the current server-side BrowserChannel over. Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Add cross site requests support
Hello, I'm not sure where is the best place to discuss this. I have created an Issue [1] yesteday, but I suppose not too many people will find it there so I am posting on the list too. I will quote the issue here for reference: in my current gwt project I need to make cross-site requests and as we all know too well, with SOP it's not as easy as it should be, but there are various hacks available. I came up with a new one, which is expanding the window.name hack (a bit more details on http://blog.piotrj.org/2009/04/wndowname-hack-taken-step-further-full.html ): * Create an iframe * Encode XHR params and a dummy localUrl in the iframe's window.name * Change the iframe's location to the server's proxy script * The proxy script reads params from window.name and creates the real XHR * Fire the XHR and encode the response (all of it) in window.name * Change the location back to localUrl * Read the response from the iframe's window.name It's more or less the url#communication hack, but with a better communication scheme. On the server-side all it needs is setting the caching headers for the proxy script. I have a working patch implementing this in GWT, but before I go into details I would like to hear whether it's something that would be suitable for GWT in general. One thing that I think would be nice to do is to look at the HTML 5 cross site xhr implementations and use them where available and only fallback to this solution on older browsers. --- Security-wise I think it can match the w3 spec - at least for GETs and POSTs (other methods are not supported in GWT anyway because of the safari bug). The server would be required to send the access control headers then, but that's a good idea anyway as it will be required for the new cross site xhr anyway. [1] - http://code.google.com/p/google-web-toolkit/issues/detail?id=3722 [2] - http://www.w3.org/TR/access-control/ -- Best Regards, Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: slow startup of hosted mode
Sounds like an easy patch waiting to be made? Takers? On Fri, Jun 5, 2009 at 12:21 PM, Freeland Abbott fabb...@google.com wrote: Since we later use outFile.setLastModified(artifact.getLastModified()), thus ensuring equality, yeah, that = is wrong On Fri, Jun 5, 2009 at 9:45 AM, Joel Webber j...@google.com wrote: Agreed, this comparison looks wrong, though it's not immediately obvious to me how this affects hosted-mode startup (linking the compiled output, I could see being affected). @bob, scott: Any thoughts on this? On Fri, Jun 5, 2009 at 8:14 AM, Sanjiv Jivan sanjiv.ji...@gmail.comwrote: Hi, Some of the users of SmartGWT have reported slow startup in hosted mode. A user narrowed down the problem to the following call in StandardLinkerContext. outFile.lastModified() = artifact.getLastModified() When changed to outFile.lastModified() artifact.getLastModified(), the startup is normal. http://code.google.com/p/google-web-toolkit/issues/detail?id=3700 Can you guys comment on whether this is a valid change? One other thing that I noticed was that when I moved the resources (skin images) from the public path of my main module (SmartGwt), to a secondary module (SmartGwtXXXSkin), and the user is required to inherit both these modules, the hosted mode startup slowed down a fair bit compared to when he inherited only one module that also had the skins resources. Does this ring a bell? If not, I'll try to dig a little deeper into this and provide more information. Thanks, Sanjiv --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A big GWT splash made by Wave
Hi Gary, We're happy to share both of those. In fact, neither one of those is really considered proprietary; it's more just that they aren't really generalized properly for widespread use. We'll put them in trunk as soon as time allows (which is likely on the order of weeks at a minimum). On Thu, Jun 4, 2009 at 11:34 PM, Gary Miller miller.ga...@gmail.com wrote: Hey All Now that the outside world has been give a peek at how Google is using GWT ... http://code.google.com/events/io/sessions/GoogleWavePoweredByGWT.html I was wondering if / when some of the propriety stuff might be made available to the outside world e.g. - Declarative UI / UiBinder - Server-side script selection - My applause to the GWT team from their involvement in Wave. Regards Gary --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
This would definitely be a good thing to look into, but I expect it's slightly tricky. Maybe the library code itself could be hacked on until a suitable formulation was found. On Fri, Jun 5, 2009 at 11:52 AM, Damon Lundin damon.lun...@gmail.comwrote: I have an idea of an optimization of usages of HashMap. I have recently switched from using the FastStringMap to using a normal HashMap since the performance difference isn't as significant as it once was. However, there is one point where I was able to still make the FastStringMap faster. I overrode the put and remove methods and had them return null instead of performing a get to fetch the current value for the keys. In the vast majority of cases, the client never uses the values returned from put or remove which just wastes the gets to look them up. I tried a test that does 100,000 puts and gets and I have found that my version which returns null in the put is almost twice as fast as the version which does not. If the compiler can devirtualize a variable to a java.util.HashMap and it sees that the return value is not used, could the compilter substitute a different method call to a different version of put and remove that just return null (or perhaps nothing)? If you want to see the details of my tests, you can read the blog post I recently put up regarding our usage of FastStringMap: http://development.lombardi.com/?p=797 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: slow startup of hosted mode
I'll take. On Fri, Jun 5, 2009 at 12:55 PM, Bruce Johnson br...@google.com wrote: Sounds like an easy patch waiting to be made? Takers? On Fri, Jun 5, 2009 at 12:21 PM, Freeland Abbott fabb...@google.comwrote: Since we later use outFile.setLastModified(artifact.getLastModified()), thus ensuring equality, yeah, that = is wrong On Fri, Jun 5, 2009 at 9:45 AM, Joel Webber j...@google.com wrote: Agreed, this comparison looks wrong, though it's not immediately obvious to me how this affects hosted-mode startup (linking the compiled output, I could see being affected). @bob, scott: Any thoughts on this? On Fri, Jun 5, 2009 at 8:14 AM, Sanjiv Jivan sanjiv.ji...@gmail.comwrote: Hi, Some of the users of SmartGWT have reported slow startup in hosted mode. A user narrowed down the problem to the following call in StandardLinkerContext. outFile.lastModified() = artifact.getLastModified() When changed to outFile.lastModified() artifact.getLastModified(), the startup is normal. http://code.google.com/p/google-web-toolkit/issues/detail?id=3700 Can you guys comment on whether this is a valid change? One other thing that I noticed was that when I moved the resources (skin images) from the public path of my main module (SmartGwt), to a secondary module (SmartGwtXXXSkin), and the user is required to inherit both these modules, the hosted mode startup slowed down a fair bit compared to when he inherited only one module that also had the skins resources. Does this ring a bell? If not, I'll try to dig a little deeper into this and provide more information. Thanks, Sanjiv --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Fixes OOPHM on IE using window.name instead of an expando; Fixes lightweight metrics.
lgtm. http://gwt-code-reviews.appspot.com/33840 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
On Fri, Jun 5, 2009 at 8:38 AM, Ray Cromwell cromwell...@gmail.com wrote: With Iterator, you've got double polymorphic dispatch, first to List.iterator(), and then in the returned iterator implementation, a call to AbstractList.get(). Whereas, with List.get() you've got a single polymorphic dispatch, and a better chance that Hotspot might figure out the concrete type and inline it to foo[index]. The second one is unfortunate, because it could be avoided by implementing the List hierarchy differently. Maybe GWT could do better if we had a final SimpleArrayList class of our own that didn't even subclass ArrayList. Its iterator method could be defined as returning a SimpleArrayList.Iterator rather than an abstract IteratorT. That should help the JVM devirtualize method calls without needing to change the looping code in GWT. Reading further in the thread, though, maybe we should simply use -server! Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
On Fri, Jun 5, 2009 at 10:24 AM, Daniel Rice (דניאל רייס) r...@google.comwrote: I retried with -server, and the difference dropped to about half a percent, which I would say is below even my optimization threshold :-). So I'm inclined to let this go. Dan, after looking over the patch once more, there is actually one place I think it's worth updating-- JsVisitor. That's going to be the hottest iteration in the whole compiler, so I think it's probably worth the trade off in this case. JsModVisitor, JVisitor, etc use looping variables instead of iterating already, so JsVisitor is really the odd man out. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum sco...@google.com wrote: This would definitely be a good thing to look into, but I expect it's slightly tricky. Maybe the library code itself could be hacked on until a suitable formulation was found. Since the JRE requires returning the values (a very bad idea IMHO) then I don't see how we can short circuit it in the library. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
On Fri, Jun 5, 2009 at 1:47 PM, Lex Spoon sp...@google.com wrote: Reading further in the thread, though, maybe we should simply use -server! Funny enough, I used to use -server in all my launch configs, but at some point I found it seemed actually a lot slower most of the time, due to all the overhead. I think you need a really big compile to make it worth it (30-perm Showcase might be worth it, the other samples probably not). Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
Sorry, lemme clarify. I mean that maybe, just maybe, there's a correct formulation of the library code such that some work can be optimized out when the return value is not used. On Fri, Jun 5, 2009 at 1:50 PM, John Tamplin j...@google.com wrote: On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum sco...@google.com wrote: This would definitely be a good thing to look into, but I expect it's slightly tricky. Maybe the library code itself could be hacked on until a suitable formulation was found. Since the JRE requires returning the values (a very bad idea IMHO) then I don't see how we can short circuit it in the library. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5516 - Fix annoying checkstyle violations.
Author: sco...@google.com
Date: Fri Jun 5 11:00:54 2009
New Revision: 5516
Modified:
releases/1.6/user/src/com/google/gwt/i18n/client/NumberFormat.java
releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplIE8.java
releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplTrident.java
releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java
releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
releases/1.6/user/test/com/google/gwt/user/client/ui/CheckBoxTest.java
Log:
Fix annoying checkstyle violations.
Review by: jgw (TBR)
Modified: releases/1.6/user/src/com/google/gwt/i18n/client/NumberFormat.java
==
--- releases/1.6/user/src/com/google/gwt/i18n/client/NumberFormat.java
(original)
+++ releases/1.6/user/src/com/google/gwt/i18n/client/NumberFormat.java Fri
Jun 5 11:00:54 2009
@@ -504,34 +504,6 @@
this(defaultNumberConstants, pattern, cdata, userSuppliedPattern);
}
- protected NumberConstants getNumberConstants() {
-return numberConstants;
- }
-
- protected String getPositivePrefix() {
-return positivePrefix;
- }
-
- protected String getPositiveSuffix() {
-return positiveSuffix;
- }
-
- protected String getNegativePrefix() {
-return negativePrefix;
- }
-
- protected String getNegativeSuffix() {
-return negativeSuffix;
- }
-
- protected int getGroupingSize() {
-return groupingSize;
- }
-
- protected boolean isDecimalSeparatorAlwaysShown() {
-return decimalSeparatorAlwaysShown;
- }
-
/**
* This method formats a double to produce a string.
*
@@ -682,6 +654,34 @@
}
return ret;
+ }
+
+ protected int getGroupingSize() {
+return groupingSize;
+ }
+
+ protected String getNegativePrefix() {
+return negativePrefix;
+ }
+
+ protected String getNegativeSuffix() {
+return negativeSuffix;
+ }
+
+ protected NumberConstants getNumberConstants() {
+return numberConstants;
+ }
+
+ protected String getPositivePrefix() {
+return positivePrefix;
+ }
+
+ protected String getPositiveSuffix() {
+return positiveSuffix;
+ }
+
+ protected boolean isDecimalSeparatorAlwaysShown() {
+return decimalSeparatorAlwaysShown;
}
/**
Modified:
releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplIE8.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplIE8.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplIE8.java
Fri Jun 5 11:00:54 2009
@@ -15,5 +15,9 @@
*/
package com.google.gwt.user.client.impl;
+/**
+ * Internet Explorer 8 implementation of
+ * {...@link com.google.gwt.user.client.impl.DOMImpl}.
+ */
public class DOMImplIE8 extends DOMImplTrident {
}
Modified:
releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplTrident.java
==
---
releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplTrident.java
(original)
+++
releases/1.6/user/src/com/google/gwt/user/client/impl/DOMImplTrident.java
Fri Jun 5 11:00:54 2009
@@ -19,6 +19,10 @@
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
+/**
+ * Base implementation of {...@link com.google.gwt.user.client.impl.DOMImpl}
shared
+ * by IE based browsers.
+ */
public abstract class DOMImplTrident extends DOMImpl {
@SuppressWarnings(unused)
Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/CheckBox.java Fri
Jun 5 11:00:54 2009
@@ -119,17 +119,6 @@
return addHandler(handler, ValueChangeEvent.getType());
}
- protected void ensureDomEventHandlers() {
-addClickHandler(new ClickHandler() {
- public void onClick(ClickEvent event) {
-// Checkboxes always toggle their value, no need to compare
-// with old value. Radio buttons are not so lucky, see
-// overrides in RadioButton
-ValueChangeEvent.fire(CheckBox.this, getValue());
- }
-});
- }
-
/**
* Returns the value property of the input element that backs this
widget.
* This is the value that will be associated with the CheckBox name and
@@ -326,6 +315,17 @@
} else {
super.sinkEvents(eventBitsToAdd);
}
+ }
+
+ protected void ensureDomEventHandlers() {
+addClickHandler(new ClickHandler() {
+ public void onClick(ClickEvent event) {
+// Checkboxes always toggle their value, no need to compare
+// with old value. Radio buttons are not so lucky, see
+// overrides in RadioButton
+
[gwt-contrib] Re: [google-web-toolkit commit] r5516 - Fix annoying checkstyle violations.
Joel: please TBR, and also please see the Checkstyle section in this documenthttp://google-web-toolkit.googlecode.com/svn/trunk/eclipse/README.txtto configure Eclipse to catch these for you. :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
Andres, this group is for discussing how to improve GWT. For questions about using GWT, please use google-web-tool...@googlegroups.com instead. Also it would probably be good to search that group for an appropriate, on topic thread related to JSON. On Fri, Jun 5, 2009 at 2:20 PM, ANDRES BRUN andres.b...@gmail.com wrote: Hello Everybody I'm trying to implement a code that permit me integrate PHP, GWT, MYSQL, I was testing and implementing different examples but I don't understand really good, which is the correct way to send data with JSON and principally. How I can receive that data in GWT? Please, I'm not newbie in Programation but I'm really newbie in GWT, and this version 1.6 is really difficult to learn. Somebody can help me with a good example for dummies... jajaja. Thank you -- Andrés Brun --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimize out 'literal' != null at JS time
Love what this patch does! I kind of want to separate simplifyEq and simplifyNeq into separate code paths. I think it would be a little clearer, and would pave the way for more equality/inequality optimizations (for example, two different value literals). http://gwt-code-reviews.appspot.com/34831 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimize out 'literal' != null at JS time
Yeah, I think that would probably be clearest. On Fri, Jun 5, 2009 at 3:16 PM, mmast...@gmail.com wrote: Sounds good... Should I split trySimplifyEq as well? On 2009/06/05 19:14:11, scottb wrote: Love what this patch does! I kind of want to separate simplifyEq and simplifyNeq into separate code paths. I think it would be a little clearer, and would pave the way for more equality/inequality optimizations (for example, two different value literals). http://gwt-code-reviews.appspot.com/34831 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimize out 'literal' != null at JS time
Mind seeing if it's in this list, and possibly checking it off? http://code.google.com/p/google-web-toolkit/wiki/CompilerOptimizations On Fri, Jun 5, 2009 at 3:18 PM, Scott Blum sco...@google.com wrote: Yeah, I think that would probably be clearest. On Fri, Jun 5, 2009 at 3:16 PM, mmast...@gmail.com wrote: Sounds good... Should I split trySimplifyEq as well? On 2009/06/05 19:14:11, scottb wrote: Love what this patch does! I kind of want to separate simplifyEq and simplifyNeq into separate code paths. I think it would be a little clearer, and would pave the way for more equality/inequality optimizations (for example, two different value literals). http://gwt-code-reviews.appspot.com/34831 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5518 - Merge trunk r5517 into the 6/2 snapshot branch.
Author: j...@google.com
Date: Fri Jun 5 12:23:25 2009
New Revision: 5518
Modified:
branches/snapshot-2009.06.02-r5498/branch-info.txt
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
Log:
Merge trunk r5517 into the 6/2 snapshot branch.
Fix for hosted mode with XHR-based iframe selection script.
Includes fix for issue 3717.
Review: http://gwt-code-reviews.appspot.com/33840
Patch by: jgw
svn merge -c5517 https://google-web-toolkit.googlecode.com/svn/trunk .
Modified: branches/snapshot-2009.06.02-r5498/branch-info.txt
==
--- branches/snapshot-2009.06.02-r5498/branch-info.txt (original)
+++ branches/snapshot-2009.06.02-r5498/branch-info.txt Fri Jun 5 12:23:25
2009
@@ -16,3 +16,5 @@
svn merge --ignore-ancestry -r5504:5506
https://google-web-toolkit.googlecode.com/svn/trunk .
/trunk r5510 was merged into this branch (Fix ICE)
svn merge --ignore-ancestry -c5510
https://google-web-toolkit.googlecode.com/svn/trunk .
+/trunk r5517 was merged into this branch (Fix IE hosted mode)
+ svn merge -c5517 https://google-web-toolkit.googlecode.com/svn/trunk .
Modified:
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
==
---
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
(original)
+++
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
Fri Jun 5 12:23:25 2009
@@ -4,11 +4,21 @@
var $doc = $wnd.document;
var $moduleName, $moduleBase
,$stats = $wnd.__gwtStatsEvent ? function(a) {return
$wnd.__gwtStatsEvent(a);} : null;
+
+// The module to be loaded can be specified either through the url query
+// parameter (as done by the legacy HostedModeTemplate.js), or by
specifying
+// window.name (as done by IFrameTemplate.js). When the former approach
+// is removed, we can drop the window.location.search part of this logic.
+var moduleFuncName = window.location.search.substring(1);
+if (!moduleFuncName || !$wnd[moduleFuncName]) {
+ moduleFuncName = window.name;
+}
+
+var moduleFunc = $wnd[moduleFuncName];
+var moduleName = moduleFunc ? moduleFunc.moduleName : unknown;
+
// Lightweight metrics
if ($stats) {
- var moduleFuncName = location.search.substr(1);
- var moduleFunc = $wnd[moduleFuncName];
- var moduleName = moduleFunc ? moduleFunc.moduleName : unknown;
$stats({moduleName:moduleName,subSystem:'startup',evtGroup:'moduleStartup',millis:(new
Date()).getTime(),type:'moduleEvalStart'});
}
@@ -241,13 +251,5 @@
}
}
-// The module to be loaded can be specified either through the url query
-// parameter (as done by the legacy HostedModeTemplate.js), or by
specifying
-// window.__gwt_module (as done by IFrameTemplate.js). When the former
approach
-// is removed, we can drop the 'query' part of this logic.
-query = window.location.search.substring(1);
-if (query $wnd[query]) setTimeout($wnd[query].onScriptLoad, 1);
-
-var module = window.__gwt_module;
-if (module $wnd[module]) setTimeout($wnd[module].onScriptLoad, 1);
+setTimeout($wnd[moduleFuncName].onScriptLoad, 1);
--/script/body/html
Modified:
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
==
---
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
(original)
+++
branches/snapshot-2009.06.02-r5498/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
Fri Jun 5 12:23:25 2009
@@ -309,6 +309,9 @@
type: 'moduleRequested'
});
+// to avoid http://support.microsoft.com/kb/927917 only mutate closed
containers - therefore we create a closed container which can be mutated
within xhr.onreadystatechange
+document.write(div id='__MODULE_NAME__.container'
style='position:absolute; width:0; height:0; border:none'/div);
+
// Fetch the contents via XHR.
var xhr = newXhr();
xhr.open('GET', base + initialHtml);
@@ -322,14 +325,14 @@
scriptFrame.id = '__MODULE_NAME__';
scriptFrame.style.cssText = 'position:absolute; width:0; height:0;
border:none';
scriptFrame.tabIndex = -1;
-document.body.appendChild(scriptFrame);
+
document.getElementById(__MODULE_NAME__.container).appendChild(scriptFrame);
-// Expose the module function via an expando on the iframe's
window.
+// Expose the module function via the iframe's window.name property
// (this is needed for the compiled script to call back into
// onScriptLoad()).
var win = scriptFrame.contentWindow;
[gwt-contrib] Email address in from field @ gwt-code-reviews
I've posted a couple of patches to the codereviews site, but I noticed that it's using my main google account as the from email (mmast...@gmail.com ) instead of my mailing list subscription address (matt...@mastracci.com). Any ideas how I might be able to set my from address on the codereviews site to use the correct address, or allow those messages to come through to this list? I can't get Groups to allow me to subscribe with both addresses, and mail sent from the wrong address ends up in the moderation queue. :) Thanks, Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] i18n support for concrete default locale
Reviewers: jat, scottb, Description: This allows binding the default locale to a user-specified locale, so that requests for which locale negotiation fails end up being an actual locale with actual currency and number formatting specification. To achieve this, we also allow property providers to do template substitution of configuration properties. I should note that the hosted mode support checks out for Linux legacy hosted FF3 oophm. It was actually *failing* for me on Windows legacy (which means my IE, IE8, right?), although I couldn't figure out why. Since it's working on Linux, I now believe that's an unrelated issue, 'cept for the time it cost me. Please review this at http://gwt-code-reviews.appspot.com/34832 Affected files: dev/core/src/com/google/gwt/core/ext/SelectionProperty.java dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java dev/core/src/com/google/gwt/dev/cfg/StaticPropertyOracle.java dev/core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java samples/i18n/src/com/google/gwt/sample/i18n/I18N.gwt.xml user/src/com/google/gwt/i18n/I18N.gwt.xml user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimize out 'literal' != null at JS time
LGTM, will commit. http://gwt-code-reviews.appspot.com/34831 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Email address in from field @ gwt-code-reviews
It's tricky. Both of them rely on Google Accounts. The upshot is that you need two separate Google identities, one for each email address. For example, I have a public Google Account for sco...@google.com, which I use on Google Code Project Hosting, etc. I also have a private @gmail.comaddress I use for personal stuff. The tricky thing is you can't sign into more than one account at the same time in the same browser. So I keep Firefox running for personal stuff, and use Chrome for work stuff. On Fri, Jun 5, 2009 at 3:26 PM, Matt Mastracci matt...@mastracci.comwrote: I've posted a couple of patches to the codereviews site, but I noticed that it's using my main google account as the from email ( mmast...@gmail.com ) instead of my mailing list subscription address (matt...@mastracci.com). Any ideas how I might be able to set my from address on the codereviews site to use the correct address, or allow those messages to come through to this list? I can't get Groups to allow me to subscribe with both addresses, and mail sent from the wrong address ends up in the moderation queue. :) Thanks, Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimize out 'literal' != null at JS time
Committed @r5519. Thanks, Matthew, this is great! On Fri, Jun 5, 2009 at 4:46 PM, sco...@google.com wrote: LGTM, will commit. http://gwt-code-reviews.appspot.com/34831 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5519 - Optimizes JS constructs like ('foo' != null) - (true).
Author: sco...@google.com
Date: Fri Jun 5 13:52:44 2009
New Revision: 5519
Added:
trunk/dev/core/test/com/google/gwt/dev/js/JsStaticEvalTest.java
Modified:
trunk/dev/core/src/com/google/gwt/dev/js/JsStaticEval.java
Log:
Optimizes JS constructs like ('foo' != null) - (true).
Patch by: mmastrac
Review by: me
Modified: trunk/dev/core/src/com/google/gwt/dev/js/JsStaticEval.java
==
--- trunk/dev/core/src/com/google/gwt/dev/js/JsStaticEval.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/js/JsStaticEval.java Fri Jun 5
13:52:44 2009
@@ -159,6 +159,8 @@
trySimplifyComma(arg1, arg2, ctx);
} else if (op == JsBinaryOperator.EQ) {
trySimplifyEq(x, arg1, arg2, ctx);
+ } else if (op == JsBinaryOperator.NEQ) {
+trySimplifyNe(x, arg1, arg2, ctx);
}
}
@@ -482,6 +484,22 @@
return original;
}
+private JsExpression simplifyNe(JsExpression original, JsExpression
arg1,
+JsExpression arg2) {
+ assert (original != null);
+
+ if (arg1 instanceof JsNullLiteral) {
+return simplifyNullNe(original, arg2);
+ }
+
+ if (arg2 instanceof JsNullLiteral) {
+return simplifyNullNe(original, arg1);
+ }
+
+ // no simplification made
+ return original;
+}
+
/**
* Simplify exp == null.
*/
@@ -499,9 +517,34 @@
return original;
}
+/**
+ * Simplify exp != null.
+ */
+private JsExpression simplifyNullNe(JsExpression original,
JsExpression exp) {
+ assert (original != null);
+
+ if (exp instanceof JsValueLiteral) {
+// undefined is not a JsValueLiteral, so the only way
+// the result can be false is if exp is itself a JsNullLiteral
+boolean result = !(exp instanceof JsNullLiteral);
+return program.getBooleanLiteral(result);
+ }
+
+ // no simplification made
+ return original;
+}
+
private void trySimplifyEq(JsExpression original, JsExpression arg1,
JsExpression arg2, JsContextJsExpression ctx) {
JsExpression updated = simplifyEq(original, arg1, arg2);
+ if (updated != original) {
+ctx.replaceMe(updated);
+ }
+}
+
+private void trySimplifyNe(JsExpression original, JsExpression arg1,
+JsExpression arg2, JsContextJsExpression ctx) {
+ JsExpression updated = simplifyNe(original, arg1, arg2);
if (updated != original) {
ctx.replaceMe(updated);
}
Added: trunk/dev/core/test/com/google/gwt/dev/js/JsStaticEvalTest.java
==
--- (empty file)
+++ trunk/dev/core/test/com/google/gwt/dev/js/JsStaticEvalTest.java Fri
Jun 5 13:52:44 2009
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.dev.js;
+
+import com.google.gwt.dev.jjs.SourceOrigin;
+import com.google.gwt.dev.js.ast.JsProgram;
+import com.google.gwt.dev.js.ast.JsStatement;
+import com.google.gwt.dev.js.ast.JsVisitor;
+import com.google.gwt.dev.util.DefaultTextOutput;
+import com.google.gwt.dev.util.TextOutput;
+
+import junit.framework.TestCase;
+
+import java.io.StringReader;
+import java.util.List;
+
+public class JsStaticEvalTest extends TestCase {
+
+ public void testLiteralEqNull() throws Exception {
+assertTrue(optimize(alert('test' == null)).equals(alert(false);));
+ }
+
+ public void testLiteralNeNull() throws Exception {
+assertTrue(optimize(alert('test' != null)).equals(alert(true);));
+ }
+
+ public void testNullEqNull() throws Exception {
+assertTrue(optimize(alert(null == null)).equals(alert(true);));
+ }
+
+ public void testNullNeNull() throws Exception {
+assertTrue(optimize(alert(null != null)).equals(alert(false);));
+ }
+
+ private String optimize(String js) throws Exception {
+JsProgram program = new JsProgram();
+ListJsStatement expected = JsParser.parse(SourceOrigin.UNKNOWN,
+program.getScope(), new StringReader(js));
+program.getGlobalBlock().getStatements().addAll(expected);
+
+// Run the static evaluation over this new program
+JsStaticEval.exec(program);
+
+TextOutput text = new DefaultTextOutput(true);
+JsVisitor generator = new JsSourceGenerationVisitor(text);
+
+generator.accept(program);
+return
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) Would keeping that VM alive open up the possibility of a semi-incremental build? On Fri, Jun 5, 2009 at 1:52 PM, Scott Blum sco...@google.com wrote: On Fri, Jun 5, 2009 at 1:47 PM, Lex Spoon sp...@google.com wrote: Reading further in the thread, though, maybe we should simply use -server! Funny enough, I used to use -server in all my launch configs, but at some point I found it seemed actually a lot slower most of the time, due to all the overhead. I think you need a really big compile to make it worth it (30-perm Showcase might be worth it, the other samples probably not). Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] SOYC gives drill-down on size for leftover and exclusive fragments
Reviewers: krpobst_google.com, Description: SOYC adds a drill-down size breakdown for the exclusive and leftover fragmetns, just like the one it currently gives for the total program and the initial download. Please review this at http://gwt-code-reviews.appspot.com/33843 Affected files: tools/soyc-vis/src/com/google/gwt/soyc/GlobalInformation.java tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java tools/soyc-vis/src/com/google/gwt/soyc/Settings.java tools/soyc-vis/src/com/google/gwt/soyc/SizeBreakdown.java tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
Ever since I started using Eclipse, I've always thought that compilers and make systems should be always on. I'd bet an incremental build would be hard to pull off first time around, but an always-on GWT compiler could at least keep the initial JDT parse tree alive somewhere (in RAM if it's not huge, on disk if it is) and update it on-demand by monitoring the filesystem for changes (at least in theory--I haven't looked at the compiler internals). Ideally, there'd be some sort of caching mechanism that could be invalidated by filesystem changes so you could store optimized JS ASTs, too, so you save on parsing _and_ compiling, but that seems like a v2 feature. Ian On Fri, Jun 5, 2009 at 2:13 PM, Isaac Truettitru...@gmail.com wrote: Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) Would keeping that VM alive open up the possibility of a semi-incremental build? On Fri, Jun 5, 2009 at 1:52 PM, Scott Blum sco...@google.com wrote: On Fri, Jun 5, 2009 at 1:47 PM, Lex Spoon sp...@google.com wrote: Reading further in the thread, though, maybe we should simply use -server! Funny enough, I used to use -server in all my launch configs, but at some point I found it seemed actually a lot slower most of the time, due to all the overhead. I think you need a really big compile to make it worth it (30-perm Showcase might be worth it, the other samples probably not). Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
On Fri, Jun 5, 2009 at 5:13 PM, Isaac Truett itru...@gmail.com wrote: Of course, if we ran the GWT compiler as a service on the developer's desktop (or kept it hot from the Eclipse plugin), then we could run it with -server and win it back over many compiles... hmmm. :) Would keeping that VM alive open up the possibility of a semi-incremental build? The coolest thing is we could keep a hot TypeOracle sitting and ready to go, and integrate with the IDE's natural build process to update it on the fly. We could also enrich the Generator API to on-demand re-run generators when their dependencies change, to avoid having to do that step. Not only would hosted mode be basically instant, but a draft compile would be blazing fast too. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Optimize out 'literal' != null at JS time
Yeah, it's awesome particularly for smaller patches, really cuts off the overhead. On Fri, Jun 5, 2009 at 5:22 PM, Matt Mastracci matt...@mastracci.comwrote: Cool thanks. This codereview process is far easier with Rietveld. :) On 5-Jun-09, at 2:52 PM, Scott Blum wrote: Committed @r5519. Thanks, Matthew, this is great! On Fri, Jun 5, 2009 at 4:46 PM, sco...@google.com wrote: LGTM, will commit. http://gwt-code-reviews.appspot.com/34831 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] UnsatisfiedLinkError during testing
Hello, I can't get the tests to work, everything fails like below: $ cat /home/peper/devel/gwt/live/gwt/build/out/user/test/linux-hosted-mode-emma/reports/TEST-com.google.gwt.core.CoreSuite.txt Testsuite: com.google.gwt.core.CoreSuite Tests run: 20, Failures: 0, Errors: 20, Time elapsed: 0.969 sec Testcase: testPayload took 0.752 sec Caused an ERROR Native Library /home/peper/devel/gwt/live/gwt/build/staging/gwt-linux-0.0.0/libswt-pi-gtk-3235.so already loaded in another classloader java.lang.UnsatisfiedLinkError: Native Library /home/peper/devel/gwt/live/gwt/build/staging/gwt-linux-0.0.0/libswt-pi-gtk-3235.so already loaded in another classloader at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1743) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674) at java.lang.Runtime.load0(Runtime.java:770) at java.lang.System.load(System.java:1003) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:132) at org.eclipse.swt.internal.gtk.OS.clinit(OS.java:22) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:126) at com.google.gwt.dev.SwtHostedModeBase.clinit(SwtHostedModeBase.java:104) at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:223) at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:132) at java.lang.Thread.run(Thread.java:619) $ java -version java version 1.6.0_14 Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode) That's a 32bit java on an otherwise 64bit linux, but hosted mode does work fine. -- Best Regards, Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Simpler eventSink calls in RadioButton
Reviewers: jlabanca, Description: John, if you have a moment... Please review this at http://gwt-code-reviews.appspot.com/33844 Affected files: reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java user/src/com/google/gwt/user/client/ui/RadioButton.java Index: reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java === --- reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java (revision 5519) +++ reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java (working copy) @@ -65,5 +65,6 @@ addIssue(new VisualsForWindowEvents()); addIssue(new VisualsForDialogBox()); addIssue(new VisualsForSuggestBox()); +addIssue(new VisualsForCheckBoxAndRadioButtonEvents()); } } Index: user/src/com/google/gwt/user/client/ui/RadioButton.java === --- user/src/com/google/gwt/user/client/ui/RadioButton.java (revision 5519) +++ user/src/com/google/gwt/user/client/ui/RadioButton.java (working copy) @@ -17,10 +17,6 @@ import com.google.gwt.dom.client.Element; import com.google.gwt.dom.client.EventTarget; -import com.google.gwt.event.dom.client.BlurEvent; -import com.google.gwt.event.dom.client.ClickEvent; -import com.google.gwt.event.dom.client.KeyDownEvent; -import com.google.gwt.event.dom.client.MouseUpEvent; import com.google.gwt.event.logical.shared.ValueChangeEvent; import com.google.gwt.user.client.DOM; import com.google.gwt.user.client.Event; @@ -65,10 +61,10 @@ super(DOM.createInputRadio(name)); setStyleName(gwt-RadioButton); -sinkEvents(Event.getTypeInt(ClickEvent.getType().getName())); -sinkEvents(Event.getTypeInt(MouseUpEvent.getType().getName())); -sinkEvents(Event.getTypeInt(BlurEvent.getType().getName())); -sinkEvents(Event.getTypeInt(KeyDownEvent.getType().getName())); +sinkEvents(Event.ONCLICK); +sinkEvents(Event.ONMOUSEOUT); +sinkEvents(Event.ONBLUR); +sinkEvents(Event.ONKEYDOWN); } /** --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
It could do it using a technique called 'semantic inlining' where the
compiler has builtin knowledge of the Map interface and treats it in a
magic fashion. To do it in a more general purpose fashion would be
very tricky. If put() or remove() could be inlined by the compiler
normally, then standard techniques like liveness analysis/dead code
elimination could remove the fetch since after inlining, the compiler
could see that the calling block never uses the value.
I hesitate to suggest the following, but here goes. Perl is not a
context-free language, methods can be evaluated in differing contexts
and functions can detect this and choose to act differently based on
what they are being assigned to, see:
http://docstore.mik.ua/orelly/perl/cookbook/ch10_07.htm
Quote:
if (wantarray()) {
# list context
}
elsif (defined wantarray()) {
# scalar context
}
else {
# void context
}
Note that last one, now imagine a magic GWT function, GWT.wantsValue()
that returns true if the current JMethod is being executed as part of
an expression that is assigned or passed as a parameter to something,
false otherwise.
You could then rewrite HashMap.put() as
public T put(S key, T val) {
if(GWT.wantsValue()) {
// call putSlow() which returns a value
}
else {
// call putFast(), return null
}
}
-Ray
On Fri, Jun 5, 2009 at 11:52 PM, Damon Lundindamon.lun...@gmail.com wrote:
I have an idea of an optimization of usages of HashMap. I have
recently switched from using the FastStringMap to using a normal
HashMap since the performance difference isn't as significant as it
once was. However, there is one point where I was able to still make
the FastStringMap faster. I overrode the put and remove methods and
had them return null instead of performing a get to fetch the current
value for the keys. In the vast majority of cases, the client never
uses the values returned from put or remove which just wastes the gets
to look them up. I tried a test that does 100,000 puts and gets and I
have found that my version which returns null in the put is almost
twice as fast as the version which does not.
If the compiler can devirtualize a variable to a java.util.HashMap and
it sees that the return value is not used, could the compilter
substitute a different method call to a different version of put and
remove that just return null (or perhaps nothing)?
If you want to see the details of my tests, you can read the blog post
I recently put up regarding our usage of FastStringMap:
http://development.lombardi.com/?p=797
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
That's... strange but cool!
On Fri, Jun 5, 2009 at 8:43 PM, Ray Cromwell cromwell...@gmail.com wrote:
It could do it using a technique called 'semantic inlining' where the
compiler has builtin knowledge of the Map interface and treats it in a
magic fashion. To do it in a more general purpose fashion would be
very tricky. If put() or remove() could be inlined by the compiler
normally, then standard techniques like liveness analysis/dead code
elimination could remove the fetch since after inlining, the compiler
could see that the calling block never uses the value.
I hesitate to suggest the following, but here goes. Perl is not a
context-free language, methods can be evaluated in differing contexts
and functions can detect this and choose to act differently based on
what they are being assigned to, see:
http://docstore.mik.ua/orelly/perl/cookbook/ch10_07.htm
Quote:
if (wantarray()) {
# list context
}
elsif (defined wantarray()) {
# scalar context
}
else {
# void context
}
Note that last one, now imagine a magic GWT function, GWT.wantsValue()
that returns true if the current JMethod is being executed as part of
an expression that is assigned or passed as a parameter to something,
false otherwise.
You could then rewrite HashMap.put() as
public T put(S key, T val) {
if(GWT.wantsValue()) {
// call putSlow() which returns a value
}
else {
// call putFast(), return null
}
}
-Ray
On Fri, Jun 5, 2009 at 11:52 PM, Damon Lundindamon.lun...@gmail.com
wrote:
I have an idea of an optimization of usages of HashMap. I have
recently switched from using the FastStringMap to using a normal
HashMap since the performance difference isn't as significant as it
once was. However, there is one point where I was able to still make
the FastStringMap faster. I overrode the put and remove methods and
had them return null instead of performing a get to fetch the current
value for the keys. In the vast majority of cases, the client never
uses the values returned from put or remove which just wastes the gets
to look them up. I tried a test that does 100,000 puts and gets and I
have found that my version which returns null in the put is almost
twice as fast as the version which does not.
If the compiler can devirtualize a variable to a java.util.HashMap and
it sees that the return value is not used, could the compilter
substitute a different method call to a different version of put and
remove that just return null (or perhaps nothing)?
If you want to see the details of my tests, you can read the blog post
I recently put up regarding our usage of FastStringMap:
http://development.lombardi.com/?p=797
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5437 - Addresses public issue 3566: Offer option to not decode cookies
Hi Kathrin, I ran into a series of checkstyle violations introduce in this revision. Please review commit attached patch. To setup Eclipse to detect checkstyle issues (see Checkstyle section): http://google-web-toolkit.googlecode.com/svn/trunk/eclipse/README.txt --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- fix-checkstyle-cookies.patch Description: Binary data
[gwt-contrib] Re: UnsatisfiedLinkError during testing
2009/6/6 Scott Blum sco...@google.com: What build/version of GWT is this? That was from the snapshot-2009.05.12-r5406 branch but I just checked trunk and it fails like that too. That's when running $ ant test in user. Tests in dev mostly pass, but I do get this for example (same for 64bit jvm) Testsuite: com.google.gwt.core.ext.typeinfo.JAbstractMethodTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.021 sec Testcase: warning took 0.001 sec FAILED Exception in constructor: testGenericMethodWithDependentTypeParameters (com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.cfg.ModuleDef.checkForSeedTypes(ModuleDef.java:448) at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:247) at com.google.gwt.dev.cfg.ModuleDef.getTypeOracle(ModuleDef.java:307) at com.google.gwt.core.ext.typeinfo.ModuleContext.init(ModuleContext.java:33) at com.google.gwt.core.ext.typeinfo.JAbstractMethodTest.init(JAbstractMethodTest.java:33) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) (snip) ) junit.framework.AssertionFailedError: Exception in constructor: testGenericMethodWithDependentTypeParameters (com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.cfg.ModuleDef.checkForSeedTypes(ModuleDef.java:448) at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:247) at com.google.gwt.dev.cfg.ModuleDef.getTypeOracle(ModuleDef.java:307) (snip) ) -- Best Regards, Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
