Re: [gwt-contrib] Re: Remove caching of style sheets in IE6 (cache may be invalid when there are multiple modules)
If you write a halfway decent microbenchmark, please add it
to trunk/reference/Microbenchmarks/src/com/google/gwt/reference/microbenchmark
On Fri, Mar 5, 2010 at 9:19 AM, jlaba...@google.com wrote:
http://gwt-code-reviews.appspot.com/159804/diff/1/3
File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
http://gwt-code-reviews.appspot.com/159804/diff/1/3#newcode101
Line 101: private static native int getDocumentStyleSheetLength(int idx)
/*-{
I don't know for sure if reading cssText.length is slow, but I'm worried
that we had a reason to cache the length originally. I agree that there
is no way to cache the info because we can't control what happens
outside of GWT, so we wouldn't even know if external code modified the
style sheets.
Can you just try injecting 40 large style sheets and compare the
performance before and after the change? At the very least, we should
warn people if its going to get really slow.
http://gwt-code-reviews.appspot.com/159804
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
On Fri, Mar 5, 2010 at 12:28 PM, Lex Spoon sp...@google.com wrote: On Thu, Mar 4, 2010 at 5:16 PM, Scott Blum sco...@google.com wrote: Straw man let's say when you inject a GWT selection script, you can add a single line at the very top: var moduleBaseURL = w00t/ Then at the top of computeScriptBase(), we just look to see if moduleBaseURL is already defined, and if so we return that. 1. That doesn't solve the problem. The problem is that different modules need different base URLs. You'd inject a different var declaration at the top of each inlined script. 2. How is this better than using a meta property? It looks identical except that it inserts a var rather than a meta tag. Seems conceptually simpler, and doesn't introduce the idea of module-specific meta props. Also should be faster since it means less DOM crawling during startup? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Example of how to use Actions with UiBinder
Hi, a very simple example of using Actions with UiBinder: http://code.google.com/p/gwt-mosaic/wiki/AppModuleUiBinder?ts=1267811945updated=AppModuleUiBinder The Actions implementation is base on GWT Beans Binding framework. Kind Regards, George. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7677 committed - Play with css styling of tree widgets...
Revision: 7677
Author: gwt.mirror...@gmail.com
Date: Fri Mar 5 10:15:44 2010
Log: Play with css styling of tree widgets
Make bikeshed compile
Review at http://gwt-code-reviews.appspot.com/160807
http://code.google.com/p/google-web-toolkit/source/detail?r=7677
Modified:
/trunk/bikeshed/.classpath
/trunk/bikeshed/src/com/google/gwt/bikeshed/cells/client/CheckboxCell.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/stocks/client/StockSample.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/stocks/server/StockServiceImpl.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/tree/client/TreeSample.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/SideBySideTreeNodeView.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/SideBySideTreeView.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/StandardTreeNodeView.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/StandardTreeView.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/TreeNodeView.java
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/TreeView.java
/trunk/bikeshed/war/Stocks.css
/trunk/bikeshed/war/Tree.css
===
--- /trunk/bikeshed/.classpath Thu Mar 4 12:59:01 2010
+++ /trunk/bikeshed/.classpath Fri Mar 5 10:15:44 2010
@@ -6,5 +6,6 @@
classpathentry kind=con
path=com.google.gwt.eclipse.core.GWT_CONTAINER/
classpathentry kind=con
path=org.eclipse.jdt.launching.JRE_CONTAINER/
classpathentry kind=lib path=war/WEB-INF/lib/gwt-servlet.jar/
+ classpathentry kind=con
path=org.eclipse.jdt.junit.JUNIT_CONTAINER/3/
classpathentry kind=output path=war/WEB-INF/classes/
/classpath
===
---
/trunk/bikeshed/src/com/google/gwt/bikeshed/cells/client/CheckboxCell.java
Fri Feb 26 09:32:06 2010
+++
/trunk/bikeshed/src/com/google/gwt/bikeshed/cells/client/CheckboxCell.java
Fri Mar 5 10:15:44 2010
@@ -40,7 +40,7 @@
@Override
public void render(Boolean data, StringBuilder sb) {
sb.append(input type=\checkbox\);
-if (data == Boolean.TRUE) {
+if (data == true) {
sb.append( checked);
}
sb.append(/);
===
---
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/stocks/client/StockSample.java
Thu Mar 4 08:02:44 2010
+++
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/stocks/client/StockSample.java
Fri Mar 5 10:15:44 2010
@@ -252,7 +252,7 @@
// Create the transactions tree.
transactionTree2 = new SideBySideTreeView(new
TransactionTreeViewModel(favoritesListModel,
-transactionListListModelsByTicker), null);
+transactionListListModelsByTicker), null, 200, 200);
Columns.favoriteColumn.setFieldUpdater(new FieldUpdaterStockQuote,
Boolean() {
public void update(StockQuote object, Boolean value) {
===
---
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/stocks/server/StockServiceImpl.java
Thu Mar 4 12:59:01 2010
+++
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/stocks/server/StockServiceImpl.java
Fri Mar 5 10:15:44 2010
@@ -51,7 +51,7 @@
/**
* The result of a query to the remote service that provides stock
quotes.
*/
- private class Result {
+ private static class Result {
int numRows;
StockQuoteList quotes;
@@ -91,7 +91,7 @@
throws IllegalArgumentException {
String query = request.getSearchQuery();
-if (query == null | query.length() == 0) {
+if (query == null || query.length() == 0) {
query = .*;
}
Range searchRange = request.getSearchRange();
===
---
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/tree/client/TreeSample.java
Thu Mar 4 08:02:44 2010
+++
/trunk/bikeshed/src/com/google/gwt/bikeshed/sample/tree/client/TreeSample.java
Fri Mar 5 10:15:44 2010
@@ -33,7 +33,7 @@
RootPanel.get().add(new HTML(hr));
-SideBySideTreeView sstree = new SideBySideTreeView(new
MyTreeViewModel(), ...);
+SideBySideTreeView sstree = new SideBySideTreeView(new
MyTreeViewModel(), ..., 100, 200);
RootPanel.get().add(sstree);
}
}
===
---
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/SideBySideTreeNodeView.java
Thu Mar 4 08:02:44 2010
+++
/trunk/bikeshed/src/com/google/gwt/bikeshed/tree/client/SideBySideTreeNodeView.java
Fri Mar 5 10:15:44 2010
@@ -15,8 +15,6 @@
*/
package com.google.gwt.bikeshed.tree.client;
-import static
com.google.gwt.bikeshed.tree.client.SideBySideTreeView.COLUMN_WIDTH;
-
import com.google.gwt.bikeshed.cells.client.Cell;
import com.google.gwt.bikeshed.tree.client.TreeViewModel.NodeInfo;
import com.google.gwt.dom.client.Document;
@@ -29,11 +27,15 @@
/**
* A tree view that displays each level in a side-by-side manner.
- *
+ *
* @param T the type that this {...@link TreeNodeView}
[gwt-contrib] [google-web-toolkit] r7678 committed - Edited wiki page through web user interface.
Revision: 7678 Author: rj...@google.com Date: Fri Mar 5 10:25:36 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7678 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Tue Mar 2 11:10:24 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:25:36 2010 @@ -5,7 +5,7 @@ We've found that the API semantics for the JRE collections classes are not an ideal match for the constraints of running inside browsers, especially mobile browsers, for several reasons. == Background and Motivation == -_The JRE collections framework encode assumptions about the relationship between types, objects, and their implementation making them highly coupled, even at the top of the hierarchy._ For example, the `Map` interface has methods such as `values()`, `entrySet()`, `keySet()` that make very specific guarantees about how the returned objects interact with the map from which they derive. These sorts of prescribed dependencies between collection types (e.g. using a `Map` implies the use of `Set` and `Collection`) and the behavior of collection objects themselves prevent simple implementations. Repeated attempts to optimize GWT's emulated JRE collections show a relatively high cost for even minimal usage of JRE collections because, for example, using a `Map` implies using a `Set` and a `Collection`. +_The JRE collections framework encode assumptions about the relationship between types, objects, and their implementation making them highly coupled, even at the top of the hierarchy._ For example, the `Map` interface has methods such as `values()`, `entrySet()`, `keySet()` that make very specific guarantees about how the returned objects interact with the map from which they derive. These sorts of prescribed dependencies between collection types (e.g. using a `Map` implies the use of `Set` and `Collection`) and the behavior of collection objects themselves prevent simple implementations. Repeated attempts to optimize GWT's emulated JRE collections show a relatively high code-size cost for even minimal usage of JRE collections because, for example, using a `Map` implies using a `Set` and a `Collection`. _Too few collection types forces runtime enforcement of behaviors that could be more efficiently modeled statically._ A common example is a class `T` that wishes to return a reference an internal list. However, the `List` interface has mutators (e.g. `add()`) which `T` would not want to make possible from the outside. The traditional best practice of calling `Collections.unmodifiableList()` on the returned list reference requires the allocation of an extra object (which generates extra GC runs that can turn pathological in IE) as well extra code that must be generated simply to implement `throw new UnsupportedOperationException()` when a mutator is called on the wrapper object. If instead there were an `ImmutableList` type that the list collections implement, class `T` could simply have returned an immutable reference, which would ensure attempts to modify the list are caught at compile-time (i.e. because `ImmutableList` has no mutators) and which would prevent extra object allocations and potentially even facilitate inlining at compile time. This -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7679 committed - Edited wiki page through web user interface.
Revision: 7679 Author: rj...@google.com Date: Fri Mar 5 10:28:09 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7679 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Fri Mar 5 10:25:36 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:28:09 2010 @@ -21,7 +21,7 @@ * Collections must be efficiently serializable over GWT RPC. * Collections must be able to be `eval()`-ed into existence from JSON. * Collections must be pleasant to use, even relative to JRE collections. If developers are still tempted to use JRE collections, we could end up with the worst case of duplicating collection code. - * When non of the other goals are compromised, individual methods on collections should be source-compatible with JRE collections. This simplifies porting existing code to use the new collections and keeps methods as familiar as possible. + * When none of the other goals are compromised, individual methods on collections should be source-compatible with JRE collections. This simplifies porting existing code to use the new collections and keeps methods as familiar as possible. == Non-goals == * We are knowingly sacrificing true compatibility and interop with existing JRE collections. For example, we do not intend to implement the JRE `Map`, `List`, or `Set` interfaces. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7680 committed - Edited wiki page through web user interface.
Revision: 7680 Author: rj...@google.com Date: Fri Mar 5 10:29:47 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7680 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Fri Mar 5 10:28:09 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:29:47 2010 @@ -34,7 +34,7 @@ We begin by acknowledging that the design of anything as fundamental as collection types is bound to be contentious, so the plan is to start small and establish some patterns for simple, high-value collections: `Array` and `Map`. === Principles === -_Assertions, not exceptions._ Assertions, when turned off, can be compiled away. Code written to defensively check for and throw exceptions is very hard to optimize. Hosted mode always has assertions on, so any well-tested code ought to execute assertions during normal testing. +_Assertions, not exceptions._ Assertions, when turned off, can be compiled away. Code written to defensively check for and throw exceptions is very hard to optimize. Development mode (was hosted mode) always has assertions on, so any well-tested code ought to execute assertions during normal testing. _Types and methods must be used properly to perform properly._ Lightweight collections are in no way defensive. Improper use generates an assertion failure or, if assertions are disabled, undefined behavior. The corollary is that the API can be designed for maximum efficiency. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
Seems conceptually simpler, and doesn't introduce the idea of module-specific meta props. Also should be faster since it means less DOM crawling during startup? Do you think any of these are blocking problems? In particular, if we went with the 7-line meta-prop solution, would users be harmed in any measurable way? -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by rj...@google.com: I'm very uncomfortable with the Keep implementations locked down assertion. So long as its very clear which implementations have been vetted by the GWT team, why should we prevent clients from providing their own when they judge it to be worth the performance risk? For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7681 committed - Edited wiki page through web user interface.
Revision: 7681 Author: rj...@google.com Date: Fri Mar 5 10:31:21 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7681 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Fri Mar 5 10:29:47 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:31:21 2010 @@ -40,7 +40,7 @@ _Bending the type system is okay if it's sufficiently hard to detect._ If there are cases in which quietly cross-casting JSOs would be the most efficient thing to do, so it shall be done. However, in such cases, it should be a goal to do the right thing in hosted mode (e.g. actually have checked casts) but then silently slip in the trickier cross-casting version during a web mode compile. -_Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical since OOPHM is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. +_Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical since the development mode browser plug in (was OOPHM) is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. _Publish and guarantee time complexity for various operations._ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by rj...@google.com: Has any thought been given to bridging from the JRE collection world to the GWT collection world, and back again? Server side this will be crucial, and if we don't address all of our users will be forced to. Perhaps we would only provide JRE implementations of such code to discourage such mistakes client side. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7682 committed - Edited wiki page through web user interface.
Revision: 7682 Author: rj...@google.com Date: Fri Mar 5 10:32:12 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7682 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Fri Mar 5 10:31:21 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:32:12 2010 @@ -40,7 +40,7 @@ _Bending the type system is okay if it's sufficiently hard to detect._ If there are cases in which quietly cross-casting JSOs would be the most efficient thing to do, so it shall be done. However, in such cases, it should be a goal to do the right thing in hosted mode (e.g. actually have checked casts) but then silently slip in the trickier cross-casting version during a web mode compile. -_Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical since the development mode browser plug in (was OOPHM) is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. +_Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical mdash; because the development mode browser plug-in (was OOPHM) is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. _Publish and guarantee time complexity for various operations._ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7683 committed - Edited wiki page through web user interface.
Revision: 7683 Author: rj...@google.com Date: Fri Mar 5 10:32:42 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7683 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Fri Mar 5 10:32:12 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:32:42 2010 @@ -40,7 +40,7 @@ _Bending the type system is okay if it's sufficiently hard to detect._ If there are cases in which quietly cross-casting JSOs would be the most efficient thing to do, so it shall be done. However, in such cases, it should be a goal to do the right thing in hosted mode (e.g. actually have checked casts) but then silently slip in the trickier cross-casting version during a web mode compile. -_Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical mdash; because the development mode browser plug-in (was OOPHM) is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. +_Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical — because the development mode browser plug-in (was OOPHM) is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. _Publish and guarantee time complexity for various operations._ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by rj...@google.com: I'm with John T about the freeze() method: encouraging people to retroactively lock down an existing array instance seems like a bad idea. Like he says, the smart ones will make defensive copies anyway, so why don't we simply do the same and make the mistakes impossible? The current change it at runtime and take your chances proposal seems very un-GWTlike. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7684 committed - Edited wiki page through web user interface.
Revision: 7684 Author: rj...@google.com Date: Fri Mar 5 10:33:58 2010 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=7684 Modified: /wiki/LightweightCollections.wiki === --- /wiki/LightweightCollections.wiki Fri Mar 5 10:32:42 2010 +++ /wiki/LightweightCollections.wiki Fri Mar 5 10:33:58 2010 @@ -42,7 +42,7 @@ _Hosted mode collections implementations can differ, if necessary, from web mode._ This follows from the previous point but is also practical — because the development mode browser plug-in (was OOPHM) is based on IPC, it may simply be harmfully slow to implement hosted mode collections using JSNI. -_Publish and guarantee time complexity for various operations._ +_Publish and guarantee time complexity for various operations._ That is, publish via documentation and enforce empirically by monitoring automated benchmarking tests. _Keep implementations locked down._ Because it's very tricky to get the implementations for these sorts of collections just right, the plan is to minimize ways in which there could be confusion about the implementation of a given collection type. More concretely, the key types should be classes rather than interfaces so that their implementation can be restricted to the package in which they are defined. If developers cannot trust that a given collection instance is truly optimal and maintains time complexity guarantees -- as might be the case if collections types were interfaces which could have been implemented anywhere -- then they may feel compelled to write defensive code. By locking the implementations down, developers can rely on the behavior of a given collection type. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by tsta...@google.com: What about bounds checking? I know that GWT goes to great lengths to emulate array bounds checking with java arrays. I assume that this would go away with these collections. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
They are both viable, I'm sure. But all else being equal, we want the simpler thing. My opinion is that the meta-prop thing is more complicated. It adds a new feature (module-specific meta props). It's also not obvious whether the meta-prop should be respected or ignored when the selection script is NOT inlined. But, this is just my opinion, and I understand that you and others might have a different opinion. On Fri, Mar 5, 2010 at 1:35 PM, Lex Spoon sp...@google.com wrote: Seems conceptually simpler, and doesn't introduce the idea of module-specific meta props. Also should be faster since it means less DOM crawling during startup? Do you think any of these are blocking problems? In particular, if we went with the 7-line meta-prop solution, would users be harmed in any measurable way? -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Remove global IncubatorSuite and modify incubator build.xml to include all Suites
Reviewers: fabbott, Description: Our incubator build file currently includes only IncubatorSuite, which in turn includes the other suites. It would be better to break this hierarchy of suites and just include all suites in the ant tests. For example, we are missing the gen2 TableSuite at the moment. Please review this at http://gwt-code-reviews.appspot.com/159805 Affected files: build.xml test/com/google/gwt/IncubatorSuite.java test/com/google/gwt/gen2/Gen2Suite.java test/com/google/gwt/gen2/table/TableSuite.java test/com/google/gwt/libideas/LibIdeasSuite.java test/com/google/gwt/widgetideas/TopLevelWidgetsTestSuite.java test/com/google/gwt/widgetideas/WidgetIdeasSuite.java test/com/google/gwt/widgetideas/table/TableSuite.java testsets.ant.xml -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Character.isWhitespace()
Why doesn't GWT's JRE support Character.isWhitespace()? It supports Character.isSpace(), but that's @deprecated by Sun in (at least) 1.5: http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isSpace(char) eric -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Character.isWhitespace()
On Fri, Mar 5, 2010 at 4:12 PM, Eric B. Ridge eeb...@gmail.com wrote: Why doesn't GWT's JRE support Character.isWhitespace()? It supports Character.isSpace(), but that's @deprecated by Sun in (at least) 1.5: http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isSpace(char) The reason is that isWhitespace() explicitly supports Unicode characters, while GWT's Character.is* methods are basically only accurate for US-ASCII. The browsers do not provide the necessary pieces to do this correctly, so we would have to include the Unicode Character Database to implement them properly. I wrote an implementation of this last year that compressed the UCD to a few hundred bytes per table (and any table not used would not have any cost), but others were concerned about the size implications. I hope to get to work on it again next quarter, but no guarantees. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Remove global IncubatorSuite and modify incubator build.xml to include all Suites
LGTM. In build.xml, I don't think you need to add -ea explicitly to devmode tests. Not wrong, but they're already on. A bigger problem, but mine not yours, is that rietveld is (wrongly) basing this on http://google-web-toolkit, not on incubator, so the side-by-sides are all wrong. (I assume you used my wrapper around upload.py; I'll have to make it either auto-detect, or at least let you specify, which it is!) http://gwt-code-reviews.appspot.com/159805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Character.isWhitespace()
Hey, thanks for the reply. This makes perfect sense. eric On Mar 5, 4:23 pm, John Tamplin j...@google.com wrote: On Fri, Mar 5, 2010 at 4:12 PM, Eric B. Ridge eeb...@gmail.com wrote: Why doesn't GWT's JRE support Character.isWhitespace()? It supports Character.isSpace(), but that's @deprecated by Sun in (at least) 1.5: http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isSpac...) The reason is that isWhitespace() explicitly supports Unicode characters, while GWT's Character.is* methods are basically only accurate for US-ASCII. The browsers do not provide the necessary pieces to do this correctly, so we would have to include the Unicode Character Database to implement them properly. I wrote an implementation of this last year that compressed the UCD to a few hundred bytes per table (and any table not used would not have any cost), but others were concerned about the size implications. I hope to get to work on it again next quarter, but no guarantees. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JConstructor redesign
On Thu, Mar 4, 2010 at 5:42 PM, sco...@google.com wrote:
Startup speed impact:
- I'm not sure exactly how to measure startup time well.. but I suspect
it will be wash since we're able to avoid double-invocation on
instantiation in many cases, and we also remove more dead clinit loops
than we did.
I have a prototype benchmark that can load your app N times using
WebDriver, injecting a __gwtStatsEvent function which records
load/parse times, I'll see if I can get a patch of it up.
Follow-on work:
- I can reduce some of the code size with a subsequent patch that merges
empty constructors and seed functions, but I ran afoul of DeRPC's
expectations so I'll do this in a follow-up.
I wonder if DeRPC will be broken by my integer seeds patch.
I need to find a way to have this patch preserve the big gains (12%
pre-gzip, 2% post) that my integer seeds patch gets. It looks look it
might be possible to have something like:
function Cons(a,b,..) { // code }
injectConstructorSeed(cons, seedId);
the injectConstructorSeed() function would essentially do
injectConstructorSeed(func, seedId) {
func.prototype = defineSeed(seedId);
}
hopefully, this would be obfuscated to something like:
function Cx(a,b) { ...}
dS(Cx, 10);
The merge is going to be painful, but I think worth it.
-Ray
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
