Re: Possible performance enhancements for CalendarUtil.getDaysBetween()

2015-01-31 Thread Davide Cavestro
I must admit I didn't spend enough time to fully understand why the
gwt original  implementation did all that stuff for resetting time. Many
thanks for the detailed explanation.
At the moment I have no access to dev tools, anyway I'm just wondering if
there's still room for optimizations without incurring in bugs: i.e. if
resetting dates time is needed, then CalendarUtils could keep two private
static Date instances instead of instantiating two new dates per call (that
should be safe until there's no multithreading)

2015-01-31 3:08 GMT+01:00 Jens :

> Your implementation does not have same behavior as the original GWT one.
>
> GWTs implementation resets hours, minutes, seconds and milliseconds while
> your implementation only resets milliseconds AND you reset them wrong as
> well :) For negative getTime() your calculation moves time to the next
> second into the future which is wrong because when you reset time you
> always want to go into the past (so you do not modify the actual day
> accidentally)
>
> As you only have modified the way aTime and bTime are calculated I have
> printed them for current GWT implementation and your new implementation.
> See output:
>
> start: 1969-12-31 *22:30:30.500*
> end: 1970-01-02 15:30:30.500
>
> current GWT aTime: -9000 => Date: 1969-12-31 *00:00:00.000*
> current GWT bTime: 8280 => Date: 1970-01-02 00:00:00.000
> *current GWT days between: 2*
>
> new aTime: -8969000 => Date: 1969-12-31 *22:30:31.000*
> new bTime: 13863 => Date: 1970-01-02 15:30:30.000
> *new days between: 1*
>
> As you can see your implementation does not reset the full time and your
> millisecond reset moves the start date 500ms into the future.
>
> GWT had the same millisecond reset bug until I fixed it in
> https://gwt-review.googlesource.com/#/c/7462/3
> This bug has caused some exceptions in DatePicker for dates that are
> within 1000ms before epoch as described in the corresponding bug report:
> https://code.google.com/p/google-web-toolkit/issues/detail?id=8653
>
>
> -- J.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/OVnGQi0k-Y4/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Possible performance enhancements for CalendarUtil.getDaysBetween()

2015-01-30 Thread Davide Cavestro
I guess com.google.gwt.user.datepicker.client.CalendarUtil.getDaysBetween(Date, 
Date) was written with datepicker in mind, BTW I've seen some code making 
heavy use of that method, and its performance was badly impacted.
Since actual implementation internally instantiates two new dates per every 
invocation and then resets the time for each of them, I've simply rewritten 
the same logic avoiding date instantiation and time resets, and this gave 
me good results.
So I hope CalendarUtil.getDaysBetween() could be enhanced the same way.

Follows an excerpt of a naive test comparing one shot original vs optimized 
implementation... clearly this kind of measurement doesn't consider GC time 
(mainly induced by original implementation) so I'd consider its results 
pessimistic. Nonetheless running it with Chrome 37 on my host, the 
execution time of optimized code is almost constantly 25% of original one.

public class Main implements EntryPoint {

@Override
public void onModuleLoad() {
final int count = 10;

final Date prev = new Date(0);
final Date next = new Date(0);
long optTime = 0;
long origTime = 0;

for (int i = 0; i "+count+" steps took 
"+optTime+"ms");
//GWT.log ("Original implementation> "+count+" steps took 
"+origTime+"ms");
}

/**
 * {@code CalendarUtil.getDaysBetween()} optimized reimplementation.
 * 
 * @see CalendarUtil#getDaysBetween(Date, Date)
 */
protected int getDaysBetween(final Date start, final Date finish) {
// Extracts midnight time for both dates
final long aTime = (start.getTime() / 1000) * 1000;
final long bTime = (finish.getTime() / 1000) * 1000;

long adjust = 60 * 60 * 1000;
adjust = (bTime > aTime) ? adjust : -adjust;

return (int) ((bTime - aTime + adjust) / (24 * 60 * 60 * 1000));
}
}

Talking about real world code instead, this change practically removed 
getDaysBetween effects from CPU profiling charts, while it was originally 
one of the main components.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


R: Re: How to dynamically choose locale at SuperDevMode compile time?

2014-08-15 Thread Davide Cavestro
Thanks! I'll give it a try as soon as I return at office. Did you consider 
contributing the gwt project with this patch?


Davide Cavestro

Aleš Pečnik  ha scritto:

I use meta tag in HTML for setting locale:


I use GWT from trunk, in Eclipse with -superDevMode argument, without 
bookmarklet. This patch works for me:

diff --git a/dev/codeserver/java/com/google/gwt/dev/codeserver/dev_mode_on.js 
b/dev/codeserver/java/com/google/gwt/dev/codeserver/dev_mode_on.js
index 2964be7..9bb0a92 100644
--- a/dev/codeserver/java/com/google/gwt/dev/codeserver/dev_mode_on.js
+++ b/dev/codeserver/java/com/google/gwt/dev/codeserver/dev_mode_on.js
@@ -380,6 +380,11 @@

 var url = url_prefix + '_callback=__gwt_bookmarklet_globals.callbacks.' +
 callback_id;
+    var nodelist=document.getElementsByTagName('meta');
+    for(var i=0; ihttps://groups.google.com/d/topic/google-web-toolkit/CJz8e_SyYTI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: How to dynamically choose locale at SuperDevMode compile time?

2014-07-23 Thread Davide Cavestro
Hey guys, no idea at all? I would need a way to set the locale for the 
super dev mode compile (even from dedicated bookmarklets would be enough...)

On Friday, July 18, 2014 4:10:50 PM UTC+2, Davide Cavestro wrote:
>
> It seems that the super dev mode cannot benefit from the meta tag 
> <https://code.google.com/p/google-web-toolkit/issues/detail?id=8175> defined 
> within a dynamic host page. I originally tried switching to the cookie 
> solution, but now I guess the compilation triggered by the bookmarklet 
> simply ignores any locale-related info derived from the host page, such as 
> the meta property, the query param and the cookie (set on host page domain).
> But this way - supposed the gwt locale should reflect some data coming 
> from a database - we have no way to make the superdevmode aware of the 
> chosen locale.
>
> Moreover, Thomas Broyer recently suggested 
> <http://stackoverflow.com/a/16295300/2652766> to
>
>> set the locale property to the full list of supported locales:
>> 
>
> in order to achieve dynamic internationalization. I thought simply 
> extending the locale property with additional values was enough, but I've 
> found no documentation talking about multiple values for this property.
> But as soon as I define multiple values for the locale property, the 
> SuperDevMode starts compiling too many permutations, eventually complaining 
> *Multiple 
> fragment 0 sourcemaps found. Too many permutations.*
> I guess this happens because it has no way to reduce the permutations 
> based on the chosen locale (in fact it doesn't log any *binding: 
> locale=...*).
>
> So my question is: what should I do in order to dynamically choose the 
> locale used by SDM compiler?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


How to dynamically choose locale at SuperDevMode compile time?

2014-07-18 Thread Davide Cavestro
It seems that the super dev mode cannot benefit from the meta tag 
 defined 
within a dynamic host page. I originally tried switching to the cookie 
solution, but now I guess the compilation triggered by the bookmarklet 
simply ignores any locale-related info derived from the host page, such as 
the meta property, the query param and the cookie (set on host page domain).
But this way - supposed the gwt locale should reflect some data coming from 
a database - we have no way to make the superdevmode aware of the chosen 
locale.

Moreover, Thomas Broyer recently suggested 
 to

> set the locale property to the full list of supported locales:
> 

in order to achieve dynamic internationalization. I thought simply 
extending the locale property with additional values was enough, but I've 
found no documentation talking about multiple values for this property.
But as soon as I define multiple values for the locale property, the 
SuperDevMode starts compiling too many permutations, eventually complaining 
*Multiple 
fragment 0 sourcemaps found. Too many permutations.*
I guess this happens because it has no way to reduce the permutations based 
on the chosen locale (in fact it doesn't log any *binding: locale=...*).

So my question is: what should I do in order to dynamically choose the 
locale used by SDM compiler?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: GWT compiling tools: is there any way to get the graph of inherited modules? Even a simple flat list would be fine :-)

2014-02-27 Thread Davide Cavestro
I've patched the original file in order to provide

   - better exit status handling
   - alternative output type (a textual representation of the deps tree)
   - possibility to write on the standard output

Follows an excerpt from the dependency tree 
--+com.google.gwt.user.UserAgent 
  |  
  `--+com.google.gwt.useragent.UserAgent 
 |   
 +--+com.google.gwt.core.CoreWithUserAgent   
 |  |
 |  +--+com.google.gwt.core.EmulateJsStack   
 |  |
 |  `-->com.google.gwt.core.CompilerParameters   
 |   
 `--+com.google.gwt.emul.EmulationWithUserAgent  
|
`--+com.google.gwt.emul.Emulation
   | 
   `-->com.google.gwt.logging.LogImpl


It works quite fine for me (integrated it into a gradle script) and I'd 
like to propose a patch, but I've never used gerrit, so I don't know how to 
propose a new patch to the existing review. May I post the changed file 
here?

Cheers
Davide

On Tuesday, February 25, 2014 3:31:28 PM UTC+1, Thomas Broyer wrote:
>
>
> On Tuesday, February 25, 2014 3:25:47 PM UTC+1, Davide Cavestro wrote:
>>
>> Hi all,
>> I am in the process of switching linker to Cross-Site-Iframe in order to 
>> obtain the compatibility with superdevmode, so I'd like to locate and 
>> remove the script tags from the modules I'm inheriting from (since this 
>> linker doesn't support them).
>> Now I'm just  wondering if there's an easy way to obtain from the gwt 
>> compiler or other tools the *graph of inherited modules* (possibly 
>> transitive).
>> It would be really useful in order to avoid having to manually read every 
>> inherited module to find additional inherited modules and so on.
>> Also, having a clear graph of this kind of dependencies would be a good 
>> check tool especially when you depend on 3rd party modules.
>>
>
> I once wrote a tiny tool that does just that: 
> https://gwt-review.googlesource.com/1210
> Or you could just compile with -logLevel DEBUG and grep for "Loading 
> inherited module" 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


Any DTD for GWT 2.6.0?

2014-02-26 Thread Davide Cavestro
I'm just wondering if there's a DTD available for  *.gwt.xml* file related 
with the 2.6.0 release
I'd expect to find it at http://google-web-toolkit.googlecode.com/svn/ 
tags/2.6.0/distro-source/core/src/gwt-module.dtd but actually there's no 
2.6.0 tag into svn repo

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


Re: GWT compiling tools: is there any way to get the graph of inherited modules? Even a simple flat list would be fine :-)

2014-02-25 Thread Davide Cavestro
I've seen that SmartGWT provided the *NoScript* flavour for their modules,
i.e. instead of inheriting from *SmartGwt* you inherit from
*SmartGwtNoScript.*
I've seen also adding

to your .gwt.xml file works (as suggested by the compiler).


2014-02-26 3:20 GMT+01:00 Srini v :

> We have an issue similar to it where we want to move to xsi frame linker
> but what if you have third party dependent modules which have script tag in
> their module XML. Did anyone face the same issue and solved it?
>
>
> On Tuesday, 25 February 2014, Jens  wrote:
>
>> Not officially I think, but in GWT's code review tool there is a patch
>> lingering around for a long time:
>> https://gwt-review.googlesource.com/#/c/1210/
>>
>> Not sure if it needs a little love again to work with GWT 2.6 but its
>> probably a good starting point.
>>
>> -- J.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit+unsubscr...@googlegroups.com.
>>
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> Visit this group at http://groups.google.com/group/google-web-toolkit.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/QLdcqcXXMtk/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


GWT compiling tools: is there any way to get the graph of inherited modules? Even a simple flat list would be fine :-)

2014-02-25 Thread Davide Cavestro
Hi all,
I am in the process of switching linker to Cross-Site-Iframe in order to 
obtain the compatibility with superdevmode, so I'd like to locate and 
remove the script tags from the modules I'm inheriting from (since this 
linker doesn't support them).
Now I'm just  wondering if there's an easy way to obtain from the gwt 
compiler or other tools the *graph of inherited modules* (possibly 
transitive).
It would be really useful in order to avoid having to manually read every 
inherited module to find additional inherited modules and so on.
Also, having a clear graph of this kind of dependencies would be a good 
check tool especially when you depend on 3rd party modules.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


Re: SuperDevMode on/off bookmarklets aren't compatible with frames

2014-02-20 Thread Davide Cavestro
The problem was that I didn't adapted the script portion that saves the 
__gwt_bookmarklet_params variable (it should work on the frame window).

So since in my case the frame was called 'sheet', at the end for me it was 
enough adapting it this way

> javascript:%7B var sheetFrame %3D document.getElementById('sheet') %3B 
> sheetFrame.contentWindow.__gwt_bookmarklet_params %3D 
> %7B'server_url'%3A'http%3A%2F%2Flocalhost%3A9876%2F'%7D%3B var s %3D 
> sheetFrame.contentWindow.document.createElement('script')%3B s.src %3D 
> 'http%3A%2F%2Flocalhost%3A9876%2Fdev_mode_on.js'%3B 
> void(sheetFrame.contentWindow.document.getElementsByTagName('head')%5B0%5D.appendChild(s))%3B%7D


that is simply the URL encoded version of

> javascript:{ var sheetFrame = document.getElementById('sheet') ; 
> sheetFrame.contentWindow.__gwt_bookmarklet_params = 
> {'server_url':'http://localhost:9876/'}; var s = 
> sheetFrame.contentWindow.document.createElement('script'); s.src = 
> 'http://localhost:9876/dev_mode_on.js'; 
> void(sheetFrame.contentWindow.document.getElementsByTagName('head')[0].appendChild(s));}
>

Cheers
Davide

On Wednesday, February 12, 2014 5:55:07 PM UTC+1, Davide Cavestro wrote:
>
> I have an entry point hosted into an iframe. I have to manually open the 
> host page into a new browser tab in order to make the superdev mode aware 
> of the modules available (otherwise the superdev mode UI doesn't detect any 
> module).
> I've tried to manually tweak the bookmarklet code in order to create the 
> boot script element within the frame (instead than within the outer 
> document) but at this point when I run the bookmarklet I obtain a dialog 
> complaining
>
> *Need to reinstall the bookmarklets.*
>
> I suspect the bookmarklet js code is somewhat validated against some hash, 
> and if I manually edit it the validation fails...
> Is there any workaround?
> I reproduce this issue with GWT 2.6.0 both on Google Chrome 32.0.1700.107 
> and Firefox 26.0
>
> Kind regards
> Davide
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


SuperDevMode on/off bookmarklets aren't compatible with frames

2014-02-12 Thread Davide Cavestro
I have an entry point hosted into an iframe. I have to manually open the 
host page into a new browser tab in order to make the superdev mode aware 
of the modules available (otherwise the superdev mode UI doesn't detect any 
module).
I've tried to manually tweak the bookmarklet code in order to create the 
boot script element within the frame (instead than within the outer 
document) but at this point when I run the bookmarklet I obtain a dialog 
complaining

*Need to reinstall the bookmarklets.*

I suspect the bookmarklet js code is somewhat validated against some hash, 
and if I manually edit it the validation fails...
Is there any workaround?
I reproduce this issue with GWT 2.6.0 both on Google Chrome 32.0.1700.107 
and Firefox 26.0

Kind regards
Davide

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


On extension strategies for GWT applications

2013-10-17 Thread Davide Cavestro
I have to support the deployment of additional modules in order to 
dynamically extend my employer's GWT application, adding new features or 
customizing the existing ones.
I mean *something like a plugin system which dynamically loads and executes 
new code deployed at any point of time*.

The basic application is composed by several logical modules: they are 
compiled together and make heavy use of GIN and DFN code splitting.
So I'm looking for a way to make the additional modules coexist with the 
basic application, hence supplying additional features *within the same 
HTML host page* of the original application.

At server side I have a Spring web MVC application. In order to deploy the 
additional modules it is acceptable having to restart the web application 
(if needed), while it is not acceptable having to redeploy the entire war 
application. i.e. I could introduce some dedicated controllers to serve 
contents from additional modules at the appropriate URIs.

I'd like to know:
  1) is there *any well established pattern for this kind of scenario?*
  2) is there any certainty that compiling two modules separately then I 
can run them into the same HTML host page without any clash? i.e. separate 
GWT compiler executions on separate modules could generate globally-scoped 
javascript variables with the same name?
2.a) if I can compile them separately, then I should find a way to make 
the two applications communicate, potentially sharing references of object 
managed by GIN. Is it feasible?
2.b) if I cannot compile them separately, then is there any alternative 
to recompile them before the deploy? i.e. did anyone successfully integrate the 
GWT compiler or the superdevmode at the server side for production uses?


-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Overuse of "AssumedStale" Issue Tag

2013-06-04 Thread Davide Cavestro
@Ed
I really hope you are right... but so far I've had the same feelings of 
Mauro and David
I guess some discouragement/vexation could be avoided adding an explanatory 
comment before or contextually tagging an issue as *AssumedStale*, and 
especially avoid stating

> I spent more than half an hour reading the code and the specs and doing 
> tests. We can't realistically spend as many time on each and every opened 
> issue. 

That really makes me wonder...

On Tuesday, June 4, 2013 9:50:15 AM UTC+2, Ed wrote:
>
> @David, @Mauro,
>
> I am surprised and disappointed by your reactions.
> My reaction on this all:
> Please be positive and not so negative. Clearly your glass is half empty 
> and mine is half full (and I am using GWT for about 7 years now)...
> Please follow the GWT news, G+ GWT posts, Ray Google 2013 GWT session, the 
> issues being solved blazing fasts currently..., the contributor forum, 
> etc...
> I am sure that if you follow these sources, your glass will be half full 
> as well. If not, please see a doctor ;)...
>
> @David: your list of negative points is incorrect as I am building huge 
> gwt projects and don't have this experience of 80% of your issues. So you 
> might want to consider refactoring/reviewing your code/GWT usage.
>
> GWT had a tough year putting all pieces in place, but I think things look 
> very promising which they  are showing if you follow the above sources...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.