[gwt-contrib] Re: review request: clean up the RPC compile-time noise

[Lex Spoon]

Can you verify that the same RPC decisions are being made?  For
example, does the code size look about the same, and the RPC policy
files exactly the same?  In particular, I'm worried about the new TICs
being added for things like wildcard types and type parameters.  After
a few minutes of poking, I don't see where those are weeded out, and
indeed I see some places where a type parameter is quietly replaced by
its upper bound.  If there are any differences, a simple way to prevent
them would be to have STOB.build() skip over any type parameters or
wildcard types when it is setting up possiblyInstantiatedTypes and
fieldSerializableTypes.

The rest of this message assumes either everything is still working
the same except for the log messages, or that the above tweak to
STOB.build is made.  In those cases, the patch LGTM, but with some
small nits:

checkTypeInstantable() starts by testing both
tic.hasInstantiableSubtypes() and tic.isInstantiable().  It only needs
to test hasInstantiableSubtypes().

For the listing of subtypes that were considered, I meant just to list
the types, not the types plus all the problems with them.  It's up to
you, though.

I wouldn't expect TypeExposureComputer to need to report any problems.
Did you run any any cases where it should?  Barring an argument to the
contrary, it looks better to not pass ProblemReports into TEC.  The
general idea is that any problem that needs reporting will also be
picked up by STOB proper.

Stepping back, I still suspect we could simplify all this if the
problems were listed in TypeInfoComputed, possibly along with some
other information.  It's just an idea, though.  The patch as is gives
GWT RPC much better logging.

Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Vitali Lovich]

Should've mentioned this in the original post, but probably the
TokenStream.javaclass
is the scanner you would be interested in I believe.

On Tue, Apr 14, 2009 at 1:14 AM, Vitali Lovich  wrote:

> Hey guys,
>
> Rhino  (one of Mozilla's javascript
> engines) is written entirely in Java & supports JS 1.7 if that helps.  I'm
> sure there's a parser component in there that can be extracted if the
> license is compatible (MPL/GPL).
>
> There's also GromJS  (public domain I
> think).
>
> On the other hand these are probably overkill for your needs.
>
>
> On Tue, Apr 14, 2009 at 12:33 AM, Lex Spoon  wrote:
>
>>
>> On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin  wrote:
>> > On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:
>> >>
>> >> If we were playing Mao, I would give you a card penalty for stating the
>> >> obvious. :-)
>> >>
>> >> But uh, reliably tracking whether or not you're in a string literal is
>> >> about as much fun as writing a JavaScript parser.  In fact, it might be
>> >> *exactly* as fun, if you know what I mean.
>> >
>> > String literals have to be known at parse time, so it seems to me all
>> you
>> > have to look for is start/stop quotes (of both sorts) while handling
>> > embedded ones of the wrong variety and escaped ones of the right
>> variety.
>> > That looks like it can be handled with a single character lookahead
>> scanner,
>> > and very little complexity -- what am I missing?
>>
>> It would be awesome if there were a simple lexer available for
>> JavaScript.  Given a token stream, brace counting would sound
>> feasible.
>>
>> However, from what I hear it's pretty complicated even to tokenize
>> JavaScript.  I don't know exactly what is so hard, but last time I
>> asked, regex literals came up.
>>
>> Lex
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Vitali Lovich]

Hey guys,

Rhino  (one of Mozilla's javascript engines)
is written entirely in Java & supports JS 1.7 if that helps.  I'm sure
there's a parser component in there that can be extracted if the license is
compatible (MPL/GPL).

There's also GromJS  (public domain I
think).

On the other hand these are probably overkill for your needs.

On Tue, Apr 14, 2009 at 12:33 AM, Lex Spoon  wrote:

>
> On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin  wrote:
> > On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:
> >>
> >> If we were playing Mao, I would give you a card penalty for stating the
> >> obvious. :-)
> >>
> >> But uh, reliably tracking whether or not you're in a string literal is
> >> about as much fun as writing a JavaScript parser.  In fact, it might be
> >> *exactly* as fun, if you know what I mean.
> >
> > String literals have to be known at parse time, so it seems to me all you
> > have to look for is start/stop quotes (of both sorts) while handling
> > embedded ones of the wrong variety and escaped ones of the right variety.
> > That looks like it can be handled with a single character lookahead
> scanner,
> > and very little complexity -- what am I missing?
>
> It would be awesome if there were a simple lexer available for
> JavaScript.  Given a token stream, brace counting would sound
> feasible.
>
> However, from what I hear it's pretty complicated even to tokenize
> JavaScript.  I don't know exactly what is so hard, but last time I
> asked, regex literals came up.
>
> Lex
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] UiBinder

[Gary Miller]

Any news on when UiBinder will be available to the outside world?

Thanks
Gary

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Lex Spoon]

On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin  wrote:
> On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:
>>
>> If we were playing Mao, I would give you a card penalty for stating the
>> obvious. :-)
>>
>> But uh, reliably tracking whether or not you're in a string literal is
>> about as much fun as writing a JavaScript parser.  In fact, it might be
>> *exactly* as fun, if you know what I mean.
>
> String literals have to be known at parse time, so it seems to me all you
> have to look for is start/stop quotes (of both sorts) while handling
> embedded ones of the wrong variety and escaped ones of the right variety.
> That looks like it can be handled with a single character lookahead scanner,
> and very little complexity -- what am I missing?

It would be awesome if there were a simple lexer available for
JavaScript.  Given a token stream, brace counting would sound
feasible.

However, from what I hear it's pretty complicated even to tokenize
JavaScript.  I don't know exactly what is so hard, but last time I
asked, regex literals came up.

Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5228 - Rollback r5225 due to failing IE7 test.

[codesite-noreply]

Author: j...@google.com
Date: Mon Apr 13 19:23:16 2009
New Revision: 5228

Removed:
trunk/user/src/com/google/gwt/jsonp/
trunk/user/test/com/google/gwt/jsonp/

Log:
Rollback r5225 due to failing IE7 test.


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] ImmutableResourceBundle deprecated, move to ClientBundle

[BobV]

I've deprecated the public ImmutableResourceBundle interfaces in the
incubator project to encourage users to migrate to the ClientBundle
series of interfaces that are now part of GWT trunk.  The IRB code in
the incubator project will not be removed for the foreseeable future,
but all future development will take place in trunk.

A summary of the user-visible changes is in the following wiki page:
  
http://code.google.com/p/google-web-toolkit/wiki/ClientBundle#Migrating_from_ImmutableResourceBundle

ClientBundle and IRB can be compiled into the same module, however the
data-types are not generally interchangeable, nor will a hybrid
approach necessarily yield optimal results.  If you have any
significant difficulties migrating your code base from
ImmutableResourceBundle to ClientBundle, let me know.

-- 
Bob Vawter
Google Web Toolkit Team

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5227 - Checkpoint current state, with HostedTest running as an app.

[codesite-noreply]

Author: j...@google.com
Date: Mon Apr 13 16:16:47 2009
New Revision: 5227

Added:
 
changes/jat/ihm/samples/hello/src/com/google/gwt/sample/hello/HostedTestApp.gwt.xml
changes/jat/ihm/samples/hello/war/HostedTestApp.html   (contents, props  
changed)
 
changes/jat/ihm/user/test/com/google/gwt/dev/jjs/test/HostedTestApp.java
(contents, props changed)
Modified:
 
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/JdtCompilationUnit.java
 
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java
 
changes/jat/ihm/samples/hello/src/com/google/gwt/sample/hello/Hello.gwt.xml
 
changes/jat/ihm/samples/hello/src/com/google/gwt/sample/hello/client/Hello.java
 
changes/jat/ihm/user/src/com/google/gwt/i18n/rebind/LocaleInfoGenerator.java

Log:
Checkpoint current state, with HostedTest running as an app.


Modified:  
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/JdtCompilationUnit.java
==
---  
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/JdtCompilationUnit.java   
 
(original)
+++  
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/JdtCompilationUnit.java   
 
Mon Apr 13 16:16:47 2009
@@ -110,15 +110,19 @@
@Override
protected Set computeReferencedTypes() {
  final Set result = new HashSet();
-cud.traverse(new TypeRefVisitor() {
-  @Override
-  protected void onTypeRef(SourceTypeBinding referencedType,
-  CompilationUnitDeclaration unitOfReferrer) {
-// Map the referenced type to the target compilation unit file.
-result.add(Name.internalName(CharOperation.charToString(
-referencedType.constantPoolName(;
-  }
-}, cud.scope);
+if (cud == null) {
+  System.err.println(getTypeName()
+  + ".computeReferencedTypes() - cud is null");
+} else {
+  cud.traverse(new TypeRefVisitor() {
+@Override
+protected void onTypeRef(SourceTypeBinding referencedType,
+CompilationUnitDeclaration unitOfReferrer) {
+  // Map the referenced type to the target compilation unit file.
+   
result.add(Name.internalName(CharOperation.charToString(referencedType.constantPoolName(;
+}
+  }, cud.scope);
+}
  return result;
}


Modified:  
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java
==
---  
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java   
 
(original)
+++  
changes/jat/ihm/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java   
 
Mon Apr 13 16:16:47 2009
@@ -241,7 +241,7 @@

  @Override
  public SignatureVisitor visitClassBound() {
-  JType[] bound = new JClassType[1];
+  JType[] bound = new JType[1];
bounds.add(bound);
return new ResolveParameterizedType(logger, bound, lookup, null);
  }
@@ -434,7 +434,7 @@
  /**
   * Resolve a parameterized type.
   *
- * @param result "pointer" to return location, ie. 1-element array
+ * @param returnTypeRef "pointer" to return location, ie. 1-element  
array
   */
  public ResolveParameterizedType(TreeLogger logger,
  JType[] returnTypeRef, TypeParameterLookup lookup,
@@ -499,8 +499,11 @@
  }
} catch (ArrayStoreException e) {
  throw new RuntimeException(
-"ArrayStore exception in ResolveParameterizedType",  
creationStackTrace);
+"ArrayStore exception in ResolveParameterizedType",
+creationStackTrace);
}
+  // this is the last visitor called on this visitor
+  visitEnd();
  }

  @Override
@@ -544,7 +547,7 @@
  @Override
  public void visitTypeArgument() {
// TODO(jat): is this the correct way to use JWildcardType?
-  JClassType[] arg = new JClassType[1];
+  JType[] arg = new JType[1]; // This could be int[] for example
arg[0] = typeOracle.getWildcardType(JWildcardType.BoundType.UNBOUND,
typeOracle.getJavaLangObject());
args.add(arg);
@@ -561,7 +564,7 @@
  @Override
  public void visitTypeVariable(String name) {
returnTypeRef[0] = lookup.lookup(name);
-  // visitTypeVariable is the last thing called on this visitor
+  // this is the last visitor called on this visitor
visitEnd();
  }

@@ -616,7 +619,10 @@
JWildcardType.BoundType.SUPER, (JClassType)  
returnTypeRef[0]);
break;
}
-  outerClass = (JClassType) returnTypeRef[0];
+  if (returnTypeRef[0] instanceof JClassType) {
+// Only JClassTypes can be an outer class
+outerClass = (JClassType) returnTypeRef[0];
+  }
  }
}


Modified:  
changes/jat/ihm/samples/hello/src/com/google/gwt/sample/hello/Hello.gwt.xml
==

[gwt-contrib] [google-web-toolkit commit] r5226 - When class metadata is disabled, use the class seed functions to derive predicable names ...

[codesite-noreply]

Author: b...@google.com
Date: Mon Apr 13 16:12:16 2009
New Revision: 5226

Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
trunk/user/super/com/google/gwt/emul/java/lang/Class.java
trunk/user/test/com/google/gwt/dev/jjs/test/ClassObjectTest.java

Log:
When class metadata is disabled, use the class seed functions to derive  
predicable names that can be deobfuscated via the symbol map files.
This implementation should be reconsidered as part of a larger cleanup of  
how class literals are modeled.

Patch by: bobv
Review by: scottb


Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.java 
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JClassLiteral.javaMon  
Apr 13 16:12:16 2009
@@ -65,6 +65,9 @@
assert (type instanceof JClassType);
JClassType classType = (JClassType) type;

+  // createForClass wants a reference to the seed function
+  call.getArgs().add(program.getLiteralClassSeed(classType));
+
JLiteral superclassLiteral;

if (classType.extnds != null) {

Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java Mon Apr 13  
16:12:16 2009
@@ -767,9 +767,6 @@
  return classLiteral;
}

-  /**
-   * TODO: unreferenced; remove this and JClassSeed?
-   */
public JClassSeed getLiteralClassSeed(JClassType type) {
  // could be interned
  return new JClassSeed(createSourceInfoSynthetic(JProgram.class,

Modified:  
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java  
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java Mon  
Apr 13 16:12:16 2009
@@ -467,17 +467,16 @@
  JavaASTGenerationVisitor.class, "Disabled class metadata");

  JMethod nameMethod = program.getIndexedMethod("Class.getName");
+JMethod simpleNameMethod =  
program.getIndexedMethod("Class.getSimpleName");

-// this.hashCode()
-JMethodCall hashCall = new JMethodCall(info,  
program.getExprThisRef(info, (JClassType) currentClass),
-program.getIndexedMethod("Object.hashCode"));
+// this.getNameFromClassSeed()
+JMethodCall seedCall = new JMethodCall(info,
+program.getExprThisRef(info, (JClassType) currentClass),
+program.getIndexedMethod("Class.getNameFromClassSeed"));

-// "Class$" + hashCode()
-JBinaryOperation op = new JBinaryOperation(info,  
program.getTypeJavaLangString(),
-JBinaryOperator.ADD,  
program.getLiteralString(info, "Class$"),
-hashCall);
-
-implementMethod(nameMethod, op);
+implementMethod(nameMethod, seedCall);
+implementMethod(simpleNameMethod, new CloneExpressionVisitor(
+program).cloneExpression(seedCall));

  // Forget the superclass
  JMethod superclassMethod =  
program.getIndexedMethod("Class.getSuperclass");

Modified:  
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
==
---  
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java   
 
(original)
+++  
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java   
 
Mon Apr 13 16:12:16 2009
@@ -547,7 +547,16 @@

  @Override
  public void endVisit(JClassSeed x, Context ctx) {
-  push(names.get(x.getRefType()).makeRef(x.getSourceInfo()));
+  /*
+   * Uninstantiated types, JSOs, and Strings don't have seed functions.
+   */
+  if (!program.typeOracle.isInstantiatedType(x.getRefType())
+  || program.isJavaScriptObject(x.getRefType())
+  || x.getRefType().equals(program.getTypeJavaLangString())) {
+push(jsProgram.getNullLiteral());
+  } else {
+push(names.get(x.getRefType()).makeRef(x.getSourceInfo()));
+  }
  }

  @SuppressWarnings("unchecked")

Modified: trunk/user/super/com/google/gwt/emul/java/lang/Class.java
==
--- trunk/user/super/com/google/gwt/emul/java/lang/Class.java   (original)
+++ trunk/user/super/com/

[gwt-contrib] [google-web-toolkit commit] r5225 - Add JSONP support - resubmit of 5208 after fixing IE7 bug.

[codesite-noreply]

Author: j...@google.com
Date: Mon Apr 13 16:01:14 2009
New Revision: 5225

Added:
trunk/user/src/com/google/gwt/jsonp/
   - copied from r5208, /trunk/user/src/com/google/gwt/jsonp/
trunk/user/src/com/google/gwt/jsonp/Jsonp.gwt.xml
   - copied unchanged from r5208,  
/trunk/user/src/com/google/gwt/jsonp/Jsonp.gwt.xml
trunk/user/src/com/google/gwt/jsonp/client/
   - copied from r5208, /trunk/user/src/com/google/gwt/jsonp/client/
trunk/user/src/com/google/gwt/jsonp/client/JsonpRequest.java
   - copied, changed from r5208,  
/trunk/user/src/com/google/gwt/jsonp/client/JsonpRequest.java
trunk/user/src/com/google/gwt/jsonp/client/JsonpRequestBuilder.java
   - copied unchanged from r5208,  
/trunk/user/src/com/google/gwt/jsonp/client/JsonpRequestBuilder.java
trunk/user/src/com/google/gwt/jsonp/client/TimeoutException.java
   - copied unchanged from r5208,  
/trunk/user/src/com/google/gwt/jsonp/client/TimeoutException.java
trunk/user/test/com/google/gwt/jsonp/
   - copied from r5208, /trunk/user/test/com/google/gwt/jsonp/
trunk/user/test/com/google/gwt/jsonp/JsonpRequestSuite.java
   - copied unchanged from r5208,  
/trunk/user/test/com/google/gwt/jsonp/JsonpRequestSuite.java
trunk/user/test/com/google/gwt/jsonp/JsonpTest.gwt.xml
   - copied unchanged from r5208,  
/trunk/user/test/com/google/gwt/jsonp/JsonpTest.gwt.xml
trunk/user/test/com/google/gwt/jsonp/client/
   - copied from r5208, /trunk/user/test/com/google/gwt/jsonp/client/
trunk/user/test/com/google/gwt/jsonp/client/JsonpRequestTest.java
   - copied unchanged from r5208,  
/trunk/user/test/com/google/gwt/jsonp/client/JsonpRequestTest.java
trunk/user/test/com/google/gwt/jsonp/server/
   - copied from r5208, /trunk/user/test/com/google/gwt/jsonp/server/
trunk/user/test/com/google/gwt/jsonp/server/EchoServlet.java
   - copied unchanged from r5208,  
/trunk/user/test/com/google/gwt/jsonp/server/EchoServlet.java

Log:
Add JSONP support - resubmit of 5208 after fixing IE7 bug.

Patch by: dwolf, jat
Review by: rjrjr, jgw (verbal)



Copied: trunk/user/src/com/google/gwt/jsonp/client/JsonpRequest.java (from  
r5208, /trunk/user/src/com/google/gwt/jsonp/client/JsonpRequest.java)
==
--- /trunk/user/src/com/google/gwt/jsonp/client/JsonpRequest.java   
(original)
+++ trunk/user/src/com/google/gwt/jsonp/client/JsonpRequest.javaMon Apr 
13  
16:01:14 2009
@@ -15,6 +15,7 @@
   */
  package com.google.gwt.jsonp.client;

+import com.google.gwt.core.client.JavaScriptObject;
  import com.google.gwt.dom.client.Document;
  import com.google.gwt.dom.client.Node;
  import com.google.gwt.dom.client.ScriptElement;
@@ -35,12 +36,18 @@
 */
private static int callbackCounter = 0;

+  /**
+   * __jsonp__ is a global object that contains callbacks of pending  
requests.
+   */
+  private static final String CALLBACKS_NAME = "__gwt_jsonp__";
+  private static final JavaScriptObject CALLBACKS =  
createCallbacksObject(CALLBACKS_NAME);
+
private static native Node getDocumentElement() /*-{
  return $doc.documentElement;
}-*/;

private static String nextCallbackId() {
-return "__jsonp" + (callbackCounter++) + "__";
+return "I" + (callbackCounter++);
}

private final String callbackId;
@@ -65,6 +72,16 @@
private Timer timer;

/**
+   * Creates a global object to store callbacks of pending requests.
+   *
+   * @param name The name of the global object.
+   * @return The created object.
+   */
+  private static native JavaScriptObject createCallbacksObject(String  
name) /*-{
+return $wnd[name] = new Object();
+  }-*/;
+
+  /**
 * Create a new JSONP request.
 *
 * @param callback The callback instance to notify when the response  
comes
@@ -109,14 +126,16 @@
 * @param baseUri To be sent to the server.
 */
void send(final String baseUri) {
-registerCallbacks();
+registerCallbacks(CALLBACKS);
  StringBuffer uri = new StringBuffer(baseUri);
  uri.append(baseUri.contains("?") ? "&" : "?");
-uri.append(callbackParam).append("=").append(callbackId).append(
+String prefix = CALLBACKS_NAME + "." + callbackId;
+
+uri.append(callbackParam).append("=").append(prefix).append(
  ".onSuccess");
  if (failureCallbackParam != null) {
uri.append("&");
-   
uri.append(failureCallbackParam).append("=").append(callbackId).append(
+  uri.append(failureCallbackParam).append("=").append(prefix).append(
".onFailure");
  }
  ScriptElement script = Document.get().createScriptElement();
@@ -165,11 +184,13 @@
 * Registers the callback methods that will be called when the JSONP  
response
 * comes back. 2 callbacks are created, one to return the value, and one  
to
 * notify a failure.
+   *
+   * @param callbacks the global JS object which stores callbacks
 */
- 

[gwt-contrib] [google-web-toolkit commit] r5224 - Merging tr...@5222:5223 into 2009-03-30 release branch.

[codesite-noreply]

Author: jlaba...@google.com
Date: Mon Apr 13 15:49:43 2009
New Revision: 5224

Modified:
branches/snapshot-2009.03.30-r5111/branch-info.txt
 
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java

Log:
Merging tr...@5222:5223 into 2009-03-30 release branch.
- Fixes a scrollLeft bug in Old Mozilla in RTL mode related to a recent  
patch.

svn merge -r 5222:5223 https://google-web-toolkit.googlecode.com/svn/trunk .

Patch by: jlabanca



Modified: branches/snapshot-2009.03.30-r5111/branch-info.txt
==
--- branches/snapshot-2009.03.30-r5111/branch-info.txt  (original)
+++ branches/snapshot-2009.03.30-r5111/branch-info.txt  Mon Apr 13 15:49:43  
2009
@@ -9,4 +9,5 @@
  A rollback of /tr...@c4974 and /tr...@c4943 was merged (r5137) into this  
branch to undo a compiler bug breaking method overrides
  Added imports to GenerateJavaAST so it would compile (r5138)
  A rollback of /tr...@c5075 was merged (r5198) into this branch to undo a  
compiler bug breaking custom field serializers
-/trunk/@5215:5216 was merged (r) into this branch to fix a scrollLeft  
bug in RTL
+/trunk/@5215:5216 was merged (r5217) into this branch to fix a scrollLeft  
bug in RTL
+/trunk/@5222:5223 was merged (r) into this branch to fix a scrollLeft  
bug in OldMozilla RTL

Modified:  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
==
---  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
 
(original)
+++  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
 
Mon Apr 13 15:49:43 2009
@@ -66,6 +66,15 @@
}-*/;

@Override
+  public int getScrollLeft(Element elem) {
+if (isRTL(elem)) {
+  return super.getScrollLeft(elem)
+  - (elem.getScrollWidth() - elem.getClientWidth());
+}
+return super.getScrollLeft(elem);
+  }
+
+  @Override
public native void setInnerText(Element elem, String text) /*-{
  // Remove all children first.
  while (elem.firstChild) {
@@ -76,7 +85,15 @@
elem.appendChild(elem.ownerDocument.createTextNode(text));
  }
}-*/;
-
+
+  @Override
+  public void setScrollLeft(Element elem, int left) {
+if (isRTL(elem)) {
+  left += elem.getScrollWidth() - elem.getClientWidth();
+}
+super.setScrollLeft(elem, left);
+  }
+
private native int getAbsoluteLeftImpl(Element viewport, Element elem)  
/*-{
  var doc = elem.ownerDocument;
  var style = doc.defaultView.getComputedStyle(elem, null);
@@ -113,5 +130,10 @@
  }

  return top + viewport.scrollTop;
+  }-*/;
+
+  private native boolean isRTL(Element elem) /*-{
+var style = elem.ownerDocument.defaultView.getComputedStyle(elem,  
null);
+return style.direction == 'rtl';
}-*/;
  }

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5223 - A recent change in getScrollLeft() normalize browsers to firefox's method of returning ne...

[codesite-noreply]

Author: jlaba...@google.com
Date: Mon Apr 13 15:42:25 2009
New Revision: 5223

Modified:
trunk/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java

Log:
A recent change in getScrollLeft() normalize browsers to firefox's method  
of returning negative indexes in RTL mode.  However, old mozilla does not  
do this automatically, so it also needs to be normalized.

Patch by: jlabanca
Review by: rjrjr



Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java  
(original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java Mon Apr 
 
13 15:42:25 2009
@@ -66,6 +66,15 @@
}-*/;

@Override
+  public int getScrollLeft(Element elem) {
+if (isRTL(elem)) {
+  return super.getScrollLeft(elem)
+  - (elem.getScrollWidth() - elem.getClientWidth());
+}
+return super.getScrollLeft(elem);
+  }
+
+  @Override
public native void setInnerText(Element elem, String text) /*-{
  // Remove all children first.
  while (elem.firstChild) {
@@ -76,7 +85,15 @@
elem.appendChild(elem.ownerDocument.createTextNode(text));
  }
}-*/;
-
+
+  @Override
+  public void setScrollLeft(Element elem, int left) {
+if (isRTL(elem)) {
+  left += elem.getScrollWidth() - elem.getClientWidth();
+}
+super.setScrollLeft(elem, left);
+  }
+
private native int getAbsoluteLeftImpl(Element viewport, Element elem)  
/*-{
  var doc = elem.ownerDocument;
  var style = doc.defaultView.getComputedStyle(elem, null);
@@ -113,5 +130,10 @@
  }

  return top + viewport.scrollTop;
+  }-*/;
+
+  private native boolean isRTL(Element elem) /*-{
+var style = elem.ownerDocument.defaultView.getComputedStyle(elem,  
null);
+return style.direction == 'rtl';
}-*/;
  }

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5222 - Removing System.out.println hack we used to track down the flakey RPC test failure.

[codesite-noreply]

Author: sco...@google.com
Date: Mon Apr 13 15:26:28 2009
New Revision: 5222

Modified:
 
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java

Log:
Removing System.out.println hack we used to track down the flakey RPC test  
failure.

Modified:  
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
==
---  
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
  
(original)
+++  
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
  
Mon Apr 13 15:26:28 2009
@@ -526,30 +526,13 @@

  } catch (ClassNotFoundException e) {
throw new SerializationException(e);
-
  } catch (InstantiationException e) {
throw new SerializationException(e);
-
  } catch (IllegalAccessException e) {
throw new SerializationException(e);
-
  } catch (IllegalArgumentException e) {
throw new SerializationException(e);
-
  } catch (InvocationTargetException e) {
-  /*
-   * HACK(scottb): temporary hack to print internal exceptions to the
-   * console while we try to pin down a flaky RPC test that fails very
-   * intermittently. The stack trace gets lost when we send this server
-   * exception back to the client, because we currently don't serialize
-   * cause and stacktrace across the wire. We end up with a useless
-   * client-side stacktrace that has no cause, and that's what JUnit  
sees.
-   * We can remove this spam if we serialize cause/stacktrace back to  
the
-   * client even if we haven't yet solve the flaky RPC test issue.
-   */
-  e.getTargetException().printStackTrace(System.out);
-  e.getTargetException().printStackTrace(System.err);
-
throw new SerializationException(e.getTargetException());
  } catch (NoSuchMethodException e) {
throw new SerializationException(e);

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Code review: SerializabilityUtil race condition

[Scott Blum]

Thanks for the IM-review.  Committed as r5221 & r5222 (I forgot to remove
the ServerSerializationStreamReader hack the first time).

On Mon, Apr 13, 2009 at 5:35 PM, Scott Blum  wrote:

> We have a confirmation on the race condition, so this review should now be
> prioritized.  At commit time, I'll also remove the hack
> from ServerSerializationStreamReader that spams System.out and System.err.
>
>
> On Mon, Apr 13, 2009 at 4:33 PM, Scott Blum  wrote:
>
>> Hi Bob,
>> Please review the attached patch to fix the SerializabilityUtil race
>> condition.  I don't want to commit this until we actually have a failed
>> build that verifies the problem (per the TBR you did over the weekend), but
>> I'd like to have the fix queued up and ready to go as soon as it does pop
>> up.
>>
>> Thanks,
>> Scott
>>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5221 - Fixes synchronization issues in SerializabilityUtil, which could cause random RPC failure...

[codesite-noreply]

Author: sco...@google.com
Date: Mon Apr 13 15:24:10 2009
New Revision: 5221

Modified:
 
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java

Log:
Fixes synchronization issues in SerializabilityUtil, which could cause  
random RPC failures due to a race condition.

Review by: bobv

Modified:  
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
==
---  
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java 
 
(original)
+++  
trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java 
 
Mon Apr 13 15:24:10 2009
@@ -48,6 +48,11 @@
 * A permanent cache of all computed CRCs on classes. This is safe to do
 * because a Class is guaranteed not to change within the lifetime of a
 * ClassLoader (and thus, this Map). Access must be synchronized.
+   *
+   * NOTE: after synchronizing on this field, it's possible to additionally
+   * synchronize on {...@link #classCustomSerializerCache} or
+   * {...@link #classSerializableFieldsCache}, so be aware deadlock potential  
when
+   * changing this code.
 */
private static final Map, String> classCRC32Cache = new  
IdentityHashMap, String>();

@@ -55,6 +60,9 @@
 * A permanent cache of all serializable fields on classes. This is safe  
to do
 * because a Class is guaranteed not to change within the lifetime of a
 * ClassLoader (and thus, this Map). Access must be synchronized.
+   *
+   * NOTE: to prevent deadlock, you may NOT synchronize {...@link  
#classCRC32Cache}
+   * after synchronizing on this field.
 */
private static final Map, Field[]> classSerializableFieldsCache  
= new IdentityHashMap, Field[]>();

@@ -63,6 +71,9 @@
 * is safe to do because a Class is guaranteed not to change within the
 * lifetime of a ClassLoader (and thus, this Map). Access must be
 * synchronized.
+   *
+   * NOTE: to prevent deadlock, you may NOT synchronize {...@link  
#classCRC32Cache}
+   * after synchronizing on this field.
 */
private static final Map, Class> classCustomSerializerCache  
= new IdentityHashMap, Class>();

@@ -97,25 +108,34 @@
   
TYPES_WHOSE_IMPLEMENTATION_IS_EXCLUDED_FROM_SIGNATURES.add(Throwable.class);
}

+  /**
+   * Returns the fields of a particular class that can be considered for
+   * serialization. The returned list will be sorted into a canonical  
order to
+   * ensure consistent answers.
+   *
+   * TODO: this method needs a better name, I think.
+   */
public static Field[] applyFieldSerializationPolicy(Class clazz) {
-Field[] serializableFields =  
getCachedSerializableFieldsForClass(clazz);
-if (serializableFields == null) {
-  ArrayList fieldList = new ArrayList();
-  Field[] fields = clazz.getDeclaredFields();
-  for (Field field : fields) {
-if (fieldQualifiesForSerialization(field)) {
-  fieldList.add(field);
+Field[] serializableFields;
+synchronized (classSerializableFieldsCache) {
+  serializableFields = classSerializableFieldsCache.get(clazz);
+  if (serializableFields == null) {
+ArrayList fieldList = new ArrayList();
+Field[] fields = clazz.getDeclaredFields();
+for (Field field : fields) {
+  if (fieldQualifiesForSerialization(field)) {
+fieldList.add(field);
+  }
  }
-  }
-  serializableFields = fieldList.toArray(new Field[fieldList.size()]);
+serializableFields = fieldList.toArray(new  
Field[fieldList.size()]);

-  // sort the fields by name
-  Arrays.sort(serializableFields, 0, serializableFields.length,
-  FIELD_COMPARATOR);
+// sort the fields by name
+Arrays.sort(serializableFields, 0, serializableFields.length,
+FIELD_COMPARATOR);

-  putCachedSerializableFieldsForClass(clazz, serializableFields);
+classSerializableFieldsCache.put(clazz, serializableFields);
+  }
  }
-
  return serializableFields;
}

@@ -140,17 +160,20 @@
}

public static String getSerializationSignature(Class instanceType) {
-String result = getCachedCRCForClass(instanceType);
-if (result == null) {
-  CRC32 crc = new CRC32();
-  try {
-generateSerializationSignature(instanceType, crc);
-  } catch (UnsupportedEncodingException e) {
-throw new RuntimeException(
-"Could not compute the serialization signature", e);
+String result;
+synchronized (classCRC32Cache) {
+  result = classCRC32Cache.get(instanceType);
+  if (result == null) {
+CRC32 crc = new CRC32();
+try {
+  generateSerializationSignature(instanceType, crc);
+} catch (UnsupportedEncodingException e) {
+  throw new RuntimeException(
+  "Could not compute the serialization signature", e);
+}
+result = Long.toString(crc.getValue()

[gwt-contrib] [google-web-toolkit commit] r5220 - Fixes how we translate between Java and JavaScript source positions in BuildTypeMap.

[codesite-noreply]

Author: sco...@google.com
Date: Mon Apr 13 15:13:24 2009
New Revision: 5220

Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java

Log:
Fixes how we translate between Java and JavaScript source positions in  
BuildTypeMap.

This fixes issue #3506, which was caused by computing this incorrectly and  
overflowing the end of file in some cases.

Issue: 3506
Found by: rice
Review by: bobv

Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java 
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.javaMon  
Apr 13 15:13:24 2009
@@ -314,6 +314,61 @@
return process(typeDeclaration);
  }

+/**
+ * JS reports the error as a line number, to find the absolute  
position in
+ * the real source stream, we have to walk from the absolute JS start
+ * position until we have counted down enough lines. Then we use the  
column
+ * position to find the exact spot.
+ */
+private int computeAbsoluteProblemPosition(char[] source, int start,
+int end, int jsStartLine, SourceDetail detail) {
+  int linesToCount = detail.getLine() - jsStartLine;
+  int i = start;
+  while (linesToCount > 0 && i < end) {
+switch (source[i]) {
+  case '\r':
+// if skip an extra character if this is a CR/LF
+if (i + 1 < end && source[i + 1] == '\n') {
+  ++i;
+}
+// intentional fall through
+  case '\n':
+--linesToCount;
+// intentional fall through
+  default:
+++i;
+}
+  }
+
+  // Jump to the correct (1-based) column.
+  i += detail.getLineOffset() - 1;
+  return i;
+}
+
+private int countLines(char[] source, int p1, int p2) {
+  assert p1 >= 0 && p1 < source.length;
+  assert p2 >= 0 && p2 <= source.length;
+  assert p1 <= p2;
+
+  int lines = 0;
+  while (p1 < p2) {
+switch (source[p1]) {
+  case '\r':
+// if skip an extra character if this is a CR/LF
+if (p1 + 1 < p2 && source[p1 + 1] == '\n') {
+  ++p1;
+}
+// intentional fall through
+  case '\n':
+++lines;
+// intentional fall through
+  default:
+++p1;
+}
+  }
+  return lines;
+}
+
  private JField createEnumField(SourceInfo info, FieldBinding binding,
  JReferenceType enclosingType) {
JType type = (JType) typeMap.get(binding.type);
@@ -708,10 +763,28 @@
  }
  syntheticFnHeader += param.getName();
}
-  syntheticFnHeader += ')';
-  StringReader sr = new StringReader(syntheticFnHeader + ' ' +  
jsniCode);
+  syntheticFnHeader += ") ";
+  StringReader sr = new StringReader(syntheticFnHeader + jsniCode);
+
+  // Absolute start and end position of braces in original source.
+  int absoluteJsStartPos = methodDeclaration.bodyStart + startPos;
+  int absoluteJsEndPos = absoluteJsStartPos + jsniCode.length();
+
+  // Adjust the points the JS parser sees to account for the synth  
header.
+  int jsStartPos = absoluteJsStartPos - syntheticFnHeader.length();
+  int jsEndPos = absoluteJsEndPos - syntheticFnHeader.length();
+
+  // To compute the start line, count lines from point to point.
+  int jsLine = info.getStartLine()
+  + countLines(source, info.getStartPos(), absoluteJsStartPos);
+
+  SourceInfo jsInfo = program.createSourceInfo(jsStartPos, jsEndPos,
+  jsLine, info.getFileName());
+  jsInfo.copyMissingCorrelationsFrom(info);
+
try {
-List result = JsParser.parse(info,  
jsProgram.getScope(), sr);
+List result = JsParser.parse(jsInfo,  
jsProgram.getScope(),
+sr);
  JsExprStmt jsExprStmt = (JsExprStmt) result.get(0);
  JsFunction jsFunction = (JsFunction) jsExprStmt.getExpression();
  jsFunction.setFromJava(true);
@@ -726,38 +799,13 @@
  "Internal error parsing JSNI in method '" + newMethod
  + "' in type '" + enclosingType.getName() + "'", e);
} catch (JsParserException e) {
-/*
- * count the number of characters to the problem (from the start  
of the
- * JSNI code)
- */
-SourceDetail detail = e.getSourceDetail();
-int line = detail.getLine();
-char[] chars = jsniCode.toCharArray();
-int i = 0, n = chars.length;
-while (line > 0) {
-  // CHECKSTYLE_OFF
-  switch (chars[i]) {
-case '\r':
-  // if skip an extra character if this is a CR/LF
-  if (i + 1 < n && chars[i + 1] == '\n') {
-++i;
-  }
-  // intentional fall-through
-

[gwt-contrib] Re: Code review: SerializabilityUtil race condition

[Scott Blum]

We have a confirmation on the race condition, so this review should now be
prioritized.  At commit time, I'll also remove the hack
from ServerSerializationStreamReader that spams System.out and System.err.

On Mon, Apr 13, 2009 at 4:33 PM, Scott Blum  wrote:

> Hi Bob,
> Please review the attached patch to fix the SerializabilityUtil race
> condition.  I don't want to commit this until we actually have a failed
> build that verifies the problem (per the TBR you did over the weekend), but
> I'd like to have the fix queued up and ready to go as soon as it does pop
> up.
>
> Thanks,
> Scott
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Ian Petersen]

On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin  wrote:
> On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:
>>
>> If we were playing Mao, I would give you a card penalty for stating the
>> obvious. :-)
>>
>> But uh, reliably tracking whether or not you're in a string literal is
>> about as much fun as writing a JavaScript parser.  In fact, it might be
>> *exactly* as fun, if you know what I mean.
>
> String literals have to be known at parse time, so it seems to me all you
> have to look for is start/stop quotes (of both sorts) while handling
> embedded ones of the wrong variety and escaped ones of the right variety.
> That looks like it can be handled with a single character lookahead scanner,
> and very little complexity -- what am I missing?

And couldn't you treat comments similarly without much increase in
complexity?  (I haven't looked at the patch so sorry if this is
irrelevant.)

Ian

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[John Tamplin]

On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:

> If we were playing Mao, I would give you a card penalty for stating the
> obvious. :-)
>
> But uh, reliably tracking whether or not you're in a string literal is
> about as much fun as writing a JavaScript parser.  In fact, it might be
> *exactly* as fun, if you know what I mean.
>

String literals have to be known at parse time, so it seems to me all you
have to look for is start/stop quotes (of both sorts) while handling
embedded ones of the wrong variety and escaped ones of the right variety.
That looks like it can be handled with a single character lookahead scanner,
and very little complexity -- what am I missing?

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] New members messages currently moderated to prevent spam

[Sumit Chandel]

Dear Contributors,

Unfortunately, the GWT Contributors Group has been getting a lot of
spam attacks as of late and most spam posts have been making it
through. To fight against these spam attacks, we will be temporarily
moderating messages posted by new members to the group.

The GWT contributor forum will still be as accessible as ever, we will
post any message relevant to GWT without hesitation. We're only
putting this moderation policy in place to deal with the spam.

Our apologies for the inconvenience this poses to new contributors.

Thanks,
-Sumit Chandel
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5219 - Removing old change branch; everything is committed to trunk now.

[codesite-noreply]

Author: sco...@google.com
Date: Mon Apr 13 13:47:35 2009
New Revision: 5219

Removed:
changes/scottb/memory/

Log:
Removing old change branch; everything is committed to trunk now.



--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5218 - DatePicker throws an IllegalStateException when it is used in a time zone where daylight ...

[codesite-noreply]

Author: jlaba...@google.com
Date: Mon Apr 13 13:46:34 2009
New Revision: 5218

Added:
 
trunk/user/test/com/google/gwt/user/datepicker/client/CalendarUtilTest.java
(contents, props changed)
Modified:
trunk/user/src/com/google/gwt/user/datepicker/client/CalendarUtil.java
trunk/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
trunk/user/test/com/google/gwt/user/UISuite.java
trunk/user/test/com/google/gwt/user/client/ui/DateBoxTest.java

Log:
DatePicker throws an IllegalStateException when it is used in a time zone  
where daylight savings time occurs at midnight.  The problem is that, as  
the DatePicker populates the dates in the calendar, it uses a time of  
00:00:00 for all dates.  However, in countries where DST occurs at  
midnight, the dates are coerced to the next day, resulting in an invalid  
state.

With this patch, DatePicker uses a time of noon instead of midnight. DST  
always occurs between midnight and 5am, so noon is safe.  This patch also  
fixes a broken test that uses date.toString() instead of formatting the  
date for the DateBox being testing.

Patch by: jlabanca
Review by: rjrjr



Modified:  
trunk/user/src/com/google/gwt/user/datepicker/client/CalendarUtil.java
==
--- trunk/user/src/com/google/gwt/user/datepicker/client/CalendarUtil.java  
 
(original)
+++ trunk/user/src/com/google/gwt/user/datepicker/client/CalendarUtil.java  
 
Mon Apr 13 13:46:34 2009
@@ -97,15 +97,11 @@
 * @return the different
 */
public static int getDaysBetween(Date start, Date finish) {
-if (hasTime(start)) {
-  start = copyDate(start);
-  resetTime(start);
-}
-
-if (hasTime(finish)) {
-  finish = copyDate(finish);
-  resetTime(finish);
-}
+// Convert the dates to the same time
+start = copyDate(start);
+resetTime(start);
+finish = copyDate(finish);
+resetTime(finish);

  long aTime = start.getTime();
  long bTime = finish.getTime();
@@ -127,6 +123,22 @@
}

/**
+   * Check if two dates represent the same date of the same year, even if  
they
+   * have different times.
+   *
+   * @param date0 a date
+   * @param date1 a second date
+   * @return true if the dates are the same
+   */
+  public static boolean isSameDate(Date date0, Date date1) {
+assert date0 != null : "date0 cannot be null";
+assert date1 != null : "date1 cannot be null";
+return date0.getYear() == date1.getYear()
+&& date0.getMonth() == date1.getMonth()
+&& date0.getDate() == date1.getDate();
+  }
+
+  /**
 * Sets a date object to be at the beginning of the month and no time
 * specified.
 *
@@ -137,11 +149,6 @@
  date.setDate(1);
}

-  static boolean hasTime(Date start) {
-return start.getHours() != 0 || start.getMinutes() != 0
-|| start.getSeconds() != 0;
-  }
-
/**
 * Is a day in the week a weekend?
 *
@@ -162,7 +169,9 @@
  msec = (msec / 1000) * 1000;
  date.setTime(msec);

-date.setHours(0);
+// Daylight savings time occurs at midnight in some time zones, so we  
reset
+// the time to noon instead.
+date.setHours(12);
  date.setMinutes(0);
  date.setSeconds(0);
}

Modified:  
trunk/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
==
--- trunk/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
 
(original)
+++ trunk/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
 
Mon Apr 13 13:46:34 2009
@@ -458,7 +458,8 @@
  CalendarView r = getView();
  Date first = r.getFirstDate();
  Date last = r.getLastDate();
-return (date != null && (first.equals(date) || last.equals(date) ||  
(first.before(date) && last.after(date;
+return (date != null && (CalendarUtil.isSameDate(first, date)
+|| CalendarUtil.isSameDate(last, date) || (first.before(date) &&  
last.after(date;
}

@Override

Modified: trunk/user/test/com/google/gwt/user/UISuite.java
==
--- trunk/user/test/com/google/gwt/user/UISuite.java(original)
+++ trunk/user/test/com/google/gwt/user/UISuite.javaMon Apr 13 13:46:34  
2009
@@ -85,6 +85,7 @@
  import com.google.gwt.user.client.ui.WidgetSubclassingTest;
  import com.google.gwt.user.client.ui.WidgetTest;
  import com.google.gwt.user.client.ui.impl.ClippedImagePrototypeTest;
+import com.google.gwt.user.datepicker.client.CalendarUtilTest;
  import com.google.gwt.user.datepicker.client.DateChangeEventTest;
  import com.google.gwt.user.rebind.ui.ImageBundleGeneratorTest;
  import com.google.gwt.xml.client.XMLTest;
@@ -109,6 +110,7 @@
  suite.addTestSuite(CompositeTest.class);
  suite.addTestSuite(CookieTest.class);
  suite.addTestSuite(CustomButtonTest.class);
+suite.addT

[gwt-contrib] Re: DatePicker failure when DST occurs at midnight

[Ray Ryan]

LGTM
On Mon, Apr 13, 2009 at 1:29 PM,  wrote:

> Reviewers: rjrjr,
>
> Description:
> The DatePicker throws an IllegalStateException when it is used in a time
> zone where daylight savings time occurs at midnight.  The problem is
> that, as the DatePicker populates the dates in the calendar, it uses a
> time of 00:00:00 for all dates.  However, in countries where DST occurs
> at midnight, the dates are coerced to the next day, resulting in an
> invalid state.
>
> With this patch, DatePicker uses a time of noon instead of midnight.
> DST always occurs between midnight and 5am, so noon is safe.
>
> This patch also fixes a broken test that uses date.toString() instead of
> formatting the date for the DateBox being testing.
>
> Finally, this patch adds tests for CalendarUtil, which provides many
> useful calendar functions.
>
> Please review this at http://gwt-code-reviews.appspot.com/22801
>
> Affected files:
>  user/src/com/google/gwt/user/datepicker/client/CalendarUtil.java
>  user/src/com/google/gwt/user/datepicker/client/DatePicker.java
>  user/test/com/google/gwt/user/UISuite.java
>  user/test/com/google/gwt/user/client/ui/DateBoxTest.java
>  user/test/com/google/gwt/user/datepicker/client/CalendarUtilTest.java
>
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT-RPC broken in GAE/J

[noon]

Hi,

I fully agree with Miguel analysis and solution proposal.
In my mind, I wrote Gilead as just a serialization adapter for
Hibernate objects, and similar work should have to be done for
DataNucleus, OpenJPA and al (by the supplier of such libraries, or
community...)

Can we have the "official GWT team" point of view about it ?

Regards
Bruno

On 13 avr, 19:04, Miguel Ping  wrote:
> I discovered the hard way that GWT and ORM needs some custom code.
> IMHO, the real problem is that class enhancers do not provide a way to
> unenhance an instance according to some rules. I ended up writing my
> custom bean copier based on dozer and beanmapper, so I can specify a
> shallow/deep clone, though most of the times I'll just be getting rid
> of proxies, since I fetch ahead what I know  I'll need.
>
> To my understanding, GWT-like applications (read: the service layer)
> don't need lazy load for most of the time; lazy load works most for
> open-session-in-view. I think almost all devs code to fetch the needed
> objets up front anyway.
>
> The real problem for me is the following:
> - I want to send an enhanced object over the wire.
> - The object may or may not be serializable due to class enhancing.
> - My object class declaration is fully serializable (but the
> underlying type may not be due to proxies).
>
> I think we have two choices:
> - copy the object to a fully serializable class using some bean mapper
> with some rules
> - describe a way to convert the proxied/enhanced class to an
> unenhanced one, again with some rules
>
> Both these ways benefit from an extensible serialization mechanism in
> GWT. In the end, I'd like to see a plugin mechanism from GWT to
> provide custom (de)serializers for RPC mechanisms, and a simple way of
> "dehydrating" a persistent/enhanced class through some rules.
>
> On Apr 12, 11:41 am, Sami Jaber  wrote:
>
> > Absolutely Ray, PB violates DRY principles and could be easily handled as a
> > specific adaptor in the whole extensibility model.
>
> > This idea is to agree on an extensibility pattern similar to the way one
> > extend RPC processCall(). CFS (Custom Field Serializer) may be an answer but
> > they are supposed to be removed in further versions.
>
> > Customizing the JDO enhancer certainly does the trick but responds to a
> > global problem by a specific solution. The main ORM used today is Hibernate
> > (thru JPA with annotations or XML files), DataNucleus will probably gain
> > momentum with AppEngine but people are waiting responses in priority for
> > their ORM implementation.
>
> > To finish on the Latency, this problem is not specific to GWT/ORM but to ORM
> > in general. Anyone who uses ORM should take care of FetchGroup,
> > EagerFetching, N+1 select and minimizing roundtrip.
>
> > The way Hibernate4GWT solves this problem should be a starting point of
> > thinking IMHO. This Framework looks like complex because of the lack of
> > extensibility model in the serialization process, it is up to us (or GWT
> > team) to simplify this mechanism.
>
> > Hope (you would) help
>
> > Sami
>
> > On Sat, Apr 11, 2009 at 7:30 PM, Ray Cromwell  wrote:
>
> > > One possibility might be to add features to the JDO enhancer to spit
> > > out Java source for IsSerializable tagged classes instead of just
> > > generating enhanced byte code. This code could then be seen by the GWT
> > > compiler. In which case, all of the extra jdo methods, as well as
> > > jdoDetachedState would be on the object. You could even emit custom
> > > serializers.
>
> > > However, I am nervous about the idea of sending actual detached
> > > objects over the wire. The philosophy of GWT is to minimize latency,
> > > by reducing HTTP requests and wire size. People might have a tendency
> > > to blindly ship detached instances over the wire, which could result
> > > in either too much serialized data being sent, or too much lazy
> > > fetching. It is true that JDO allows fetch groups to control this, but
> > > it seems like it would more consideration to the client than is usual
> > > for JDO clients, as it seems many people using ORMs are trying to
> > > optimize RDBMS performance, not serialization performance.
>
> > > That's why I like the PB approach, because with PB's, it's very clear
> > > that cycles can't occur, that optional nullable fields take up no
> > > space, and that relations require explicit fetching on the client. The
> > > downside is, it violates DRY, and I agree, I hate the DTO pattern.
>
> > > I am not really an expert in the ORM domain, so the datanucleus guys
> > > probably have alot better recommendations for patterns on using JDO to
> > > minimize fetching and wire-size.
>
> > > I do think that with Datanucleus's help, there can probably be a real
> > > solution, and if done right, perhaps one that addresses common
> > > mistakes people make with wire-size and latency.
>
> > > -Ray
>
> > > On Sat, Apr 11, 2009 at 2:34 AM, datanucleus 
> > > wrote:
>
> > > > Hi,
> > > > didn't see th

[gwt-contrib] Code review: SerializabilityUtil race condition

[Scott Blum]

Hi Bob,
Please review the attached patch to fix the SerializabilityUtil race
condition.  I don't want to commit this until we actually have a failed
build that verifies the problem (per the TBR you did over the weekend), but
I'd like to have the fix queued up and ready to go as soon as it does pop
up.

Thanks,
Scott

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---



rpc-race-condition.patch
Description: Binary data

[gwt-contrib] DatePicker failure when DST occurs at midnight

[jlabanca]

Reviewers: rjrjr,

Description:
The DatePicker throws an IllegalStateException when it is used in a time
zone where daylight savings time occurs at midnight.  The problem is
that, as the DatePicker populates the dates in the calendar, it uses a
time of 00:00:00 for all dates.  However, in countries where DST occurs
at midnight, the dates are coerced to the next day, resulting in an
invalid state.

With this patch, DatePicker uses a time of noon instead of midnight.
DST always occurs between midnight and 5am, so noon is safe.

This patch also fixes a broken test that uses date.toString() instead of
formatting the date for the DateBox being testing.

Finally, this patch adds tests for CalendarUtil, which provides many
useful calendar functions.

Please review this at http://gwt-code-reviews.appspot.com/22801

Affected files:
   user/src/com/google/gwt/user/datepicker/client/CalendarUtil.java
   user/src/com/google/gwt/user/datepicker/client/DatePicker.java
   user/test/com/google/gwt/user/UISuite.java
   user/test/com/google/gwt/user/client/ui/DateBoxTest.java
   user/test/com/google/gwt/user/datepicker/client/CalendarUtilTest.java



--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Scott Blum]

If we were playing Mao, I would give you a card penalty for stating the
obvious. :-)

But uh, reliably tracking whether or not you're in a string literal is about
as much fun as writing a JavaScript parser.  In fact, it might be *exactly*
as fun, if you know what I mean.

On Mon, Apr 13, 2009 at 3:13 PM, John Tamplin  wrote:

> On Mon, Apr 13, 2009 at 2:55 PM, Scott Blum  wrote:
>
>> Actually, I am going to have to torpedo this (sorry!).  It just occurred
>> to me that while comments are only a hypothetical problem, string literals
>> are a real, actual problem that could cause problems today.  A string
>> literal with mismatched curly braces would break this.
>>
>
> You could avoid that problem by tracking when you are in a string literal.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5217 - Merging tr...@5215:5216 into branch.

[codesite-noreply]

Author: jlaba...@google.com
Date: Mon Apr 13 12:45:26 2009
New Revision: 5217

Modified:
branches/snapshot-2009.03.30-r5111/branch-info.txt
 
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImpl.java
 
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplIE6.java
 
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplSafari.java
 
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/Document.java
 
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/Element.java
 
branches/snapshot-2009.03.30-r5111/user/test/com/google/gwt/dom/client/ElementTest.java

Log:
Merging tr...@5215:5216 into branch.
- Fixes a bug with getScrollLeft in RTL mode.

svn merge -r5215:5216 https://google-web-toolkit.googlecode.com/svn/trunk .

Patch by: jlabanca




Modified: branches/snapshot-2009.03.30-r5111/branch-info.txt
==
--- branches/snapshot-2009.03.30-r5111/branch-info.txt  (original)
+++ branches/snapshot-2009.03.30-r5111/branch-info.txt  Mon Apr 13 12:45:26  
2009
@@ -9,3 +9,4 @@
  A rollback of /tr...@c4974 and /tr...@c4943 was merged (r5137) into this  
branch to undo a compiler bug breaking method overrides
  Added imports to GenerateJavaAST so it would compile (r5138)
  A rollback of /tr...@c5075 was merged (r5198) into this branch to undo a  
compiler bug breaking custom field serializers
+/trunk/@5215:5216 was merged (r) into this branch to fix a scrollLeft  
bug in RTL

Modified:  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImpl.java
==
---  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImpl.java
   
(original)
+++  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImpl.java
   
Mon Apr 13 12:45:26 2009
@@ -224,6 +224,10 @@
  return doc.getViewportElement().getScrollLeft();
}

+  public native int getScrollLeft(Element elem) /*-{
+return elem.scrollLeft || 0;
+  }-*/;
+
public int getScrollTop(Document doc) {
  return doc.getViewportElement().getScrollTop();
}
@@ -309,6 +313,10 @@
public void setScrollLeft(Document doc, int left) {
  doc.getViewportElement().setScrollLeft(left);
}
+
+  public native void setScrollLeft(Element elem, int left) /*-{
+elem.scrollLeft = left;
+  }-*/;

public void setScrollTop(Document doc, int top) {
  doc.getViewportElement().setScrollTop(top);

Modified:  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplIE6.java
==
---  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplIE6.java

(original)
+++  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplIE6.java

Mon Apr 13 12:45:26 2009
@@ -193,6 +193,14 @@
  return elem.parentElement;
}-*/;

+  @Override
+  public int getScrollLeft(Element elem) {
+if (isRTL(elem)) {
+  return super.getScrollLeft(elem) - (elem.getScrollWidth() -  
elem.getClientWidth());
+}
+return super.getScrollLeft(elem);
+  }
+
/*
 * The src may not be set yet because of funky logic in setImgSrc(). See
 * setImgSrc().
@@ -237,6 +245,14 @@
  elem.innerText = text || '';
}-*/;

+  @Override
+  public void setScrollLeft(Element elem, int left) {
+if (isRTL(elem)) {
+  left += elem.getScrollWidth() - elem.getClientWidth();
+}
+super.setScrollLeft(elem, left);
+  }
+
private 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
@@ -286,4 +302,8 @@
  doc.getBody().getOffsetWidth();
  }
}
+
+  private native boolean isRTL(Element elem) /*-{
+return elem.currentStyle.direction == 'rtl';
+  }-*/;
  }

Modified:  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplSafari.java
==
---  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplSafari.java
 
(original)
+++  
branches/snapshot-2009.03.30-r5111/user/src/com/google/gwt/dom/client/DOMImplSafari.java
 
Mon Apr 13 12:45:26 2009
@@ -155,6 +155,14 @@
}

@Override
+  public int getScrollLeft(Element elem) {
+if (isRTL(elem)) {
+  return super.getScrollLeft(elem) - (elem.getScrollWidth() -  
elem.getClientWidth());
+}
+return super.getScrollLeft(elem);
+  }
+
+  @Override
public int getScrollTop(Document doc) {
  // Safari always applies document scrolling to the body element, even  
in
  // strict mode.
@@ -213,9 +221,21 @@
}

@Overri

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[John Tamplin]

On Mon, Apr 13, 2009 at 2:55 PM, Scott Blum  wrote:

> Actually, I am going to have to torpedo this (sorry!).  It just occurred to
> me that while comments are only a hypothetical problem, string literals are
> a real, actual problem that could cause problems today.  A string literal
> with mismatched curly braces would break this.
>

You could avoid that problem by tracking when you are in a string literal.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5216 - IE and WebKit report incorrect values for scroll-left in RTL mode, and I've normalized on...

[codesite-noreply]

Author: jlaba...@google.com
Date: Mon Apr 13 12:21:06 2009
New Revision: 5216

Modified:
trunk/user/src/com/google/gwt/dom/client/DOMImpl.java
trunk/user/src/com/google/gwt/dom/client/DOMImplIE6.java
trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
trunk/user/src/com/google/gwt/dom/client/Document.java
trunk/user/src/com/google/gwt/dom/client/Element.java
trunk/user/test/com/google/gwt/dom/client/ElementTest.java

Log:
IE and WebKit report incorrect values for scroll-left in RTL mode, and I've  
normalized on what Firefox does, which is to report negative offsets from  
the right edge. This makes the absolute-positioning math work out properly,  
and is what other toolkits seem to have standardized on as well.

Patch by: jgw
Review by: jlabanca



Modified: trunk/user/src/com/google/gwt/dom/client/DOMImpl.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImpl.java   (original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImpl.java   Mon Apr 13  
12:21:06 2009
@@ -224,6 +224,10 @@
  return doc.getViewportElement().getScrollLeft();
}

+  public native int getScrollLeft(Element elem) /*-{
+return elem.scrollLeft || 0;
+  }-*/;
+
public int getScrollTop(Document doc) {
  return doc.getViewportElement().getScrollTop();
}
@@ -309,6 +313,10 @@
public void setScrollLeft(Document doc, int left) {
  doc.getViewportElement().setScrollLeft(left);
}
+
+  public native void setScrollLeft(Element elem, int left) /*-{
+elem.scrollLeft = left;
+  }-*/;

public void setScrollTop(Document doc, int top) {
  doc.getViewportElement().setScrollTop(top);

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 Apr 13  
12:21:06 2009
@@ -193,6 +193,14 @@
  return elem.parentElement;
}-*/;

+  @Override
+  public int getScrollLeft(Element elem) {
+if (isRTL(elem)) {
+  return super.getScrollLeft(elem) - (elem.getScrollWidth() -  
elem.getClientWidth());
+}
+return super.getScrollLeft(elem);
+  }
+
/*
 * The src may not be set yet because of funky logic in setImgSrc(). See
 * setImgSrc().
@@ -237,6 +245,14 @@
  elem.innerText = text || '';
}-*/;

+  @Override
+  public void setScrollLeft(Element elem, int left) {
+if (isRTL(elem)) {
+  left += elem.getScrollWidth() - elem.getClientWidth();
+}
+super.setScrollLeft(elem, left);
+  }
+
private 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
@@ -286,4 +302,8 @@
  doc.getBody().getOffsetWidth();
  }
}
+
+  private native boolean isRTL(Element elem) /*-{
+return elem.currentStyle.direction == 'rtl';
+  }-*/;
  }

Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java (original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java Mon Apr 13  
12:21:06 2009
@@ -155,6 +155,14 @@
}

@Override
+  public int getScrollLeft(Element elem) {
+if (isRTL(elem)) {
+  return super.getScrollLeft(elem) - (elem.getScrollWidth() -  
elem.getClientWidth());
+}
+return super.getScrollLeft(elem);
+  }
+
+  @Override
public int getScrollTop(Document doc) {
  // Safari always applies document scrolling to the body element, even  
in
  // strict mode.
@@ -213,9 +221,21 @@
}

@Override
+  public void setScrollLeft(Element elem, int left) {
+if (isRTL(elem)) {
+  left += elem.getScrollWidth() - elem.getClientWidth();
+}
+super.setScrollLeft(elem, left);
+  }
+
+  @Override
public void setScrollTop(Document doc, int top) {
  // Safari always applies document scrolling to the body element, even  
in
  // strict mode.
  doc.getBody().setScrollTop(top);
}
+
+  private native boolean isRTL(Element elem) /*-{
+return $wnd.getComputedStyle(elem).direction == 'rtl';
+  }-*/;
  }

Modified: trunk/user/src/com/google/gwt/dom/client/Document.java
==
--- trunk/user/src/com/google/gwt/dom/client/Document.java  (original)
+++ trunk/user/src/com/google/gwt/dom/client/Document.java  Mon Apr 13  
12:21:06 2009
@@ -889,6 +889,15 @@
}

/**
+   * Creates an  element.
+   *
+   * @return the newly created element
+   */
+  public final InputElement createSubmitInputElement() {
+return DOMImpl.impl.createInputElement(this, "submit");
+ 

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[BobV]

On Mon, Apr 13, 2009 at 2:55 PM, Scott Blum  wrote:
> Actually, I am going to have to torpedo this (sorry!).  It just occurred to
> me that while comments are only a hypothetical problem, string literals are
> a real, actual problem that could cause problems today.  A string literal
> with mismatched curly braces would break this.

Duh.  Right, time to rewrite this.

-- 
Bob Vawter
Google Web Toolkit Team

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Scott Blum]

Actually, I am going to have to torpedo this (sorry!).  It just occurred to
me that while comments are only a hypothetical problem, string literals are
a real, actual problem that could cause problems today.  A string literal
with mismatched curly braces would break this.
I know it seems hacky, but it actually would be better to compute split
points in JsSourceGeneration, I think.  If you wait until Link, you have to
use things like character counts or line counts as a heuristic.  But doing
it when you still have the JS AST allows you to be much smarter about when
to break.  You could count things like number of statements or decls or
things like that.

I also have to mention that all else being equal, it would be REALLY nice to
use the exact same split points in PRETTY/DETAILED as OBFUSCATED.

On Mon, Apr 13, 2009 at 2:47 PM, BobV  wrote:

> On Mon, Apr 13, 2009 at 2:40 PM,   wrote:
> > The code LG, one high-level comment about the design.  Assuming we're ok
> > with the design implications, this seems good.
>
> The never-fail way to do this would be to have JsSourceGeneration
> visitor indicate offset values of top-level statements in the strings
> that it generates.  Then the offset data needs to be threaded back
> from JavaToJavaScriptCompiler back through the PermutationResult and
> then onto the Linker API.  It's doable, but somehow it feels like it's
> littering more junk around the compiler.
>
> So does anyone want to veto the block-depth-counting approach?
>
> --
> Bob Vawter
> Google Web Toolkit Team
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[BobV]

On Mon, Apr 13, 2009 at 2:40 PM,   wrote:
> The code LG, one high-level comment about the design.  Assuming we're ok
> with the design implications, this seems good.

The never-fail way to do this would be to have JsSourceGeneration
visitor indicate offset values of top-level statements in the strings
that it generates.  Then the offset data needs to be threaded back
from JavaToJavaScriptCompiler back through the PermutationResult and
then onto the Linker API.  It's doable, but somehow it feels like it's
littering more junk around the compiler.

So does anyone want to veto the block-depth-counting approach?

-- 
Bob Vawter
Google Web Toolkit Team

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[scottb]

The code LG, one high-level comment about the design.  Assuming we're ok
with the design implications, this seems good.


http://gwt-code-reviews.appspot.com/21801/diff/1/2
File
dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
(right):

http://gwt-code-reviews.appspot.com/21801/diff/1/2#newcode419
Line 419: private void segmentJs(StringBuilder b, CharSequence js) {
It's true that we presently never emit comments into the JS, but we need
to be keenly aware that this technique will break in the face of
comments because this depth-tracking technique won't be reliable.

http://gwt-code-reviews.appspot.com/21801

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT-RPC broken in GAE/J

[Miguel Ping]

I discovered the hard way that GWT and ORM needs some custom code.
IMHO, the real problem is that class enhancers do not provide a way to
unenhance an instance according to some rules. I ended up writing my
custom bean copier based on dozer and beanmapper, so I can specify a
shallow/deep clone, though most of the times I'll just be getting rid
of proxies, since I fetch ahead what I know  I'll need.

To my understanding, GWT-like applications (read: the service layer)
don't need lazy load for most of the time; lazy load works most for
open-session-in-view. I think almost all devs code to fetch the needed
objets up front anyway.

The real problem for me is the following:
- I want to send an enhanced object over the wire.
- The object may or may not be serializable due to class enhancing.
- My object class declaration is fully serializable (but the
underlying type may not be due to proxies).

I think we have two choices:
- copy the object to a fully serializable class using some bean mapper
with some rules
- describe a way to convert the proxied/enhanced class to an
unenhanced one, again with some rules

Both these ways benefit from an extensible serialization mechanism in
GWT. In the end, I'd like to see a plugin mechanism from GWT to
provide custom (de)serializers for RPC mechanisms, and a simple way of
"dehydrating" a persistent/enhanced class through some rules.

On Apr 12, 11:41 am, Sami Jaber  wrote:
> Absolutely Ray, PB violates DRY principles and could be easily handled as a
> specific adaptor in the whole extensibility model.
>
> This idea is to agree on an extensibility pattern similar to the way one
> extend RPC processCall(). CFS (Custom Field Serializer) may be an answer but
> they are supposed to be removed in further versions.
>
> Customizing the JDO enhancer certainly does the trick but responds to a
> global problem by a specific solution. The main ORM used today is Hibernate
> (thru JPA with annotations or XML files), DataNucleus will probably gain
> momentum with AppEngine but people are waiting responses in priority for
> their ORM implementation.
>
> To finish on the Latency, this problem is not specific to GWT/ORM but to ORM
> in general. Anyone who uses ORM should take care of FetchGroup,
> EagerFetching, N+1 select and minimizing roundtrip.
>
> The way Hibernate4GWT solves this problem should be a starting point of
> thinking IMHO. This Framework looks like complex because of the lack of
> extensibility model in the serialization process, it is up to us (or GWT
> team) to simplify this mechanism.
>
> Hope (you would) help
>
> Sami
>
> On Sat, Apr 11, 2009 at 7:30 PM, Ray Cromwell  wrote:
>
> > One possibility might be to add features to the JDO enhancer to spit
> > out Java source for IsSerializable tagged classes instead of just
> > generating enhanced byte code. This code could then be seen by the GWT
> > compiler. In which case, all of the extra jdo methods, as well as
> > jdoDetachedState would be on the object. You could even emit custom
> > serializers.
>
> > However, I am nervous about the idea of sending actual detached
> > objects over the wire. The philosophy of GWT is to minimize latency,
> > by reducing HTTP requests and wire size. People might have a tendency
> > to blindly ship detached instances over the wire, which could result
> > in either too much serialized data being sent, or too much lazy
> > fetching. It is true that JDO allows fetch groups to control this, but
> > it seems like it would more consideration to the client than is usual
> > for JDO clients, as it seems many people using ORMs are trying to
> > optimize RDBMS performance, not serialization performance.
>
> > That's why I like the PB approach, because with PB's, it's very clear
> > that cycles can't occur, that optional nullable fields take up no
> > space, and that relations require explicit fetching on the client. The
> > downside is, it violates DRY, and I agree, I hate the DTO pattern.
>
> > I am not really an expert in the ORM domain, so the datanucleus guys
> > probably have alot better recommendations for patterns on using JDO to
> > minimize fetching and wire-size.
>
> > I do think that with Datanucleus's help, there can probably be a real
> > solution, and if done right, perhaps one that addresses common
> > mistakes people make with wire-size and latency.
>
> > -Ray
>
> > On Sat, Apr 11, 2009 at 2:34 AM, datanucleus 
> > wrote:
>
> > > Hi,
> > > didn't see this thread since I tried on the main GWT group. See
>
> >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
>
> > > Having your RPC generator recognise JDO/JPA annotations isn't a way to
> > > go since the user may have defined persistence in XML. The one thing
> > > is, the field is always called jdoDetachedState so can't this be
> > > recognised ? (non-GWT person here so excuse stupid questions ;-) ).
>
> > > Ray's workaround (of using transient) obviously will work, and we
> > > (DataNucleus) could provide complet

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Bruce Johnson]

On Mon, Apr 13, 2009 at 12:39 PM,  wrote:

> Discussion:
>  - What is the correct chunk size?


It seems like this could (and should) be determined by an experiment.

  - Can runAsync fragments take advantage of this?


One (possibly crazy) way in which we could do this is to chunk up the JS
such that it evals clusters of declarations in a timer-controlled loop. The
semantics are compatible because we wouldn't call the runAsync() handler
until the last timer iteration has completed. IOW, it doesn't break the
API.

However, we might have to implement the fast deferred command trick (i.e.
bypass setTimeout() minimums) to make this acceptably fast.

  - Would in increase in total number of round-trips in XS-mode make
> this technique worthwhile, when the developer could more aggressively
> adopt runAsync to reduce the initial fragment size?


Perhaps if the wacky timer-loop suggestion above works, this questions could
become moot.

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] RR : Chunk the JavaScript in the initial fragment

[bobv]

Reviewers: bruce, scottb, knorton, spoon,

Description:
This patch will alter the encoding of the initial fragment so that the
browser will evaluate it in chunks.  Chunking the evaluation has
beneficial usability effects because the browser will periodically
unblock the event loop and this helps to offset any super-linear
behavior in JS parsing and evaluation in larger scripts.

Discussion:
   - What is the correct chunk size?
   - Can runAsync fragments take advantage of this?
   - Would in increase in total number of round-trips in XS-mode make
this technique worthwhile, when the developer could more aggressively
adopt runAsync to reduce the initial fragment size?

Please review this at http://gwt-code-reviews.appspot.com/21801

Affected files:

dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
   dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
   dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java



--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5215 - Some user-agents return status code 0 when operating off of file: URLs.

[codesite-noreply]

Author: b...@google.com
Date: Mon Apr 13 08:41:09 2009
New Revision: 5215

Modified:
trunk/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java

Log:
Some user-agents return status code 0 when operating off of file: URLs.

Patch by: bobv
Review by: scottb


Modified: trunk/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
==
--- trunk/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java   
(original)
+++ trunk/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java  Mon  
Apr 13 08:41:09 2009
@@ -116,7 +116,7 @@
super("HTTP download failed with status " + statusCode);
this.statusCode = statusCode;
  }
-
+
  public int getStatusCode() {
return statusCode;
  }
@@ -169,6 +169,12 @@

private static final String HTTP_GET = "GET";

+  /**
+   * Some UA's like Safari will have a "0" status code when loading from  
file:
+   * URLs.
+   */
+  private static final int HTTP_STATUS_LOCAL = 0;
+
private static final int HTTP_STATUS_OK = 200;

/**
@@ -365,14 +371,16 @@
  public void onReadyStateChange(XMLHttpRequest xhr) {
if (xhr.getReadyState() == XMLHttpRequest.DONE) {
  xhr.clearOnReadyStateChange();
-if (xhr.getStatus() == HTTP_STATUS_OK) {
+if (xhr.getStatus() == HTTP_STATUS_OK
+|| xhr.getStatus() == HTTP_STATUS_LOCAL) {
try {
  installCode(xhr.getResponseText());
} catch (RuntimeException e) {
  loadErrorHandler.loadFailed(e);
}
  } else {
-  loadErrorHandler.loadFailed(new  
HttpDownloadFailure(xhr.getStatus()));
+  loadErrorHandler.loadFailed(new HttpDownloadFailure(
+  xhr.getStatus()));
  }
}
  }

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Fix runAsync with file: URLs in Safari, Firefox

[BobV]

On Mon, Apr 13, 2009 at 11:38 AM, Scott Blum  wrote:
> LGTM.

Thanks. Committed at r5215.

-- 
Bob Vawter
Google Web Toolkit Team

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Fix runAsync with file: URLs in Safari, Firefox

[Scott Blum]

LGTM.

On Mon, Apr 13, 2009 at 11:14 AM,  wrote:

> Reviewers: spoon, scottb,
>
> Description:
> Some user-agents return status code 0 when operating off of file: URLs.
> This patch gets Showcase working from local files.
>
> Please review this at http://gwt-code-reviews.appspot.com/20801
>
> Affected files:
>  user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
>
>
> Index: user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
> ===
> --- user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
>  (revision 5214)
> +++ user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
>  (working copy)
> @@ -116,7 +116,7 @@
>   super("HTTP download failed with status " + statusCode);
>   this.statusCode = statusCode;
> }
> -
> +
> public int getStatusCode() {
>   return statusCode;
> }
> @@ -169,6 +169,12 @@
>
>   private static final String HTTP_GET = "GET";
>
> +  /**
> +   * Some UA's like Safari will have a "0" status code when loading from
> file:
> +   * URLs.
> +   */
> +  private static final int HTTP_STATUS_LOCAL = 0;
> +
>   private static final int HTTP_STATUS_OK = 200;
>
>   /**
> @@ -365,14 +371,16 @@
> public void onReadyStateChange(XMLHttpRequest xhr) {
>   if (xhr.getReadyState() == XMLHttpRequest.DONE) {
> xhr.clearOnReadyStateChange();
> -if (xhr.getStatus() == HTTP_STATUS_OK) {
> +if (xhr.getStatus() == HTTP_STATUS_OK
> +|| xhr.getStatus() == HTTP_STATUS_LOCAL) {
>   try {
> installCode(xhr.getResponseText());
>   } catch (RuntimeException e) {
> loadErrorHandler.loadFailed(e);
>   }
> } else {
> -  loadErrorHandler.loadFailed(new
> HttpDownloadFailure(xhr.getStatus()));
> +  loadErrorHandler.loadFailed(new HttpDownloadFailure(
> +  xhr.getStatus()));
> }
>   }
> }
>
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] RR : Fix runAsync with file: URLs in Safari, Firefox

[bobv]

Reviewers: spoon, scottb,

Description:
Some user-agents return status code 0 when operating off of file: URLs.
This patch gets Showcase working from local files.

Please review this at http://gwt-code-reviews.appspot.com/20801

Affected files:
   user/src/com/google/gwt/core/client/AsyncFragmentLoader.java


Index: user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
===
--- user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
(revision  
5214)
+++ user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
(working  
copy)
@@ -116,7 +116,7 @@
super("HTTP download failed with status " + statusCode);
this.statusCode = statusCode;
  }
-
+
  public int getStatusCode() {
return statusCode;
  }
@@ -169,6 +169,12 @@

private static final String HTTP_GET = "GET";

+  /**
+   * Some UA's like Safari will have a "0" status code when loading from  
file:
+   * URLs.
+   */
+  private static final int HTTP_STATUS_LOCAL = 0;
+
private static final int HTTP_STATUS_OK = 200;

/**
@@ -365,14 +371,16 @@
  public void onReadyStateChange(XMLHttpRequest xhr) {
if (xhr.getReadyState() == XMLHttpRequest.DONE) {
  xhr.clearOnReadyStateChange();
-if (xhr.getStatus() == HTTP_STATUS_OK) {
+if (xhr.getStatus() == HTTP_STATUS_OK
+|| xhr.getStatus() == HTTP_STATUS_LOCAL) {
try {
  installCode(xhr.getResponseText());
} catch (RuntimeException e) {
  loadErrorHandler.loadFailed(e);
}
  } else {
-  loadErrorHandler.loadFailed(new  
HttpDownloadFailure(xhr.getStatus()));
+  loadErrorHandler.loadFailed(new HttpDownloadFailure(
+  xhr.getStatus()));
  }
}
  }



--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---