[gwt-contrib] Re: Fwd: DateTimeFormat parsing patch
Hi Shanjian, Alex, I have verified that the new DateTimeFormat parsing code correctly rejects zero month and zero day-of month values. However, it now accepts zero year values. Is this desired? Thanks, Florbela On Apr 17, 2:55 pm, Alex Rudnick a...@google.com wrote: LGTM. Thanks, Shanjian! Committed to the trunk at r5257. On Fri, Apr 17, 2009 at 2:19 PM, Shanjian Li shanjia...@gmail.com wrote: This is a complete patch to address a bug inDateTimeFormatparsing code. Zero should be treated as invalid input for month and day-of-month value. shanjian -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Comment on OverlayTypes in google-web-toolkit
I'm assuming we'd have to rewrite new and field access operators to these
classes in the hosted-mode classloader, right? I haven't messed with the
hosted-mode classloader in a *very* long time, so we may be doing this
already for all I know. If that's feasible, this sounds like it would be
pretty useful. In particular, it seems that it would be particularly nice
for JSON overlays.
On Fri, Jun 12, 2009 at 9:59 PM, codesite-nore...@google.com wrote:
Comment by cromwellian:
It would be interesting to consider Constructor() as being rewritten to a
static method with an implicit call to createObject() and all references to
this rewritten to this$static. e.g.
public Foo(int x, String y) {
this.x = x;
this.y = y;
}
rewritten to
public static Foo consFoo(int x, String y) {
Foo this$static=createObject.cast();
this$static.x=x;
this$static.y=y;
return this$static;
}
Moreover, you could consider any field declarations on Foo as having
implicit native methods for getting and assignment. Thus,
public Foo extends JavaScriptObject {
int x;
}
would implicitly have methods like
native int getX() /*-{ return x; }-*/;
native void setX(int x) /*-{ this.x=x; }-*/;
although these would only exist in the compiler/AST (purely for
visualization purposes here). That way, needless boilerplate accessors in
JSOs would be eliminated.
All of the usual JSO restrictions would apply. This is purely syntactic
sugar. Stuff like field initializers and super calls in the constructor
would still be banned (for now), although they could be supported via
additional rewriting logic (like moving initializers into the synthesized
factory method and super calls invoking super class factory methods which
take this$static parameters)
For more information:
http://code.google.com/p/google-web-toolkit/wiki/OverlayTypes
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Comment on OverlayTypes in google-web-toolkit
On Mon, Jun 15, 2009 at 7:26 AM, Joel Webberj...@google.com wrote: I'm assuming we'd have to rewrite new and field access operators to these classes in the hosted-mode classloader, right? I haven't messed with the hosted-mode classloader in a *very* long time, so we may be doing this already for all I know. If that's feasible, this sounds like it would be pretty useful. In particular, it seems that it would be particularly nice for JSON overlays. Rewriting get/setField opcodes to call into JsValueGlue wouldn't be any harder than anything else HostedModeRewriter currently does. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by ivancevic.nikola: Works fine (Windows Vista 32-bit, jdk 1.6.0u13, Eclipse 3.4, GWT trunk rev5557, FireFox 3.0.11). With jdk 1.6.0u14, after the page has been opened, it is needed to reload it once more in order to activate breakpoints. 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: Comment on OverlayTypes in google-web-toolkit
+1 to field overlays. Just need to schedule the work. On Mon, Jun 15, 2009 at 9:23 AM, BobV b...@google.com wrote: On Mon, Jun 15, 2009 at 7:26 AM, Joel Webberj...@google.com wrote: I'm assuming we'd have to rewrite new and field access operators to these classes in the hosted-mode classloader, right? I haven't messed with the hosted-mode classloader in a *very* long time, so we may be doing this already for all I know. If that's feasible, this sounds like it would be pretty useful. In particular, it seems that it would be particularly nice for JSON overlays. Rewriting get/setField opcodes to call into JsValueGlue wouldn't be any harder than anything else HostedModeRewriter currently does. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5537 - Ant rework for speed:
+GWTC With regard to the Mac looking for gwt-dev-linux, since I don't literally see a build-dev target, what's the chain above the line you cited? I thought my fixes to property.ensure in e.g. user/build.xml line 47 addressed that, and I see I missed some (in doc, samples, and soyc-vis... only the last of which is likely to be stopping you, though). With regard to using buildonly as precursor to tests, I think you want to the target dist-dev, though I'm open to suggestions for how this should work. It used to be that: 1. we had both build and dist, as separate targets (unchanged), 2. tests effectively require a distribution to run in (unchanged), 3. we had buildonly, but did not have dist-dev, so the two were blurred explicitly (changed), 4. build depended, by way of -do, on dist, which I found confusingly backwards (changed), 5. top-level test depended on build, which depended on dist as above (changed to depend on dist-one, but should probably be dist-dev instead now that it exists), 6. build was the default target, which as above worked because it ran dist as a dependency (changed; dist is project default target, and depends on build). Solutions: 1. Do we want buildonly to imply dist-dev? Do we want build to imply dist? My intuition is no, that if separate, build builds and dist packages and dist needs build (but not vice-versa). That is semantic a change from before, though. 2. If not, then we want to retrain ourselves to use dist-dev at least once, to get the distro set, even if you then use buildonly after that to refresh sources? On Mon, Jun 15, 2009 at 11:10 AM, Freeland Abbott fabb...@google.comwrote: Thanks, I'll revisit. On Mon, Jun 15, 2009 at 10:43 AM, BobV b...@google.com wrote: This no longer correctly works on mac platform. ant buildonly cd user ant test /Users/bob/gwt/trunk/common.ant.xml:299: GWT must be built before performing any tests. This can be fixed by running ant in the /Users/bob/gwt/trunk directory. also, the ant build-dev target fails: /Users/bob/gwt/trunk/common.ant.xml:299: Cannot find dependency /Users/bob/gwt/trunk/build/lib/gwt-dev-linux.jar -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5537 - Ant rework for speed:
Bob, John, can you review? This doesn't address the buildonly or dist-dev
as precursor to user/test question, but I think addresses Thomas' and Bob's
other issue.
On Mon, Jun 15, 2009 at 11:47 AM, Freeland Abbott fabb...@google.comwrote:
+GWTC
With regard to the Mac looking for gwt-dev-linux, since I don't literally
see a build-dev target, what's the chain above the line you cited? I
thought my fixes to property.ensure in e.g. user/build.xml line 47
addressed that, and I see I missed some (in doc, samples, and soyc-vis...
only the last of which is likely to be stopping you, though).
With regard to using buildonly as precursor to tests, I think you want to
the target dist-dev, though I'm open to suggestions for how this should
work. It used to be that:
1. we had both build and dist, as separate targets (unchanged),
2. tests effectively require a distribution to run in (unchanged),
3. we had buildonly, but did not have dist-dev, so the two were
blurred explicitly (changed),
4. build depended, by way of -do, on dist, which I found
confusingly backwards (changed),
5. top-level test depended on build, which depended on dist as
above (changed to depend on dist-one, but should probably be dist-dev
instead now that it exists),
6. build was the default target, which as above worked because it ran
dist as a dependency (changed; dist is project default target, and
depends on build).
Solutions:
1. Do we want buildonly to imply dist-dev? Do we want build to imply
dist? My intuition is no, that if separate, build builds and dist packages
and dist needs build (but not vice-versa). That is semantic a change from
before, though.
2. If not, then we want to retrain ourselves to use dist-dev at least
once, to get the distro set, even if you then use buildonly after that to
refresh sources?
On Mon, Jun 15, 2009 at 11:10 AM, Freeland Abbott fabb...@google.comwrote:
Thanks, I'll revisit.
On Mon, Jun 15, 2009 at 10:43 AM, BobV b...@google.com wrote:
This no longer correctly works on mac platform.
ant buildonly cd user ant test
/Users/bob/gwt/trunk/common.ant.xml:299: GWT must be built before
performing any tests. This can be fixed by running ant in the
/Users/bob/gwt/trunk directory.
also, the ant build-dev target fails:
/Users/bob/gwt/trunk/common.ant.xml:299: Cannot find dependency
/Users/bob/gwt/trunk/build/lib/gwt-dev-linux.jar
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: build.xml
===
--- build.xml (revision 5557)
+++ build.xml (working copy)
@@ -93,7 +93,7 @@
call-subproject subproject=samples subtarget=checkstyle /
/target
- target name=test depends=dist-one description=Runs all the GWT tests
+ target name=test depends=dist-dev description=Runs all the GWT tests
call-subproject subproject=buildtools subtarget=test /
call-subproject subproject=dev subtarget=test /
call-subproject subproject=user subtarget=test /
Index: build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java
===
--- build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java (revision 5557)
+++ build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java (working copy)
@@ -116,8 +116,12 @@
@Override
public void addToZip(ZipOutputStream out, String path) throws IOException {
FileInputStream inStream = new FileInputStream(tmpFile);
- doZipFile(inStream, out, path, timestamp, archive, mode);
- tmpFile.delete();
+ try {
+doZipFile(inStream, out, path, timestamp, archive, mode);
+tmpFile.delete();
+ } finally {
+inStream.close();
+ }
}
}
Index: tools/api-checker/build.xml
===
--- tools/api-checker/build.xml (revision 5557)
+++ tools/api-checker/build.xml (working copy)
@@ -7,7 +7,7 @@
property name=tools.build value=${gwt.build.out}/${project.tail} /
!-- Platform shouldn't matter here, just picking one --
- property.ensure name=gwt.dev.jar location=${gwt.build.lib}/gwt-dev-linux.jar /
+ property.ensure name=gwt.dev.jar location=${gwt.build.lib}/gwt-dev-${build.host.platform}.jar /
property.ensure name=gwt.user.jar location=${gwt.build.lib}/gwt-user.jar /
target name=compile description=Compile all class files
Index: tools/soyc-vis/build.xml
===
--- tools/soyc-vis/build.xml (revision 5557)
+++ tools/soyc-vis/build.xml (working copy)
@@ -7,7 +7,7 @@
import file=${gwt.root}/common.ant.xml /
!-- Platform shouldn't matter here, just picking
[gwt-contrib] RPC extension points
Hello, This thread follows this one (http://groups.google.com/group/Google- Web-Toolkit-Contributors/msg/582cfe33f17deab3), so please read it before this one. To make Google App Engine and GWT work together (in adapter4appengine project), I had to modify the RPC serialization code. My first goal was to add *clean extension points*, to allow any third library developer to tune RPC serialization according to his needs. Of course, I used it to develop a DataNucleus adapter, and plan to port Hibernate one as well. The idea is to allow 2 kinds of extension points : - ISerializationFilter, that indicates if a specific field of a class should be serialized or not. It is called for serialization signature computation and for each object serialization * Typical use : used to remove new fields from enhancement - ISerializationTransformer, that can change a object instance from one type to another one * Typical use : used to turn persistent collection back to regular one A first step has been implemented in adapter4appengine library. It only needs change for 4 existing classes (RPC, SerializabilityUtil, ServerSerializationStreamReader and ServerSerializationStreamWriter). A next step would be to read filters and transformers from the gwt.xml file (currently, they are set by code in EngireRemoteServlet class). I would *really* love to see this code integrated in official GWT release, since it would be a pain for me to do the same fixes every time a new GWT release is out (as I still have to do it since GWT 1.4 for Hibernate4GWT/Gilead because issue 1291 is opened without result since 2 years :-( ). My 2 cents Bruno --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5558 - Fixed an HTMLTable bug where getCellElement would add the row offset instead of subtracti...
Author: jlaba...@google.com
Date: Mon Jun 15 08:53:50 2009
New Revision: 5558
Modified:
changes/jlabanca/scrolltable/user/src/com/google/gwt/user/client/ui/HTMLTable.java
Log:
Fixed an HTMLTable bug where getCellElement would add the row offset
instead of subtracting it.
Patch by: jlabanca
Modified:
changes/jlabanca/scrolltable/user/src/com/google/gwt/user/client/ui/HTMLTable.java
==
---
changes/jlabanca/scrolltable/user/src/com/google/gwt/user/client/ui/HTMLTable.java
(original)
+++
changes/jlabanca/scrolltable/user/src/com/google/gwt/user/client/ui/HTMLTable.java
Mon Jun 15 08:53:50 2009
@@ -19,6 +19,7 @@
import com.google.gwt.dom.client.TableRowElement;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.event.dom.client.DomEvent;
import com.google.gwt.event.dom.client.HasClickHandlers;
import com.google.gwt.event.shared.HandlerRegistration;
import com.google.gwt.user.client.DOM;
@@ -438,8 +439,8 @@
* @return the element
*/
private native Element getCellElement(Element table, int row, int col)
/*-{
- return table.rows[row].cells[col];
- }-*/;
+ return table.rows[row].cells[col];
+}-*/;
}
/**
@@ -814,7 +815,7 @@
*
* @param listener listener to add
* @deprecated add a click handler instead and use
- * {...@link HTMLTable#getCellForEvent(ClickEvent)} to get the
cell
+ * {...@link HTMLTable#getCellForEvent(DomEvent)} to get the
cell
* information (remember to check for a null return value)
*/
@Deprecated
@@ -876,13 +877,13 @@
* @param event A click event of indeterminate origin
* @return The appropriate cell, or null
*/
- public Cell getCellForEvent(ClickEvent event) {
+ public Cell getCellForEvent(DomEvent? event) {
TableCellElement td =
getEventTargetCell(Event.as(event.getNativeEvent())).cast();
if (td == null) {
return null;
}
TableRowElement tr = td.getParentElement().cast();
-return new Cell(tr.getRowIndex() + rowOffset, td.getCellIndex());
+return new Cell(tr.getRowIndex() - rowOffset, td.getCellIndex());
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5537 - Ant rework for speed:
Bob notes that dist-dev doesn't need (and thus shouldn't have) its
dependency on tools. I take that as tacit agreement that dist-dev can be
the minimally build everything for test execution name.
On Mon, Jun 15, 2009 at 11:53 AM, Freeland Abbott fabb...@google.comwrote:
Bob, John, can you review? This doesn't address the buildonly or dist-dev
as precursor to user/test question, but I think addresses Thomas' and Bob's
other issue.
On Mon, Jun 15, 2009 at 11:47 AM, Freeland Abbott fabb...@google.comwrote:
+GWTC
With regard to the Mac looking for gwt-dev-linux, since I don't literally
see a build-dev target, what's the chain above the line you cited? I
thought my fixes to property.ensure in e.g. user/build.xml line 47
addressed that, and I see I missed some (in doc, samples, and soyc-vis...
only the last of which is likely to be stopping you, though).
With regard to using buildonly as precursor to tests, I think you want to
the target dist-dev, though I'm open to suggestions for how this should
work. It used to be that:
1. we had both build and dist, as separate targets (unchanged),
2. tests effectively require a distribution to run in (unchanged),
3. we had buildonly, but did not have dist-dev, so the two were
blurred explicitly (changed),
4. build depended, by way of -do, on dist, which I found
confusingly backwards (changed),
5. top-level test depended on build, which depended on dist as
above (changed to depend on dist-one, but should probably be dist-dev
instead now that it exists),
6. build was the default target, which as above worked because it
ran dist as a dependency (changed; dist is project default target, and
depends on build).
Solutions:
1. Do we want buildonly to imply dist-dev? Do we want build to imply
dist? My intuition is no, that if separate, build builds and dist
packages
and dist needs build (but not vice-versa). That is semantic a change from
before, though.
2. If not, then we want to retrain ourselves to use dist-dev at least
once, to get the distro set, even if you then use buildonly after that to
refresh sources?
On Mon, Jun 15, 2009 at 11:10 AM, Freeland Abbott fabb...@google.comwrote:
Thanks, I'll revisit.
On Mon, Jun 15, 2009 at 10:43 AM, BobV b...@google.com wrote:
This no longer correctly works on mac platform.
ant buildonly cd user ant test
/Users/bob/gwt/trunk/common.ant.xml:299: GWT must be built before
performing any tests. This can be fixed by running ant in the
/Users/bob/gwt/trunk directory.
also, the ant build-dev target fails:
/Users/bob/gwt/trunk/common.ant.xml:299: Cannot find dependency
/Users/bob/gwt/trunk/build/lib/gwt-dev-linux.jar
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java
===
--- build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java (revision 5558)
+++ build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/LatestTimeJar.java (working copy)
@@ -116,8 +116,12 @@
@Override
public void addToZip(ZipOutputStream out, String path) throws IOException {
FileInputStream inStream = new FileInputStream(tmpFile);
- doZipFile(inStream, out, path, timestamp, archive, mode);
- tmpFile.delete();
+ try {
+doZipFile(inStream, out, path, timestamp, archive, mode);
+tmpFile.delete();
+ } finally {
+inStream.close();
+ }
}
}
Index: build.xml
===
--- build.xml (revision 5558)
+++ build.xml (working copy)
@@ -35,7 +35,7 @@
gwt.ant dir=distro-source target=${build.host.platform} /
/target
- target name=dist-dev depends=buildonly, tools description=Make this platform's distribution, minus doc and samples
+ target name=dist-dev depends=buildonly description=Make this platform's distribution, minus doc and samples
gwt.ant dir=distro-source target=${build.host.platform} /
/target
@@ -93,7 +93,7 @@
call-subproject subproject=samples subtarget=checkstyle /
/target
- target name=test depends=dist-one description=Runs all the GWT tests
+ target name=test depends=dist-dev description=Runs all the GWT tests
call-subproject subproject=buildtools subtarget=test /
call-subproject subproject=dev subtarget=test /
call-subproject subproject=user subtarget=test /
Index: tools/api-checker/build.xml
===
--- tools/api-checker/build.xml (revision 5558)
+++ tools/api-checker/build.xml (working copy)
@@ -7,7 +7,7 @@
property name=tools.build value=${gwt.build.out}/${project.tail} /
[gwt-contrib] Re: initial load sequence for runAsync's
LGTM http://gwt-code-reviews.appspot.com/33848/diff/4002/4005 File dev/core/src/com/google/gwt/core/ext/soyc/impl/SplitPointRecorder.java (right): http://gwt-code-reviews.appspot.com/33848/diff/4002/4005#newcode68 Line 68: String location = splitPointMap.get(sp); assert location != null http://gwt-code-reviews.appspot.com/33848/diff/4002/4012 File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (right): http://gwt-code-reviews.appspot.com/33848/diff/4002/4012#newcode234 Line 234: private ListInteger splitPointInitialSequence = new ArrayListInteger(); Use Lists.create()? http://gwt-code-reviews.appspot.com/33848 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by liang.chu: I was trying to follow the Compiling guide and I'm getting the following ant compiling error: BUILD FAILED google/trunk/build.xml:43: The following error occurred while executing this line: google/trunk/platforms.ant.xml:36: The following error occurred while executing this line: google/trunk/platforms.ant.xml:13: The following error occurred while executing this line: google/trunk/dev/core/build.xml:66: The following error occurred while executing this line: google/trunk/common.ant.xml:155: Problem creating jar: /tmp/gwtjar2420128593920631719 (Too many open files) I'm using Ubuntu 8.10 64 bit Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Apache Ant version 1.7.1 Any ideas, thanks Ken 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: DockLayoutPanel
I'm still not 100% done with the API design, and a few edge-cases, but will announce on the lists as soon as I have something ready for everyone to try out. It uses a similar approach to the code in Wave, but is rather more general, and supports IE6 (which Wave doesn't). On Thu, Jun 11, 2009 at 5:41 PM, Bruce Johnson br...@google.com wrote: No, it's not checked in yet, but I think Joel might started a branch to land it before t long. It isn't literally the same code as in Wave, but it's logically equivalent. Joel can say a lot more about it than me. On Thu, Jun 11, 2009 at 5:36 PM, dflorey daniel.flo...@gmail.com wrote: Is the DockLayoutPanel presented at Google IO already in svn? The one that is being used by the wave client? I've not been able to find it... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR : Allow user-provided bridge classes in hosted mode
Reviewers: scottb, Message: Requesting review Description: This patch would allow user-provided code to escape from the CompilingClassLoader sandbox. Use case: - Create a type that should be used only in hosted mode which lives somewhere in the classpath - Create a web-mode implementation which lives in super-source - Annotate the web-mode implementation with the @BridgeClass annotation When CCL loads the super-source version it will notice the BridgeClass annotation and load the (possibly binary-only) implementation of the bridge class from the classpath via a child classloader. This newly-loaded type will then be able to refer to types that are not defined in the CCL sandbox. The web-mode compiler will continue to use the version in super-source and ignore the BridgeClass annotation. Please review this at http://gwt-code-reviews.appspot.com/34836 Affected files: M dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java A dev/core/src/com/google/gwt/dev/shell/rewrite/HasAnnotation.java A dev/core/super/com/google/gwt/core/client/BridgeClass.java M user/build.xml A user/test-super/com/google/gwt/dev/jjs/super/com/google/gwt/dev/jjs/bridge/UserBridgeClass.java M user/test/com/google/gwt/dev/jjs/CompilerSuite.java A user/test/com/google/gwt/dev/jjs/UserBridgeTest.gwt.xml A user/test/com/google/gwt/dev/jjs/bridge/BaseClass.java A user/test/com/google/gwt/dev/jjs/bridge/UserBridgeClass.java A user/test/com/google/gwt/dev/jjs/bridge/UserBridgeTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR : Make ClientBundle and CssResource generators faster
Reviewers: Dan Rice, Message: Requesting review Description: This change speeds up the ClientBundle and CssResource generators. - Use the compiler's ResourceOracle instead of the ClassLoader to find resources - Add a caching mechanism to ClientBundle's ResourceContext to allow ResourceGenerators to cache data between invocations. - Update CssResourceGenerator to use the cache for obfuscated type names. The cache in ResourceContext will be discarded whenever the TypeOracle changes or its reload count increases. Please review this at http://gwt-code-reviews.appspot.com/40804 Affected files: M user/src/com/google/gwt/resources/ext/ResourceContext.java M user/src/com/google/gwt/resources/ext/ResourceGeneratorUtil.java M user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java M user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java M user/src/com/google/gwt/resources/rg/CssResourceGenerator.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5559 - Add additional RPC sanity checks.
Author: b...@google.com
Date: Mon Jun 15 14:00:16 2009
New Revision: 5559
Modified:
trunk/user/src/com/google/gwt/user/server/rpc/RPC.java
trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
Log:
Add additional RPC sanity checks.
Patch by: meder
Review by: bobv
Modified: trunk/user/src/com/google/gwt/user/server/rpc/RPC.java
==
--- trunk/user/src/com/google/gwt/user/server/rpc/RPC.java (original)
+++ trunk/user/src/com/google/gwt/user/server/rpc/RPC.java Mon Jun 15
14:00:16 2009
@@ -269,6 +269,9 @@
String serviceMethodName = streamReader.readString();
int paramCount = streamReader.readInt();
+ if (paramCount streamReader.getNumberOfTokens()) {
+throw new IncompatibleRemoteServiceException(Invalid number of
parameters);
+ }
Class?[] parameterTypes = new Class[paramCount];
for (int i = 0; i parameterTypes.length; i++) {
Modified:
trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
==
--- trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
(original)
+++ trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
Mon Jun 15 14:00:16 2009
@@ -177,6 +177,9 @@
*/
public String processCall(String payload) throws SerializationException {
try {
+ if (getPermutationStrongName() == null) {
+throw new SecurityException(Blocked request without GWT
permutation header(XSRF attack?));
+ }
RPCRequest rpcRequest = RPC.decodeRequest(payload, this.getClass(),
this);
onAfterRequestDeserialized(rpcRequest);
return RPC.invokeAndEncodeResponse(this, rpcRequest.getMethod(),
Modified:
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
==
---
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
(original)
+++
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
Mon Jun 15 14:00:16 2009
@@ -373,6 +373,10 @@
}
}
+ public int getNumberOfTokens() {
+return tokenList.size();
+ }
+
public SerializationPolicy getSerializationPolicy() {
return serializationPolicy;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Allow user-provided bridge classes in hosted mode
Bob, I have some questions about the twilight zone in which this new class loader lives, but I'm kinda swamped this week. Maybe we can make some time to discuss? http://gwt-code-reviews.appspot.com/34836 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
Ray,
I think we can improve the class over time -- any reasonable starting point
(even without iterators or with non-optimal iterators) would help
significantly.
Stefan
On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell cromwell...@gmail.com wrote:
BTW, the last proposal is very unsafe with some form of escape
analysis since it is unsafe to pass references to classes which
reference local scope to other scopes. Another possibility is a form
of 'destructuring' of Iterator classes by inlining them completely
into local scope vs escape analysis and then forgoing separate
construction.
A simpler way to maintain for-each with JRE collections without
creating objects is to change the way that for-each deals with
IterableT when T is a List.
The compiler could change:
for(T x : foo) { ... }
where foo is a ListT
into
for(int i=0; ifoo.size(); ++i) {
T x = foo.get(i);
}
instead of calling foo.iterator() and using Iterator methods.
-Ray
On Fri, Jun 12, 2009 at 7:31 PM, Ray Cromwellcromwell...@gmail.com
wrote:
I'm in the process of some final tweaks on GQuery, so I'll look at how
much of my private JSArray class I can move over as a patch.
One possibility for avoiding Iterator object creation without using
flyweights is to introduce a new Iterator type which contains methods
which are parameterized by the collection and which use my Extension
Method/Category method JSO trick.
public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS list) {
return (FastIteratorS)(GWT.isScript() ? makeWeb() : makeHosted());
}
private final native FastIterator makeWeb() /*-{
return 0;
}-*/;
private final native FastIterator makeHosted() /*-{
return [0];
}-*/;
public final int value() {
return GWT.isScript() ? valueWeb() : valueHosted();
}
public native int valueWeb() /*-{
return this;
}-*/;
public native int valueHosted() /*-{
return this[0];
}-*/;
public native hasNext(ListT list) {
return value() list.size();
}
public native T next(ListT list) {
return list.get(value()++); // unsure if using value() as rvalue
will work here
}
}
then you should be able to write code like
ListString foo = getList();
FastIteratorString iter = FastIterator.make(foo);
while(iter.hasNext(foo)) {
String s = iter.next(foo);
}
Why doesn't this create any additional objects? Because
'iter'/FastIterator is actually a native JS number/scalar type, and
what this is really doing is simulating the addition of
hasNext()/next() to the number's prototype.
We could dispense with the need for an additional parameter if GWT had
a magic method for allocating new local variables/symbols in the local
scope. Imagine if writing
VariableT x = GWT.createVariable(0);
was a magic method that just generated a 'var x = 0' declaration, only
it promised to always be inlined and do so in the caller's scope.
'Variable' would be a magic class that never creates fields on the
actual object themselves and are pruned/removed at runtime.
Then you could have FastIterator impersonate a reference to the
underlying ListT, and rewrite hasNext()/next() as:
VariableInt x = GWT.createVariableInt(0);
public boolean hasNext() {
return x.get() this.size();
}
public T next() {
return this.get(x.get()++); // or x.postIncrement()
}
this would produce code that would create no additional objects as
well as maintain Iterator-like interface.
-Ray
On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
wrote:
+1 Ray
Could you contribute your implementation(s)?
On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com wrote:
+1 Ray. Now here's the really tricky question. Is there any way we can
take advantage of Javascript's for (x in y) { ... } syntax (and
should we,
given its spotty performance)? My intuition tells me that the only way
we
could use it would be through a callback, because there's nothing like
.NET
generators/yield in Javascript.
On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell cromwell...@gmail.com
wrote:
My take on this is that there is many places where I'd like to avoid
JRE collections, but the basic JsArray is too much of a downgrade. I
don't mind changing it to T if it doesn't effect performance cause
then I could subclass it, but as an example of the stuff I would like
in a 'FastArrayList' that is not a collections derivative:
1) add() instead of just set(length(), item) (e.g. push)
2) addAll(anotherFastArrayList) (e.g. concat)
3) splice
4) toArray() (webmode is reinterpret cast op)
5) remove
6) shift/unshift (useful for queue when combined with pop)
I use the following pattern all over GQuery to avoid JRE collections
but preserve for-each
for(Foo f :
[gwt-contrib] Re: initial load sequence for runAsync's
Committed at r5560. http://gwt-code-reviews.appspot.com/33848/diff/4002/4005 File dev/core/src/com/google/gwt/core/ext/soyc/impl/SplitPointRecorder.java (right): http://gwt-code-reviews.appspot.com/33848/diff/4002/4005#newcode68 Line 68: String location = splitPointMap.get(sp); On 2009/06/15 17:45:30, bobv wrote: assert location != null Done. http://gwt-code-reviews.appspot.com/33848/diff/4002/4012 File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (right): http://gwt-code-reviews.appspot.com/33848/diff/4002/4012#newcode234 Line 234: private ListInteger splitPointInitialSequence = new ArrayListInteger(); On 2009/06/15 17:45:30, bobv wrote: Use Lists.create()? Done. http://gwt-code-reviews.appspot.com/33848 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
I'm starting to make a bit o' progress on this. I'll send out a design doc
real soon now.
BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure
would be easier to discuss this in a wave...
On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein haust...@google.comwrote:
Ray,
I think we can improve the class over time -- any reasonable starting point
(even without iterators or with non-optimal iterators) would help
significantly.
Stefan
On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell cromwell...@gmail.comwrote:
BTW, the last proposal is very unsafe with some form of escape
analysis since it is unsafe to pass references to classes which
reference local scope to other scopes. Another possibility is a form
of 'destructuring' of Iterator classes by inlining them completely
into local scope vs escape analysis and then forgoing separate
construction.
A simpler way to maintain for-each with JRE collections without
creating objects is to change the way that for-each deals with
IterableT when T is a List.
The compiler could change:
for(T x : foo) { ... }
where foo is a ListT
into
for(int i=0; ifoo.size(); ++i) {
T x = foo.get(i);
}
instead of calling foo.iterator() and using Iterator methods.
-Ray
On Fri, Jun 12, 2009 at 7:31 PM, Ray Cromwellcromwell...@gmail.com
wrote:
I'm in the process of some final tweaks on GQuery, so I'll look at how
much of my private JSArray class I can move over as a patch.
One possibility for avoiding Iterator object creation without using
flyweights is to introduce a new Iterator type which contains methods
which are parameterized by the collection and which use my Extension
Method/Category method JSO trick.
public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS list) {
return (FastIteratorS)(GWT.isScript() ? makeWeb() :
makeHosted());
}
private final native FastIterator makeWeb() /*-{
return 0;
}-*/;
private final native FastIterator makeHosted() /*-{
return [0];
}-*/;
public final int value() {
return GWT.isScript() ? valueWeb() : valueHosted();
}
public native int valueWeb() /*-{
return this;
}-*/;
public native int valueHosted() /*-{
return this[0];
}-*/;
public native hasNext(ListT list) {
return value() list.size();
}
public native T next(ListT list) {
return list.get(value()++); // unsure if using value() as rvalue
will work here
}
}
then you should be able to write code like
ListString foo = getList();
FastIteratorString iter = FastIterator.make(foo);
while(iter.hasNext(foo)) {
String s = iter.next(foo);
}
Why doesn't this create any additional objects? Because
'iter'/FastIterator is actually a native JS number/scalar type, and
what this is really doing is simulating the addition of
hasNext()/next() to the number's prototype.
We could dispense with the need for an additional parameter if GWT had
a magic method for allocating new local variables/symbols in the local
scope. Imagine if writing
VariableT x = GWT.createVariable(0);
was a magic method that just generated a 'var x = 0' declaration, only
it promised to always be inlined and do so in the caller's scope.
'Variable' would be a magic class that never creates fields on the
actual object themselves and are pruned/removed at runtime.
Then you could have FastIterator impersonate a reference to the
underlying ListT, and rewrite hasNext()/next() as:
VariableInt x = GWT.createVariableInt(0);
public boolean hasNext() {
return x.get() this.size();
}
public T next() {
return this.get(x.get()++); // or x.postIncrement()
}
this would produce code that would create no additional objects as
well as maintain Iterator-like interface.
-Ray
On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
wrote:
+1 Ray
Could you contribute your implementation(s)?
On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com wrote:
+1 Ray. Now here's the really tricky question. Is there any way we can
take advantage of Javascript's for (x in y) { ... } syntax (and
should we,
given its spotty performance)? My intuition tells me that the only way
we
could use it would be through a callback, because there's nothing like
.NET
generators/yield in Javascript.
On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell cromwell...@gmail.com
wrote:
My take on this is that there is many places where I'd like to avoid
JRE collections, but the basic JsArray is too much of a downgrade. I
don't mind changing it to T if it doesn't effect performance cause
then I could subclass it, but as an example of the stuff I would like
in a 'FastArrayList' that is not a collections derivative:
1) add() instead of just set(length(), item) (e.g. push)
2)
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
2009/6/16 Bruce Johnson br...@google.com I'm starting to make a bit o' progress on this. I'll send out a design doc real soon now. BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure would be easier to discuss this in a wave... No :( But if you are offering invites, send one this way :) Otherwise, its probably wise to keep the discussion in a place where all interested parties can participate. Cam --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5560 - Allow specifying an initial load sequence for runAsync calls
Author: sp...@google.com
Date: Mon Jun 15 17:20:03 2009
New Revision: 5560
Added:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/JsniRefLookup.java
(contents, props changed)
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/SplitPointRecorder.java
trunk/dev/core/src/com/google/gwt/core/linker/SoycReportLinker.java
trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
trunk/user/src/com/google/gwt/core/CompilerParameters.gwt.xml
trunk/user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java
Log:
Allow specifying an initial load sequence for runAsync calls
in an application's gwt.xml file. If the specified sequence
matches the actual order the runAsync's are reached at
run time, then the load time is improved because the leftovers
fragment can be loaded later than otherwise. If the load
order is incorrect, the program still runs, but it
will likely be slowed down.
Review by: bobv
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/SplitPointRecorder.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/SplitPointRecorder.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/SplitPointRecorder.java
Mon Jun 15 17:20:03 2009
@@ -16,8 +16,11 @@
package com.google.gwt.core.ext.soyc.impl;
import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.dev.jjs.ast.JMethod;
import com.google.gwt.dev.jjs.ast.JProgram;
+import com.google.gwt.dev.jjs.impl.ReplaceRunAsyncs.RunAsyncReplacement;
import com.google.gwt.dev.util.HtmlTextOutput;
+import com.google.gwt.dev.util.collect.HashMap;
import com.google.gwt.util.tools.Utility;
import java.io.OutputStream;
@@ -30,18 +33,13 @@
* Records split points to a file for SOYC reports.
*/
public class SplitPointRecorder {
-
/**
* Used to record (runAsync) split points of a program.
- *
- * @param jprogram
- * @param out
- * @param logger
*/
public static void recordSplitPoints(JProgram jprogram, OutputStream out,
TreeLogger logger) {
-logger = logger.branch(TreeLogger.INFO,
+logger = logger.branch(TreeLogger.TRACE,
Creating Split Point Map file for SOYC);
try {
@@ -59,19 +57,22 @@
htmlOut.indentIn();
htmlOut.indentIn();
- MapInteger, String splitPointMap = jprogram.getSplitPointMap();
+ MapInteger, String splitPointMap = splitPointNames(jprogram);
if (splitPointMap.size() 0) {
curLine = splitpoints;
htmlOut.printRaw(curLine);
htmlOut.newline();
htmlOut.indentIn();
htmlOut.indentIn();
-for (Map.EntryInteger, String entry : splitPointMap.entrySet()) {
- Integer splitPointCount = entry.getKey();
- curLine = splitpoint id=\ + splitPointCount + \
location=\
- + entry.getValue() + \/;
+for (int sp = 1; sp = splitPointMap.size(); sp++) {
+ String location = splitPointMap.get(sp);
+ assert location != null;
+ curLine = splitpoint id=\ + sp + \ location=\ + location
+ + \/;
htmlOut.printRaw(curLine);
htmlOut.newline();
+ logger.log(TreeLogger.TRACE, Assigning split point # + sp
+ + in method + location);
}
htmlOut.indentOut();
htmlOut.indentOut();
@@ -94,6 +95,33 @@
} catch (Throwable e) {
logger.log(TreeLogger.ERROR, Could not open dependency file., e);
}
+ }
+
+ private static String fullMethodDescription(JMethod method) {
+return (method.getEnclosingType().getName() + . +
JProgram.getJsniSig(method));
+ }
+
+ /**
+ * Choose human-readable names for the split points.
+ */
+ private static MapInteger, String splitPointNames(JProgram program) {
+MapInteger, String names = new HashMapInteger, String();
+MapString, Integer counts = new HashMapString, Integer();
+for (RunAsyncReplacement replacement :
program.getRunAsyncReplacements().values()) {
+ int entryNumber = replacement.getNumber();
+ String methodDescription =
fullMethodDescription(replacement.getEnclosingMethod());
+ if (counts.containsKey(methodDescription)) {
+counts.put(methodDescription, counts.get(methodDescription) + 1);
+methodDescription += #
++ Integer.toString(counts.get(methodDescription));
+ } else {
+counts.put(methodDescription, 1);
+ }
+
+ names.put(entryNumber, methodDescription);
+}
+
+return names;
}
private SplitPointRecorder() {
Modified:
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
I do, cromwellian is my id on the sandbox.
-Ray
On Mon, Jun 15, 2009 at 6:14 PM, Bruce Johnsonbr...@google.com wrote:
I'm starting to make a bit o' progress on this. I'll send out a design doc
real soon now.
BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure
would be easier to discuss this in a wave...
On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein haust...@google.com
wrote:
Ray,
I think we can improve the class over time -- any reasonable starting
point (even without iterators or with non-optimal iterators) would help
significantly.
Stefan
On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell cromwell...@gmail.com
wrote:
BTW, the last proposal is very unsafe with some form of escape
analysis since it is unsafe to pass references to classes which
reference local scope to other scopes. Another possibility is a form
of 'destructuring' of Iterator classes by inlining them completely
into local scope vs escape analysis and then forgoing separate
construction.
A simpler way to maintain for-each with JRE collections without
creating objects is to change the way that for-each deals with
IterableT when T is a List.
The compiler could change:
for(T x : foo) { ... }
where foo is a ListT
into
for(int i=0; ifoo.size(); ++i) {
T x = foo.get(i);
}
instead of calling foo.iterator() and using Iterator methods.
-Ray
On Fri, Jun 12, 2009 at 7:31 PM, Ray Cromwellcromwell...@gmail.com
wrote:
I'm in the process of some final tweaks on GQuery, so I'll look at how
much of my private JSArray class I can move over as a patch.
One possibility for avoiding Iterator object creation without using
flyweights is to introduce a new Iterator type which contains methods
which are parameterized by the collection and which use my Extension
Method/Category method JSO trick.
public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS list) {
return (FastIteratorS)(GWT.isScript() ? makeWeb() :
makeHosted());
}
private final native FastIterator makeWeb() /*-{
return 0;
}-*/;
private final native FastIterator makeHosted() /*-{
return [0];
}-*/;
public final int value() {
return GWT.isScript() ? valueWeb() : valueHosted();
}
public native int valueWeb() /*-{
return this;
}-*/;
public native int valueHosted() /*-{
return this[0];
}-*/;
public native hasNext(ListT list) {
return value() list.size();
}
public native T next(ListT list) {
return list.get(value()++); // unsure if using value() as rvalue
will work here
}
}
then you should be able to write code like
ListString foo = getList();
FastIteratorString iter = FastIterator.make(foo);
while(iter.hasNext(foo)) {
String s = iter.next(foo);
}
Why doesn't this create any additional objects? Because
'iter'/FastIterator is actually a native JS number/scalar type, and
what this is really doing is simulating the addition of
hasNext()/next() to the number's prototype.
We could dispense with the need for an additional parameter if GWT had
a magic method for allocating new local variables/symbols in the local
scope. Imagine if writing
VariableT x = GWT.createVariable(0);
was a magic method that just generated a 'var x = 0' declaration, only
it promised to always be inlined and do so in the caller's scope.
'Variable' would be a magic class that never creates fields on the
actual object themselves and are pruned/removed at runtime.
Then you could have FastIterator impersonate a reference to the
underlying ListT, and rewrite hasNext()/next() as:
VariableInt x = GWT.createVariableInt(0);
public boolean hasNext() {
return x.get() this.size();
}
public T next() {
return this.get(x.get()++); // or x.postIncrement()
}
this would produce code that would create no additional objects as
well as maintain Iterator-like interface.
-Ray
On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
wrote:
+1 Ray
Could you contribute your implementation(s)?
On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com wrote:
+1 Ray. Now here's the really tricky question. Is there any way we
can
take advantage of Javascript's for (x in y) { ... } syntax (and
should we,
given its spotty performance)? My intuition tells me that the only
way we
could use it would be through a callback, because there's nothing
like .NET
generators/yield in Javascript.
On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell cromwell...@gmail.com
wrote:
My take on this is that there is many places where I'd like to avoid
JRE collections, but the basic JsArray is too much of a downgrade. I
don't mind changing it to T if it doesn't effect performance cause
then I could subclass it, but as an example of the stuff I would
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
I do as well - I'm mmastrac.
On 15-Jun-09, at 8:02 PM, Ray Cromwell wrote:
I do, cromwellian is my id on the sandbox.
-Ray
On Mon, Jun 15, 2009 at 6:14 PM, Bruce Johnsonbr...@google.com
wrote:
I'm starting to make a bit o' progress on this. I'll send out a
design doc
real soon now.
BTW, anyone on the Contributors list here have Wave sandbox
accounts? Sure
would be easier to discuss this in a wave...
On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein
haust...@google.com
wrote:
Ray,
I think we can improve the class over time -- any reasonable
starting
point (even without iterators or with non-optimal iterators) would
help
significantly.
Stefan
On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell
cromwell...@gmail.com
wrote:
BTW, the last proposal is very unsafe with some form of escape
analysis since it is unsafe to pass references to classes which
reference local scope to other scopes. Another possibility is a
form
of 'destructuring' of Iterator classes by inlining them completely
into local scope vs escape analysis and then forgoing separate
construction.
A simpler way to maintain for-each with JRE collections without
creating objects is to change the way that for-each deals with
IterableT when T is a List.
The compiler could change:
for(T x : foo) { ... }
where foo is a ListT
into
for(int i=0; ifoo.size(); ++i) {
T x = foo.get(i);
}
instead of calling foo.iterator() and using Iterator methods.
-Ray
On Fri, Jun 12, 2009 at 7:31 PM, Ray
Cromwellcromwell...@gmail.com
wrote:
I'm in the process of some final tweaks on GQuery, so I'll look
at how
much of my private JSArray class I can move over as a patch.
One possibility for avoiding Iterator object creation without
using
flyweights is to introduce a new Iterator type which contains
methods
which are parameterized by the collection and which use my
Extension
Method/Category method JSO trick.
public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS list) {
return (FastIteratorS)(GWT.isScript() ? makeWeb() :
makeHosted());
}
private final native FastIterator makeWeb() /*-{
return 0;
}-*/;
private final native FastIterator makeHosted() /*-{
return [0];
}-*/;
public final int value() {
return GWT.isScript() ? valueWeb() : valueHosted();
}
public native int valueWeb() /*-{
return this;
}-*/;
public native int valueHosted() /*-{
return this[0];
}-*/;
public native hasNext(ListT list) {
return value() list.size();
}
public native T next(ListT list) {
return list.get(value()++); // unsure if using value() as
rvalue
will work here
}
}
then you should be able to write code like
ListString foo = getList();
FastIteratorString iter = FastIterator.make(foo);
while(iter.hasNext(foo)) {
String s = iter.next(foo);
}
Why doesn't this create any additional objects? Because
'iter'/FastIterator is actually a native JS number/scalar type,
and
what this is really doing is simulating the addition of
hasNext()/next() to the number's prototype.
We could dispense with the need for an additional parameter if
GWT had
a magic method for allocating new local variables/symbols in the
local
scope. Imagine if writing
VariableT x = GWT.createVariable(0);
was a magic method that just generated a 'var x = 0'
declaration, only
it promised to always be inlined and do so in the caller's scope.
'Variable' would be a magic class that never creates fields on the
actual object themselves and are pruned/removed at runtime.
Then you could have FastIterator impersonate a reference to the
underlying ListT, and rewrite hasNext()/next() as:
VariableInt x = GWT.createVariableInt(0);
public boolean hasNext() {
return x.get() this.size();
}
public T next() {
return this.get(x.get()++); // or x.postIncrement()
}
this would produce code that would create no additional objects as
well as maintain Iterator-like interface.
-Ray
On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
wrote:
+1 Ray
Could you contribute your implementation(s)?
On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com
wrote:
+1 Ray. Now here's the really tricky question. Is there any
way we
can
take advantage of Javascript's for (x in y) { ... } syntax
(and
should we,
given its spotty performance)? My intuition tells me that the
only
way we
could use it would be through a callback, because there's
nothing
like .NET
generators/yield in Javascript.
On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell cromwell...@gmail.com
wrote:
My take on this is that there is many places where I'd like
to avoid
JRE collections, but the basic JsArray is too much of a
downgrade. I
don't mind changing it to T if it doesn't effect
performance cause
then I
[gwt-contrib] [google-web-toolkit commit] r5562 - Edited wiki page through web user interface.
Author: fabb...@google.com
Date: Mon Jun 15 19:57:26 2009
New Revision: 5562
Modified:
wiki/DefaultLocaleBinding.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/DefaultLocaleBinding.wiki
==
--- wiki/DefaultLocaleBinding.wiki (original)
+++ wiki/DefaultLocaleBinding.wiki Mon Jun 15 19:57:26 2009
@@ -13,7 +13,7 @@
= Usage Specification =
-I propose adding configuration property to I18N.gwt.xml, for
default.locale. It's a configuration property because it isn't used for
permutations; indeed, it shouldn't ever have multiple values. This would
be set to default by I18N.gwt.xml, but should be reset by user modules to
whatever locale they want to have as their default.
+I propose adding a new XML element, `set-property-fallback
name=_propname_ value=_fallbackvalue_/`. I18N.gwt.xml would set the
fallback for `locale` to default by I18N.gwt.xml, but should be reset by
user modules to whatever locale they want to have as their default.
So, I18N.gwt.xml would contain:
{{{
@@ -21,27 +21,37 @@
!-- 'default' is always defined, but might not be set if--
!-- default.locale is used to specify an actual locale as default. --
define-property name=locale values=default /
- define-configuration-property name=default.locale
is-multi-valued=false/
- set-configuration-property name=default.locale value=default/
+ set-property-fallback name=locale value=default/
}}}
And my hypothetical app's .gwt.xml would contain:
{{{
extend-property name=locale values=fr_CA,de /
- set-configuration-property name=default.locale value=fr_CA /
+ set-property-fallback name=locale value=fr_CA /
}}}
= Implementation Requirements =
-The `AbstractLocalizableImpleCreator` code has to recognize generators
that operate only on default, and decide based on whether
`default.locale` is or is not set and whether default is or is not in the
locales list whether and when to run a given generator; in this example,
the fr_CA permutation would run generators that run on all locales,
on fr_CA _or_ on default. This requires access not to the defined
values (from `define-property` and `extend-property`), but to the set
values, which is currently inaccessible.
+The fallback value would be stored in a new filed of `BindingProperty`,
with a public getter, default setter, and default value of . The
interesting changes happen in the property provider, which would use a
template syntax in the property provider !JavaScript and
`getPropertyProvider()` would do template substitution, so that a property
provider of
-More interesting changes happen in the property provider, which today can
access only selection properties _with multiple values_. The default
locale should not be multiple, which is one reason I suggest it as a
configuration property. I propose giving property providers access to
configuration properties as well, using a template syntax in the property
provider !JavaScript and token substitution in `SelectionScriptLinker`,
something like this fragment from I18n.gwt.xml:
+{{{
+ while (!__gwt_isKnownPropertyValue(locale, locale)) {
+var lastIndex = locale.lastIndexOf(_);
+if (lastIndex == -1) {
+ locale = /*-FALLBACK*/;
+ break;
+} else {
+ locale = locale.substring(0,lastIndex);
+}
+ }
+}}}
+Would become, for my hypothetical app,
{{{
while (!__gwt_isKnownPropertyValue(locale, locale)) {
var lastIndex = locale.lastIndexOf(_);
if (lastIndex == -1) {
- locale = /*-GWTCONFIGPROPERTY(default.locale)-*/;
+ locale = fa_CA;
break;
} else {
locale = locale.substring(0,lastIndex);
@@ -49,6 +59,8 @@
}
}}}
-Note that this is a static substitution, because configuration properties
have fixed value, unlike selection properties. The substitution is used in
generated the selection script, so a request for locale jp will fail to
match known property values and be assigned fr_CA instead, as the
requested `default.locale`.
+Note that this is a static substitution, at compile time. The
substitution is used in generated the selection script, so a request for
locale jp will fail to match known property values and be
assigned fr_CA instead, as the requested fallback.
+
+Also note that the substitution token is, if somehow seen by
naive !JavaScript, merely a comment (much as JSNI is for Java code). In
this particular example, moreover, the token is inside a string literal, so
a naive interpreter would merely see a very odd-looking (and in fact
invalid) locale string.
-Also note that the substitution token is, if seen by naive !JavaScript,
merely a comment (much as JSNI is for Java code). In this particular
example, moreover, the token is inside a string
[gwt-contrib] Re: i18n support for concrete default locale
Revision to the concept, for design review: See
http://code.google.com/p/google-web-toolkit/wiki/DefaultLocaleBinding, but
the short-and-sweet is:
- Introduction of XML tag set-property-fallback name=*propname*
value=*fallbackString*/. It's fine, and expected, to set this zero,
one, or many times for any given property.
- A new field gets added in BindingProperty, with setter and getter, and
a default value of empty string
- getPropertyProvider() is rewritten to return, not the literal property
provider string, but the result of replacing all instances of /*-FALLBACK-*/
with the fallback string, whether empty or otherwise.
- For my default locale use case, our I18N.gwt.xml sets the locale
fallback to default, and user code sets it to something real if the user
doesn't like that.
On Wed, Jun 10, 2009 at 11:49 AM, Freeland Abbott fabb...@google.comwrote:
Yes, he and I already discussed it. I was initially trying to avoid
needing a new XML tag when the existing one was such a near fit, but the
legacy linker support issues convinced me we needed it.
On Tue, Jun 9, 2009 at 5:37 PM, Bruce Johnson br...@google.com wrote:
I like what jat said. Freeland?
On Tue, Jun 9, 2009 at 5:33 PM, j...@google.com wrote:
The alternative to this would be Bruce's suggestion of defining a
specific fallback value for a selection property rather than using
config properties for it. That would narrow the scope to exactly what
we know we want to support and simplify the linker changes and avoids
the breaking API change for existing linkers (where they have to supply
the config properties to avoid breaking, which means the same linker
can't work for GWT 1.6 and GWT 2.0).
Something like:
set-property-fallback name=locale value=default/
and the last set value wins.
http://gwt-code-reviews.appspot.com/34832/diff/1/2
File
dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
(right):
http://gwt-code-reviews.appspot.com/34832/diff/1/2#newcode194
Line 194: new TreeSetConfigurationProperty());
It seems like allowing this could cause incorrect behavior. I know it
is a tradeoff of not breaking existing code, but if there is a linker
which calls this method, any code depending on config property lookup
will just break.
http://gwt-code-reviews.appspot.com/34832/diff/1/2#newcode223
Line 223: }
It looks like we are just substituting the empty string for unknown
properties, which is especially bad if the call is relayed through the
above method.
http://gwt-code-reviews.appspot.com/34832/diff/1/4
File dev/core/src/com/google/gwt/dev/cfg/StaticPropertyOracle.java
(right):
http://gwt-code-reviews.appspot.com/34832/diff/1/4#newcode149
Line 149: for (String v : prop.getAllowedValues()) {
setValues.addAll(cprop.getAllowedValues())?
Also, maybe this should be computed in getPossibleValues() instead.
http://gwt-code-reviews.appspot.com/34832/diff/1/5
File
dev/core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java
(right):
http://gwt-code-reviews.appspot.com/34832/diff/1/5#newcode127
Line 127: for (String v : cprop.getAllowedValues()) {
setValues.addAll(cprop.getAllowedValues())?
Also, maybe this should be computed in getPossibleValues() instead.
http://gwt-code-reviews.appspot.com/34832/diff/1/7
File user/src/com/google/gwt/i18n/I18N.gwt.xml (right):
http://gwt-code-reviews.appspot.com/34832/diff/1/7#newcode51
Line 51: $wnd['__gwt_Locale'] = locale ||
'/*-GWTCONFIGPROP(default.locale)-*/';
I think we haven't nailed this down enough that we want anyone else
using it and expecting it to keep working. So, I would suggest a
comment here to that effect.
http://gwt-code-reviews.appspot.com/34832/diff/1/7#newcode55
Line 55: return /*-GWTCONFIGPROP(default.locale)-*/;
Since these can all be empty strings, I would suggest storing
/*-GWTCONFIGPROP(default.locale)-*/ || 'default' in a variable and
reusing that. Things will fall over if the property provider returns a
value that is not valid.
http://gwt-code-reviews.appspot.com/34832/diff/1/8
File
user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java
(right):
http://gwt-code-reviews.appspot.com/34832/diff/1/8#newcode136
Line 136: logger.log(Type.WARN, default.locale has more than one value,
using
Is this even possible since the config property definition says it isn't
multivalued?
http://gwt-code-reviews.appspot.com/34832
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Reducing noise in GWT compiler output
We've known for a while that the GWT compiler is spammy, even at default log levels. There is a reason for this behavior, believe it or not: TypeOracle's JClassType#getSubtypes() call. Because generators can ask for the subtypes of any type, the compiler has to parse essentially everything, not just those types that are statically reachable from a module's entry point(s). We sometimes refer to it as speculative parsing. Overall, the behavior is vitally useful for code generators, especially RPC and I18n, and it's generally useful anytime you need to do something factory-like, where you might have used Class.forName() if it were available. So, I'm not proposing that we change that behavior. The problem is that in the process of speculatively parsing everything on the client source path, inevitably we end up encountering source files that can't actually be meaninfully compiled given the current client source path and other various reasons for mismatches. It can happen when you have more than one module.gwt.xml in the same location with different sets of inherited modules. We ought to find a way to keep quieter about problems we find during that speculative parse. We want to *not* spam the log when the source file was found speculatively but definitely still report errors when they really are relevant to getting a clean compile. This isn't as simple as it might sound. It isn't just a how do we code it question. Imagine you have a GWT module that needs RPC. Because RPC can use polymorphism, you might have an RPC method whose return type is Shape (vs. concrete subtypes Circle, Square, Triangle). This is handled magically in the GWT RPC generator because it can see those subtypes of Shape and quietly generate deserializers in the generated RPC proxy. The tricky bit is when Circle.java has a syntax error, say. The type Circle won't be found as a subtype of Shape in the type oracle, so the GWT RPC generator won't know to emit a deserializer for it. (To be precise, it won't even know that it *ought* to try to do so.) We have a choice: either we emit a string of non-fatal errors regarding the failure to parse Circle.java or we don't. If we do, we get the spam we hate today, but at least we've informed the developer that something fishy may happen, since it wasn't a perfectly clean compile. If we don't emit such errors, then a module will quietly appear to compile, even when there are compilation problems that might affect the intended behavior (in this case, when a server responds to the client with a Circle object, the client won't know how to deserialize it). All that said, I don't think it will be big a problem in practice if we log less and risk the kind of surprise failure I described with something like RPC. After all, javac (or your IDE) would complain about Cirlce.java not compiling anyway, so the only real failure mode happens if you *only* compile with the GWT compiler -- and that seems pretty unlikely, especially if you're working in an IDE. Here's a proposal for the new behavior. When the GWT compile invokes JDT to do the front-end compile, capture the errors in an in-memory data structure (keyed by type name?) but do not log them right away. After the JDT front-end compile settles, create a set of known statically reachable types from the entry point classes (the entry point classes are reachable from themselves by definition). Only log errors on compilation unit in that set of dependencies, and do not log errors in an other case. Anybody see any problems with this idea? I think this would omit log messages that make you say, What on earth does NumberFormat_fr_Test.java have to do with my compiling Hello.java? -- Bruce --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Reducing noise in GWT compiler output
On Mon, Jun 15, 2009 at 11:11 PM, Bruce Johnson br...@google.com wrote: We've known for a while that the GWT compiler is spammy, even at default log levels. There is a reason for this behavior, believe it or not: TypeOracle's JClassType#getSubtypes() call. Because generators can ask for the subtypes of any type, the compiler has to parse essentially everything, not just those types that are statically reachable from a module's entry point(s). We sometimes refer to it as speculative parsing. Overall, the behavior is vitally useful for code generators, especially RPC and I18n, and it's generally useful anytime you need to do something factory-like, where you might have used Class.forName() if it were available. So, I'm not proposing that we change that behavior. The problem is that in the process of speculatively parsing everything on the client source path, inevitably we end up encountering source files that can't actually be meaninfully compiled given the current client source path and other various reasons for mismatches. It can happen when you have more than one module.gwt.xml in the same location with different sets of inherited modules. We ought to find a way to keep quieter about problems we find during that speculative parse. We want to *not* spam the log when the source file was found speculatively but definitely still report errors when they really are relevant to getting a clean compile. This isn't as simple as it might sound. It isn't just a how do we code it question. Imagine you have a GWT module that needs RPC. Because RPC can use polymorphism, you might have an RPC method whose return type is Shape (vs. concrete subtypes Circle, Square, Triangle). This is handled magically in the GWT RPC generator because it can see those subtypes of Shape and quietly generate deserializers in the generated RPC proxy. The tricky bit is when Circle.java has a syntax error, say. The type Circle won't be found as a subtype of Shape in the type oracle, so the GWT RPC generator won't know to emit a deserializer for it. (To be precise, it won't even know that it *ought* to try to do so.) We have a choice: either we emit a string of non-fatal errors regarding the failure to parse Circle.java or we don't. If we do, we get the spam we hate today, but at least we've informed the developer that something fishy may happen, since it wasn't a perfectly clean compile. If we don't emit such errors, then a module will quietly appear to compile, even when there are compilation problems that might affect the intended behavior (in this case, when a server responds to the client with a Circle object, the client won't know how to deserialize it). All that said, I don't think it will be big a problem in practice if we log less and risk the kind of surprise failure I described with something like RPC. After all, javac (or your IDE) would complain about Cirlce.java not compiling anyway, so the only real failure mode happens if you *only* compile with the GWT compiler -- and that seems pretty unlikely, especially if you're working in an IDE. Here's a proposal for the new behavior. When the GWT compile invokes JDT to do the front-end compile, capture the errors in an in-memory data structure (keyed by type name?) but do not log them right away. After the JDT front-end compile settles, create a set of known statically reachable types from the entry point classes (the entry point classes are reachable from themselves by definition). Only log errors on compilation unit in that set of dependencies, and do not log errors in an other case. Anybody see any problems with this idea? I think this would omit log messages that make you say, What on earth does NumberFormat_fr_Test.java have to do with my compiling Hello.java? How does that fit with instant hosted mode? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Reducing noise in GWT compiler output
+1 from me; I did a similar thing in STOB with regard to non-serializable types. I also think---though I don't have data to prove---that we often get spam from classes that happen to be on the classpath, but could be provably *not* reachable (even by things like RPC polymorphism), for example from server-only classes. I was hoping to get around to doing something like my STOB work, such that problems during speculative scanning would result in a tombstone class definition, and an actual error message only if that tombstone were later referenced. That's a provably correct, and less spammy than we are now. If you wanted to be very fancy, you could add a verbosity or warnings-control flag to choose that and your may-give-false-positives case... I think we've rejected warning-suppression flags a while ago, but I'm not sure it's the right call. On Mon, Jun 15, 2009 at 11:11 PM, Bruce Johnson br...@google.com wrote: We've known for a while that the GWT compiler is spammy, even at default log levels. There is a reason for this behavior, believe it or not: TypeOracle's JClassType#getSubtypes() call. Because generators can ask for the subtypes of any type, the compiler has to parse essentially everything, not just those types that are statically reachable from a module's entry point(s). We sometimes refer to it as speculative parsing. Overall, the behavior is vitally useful for code generators, especially RPC and I18n, and it's generally useful anytime you need to do something factory-like, where you might have used Class.forName() if it were available. So, I'm not proposing that we change that behavior. The problem is that in the process of speculatively parsing everything on the client source path, inevitably we end up encountering source files that can't actually be meaninfully compiled given the current client source path and other various reasons for mismatches. It can happen when you have more than one module.gwt.xml in the same location with different sets of inherited modules. We ought to find a way to keep quieter about problems we find during that speculative parse. We want to *not* spam the log when the source file was found speculatively but definitely still report errors when they really are relevant to getting a clean compile. This isn't as simple as it might sound. It isn't just a how do we code it question. Imagine you have a GWT module that needs RPC. Because RPC can use polymorphism, you might have an RPC method whose return type is Shape (vs. concrete subtypes Circle, Square, Triangle). This is handled magically in the GWT RPC generator because it can see those subtypes of Shape and quietly generate deserializers in the generated RPC proxy. The tricky bit is when Circle.java has a syntax error, say. The type Circle won't be found as a subtype of Shape in the type oracle, so the GWT RPC generator won't know to emit a deserializer for it. (To be precise, it won't even know that it *ought* to try to do so.) We have a choice: either we emit a string of non-fatal errors regarding the failure to parse Circle.java or we don't. If we do, we get the spam we hate today, but at least we've informed the developer that something fishy may happen, since it wasn't a perfectly clean compile. If we don't emit such errors, then a module will quietly appear to compile, even when there are compilation problems that might affect the intended behavior (in this case, when a server responds to the client with a Circle object, the client won't know how to deserialize it). All that said, I don't think it will be big a problem in practice if we log less and risk the kind of surprise failure I described with something like RPC. After all, javac (or your IDE) would complain about Cirlce.java not compiling anyway, so the only real failure mode happens if you *only* compile with the GWT compiler -- and that seems pretty unlikely, especially if you're working in an IDE. Here's a proposal for the new behavior. When the GWT compile invokes JDT to do the front-end compile, capture the errors in an in-memory data structure (keyed by type name?) but do not log them right away. After the JDT front-end compile settles, create a set of known statically reachable types from the entry point classes (the entry point classes are reachable from themselves by definition). Only log errors on compilation unit in that set of dependencies, and do not log errors in an other case. Anybody see any problems with this idea? I think this would omit log messages that make you say, What on earth does NumberFormat_fr_Test.java have to do with my compiling Hello.java? -- Bruce --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speed up compilation by rewriting for loops to avoid iterators
Would it not be possible to store the Unified/Precompiled/Unoptimized AST to disk and then you'd only have to JDT-reparse any classes that changed? Or use, was it Toby?'s, old idea of tunneling compiler information in .class files on disk (e.g. have the GWT compiler store the AST as some extra segment of the .class file)? Is this how Instant Hosted Mode works? If so, can't it be used for web-mode compiles as well? -Ray On Mon, Jun 8, 2009 at 10:41 AM, Lex Spoonsp...@google.com wrote: On Fri, Jun 5, 2009 at 6:27 PM, Ian Petersenispet...@gmail.com wrote: 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. Sounds good to me. It works even better if there is a non-optimizing mode. A non-optimizing, always on compiler could really scream. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5537 - Ant rework for speed:
Ping. Bob, I think you had special interest in this one. ;-) On Mon, Jun 15, 2009 at 1:27 PM, Freeland Abbott fabb...@google.com wrote: Bob notes that dist-dev doesn't need (and thus shouldn't have) its dependency on tools. I take that as tacit agreement that dist-dev can be the minimally build everything for test execution name. On Mon, Jun 15, 2009 at 11:53 AM, Freeland Abbott fabb...@google.comwrote: Bob, John, can you review? This doesn't address the buildonly or dist-dev as precursor to user/test question, but I think addresses Thomas' and Bob's other issue. On Mon, Jun 15, 2009 at 11:47 AM, Freeland Abbott fabb...@google.comwrote: +GWTC With regard to the Mac looking for gwt-dev-linux, since I don't literally see a build-dev target, what's the chain above the line you cited? I thought my fixes to property.ensure in e.g. user/build.xml line 47 addressed that, and I see I missed some (in doc, samples, and soyc-vis... only the last of which is likely to be stopping you, though). With regard to using buildonly as precursor to tests, I think you want to the target dist-dev, though I'm open to suggestions for how this should work. It used to be that: 1. we had both build and dist, as separate targets (unchanged), 2. tests effectively require a distribution to run in (unchanged), 3. we had buildonly, but did not have dist-dev, so the two were blurred explicitly (changed), 4. build depended, by way of -do, on dist, which I found confusingly backwards (changed), 5. top-level test depended on build, which depended on dist as above (changed to depend on dist-one, but should probably be dist-dev instead now that it exists), 6. build was the default target, which as above worked because it ran dist as a dependency (changed; dist is project default target, and depends on build). Solutions: 1. Do we want buildonly to imply dist-dev? Do we want build to imply dist? My intuition is no, that if separate, build builds and dist packages and dist needs build (but not vice-versa). That is semantic a change from before, though. 2. If not, then we want to retrain ourselves to use dist-dev at least once, to get the distro set, even if you then use buildonly after that to refresh sources? On Mon, Jun 15, 2009 at 11:10 AM, Freeland Abbott fabb...@google.comwrote: Thanks, I'll revisit. On Mon, Jun 15, 2009 at 10:43 AM, BobV b...@google.com wrote: This no longer correctly works on mac platform. ant buildonly cd user ant test /Users/bob/gwt/trunk/common.ant.xml:299: GWT must be built before performing any tests. This can be fixed by running ant in the /Users/bob/gwt/trunk directory. also, the ant build-dev target fails: /Users/bob/gwt/trunk/common.ant.xml:299: Cannot find dependency /Users/bob/gwt/trunk/build/lib/gwt-dev-linux.jar -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
