[gwt-contrib] [google-web-toolkit commit] r5491 - Merge r5487 and r5490 into the snapshot branch.
Author: j...@google.com
Date: Mon Jun 1 23:11:52 2009
New Revision: 5491
Modified:
branches/snapshot-2009.05.12-r5406/branch-info.txt
branches/snapshot-2009.05.12-r5406/user/src/com/google/gwt/i18n/client/Dictionary.java
branches/snapshot-2009.05.12-r5406/user/super/com/google/gwt/emul/java/util/Date.java
branches/snapshot-2009.05.12-r5406/user/test/com/google/gwt/emultest/java/util/DateTest.java
branches/snapshot-2009.05.12-r5406/user/test/com/google/gwt/i18n/client/I18NTest.java
Log:
Merge r5487 and r5490 into the snapshot branch.
/trunk c5487 was merged into this branch (MissingResourceException diag
info)
svn merge -c5487 https://google-web-toolkit.googlecode.com/svn/trunk .
/trunk c5490 was merged into this branch (Date diag info)
svn merge -c5490 https://google-web-toolkit.googlecode.com/svn/trunk .
Patch by: jat
Review by: fabbott (TBR)
Modified: branches/snapshot-2009.05.12-r5406/branch-info.txt
==
--- branches/snapshot-2009.05.12-r5406/branch-info.txt (original)
+++ branches/snapshot-2009.05.12-r5406/branch-info.txt Mon Jun 1 23:11:52
2009
@@ -20,3 +20,7 @@
svn merge -r 5296:5295
https://google-web-toolkit.googlecode.com/svn/trunk .
svn merge -r 5293:5292
https://google-web-toolkit.googlecode.com/svn/trunk .
(had minor conflicts in CodeSplitter.java, JavaToJavaScriptCompiler.java)
+/trunk c5487 was merged into this branch (MissingResourceException diag
info)
+ svn merge -c5487 https://google-web-toolkit.googlecode.com/svn/trunk .
+/trunk c5490 was merged into this branch (Date diag info)
+ svn merge -c5490 https://google-web-toolkit.googlecode.com/svn/trunk .
Modified:
branches/snapshot-2009.05.12-r5406/user/src/com/google/gwt/i18n/client/Dictionary.java
==
---
branches/snapshot-2009.05.12-r5406/user/src/com/google/gwt/i18n/client/Dictionary.java
(original)
+++
branches/snapshot-2009.05.12-r5406/user/src/com/google/gwt/i18n/client/Dictionary.java
Mon Jun 1 23:11:52 2009
@@ -102,6 +102,7 @@
null, name);
}
+ private JavaScriptObject accessedKeys;
private JavaScriptObject dict;
private String label;
@@ -123,8 +124,13 @@
"Cannot find JavaScript object with the name '" + name + "'",
name,
null);
}
+createAccessedKeysArray();
}
+ private native void createAccessedKeysArray() /*-{
+th...@com.google.gwt.i18n.client.dictionary::accessedKeys = new
Array();
+ }-*/;
+
/**
* Get the value associated with the given Dictionary key.
*
@@ -138,6 +144,12 @@
*/
public native String get(String key) /*-{
var value = th...@com.google.gwt.i18n.client.dictionary::dict[key];
+ var keys = th...@com.google.gwt.i18n.client.dictionary::accessedKeys;
+ keys.unshift(key);
+ // only keep the last 30 elements. Shrink it when array exceeds 60
+ if (keys.length > 60) {
+ keys.splice(30);
+ }
if (value == null || !Object.prototype.hasOwnProperty.call(
th...@com.google.gwt.i18n.client.dictionary::dict, key))
{
@@ -179,6 +191,7 @@
if (s.size() < MAX_KEYS_TO_SHOW) {
error += "\n keys found: " + s;
}
+error += "\n accessed keys: " + accessedKeys;
throw new MissingResourceException(error, this.toString(), key);
}
Modified:
branches/snapshot-2009.05.12-r5406/user/super/com/google/gwt/emul/java/util/Date.java
==
---
branches/snapshot-2009.05.12-r5406/user/super/com/google/gwt/emul/java/util/Date.java
(original)
+++
branches/snapshot-2009.05.12-r5406/user/super/com/google/gwt/emul/java/util/Date.java
Mon Jun 1 23:11:52 2009
@@ -15,12 +15,21 @@
*/
package java.util;
+import com.google.gwt.core.client.JavaScriptObject;
+
import java.io.Serializable;
/**
* Represents a date and time.
*/
public class Date implements Cloneable, Comparable, Serializable {
+
+ /**
+ * JavaScript Date instance.
+ */
+ @SuppressWarnings("unused") // used from JSNI
+ private JavaScriptObject jsdate;
+
/**
* Used only by toString().
*/
@@ -88,6 +97,16 @@
return isNaN(d) ? -1 : d;
}-*/;
+ /**
+ * Throw an exception if jsdate is not an object.
+ *
+ * @param val
+ */
+ @SuppressWarnings("unused") // called by JSNI
+ private static void throwJsDateException(String val) {
+throw new IllegalStateException("jsdate is " + val);
+ }
+
private static native double utc0(int year, int month, int date, int hrs,
int min, int sec) /*-{
return Date.UTC(year + 1900, month, date, hrs, min, sec);
@@ -147,27 +166,33 @@
}
public native int getDate() /*-{
-return this.jsdate.getDate();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getDate();
}-*/;
public
[gwt-contrib] [google-web-toolkit commit] r5490 - two changes to java.util.Date in an effort to track down a very intermittent
Author: j...@google.com
Date: Mon Jun 1 22:59:06 2009
New Revision: 5490
Modified:
trunk/user/super/com/google/gwt/emul/java/util/Date.java
trunk/user/test/com/google/gwt/emultest/java/util/DateTest.java
Log:
two changes to java.util.Date in an effort to track down a very intermittent
failure on IE. IE doesn't provide useful stack traces for JS-initiated
exceptions, so all we know is that jsdate is uninitialized or not an object
at some point when it is dereferenced. The changes are:
- use a JSO field storing the JS Date object rather than
making an expando on the underlying object (which
couldn't ever work in hosted mode, but since this is a
JRE emulation class it didn't have to)
- add checks before each dereference of jsdate to see if it has been
mangled;
if so throws a Java exception so we can get a good stack trace.
This does add some overhead, but it shouldn't be too bad. This is a
temporary
change that will be removed once the cause is found.
Patch by: jat
Review by: amitmanjhi, scottb
Modified: trunk/user/super/com/google/gwt/emul/java/util/Date.java
==
--- trunk/user/super/com/google/gwt/emul/java/util/Date.java(original)
+++ trunk/user/super/com/google/gwt/emul/java/util/Date.javaMon Jun 1
22:59:06 2009
@@ -15,12 +15,21 @@
*/
package java.util;
+import com.google.gwt.core.client.JavaScriptObject;
+
import java.io.Serializable;
/**
* Represents a date and time.
*/
public class Date implements Cloneable, Comparable, Serializable {
+
+ /**
+ * JavaScript Date instance.
+ */
+ @SuppressWarnings("unused") // used from JSNI
+ private JavaScriptObject jsdate;
+
/**
* Used only by toString().
*/
@@ -88,6 +97,16 @@
return isNaN(d) ? -1 : d;
}-*/;
+ /**
+ * Throw an exception if jsdate is not an object.
+ *
+ * @param val
+ */
+ @SuppressWarnings("unused") // called by JSNI
+ private static void throwJsDateException(String val) {
+throw new IllegalStateException("jsdate is " + val);
+ }
+
private static native double utc0(int year, int month, int date, int hrs,
int min, int sec) /*-{
return Date.UTC(year + 1900, month, date, hrs, min, sec);
@@ -147,27 +166,33 @@
}
public native int getDate() /*-{
-return this.jsdate.getDate();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getDate();
}-*/;
public native int getDay() /*-{
-return this.jsdate.getDay();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getDay();
}-*/;
public native int getHours() /*-{
-return this.jsdate.getHours();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getHours();
}-*/;
public native int getMinutes() /*-{
-return this.jsdate.getMinutes();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getMinutes();
}-*/;
public native int getMonth() /*-{
-return this.jsdate.getMonth();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getMonth();
}-*/;
public native int getSeconds() /*-{
-return this.jsdate.getSeconds();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getSeconds();
}-*/;
public long getTime() {
@@ -175,11 +200,13 @@
}
public native int getTimezoneOffset() /*-{
-return this.jsdate.getTimezoneOffset();
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getTimezoneOffset();
}-*/;
public native int getYear() /*-{
-return this.jsdate.getFullYear()-1900;
+th...@java.util.date::checkJsDate()();
+return th...@java.util.date::jsdate.getFullYear()-1900;
}-*/;
@Override
@@ -188,23 +215,28 @@
}
public native void setDate(int date) /*-{
-this.jsdate.setDate(date);
+th...@java.util.date::checkJsDate()();
+th...@java.util.date::jsdate.setDate(date);
}-*/;
public native void setHours(int hours) /*-{
-this.jsdate.setHours(hours);
+th...@java.util.date::checkJsDate()();
+th...@java.util.date::jsdate.setHours(hours);
}-*/;
public native void setMinutes(int minutes) /*-{
-this.jsdate.setMinutes(minutes);
+th...@java.util.date::checkJsDate()();
+th...@java.util.date::jsdate.setMinutes(minutes);
}-*/;
public native void setMonth(int month) /*-{
-this.jsdate.setMonth(month);
+th...@java.util.date::checkJsDate()();
+th...@java.util.date::jsdate.setMonth(month);
}-*/;
public native void setSeconds(int seconds) /*-{
-this.jsdate.setSeconds(seconds);
+th...@java.util.date::checkJsDate()();
+th...@java.util.date::jsdate.setSeconds(seconds);
}-*/;
public void setTime(long time) {
@@ -212,14 +244,16 @@
}
public native void setYear(int year) /*-{
-thi
[gwt-contrib] [google-web-toolkit commit] r5489 - Note revision of "Reverted r5296 and r5293"
Author: rj...@google.com Date: Mon Jun 1 21:56:15 2009 New Revision: 5489 Modified: branches/snapshot-2009.05.12-r5406/branch-info.txt Log: Note revision of "Reverted r5296 and r5293" Modified: branches/snapshot-2009.05.12-r5406/branch-info.txt == --- branches/snapshot-2009.05.12-r5406/branch-info.txt (original) +++ branches/snapshot-2009.05.12-r5406/branch-info.txt Mon Jun 1 21:56:15 2009 @@ -16,7 +16,7 @@ /trunk c5472 was merged into this branch (ClassCircularityError on SingleJsoImpl) /trunk c5476 was merged into this branch (bug fix for r5450 and associated tests) svn merge -c5476 https://google-web-toolkit.googlecode.com/svn/trunk . -Reverted r5296 and r5293 (r) from trunk (due to aw3 latency regression): +Reverted r5296 and r5293 (r5488) from trunk (due to aw3 latency regression): svn merge -r 5296:5295 https://google-web-toolkit.googlecode.com/svn/trunk . svn merge -r 5293:5292 https://google-web-toolkit.googlecode.com/svn/trunk . (had minor conflicts in CodeSplitter.java, JavaToJavaScriptCompiler.java) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: chunk script tags into smaller ones to improve load time
Mostly LGTM, some comments.
http://gwt-code-reviews.appspot.com/33804/diff/24/30
File
dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
(right):
http://gwt-code-reviews.appspot.com/33804/diff/24/30#newcode388
Line 388: * @param modifyPrimaryJavascript(strongName) strong name of
the module being emitted
???
http://gwt-code-reviews.appspot.com/33804/diff/24/31
File
dev/core/src/com/google/gwt/core/ext/linker/impl/StandardStatementRanges.java
(right):
http://gwt-code-reviews.appspot.com/33804/diff/24/31#newcode27
Line 27: private static int[] toArray(List list) {
Danger Will Robinson: if the passed-in list is a LinkedList, this will
be N^2. I'd either use enhanced for, or else toArray() -> Integer[]
then manually unbox.
http://gwt-code-reviews.appspot.com/33804/diff/24/33
File dev/core/src/com/google/gwt/core/linker/IFrameLinker.java (right):
http://gwt-code-reviews.appspot.com/33804/diff/24/33#newcode64
Line 64: if (charsPerChunk < 0) {
Would it improve anything to short-circuit:
|| js.length() < charsPerChunk?
http://gwt-code-reviews.appspot.com/33804/diff/24/33#newcode68
Line 68: StringBuffer sb = new StringBuffer();
This should be a StringBuilder rather than a StringBuffer.
http://gwt-code-reviews.appspot.com/33804/diff/24/43
File user/src/com/google/gwt/core/CompilerParameters.gwt.xml (right):
http://gwt-code-reviews.appspot.com/33804/diff/24/43#newcode19
Line 19: This is the maximum number of variables in any var statement
GWT will emit. This avoids a bug in
Looks like this was reformatted from 80 cols to something longer?
http://gwt-code-reviews.appspot.com/33804/diff/24/44
File user/super/com/google/gwt/emul/java/lang/Class.java (right):
http://gwt-code-reviews.appspot.com/33804/diff/24/44#newcode123
Line 123: + (seedName != null ? seedName : "" + clazz.hashCode());
Unrelated change, please commit to trunk by itself; LGTM.
http://gwt-code-reviews.appspot.com/33804/diff/24/42
File user/test/com/google/gwt/emultest/EmulSuite.gwt.xml (right):
http://gwt-code-reviews.appspot.com/33804/diff/24/42#newcode25
Line 25:
Is EmulSuite the right place for these? Seems like something part of
CompilerSuite would be more appropriate; this is for JRE tests and
stuff.
http://gwt-code-reviews.appspot.com/33804
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5487 - Adding diagnostic information when a MissingResourceException is thrown.
Author: amitman...@google.com
Date: Mon Jun 1 16:12:37 2009
New Revision: 5487
Modified:
trunk/user/src/com/google/gwt/i18n/client/Dictionary.java
trunk/user/test/com/google/gwt/i18n/client/I18NTest.java
Log:
Adding diagnostic information when a MissingResourceException is thrown.
Patch by: amitmanjhi
Review by: jat
Modified: trunk/user/src/com/google/gwt/i18n/client/Dictionary.java
==
--- trunk/user/src/com/google/gwt/i18n/client/Dictionary.java (original)
+++ trunk/user/src/com/google/gwt/i18n/client/Dictionary.java Mon Jun 1
16:12:37 2009
@@ -102,6 +102,7 @@
null, name);
}
+ private JavaScriptObject accessedKeys;
private JavaScriptObject dict;
private String label;
@@ -123,8 +124,13 @@
"Cannot find JavaScript object with the name '" + name + "'",
name,
null);
}
+createAccessedKeysArray();
}
+ private native void createAccessedKeysArray() /*-{
+th...@com.google.gwt.i18n.client.dictionary::accessedKeys = new
Array();
+ }-*/;
+
/**
* Get the value associated with the given Dictionary key.
*
@@ -138,6 +144,12 @@
*/
public native String get(String key) /*-{
var value = th...@com.google.gwt.i18n.client.dictionary::dict[key];
+ var keys = th...@com.google.gwt.i18n.client.dictionary::accessedKeys;
+ keys.unshift(key);
+ // only keep the last 30 elements. Shrink it when array exceeds 60
+ if (keys.length > 60) {
+ keys.splice(30);
+ }
if (value == null || !Object.prototype.hasOwnProperty.call(
th...@com.google.gwt.i18n.client.dictionary::dict, key))
{
@@ -179,6 +191,7 @@
if (s.size() < MAX_KEYS_TO_SHOW) {
error += "\n keys found: " + s;
}
+error += "\n accessed keys: " + accessedKeys;
throw new MissingResourceException(error, this.toString(), key);
}
Modified: trunk/user/test/com/google/gwt/i18n/client/I18NTest.java
==
--- trunk/user/test/com/google/gwt/i18n/client/I18NTest.java(original)
+++ trunk/user/test/com/google/gwt/i18n/client/I18NTest.javaMon Jun 1
16:12:37 2009
@@ -421,6 +421,46 @@
assertTrue(s.contains("a"));
assertTrue(s.contains("b"));
assertFalse(s.contains("c"));
+String nonExistentKey = "nonExistentKey";
+try {
+ d.get(nonExistentKey);
+ fail("should have thrown a MissingResourceException");
+} catch (MissingResourceException ex) {
+ assertTrue(ex.getMessage(), ex.getMessage().indexOf(
+ "accessed keys: " + nonExistentKey + ",d,formattedMessage") !=
-1);
+}
+
+/*
+ * verify that accessedKeys maintains at least the last 30 entries in
the
+ * correct order. Steps involved: (i) create expectedKeys array, (ii)
access
+ * the dictionary, (iii) confirm that accessedKeys is maintained
correctly.
+ */
+// expectedKeys: nonExistentKey, 9 a's, 9 b's, 9 d's, 2
formattedMessage's
+StringBuffer expectedKeys = new StringBuffer();
+expectedKeys.append(nonExistentKey);
+for (String key : new String[] {"a", "b", "d"}) {
+ for (int i = 0; i < 9; i++) {
+expectedKeys.append(",");
+expectedKeys.append(key);
+ }
+}
+expectedKeys.append(",formattedMessage,formattedMessage");
+// access 360 keys. last 30 should match expectedKeys
+for (int i = 0; i < 10; i++) {
+ for (String key : new String[] {"formattedMessage", "d", "b", "a"}) {
+for (int j = 0; j < 9; j++) {
+ d.get(key);
+}
+ }
+}
+try {
+ d.get(nonExistentKey);
+ fail("should have thrown a MissingResourceException");
+} catch (MissingResourceException ex) {
+ assertTrue(ex.getMessage(), ex.getMessage().indexOf(
+ "accessed keys: " + expectedKeys.toString()) != -1);
+}
+
Collection s2 = d.values();
assertTrue(s2.contains("A"));
assertTrue(s2.contains("B"));
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5486 - Fixes a spurious NPE during a web mode rebind failure.
Author: sco...@google.com
Date: Mon Jun 1 15:17:17 2009
New Revision: 5486
Modified:
trunk/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
Log:
Fixes a spurious NPE during a web mode rebind failure.
Found by: rdamazio
Review by: spoon (desk)
Modified:
trunk/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
Mon Jun 1 15:17:17 2009
@@ -192,6 +192,7 @@
} catch (UnableToCompleteException e) {
FindDeferredBindingSitesVisitor.reportRebindProblem(site,
"Failed to resolve '" + reqType + "' via deferred binding");
+rebindAnswers.put(reqType, new String[0]);
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Adding diagnostic information to MissingResourceException bug
One minor nit and one concern. http://gwt-code-reviews.appspot.com/33838/diff/1/2 File user/src/com/google/gwt/i18n/client/Dictionary.java (right): http://gwt-code-reviews.appspot.com/33838/diff/1/2#newcode131 Line 131: th...@com.google.gwt.i18n.client.dictionary::accessedKeys = new Array(); Any reason this isn't just [] instead of new Array()? http://gwt-code-reviews.appspot.com/33838/diff/1/2#newcode147 Line 147: th...@com.google.gwt.i18n.client.dictionary::accessedKeys.push(key); I worry about how big this could potentially get. What if the same key is accessed many times? Perhaps it would be better to keep only the last n keys. http://gwt-code-reviews.appspot.com/33838 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Adding diagnostic information to MissingResourceException bug
Reviewers: jat,
Please review this at http://gwt-code-reviews.appspot.com/33838
Affected files:
user/src/com/google/gwt/i18n/client/Dictionary.java
user/test/com/google/gwt/i18n/client/I18NTest.java
Index: user/src/com/google/gwt/i18n/client/Dictionary.java
--- user/src/com/google/gwt/i18n/client/Dictionary.java (revision 1403)
+++ user/src/com/google/gwt/i18n/client/Dictionary.java (working copy)
@@ -102,6 +102,7 @@ public final class Dictionary {
null, name);
}
+ private JavaScriptObject accessedKeys;
private JavaScriptObject dict;
private String label;
@@ -123,8 +124,13 @@ public final class Dictionary {
"Cannot find JavaScript object with the name '" + name + "'",
name,
null);
}
+createAccessedKeysArray();
}
+ private native void createAccessedKeysArray() /*-{
+th...@com.google.gwt.i18n.client.dictionary::accessedKeys = new
Array();
+ }-*/;
+
/**
* Get the value associated with the given Dictionary key.
*
@@ -138,6 +144,7 @@ public final class Dictionary {
*/
public native String get(String key) /*-{
var value = th...@com.google.gwt.i18n.client.dictionary::dict[key];
+ th...@com.google.gwt.i18n.client.dictionary::accessedKeys.push(key);
if (value == null || !Object.prototype.hasOwnProperty.call(
th...@com.google.gwt.i18n.client.dictionary::dict, key))
{
@@ -179,6 +186,7 @@ public final class Dictionary {
if (s.size() < MAX_KEYS_TO_SHOW) {
error += "\n keys found: " + s;
}
+error += "\n accessed keys: " + accessedKeys;
throw new MissingResourceException(error, this.toString(), key);
}
Index: user/test/com/google/gwt/i18n/client/I18NTest.java
--- user/test/com/google/gwt/i18n/client/I18NTest.java (revision 4905)
+++ user/test/com/google/gwt/i18n/client/I18NTest.java (working copy)
@@ -421,6 +421,13 @@ public class I18NTest extends GWTTestCase {
assertTrue(s.contains("a"));
assertTrue(s.contains("b"));
assertFalse(s.contains("c"));
+try {
+ d.get("nonExistentKey");
+ fail("should have thrown a MissingResourceException");
+} catch (MissingResourceException ex) {
+ assertTrue(ex.getMessage(), ex.getMessage().indexOf(
+ "accessed keys: formattedMessage,d,nonExistentKey") != -1);
+}
Collection s2 = d.values();
assertTrue(s2.contains("A"));
assertTrue(s2.contains("B"));
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Fix for IE8's implementation of getAbsoluteLeft/Top()
Committed as r5485. http://gwt-code-reviews.appspot.com/34827 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5485 - Fixes missing body scroll-position addition in IE8's implementation of
Author: j...@google.com
Date: Mon Jun 1 14:02:57 2009
New Revision: 5485
Modified:
trunk/user/src/com/google/gwt/dom/client/DOMImplIE6.java
trunk/user/src/com/google/gwt/dom/client/DOMImplIE8.java
trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.java
trunk/user/test/com/google/gwt/dom/client/ElementTest.java
Log:
Fixes missing body scroll-position addition in IE8's implementation of
getAbsoluteLeft/Top().
Review: http://gwt-code-reviews.appspot.com/34827
Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplIE6.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImplIE6.java(original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImplIE6.javaMon Jun 1
14:02:57 2009
@@ -24,14 +24,14 @@
@Override
public int getAbsoluteLeft(Element elem) {
Document doc = elem.getOwnerDocument();
-return (int) Math.floor(super.getAbsoluteLeft(elem)
+return (int) Math.floor(getBoundingClientRectLeft(elem)
/ getZoomMultiple(doc) + doc.getScrollLeft());
}
@Override
public int getAbsoluteTop(Element elem) {
Document doc = elem.getOwnerDocument();
-return (int) Math.floor(super.getAbsoluteTop(elem)
+return (int) Math.floor(getBoundingClientRectTop(elem)
/ getZoomMultiple(doc) + doc.getScrollTop());
}
Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplIE8.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImplIE8.java(original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImplIE8.javaMon Jun 1
14:02:57 2009
@@ -18,6 +18,18 @@
class DOMImplIE8 extends DOMImplTrident {
@Override
+ public int getAbsoluteLeft(Element elem) {
+Document doc = elem.getOwnerDocument();
+return getBoundingClientRectLeft(elem) + doc.getScrollLeft();
+ }
+
+ @Override
+ public int getAbsoluteTop(Element elem) {
+Document doc = elem.getOwnerDocument();
+return getBoundingClientRectTop(elem) + doc.getScrollTop();
+ }
+
+ @Override
public int getScrollLeft(Element elem) {
if (isRTL(elem)) {
// IE8 returns increasingly *positive* values as you scroll left in
RTL.
Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.java
(original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImplTrident.javaMon Jun
1
14:02:57 2009
@@ -166,16 +166,6 @@
return "[event" + evt.type + "]";
}-*/;
- @Override
- public int getAbsoluteLeft(Element elem) {
-return getBoundingClientRectLeft(elem);
- }
-
- @Override
- public int getAbsoluteTop(Element elem) {
-return getBoundingClientRectTop(elem);
- }
-
/**
* IE returns a numeric type for some attributes that are really
properties,
* such as offsetWidth. We need to coerce these to strings to prevent a
@@ -253,23 +243,7 @@
elem.innerText = text || '';
}-*/;
- protected native boolean isRTL(Element elem) /*-{
-return elem.currentStyle.direction == 'rtl';
- }-*/;
-
- private native Element createElementInternal(Document doc, String
tagName) /*-{
-return doc.createElement(tagName);
- }-*/;
-
- // IE needs a container div *for each document* for use by
createElement().
- private native Element ensureContainer(Document doc) /*-{
-if (!doc.__gwt_container) {
- doc.__gwt_container = doc.createElement('div');
-}
-return doc.__gwt_container;
- }-*/;
-
- private native int getBoundingClientRectLeft(Element elem) /*-{
+ protected native int getBoundingClientRectLeft(Element elem) /*-{
// getBoundingClientRect() throws a JS exception if the elem is not
attached
// to the document, so we wrap it in a try/catch block
try {
@@ -279,7 +253,7 @@
}
}-*/;
- private native int getBoundingClientRectTop(Element elem) /*-{
+ protected native int getBoundingClientRectTop(Element elem) /*-{
// getBoundingClientRect() throws a JS exception if the elem is not
attached
// to the document, so we wrap it in a try/catch block
try {
@@ -287,6 +261,22 @@
} catch (e) {
return 0;
}
+ }-*/;
+
+ protected native boolean isRTL(Element elem) /*-{
+return elem.currentStyle.direction == 'rtl';
+ }-*/;
+
+ private native Element createElementInternal(Document doc, String
tagName) /*-{
+return doc.createElement(tagName);
+ }-*/;
+
+ // IE needs a container div *for each document* for use by
createElement().
+ private native Element ensureContainer(Document doc) /*-{
+if (!doc.__gwt_container) {
+ doc.__gwt_container = doc.createElement('div');
+}
+return doc.__gwt_container;
}-*/;
/**
Modified: trunk/user/test/com/google/gwt/dom/client/ElementTest.java
==
[gwt-contrib] Re: Fix for IE8's implementation of getAbsoluteLeft/Top()
LGTM http://gwt-code-reviews.appspot.com/34827 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speedups for -soyc compilation
On Mon, Jun 1, 2009 at 3:16 PM, Daniel Rice (דניאל רייס) wrote: > I have verified that the xml files for a single-permutation Showcase > build are identical modulo whitespace to a set of "golden" xml files. > I would be happy to run the dashboard on a larger compile -- how do I > run it? IMHO that's enough checking. Thanks! Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Fix for IE8's implementation of getAbsoluteLeft/Top()
http://gwt-code-reviews.appspot.com/34827/diff/9/1002 File user/test/com/google/gwt/dom/client/ElementTest.java (right): http://gwt-code-reviews.appspot.com/34827/diff/9/1002#newcode238 Line 238: assertEquals(absTop, div.getAbsoluteTop()); The diff is a bit weird here, because it looks a lot like the original testGetAbsolutePositionWhenScrolled() that used to be here. But it's a new method altogether. http://gwt-code-reviews.appspot.com/34827/diff/9/1002#newcode314 Line 314: assertFalse(Element.is(null)); More sort cruft. Sorry about that. http://gwt-code-reviews.appspot.com/34827/diff/9/1002#newcode432 Line 432: assertEquals(outer.getScrollLeft(), 0); This used to be called testGetAbsolutePositionWhenScrolled(), but that was completely incorrect, as it didn't test getAbsoluteLeft/Top() at all. http://gwt-code-reviews.appspot.com/34827 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Fix for IE8's implementation of getAbsoluteLeft/Top()
Reviewers: , http://gwt-code-reviews.appspot.com/34827/diff/1/4 File user/src/com/google/gwt/dom/client/DOMImplIE8.java (right): http://gwt-code-reviews.appspot.com/34827/diff/1/4#newcode30 Line 30: } This is equivalent to the implementation in IE6, but without that zoom stuff (they finally got rid of that on IE8). http://gwt-code-reviews.appspot.com/34827/diff/1/3 File user/src/com/google/gwt/dom/client/DOMImplTrident.java (left): http://gwt-code-reviews.appspot.com/34827/diff/1/3#oldcode177 Line 177: } Removing these, because they're not correct on any of IE6, IE7, IE8. The body's scroll position has to be added in all three. http://gwt-code-reviews.appspot.com/34827/diff/1/3#oldcode270 Line 270: }-*/; Sorry about the sort cruft. Please review this at http://gwt-code-reviews.appspot.com/34827 Affected files: M user/src/com/google/gwt/dom/client/DOMImplIE6.java M user/src/com/google/gwt/dom/client/DOMImplIE8.java M user/src/com/google/gwt/dom/client/DOMImplTrident.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speedups for -soyc compilation
I have verified that the xml files for a single-permutation Showcase build are identical modulo whitespace to a set of "golden" xml files. I would be happy to run the dashboard on a larger compile -- how do I run it? I already submitted a CL, so I will make this changes in a follow-up CL. Dan On Mon, Jun 1, 2009 at 2:57 PM, wrote: > LGTM > > I do want to re-iterate Lex's point that we need to make sure that the > dashboard does not produce different results with this. This is > especially true because we know that the output of the SOYC files has > changed with this patch. > > Having said that, this should really speed up compilation, and as a nice > side effect, the resulting files should be quite a bit smaller, which is > a VERY good thing. > > > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1003 > File dev/core/src/com/google/gwt/core/ext/soyc/Story.java (right): > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1003#newcode35 > Line 35: import java.util.SortedSet; > do you still need this import? > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1004 > File dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryImpl.java > (right): > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1004#newcode24 > Line 24: import java.util.SortedSet; > again, delete this import. > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1008 > File dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java > (right): > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1008#newcode368 > Line 368: + (System.currentTimeMillis() - permStart) + " ms"); > I'm not sure we want to have this in the general compile. If you want > it in there, add it to a logger instead of printing to stdout? > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1010 > File dev/core/src/com/google/gwt/dev/jjs/SourceInfo.java (right): > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1010#newcode66 > Line 66: Set getPrimaryCorrelations(); > can we get rid of this (now that we have Correlation[] get > PrimaryCorrelationsArray())? I know this gets called from other places > as well, but it would be good to simplify. If it you get rid of it, can > you do the same for Correlation get PrimaryCorrelation(Axis axis)? > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1011 > File dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java > (right): > > http://gwt-code-reviews.appspot.com/34818/diff/1002/1011#newcode40 > Line 40: private static final int numCorrelationAxes = > Axis.values().length; > I'd be a bit careful with this. It's a nice simplification, but SOYC > compiles tend to suffer from bad memory blow-ups. This will add a field > to every single SourceOrigin. > > http://gwt-code-reviews.appspot.com/34818 > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Speedups for -soyc compilation
LGTM I do want to re-iterate Lex's point that we need to make sure that the dashboard does not produce different results with this. This is especially true because we know that the output of the SOYC files has changed with this patch. Having said that, this should really speed up compilation, and as a nice side effect, the resulting files should be quite a bit smaller, which is a VERY good thing. http://gwt-code-reviews.appspot.com/34818/diff/1002/1003 File dev/core/src/com/google/gwt/core/ext/soyc/Story.java (right): http://gwt-code-reviews.appspot.com/34818/diff/1002/1003#newcode35 Line 35: import java.util.SortedSet; do you still need this import? http://gwt-code-reviews.appspot.com/34818/diff/1002/1004 File dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryImpl.java (right): http://gwt-code-reviews.appspot.com/34818/diff/1002/1004#newcode24 Line 24: import java.util.SortedSet; again, delete this import. http://gwt-code-reviews.appspot.com/34818/diff/1002/1008 File dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java (right): http://gwt-code-reviews.appspot.com/34818/diff/1002/1008#newcode368 Line 368: + (System.currentTimeMillis() - permStart) + " ms"); I'm not sure we want to have this in the general compile. If you want it in there, add it to a logger instead of printing to stdout? http://gwt-code-reviews.appspot.com/34818/diff/1002/1010 File dev/core/src/com/google/gwt/dev/jjs/SourceInfo.java (right): http://gwt-code-reviews.appspot.com/34818/diff/1002/1010#newcode66 Line 66: Set getPrimaryCorrelations(); can we get rid of this (now that we have Correlation[] get PrimaryCorrelationsArray())? I know this gets called from other places as well, but it would be good to simplify. If it you get rid of it, can you do the same for Correlation get PrimaryCorrelation(Axis axis)? http://gwt-code-reviews.appspot.com/34818/diff/1002/1011 File dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java (right): http://gwt-code-reviews.appspot.com/34818/diff/1002/1011#newcode40 Line 40: private static final int numCorrelationAxes = Axis.values().length; I'd be a bit careful with this. It's a nice simplification, but SOYC compiles tend to suffer from bad memory blow-ups. This will add a field to every single SourceOrigin. http://gwt-code-reviews.appspot.com/34818 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: ant de-duplication
On Mon, Jun 1, 2009 at 2:23 PM, wrote: > In that case, there are two other possible fixes, of which I suspect > you'll prefer the second. We could: > 1. revisit every instance of gwt.jar, and rearrange so > that the newest output directories will always be > first. That's brittle to future jars being wrong. > 2. rewrite gwt.jar as a macro, taking e.g. "sourcefiles" > and "generatedfiles" explicitly, and explicitly naming > the generated ones first (i.e. new directories first). > This was, in fact, my plan before I noted filesonly. > > I'll rework with the second approach. > SGTM. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Restore some convenience constructors
LGTM. However, long term I think it's a travesty these are concrete
classes. Ultimately I'd wish for TypeOracle's classes to be read-only
interfaces with private implementation classes.
On Mon, Jun 1, 2009 at 2:02 PM, wrote:
> Reviewers: scottb,
>
> Description:
> Restore public convenience constructors in JConstructor, JMethod, and
> JParameter (over-zealously removed in r5410) that turn out to be used by
> third-party code.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/34826
>
> Affected files:
> dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
> dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
> dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
>
>
> Index: dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
> ===
> --- dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
> (revision 5475)
> +++ dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
> (working copy)
> @@ -23,6 +23,10 @@
> */
> public class JConstructor extends JAbstractMethod {
> private final JClassType enclosingType;
> +
> + public JConstructor(JClassType enclosingType, String name) {
> +this(enclosingType, name, null, null);
> + }
>
> public JConstructor(JClassType enclosingType, String name,
> Map, Annotation> declaredAnnotations,
> Index: dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
> ===
> --- dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
> (revision 5475)
> +++ dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
> (working copy)
> @@ -31,6 +31,11 @@
> private JType type;
>
> private final JAbstractMethod enclosingMethod;
> +
> + public JParameter(JAbstractMethod enclosingMethod, JType type,
> + String name) {
> +this(enclosingMethod, type, name, null);
> + }
>
> public JParameter(JAbstractMethod enclosingMethod, JType type, String
> name,
> Map, Annotation> declaredAnnotations) {
> Index: dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
> ===
> --- dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java (revision
> 5475)
> +++ dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java (working
> copy)
> @@ -27,6 +27,10 @@
>
> private JType returnType;
>
> + public JMethod(JClassType enclosingType, String name) {
> +this(enclosingType, name, null, null);
> + }
> +
> public JMethod(JClassType enclosingType, String name,
> Map, Annotation> declaredAnnotations,
> JTypeParameter[] jtypeParameters) {
>
>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Removal of JMethod & JParameter constructors
On Mon, Jun 1, 2009 at 1:57 PM, Daniel Rice (דניאל רייס) wrote: > I think simply because they were unreferenced. I'll restore them. > But I am wondering how a third-party library could use them. AFAIK, these are only constructed by TypeOracleMediator, and any generator creates new types/etc by generating source and getting it compiled. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: ant de-duplication
Reviewers: scottb, http://gwt-code-reviews.appspot.com/33837/diff/1/2 File common.ant.xml (right): http://gwt-code-reviews.appspot.com/33837/diff/1/2#newcode145 Line 145: On 2009/06/01 17:56:26, scottb wrote: > I have to admit I'm a bit concerned about this. You've verified that omitting > the directories has no impact? We used to require directories to be in jars, > and I think there are still some cases where it's important. See > AbstractCompiler.INameEnvironmentImpl.isPackage() and > JDTCompiler.INameEnvironmentImpl.isPackage(). > Is there any other way we could fix the timestamp issues? Ah. Testing has been less than light, other than that the builds complete... and, yes, I am seeing some failures now that I'm running the tests. In that case, there are two other possible fixes, of which I suspect you'll prefer the second. We could: 1. revisit every instance of gwt.jar, and rearrange so that the newest output directories will always be first. That's brittle to future jars being wrong. 2. rewrite gwt.jar as a macro, taking e.g. "sourcefiles" and "generatedfiles" explicitly, and explicitly naming the generated ones first (i.e. new directories first). This was, in fact, my plan before I noted filesonly. I'll rework with the second approach. http://gwt-code-reviews.appspot.com/33837/diff/1/5 File user/build.xml (right): http://gwt-code-reviews.appspot.com/33837/diff/1/5#newcode5 Line 5: On 2009/06/01 17:56:26, scottb wrote: > This reordering because..? Because (1) ant properties are immutable, and (2) the local.ant.properties file is read inside common.ant.xml. So by relocating the default assignment of gwt.junit.emmatestcase.includes to be after the import, users get a chance to set their own values. Description: We used to do a lot of repeated work on back-to-back build commands. This patch makes us not do so. Please review this at http://gwt-code-reviews.appspot.com/33837 Affected files: common.ant.xml dev/common.ant.xml dev/core/build.xml user/build.xml Index: common.ant.xml === --- common.ant.xml (revision 5480) +++ common.ant.xml (working copy) @@ -1,4 +1,10 @@ + + + Index: dev/core/build.xml === --- dev/core/build.xml (revision 5480) +++ dev/core/build.xml (working copy) @@ -22,7 +22,13 @@ - + + + + + @@ -45,7 +51,6 @@ - Index: user/build.xml === --- user/build.xml (revision 5480) +++ user/build.xml (working copy) @@ -2,9 +2,11 @@ - + + + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5484 - Restore constructors removed in r5410.
Author: r...@google.com
Date: Mon Jun 1 11:19:34 2009
New Revision: 5484
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
Log:
Restore constructors removed in r5410.
Review by: sco...@google.com
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
Mon Jun 1 11:19:34 2009
@@ -23,6 +23,10 @@
*/
public class JConstructor extends JAbstractMethod {
private final JClassType enclosingType;
+
+ public JConstructor(JClassType enclosingType, String name) {
+this(enclosingType, name, null, null);
+ }
public JConstructor(JClassType enclosingType, String name,
Map, Annotation> declaredAnnotations,
Modified: trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.javaMon
Jun 1 11:19:34 2009
@@ -27,6 +27,10 @@
private JType returnType;
+ public JMethod(JClassType enclosingType, String name) {
+this(enclosingType, name, null, null);
+ }
+
public JMethod(JClassType enclosingType, String name,
Map, Annotation> declaredAnnotations,
JTypeParameter[] jtypeParameters) {
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java Mon
Jun 1 11:19:34 2009
@@ -31,6 +31,11 @@
private JType type;
private final JAbstractMethod enclosingMethod;
+
+ public JParameter(JAbstractMethod enclosingMethod, JType type,
+ String name) {
+this(enclosingMethod, type, name, null);
+ }
public JParameter(JAbstractMethod enclosingMethod, JType type, String
name,
Map, Annotation> declaredAnnotations) {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5483 - Avoid a linear search when generating identifier names in the inliner and pretty namer.
Author: r...@google.com
Date: Mon Jun 1 11:11:35 2009
New Revision: 5483
Modified:
trunk/dev/core/src/com/google/gwt/dev/js/JsInliner.java
trunk/dev/core/src/com/google/gwt/dev/js/JsPrettyNamer.java
Log:
Avoid a linear search when generating identifier names in the inliner and
pretty namer.
Review by: sco...@google.com
Modified: trunk/dev/core/src/com/google/gwt/dev/js/JsInliner.java
==
--- trunk/dev/core/src/com/google/gwt/dev/js/JsInliner.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/js/JsInliner.java Mon Jun 1
11:11:35 2009
@@ -63,6 +63,7 @@
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
+import java.util.HashMap;
import java.util.HashSet;
import java.util.IdentityHashMap;
import java.util.List;
@@ -727,6 +728,13 @@
private final JsProgram program;
/**
+ * A map containing the next integer to try as an identifier suffix for
+ * a given JsScope.
+ */
+private IdentityHashMap>
startIdentForScope
+= new IdentityHashMap>();
+
+/**
* Not a stack because program fragments aren't nested.
*/
private JsFunction programFunction;
@@ -961,11 +969,20 @@
* function so we'll use a counter for disambiguation.
*/
String ident;
-int count = 0;
+String base = f.getName() + "_" + name.getIdent();
JsScope scope = functionStack.peek().getScope();
+HashMap startIdent = startIdentForScope.get(scope);
+if (startIdent == null) {
+ startIdent = new HashMap();
+ startIdentForScope.put(scope, startIdent);
+}
+
+Integer s = startIdent.get(base);
+int suffix = (s == null) ? 0 : s.intValue();
do {
- ident = f.getName() + "_" + name.getIdent() + "_" + count++;
+ ident = base + "_" + suffix++;
} while (scope.findExistingName(ident) != null);
+startIdent.put(base, suffix);
JsName newName = scope.declareName(ident, name.getShortIdent());
v.setReplacementName(name, newName);
Modified: trunk/dev/core/src/com/google/gwt/dev/js/JsPrettyNamer.java
==
--- trunk/dev/core/src/com/google/gwt/dev/js/JsPrettyNamer.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/js/JsPrettyNamer.java Mon Jun 1
11:11:35 2009
@@ -20,7 +20,9 @@
import com.google.gwt.dev.js.ast.JsRootScope;
import com.google.gwt.dev.js.ast.JsScope;
+import java.util.HashMap;
import java.util.HashSet;
+import java.util.IdentityHashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Set;
@@ -40,6 +42,13 @@
private Set childIdents = null;
private final JsProgram program;
+
+ /**
+ * A map containing the next integer to try as an identifier suffix for
+ * a given JsScope.
+ */
+ private IdentityHashMap>
startIdentForScope =
+new IdentityHashMap>();
public JsPrettyNamer(JsProgram program) {
this.program = program;
@@ -66,6 +75,12 @@
}
private void visit(JsScope scope) {
+HashMap startIdent = startIdentForScope.get(scope);
+if (startIdent == null) {
+ startIdent = new HashMap();
+ startIdentForScope.put(scope, startIdent);
+}
+
// Save off the childIdents which is currently being computed for my
parent.
Set myChildIdents = childIdents;
@@ -95,13 +110,17 @@
String newIdent = name.getShortIdent();
if (!isLegal(scope, childIdents, newIdent)) {
-String checkIdent = newIdent;
-for (int i = 0; true; ++i) {
- checkIdent = newIdent + "_" + i;
- if (isLegal(scope, childIdents, checkIdent)) {
-break;
- }
-}
+String checkIdent;
+
+// Start searching using a suffix hint stored in the scope.
+// We still do a search in case there is a collision with
+// a user-provided identifier
+Integer s = startIdent.get(newIdent);
+int suffix = (s == null) ? 0 : s.intValue();
+do {
+ checkIdent = newIdent + "_" + suffix++;
+} while (!isLegal(scope, childIdents, checkIdent));
+startIdent.put(newIdent, suffix);
name.setShortIdent(checkIdent);
} else {
// nothing to do; the short name is already good
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Restore some convenience constructors
Reviewers: scottb,
Description:
Restore public convenience constructors in JConstructor, JMethod, and
JParameter (over-zealously removed in r5410) that turn out to be used by
third-party code.
Please review this at http://gwt-code-reviews.appspot.com/34826
Affected files:
dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
Index: dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
===
--- dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
(revision 5475)
+++ dev/core/src/com/google/gwt/core/ext/typeinfo/JConstructor.java
(working copy)
@@ -23,6 +23,10 @@
*/
public class JConstructor extends JAbstractMethod {
private final JClassType enclosingType;
+
+ public JConstructor(JClassType enclosingType, String name) {
+this(enclosingType, name, null, null);
+ }
public JConstructor(JClassType enclosingType, String name,
Map, Annotation> declaredAnnotations,
Index: dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
===
--- dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
(revision
5475)
+++ dev/core/src/com/google/gwt/core/ext/typeinfo/JParameter.java
(working
copy)
@@ -31,6 +31,11 @@
private JType type;
private final JAbstractMethod enclosingMethod;
+
+ public JParameter(JAbstractMethod enclosingMethod, JType type,
+ String name) {
+this(enclosingMethod, type, name, null);
+ }
public JParameter(JAbstractMethod enclosingMethod, JType type, String
name,
Map, Annotation> declaredAnnotations) {
Index: dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java
===
--- dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java (revision
5475)
+++ dev/core/src/com/google/gwt/core/ext/typeinfo/JMethod.java (working
copy)
@@ -27,6 +27,10 @@
private JType returnType;
+ public JMethod(JClassType enclosingType, String name) {
+this(enclosingType, name, null, null);
+ }
+
public JMethod(JClassType enclosingType, String name,
Map, Annotation> declaredAnnotations,
JTypeParameter[] jtypeParameters) {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Removal of JMethod & JParameter constructors
I think simply because they were unreferenced. I'll restore them. Dan On Mon, Jun 1, 2009 at 12:29 PM, Scott Blum wrote: > Dan, can you shed some light? I think you removed them in r5410. > > On Sun, May 31, 2009 at 9:40 PM, Amir wrote: >> >> It looks like the following constructors were recently removed: >> >> public JMethod(JClassType enclosingType, String name) >> public JParameter(JAbstractMethod enclosingMethod, JType type, >> String name) >> >> I realize they're just convenience constructors, but a third party >> library we're using depends on these constructors, so I was wondering >> if someone could shed some light as to why they were removed? I >> couldn't find any discussions regarding it. >> >> Thanks. >> >> - Amir >> >> >> > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] ant de-duplication
http://gwt-code-reviews.appspot.com/33837/diff/1/2 File common.ant.xml (right): http://gwt-code-reviews.appspot.com/33837/diff/1/2#newcode6 Line 6: +10! http://gwt-code-reviews.appspot.com/33837/diff/1/2#newcode145 Line 145: I have to admit I'm a bit concerned about this. You've verified that omitting the directories has no impact? We used to require directories to be in jars, and I think there are still some cases where it's important. See AbstractCompiler.INameEnvironmentImpl.isPackage() and JDTCompiler.INameEnvironmentImpl.isPackage(). Is there any other way we could fix the timestamp issues? http://gwt-code-reviews.appspot.com/33837/diff/1/5 File user/build.xml (right): http://gwt-code-reviews.appspot.com/33837/diff/1/5#newcode5 Line 5: This reordering because..? http://gwt-code-reviews.appspot.com/33837 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] for review: Ant useful partial
Scott, Attached and also at http://gwt-code-reviews.appspot.com/33837 is the portion of the ant work which will, for example, stop the double-build of samples. It doesn't (yet) have any of the more sweeping changes I proposed in it. In all cases, the problems came from duplicate entries in the various jar files. So, for example, we'd get a directory "com" from both the src tree (with an old timestamp) and also from the bin tree (with a new one), first seen wins (because we used to have duplicate=preserve), which meant our output had "com/" with an old date, which a second look would invalidate against the bin "com/" with a newer date. Similarly for the class files in, say, the servlet api jar, of which we had/have several competing versions. I omitted directory entries, which I think are useless in jars anyway, and made the default duplicate behavior be to throw an error. Where we have semi-legitimate duplication, I special-case overrode with the old "preserve," but rearranged to become newest-first always. There's one stray change from my other work also, that ./common.ant.xml references a local settings property file, which is perhaps useful if set and harmless if not. In addition to allowing easy persistence of the test suites to run, as cited in the comment, it may later be useful for the $ vs _ handling. That also made me move the set of the emma testcases to be after importing common.ant.xml, so that users have a chance to override it. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- ant-nojardups@r5475.patch Description: Binary data
[gwt-contrib] [google-web-toolkit commit] r5482 - Speed up SOYC compilation.
Author: r...@google.com
Date: Mon Jun 1 10:40:23 2009
New Revision: 5482
Added:
trunk/dev/core/test/com/google/gwt/core/ext/util/
trunk/dev/core/test/com/google/gwt/core/ext/util/UtilSuite.java
(contents, props changed)
trunk/dev/core/test/com/google/gwt/core/ext/util/UtilTest.java
(contents, props changed)
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/Range.java
trunk/dev/core/src/com/google/gwt/core/ext/soyc/Story.java
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/DependencyRecorder.java
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryImpl.java
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryRecorder.java
trunk/dev/core/src/com/google/gwt/dev/CompilePerms.java
trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
trunk/dev/core/src/com/google/gwt/dev/jjs/SourceInfo.java
trunk/dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java
trunk/dev/core/src/com/google/gwt/dev/jjs/SourceOrigin.java
trunk/dev/core/src/com/google/gwt/dev/util/Util.java
Log:
Speed up SOYC compilation.
Review by: sp...@google.com
Modified: trunk/dev/core/src/com/google/gwt/core/ext/soyc/Range.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/soyc/Range.java (original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/soyc/Range.java Mon Jun 1
10:40:23 2009
@@ -54,8 +54,8 @@
}
};
- private final int end;
- private final int start;
+ final int end;
+ final int start;
/**
* Constructor.
Modified: trunk/dev/core/src/com/google/gwt/core/ext/soyc/Story.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/soyc/Story.java (original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/soyc/Story.java Mon Jun 1
10:40:23 2009
@@ -31,6 +31,7 @@
package com.google.gwt.core.ext.soyc;
import java.io.Serializable;
+import java.util.Set;
import java.util.SortedSet;
/**
@@ -82,6 +83,5 @@
* string literals) that appear in multiple locations in the source may
be
* merged by the compiler into a single Story.
*/
- SortedSet getSourceOrigin();
-
-}
\ No newline at end of file
+ Set getSourceOrigin();
+}
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/DependencyRecorder.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/DependencyRecorder.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/DependencyRecorder.java
Mon Jun 1 10:40:23 2009
@@ -19,12 +19,10 @@
import com.google.gwt.dev.jjs.ast.JMethod;
import com.google.gwt.dev.jjs.ast.JProgram;
import com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer;
-import com.google.gwt.dev.util.HtmlTextOutput;
import com.google.gwt.util.tools.Utility;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
-import java.io.PrintWriter;
import java.util.ArrayList;
import java.util.zip.GZIPOutputStream;
@@ -42,10 +40,7 @@
new DependencyRecorder().recordDependenciesImpl(logger, out, jprogram);
}
- private HtmlTextOutput htmlOut;
- private PrintWriter pw;
-
- private OutputStreamWriter writer;
+ private StringBuilder builder;
private DependencyRecorder() {
}
@@ -74,22 +69,29 @@
dependencyAnalyzer.setDependencyRecorder(this);
try {
- writer = new OutputStreamWriter(new GZIPOutputStream(out), "UTF-8");
- pw = new PrintWriter(writer);
- htmlOut = new HtmlTextOutput(pw, false);
-} catch (Throwable e) {
- logger.log(TreeLogger.ERROR, "Could not open dependency file.", e);
-}
+ OutputStreamWriter writer
+ = new OutputStreamWriter(new GZIPOutputStream(out), "UTF-8");
+
+ StringBuilder localBuilder = new StringBuilder();
+ this.builder = localBuilder;
+
+ printPre();
+ for (JMethod method : jprogram.getAllEntryMethods()) {
+dependencyAnalyzer.traverseFrom(method);
+if (localBuilder.length() > 8 * 1024) {
+ writer.write(localBuilder.toString());
+ localBuilder.setLength(0);
+}
+ }
+ printPost();
-printPre();
-for (JMethod method : jprogram.getAllEntryMethods()) {
- dependencyAnalyzer.traverseFrom(method);
-}
-printPost();
-pw.close();
-Utility.close(writer);
+ writer.write(localBuilder.toString());
+ Utility.close(writer);
-logger.log(TreeLogger.INFO, "Done");
+ logger.log(TreeLogger.INFO, "Done");
+} catch (Throwable e) {
+ logger.log(TreeLogger.ERROR, "Could not write dependency file.", e);
+}
}
/**
@@ -99,55 +101,45 @@
* @param dependencyChain
*/
private void printMethodDependency(ArrayList dependencyChain) {
-String curLine;
-for (int i = dependencyChain.size() - 1; i >= 0; i--)
[gwt-contrib] Re: Removal of JMethod & JParameter constructors
Dan, can you shed some light? I think you removed them in r5410. On Sun, May 31, 2009 at 9:40 PM, Amir wrote: > > It looks like the following constructors were recently removed: > > public JMethod(JClassType enclosingType, String name) > public JParameter(JAbstractMethod enclosingMethod, JType type, > String name) > > I realize they're just convenience constructors, but a third party > library we're using depends on these constructors, so I was wondering > if someone could shed some light as to why they were removed? I > couldn't find any discussions regarding it. > > Thanks. > > - Amir > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Grammatical Error in Documentation
Thanks! Fixing :) On Sat, May 30, 2009 at 6:24 PM, Peter wrote: > > I think there is an error here: > > Tip: One way you can you can leverage Eclipse is to use its "suggest" > feature to add the required import declarations. > > http://code.google.com/webtoolkit/tutorials/1.6/buildui.html > > It says 'you can' twice :p > > Cheers. -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Question about the default linkers
Robert, There are several scripts that are doc.written into the page in both the std and xs linkers. Let me preface by saying that I hate the way these things have to work, but it's remarkably difficult to get them right across browsers. We use doc.write() for external script dependencies, because there's no way to know when they're done otherwise. When you doc.write() a script tag, it is fetched synchronously (after the current script is done evaluating), just as it would be if it were statically defined. If you attach the script element to the DOM, it's fetched asynchronously, and the script's onload event doesn't work properly on all browsers (see IFrameTemplate::onInjectionDone). We also use doc.write() in computeScriptBase(), because there's no other way to find the "current" script tag. It's an ugly hack, but I know of no other way to solve this problem. The only other solution I'm aware of would be to require users to add a tag to explicitly specify the base url for the compiled script, but we're kind of hamstrung by the fact that we've always done this automagically. Probably the best solution to this problem would be to create a highly-restricted linker, which would simply not support automatic rebasing and dependent script/css injection. If you're interested in doing so, be my guest -- I'd be quite happy to review it. Cheers, joel. On Fri, May 15, 2009 at 1:46 PM, Robert kebernet Cooper wrote: > > Is there a compelling reason that the linkers add scripts to the page > using document.write rather than making DOM calls? The reason I ask is > because this prevents me from being able to add a non-single script > app to a page after the page has been rendered. I was going to look > into implementing my own SelectionScriptLinker class with new > templates, but if anyone knows that this will not work it would be > great to know in advance. > > Thanks. > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5481 - The overridesView doesn't appear to be accessed in some cases, so we can
Author: r...@google.com
Date: Mon Jun 1 08:23:58 2009
New Revision: 5481
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardClassMember.java
Log:
The overridesView doesn't appear to be accessed in some cases, so we can
save time by creating it lazily.
Review by: b...@google.com
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardClassMember.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardClassMember.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardClassMember.java
Mon Jun 1 08:23:58 2009
@@ -34,22 +34,26 @@
*/
public class StandardClassMember extends AbstractMemberWithDependencies
implements ClassMember {
+ private final MemberFactory factory;
private final SortedSet fields = new TreeSet(
Member.SOURCE_NAME_COMPARATOR);
private final SortedSet fieldsView =
Collections.unmodifiableSortedSet(fields);
private final SortedSet methods = new
TreeSet(
Member.SOURCE_NAME_COMPARATOR);
private final SortedSet methodsView =
Collections.unmodifiableSortedSet(methods);
- private final SortedSet overridesView;
+ private SortedSet overridesView; // Initialized lazily
private final String packageName;
private final String sourceName;
-
+ private final JDeclaredType type;
+
/**
* Constructed by {...@link MemberFactory#get(JReferenceType)}.
*/
public StandardClassMember(MemberFactory factory, JDeclaredType type) {
super(type.getSourceInfo());
-
+this.factory = factory;
+this.type = type;
+
int index = type.getName().lastIndexOf('.');
if (index < 0) {
packageName = "";
@@ -57,31 +61,6 @@
packageName = type.getName().substring(0, index).intern();
}
sourceName = type.getName().intern();
-
-Set seen = new HashSet();
-Set toTraverse = new HashSet();
-toTraverse.add(type);
-
-SortedSet overrides = new TreeSet(
-Member.SOURCE_NAME_COMPARATOR);
-
-while (!toTraverse.isEmpty()) {
- JDeclaredType currentType = toTraverse.iterator().next();
- seen.add(currentType);
-
- if (currentType != type) {
-overrides.add(factory.get(currentType));
- }
-
- if (currentType.getSuperClass() != null) {
-toTraverse.add(currentType.getSuperClass());
- }
-
- toTraverse.addAll(currentType.getImplements());
-
- toTraverse.removeAll(seen);
-}
-overridesView = Collections.unmodifiableSortedSet(overrides);
}
public void addField(FieldMember field) {
@@ -101,7 +80,12 @@
}
public SortedSet getOverrides() {
-return overridesView;
+synchronized (StandardClassMember.class) {
+ if (overridesView == null) {
+computeOverrides();
+ }
+ return overridesView;
+}
}
public String getPackage() {
@@ -120,4 +104,32 @@
public String toString() {
return "ClassMember " + getSourceName();
}
-}
\ No newline at end of file
+
+ /** Compute overrides on demand. */
+ private void computeOverrides() {
+Set seen = new HashSet();
+Set toTraverse = new HashSet();
+toTraverse.add(type);
+
+SortedSet overrides = new TreeSet(
+Member.SOURCE_NAME_COMPARATOR);
+
+while (!toTraverse.isEmpty()) {
+ JDeclaredType currentType = toTraverse.iterator().next();
+ seen.add(currentType);
+
+ if (currentType != type) {
+overrides.add(factory.get(currentType));
+ }
+
+ if (currentType.getSuperClass() != null) {
+toTraverse.add(currentType.getSuperClass());
+ }
+
+ toTraverse.addAll(currentType.getImplements());
+
+ toTraverse.removeAll(seen);
+}
+overridesView = Collections.unmodifiableSortedSet(overrides);
+ }
+}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] GWT+CAS+Spring Security
Hi All, I want to replace JSP's in CAS with GWT.Right now CAS(provided by http://www.jasig.org/cas) using standard Jsp's for login pages. form submission on JSP page will handled by Spring webflow classes.By default all these configuration are being provided by CAS war file .Here instead of JSP's i would like to use GWT login page . But wt ever they are doing in Spring webflow ..where do i need to write the code..?What should i do ../ Please reply thanks in Advance --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Removal of JMethod & JParameter constructors
It looks like the following constructors were recently removed: public JMethod(JClassType enclosingType, String name) public JParameter(JAbstractMethod enclosingMethod, JType type, String name) I realize they're just convenience constructors, but a third party library we're using depends on these constructors, so I was wondering if someone could shed some light as to why they were removed? I couldn't find any discussions regarding it. Thanks. - Amir --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: possible ant changes
On Mon, Jun 1, 2009 at 10:48 AM, Rajeev Dayal wrote: > If it is the case that a subsequent "ant build" after running "ant build" > is zero work provided that there are no code changes, then I am okay with > having "ant test" depend on "ant build". However, if running "ant build" in > a zero-work case takes a non-trivial amount of time, then we should > re-consider having "ant test" depend on "ant build". > It will be the case that the second of two back-to-back "ant build" commands will be zero work. (I think I have that part already, though I've gotten interrupted into FF 3.5b4 issues.) > I'd also recommend that running "ant test" rebuild the test classes > themselves, and the build step for test code should be zero-work if "ant > test" is run back-to-back with no test code changes in-between. > I think that's allready the structure; I'll double-check the zero-work bit. > A nice-to-have (i.e. less important than all of the other things you > mentioned) would be the ability to specify specific tests via the > command-line (maybe via a system property?). > That actually exists already, mostly, in that the little-known ant property gwt.junit.testcase.includes is an ant-style glob of tests to run. Its default value is **/*Suite.class, but you can override that to a narrower value if you like. What's missing, however, is the ability to anything fancier than a glob, like say a comma-separated lists. So you can easily restrict to a directory's suites, to to a specific suite, but it's harder to run say the RPC and I18N suites at once. > Rajeev > > > > On Wed, May 27, 2009 at 1:38 PM, Freeland Abbott wrote: > >> So, I'm looking at our ant files, and trying to unwind several problems... >> but I figure I'll ask what other people have as pet peeves, to see if there >> are other games I should play, too. >> >> Here's what's on my mind right now: >> >>- If you run "ant clean build; ant build", the second build should be >>zero work. It's not, and in particular it painfully builds samples twice. >>It shouldn't. >>- Right now, tests require a staging directory, which implies >>requiring a full distro kit including samples. That's unnecessary; tests >>should require build, but not much more. >> - Related to that, too much depends on the semi-recursive -do, >> which is actually a no-op that depends on dist, which pulls too much >> in for >> simple cases. >>- Largely orthogonal, we have checked in files with $ in their names, >>which are supposed to also be usable wtih _ instead. I've got a system >>which is badly allergic to the $'s, which is why this causes me pain, but >>generally it seems this "should" be addressed with alternate classpath >> roots >>anyway, so we can test both the two cases easily. >> >> Does anyone have other pain points to add? >> >> >> What I was thinking of doing is: >> >>- Shoot the top-level -do target, in favor of having subtargets >>directly invoke what they need from subprojects, via , and >> setting >>"target" as is done today... so e.g. target "test" can depend target >> "build" >>or "buildonly" and then the "test" targets of dev, user, etc. >>explicitly. Since -do would no longer exist, it wouldn't depend on "dist" >>to get the fan-out effects, and fan-out can be more selectively >> controlled. >>- Untangle whatever our double-build is caused by; at first blush, it >>seems to think my directories are out of date relative to the existing jar >>(not the files in them, but the directories themselves). >>- Change the default target to "dist," for back compatibility, since >>that's what build today really does (build depends on -do which depends on >>dist which depends on build in all the subprojects). >>- Twiddle the semantics of "build" to be just building. I haven't >>decided whether that would include building samples (probably; buildonly >>exists to skip that), but it wouldn't assemble the distro archive and then >>unpack it as dist does. >>- Introduce user/test_dollar and user/test_underbar as java-root >>directories with the obvious subset of files from today's user/test, and >> an >>adjustment to the test target one or the other is on classpath, >> controlled I >>think by a system property. >> >> Thoughts on that? >> >> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: possible ant changes
Hey Freeland, All of this sounds great. The build scripts have been in severe need of tweaking for a while, and I'm glad that you've decided to tackle this tricky issue. I've got a couple of comments about the "ant test" behavior. If it is the case that a subsequent "ant build" after running "ant build" is zero work provided that there are no code changes, then I am okay with having "ant test" depend on "ant build". However, if running "ant build" in a zero-work case takes a non-trivial amount of time, then we should re-consider having "ant test" depend on "ant build". I'd also recommend that running "ant test" rebuild the test classes themselves, and the build step for test code should be zero-work if "ant test" is run back-to-back with no test code changes in-between. A nice-to-have (i.e. less important than all of the other things you mentioned) would be the ability to specify specific tests via the command-line (maybe via a system property?). Rajeev On Wed, May 27, 2009 at 1:38 PM, Freeland Abbott wrote: > So, I'm looking at our ant files, and trying to unwind several problems... > but I figure I'll ask what other people have as pet peeves, to see if there > are other games I should play, too. > > Here's what's on my mind right now: > >- If you run "ant clean build; ant build", the second build should be >zero work. It's not, and in particular it painfully builds samples twice. >It shouldn't. >- Right now, tests require a staging directory, which implies requiring >a full distro kit including samples. That's unnecessary; tests should >require build, but not much more. > - Related to that, too much depends on the semi-recursive -do, which > is actually a no-op that depends on dist, which pulls too much in for > simple > cases. >- Largely orthogonal, we have checked in files with $ in their names, >which are supposed to also be usable wtih _ instead. I've got a system >which is badly allergic to the $'s, which is why this causes me pain, but >generally it seems this "should" be addressed with alternate classpath > roots >anyway, so we can test both the two cases easily. > > Does anyone have other pain points to add? > > > What I was thinking of doing is: > >- Shoot the top-level -do target, in favor of having subtargets >directly invoke what they need from subprojects, via , and setting >"target" as is done today... so e.g. target "test" can depend target > "build" >or "buildonly" and then the "test" targets of dev, user, etc. >explicitly. Since -do would no longer exist, it wouldn't depend on "dist" >to get the fan-out effects, and fan-out can be more selectively controlled. >- Untangle whatever our double-build is caused by; at first blush, it >seems to think my directories are out of date relative to the existing jar >(not the files in them, but the directories themselves). >- Change the default target to "dist," for back compatibility, since >that's what build today really does (build depends on -do which depends on >dist which depends on build in all the subprojects). >- Twiddle the semantics of "build" to be just building. I haven't >decided whether that would include building samples (probably; buildonly >exists to skip that), but it wouldn't assemble the distro archive and then >unpack it as dist does. >- Introduce user/test_dollar and user/test_underbar as java-root >directories with the obvious subset of files from today's user/test, and an >adjustment to the test target one or the other is on classpath, controlled > I >think by a system property. > > Thoughts on that? > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT-RPC broken in GAE/J
Glad to see progress on this. Ray, did anything come out of discussions at Google I/O? There seems to be two schools of thought here (both equally valid approaches mind you): 1. Help the client participate in the persistence, maintain detached state, dirty field lists, etc. This seems lofty and makes me more concerned about tight coupling, but is probably exactly what is needed for some applications. 2. Make a clean cut and keep the client free from persistence concerns. This could be RPC with seperate DTOs or marshalled XML/JSON. The client is only able to save by sending the modified object which is then fully updated in the database (all fields, since we lost track of what changed). This would typically happen by having the server reconstruct the object (unmarshal), then merge this over an existing entity. Our app actually functions as #2. Currently we use GWT-generated XML conversion code on the client. It's inefficient if your entity has many fields and you change just one. We've employed "sparse xml" to help, where we send back only the elements we want to modify (all of them are optional). When this is applied to the entity, only one field is triggered in the update. In theory this is great but I haven't implemented to dirty field tracking in the client, so in practice we serialize the whole object and we don't get any benefit from it. So I guess I'm sort of sitting on fence on this one. I beleive #1 can work, but I need to see proof of it in a large-ish app before we go and touch anything. On May 30, 4:24 pm, Piotr Jaroszyński wrote: > Hey Ray, > > > I've pretty much decided to go the DTO approach at this point as it is > > known to work 100%. I don't feel the current hacks are production > > worthy. > > You have mentioned on your blog that you use protobufs for DTOs. Could > you please elaborate on that? > > P.S. Can't wait for gwt sessions to be uploaded on youtube! > > -- > Best Regards, > Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Create overridesView lazily in StandardClassMember
LGTM, just some nits. http://gwt-code-reviews.appspot.com/33835/diff/1/2 File dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardClassMember.java (right): http://gwt-code-reviews.appspot.com/33835/diff/1/2#newcode44 Line 44: private SortedSet overridesView = null; The explicit initialization isn't necessary. http://gwt-code-reviews.appspot.com/33835/diff/1/2#newcode65 Line 65: Whitespace. http://gwt-code-reviews.appspot.com/33835/diff/1/2#newcode106 Line 106: // Compute overrides on demand Use a javadoc-style comment here http://gwt-code-reviews.appspot.com/33835 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
