Re: [gwt-contrib] Re: Add README step to use the Google Web Toolkit SDK in the gwt-user project so that users can run ... (issue966802)
Actually, I'm not sure that this is accurate. I just tried it out against gwt-user and gwt-dev with natures and builders on in a clean eclipse Helios install (no GPE) and I did not see any exceptions thrown. There were no visible exceptions and the error log was not updated. It seems worth it to take a look and see if it is eclipse version specific. On Wed, Nov 24, 2010 at 10:31 AM, rda...@google.com wrote: I think that jat is right - if you have a builder defined on your project that Eclipse does not know about, it will throw an exception. For now, let's go with this update to the README. I think, as a future step, we should add the natures and builders to the gwt-user and gwt-dev project, and make it a necessary step for them to install GPE. http://gwt-code-reviews.appspot.com/966802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics
On Fri, Nov 12, 2010 at 5:34 AM, yves yves.ko...@gmail.com wrote: @Jeff As you suggested me, I tried the followig without success (same OOME problem): public class ResultNodeT extends IResultNode implements IResultNode and public interface IResultNode extends Result Again this is syntaxically correct and compiles sucessfully with javac, BUT gives again the OOME problem with the GWT compiler. So apprently the problem is NOT due to the self-referenced generics ResulNodeT extends ResultNode? @Miguel As youl suggests in your link, is the problem the serialization of an array of type T : T[] next; ? As a workarround, I'll try to replace this array T[] by an ArrayListT which serializes without know issue. Yves I do suspect that T[] is the issue. @zhuyi: can you take a look at http://code.google.com/p/google-web-toolkit/issues/detail?id=5582 and let me know what you think. -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics
[+zhuyi] On Fri, Nov 12, 2010 at 9:52 AM, Miguel Méndez mmen...@google.com wrote: On Fri, Nov 12, 2010 at 5:34 AM, yves yves.ko...@gmail.com wrote: @Jeff As you suggested me, I tried the followig without success (same OOME problem): public class ResultNodeT extends IResultNode implements IResultNode and public interface IResultNode extends Result Again this is syntaxically correct and compiles sucessfully with javac, BUT gives again the OOME problem with the GWT compiler. So apprently the problem is NOT due to the self-referenced generics ResulNodeT extends ResultNode? @Miguel As youl suggests in your link, is the problem the serialization of an array of type T : T[] next; ? As a workarround, I'll try to replace this array T[] by an ArrayListT which serializes without know issue. Yves I do suspect that T[] is the issue. @zhuyi: can you take a look at http://code.google.com/p/google-web-toolkit/issues/detail?id=5582 and let me know what you think. -- Miguel -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics
@yves: What does the ResultNode class look like? It is class ResultNodeT extends ResultNode? but what about its supertype and fields? On Thu, Nov 11, 2010 at 10:50 AM, yves yves.ko...@gmail.com wrote: Chris, JConsole does not succeed to connect to the java compilation : I get an out of memory error in sun.rmi.transport.tcp.TCPTransport $AcceptLoop.executeAcceptLoop while trying to start a new thread. = Result: no data in jconsole The compiler is the one shipped with GWT 2.1.0RC1 I'll send you the output of -verbose:gc Yves On 10 nov, 23:26, Chris Conroy con...@google.com wrote: Yves, You say this error did not occur before your most recent change. It would be useful to get an idea for the memory usage before this change: it could be that your app is just very large and you were already on the edge of an OOME, your change really necessitates more memory, or this is a pathological case. Here are a few things to try for gathering more useful information: -Try attaching jconsole to the compile in the before and after scenario and see how the memory usage compares between both. -add -XX:-HeapDumpOnOutOfMemoryError to the JVM args for your failing compile. There may be some interesting data in the resulting dump. If you can share the heap dump with us (you can send me a link off list if you like), then I can take a look. -Of course, make sure you are using the latest version of the GWT compiler. The 2.1 compiler contains some changes that will reduce the memory footprint of your compile. On Wed, Nov 10, 2010 at 1:20 PM, Scott Blum sco...@google.com wrote: Hmmm what happens if you turn down the log level, say to WARN? Are you invoking from the command line, or are you using the Google Plugin for Eclipse? On Wed, Nov 10, 2010 at 4:16 PM, yves yves.ko...@gmail.com wrote: Scott, Thx for the tip. Anyway I can't allocate more than -Xmx1590M and I get exactly the same error. Yves On 9 nov, 07:47, Scott Blum sco...@google.com wrote: Hmm can you increase your virtual memory? On Mon, Nov 8, 2010 at 5:13 PM, yves yves.ko...@gmail.com wrote: I can't, I only have 2GB RAM, I get this error as from -Xmx1024M [java] Error occurred during initialization of VM [java] Could not reserve enough space for object heap [java] Could not create the Java virtual machine. and the log level is INFO Yves On 8 nov, 22:53, Scott Blum sco...@google.com wrote: What if you turn the heap up to -Xmx2048M? What log level are you using? On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com wrote: Hi, I had a class named ResultNode and the project compiled fine. In order to improve the code, I changed this class by adding generic stuff like that : ResultNodeT extends ResultNode?. Of course I adapted the entire project where needed to take advantage of this change. Now I get an Internal compiler error This is produced with java memory settings -Xmx768M and -Xss32M . (usually the settings are -Xmx128M and default value for -Xss and I never had such problem). BTW : a javac compilation on the project is succesfull, so it is not a java error. Any suggestion ? If more information is needed do not hesitate to ask. Thanks in advance Yves [java] Compiling module com.mycompany.myproject.MyProject [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/ src/com/mycompany/myproject/client/model/AppActivityMapper.java' [java] [ERROR] Internal compiler error [java] java.lang.OutOfMemoryError: Java heap space [java] at java.util.Arrays.copyOf(Arrays.java:2882) [java] at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java: 100) [java] at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) [java] at java.lang.StringBuilder.append(StringBuilder.java:119) [java] at com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java: 59) [java] at com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java: 126) [java] at com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 939) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at
Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics
Thanks. I was able to reproduce the problem and filed issue
5582http://code.google.com/p/google-web-toolkit/issues/detail?id=5582
.
@zhuyi: can you take a look at this bug?
On Thu, Nov 11, 2010 at 11:58 AM, yves yves.ko...@gmail.com wrote:
Miguel,
Here is the ResultNode class
public class ResultNodeT extends ResultNode? implements Result {
private static final long serialVersionUID = -3560238969723137110L;
public int dataType;
public int id1;
public int id2;
public int id3;
public int id4;
public int numChildren;
public String data;
public T[] next;
public ResultNode() {}
}
and its parent, which is an empty placeholder for Serializable:
public interface Result extends Serializable {
}
This class implements a node in a tree.
The goal of the generics is to define the children nodes type (the
next[] member).
Actually ResultNode is not used by itself, only subtypes are
instanciated. Subtypes of ResultNode define only additional int,
boolean or float members. Nothing else.
Even if the goal here is not to justify why I am doing this, this
usage of the genrics allows me to remove from the code many unsafe
type cast. Now with the generics I am sure of the member type
(next[]). Isn't this the goal of generics ? :-)
Yves
On 11 nov, 17:34, Miguel Méndez mmen...@google.com wrote:
@yves: What does the ResultNode class look like? It is class
ResultNodeT
extends ResultNode? but what about its supertype and fields?
On Thu, Nov 11, 2010 at 10:50 AM, yves yves.ko...@gmail.com wrote:
Chris,
JConsole does not succeed to connect to the java compilation : I get
an out of memory error in sun.rmi.transport.tcp.TCPTransport
$AcceptLoop.executeAcceptLoop while trying to start a new thread.
= Result: no data in jconsole
The compiler is the one shipped with GWT 2.1.0RC1
I'll send you the output of -verbose:gc
Yves
On 10 nov, 23:26, Chris Conroy con...@google.com wrote:
Yves,
You say this error did not occur before your most recent change. It
would be useful to get an idea for the memory usage before this
change: it could be that your app is just very large and you were
already on the edge of an OOME, your change really necessitates more
memory, or this is a pathological case.
Here are a few things to try for gathering more useful information:
-Try attaching jconsole to the compile in the before and after
scenario and see how the memory usage compares between both.
-add -XX:-HeapDumpOnOutOfMemoryError to the JVM args for your failing
compile. There may be some interesting data in the resulting dump. If
you can share the heap dump with us (you can send me a link off list
if you like), then I can take a look.
-Of course, make sure you are using the latest version of the GWT
compiler. The 2.1 compiler contains some changes that will reduce the
memory footprint of your compile.
On Wed, Nov 10, 2010 at 1:20 PM, Scott Blum sco...@google.com
wrote:
Hmmm what happens if you turn down the log level, say to
WARN?
Are you invoking from the command line, or are you using the Google
Plugin
for Eclipse?
On Wed, Nov 10, 2010 at 4:16 PM, yves yves.ko...@gmail.com
wrote:
Scott,
Thx for the tip. Anyway I can't allocate more than -Xmx1590M and I
get
exactly the same error.
Yves
On 9 nov, 07:47, Scott Blum sco...@google.com wrote:
Hmm can you increase your virtual memory?
On Mon, Nov 8, 2010 at 5:13 PM, yves yves.ko...@gmail.com
wrote:
I can't, I only have 2GB RAM, I get this error as from
-Xmx1024M
[java] Error occurred during initialization of VM
[java] Could not reserve enough space for object heap
[java] Could not create the Java virtual machine.
and the log level is INFO
Yves
On 8 nov, 22:53, Scott Blum sco...@google.com wrote:
What if you turn the heap up to -Xmx2048M?
What log level are you using?
On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com
wrote:
Hi,
I had a class named ResultNode and the project compiled
fine.
In order to improve the code, I changed this class by
adding
generic
stuff like that : ResultNodeT extends ResultNode?.
Of course I adapted the entire project where needed to
take
advantage
of this change.
Now I get an Internal compiler error
This is produced with java memory settings -Xmx768M and
-Xss32M .
(usually the settings are -Xmx128M and default value for
-Xss
and
I
never had such problem).
BTW : a javac compilation on the project is succesfull,
so
it is
not
a java error.
Any suggestion ? If more information is needed do
Re: [gwt-contrib] Re: Problem in the P4 - SVN mirroring bot
[+fabbott] Thanks for pointing this out Thomas. @fabbott: can you take a look and see what went on here? I took a look and can confirm that not all of http://code.google.com/p/google-web-toolkit/source/detail?r=8890 was mirrored over. On Wed, Sep 29, 2010 at 6:21 AM, Thomas Broyer t.bro...@gmail.com wrote: [+Cc: bruce_at_google] On Sep 29, 11:03 am, Thomas Broyer t.bro...@gmail.com wrote: At least r8887 up to r8890 are missing some changes. The missing changes in r8887 and r break the build; whereas r8890 just misses the faster function clusterer (and r8889 is in the expenses sample which I haven't tried to build) D'oh! r8881 is broken too. Haven't checked earlier revisions yet. Last svn update was r8871 and it was OK (at least ant clean dist was successful, but maybe some changes were already missing without causing build errors, similar to r8890) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Problem in the P4 - SVN mirroring bot
Thanks for looking into this Freeland. On Wed, Sep 29, 2010 at 10:41 AM, Freeland Abbott fabb...@google.comwrote: Yep, I'm looking (and apologies!). I'm planning to force-correct svn first, then troll over the logs to see what went wrong. I did recently update the script (to support merge metadata for branch integrations), but that... shouldn't... have affected the textual content of any given mirror, especially one that wasn't a cross-branch copy/merge On Wed, Sep 29, 2010 at 9:51 AM, Miguel Méndez mmen...@google.com wrote: [+fabbott] Thanks for pointing this out Thomas. @fabbott: can you take a look and see what went on here? I took a look and can confirm that not all of http://code.google.com/p/google-web-toolkit/source/detail?r=8890 was mirrored over. On Wed, Sep 29, 2010 at 6:21 AM, Thomas Broyer t.bro...@gmail.comwrote: [+Cc: bruce_at_google] On Sep 29, 11:03 am, Thomas Broyer t.bro...@gmail.com wrote: At least r8887 up to r8890 are missing some changes. The missing changes in r8887 and r break the build; whereas r8890 just misses the faster function clusterer (and r8889 is in the expenses sample which I haven't tried to build) D'oh! r8881 is broken too. Haven't checked earlier revisions yet. Last svn update was r8871 and it was OK (at least ant clean dist was successful, but maybe some changes were already missing without causing build errors, similar to r8890) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8780 committed - Fixes https://jira.springsource.org/browse/ROO-1213 - Hide Property fr...
Thanks for spotting that Patrick. I'll get the code updated.
On Wed, Sep 15, 2010 at 5:54 PM, Patrick Julien pjul...@gmail.com wrote:
using this as tmp work around for now:
package com...workarounds;
import com.google.gwt.app.place.PropertyColumn;
import com.google.gwt.requestfactory.client.impl.ProxyImpl;
import com.google.gwt.requestfactory.shared.EntityProxy;
import com.google.gwt.text.shared.Renderer;
public final class WorkAroundPropertyColumnR extends EntityProxy, T
extends PropertyColumnR, T {
private final RendererT renderer;
private final String property;
private final ClassT clazz;
public WorkAroundPropertyColumn(final String property, final String
displayName, final RendererT renderer, final ClassT clazz) {
super(property, displayName, renderer);
this.property = property;
this.renderer = renderer;
this.clazz = clazz;
}
@Override
public String getValue(final R object) {
final ProxyImpl proxyImpl = (ProxyImpl) object;
return renderer.render(proxyImpl.T get(property, clazz));
}
}
On Wed, Sep 15, 2010 at 5:10 PM, Pascal Patry i...@invalidip.com wrote:
On Wednesday, September 15, 2010 16:16:06 Patrick Julien wrote:
public String getValue(R object) {
-return renderer.render(object.get(property));
+ProxyImpl proxyImpl = (ProxyImpl) object;
+return renderer.render(proxyImpl.Tget(property, String.class));
}
This blows up on anything that isn't a String. At least on
Windows/Chrome it does in dev mode. In Linux seems to work fine.
[...]
Yeah, I'm also getting this issue on FF on linux when debugging a gwt
app.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
Miguel
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)
Eric, I think that you are on the right track by trying to measure the effectiveness of each optimization -- even if we need to more data to increase the accuracy. On Fri, Sep 3, 2010 at 6:02 AM, Eric Ayers zun...@google.com wrote: I was thinking about how keeping track of the AST size on the fly could be expensive and complicated. The simplest thing to do would be to have to add in a separate walk that just counted nodes, maybe once at the head of optimizeLoop. I wrote this dummy code earlier to measure the cost of just a walk, and it turns out that walking the tree and counting all nodes is a computationally significant amount of work - its like adding an extra optimizer. I didn't want to have too much observer effect if the change is just for statistical purposes. (but maybe I could add that walk just in the case of having tracing enabled.) But I mis-spoke when describing my goal as tuning code size to compile time. I'm really just trying to find ways to shorten the compile time. You've mentioned a couple of times about the optimizations being quadratic cost. I want to use this feature to add an option with a decent amount of optimization and shave off a significant amount of the compile time. Something between draftCompile and fully optimized. The decision point to opt out of the build to could be specific to each optimizer. For example, if each optimizer declares that isn't doing much through a single or two consecutive passes, it might be time to throw in the towel. We could have users specify an optimization level: -O, -O2, -O3, ... like c compilers and gzip do to specify the amount of optimization desired. At the water cooler we've speculated that there might be interaction between optimizers we can predict. e.g. dead code elimination isn't going to do much if the pruner and type tightener weren't very effective on the last pass (I just made that up). Early in my investigations I was hoping that we could just stop calling some of the optimizers that aren't very effective after the first few passes, but the only visibility I had was the didChange boolean. Now we could do some statistics gathering on different apps and see if that would be worth pursuing. -Eric. On Fri, Sep 3, 2010 at 12:02 AM, Ray Cromwell cromwell...@gmail.comwrote: I think it's useful to see the amount of work done vs time spent, but I don't think it will help automate size-tradeoffs unless you keep track of the size of the AST as well, so that you can see roughly how much it's being reduced each pass. Some optimizations don't really shrink the AST size, but enable other optimizations. e.g. type tightening, finalizing, and static-fying help method inliner, DCE, and pruner. It would be nice to correlate, for example, with and without those tightening/staticifying passes, how much worst the actual code-deleting passes would be, because that's the only real way if you know they're worth it. Some things have an effect far down the chain, for example, static-methods can be obfuscated better, because 'this' can't be obfuscated, so you don't see the code-size effect symbol obfuscation, as AST size doesn't tell the whole story. -Ray On Thu, Sep 2, 2010 at 8:48 PM, Eric Ayers zun...@google.com wrote: I'm looking for feedback on this proposed change, mainly, is the statistical information worth the added complexity? Currently, this only dumps out a diagnostic when you specify -Dgwt.jjs.traceMethods=com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimize on the Compiler command line. Here's a sample of what the statistical output looks like on a minimal GWT app: Pass 1 ( 0/ 0) Pruner 27.94% ( 3132/ 11211)Finalizer 45.64% ( 2455/ 5379) MakeCallsStatic 7.94% ( 812/ 10229) TypeTightener 2.41% ( 1226/ 50966) MethodCallTightener 1.96% (70/ 3569) DeadCodeElimination 1.93% ( 1277/ 66324) MethodInliner 28.84% ( 5430/ 18830) SameParameterValueOptimizer 0.58% (44/ 7588) Pass 2 ( 0/ 0) Pruner 12.24% ( 1089/ 8895)Finalizer 0.09% ( 4/ 4400) MakeCallsStatic 2.68% ( 182/ 6796) TypeTightener 0.80% ( 272/ 33915) MethodCallTightener 1.36% (32/ 2353) DeadCodeElimination 0.41% ( 166/ 40201) MethodInliner 9.95% ( 956/ 9609) SameParameterValueOptimizer 0.24% (14/ 5776) Pass 3 ( 0/ 0) Pruner 1.79% ( 240/ 13392)Finalizer 0.00% ( 0/ 4036) MakeCallsStatic 0.50% (31/ 6221) TypeTightener 0.31% (62/ 20088) MethodCallTightener 0.05% ( 1/ 2190) DeadCodeElimination 0.20% (74/ 37391) MethodInliner 2.90% ( 250/ 8608) SameParameterValueOptimizer 0.11% ( 6/ 5325) Pass 4 ( 0/ 0) Pruner 0.54% (57/ 10492)Finalizer 0.03% ( 1/ 3948) MakeCallsStatic 0.02% ( 1/ 6086) TypeTightener 0.05% ( 8/ 14660)
Re: [gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
FWIW, since we the time bounds of further optimizing this patch are not yet
clear, I'd be in favor of landing it and then doing a second round of
optimizations.
On Wed, Aug 11, 2010 at 5:39 PM, Jason Rosenberg jbrosenb...@google.comwrote:
So, I've added some minor clarification in the comments describing the
castableTypeMap 'Object' (and removed some whitespace), but have not
attempted to narrow the typing on that Object (e.g. as a sub-classed
JavaScriptObject (as suggested by BobV), or as an int[] array (as
suggested by Scott/RayC).
Also, I have not attempted in this patch to remove the typeId from the
Object class. I will have further discussion on how to best to do
this (as it touches the issue of the special treatment of the String
class, and the typeMarker field, in Cast.java).
Since these more detailed mods will likely take a bit more time to
discuss and implement and test for results, the proposal on the table
is to proceed with this patch as is, since it does achieve the primary
goal of removing the big typeIdArray in the initial js fragment
download.
Regardless, I am proceeding on mods to test removal of typeId and also
to implement the int[] solution for the castableTypeMap, but I am not
sure how long it will take to complete (as it may require some further
discussion).
On Wed, Aug 11, 2010 at 5:28 PM, jbrosenb...@google.com wrote:
http://gwt-code-reviews.appspot.com/750801/diff/1/2
File dev/core/src/com/google/gwt/core/ext/linker/SymbolData.java
(right):
http://gwt-code-reviews.appspot.com/750801/diff/1/2#newcode86
dev/core/src/com/google/gwt/core/ext/linker/SymbolData.java:86: Object
getCastableTypeMap();
Added minor clarification in comment. Will test re-implementing the
castableTypeMap as an int[] array in a subsequent patch
http://gwt-code-reviews.appspot.com/750801/diff/1/4
File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (right):
http://gwt-code-reviews.appspot.com/750801/diff/1/4#newcode1102
dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java:1102:
On 2010/08/11 12:24:36, bobv wrote:
Extra whitespace.
Done.
http://gwt-code-reviews.appspot.com/750801/diff/1/7
File
dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Array.java
(right):
http://gwt-code-reviews.appspot.com/750801/diff/1/7#newcode137
dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Array.java:137:
Object castableTypeMap, int queryId, int length, int seedType) {
Added minor clarification in comments. Will test re-implementing the
castableTypeMap as an int[] array in a subsequent patch
http://gwt-code-reviews.appspot.com/750801/diff/1/12
File user/src/com/google/gwt/rpc/server/ClientOracle.java (right):
http://gwt-code-reviews.appspot.com/750801/diff/1/12#newcode117
user/src/com/google/gwt/rpc/server/ClientOracle.java:117:
On 2010/08/11 12:24:36, bobv wrote:
Extra whitespace.
Done.
http://gwt-code-reviews.appspot.com/750801/diff/1/17
File user/super/com/google/gwt/emul/java/lang/Object.java (right):
http://gwt-code-reviews.appspot.com/750801/diff/1/17#newcode46
user/super/com/google/gwt/emul/java/lang/Object.java:46: * lookup
castability between types
Added minor clarification in comments. Will test re-implementing the
castableTypeMap as an int[] array in a subsequent patch
http://gwt-code-reviews.appspot.com/750801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
Miguel
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: GPE JSNI formatting issues
Keith, could you take a look at this one. If it is easy, maybe we can add it to 1.4? On Fri, Apr 2, 2010 at 1:15 PM, Matt Mastracci matt...@mastracci.comwrote: I think I worded this more clearly in the bug, but it's actually the format save action that causes the JSNI to be unformatted, not the regular format action. The regular format action correctly ignores JSNI formatting, while the format save action seems to eat all of the leading whitespace. I had to paste the entire contents of an ancient version of Douglas Crockford's JSON library into a JSNI function earlier today as part of a unit test and I ended up with a few hundred lines of unindented circa-2005 Javascript after saving. :) On 2010-04-02, at 10:13 AM, Matt Mastracci wrote: Hey all, I've been fighting this JSNI formatting bug for a while now. The Google Plugin for Eclipse is basically flattening the indents on all my JSNI methods when using the format command. With the 'format on save' option chosen in Eclipse, it unformats all the JSNI in the file after a save operation: http://code.google.com/p/google-web-toolkit/issues/detail?id=4369 Any possibility of getting this on the roadmap for a quick fix? I've included a repro case in the bug that should demonstrate it in a clean Eclipse workspace. Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject. -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Array implementation for Lightweight Collections. Pure Java implementation only.
I'm not advocating that you save up for one large patch at the end. You should have the code reviewed in increments as you are planning on doing. All I'm suggesting is that the code not land in trunk/user/... until is ready. A real branch or bikeshed would be a better place. On Thu, Mar 18, 2010 at 4:44 PM, Rodrigo Chandia rchan...@google.comwrote: Sure, discussion and comments are welcome. I am developing all this in a branch. The idea is to keep reviewing the changes until we are all satisfied with it. I just thought it made more sense to publish small changes rather than posting a huge patch for review at the end. I can do either or something in between, but I tend to lean towards the incremental approach. El 18 de marzo de 2010 14:40, Miguel Méndez mmen...@google.com escribió: Not sure if this has been discussed already, but you should consider developing these in a branch until the landing plan for the changes is clear. On Thu, Mar 18, 2010 at 9:50 AM, rchan...@google.com wrote: Reviewers: fabbott, Description: Array implementation for Lightweight Collections. Pure Java implementation only. This is part of an incremental review. Not likely to land until other parts are reviewed. Please review this at http://gwt-code-reviews.appspot.com/232801 Affected files: A user/src/com/google/gwt/collections/Array.java A user/src/com/google/gwt/collections/Assertions.java A user/src/com/google/gwt/collections/CollectionFactory.java A user/src/com/google/gwt/collections/ConstantTime.java A user/src/com/google/gwt/collections/LinearTime.java A user/src/com/google/gwt/collections/MutableArray.java A user/test/com/google/gwt/collections/ObjectArrayTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [gwt-contrib] Array implementation for Lightweight Collections. Pure Java implementation only.
Not sure if this has been discussed already, but you should consider developing these in a branch until the landing plan for the changes is clear. On Thu, Mar 18, 2010 at 9:50 AM, rchan...@google.com wrote: Reviewers: fabbott, Description: Array implementation for Lightweight Collections. Pure Java implementation only. This is part of an incremental review. Not likely to land until other parts are reviewed. Please review this at http://gwt-code-reviews.appspot.com/232801 Affected files: A user/src/com/google/gwt/collections/Array.java A user/src/com/google/gwt/collections/Assertions.java A user/src/com/google/gwt/collections/CollectionFactory.java A user/src/com/google/gwt/collections/ConstantTime.java A user/src/com/google/gwt/collections/LinearTime.java A user/src/com/google/gwt/collections/MutableArray.java A user/test/com/google/gwt/collections/ObjectArrayTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: One-line fix to SelectionScript's fallback logic for
Thanks Lex! 2010/3/12 Lex Spoon sp...@google.com 2010/3/11 Miguel Méndez mmen...@google.com +1 to Ray's question. I know that you were simply doing a fix Lex, but we need to think about how we test these features. I agree. I'll work out a test. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: One-line fix to SelectionScript's fallback logic for
+1 to Ray's question. I know that you were simply doing a fix Lex, but we need to think about how we test these features. On Thu, Mar 11, 2010 at 9:49 PM, cromwell...@gmail.com wrote: LGTM. On a side note, is there a way to write a test case for this? http://gwt-code-reviews.appspot.com/183801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT 2.0.2
We should have the 2.0.2 release out by end of day today or Monday at the latest. On Fri, Feb 12, 2010 at 3:40 AM, stuckagain david.no...@gmail.com wrote: Hi, Any idea when there will be a GWT 2.0.2 ? The 2.0.1 contains a few issues that stops us from migrating (already reported and fixed), the 2.0 contains issues that were fixed in 2.0.1 ... so we must migrate. building our own version is not immediatly possible. David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)
We are in the process of smoke testing 2.0.1. We expect for it to be released in the next day or so. On Tue, Feb 2, 2010 at 7:18 AM, David david.no...@gmail.com wrote: Hi, The subject of roadmap ... when will we see a 2.0.1 ? We currently need to run with a patch gwt-servlet) due to a classloading issue which is now in fixed state in the issue database. Moving to a Wave would be great! I'm always waving alone :-S... maybe I can then finally grasp why it is supposed to be so great. David On Tue, Feb 2, 2010 at 12:46 AM, Bruce Johnson br...@google.com wrote: On Mon, Feb 1, 2010 at 4:05 PM, Sami Jaber sami.ja...@gmail.com wrote: I'm agree with Thomas. RegExp integration should have been discussed in the list. It is landing into the trunk from nowhere for us... I mentioned a couple of weeks ago that we were switching to a different version control system -- and this is the first example of the sorts of hiccups we thought could happen. A Googler, a GWT user but who is not on the GWT team proper, has been working on this as a potential contribution, and submitted this patch for a code review. We accidentally approved it for commit rather than just giving some positive feedback on the code review. Thus, a work in progress got dumped on svn. We're still working out what sort of approval process makes sense for these sorts of contributions, but for a large change like this involving new API surface area, we definitely do want and need open, public discussion. Since the 2.0 release, I feel that there is less interaction with the contrib list (btw what have been decided for the roadmap ?) and what we are supposed to see in the coming releases. I think more than anything, you're seeing the effects of a lot of us being tired from the GWT 2.0 push. An updated roadmap is still forthcoming, but I can summarize a lot of the ad hoc design discussions starting to take place like this: we need to fill a lot of gaps in the libraries, especially widgets and app framewpork sorts of library code. GWT is powerful at present, but it doesn't make it especially easy to create traditional business apps quickly. We'd like to change that. We can understand that you prefer to use internal waves/lists but please let's not forget the openess nature of GWT that contribute to make this framework so popular It's true that Wave is fantastic for design docs, and it's hard not to want to use that instead of email. Maybe the right answer is to get everyone on this list to move to Wave :-) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Announcing GWT 2.0.1
The GWT 2.0.1 point release is now available for download. It contains fixes for bugs found in the 2.0.0 release. Potentially breaking changes and fixes - Fixed a bug in how code generators collect method arguments from generated source, which impacted the Messages interfaces generated for UiBinder template files. In GWT 2.0, such argument names were incorrectly changed to ARGn. Most GWT applications will be unaffected, but external systems relying on these names may need to be updated. - The development mode server will, by default, only bind to localhost which will break cross-machine debugging. You can get the old behavior by specifying -bindAddress 0.0.0.0. Please see issue (#4322http://code.google.com/p/google-web-toolkit/issues/detail?id=4322) for more details. For webAppCreator-generated ant files, you can pass this with ant -Dgwt.args=-bindAddress 0.0.0.0 devmode. - The CurrencyList/CurrencyData APIs are now public - if you were relying upon these classes in their non-public location, you should only need to update your imports. Noteworthy Fixed Issues - UiBinder Image class with resource attribute, removes styles on that image (#4415http://code.google.com/p/google-web-toolkit/issues/detail?id=4415 ) - Widgets lose focus if its placed on FocusPanel (Opera, Safari) (#1471http://code.google.com/p/google-web-toolkit/issues/detail?id=1471 ) - Standard.css missing new layout styles (#4429http://code.google.com/p/google-web-toolkit/issues/detail?id=4429 ) - Remove method in SplitLayoutPanel is broken (#4217http://code.google.com/p/google-web-toolkit/issues/detail?id=4217 ) - Splitter constructor hard codes the background color of the splitter to white (#4335http://code.google.com/p/google-web-toolkit/issues/detail?id=4335 ) - Image should provide method to set alternative text (#4335http://code.google.com/p/google-web-toolkit/issues/detail?id=4335 ) - CssResource cannot parse unescaped '-', '_' in class selectors and unknown at-rules (#3946http://code.google.com/p/google-web-toolkit/issues/detail?id=3946 ) - Focusable implementation breaks ScrollPanels in Safari (#1313http://code.google.com/p/google-web-toolkit/issues/detail?id=1313 ) - RequestBuilder restricted to GET and POST (#3388http://code.google.com/p/google-web-toolkit/issues/detail?id=3388 ) - HTMLTable.Cell.getElement() calls getCellFormatter().getElement() with row and column swapped RequestBuilder restricted to GET and POST (#3757http://code.google.com/p/google-web-toolkit/issues/detail?id=3757 ) - MenuBar steals focus when hovered (#3884http://code.google.com/p/google-web-toolkit/issues/detail?id=3884 ) - TabLayoutPanel tabs don't line up properly on IE (#4447http://code.google.com/p/google-web-toolkit/issues/detail?id=4447 ) - webAppCreator produces ant build files which support the gwt.args property for passing additional flags to the gwtc and devmode rules, such as ant -Dgwt.args=-style PRETTY gwtc. See the GWT issue tracker for the complete list of bug fixes and enhancementshttp://code.google.com/p/google-web-toolkit/issues/list?can=1q=status:Fixed,FixedNotReleased%20milestone:2_0_1num=1000 in this release. -- Miguel on behalf of the GWT Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] wrong DTD generated for modules in GEP
The 2.0.0 release has been tagged. The DTD references should be correct now. Thanks for pointing this out! On Thu, Dec 17, 2009 at 10:56 AM, Arthur Kalmenson arthur.k...@gmail.comwrote: Hey everyone, I just noticed that the DTD used in the GWT modules generated by the GEP is incorrect. It points to http://google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source/core/src/gwt-module.dtd which doesn't exist. Looks like the fix would be pretty easy though, just create a 2.0.0 tag in the repo, because http://google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-source/core/src/gwt-module.dtd works. All the best, -- Arthur Kalmenson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: wrong DTD generated for modules in GEP
On Fri, Dec 18, 2009 at 5:09 AM, David david.no...@gmail.com wrote: Hi, Small question: Is there a reason why GWT is still using a DTD instead of a schema ? In Schema's you can put a lot extra information (inline docs) and eclipse also supports completions with schemas if you put the schema in the XML repository. The main reason is that someone who knew DTDs well put one together. Completions based on the DTD should still work in eclipse so long as the DTD URL can be resolved. They don't necessarily have to be part of eclipse's catalog. David On Thu, Dec 17, 2009 at 11:59 PM, Fushion menno.van.gange...@gmail.com wrote: This one is better: http://google-web-toolkit.googlecode.com/svn/releases/2.0/distro-source/core/src/gwt-module.dtd On 17 dec, 16:56, Arthur Kalmenson arthur.k...@gmail.com wrote: Hey everyone, I just noticed that the DTD used in the GWT modules generated by the GEP is incorrect. It points tohttp:// google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source... which doesn't exist. Looks like the fix would be pretty easy though, just create a 2.0.0 tag in the repo, becausehttp:// google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-so... works. All the best, -- Arthur Kalmenson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Announcing GWT 2.0 and much, much more...
Hi Folks! We have some very exciting announcements today. Please check out the following blog post that covers the GWT 2.0 SDK, Google Plugin for Eclipse, and -- brand new in GWT 2.0 -- a performance analysis tool called Speed Tracer. I think that you will find it pretty interesting... http://googlewebtoolkit.blogspot.com/2009/12/introducing-google-web-toolkit-20-now.html -- Miguel on behalf of the GWT team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GPE 2.0-RC2 and GWTShell
That is right, at the time that the project is GWT-enabled it checks for the existence of a war/WEB-INF/web.xml. If that exists it will think that it is dealing with a war-style project and then it will use the HostedMode if it is available or DevMode when launching the application. With that version of the plugin, if you have a war/WEB-INF/web.xml file in your project, then you can go to the project properties, and disable gwt for the project apply the changes, go back in and re-enable GWT.That should make it think that it is dealing with a war layout project and it won't use GWTShell. There are a few problems with this heuristic that we need to revisit post 1.2/2.0. On Tue, Dec 1, 2009 at 4:14 PM, Matt Mastracci matt...@mastracci.comwrote: Ahh - there's a webAppNature in .project that gets set when you enable GWT. I disabled GWT support, re-added it and now the .project has a com.google.gdt.eclipse.core.webAppNature. This seems to be the trigger for enabling DevMode vs. GWTShell. Thanks, Matt. On 1-Dec-09, at 1:57 PM, Joel Webber wrote: @Miguel: I've hit this before when upgrading projects, and I keep forgetting what the trick was. I seem to recall the plugin was making the project layout determination at the time the GWT nature is added, but I'm not 100% certain. On Tue, Dec 1, 2009 at 3:55 PM, Matt Mastracci matt...@mastracci.com wrote: Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GPE 2.0-RC2 and GWTShell
One correction: When launching web apps, we use DevMode if the SDK supports it and HostedMode otherwise. 2009/12/1 Miguel Méndez mmen...@google.com That is right, at the time that the project is GWT-enabled it checks for the existence of a war/WEB-INF/web.xml. If that exists it will think that it is dealing with a war-style project and then it will use the HostedMode if it is available or DevMode when launching the application. With that version of the plugin, if you have a war/WEB-INF/web.xml file in your project, then you can go to the project properties, and disable gwt for the project apply the changes, go back in and re-enable GWT.That should make it think that it is dealing with a war layout project and it won't use GWTShell. There are a few problems with this heuristic that we need to revisit post 1.2/2.0. 2009/12/1 Joel Webber j...@google.com @Miguel: I've hit this before when upgrading projects, and I keep forgetting what the trick was. I seem to recall the plugin was making the project layout determination at the time the GWT nature is added, but I'm not 100% certain. On Tue, Dec 1, 2009 at 3:55 PM, Matt Mastracci matt...@mastracci.comwrote: Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Code Review Request: Send startup URLs over the wire to GPE
On Tue, Nov 24, 2009 at 12:17 AM, rda...@google.com wrote:
Thanks for the review!
http://gwt-code-reviews.appspot.com/111807/diff/1/5
File dev/core/src/com/google/gwt/dev/shell/remoteui/RemoteUI.java
(right):
http://gwt-code-reviews.appspot.com/111807/diff/1/5#newcode169
Line 169: public void setStartupUrls(MapString, URL urls) {
On 2009/11/24 05:14:07, mmendez wrote:
Nit: why was this a Map again?
That's a good question. I think the intent was that that String value in
the map would be the URL fragment - i.e. Test.html. The URL would be the
fully-qualified URL, such as
http://localhost:/Test.html?gwt.codesvr=
http://gwt-code-reviews.appspot.com/111807
It would be good to confirm this at some point.
--
Miguel
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Code Review Request: Send startup URLs over the wire to GPE
Thanks for the clarification.
2009/11/24 Rajeev Dayal rda...@google.com
Ok, I did confirm it - check out the documentation on
DevModeUI.setStartupURLs - that defines the values in the map.
2009/11/24 Miguel Méndez mmen...@google.com
On Tue, Nov 24, 2009 at 12:17 AM, rda...@google.com wrote:
Thanks for the review!
http://gwt-code-reviews.appspot.com/111807/diff/1/5
File dev/core/src/com/google/gwt/dev/shell/remoteui/RemoteUI.java
(right):
http://gwt-code-reviews.appspot.com/111807/diff/1/5#newcode169
Line 169: public void setStartupUrls(MapString, URL urls) {
On 2009/11/24 05:14:07, mmendez wrote:
Nit: why was this a Map again?
That's a good question. I think the intent was that that String value in
the map would be the URL fragment - i.e. Test.html. The URL would be the
fully-qualified URL, such as
http://localhost:/Test.html?gwt.codesvr=
http://gwt-code-reviews.appspot.com/111807
It would be good to confirm this at some point.
--
Miguel
--
Miguel
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fixes checkstyle issues introduced by r7001.
Thanks. I ended up deleting the issue because Bruce committed a fix
separately. Thanks for looking at it though.
On Thu, Nov 19, 2009 at 9:14 AM, Rajeev Dayal rda...@google.com wrote:
The Rietveld link does not seem to be working, but LGTM.
On Wed, Nov 18, 2009 at 5:18 PM, mmen...@google.com wrote:
Reviewers: rdayal, jat,
Please review this at http://gwt-code-reviews.appspot.com/103813
Affected files:
M dev/core/src/com/google/gwt/dev/DevModeBase.java
Index: dev/core/src/com/google/gwt/dev/DevModeBase.java
diff --git a/dev/core/src/com/google/gwt/dev/DevModeBase.java
b/dev/core/src/com/google/gwt/dev/DevModeBase.java
index
511d5458f848e1493c608c267ba5840971ae98eb..4bb36ecc206b3a9d83999be4cb8bb2ad4a279d95
100644
--- a/dev/core/src/com/google/gwt/dev/DevModeBase.java
+++ b/dev/core/src/com/google/gwt/dev/DevModeBase.java
@@ -429,6 +429,10 @@ abstract class DevModeBase implements DoneCallback {
return remoteUIClientId;
}
+public int getCodeServerPort() {
+ return portHosted;
+}
+
public File getLogDir() {
return logDir;
}
@@ -444,10 +448,6 @@ abstract class DevModeBase implements DoneCallback {
return port;
}
-public int getCodeServerPort() {
- return portHosted;
-}
-
public String getRemoteUIHost() {
return remoteUIHost;
}
@@ -472,6 +472,10 @@ abstract class DevModeBase implements DoneCallback {
this.remoteUIClientId = clientId;
}
+public void setCodeServerPort(int port) {
+ portHosted = port;
+}
+
public void setLogFile(String filename) {
logDir = new File(filename);
}
@@ -484,10 +488,6 @@ abstract class DevModeBase implements DoneCallback {
this.port = port;
}
-public void setCodeServerPort(int port) {
- portHosted = port;
-}
-
public void setRemoteUIHost(String remoteUIHost) {
this.remoteUIHost = remoteUIHost;
}
@@ -502,6 +502,15 @@ abstract class DevModeBase implements DoneCallback {
}
/**
+ * Controls what code server port to use.
+ */
+ protected interface OptionCodeServerPort {
+int getCodeServerPort();
+
+void setCodeServerPort(int codeServerPort);
+ }
+
+ /**
* Controls whether and where to log data to file.
*
*/
@@ -535,12 +544,6 @@ abstract class DevModeBase implements DoneCallback {
void setPort(int port);
}
- protected interface OptionCodeServerPort {
-int getCodeServerPort();
-
-void setCodeServerPort(int codeServerPort);
- }
-
/**
* Controls the UI that should be used to display the dev mode server's
data.
*/
--
Miguel
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Code Review Request: Addition of the Message Transport API
I can't attach a new patch to the issue since I don't own it, but here is the updated patch that we pair programed. It fixes the problems uncovered by the unit test. This patch should be applied over patch set 3. On Tue, Oct 20, 2009 at 11:06 AM, mmen...@google.com wrote: I found a couple of failures on my OSX box last night. Let's look at them together. http://gwt-code-reviews.appspot.com/81805/diff/2003/2007 File dev/core/test/com/google/gwt/dev/shell/remoteui/MessageTransportTest.java (right): http://gwt-code-reviews.appspot.com/81805/diff/2003/2007#newcode110 Line 110: MessageTransport messageTransport = new MessageTransport( Nit: messageTransport - Unused local. http://gwt-code-reviews.appspot.com/81805/diff/2003/2007#newcode151 Line 151: public void testExecuteAsyncRequestWithClosedSendStream() throws IOException, This fails sporadically for me on OSX JRE 1.5.0, but not OSX JRE 1.6.0. http://gwt-code-reviews.appspot.com/81805/diff/2003/2007#newcode322 Line 322: public void testExecuteRequestAsyncWithClosedReceiveStreamBeforeResponse() This fails sporadically for me on OSX JRE 1.5.0, but not OSX JRE 1.6.0. http://gwt-code-reviews.appspot.com/81805 -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review Request: Addition of the Message Transport API
And here is the patch... 2009/10/20 Miguel Méndez mmen...@google.com I can't attach a new patch to the issue since I don't own it, but here is the updated patch that we pair programed. It fixes the problems uncovered by the unit test. This patch should be applied over patch set 3. On Tue, Oct 20, 2009 at 11:06 AM, mmen...@google.com wrote: I found a couple of failures on my OSX box last night. Let's look at them together. http://gwt-code-reviews.appspot.com/81805/diff/2003/2007 File dev/core/test/com/google/gwt/dev/shell/remoteui/MessageTransportTest.java (right): http://gwt-code-reviews.appspot.com/81805/diff/2003/2007#newcode110 Line 110: MessageTransport messageTransport = new MessageTransport( Nit: messageTransport - Unused local. http://gwt-code-reviews.appspot.com/81805/diff/2003/2007#newcode151 Line 151: public void testExecuteAsyncRequestWithClosedSendStream() throws IOException, This fails sporadically for me on OSX JRE 1.5.0, but not OSX JRE 1.6.0. http://gwt-code-reviews.appspot.com/81805/diff/2003/2007#newcode322 Line 322: public void testExecuteRequestAsyncWithClosedReceiveStreamBeforeResponse() This fails sporadically for me on OSX JRE 1.5.0, but not OSX JRE 1.6.0. http://gwt-code-reviews.appspot.com/81805 -- Miguel -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- issue81805-patch4.patch Description: Binary data
[gwt-contrib] Re: Fixes a couple of checkstyle errors introduced by r6432.
Thanks. Committed as r6437. On Wed, Oct 21, 2009 at 1:01 AM, rda...@google.com wrote: LGTM. http://gwt-code-reviews.appspot.com/83806 -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
Here is some more information. I ran into this problem while testing the plugin against GWT 1.7, trunk, and 2.0 MS1. It looks like whenever we generate the hosted.html we use the timestamp of that file as it was inside of the gwt-dev-PLAT.jar. It would seem to me that we want to touch that file every time it is copied/generated. On Mon, Sep 21, 2009 at 3:47 PM, John Tamplin j...@google.com wrote: On Mon, Sep 21, 2009 at 3:38 PM, Ray Ryan rj...@google.com wrote: Time to put it up on rietveld again? Or is there already an url? Same one is still there - http://gwt-code-reviews.appspot.com/56807/show -- John A. Tamplin Software Engineer (GWT), Google -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
I entered the issue 4112http://code.google.com/p/google-web-toolkit/issues/detail?id=4112, to track this problem. 2009/10/7 Miguel Méndez mmen...@google.com Here is some more information. I ran into this problem while testing the plugin against GWT 1.7, trunk, and 2.0 MS1. It looks like whenever we generate the hosted.html we use the timestamp of that file as it was inside of the gwt-dev-PLAT.jar. It would seem to me that we want to touch that file every time it is copied/generated. On Mon, Sep 21, 2009 at 3:47 PM, John Tamplin j...@google.com wrote: On Mon, Sep 21, 2009 at 3:38 PM, Ray Ryan rj...@google.com wrote: Time to put it up on rietveld again? Or is there already an url? Same one is still there - http://gwt-code-reviews.appspot.com/56807/show -- John A. Tamplin Software Engineer (GWT), Google -- Miguel -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
This is definitely a bug and you should be able to switch between the two versions. As a work around try the following: 1) Delete the current war/MODULE/hosted.html file 2) Re-run hosted mode and see the failure and stop hosted mode (this causes a new hosted.html file with the right version to be generated). 3) Touch the newly generated war/MODULE/hosted.html file. 4) Relaunch hosted mode (this should succeed) On Wed, Oct 7, 2009 at 1:15 PM, Sky myonceinalifet...@gmail.com wrote: I get this error when I switch from the GWT compiled from Trunk back to 1.7.1 or any previous versions. I only know two ways to solve it: 1) Open up war\projectname\hosted.html and edit line 16 from var $hostedHtmlVersion=2.0; to var $hostedHtmlVersion=1.6; (which I think is a terrible hack because I don't know what other differences there could be in that file or for that matter the entire project that isn't being correctly changed back to the previous version...) 2) Create a whole new project from scratch that is using GWT 1.7.1 and copy all my files from the broken project into this new one and scrap the broken one. This just seems dumb. So why can't I switch between GWT Trunk and the stable version seamlessly? It has nothing to do with browser caching because the actual hosted.html file in the project has the value 2.0 instead of 1.6. I did try clearing the browser cache though. Any help would be very much appreciated. On Oct 7, 10:29 am, Miguel Méndez mmen...@google.com wrote: Here is some more information. I ran into this problem while testing the plugin against GWT 1.7, trunk, and 2.0 MS1. It looks like whenever we generate the hosted.html we use the timestamp of that file as it was inside of the gwt-dev-PLAT.jar. It would seem to me that we want to touch that file every time it is copied/generated. On Mon, Sep 21, 2009 at 3:47 PM, John Tamplin j...@google.com wrote: On Mon, Sep 21, 2009 at 3:38 PM, Ray Ryan rj...@google.com wrote: Time to put it up on rietveld again? Or is there already an url? Same one is still there - http://gwt-code-reviews.appspot.com/56807/show -- John A. Tamplin Software Engineer (GWT), Google -- Miguel -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Invalid version number 2.0 passed to external.gwtOnLoad()
I've also run into this problem... On Fri, Sep 18, 2009 at 8:37 AM, Marko Vuksanovic markovuksano...@gmail.com wrote: I had the same problem.. After struggling for 2 days I figured out that the embedded jetty loads the hosted.html file form cache (C: \Documents and Settings\YOUR_USERNAME\Local Settings\Temporary Internet Files\Content.IE5 - on windows xp) - after manually deleting that cache everything started working normally. Hope this saves somebody else at least 2 days :) On Aug 12, 5:52 pm, Ray Ryan rj...@google.com wrote: We could make the error message a bit more helpful. If I'm following the conversation correctly I think I've bumped into this due to browser caching. Suggesting that possibility in the error message, or offering a link to force a reload in a browser busting way (e.g. adding a query param wtih a date stamp value) could save folks a lot of time. On Tue, Aug 11, 2009 at 9:33 PM, Fred Sauer fre...@google.com wrote: On Tue, Aug 11, 2009 at 5:47 PM, John Tamplin j...@google.com wrote: On Tue, Aug 11, 2009 at 8:22 PM, Fred Sauer fre...@google.com wrote: I'm not sure I understand the issue. If you have different versions of hosted.html and GWT, things are likely to not work and that is why that check was added in 1.6. I don't see how you could have the incorrect contents of hosted.html but the correct version, unless you update/rollback parts of GWT separately, in which case you are already likely to break things if you don't know what you are doing. Yep, that's exactly the scenario :). Knowing that you have to watch out for this stuff is one thing. Being bit by it every now and again and going down a rabbit hole, is (mildly) annoying. Not a huge deal as this affect contributors only, but could be a good sanity check to save time down the road. There are so many ways you can screw things up by mixing different versions of parts of GWT, I don't see how this is any different. For example, if you rollback an old TypeOracleMediator but don't roll back related TypeOracle changes, things are going to break horribly. I think trying to add code inside GWT to detect such situations is counterproductive and unlikely to be effective anyway. You had me at There are so many ways you can screw things up Thanks Fred I would hope that anyone knows building a version of GWT that is not at a consistent revision across the board means they better know exactly what they are doing or they will get weird breakages. -- John A. Tamplin Software Engineer (GWT), Google -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Supress Google Eclipse Plugin errors in gwt trunk
I actually did ignore it specifically, but I took your suggestion to not do that and simply rely on the annotation. We can treat RpcService specially. On Thu, Sep 17, 2009 at 2:23 PM, Ray Ryan rj...@google.com wrote: Miguel, are you and John in touch on this? I thought you were going to special case RpcService itself so that we wouldn't need a suppress there. On Thu, Sep 17, 2009 at 11:09 AM, jlaba...@google.com wrote: Reviewers: Ray Ryan, Description: Description: The Google Eclipse Plugin generates some error messages in gwt-user because we have some unmatched RemoveServices, which are used in tests. Fix: Add @SuppressWarnings to each instance of this. Also add the gwtNature to the user project file. I'll add the gwtNature to the samples in a separate patch. Testing: All errors are gone in Eclipse. Please review this at http://gwt-code-reviews.appspot.com/67802 Affected files: eclipse/user/.project user/src/com/google/gwt/rpc/client/RpcService.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/AbstractSerializableTypes.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/ManualSerialization.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/MissingGwtTypeArgs.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/NoSerializableTypes.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/ObjectArrayInMethodSignature.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/ObjectInMethodSignature.java user/test/com/google/gwt/user/server/rpc/RPCTest.java -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Supress Google Eclipse Plugin errors in gwt trunk
On Thu, Sep 17, 2009 at 2:24 PM, Scott Blum sco...@google.com wrote: I think the ones in user/test are fine, but may I offer a note of caution to the one in user/src? Depending on the settings, some compilers will emit a warning if you try to suppress a warning that they don't understand, strangely enough. Non-GEP users might therefore get a warning about that on RpcService. Maybe the plugin should ignore that one, or many in general ones that don't have methods? Lets special case RpcService for now. I'll need to convince myself that it is okay in general to ignore empty interfaces, specially if the super interfaces do declare methods. On Thu, Sep 17, 2009 at 2:09 PM, jlaba...@google.com wrote: Reviewers: Ray Ryan, Description: Description: The Google Eclipse Plugin generates some error messages in gwt-user because we have some unmatched RemoveServices, which are used in tests. Fix: Add @SuppressWarnings to each instance of this. Also add the gwtNature to the user project file. I'll add the gwtNature to the samples in a separate patch. Testing: All errors are gone in Eclipse. Please review this at http://gwt-code-reviews.appspot.com/67802 Affected files: eclipse/user/.project user/src/com/google/gwt/rpc/client/RpcService.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/AbstractSerializableTypes.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/ManualSerialization.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/MissingGwtTypeArgs.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/NoSerializableTypes.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/ObjectArrayInMethodSignature.java user/test/com/google/gwt/user/rebind/rpc/testcases/client/ObjectInMethodSignature.java user/test/com/google/gwt/user/server/rpc/RPCTest.java -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Announcing the Google Plugin for Eclipse 1.1.0
Hi everyone, We wanted to let all of you know that the Google Plugin for Eclipse 1.1.0 is now available. Some of the notable improvements are: - Support for Eclipse 3.5 (Galileo) - GWT RPC interface validation with quick fixes - App Engine DataNucleus enhancer console no longer steals focus on save If you'd like more details on the contents of the release, please see the Release Notes http://code.google.com/eclipse/docs/release_notes.html. To get started right way, take a look at the installation instructionshttp://code.google.com/eclipse/docs/download.html or just use the update site below that corresponds to your version of Eclipse. - Eclipse 3.5 (Galileo) - http://dl.google.com/eclipse/plugin/3.5 - Eclipse 3.4 (Ganymede) - http://dl.google.com/eclipse/plugin/3.4 - Eclipse 3.3 (Europa) - http://dl.google.com/eclipse/plugin/3.3 Cheers, Miguel, on behalf of the Google Plugin for Eclipse Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Announcing the Google Plugin for Eclipse 1.1.0
I must admit that there are some features that we forgot to include the public documentation that are specifically targeted at contributors. The first is something that we call contributor SDKs. These allow you to define a GWT SDK that is backed by the gwt-user, gwt-dev-PLAT/gwt-dev-oophm projects in your eclipse workspace. Configure your workspace per http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt, do a single ant build to populate the staging directory, and import the gwt-user, gwt-dev-PLAT and gwt-dev-oophm projects. Then add a new GWT SDK (you'll notice that you get an option to create an SDK uses the GWT source projects in your workspace). The second feature is very basic support for OOPHM. If you are working against an SDK that supports OOPHM, you'll get a checkbox in the GWT tab of the web app launch configuration which selects between OOPHM or normal hosted mode. Lastly, if you are on OSX and you are using an OOPHM-enabled contributor SDK, we filter the SWT jars out of the launch configuration classpath to prevent eclipse from putting -XstartOnFirstThread and breaking OOPHM. On Thu, Jul 30, 2009 at 3:41 PM, Isaac Truett itru...@gmail.com wrote: Thank you, Miguel and the plugin team, and congratulations on your latest release! I was amused to find that some old code in my current project triggered the RPC interface validations (and rightly so), even though the services were perfectly functional. Thanks, Isaac 2009/7/30 Miguel Méndez mmen...@google.com: Hi everyone, We wanted to let all of you know that the Google Plugin for Eclipse 1.1.0 is now available. Some of the notable improvements are: Support for Eclipse 3.5 (Galileo) GWT RPC interface validation with quick fixes App Engine DataNucleus enhancer console no longer steals focus on save If you'd like more details on the contents of the release, please see the Release Notes. To get started right way, take a look at the installation instructions or just use the update site below that corresponds to your version of Eclipse. Eclipse 3.5 (Galileo) - http://dl.google.com/eclipse/plugin/3.5 Eclipse 3.4 (Ganymede) - http://dl.google.com/eclipse/plugin/3.4 Eclipse 3.3 (Europa) - http://dl.google.com/eclipse/plugin/3.3 Cheers, Miguel, on behalf of the Google Plugin for Eclipse Team -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
This sounds like a very reasonable approach. Pruning clinits based on the
whole program CFG is definitely interesting, but is there an estimate on the
saving (speed/size) that would be gained from that optimization? I ask,
just as a cross-check.
On Wed, Jun 17, 2009 at 1:16 PM, Ray Cromwell cromwell...@gmail.com wrote:
Miguel, for what it's worth, I agree wholeheartedly. Object oriented
programming tends to encourage small block sizes except where inlining helps
to enlarge them, so inter-block definitely helps alot. Moreover, you can't
really build a good CFA/DFA without inter-block information propagation.
Here's an off the cuff proposal for doing this later:
Step 1, as I outlined, is to take JExpressions which are not literals,
fieldrefs, etc and introduce temporaries so as to introduce a three-address
style into the AST.
e.g.
a + b where a is unary/binary/etc op becomes t = a, t + b
return expr becomes t=expr; return t
while(expr) becomes t=expr, while(t) { t=expr; }
etc
This gives us an AST structure amenable to traditional analysis without
introducing a totally new IR, we can reuse most of the existing JNode
classes, only unlike what you'd find in the Dragon Book, we keep high level
ops for loops, conditionals, method calls, and everything else.
Step 2, introduce a new JPhi node (extends JNode). Build CFG. Add steps to
compute dominator trees/dominance frontiers and use these to insert JPhi
nodes into the ASTs. Modify all of the existing visitors to deal with JPhi.
Add stage to unSSA.
Step 3: Introduce optimizations to this structure. Edge-split form. Faster
'optimal' dominance algorithms (I say, use something simpler like the Cooper
technique at first:
http://www.hipersoft.rice.edu/grads/publications/dom14.pdf)
The crucial question is whether to do procedure level CFG, or whole program
CFG. One of the things that interested me about the potential of building a
limited whole-program CFG was the ability to aggressively (and correctly)
prune clinits. Now, if the eager clinit hoisting is acceptable, than this
would be overkill, but if not, then the way to do it is to compute the
immediate dominator hierarchy for each block.
If block B_j contains clinitA() and it is dominated by some block B_i in
its immediate dominators which contains a call to clinitA(), then it is safe
to remove clinitA() from B_j since all possible paths of execution for
reaching B_j must first go through B_i, guaranteeing the clinitA() would
have been invoked.
-Ray
2009/6/17 Miguel Méndez mmen...@google.com
If you are going to tackle the intra-block optimization, you might as well
for inter-block opt with block summaries that merge across the control flow.
The later is not that much harder since you summarize the intra-block data
and propagate. But yes, doing SSA for real is a non-trivial amount of work.
On Wed, Jun 17, 2009 at 11:44 AM, Ray Cromwell cromwell...@gmail.comwrote:
I agree. My current proposal really isn't SSA, but poor man's SSA, which
is to simply flatten blocks by introducing temporaries, renumber the
existing variables, perform classic intra-block optimizations, and then
undo. This would atleast result in some modest block level improvements,
including making builder pattern more optimal. The in-block renumbering
procedure I've come up with essentially constructs the liveness range
information as your doing it, without having to deal with the more exotic
SSA algorithms. It might be small enough to perform a useful experiment
without too much work.
Doing real SSA would require quite a bit more work, especially if you
want to deal fully with exceptions and arrays. That to me is something
that's too big of a change to the current compiler infrastructure at the
moment.
-Ray
2009/6/17 Miguel Méndez mmen...@google.com
Longer term moving towards an SSA variant has a lot of
advantages. In the near term, simply experimenting with performing the
classic intra-procedural (block global) optimizations wouldn't necessarily
require SSA although SSA does make the bookkeeping easier and faster. If
you introduced a pass to perform the intra-procedural optimizations that
would not violate the invariants expected by subsequent optimizations
(procedure is still in tree form) you'd go a long way.
If you do go with SSA, it's my experience that you should go all the way
and dead create deal with the phi functions otherwise you end up getting a
lot more temps than you would otherwise and therefore more live refs etc.
On Wed, Jun 17, 2009 at 1:12 AM, Ray Cromwell cromwell...@gmail.comwrote:
I agree, although I find having a wiki with inline response rather
convenient. Here is what I have so far from the Wave, at the end, there
is
a possible to solution to the problem of optimizing away the builder
pattern
using general purpose optimizations.
-Ray
Advanced GWT Compiler Optimizations
The purpose of this wave is to talk about
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
If you are going to tackle the intra-block optimization, you might as well for inter-block opt with block summaries that merge across the control flow. The later is not that much harder since you summarize the intra-block data and propagate. But yes, doing SSA for real is a non-trivial amount of work. On Wed, Jun 17, 2009 at 11:44 AM, Ray Cromwell cromwell...@gmail.comwrote: I agree. My current proposal really isn't SSA, but poor man's SSA, which is to simply flatten blocks by introducing temporaries, renumber the existing variables, perform classic intra-block optimizations, and then undo. This would atleast result in some modest block level improvements, including making builder pattern more optimal. The in-block renumbering procedure I've come up with essentially constructs the liveness range information as your doing it, without having to deal with the more exotic SSA algorithms. It might be small enough to perform a useful experiment without too much work. Doing real SSA would require quite a bit more work, especially if you want to deal fully with exceptions and arrays. That to me is something that's too big of a change to the current compiler infrastructure at the moment. -Ray 2009/6/17 Miguel Méndez mmen...@google.com Longer term moving towards an SSA variant has a lot of advantages. In the near term, simply experimenting with performing the classic intra-procedural (block global) optimizations wouldn't necessarily require SSA although SSA does make the bookkeeping easier and faster. If you introduced a pass to perform the intra-procedural optimizations that would not violate the invariants expected by subsequent optimizations (procedure is still in tree form) you'd go a long way. If you do go with SSA, it's my experience that you should go all the way and dead create deal with the phi functions otherwise you end up getting a lot more temps than you would otherwise and therefore more live refs etc. On Wed, Jun 17, 2009 at 1:12 AM, Ray Cromwell cromwell...@gmail.comwrote: I agree, although I find having a wiki with inline response rather convenient. Here is what I have so far from the Wave, at the end, there is a possible to solution to the problem of optimizing away the builder pattern using general purpose optimizations. -Ray Advanced GWT Compiler Optimizations The purpose of this wave is to talk about a list of future compiler improvements / optimizations for GWT that go beyond the scope of those listed in the current project wiki. Hybrid Intermediate Representations (Tree SSA) Control Flow / Data Flow Analysis Common Subexpression Elimination / Partial Redundancy Elimination Block Level Dead Code Elimination Copy Propagation Register Allocation (temporary/local reduction) Escape Analysis Object inlining / Destructuring Speculative Inlining/Function Cloning Efficient Anonymous Inner Classes Loop Hoisting / Loop Induction Intermediate Representations In order to perform many optimizations, it is easier to deal with a flatter data structure than the traditional AST such as the traditional three address code, but using pure three address code for everything has its own downsides, as well as requiring substantial changes to the compiler. Matt M suggested a hybrid approach of only converting JExpressions to SSA form, This would have the benefit of localizing the changes. It reminded me of GCC's Tree SSA, which upon re-review, looks like it can offer us some useful lessons. As an example, consider the expression x = a + b + c + d in the current AST, this will look something like (assign x (+ d (+ c (+ a b. We can flatten this by introducing temporaries, arriving at: t1 = a + b t2 = t1 + c t3 = t2 + d x = t3 In addition, if we are only dealing with simple blocks (no branches), we can use a more simpler kind of SSA, which is simply to rename variables on assignment. Thus, if you have x = 1 y = 2 z = x + y x++ y++ z = x + y you can rename each variable on assignment, yielding the following x1 = 1 y1 = 2 z1 = x1 + y1 x2 = x1 + 1 y2 = y1 + 1 z2 = x2 + y2 This produces an SSA-like form, with each variable defined only once. At first glance, it looks like a de-optimization, but a later pass that does constant folding, copy propagation, and dead elimination will clean this up. As an example, after copy propagation x1 = 1 y1 = 1 z1 = 1 + 2 x2 = 1 + 1 y2 = 2 + 1 z2 = x2 + y2 after constant folding x1 = 1 y1 = 1 z1 = 3 x2 = 2 y2 = 3 z2 = x2 + y2 after DCE (x1/y1/z1 no longer referenced) x2 = 2 y2 = 3 z2 = x2 + y2 after copy prop x2 = 2 y2 = 3 z2 = 2 + 3 after constant fold x2 = 2 y2 = 3 z2 = 5 after DCE z2 = 5 Finally, after renaming registers back to their original names z = 5 A register allocation style pass can further eliminate temporaries later. However, do to proper CFA/DFA, we may
[gwt-contrib] Re: Eclipse Web Tools Integration
We are looking at ways to better integrate with Webtools. My comment #2 on the following issue 3583http://code.google.com/p/google-web-toolkit/issues/detail?id=3583calls out some of the changes under consideration. Issue 3584 http://code.google.com/p/google-web-toolkit/issues/detail?id=3584also has some other aspects. http://code.google.com/p/google-web-toolkit/issues/detail?id=3583 On Fri, May 8, 2009 at 1:59 PM, hugo.a.garcia hgar...@google.com wrote: Hi Is there any work being done to integrate Eclipse Webtools with the GWT Eclipse Plugin? -H -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Eclipse Web Tools Integration
Also, please weigh in on those issues or create a new issue if they don't cover your use cases for Webtools integration. 2009/5/8 Miguel Méndez mmen...@google.com We are looking at ways to better integrate with Webtools. My comment #2 on the following issue 3583http://code.google.com/p/google-web-toolkit/issues/detail?id=3583calls out some of the changes under consideration. Issue 3584 http://code.google.com/p/google-web-toolkit/issues/detail?id=3584also has some other aspects. http://code.google.com/p/google-web-toolkit/issues/detail?id=3583 On Fri, May 8, 2009 at 1:59 PM, hugo.a.garcia hgar...@google.com wrote: Hi Is there any work being done to integrate Eclipse Webtools with the GWT Eclipse Plugin? -H -- Miguel -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Announcing GWT 1.6...and quite a bit more
We've talked about exposing zip files for use with 3.4's dropins folder, etc. Would that work meet your constraints? On Wed, Apr 8, 2009 at 3:44 AM, stuckagain david.no...@gmail.com wrote: Great news, Any chance for getting an offline installation for the eclipse plugin ? Company policy makes it impossible to connect my development machine to the internet. Davdi On Apr 8, 5:54 am, Bruce Johnson br...@google.com wrote: Hi Folks! Exciting news today. Rather than attempting to describe everything here, let me point you to some blog posts that hopefully you will find interesting: GWT 1.6 and friends: http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-f... Seriously this time, the new language on App Engine: Javahttp:// googleappengine.blogspot.com/2009/04/seriously-this-time-new-l... Google Plugin for Eclipse -- Peanut Butter to Eclipse's Chocolatehttp:// googlewebtoolkit.blogspot.com/2009/04/google-plugin-for-eclips... -- Bruce, on behalf of the GWT, App Engine, and Google Plugin teams -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Updated WAR design for GWT 1.6
Can we get a patch? On Wed, Oct 29, 2008 at 5:55 PM, Scott Blum [EMAIL PROTECTED] wrote: Hearing no objections, we implemented this. :) On Wed, Oct 29, 2008 at 11:00 AM, BobV [EMAIL PROTECTED] wrote: Scott, Miguel, Kelly, and I sat down today to try to resolve some of the problems with the existing WAR deployment design. Here is our strawman proposal for how it should work in the future (we can go into more detail on the rationale). Note that legacy mode would be supported for 1.6 to maintain backwards compatibility. Either: 1a) A new tag in GWT modules to specify a subdir in the output folder to deploy into, something like: deploy-path value=/shortName / - This specifies a subdirectory inside your WAR directory that GWT should output public files (and compiled files) into. For backwards compatibility, the default value if this tag isn't specified will be the fully-qualified module name. - Our project creator could emit a either a module short name, or a constant name (such as gwt or compiled). - A user could also specify / to dump the output directly into the top level of the WAR directory. - deploy-path tags are inherited and last-one wins. or: 1b) A new attribute deploy-path on the module tag. - As above, except that the value is not inherited. 2) GWTShell (or another entry point) requires you to specify the modules you care about on the command line. This is critical because during hosted mode development, we need to create a map of deploy-path - module name. It also breaks potential circular dependencies between static html files and public resources. It also gives an easy answer to What does Compile/Browse do? in hosted mode. 3) The GWT module servlet tag is deprecated; it only works in legacy mode and is ignored (or generates a warning) in WAR mode. Instead, you should configure servlets in your web.xml. -- Bob Vawter Google Web Toolkit Team -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps Add version check
On Thu, Oct 23, 2008 at 8:42 AM, Eric Ayers [EMAIL PROTECTED] wrote: Hi Miguel, Could you please review this patch? It is very small! I am currently running into issues with maps regression tests failing due to some problems with the Maps JavaScript API. The Maps JavaScript API can be configured to return the current version, either stable or experimental. When you run into problems, it is helpful to know what version your app is actually running so you can research the problem or write a good bug report. This change adds Maps.getVersion() to return the current Maps JavaScript API version and adds a unit test case for it. Also, when I sorted MapWidgetTest, a method moved. M maps/src/com/google/gwt/maps/client/Maps.java LG - The javadoc should probably be changed since this method will return the JS Maps API version even in cases where current scheme is not used. M maps/test/com/google/gwt/maps/client/MapWidgetTest.java LG with one nit: Ideally tests will not output to std:out unless there is an error or failure. So, consider removing the System.out.println during the test. Patch is made against the releases/maps/1.0 branch Thanks, -Eric. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps Add version check
On Thu, Oct 23, 2008 at 9:44 AM, Eric Ayers [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 9:21 AM, Miguel Méndez [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 8:42 AM, Eric Ayers [EMAIL PROTECTED] wrote: Hi Miguel, Could you please review this patch? It is very small! I am currently running into issues with maps regression tests failing due to some problems with the Maps JavaScript API. The Maps JavaScript API can be configured to return the current version, either stable or experimental. When you run into problems, it is helpful to know what version your app is actually running so you can research the problem or write a good bug report. This change adds Maps.getVersion() to return the current Maps JavaScript API version and adds a unit test case for it. Also, when I sorted MapWidgetTest, a method moved. M maps/src/com/google/gwt/maps/client/Maps.java LG - The javadoc should probably be changed since this method will return the JS Maps API version even in cases where current scheme is not used. M maps/test/com/google/gwt/maps/client/MapWidgetTest.java LG with one nit: Ideally tests will not output to std:out unless there is an error or failure. So, consider removing the System.out.println during the test. Do you have an alternate suggestion for getting the version of the Maps API from running the hosted mode tests? Seems like you would want to include it in the failure capture information of the assertions (exceptions thrown). -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis maps Formatting and comment cleanup
LGTM On Fri, Oct 17, 2008 at 11:35 AM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, Would you mind reviewing the attached patch? It only changes comments and formatting. The API suffered through a long bout of build breakage. While debugging it, I ran across some comments that were not at all clear in the Maps Test. relative to releases/maps/1.0 branch in subversion: maps/test/com/google/gwt/maps/client/MapWidgetEventsTest.java Thanks, -Eric. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis gears Making ResouceStore demo a bit prettier
That was the problem. LGTM with one nit: ResourceStoreDemo line 41 has some additional whitespace. Nice cleanup. On Fri, Oct 10, 2008 at 9:32 AM, Eric Ayers [EMAIL PROTECTED] wrote: I didn't mention that this patch was against the releases/gears/1.1 branch - could that have been the problem? I just created a new diff on my Linux box and it looks slightly different (attached). Would you mind giving that one a try (r875) On Fri, Oct 10, 2008 at 9:24 AM, Miguel Méndez [EMAIL PROTECTED] wrote: The patch did not apply cleanly against r874. Was that the revision against which the patch was built? Here is the output: Hunk #3 FAILED at 85. 1 out of 6 hunks FAILED -- saving rejects to file samples/resourcestore/src/com/google/gwt/gears/sample/resourcestore/client/ResourceStoreDemo.java.rej The *.orig and *.rej files are attached. On Thu, Oct 9, 2008 at 2:54 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, I'd like for you to review the attached patch ( screenshot) It changes the layout of the demo just a bit to put some margin around the outside. It also adds code to toggle the enable/disable state of the buttons to match the user's actions. M samples/resourcestore/src/com/google/gwt/gears/sample/resourcestore/client/ResourceStoreDemo.java M samples/resourcestore/src/com/google/gwt/gears/sample/resourcestore/public/ResourceStoreDemo.html -Eric. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis gears Worker Pool Demo
On Mon, Oct 6, 2008 at 2:48 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel Attached is a demo for the WorkerPool class that I would like for you to review. The demo is a bit more rich than the demos for the other Gears features. I intend to add documentation for a simple worker pool tutorial in the Getting Started guide that will show a simple version of how to use WorkerPool, so I felt justified in making a more complex demo. The demo shows how the interface is interactive when a worker pool thread is running by giving a little animation to play with (and the results are printed out as they come out). Also, there is a small enhancement to WorkerPool.sendMessage() part of the attached patch that allows the user to pass a JSO as the message. It is not necessary for the demo and I can't recall if I already sent it to you for review or not. M gears/src/com/google/gwt/gears/client/workerpool/WorkerPool.java I did not realize that they had extended the API to allow the passing of boolean, string, number, array, object, and Blobs. Doesn't this mean that the WorkerPoolMessageHandler.MessageEvent class will need to be updated? It mirrors the messageObject parameter to the JS API's onmessage callback, but now messageObject.body should really be a JSO and we should expose messageObject.text. You'd need to figure out how to deal with the case where the caller passed a string because messageObject.body could contain a string in pure JS but in the Java wrapper String and JSO's are not compatible. A samples/workerpool/launch-scripts/linux/WorkerPoolDemo-shell Did not review. A samples/workerpool/launch-scripts/linux/WorkerPoolDemo-compile Did not review. A samples/workerpool/launch-scripts/mac/WorkerPoolDemo-shell LG A samples/workerpool/launch-scripts/mac/WorkerPoolDemo-compile LG A samples/workerpool/launch-scripts/windows/WorkerPoolDemo-shell.cmd Did not review. A samples/workerpool/launch-scripts/windows/WorkerPoolDemo-compile.cmd Did not review. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/WorkerPoolDemo.gwt.xml LG A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/WorkerPoolDemoNoGears.java LG A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/WorkerPoolDemo.java LG - You should add some javadoc to the doSync*, doAsync*, and the stopCalculation methods. Also, on line 134 you may want a comment that explains why we use a deferred command to trigger either computation. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/AnimationToy.java LG A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/PiSpigot.java LG - The name did not make sense to me until I read the Java comment. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/gears_init.js You should not need to include the startup script since you will inherit it from Gears.gwt.xml. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/pi_spigot_worker.js Nice JS code! What is the plan for showing a worker thread in GWT? A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/gwtLogoThumb.png The file was not included in the patch; it prevented me from seeing the animation aspect of the demo. Could you send it to me? A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/WorkerPoolDemo.html LG A samples/workerpool/build.xml LG M samples/build.xml LG -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis gears fix typo in method name.
LGTM On Tue, Oct 7, 2008 at 3:27 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hi Miguel, This patch addresses issue 183, a typo in a method name: http://code.google.com/p/gwt-google-apis/issues/detail?id=183 I renamed the method in the library class and updated the test. M test/com/google/gwt/gears/client/localserver/LocalServerTest.java M src/com/google/gwt/gears/client/localserver/ResourceStoreUrlCaptureHandler.java -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis gears Worker Pool Demo
Thanks for sending the image. I think that you meant to say that the file belongs in: samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/gwtLogoThumb.png? You should add more text to the sample to call out that you can interact with the animation only when using a worker thread to compute the value. Could there be a label better than Calculation Type? It is not that the calculation itself is changed, but really the way in which it is executed. Maybe Execute calculation: Synchronously or Asynchronously. On Wed, Oct 8, 2008 at 10:13 AM, Eric Ayers [EMAIL PROTECTED] wrote: Attached file that belongs in samples/Showcase/src/com/google/gwt/sample/showcase/client/gwtLogoThumb.png On Wed, Oct 8, 2008 at 10:02 AM, Miguel Méndez [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 2:48 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel Attached is a demo for the WorkerPool class that I would like for you to review. The demo is a bit more rich than the demos for the other Gears features. I intend to add documentation for a simple worker pool tutorial in the Getting Started guide that will show a simple version of how to use WorkerPool, so I felt justified in making a more complex demo. The demo shows how the interface is interactive when a worker pool thread is running by giving a little animation to play with (and the results are printed out as they come out). Also, there is a small enhancement to WorkerPool.sendMessage() part of the attached patch that allows the user to pass a JSO as the message. It is not necessary for the demo and I can't recall if I already sent it to you for review or not. M gears/src/com/google/gwt/gears/client/workerpool/WorkerPool.java I did not realize that they had extended the API to allow the passing of boolean, string, number, array, object, and Blobs. Doesn't this mean that the WorkerPoolMessageHandler.MessageEvent class will need to be updated? It mirrors the messageObject parameter to the JS API's onmessage callback, but now messageObject.body should really be a JSO and we should expose messageObject.text. You'd need to figure out how to deal with the case where the caller passed a string because messageObject.body could contain a string in pure JS but in the Java wrapper String and JSO's are not compatible. A samples/workerpool/launch-scripts/linux/WorkerPoolDemo-shell Did not review. A samples/workerpool/launch-scripts/linux/WorkerPoolDemo-compile Did not review. A samples/workerpool/launch-scripts/mac/WorkerPoolDemo-shell LG A samples/workerpool/launch-scripts/mac/WorkerPoolDemo-compile LG A samples/workerpool/launch-scripts/windows/WorkerPoolDemo-shell.cmd Did not review. A samples/workerpool/launch-scripts/windows/WorkerPoolDemo-compile.cmd Did not review. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/WorkerPoolDemo.gwt.xml LG A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/WorkerPoolDemoNoGears.java LG A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/WorkerPoolDemo.java LG - You should add some javadoc to the doSync*, doAsync*, and the stopCalculation methods. Also, on line 134 you may want a comment that explains why we use a deferred command to trigger either computation. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/AnimationToy.java LG A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/client/PiSpigot.java LG - The name did not make sense to me until I read the Java comment. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/gears_init.js You should not need to include the startup script since you will inherit it from Gears.gwt.xml. A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/pi_spigot_worker.js Nice JS code! What is the plan for showing a worker thread in GWT? A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/gwtLogoThumb.png The file was not included in the patch; it prevented me from seeing the animation aspect of the demo. Could you send it to me? A samples/workerpool/src/com/google/gwt/gears/sample/workerpool/public/WorkerPoolDemo.html LG A samples/workerpool/build.xml LG M samples/build.xml LG -- Miguel -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: Gadget RPC demo (it works!)
LGTM just a couple of nits below. On Fri, Sep 5, 2008 at 1:52 PM, Eric Ayers [EMAIL PROTECTED] wrote: A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/server/GadgetRPCServlet.java Nit: Add @SuppressWarning(serial). Did you intend to have the servletStartTime field be static? Would instance final be better? A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/client/ServerInfo.java Nits: accessor methods? Add @SuppressWarning(serial) A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/public/GadgetRPC.html Nit: do you need this file? -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: Gadget RPC demo (it works!)
It all sounds good to me. On Wed, Sep 24, 2008 at 11:34 AM, Eric Ayers [EMAIL PROTECTED] wrote: Committed as r853 and r854. Thanks for the review. On Wed, Sep 24, 2008 at 9:59 AM, Miguel Méndez [EMAIL PROTECTED] wrote: LGTM just a couple of nits below. On Fri, Sep 5, 2008 at 1:52 PM, Eric Ayers [EMAIL PROTECTED] wrote: A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/server/GadgetRPCServlet.java Nit: Add @SuppressWarning(serial). Did you intend to have the servletStartTime field be static? Would instance final be better? I wanted a value that wouldn't change between RPCs, but would change if the server was restarted (code might be updated). I think that both would accomplish that, but the instance final might change without a reload, which could be confusing. A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/client/ServerInfo.java Nits: accessor methods? Add @SuppressWarning(serial) added. A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/public/GadgetRPC.html Nit: do you need this file? It is used by the GadgetsRPC-shell startup file so that it doesn't just come up with an error or a blank screen. Except for that the reference might have been missing from GadgetsRPC-shell, which I just added. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps issue 170 - InfoWindow should be Overlay subclass
Should InfoWindow be included in this patch? Shouldn't the Overlay.createPeer method perform the tests on the JavaScriptObject and return the correct concrete wrapper class? On Tue, Sep 16, 2008 at 2:19 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, I would like you to review the attached patch. This patch addresses issue 170 http://code.google.com/p/gwt-google-apis/issues/detail?id=170 This change makes InfoWindow extend the ConcreteOverlay class. It also adds the methods isInfoWindow(), isPolyline(), isPolygon(), and isMarker() to the Overlay class. M maps/maps/test/com/google/gwt/maps/client/overlay/OverlayTest.java M maps/maps/src/com/google/gwt/maps/client/overlay/Overlay.java -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis add Google Earth map type
A
maps/maps/src/com/google/gwt/maps/client/event/EarthInstanceHandler.java
LG
M maps/maps/src/com/google/gwt/maps/client/impl/MapImpl.java
LG
M maps/maps/src/com/google/gwt/maps/client/MapWidget.java
1408 - Javadoc?
M
maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/HelloMaps.java
LG
A
maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/EarthPluginDemo.java
77 - This code won't work on Java 1.5, remove the @Override.Should we run
the demo on a non-windows box?
On Thu, Sep 18, 2008 at 2:51 PM, Eric Ayers [EMAIL PROTECTED] wrote:
Hello Miguel,
Attached is a modified version of the patch was originally put forth by
Jesse Crossley to address issue 128 133.
http://code.google.com/p/gwt-google-apis/issues/detail?id=128
http://code.google.com/p/gwt-google-apis/issues/detail?id=133
I've modified it to use the Handler pattern and added a demo. If you
want to see it work, run it on a Windows platform, that's the only platform
supported by the Google Earth plugin.
-Eric.
On Thu, Jul 17, 2008 at 9:03 AM, Miguel Méndez [EMAIL PROTECTED] wrote:
I think that I drew the *Handler analogy with the assumption that the
spirit of the change would shine through. I fired that email off a little
quickly -- my bad.
What I meant to suggest was that the Java callback interface should
provide some insulation from changes to the signature of the JS callback
interface. I did not mean that we needed to add a handler collection et al.
Something like this would suffice:
interface EarthInstanceCallback {
class EarthInstanceCallbackArguments {
EarthInstance getEarthInstance() {
return ...
}
}
void onEarthInstance(EarthInstanceCallbackArguments args);
}
That way changes to the JS earth callback method signature would result in
the deprecation or addition of members to the EarthInstanceCallbackArguments
class. I suggested this because there have been several times where the JS
API has changed the signature of the the JS callback methods. Given that
the Earth/Maps integration is relatively new I would expect some volatility.
On Wed, Jul 16, 2008 at 8:26 PM, jesse crossley [EMAIL PROTECTED]
wrote:
okay, i think i've got something more in the spirit of the Handler
pattern and that will proof against future google-maps-api changes. patch
is attached. i think, though, that some extra mods have slipped in to
MapWidget and MapWidgetImpl, where i was exposing and playing with methods
i'd found on the GMap2 JavaScript object.
On Wed, Jul 16, 2008 at 4:10 PM, jesse crossley
[EMAIL PROTECTED] wrote:
We are manufacturing the event types. An event type is really just a
container to hold the event arguments. The intention is to future proof
the
gwt-google-apis callbacks against changing JS apis that add or remove
arguments. That is just fine in JS but wreaks havoc on a Java API
(dynanic
vs. strong typing)
so would you envision a public abstract static class
EarthInstanceCallback (defined in EventImpl.java)? and would we also add
EARTHINSTANCEINITIALIZED(earthinstanceinitialized) and
EARTHINSTANCEFAILED(earthinstancefailed) to the MapEvent enumeration?
after looking closer, that seems wrong since we're not attaching any
proper listeners to anything, so the Callback as defined in EventImpl seems
incorrect.
I think the important bit we want to copy from the Handler pattern is
the creating of a container to hold the callback arguments returned from
the
JS callback, and then passing the container as the only argument to the
user
callback. Then, you can add methods to the event object like
getEarthInstance() and isValid() or something like that. This future
proofs
this method against JS API changes.
i think what's giving me grief is trying to match Callback and Handler
terminology. it seems like we would want a public interface
EarthInstanceCallback that behaves like the other
com.google.gwt.maps.event.***Handlers, like this:
public interface EarthInstanceCallback {
class EarthInstanceEvent extends EventObject {
public EarthInstanceEvent(Earth source) {
super(source);
}
public Earth getSender() {
return (Earth) getSource();
}
}
void onInitialized(EarthInstanceEvent event);
void onFailed(EarthInstanceEvent event);
}
with the understanding that EarthInstanceEvent.getSender() will return
null if onFailed(EarthInstanceEvent) is invoked.
would we want this interface to be called EarthInstanceCallback to
match the google-maps-api terminology, or should it be
EarthInstanceHandler, in keeping with the gwt-maps Handler pattern?
if i implement this, then i think the MapWidget will no longer have an
Earth field; it will just invoke the GMap2.getEarthInstance(callback)
method
everytime. ah, but i'll still want to pass in my own callback function to
GMap2 that will then invoke the right method on the EarthInstanceHandler
[gwt-contrib] Re: Code Review: gwt-google-apis add Google Earth map type
LGTM!
On Thu, Sep 18, 2008 at 3:49 PM, Eric Ayers [EMAIL PROTECTED] wrote:
Updated patch attached.
On Thu, Sep 18, 2008 at 3:08 PM, Miguel Méndez [EMAIL PROTECTED] wrote:
A
maps/maps/src/com/google/gwt/maps/client/event/EarthInstanceHandler.java
LG
M maps/maps/src/com/google/gwt/maps/client/impl/MapImpl.java
LG
Removed hideControls() and showControls() from the patch - what were those
methods? I didn't see them documented.
M maps/maps/src/com/google/gwt/maps/client/MapWidget.java
1408 - Javadoc?
Added.
M
maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/HelloMaps.java
LG
A
maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/EarthPluginDemo.java
77 - This code won't work on Java 1.5, remove the @Override.
Fixed.
Should we run the demo on a non-windows box?
If you are asking if I've tested this on a non-windows box, the answer is
yes. It prints a nice not supported or click here to download if your
browser is not supported or it discovers you just don't have the plugin
installed.
I don't want to put in code to remove the method on other machines - you
can test to see if the plugin loaded properly (the callback returns null),
and it could be that in the future the plugin folks will support more
platforms.
On Thu, Sep 18, 2008 at 2:51 PM, Eric Ayers [EMAIL PROTECTED] wrote:
Hello Miguel,
Attached is a modified version of the patch was originally put forth by
Jesse Crossley to address issue 128 133.
http://code.google.com/p/gwt-google-apis/issues/detail?id=128
http://code.google.com/p/gwt-google-apis/issues/detail?id=133
I've modified it to use the Handler pattern and added a demo. If you
want to see it work, run it on a Windows platform, that's the only platform
supported by the Google Earth plugin.
-Eric.
On Thu, Jul 17, 2008 at 9:03 AM, Miguel Méndez [EMAIL PROTECTED]wrote:
I think that I drew the *Handler analogy with the assumption that the
spirit of the change would shine through. I fired that email off a little
quickly -- my bad.
What I meant to suggest was that the Java callback interface should
provide some insulation from changes to the signature of the JS callback
interface. I did not mean that we needed to add a handler collection et
al.
Something like this would suffice:
interface EarthInstanceCallback {
class EarthInstanceCallbackArguments {
EarthInstance getEarthInstance() {
return ...
}
}
void onEarthInstance(EarthInstanceCallbackArguments args);
}
That way changes to the JS earth callback method signature would result
in the deprecation or addition of members to the
EarthInstanceCallbackArguments class. I suggested this because there have
been several times where the JS API has changed the signature of the the JS
callback methods. Given that the Earth/Maps integration is relatively new
I
would expect some volatility.
On Wed, Jul 16, 2008 at 8:26 PM, jesse crossley
[EMAIL PROTECTED] wrote:
okay, i think i've got something more in the spirit of the Handler
pattern and that will proof against future google-maps-api changes. patch
is attached. i think, though, that some extra mods have slipped in to
MapWidget and MapWidgetImpl, where i was exposing and playing with methods
i'd found on the GMap2 JavaScript object.
On Wed, Jul 16, 2008 at 4:10 PM, jesse crossley
[EMAIL PROTECTED] wrote:
We are manufacturing the event types. An event type is really just a
container to hold the event arguments. The intention is to future
proof the
gwt-google-apis callbacks against changing JS apis that add or remove
arguments. That is just fine in JS but wreaks havoc on a Java API
(dynanic
vs. strong typing)
so would you envision a public abstract static class
EarthInstanceCallback (defined in EventImpl.java)? and would we also add
EARTHINSTANCEINITIALIZED(earthinstanceinitialized) and
EARTHINSTANCEFAILED(earthinstancefailed) to the MapEvent enumeration?
after looking closer, that seems wrong since we're not attaching any
proper listeners to anything, so the Callback as defined in EventImpl
seems
incorrect.
I think the important bit we want to copy from the Handler pattern is
the creating of a container to hold the callback arguments returned
from the
JS callback, and then passing the container as the only argument to the
user
callback. Then, you can add methods to the event object like
getEarthInstance() and isValid() or something like that. This future
proofs
this method against JS API changes.
i think what's giving me grief is trying to match Callback and Handler
terminology. it seems like we would want a public interface
EarthInstanceCallback that behaves like the other
com.google.gwt.maps.event.***Handlers, like this:
public interface EarthInstanceCallback {
class EarthInstanceEvent extends EventObject {
public EarthInstanceEvent(Earth source
[gwt-contrib] Re: Code Review: gwt-google-apis add Google Earth map type
Sweet!!!
On Thu, Sep 18, 2008 at 4:32 PM, Eric Ayers [EMAIL PROTECTED] wrote:
Thanks. committed as r803. That was the last issue marked for RC1!
On Thu, Sep 18, 2008 at 4:17 PM, Miguel Méndez [EMAIL PROTECTED] wrote:
LGTM!
On Thu, Sep 18, 2008 at 3:49 PM, Eric Ayers [EMAIL PROTECTED] wrote:
Updated patch attached.
On Thu, Sep 18, 2008 at 3:08 PM, Miguel Méndez [EMAIL PROTECTED]wrote:
A
maps/maps/src/com/google/gwt/maps/client/event/EarthInstanceHandler.java
LG
M maps/maps/src/com/google/gwt/maps/client/impl/MapImpl.java
LG
Removed hideControls() and showControls() from the patch - what were
those methods? I didn't see them documented.
M maps/maps/src/com/google/gwt/maps/client/MapWidget.java
1408 - Javadoc?
Added.
M
maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/HelloMaps.java
LG
A
maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/EarthPluginDemo.java
77 - This code won't work on Java 1.5, remove the @Override.
Fixed.
Should we run the demo on a non-windows box?
If you are asking if I've tested this on a non-windows box, the answer is
yes. It prints a nice not supported or click here to download if your
browser is not supported or it discovers you just don't have the plugin
installed.
I don't want to put in code to remove the method on other machines - you
can test to see if the plugin loaded properly (the callback returns null),
and it could be that in the future the plugin folks will support more
platforms.
On Thu, Sep 18, 2008 at 2:51 PM, Eric Ayers [EMAIL PROTECTED] wrote:
Hello Miguel,
Attached is a modified version of the patch was originally put forth by
Jesse Crossley to address issue 128 133.
http://code.google.com/p/gwt-google-apis/issues/detail?id=128
http://code.google.com/p/gwt-google-apis/issues/detail?id=133
I've modified it to use the Handler pattern and added a demo. If you
want to see it work, run it on a Windows platform, that's the only
platform
supported by the Google Earth plugin.
-Eric.
On Thu, Jul 17, 2008 at 9:03 AM, Miguel Méndez [EMAIL PROTECTED]wrote:
I think that I drew the *Handler analogy with the assumption that the
spirit of the change would shine through. I fired that email off a
little
quickly -- my bad.
What I meant to suggest was that the Java callback interface should
provide some insulation from changes to the signature of the JS callback
interface. I did not mean that we needed to add a handler collection et
al.
Something like this would suffice:
interface EarthInstanceCallback {
class EarthInstanceCallbackArguments {
EarthInstance getEarthInstance() {
return ...
}
}
void onEarthInstance(EarthInstanceCallbackArguments args);
}
That way changes to the JS earth callback method signature would
result in the deprecation or addition of members to the
EarthInstanceCallbackArguments class. I suggested this because there
have
been several times where the JS API has changed the signature of the the
JS
callback methods. Given that the Earth/Maps integration is relatively
new I
would expect some volatility.
On Wed, Jul 16, 2008 at 8:26 PM, jesse crossley
[EMAIL PROTECTED] wrote:
okay, i think i've got something more in the spirit of the Handler
pattern and that will proof against future google-maps-api changes.
patch
is attached. i think, though, that some extra mods have slipped in to
MapWidget and MapWidgetImpl, where i was exposing and playing with
methods
i'd found on the GMap2 JavaScript object.
On Wed, Jul 16, 2008 at 4:10 PM, jesse crossley
[EMAIL PROTECTED] wrote:
We are manufacturing the event types. An event type is really just
a container to hold the event arguments. The intention is to future
proof
the gwt-google-apis callbacks against changing JS apis that add or
remove
arguments. That is just fine in JS but wreaks havoc on a Java API
(dynanic
vs. strong typing)
so would you envision a public abstract static class
EarthInstanceCallback (defined in EventImpl.java)? and would we also
add
EARTHINSTANCEINITIALIZED(earthinstanceinitialized) and
EARTHINSTANCEFAILED(earthinstancefailed) to the MapEvent enumeration?
after looking closer, that seems wrong since we're not attaching any
proper listeners to anything, so the Callback as defined in EventImpl
seems
incorrect.
I think the important bit we want to copy from the Handler pattern
is the creating of a container to hold the callback arguments
returned from
the JS callback, and then passing the container as the only argument
to the
user callback. Then, you can add methods to the event object like
getEarthInstance() and isValid() or something like that. This future
proofs
this method against JS API changes.
i think what's giving me grief is trying to match Callback and
Handler terminology. it seems like we would want a public interface
[gwt-contrib] Re: Code Review: gwt-google-apis Maps update the DirectionsTest
LGTM On Tue, Sep 16, 2008 at 7:40 AM, Eric Ayers [EMAIL PROTECTED] wrote: I updated issue 171 - the 1.5.2 release is broken on this unit test, but has been subsequently fixed. See GWT issue 2841 http://code.google.com/p/google-web-toolkit/issues/detail?id=2841 On Mon, Sep 15, 2008 at 4:30 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, This resolves issue 171 - which was apparently due to a core GWT issue. It also adds a few more tests to the DirectionsTest, and updates the Marker class to properly extract Markers from a list. M maps/maps/test/com/google/gwt/maps/client/geocode/DirectionsTest.java M maps/maps/src/com/google/gwt/maps/client/overlay/Marker.java -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps issue 46 - add MapWidget.closeInfoWindow()
LGTM On Fri, Sep 12, 2008 at 5:12 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, This change addresses issue 46 (add the closeInfoWindow() method to the MapWidget class), and also addresses a long standing issue, which is to make a 1:1 relationship between the InfoWindow object and the MapWidget object. Now there is an instance variable in MapWidget so that we only construct a new InfoWindow object once. M maps/maps/src/com/google/gwt/maps/client/impl/MapImpl.java M maps/maps/src/com/google/gwt/maps/client/MapWidget.java M maps/maps/test/com/google/gwt/maps/client/MapWidgetTest.java -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps Convert LatLng and LatLngBounds to JavaScript overlay
LGTM - Don't forget to set the mime type and line ending properties for the new files. What is the resolution for the DirectionResults TODOs? Is this future work? On Thu, Sep 11, 2008 at 2:29 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, I would like for you to review the attached patch. Its pretty big. This patch converts LatLng and LatLngBounds to JavaScript overlays. - Changes all constructors from new LatLng(...) to LatLng.newInstance(...) - Adds unit tests for LatLng and LatLngBounds - Updates the Drawing demo (there were cases where changing the input values caused the demo to fail) - Found a bug in DirectionResults.getPolyline() - this will be fixed when converting Polyline to a JSO subclass. - Removed LatLngImpl and LatLngBoundsImpl classes. M maps/maps/test/com/google/gwt/maps/MapsTestSuite.java M maps/maps/test/com/google/gwt/maps/client/overlay/MarkerTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/OverlayTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/MarkerEventsTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolygonTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolyEventsTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/IconTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolylineTest.java M maps/maps/test/com/google/gwt/maps/client/MapWidgetTest.java M maps/maps/test/com/google/gwt/maps/client/MapsNotInstalledTest.java M maps/maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java M maps/maps/test/com/google/gwt/maps/client/geocode/DirectionsTest.java M maps/maps/test/com/google/gwt/maps/client/MapWidgetEventsTest.java A maps/maps/test/com/google/gwt/maps/client/geom/LatLngTest.java M maps/maps/test/com/google/gwt/maps/client/geom/ProjectionTest.java A maps/maps/test/com/google/gwt/maps/client/geom/LatLngBoundsTest.java M maps/maps/test/com/google/gwt/maps/client/InfoWindowEventsTest.java M maps/maps/test/com/google/gwt/maps/client/CopyrightEventTest.java M maps/maps/src/com/google/gwt/maps/client/overlay/Polygon.java M maps/maps/src/com/google/gwt/maps/client/overlay/Polyline.java M maps/maps/src/com/google/gwt/maps/client/geom/LatLng.java M maps/maps/src/com/google/gwt/maps/client/geom/LatLngBounds.java M maps/maps/src/com/google/gwt/maps/client/MapWidget.java D maps/maps/src/com/google/gwt/maps/client/impl/LatLngImpl.java M maps/maps/src/com/google/gwt/maps/client/impl/PolygonImpl.java M maps/maps/src/com/google/gwt/maps/client/impl/JsUtil.java M maps/maps/src/com/google/gwt/maps/client/impl/PolylineImpl.java D maps/maps/src/com/google/gwt/maps/client/impl/LatLngBoundsImpl.java M maps/maps/src/com/google/gwt/maps/client/geocode/Placemark.java M maps/maps/src/com/google/gwt/maps/client/geocode/DirectionResults.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DrawingOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/GroundOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/ControlsDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/GeoRssOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/CustomMapTypeDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/SimpleDirectionsDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/AnimateDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DragMarkerDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/MapEventDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/EventDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/OverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/KmlOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/ClickDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/MarkerInfoWindowDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/Geocoder2Demo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DragCursorDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/CustomControlDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/CustomOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/IconClassDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/MapTypeDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/TrafficOverlayDemo.java M
[gwt-contrib] Re: Code Review: gwt-google-apis Maps Convert LatLng and LatLngBounds to JavaScript overlay
On Fri, Sep 12, 2008 at 9:55 AM, Eric Ayers [EMAIL PROTECTED] wrote: Hi Miguel, Thanks for the review. I submitted issue 181 for the DirectionResults.getPolyline(). I suppose this has been an issue for a long time. Since we don't plan to convert Polyline to a JS Overlay, I'm not sure what the resolution will be. I think that you meant issue 171. Looks like we will need to kick off the JSIO wrapping stuff manually. I haven't had to set the mime types or line ending properties for files I just updated to r785 and the mime types and lines endings aren't set on the new files. It won't appear to matter until people start using windows and unix systems to work on the source code. Committed the fix in r786. Committed as r785. On Fri, Sep 12, 2008 at 9:25 AM, Miguel Méndez [EMAIL PROTECTED] wrote: LGTM - Don't forget to set the mime type and line ending properties for the new files. What is the resolution for the DirectionResults TODOs? Is this future work? On Thu, Sep 11, 2008 at 2:29 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, I would like for you to review the attached patch. Its pretty big. This patch converts LatLng and LatLngBounds to JavaScript overlays. - Changes all constructors from new LatLng(...) to LatLng.newInstance(...) - Adds unit tests for LatLng and LatLngBounds - Updates the Drawing demo (there were cases where changing the input values caused the demo to fail) - Found a bug in DirectionResults.getPolyline() - this will be fixed when converting Polyline to a JSO subclass. - Removed LatLngImpl and LatLngBoundsImpl classes. M maps/maps/test/com/google/gwt/maps/MapsTestSuite.java M maps/maps/test/com/google/gwt/maps/client/overlay/MarkerTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/OverlayTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/MarkerEventsTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolygonTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolyEventsTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/IconTest.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolylineTest.java M maps/maps/test/com/google/gwt/maps/client/MapWidgetTest.java M maps/maps/test/com/google/gwt/maps/client/MapsNotInstalledTest.java M maps/maps/test/com/google/gwt/maps/client/impl/MinimumMapVersionTest.java M maps/maps/test/com/google/gwt/maps/client/geocode/DirectionsTest.java M maps/maps/test/com/google/gwt/maps/client/MapWidgetEventsTest.java A maps/maps/test/com/google/gwt/maps/client/geom/LatLngTest.java M maps/maps/test/com/google/gwt/maps/client/geom/ProjectionTest.java A maps/maps/test/com/google/gwt/maps/client/geom/LatLngBoundsTest.java M maps/maps/test/com/google/gwt/maps/client/InfoWindowEventsTest.java M maps/maps/test/com/google/gwt/maps/client/CopyrightEventTest.java M maps/maps/src/com/google/gwt/maps/client/overlay/Polygon.java M maps/maps/src/com/google/gwt/maps/client/overlay/Polyline.java M maps/maps/src/com/google/gwt/maps/client/geom/LatLng.java M maps/maps/src/com/google/gwt/maps/client/geom/LatLngBounds.java M maps/maps/src/com/google/gwt/maps/client/MapWidget.java D maps/maps/src/com/google/gwt/maps/client/impl/LatLngImpl.java M maps/maps/src/com/google/gwt/maps/client/impl/PolygonImpl.java M maps/maps/src/com/google/gwt/maps/client/impl/JsUtil.java M maps/maps/src/com/google/gwt/maps/client/impl/PolylineImpl.java D maps/maps/src/com/google/gwt/maps/client/impl/LatLngBoundsImpl.java M maps/maps/src/com/google/gwt/maps/client/geocode/Placemark.java M maps/maps/src/com/google/gwt/maps/client/geocode/DirectionResults.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DrawingOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/GroundOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/ControlsDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/GeoRssOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/CustomMapTypeDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/SimpleDirectionsDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/AnimateDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DragMarkerDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/MapEventDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/EventDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/OverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/KmlOverlayDemo.java M maps/samples
[gwt-contrib] Re: Code Review: gwt-google-apis Maps convert PolyXXXOptions to JavaScript overlays
On Tue, Sep 9, 2008 at 3:54 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, I've combined the conversion of several classes into one patch because of the overlap. - PolylineOptions - PolygonOptions - Fixed constructor name in PolyStyleOptions.java - Fixed references to above. - Changed some references to PolylineOptions to EncodedPolyline... that was weird! M maps/maps/test/com/google/gwt/maps/client/overlay/PolygonTest.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/PolygonOptions.java LG - consider adding a newInstance(boolean clickable) method. A maps/maps/src/com/google/gwt/maps/client/overlay/PolylineOptions.java LG - This is one place where we could provide an additional newInstance overload to specify clickable and geodesic. M maps/maps/src/com/google/gwt/maps/client/overlay/EncodedPolyline.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/PolyStyleOptions.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/Polygon.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/Polyline.java LG D maps/maps/src/com/google/gwt/maps/client/impl/PolyStyleOptionsImpl.java LG M maps/maps/src/com/google/gwt/maps/client/impl/PolylineFactoryImpl.java LG - Is this an overlay conversion candidate? D maps/maps/src/com/google/gwt/maps/client/impl/PolygonOptionsImpl.java LG D maps/maps/src/com/google/gwt/maps/client/impl/PolylineOptionsImpl.java LG M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DrawingOverlayDemo.java LG M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/OverlayDemo.java LG -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps Convert Bounds to JavaScript overlay
On Wed, Sep 10, 2008 at 9:43 AM, Eric Ayers [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 9:13 AM, Miguel Méndez [EMAIL PROTECTED] wrote: On Mon, Sep 8, 2008 at 5:37 PM, Eric Ayers [EMAIL PROTECTED] wrote: M maps/maps/src/com/google/gwt/maps/client/geom/Bounds.java 37 - This Bounds construction is not part of the Maps API proper and it is only called from our test code. Do we still need it? I added this as a convenience, because I was tired of constructing JsArrays over and over in the test code. It results in compiled code just as tight or tighter (if you don't already have Point objects made). We could add a 3rd constructor with 2 point objects. Sounds like it should be in the test code then. If anything you could create a variadic method to take Point arguments and return a JsArrayPoint. I would not worry about a third constructor for now. 105, 114, 123, 132 - Should get[Max|Min][X|Y] just return doubles? The JS API just states that this is a Number however the documentation would lead you to believe that it is really an integer value. It seems like the safest thing to do would be to use a double. Maybe Pam could shed some light? This would call into question the newPoint method. This sounds familiar - have we been through this before? Along with Point, this object represents pixels on the screen. Of course, JS doesn't have an integer type, but I see in the JS code that pixel values (stored in the Bounds object) are looped through with for loops with operators like x++ and y--, indicating to me they are intended to be integers. We have been through this before, but it seems that every instance in the maps API is unique. ++ and -- are valid for floating point also it might be more illuminating to look at the terminating condition for the loop. Better yet, just double check with Pam. -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: gwt-google-apis Maps convert PolyXXXOptions to JavaScript overlays
LGTM On Wed, Sep 10, 2008 at 12:52 PM, Eric Ayers [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 9:48 AM, Miguel Méndez [EMAIL PROTECTED] wrote: On Tue, Sep 9, 2008 at 3:54 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello Miguel, I've combined the conversion of several classes into one patch because of the overlap. - PolylineOptions - PolygonOptions - Fixed constructor name in PolyStyleOptions.java - Fixed references to above. - Changed some references to PolylineOptions to EncodedPolyline... that was weird! M maps/maps/test/com/google/gwt/maps/client/overlay/PolygonTest.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/PolygonOptions.java LG - consider adding a newInstance(boolean clickable) method. done. A maps/maps/src/com/google/gwt/maps/client/overlay/PolylineOptions.java LG - This is one place where we could provide an additional newInstance overload to specify clickable and geodesic. created newInstance(boolean clickable) and newInstance(boolean clickable, boolean geodesic) M maps/maps/src/com/google/gwt/maps/client/overlay/EncodedPolyline.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/PolyStyleOptions.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/Polygon.java LG M maps/maps/src/com/google/gwt/maps/client/overlay/Polyline.java LG D maps/maps/src/com/google/gwt/maps/client/impl/PolyStyleOptionsImpl.java LG M maps/maps/src/com/google/gwt/maps/client/impl/PolylineFactoryImpl.java LG - Is this an overlay conversion candidate? D maps/maps/src/com/google/gwt/maps/client/impl/PolygonOptionsImpl.java LG D maps/maps/src/com/google/gwt/maps/client/impl/PolylineOptionsImpl.java LG M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DrawingOverlayDemo.java LG M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/OverlayDemo.java LG -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel I've gone ahead and committed this patch as r774, but attached it in case you feel it needs further review. I Modified the tests a bit, adding a new PolylineTest class. M maps/maps/test/com/google/gwt/maps/MapsTestSuite.java M maps/maps/test/com/google/gwt/maps/client/overlay/PolygonTest.java M maps/maps/src/com/google/gwt/maps/client/overlay/PolygonOptions.java A maps/maps/src/com/google/gwt/maps/client/overlay/PolylineOptions.java M maps/maps/src/com/google/gwt/maps/client/overlay/EncodedPolyline.java M maps/maps/src/com/google/gwt/maps/client/overlay/PolyStyleOptions.java M maps/maps/src/com/google/gwt/maps/client/overlay/Polygon.java M maps/maps/src/com/google/gwt/maps/client/overlay/Polyline.java D maps/maps/src/com/google/gwt/maps/client/impl/PolyStyleOptionsImpl.java M maps/maps/src/com/google/gwt/maps/client/impl/PolylineFactoryImpl.java D maps/maps/src/com/google/gwt/maps/client/impl/PolygonOptionsImpl.java D maps/maps/src/com/google/gwt/maps/client/impl/PolylineOptionsImpl.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/DrawingOverlayDemo.java M maps/samples/hellomaps/src/com/google/gwt/maps/sample/hellomaps/client/OverlayDemo.java -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
