from:"'John Stalcup' via GWT Contributors"

Re: [gwt-contrib] Setting up gwt project for development

2016-05-09 Thread 'John Stalcup' via GWT Contributors

Konstantin:

You're correct that internally we use Blaze (which is open sourced as Bazel
at http://bazel.io/) and not Ant.

But even though most of our BUILD files (the build configuration that Blaze
uses) are included in the open source repo, some significant pieces are
missing (some referenced scripts, Bazel/Skylark implementation of
gwt_module, and Bazel/Skylark implementation of gwt_application).

You probably won't be able to get it to work, so I don't recommend it
unless you just think it will be interesting.

John


On Thu, May 5, 2016 at 3:55 PM, Konstantin Solomatov <
konstantin.soloma...@gmail.com> wrote:

> Hello,
>
> How do you usually setup the gwt project for development? The repository
> provides only ant build file which is quite slow to build, and hard to
> test. It's possible to develop in this way, but IMO, the feedback cycle is
> too slow. Do you know any way to optimize this?
>
> I am almost sure that google contributors don't use it directly but use
> blaze instead. Is there any probability that this stuff will be made
> available to wider audience?
>
> Thanks,
> Kostya
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8d688945-563f-4c4e-befa-d31909deb0dc%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ94yvCWawT1Hvf-9VV%2BNr4z2_6ofSTrZ_ButhekBmrwBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

2015-11-13 Thread 'John Stalcup' via GWT Contributors

Generally speaking J2CL seeks to support Java language features and in the
process of doing so make use of modern ES6 features. When it comes to the
separate topic of making advanced ES6 features (that don't exist in the
Java language) available to J2CL users the path for that is via the
JsInterop spec.

To be specific:

- J2CL currently outputs Closure goog.module()s instead of ES6 modules
because no browser yet supports ES6 modules and we like having our output
immediately runnable in the browser without a ES6to5 downsampling. When
browsers support ES6 modules we are likely to switch.
- When/if the Java language provides Decorators/Generators/Async functions
we will transpile them
- The JsInterop spec does not currently provide sugar for
Decorators/Generators/Async
functions but it might in a future revision
- You can already take advantage of Generators and Async functions (but
probably not Decorators) by using JsInterop to expose a JS library to Java
where that JS library exposes utility functions for Generators and Async
functions


On Fri, Nov 13, 2015 at 1:27 PM, Paul Stockley  wrote:

> Do you plan on supporting these features in j2cl in the future?
>
> On Friday, November 13, 2015 at 4:23:21 PM UTC-5, Ray Cromwell wrote:
>>
>>
>> You could probably support Modules via a GWT linker. Generators and Async
>> functions could be done by a GWT Generator/Linker combo + BabelJS.  There's
>> no real plans to support ES6 in GWT, but you could arrange enough hacks
>> with Generator/Linker/Library stuff to make GWT 2.x stuff consumable from
>> ES6 code.
>>
>> On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley 
>> wrote:
>>
>>> A number of the new frameworks (Angular 2, Aurelia)  are planning on
>>> using ES6 and ES7 features such as Modules, Decorators, Generators and
>>> Async functions etc. Are there plans to support these on the 2.x code base
>>> or would these only be supported by j2cl in the future?
>>>
>>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:

 As we are getting close to 2.8 release I wrote a new document that is
 concentrating on jsinterop features to be released in 2.8:

 https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#

 Please share your feedback.

 Thanks,

 Goktug

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/b5adb853-08d2-42b1-a69a-fccc2d81004d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-%3DWHGsq--dO7jj825U64iqj_ZNCjU9_P8-hP3T4MYFOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java to WebAssembly Compiler

2015-06-22 Thread 'John Stalcup' via GWT Contributors

My thoughts are pretty much exactly what Colin said.

Without GC it's not a reasonable target for Java cross compilation because
you'd have to embed your own GC implementation into the output.

That being said, they plan to add GC, which will make it more attractive.
But WebAssembly would probably be even less readable than current GWT
output. So it might be good for GWT apps that don't interoperate with any
external JS and might be bad for those that do interoperate wtih external
JS.

On Mon, Jun 22, 2015 at 12:16 PM Colin Alworth niloc...@gmail.com wrote:

Without GC, I think its going to be a bit of a non-starter - the same
issues that apply to compiling to asm.js apply here too. I've heard a few
ideas floated around to just compile specific methods to asm.js, and those
same ideas seem that they could work, but the really hard part is isolating
these pieces of code, and at least for asm.js, you can actually take a
significant performance hit from moving data into (or even just allocating)
typed arrays. If you can tune the feature to how you'll need it (i.e. only
ask the compiler to turn it on if you'll keep them around for a long time
and have very hot code running through there) it seems worth it, but at
that point JSNI or JsInterop might almost be easier to talk to raw JS (or
WebAssembly) to guarantee that you get it right.

That said, GC is an eventual design goal in WebAssembly, so I think GWT or
something like GWT could make it an eventual target.

/2cents

On Mon, Jun 22, 2015 at 2:03 PM Joel Handwell joelhandw...@gmail.com
wrote:

- Luke Wagner wrote a post on his blog to report that his team at Mozilla
have started working with Chromium, Edge and WebKit engineers on creating a
new standard, WebAssembly, that defines a portable, size- and
load-time-efficient format and execution model specifically designed to
serve as a compilation target for the Web.

- Google's JF Bastien mentions
https://github.com/WebAssembly/design/commit/34318807a17cb43d79e8cf5939319e5b4909dc6d
GWT in the design document of WebAssembly as a better execution for
languages and toolkits that are currently cross-compiled to the Web.

Given this context, how do you think about considing building Java to
WebAssembly compiler?

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/f9c423c0-bda2-4018-b7e1-9f56f3a34d73%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/f9c423c0-bda2-4018-b7e1-9f56f3a34d73%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMx%3D6Rr-rBdt%3Dym2uf9t-ouP9v-KvJxdErm94XNudbwbyw%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMx%3D6Rr-rBdt%3Dym2uf9t-ouP9v-KvJxdErm94XNudbwbyw%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_pVm7GrH_pwqV3zcKK%2BPV0mAaXPLzcTuDT4U5ui-NG0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT Meet-up 2015 Videos

2015-06-12 Thread 'John Stalcup' via GWT Contributors

Done

On Wed, Jun 10, 2015 at 10:39 PM Bhaskar Janakiraman 
bjanakira...@google.com wrote:

 For those who missed the G+ post, the talks at the Meet-up are now on the
 GWT YouTube channel, enjoy!

 https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

 Bhaskar

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/14d96ada-f554-45c2-8d32-7a81e3841864%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/14d96ada-f554-45c2-8d32-7a81e3841864%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8%3DzHfNYBv1PV_bQw66jq8B95bi%3DGjSF7Fhx7fy%2B_W0VQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.8 SnapShot Unexpected internal compiler error in SDM after switching to GSS

2015-02-02 Thread 'John Stalcup' via GWT Contributors

If you can provide a small sample that reproduces the problem I will take a
look.

On Fri Jan 30 2015 at 3:09:32 PM confile michael.gorsk...@googlemail.com
wrote:

 I use GWT 2.8 SnapShot with an app that runs with CSS only no GSS. Then I
 switched to GSS using:

 set-configuration-property name=CssResource.enableGss value=true /

  set-configuration-property name=CssResource.legacy value=true /

 set-configuration-property name=CssResource.conversionMode value=
 lenient /


 When I compile with option -strict there are no errors. When I run my
 server in SDM and try to connect I get the following errors:


  Compiling 1 permutation

 Compiling permutation 0...

 [ERROR] Unexpected internal compiler error

 java.lang.NullPointerException

 at com.google.gwt.dev.jjs.ast.HasName$1.compare(HasName.java:33)

 at com.google.gwt.dev.jjs.ast.HasName$1.compare(HasName.java:30)

 at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)

 at java.util.TimSort.sort(TimSort.java:189)

 at java.util.TimSort.sort(TimSort.java:173)

 at java.util.Arrays.sort(Arrays.java:659)

 at java.util.Collections.sort(Collections.java:217)

 at
 com.google.gwt.dev.jjs.ast.JTypeOracle.getCastableDestinationTypes(JTypeOracle.java:1019)

 at
 com.google.gwt.dev.jjs.impl.ComputeExhaustiveCastabilityInformation.createCompleteCastMap(ComputeExhaustiveCastabilityInformation.java:44)

 at
 com.google.gwt.dev.jjs.impl.ComputeExhaustiveCastabilityInformation.execImpl(ComputeExhaustiveCastabilityInformation.java:50)

 at
 com.google.gwt.dev.jjs.impl.ComputeExhaustiveCastabilityInformation.exec(ComputeExhaustiveCastabilityInformation.java:32)

 at
 com.google.gwt.dev.jjs.MonolithicJavaToJavaScriptCompiler$MonolithicPermutationCompiler.normalizeSemantics(MonolithicJavaToJavaScriptCompiler.java:102)

 at
 com.google.gwt.dev.jjs.JavaToJavaScriptCompiler$PermutationCompiler.compilePermutation(JavaToJavaScriptCompiler.java:286)

 at
 com.google.gwt.dev.jjs.MonolithicJavaToJavaScriptCompiler.compilePermutation(MonolithicJavaToJavaScriptCompiler.java:292)

 at
 com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:130)

 at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:197)

 at
 com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)

 at
 com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74)

 at java.lang.Thread.run(Thread.java:745)

 [ERROR] Unrecoverable exception, shutting down

 com.google.gwt.core.ext.UnableToCompleteException: (see previous log
 entries)

 at
 com.google.gwt.dev.javac.CompilationProblemReporter.logAndTranslateException(CompilationProblemReporter.java:112)

 at
 com.google.gwt.dev.jjs.JavaToJavaScriptCompiler$PermutationCompiler.compilePermutation(JavaToJavaScriptCompiler.java:363)

 at
 com.google.gwt.dev.jjs.MonolithicJavaToJavaScriptCompiler.compilePermutation(MonolithicJavaToJavaScriptCompiler.java:292)

 at
 com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:130)

 at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:197)

 at
 com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)

 at
 com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74)

 at java.lang.Thread.run(Thread.java:745)

 [ERROR] Not all permutation were compiled , completed (0/1)

   [WARN] recompile failed

   [WARN] continuing to serve previous version


  --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/d6fc2554-5359-4e95-aa44-2caf3cb13614%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/d6fc2554-5359-4e95-aa44-2caf3cb13614%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9YmGsxxAugGkdFmhpKb4DXKD%3Dba7CJDxAkciKJ-yxB8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] *.nocache.js file with old lastmodified date

2014-12-02 Thread 'John Stalcup' via GWT Contributors

addressing this at https://gwt-review.googlesource.com/#/c/10520/

On Tue Dec 02 2014 at 8:11:59 AM christiankempe...@gmail.com wrote:

Hello,

compiling a GWT module causes the last-modified date of the *.nocache.js
file is set to the last-modified date of the *.gwt.xml file.
If using eclipse with tomcat you are running in problems. All files -
except the nocache.js - are copied to tomcat working directory. The
nocache.hs file is not copied, because its last-modified timestamp is not
updated.
Problem exists in GWT 2.7.0 running on OSX 10.10. Current workaround is to
overwrite the emitSelectionScript in a custom linker:

@Override
protected EmittedArtifact emitSelectionScript(TreeLogger logger,
LinkerContext context, ArtifactSet artifacts) throws
UnableToCompleteException {
String ss = generateSelectionScript(logger, context, artifacts);
return emitString(logger, ss, context.getModuleName() + .nocache.js);
}

Because this was working in GWT 2.6.0 we think it is a bug in GWT 2.7.0.

Thanks

Christian

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5f62e34b-6260-45b9-8ced-f9e1897cf353%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5f62e34b-6260-45b9-8ced-f9e1897cf353%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_25wizEHMZ6cutgbY5xn2m9G6jEr7j_fXO%3DaEgmA4CNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] 2 new libraries

2014-12-01 Thread 'John Stalcup' via GWT Contributors

The SDM + testing framework combination sounds neat. I imagine it should
make it a lot faster to rerun tests.

On Thu Nov 27 2014 at 1:57:29 PM Tal Shani tsh...@gmail.com wrote:

Hi all,

I have created two new libraries for GWT.
The first is a jasmine wrapper so testing can be done on the browser with
simple refresh with the new SDM
you can find it here: https://github.com/gwt-noo/jasmine-wrapper

The second is a promise library that is cross platform and uses native
promises if exists. It also adds setImmediate as a side effect.
you can find it here: https://github.com/gwt-noo/promise

not much is documented and i hope to improve that. but they really don't
have alot in them.
notes and suggestions are welcome.

Tal.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/24136d26-ecfa-4724-a950-4a18ac63eb95%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/24136d26-ecfa-4724-a950-4a18ac63eb95%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8E%3DoAjYkGM6fMu5ESunyhxes%3DNf9DYHD%3DXxwfW2_WCUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: two errors in master

2014-12-01 Thread 'John Stalcup' via GWT Contributors

Glad you like the cache reuse speedup!

Also thanks for pointing out the CME, a fix for it is in review at
https://gwt-review.googlesource.com/#/c/10500/
On Mon Dec 01 2014 at 2:27:20 AM Stephen Haberman
stephen.haber...@gmail.com wrote:

Okay, okay, sorry for all the emails, but I ditched sourceLevel 1.8 and am
now just playing with the new cached-SDM...

Wow. It's awesome. Great work!

I was hesitant to move our app over to 2.7.0, but this, this is nice.

- Stephen

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5cfcf422-c969-4a00-8351-fbe34c648958%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5cfcf422-c969-4a00-8351-fbe34c648958%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9pmDTvdV9bhdxOptD4qtBOue_qxQmZxbUwYdCTzjYcOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM + gin + generated GinModule not working well together

2014-11-20 Thread 'John Stalcup' via GWT Contributors

Though we do not make a promise to process GWT.create() of entry point
types before any other GWT.create() calls, it was easy to restore this
behavior in incremental, so I went ahead and did it (
https://gwt-review.googlesource.com/#/c/10410/).

You should probably find a way not to depend on this in the future, as it
is not promised and may change again.


On Mon Nov 17 2014 at 2:07:02 PM Christopher Viel 
viel.christop...@gmail.com wrote:

 Hi,

 I'm gonna add some more background here.

 The generator generates a bunch of file and binds the interfaces using
 GIN. I would't say this is strictly necessary, but it brings the advantages
 of DI to the generated code. So we have an Entry Point that is an interface
 and a rebind rule. UserAgentAsserter uses a similar technique. What we also
 do is generate a Ginjector interface and put a
 *GWT.create(GeneratedGinjector.class)* call inside the generated entry
 point. That way GIN's generator is called after and everything should be
 resolvable. The generated ginjector is setup to look at a specific property
 to load additional gin modules. Here it happens  that one of them is also
 generated. So all of that actually work with 2.7.

 What no longer works is if the entry point and the ginjector are no longer
 generated. If there is a GWT.create() call that resolves to a Ginjector
 from an explicit entry point, it fails. I'm not sure I'm being very clear
 here so here's an example:

 *MyModule.gwt.xml:*
 module
 entry-point class=com.project.EntryPointToGenerate/
 entry-point class=com.project.ExplicitEntryPoint/

 extend-configuration-property name=gin.ginjector.modules
 value=com.project.GeneratedGinModule/

 generate-with class=com.project.EntryPointGenerator
 when-type-is class=com.project.EntryPointToGenerate/
 /generate-with
 /module

 *EntryPointToGenerate:*
 public interface EntryPointToGenerate extends EntryPoint {}

 *EntryPointGenerator*: Generates *com.project.GeneratedGinModule* and an
 implementation of *EntryPointToGenerate*

 *ExplicitEntryPoint*:
 public class ExplicitEntryPoint implements EntryPoint {
 private static final ExplicitGinjector GINJECTOR = GWT.create(
 ExplicitGinjector.class);

 @Override
 public void onModuleLoad() {}
 }

 *ExplicitGinjector:*
 @GinModules( value = ExplicitGinModule.class, properties =
 gin.ginjector.modules )
 public interface ExplicitGinjector extends Ginjector {
 /* snip */
 }

 With this code in a regular compilation, EntryPointToGenerate is generated
 before ExplicitEntryPoint is traversed. With incremental compilation,
 ExplicitEntryPoint is traversed (and incidentally GINs generator is called)
 before EntryPointGenerator is called. I would expect the first entry point
 to be traversed at first, even if it means calling a generator.

 On Sunday, November 16, 2014 3:56:20 PM UTC-5, Nicolas Morel wrote:

 Hi,

 I'm currently testing GWT 2.7.0-rc1 and one of my project using GWTP
 Rest-Dispatch https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch is
 not working under SDM.
 The compilation fails with this error :

   [ERROR] Unable to load gin module type
 [com.gwtplatform.dispatch.rest.client.RestGinModule], maybe you haven't
 compiled your client java sources?
 java.lang.ClassNotFoundException: com$gwtplatform$dispatch$rest$
 client$RestGinModule
 at com.google.gwt.inject.rebind.GinBridgeClassLoader.findClass(
 GinBridgeClassLoader.java:150)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
 at com.google.gwt.inject.rebind.GinBridgeClassLoader.loadClass(
 GinBridgeClassLoader.java:108)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:340)
 at com.google.gwt.inject.rebind.GinjectorGenerator.loadClass(
 GinjectorGenerator.java:223)
 at com.google.gwt.inject.rebind.GinjectorGenerator.
 getPropertyModuleClasses(GinjectorGenerator.java:137)
 at com.google.gwt.inject.rebind.GinjectorGenerator.getModuleClasses(
 GinjectorGenerator.java:116)
 at com.google.gwt.inject.rebind.GinjectorGenerator.generate(
 GinjectorGenerator.java:72)
 at com.google.gwt.core.ext.IncrementalGenerator.generateNonIncrementally(
 IncrementalGenerator.java:40)

 The full stack trace is available in attachment.

 The problem has been reported to the GWTP team here
 https://github.com/ArcBees/GWTP/issues/614. The normal compilation
 works but not the incremental compile from SDM.

 I made a simple example available here
 https://github.com/nmorel/hello-gwt-rest-dispatch.

 From what I saw, the RestGinModule that gin is trying to load is
 generated by a GWT generator (VelocityGenerator
 https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-dispatch-rest/src/main/java/com/gwtplatform/dispatch/rest/rebind/VelocityGenerator.java
 .generateRestGinModule()) and passed to gin through the property
  gin.ginjector.modules.
 It seems unconventional but was working before.
 Any ideas

[gwt-contrib] Re: 2.7.0 RC1 SDM not working when using java.util.List - Example attached

2014-11-17 Thread 'John Stalcup' via GWT Contributors

A fix for this is now committed. Which means this code snippet will now
be rejected all the time.

To accomplish the same thing you need to execute the .size() function
dispatch (or really any function dispatch on a List instance since you've
used the List interface on a JSO type) inside of a *Java* not inside of a
JSNI function. This is relatively straight forward if you make a static
Java function that takes a List instance and calls size() on it, and you
can call this static Java function inside of your JSNI.


On Wed Nov 12 2014 at 4:05:26 PM John Stalcup stal...@google.com wrote:

 It's more like, 50% of the time.

 Here's what's going on:

 It's currently illegal to call foo.blah() in JSNI if the variable foo is
 either a JSO type or interface that is implemented by some JSO type.

 The error you're seeing is JsniReferenceResolver enforcing this
 requirement, the weird part is that it should enforce it all the time but
 it's only enforcing it 50% of the time.

 The reason this is occurring is that depending on the order that JDT
 processes types we may or may not yet have collected the knowledge to know
 that the java.util.List interface is used on a JSO before
 JsniReferenceResolver performns its check.

 We need to move the correctness check to some later stage, late enough
 that is JSO checks will always be accurate.

 In the 50% of compiles that are succeeding for you right now you're
 actually vulnerable to runtime errors because it's outputting code that
 attempts to call the size() function on the prototype of the list
 parameter (and that will fail if the instance that is passed in happens to
 be a JsArrayListWrapper).


 On Wed Nov 12 2014 at 1:27:42 PM John Stalcup stal...@google.com wrote:

 I'm able to repro this both with -noincremental and -incremental, but
 only randomly (seems about 30% of the time).

 Still looking into it.
 On Wed Nov 12 2014 at 8:24:43 AM Thomas Broyer t.bro...@gmail.com
 wrote:

 [+cc stalcup@]

 This might be because of incremental compilation: when
 JsArrayListWrapper is in another module, that module is precompiled, so
 the compiler knows about the type. When it's in the same module, because
 it's the module being compiled, it can be pruned (unused) and as
 consequence doesn't interfere with the JSNI checks.

 The workaround would be to call a static method passing the List as
 argument, and call the size() method in that static method, in Java-land,
 outside of JSNI.


 On Wednesday, November 12, 2014 1:39:55 PM UTC+1, Jan Thewes wrote:

 Hello guys,

 we're currently running in problems related to the SDM in GWT 2.7.
 We've attached two examples.
 JsListWrapperWorking is an example project where everything is working
 fine. It is CODE IDENTICAL to JsListWrapperNotWorking.
 In the latter one we've moved the source for the two classes
 JsArrayListWrapper and JsArrayWrapper to another module.
 No source code has been touched.

 When starting SDM for JsListWrapperWorking everything is working fine.
 When starting SDM for JsListWrapperNotWorking we get following
 exception:

 [ERROR] Errors in 'file:~/JsListWrapperNotWorking/src/
 de/gad/list/client/JsListWrapperNotWorking.java'

 [ERROR] Line 19: Referencing interface method 'java.util.List.size()':
 implemented by 'de.gad.list.client.myListImpl.JsArrayListWrapper';
 references to instance methods in overlay types are illegal; use a stronger
 type or a Java trampoline method


 If you need any further information I'll provide them as soon as
 possible!


 Cheers,

 Jan



-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ91Eqd-Ovxcy9EUADsm-BStJO9hkNvKd1t_oMyBTrHv2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] stylesheet ignored/not handled in SDM 2.7.0-rc1

2014-11-05 Thread 'John Stalcup' via GWT Contributors

Are you getting that error in SuperDevMode before or after the first
compile?

If before then it probably means that the existing initial public
resources copying code is not picking up things that are only referenced
via stylesheet tag but if the error is after the first compile then it
probably has something to do with your GWT linker selection.

On Wed Nov 05 2014 at 12:06:28 AM Christian X
christian.phil...@it-informatik.de wrote:

Hello,
I wanted to test the new SDM in 2.7.0-rc1.
A stylesheet that I reference im my model file is not loaded, in console I
get the output:

[INFO] GET /overwrite.css
[INFO][WARN] ignored get request: /overwrite.css
[INFO][WARN] not handled: /overwrite.css

With gwt 2.6.1 I could use normal dev mode and everything was fine. If I
use GWT 2.7.0-rc1 and compile my application to a war file it also works
fine. Without this stylesheet I can't use devmode because everything looks
to different from the compiled war file.

I use tomcat to deploy the war file and I have noServertrue/noServer
set im my pom.xml, see configuration below.

I start devmode with:
mvn gwt:run

I use gwtbootstrap and in my overwrite.css I have a few css rules
(corporate identity) to overwrite the gwtbootstrap css.

from my model file GUI.gwt.xml:

!-- Bootstrap --
inherits name='com.github.gwtbootstrap.Bootstrap'/
inherits name='com.github.gwtbootstrap.datepicker.Datepicker'/
inherits name='com.github.gwtbootstrap.datetimepicker.Datetimepicker'
/
set-property name=bootstrap.responsiveDesign value=true/

!-- overwrite Bootstrap --
stylesheet src=../fp-overwrite-global.css/

the overwrite.css is placed in GUI/src/main/webapp this is the same
folder where my GUI.html file is.

configuration from my pom.xml:
...
properties
webappDirectory${project.build.directory}/${project.
build.finalName}/webappDirectory
/properties
...

!-- GWT Maven Plugin --
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdgwt-maven-plugin/artifactId
version${gwtVersion}/version
executions
execution
goals
goalcompile/goal
goali18n/goal
/goals
/execution
/executions
configuration
hostedWebapp${webappDirectory}/hostedWebapp
runTargetGUI/GUI.html/runTarget
noServertrue/noServer
port8080/port
debugPort8008/debugPort
localWorkers8/localWorkers

i18nMessagesBundlede.company.department.project.
client.util.i18n.Translation/i18nMessagesBundle

extraJvmArgs
-Xmx1024M -XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC -XX:MaxPermSize=256M
/extraJvmArgs

disableClassMetadatatrue/disableClassMetadata
disableCastCheckingtrue/disableCastChecking

closureCompilertrue/closureCompiler
draftCompilefalse/draftCompile
optimizationLevel9/optimizationLevel
/configuration
/plugin

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/5a9a8e23-1d82-
427b-bd09-0de2d044a1ee%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5a9a8e23-1d82-427b-bd09-0de2d044a1ee%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-FDnXBkxXni83nkFJ75sFib%2BMFO4b%2BiQH%2BrDrC%3DTwh0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] super dev mode not working

2014-11-05 Thread 'John Stalcup' via GWT Contributors

This is with GWT 2.6.1?

SuperDevMode will only find changes in .java files that are in a directory
that has been supplied to the JVM launch as part of the classpath or is
specifically added using a -src parameter.

From what you say it sounds like something about your project setup is
leading to SuperDevMode being able to see your project source (so it can
compile) but is seeing it in a location that is different than the .java
files that you're editing. Is it possible that your maven project setup is
somehow packaging your source code into jar files and SuperDevMode is only
seeing and compiling that version of the source files?

On Tue Nov 04 2014 at 10:48:18 PM KARAN DANI karandani@gmail.com
wrote:

i followed below steps to start super dev mode in my project
my project name is phoenix and it has total 14 moduls

modules
modulephoenix-main/module
modulephoenix-core/module
modulephoenix-common/module
modulephoenix-ocean/module
!-- modulephoenix-air/module --
modulephoenix-admin/module
!-- modulephoenix-hr/module
modulephoenix-account-finance/module --
modulephoenix-framework/module
modulephoenix-reports/module
!-- modulephoenix-global/module
modulephoenix-accurate/module
modulephoenix-search/module
modulephoenix-appstore/module --
/modules
1. first in change my main pom.xml.
2. then i change my phoenix-main pom.xml and Application.gwt.xml
3. i start my project in super dev mode it is compiled successfully but
when i do changes in my code and recompile my project the changes in not
affected

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/620809b0-dce7-4ab6-b8fe-b332568704ed%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/620809b0-dce7-4ab6-b8fe-b332568704ed%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9Kvbt6ah019n6J6aaLFgo4ui6bmUs_PV4T%3DVPhrn3AWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.7 SDM incremental output too large

2014-10-22 Thread 'John Stalcup' via GWT Contributors

We're planning to do some work (link time pruning) to reduce incremental
output size some time before the end of the year.

On Wed, Oct 22, 2014 at 9:33 AM, Rene Hangstrup Møller rhmol...@gmail.com
wrote:

Good point. When I tried remote js debugging with sourcemaps from intellij
I thought about the irony og the setup.

You have the source in your IDE. Then you push the source and mappings to
the compiled output into the browser, and then you remote control the
debugger from the IDE.

It would be awesome if I could just have the browser run the compiled and
minimized code, and my IDE could do the mapping between original source and
compiled output.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/e718fd83-c3c7-49b5-8fe3-294622047266%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9u87g%3D6RNSEBPtazo3F0WUhWEiZnJ7ix7x%3DjG0jyw%3D6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

2014-10-21 Thread 'John Stalcup' via GWT Contributors

Ah, thanks for getting to the bottom of it. I agree that we should opt to
use more RAM rather than have randomly slower compiles. And it would be
nice to cherry pick the change into the release branch.

On Mon, Oct 20, 2014, 9:39 PM Stephen Haberman stephen.haber...@gmail.com
wrote:

Well, this is somewhat anti-climatic, but, AFAICT, it was just
MemoryUnitCache's maps using soft values.

Instead of turning on TRACE everywhere, I upgraded
MinimalRebuildCache's known modified type output to WARN. (It would
be great to have log4j-style package-level knobs in the GWT log
output.) That was always right (only 1 .java file with it's 3 inner
types).

After trying a few other things, I also upgraded
CompilationStateBuilder's doBuildFrom, where it reads from the unit
cache, Used x/y units from cache line.

And that's it; whenever I have a slow load, I'm loading only ~3k out of
~4k units from cache. Or less (I saw zero once, after I had
particularly annoyed the GC somehow). Whenever it's fast, all ~4k
(minus the newly invalidated one) are loaded from the unit cache.

I removed MemoryUnitCache's maps' .softValues() and that seems to fix
it. Upping the Xmx from 1g to 2g also fixes it, and provides a nice
speed up anyway.

Perhaps 1g was a naively low setting, but, AFAICT, without poking in
the code (or turning on TRACE and knowing exactly what to look for),
there are no visible hints about hey, the cache isn't keeping up,
that's why your reloads are slow, so up your Xmx.

Given how important the unit cache is now, perhaps the maps should no
longer use soft values? In my case, I would have preferred an OOME as
an blatant needs more RAM than silent sub-optimal behavior.

- Stephen

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_tqOMHrG7Jon6521UZquTkQyexbH%3DzerjJmnKmsOequQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7 : precompile and incremental flags

2014-10-21 Thread 'John Stalcup' via GWT Contributors

I think this is a reasonable change to make since it's simple to implement
and a noticeable improvement for SVN users. I'll go ahead and get it in and
we can cherry pick it into this release.

On Tue Oct 21 2014 at 5:58:00 AM Juan Pablo Gardella
gardellajuanpa...@gmail.com wrote:

Thanks for sharing Jérémie. Good to know.

On 21 October 2014 09:32, Jérémie Gottero jeremiegott...@gmail.com
wrote:

Do we have an easy way to exclude these folders to see if it improves
things?

Quick and dirty: I overrode the descendToFindResources method to exclude
.svn files (note that the file is excluded before isDirectory/isFile calls,
avoiding an extra i/o):

File[] children = dir.listFiles();
for (File child : children) {
if (child.getName().equals(.svn)) // hardcoded filter here
continue;
String childPath = dirPath + child.getName();
if (child.isDirectory()) {

Reload time goes down from 2,8s to 1,1sec. The ability to filter files
here could lead to interesting speed improvements.

Another possible improvement: I got 4874 calls to file.lastModified() in
a single browser refresh, for 2088 unique files. Caching the result per run
could avoid 50% i/o and reload time would go below 1s. I have no idea if
it's realistic/easy to do though, I havent dug in the code ;)

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/b052327f-8538-4598-b4fb-740cd16d2deb%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/b052327f-8538-4598-b4fb-740cd16d2deb%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFse_4M3ZqrOa2D%2BdQfVhmWvxXABFH7F7y-KkNXKu5HLxcA%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFse_4M3ZqrOa2D%2BdQfVhmWvxXABFH7F7y-KkNXKu5HLxcA%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9neWoGRV-ZRwWBSn-8aMo4WnabdK73ooL%2B0o_kXTpuPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7 : precompile and incremental flags

2014-10-21 Thread 'John Stalcup' via GWT Contributors

change in review at https://gwt-review.googlesource.com/#/c/9850/

On Tue Oct 21 2014 at 3:43:47 PM Stephen Haberman 
stephen.haber...@gmail.com wrote:


if (child.getName().equals(.svn)) // hardcoded filter here

 Just curious, but didn't svn change (maybe a year ago or so?) to only
 using one top-level .svn folder, similar to Git's top-level .git
 folder, and not having .svn littered throughout the file system?

 - Stephen

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/google-web-toolkit-contributors/20141021174343.46a191a4%40sh9.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-X0ToVXkXW0JivN-VCAYwzzz%3DZKomGnf-%2Bdny7DVGnAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

2014-10-20 Thread 'John Stalcup' via GWT Contributors

I think it's in master now (commit 14f27064497f1171907d0ecbe01a4d2991a7a855)

On Sun, Oct 19, 2014 at 7:51 PM, Stephen Haberman 
stephen.haber...@gmail.com wrote:


  depends on how many files are modified [+ invalidations]

 Yeah, sorry, I should have mentioned I've only been changing one file,
 just adding/removing a character in a string.

  John detected that behavior in the persistent unit cache and has a
  fix for it.

 Great! I'll try it out when it hits master.

 - Stephen

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/20141019215142.6e6e53f1%40sh9
 .
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-j4KGj%3DG-sSda%2Bei9M3X%2BDx4%2BzZGW2joogbjoRkSe-Sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Starting super dev mode in debug : performance very bad

2014-10-02 Thread 'John Stalcup' via GWT Contributors

Hey

I don't think there's anything special we're doing that would be
particularly slow in a JVM debugger.

Maybe this is a stupid question but, do you have any conditional
breakpoints set? Those can be particularly slow. Also maybe the debug
process costs extra RAM, putting the JVM at it's RAM limit, then causing a
lot of really slow GCs? You could try raising the RAM.

On Thu, Oct 2, 2014 at 12:37 PM, Julien Dramaix julien.dram...@gmail.com
wrote:

Hi,

I've tried to run the super dev mode (dev mode with flag -superDevMode) in
debug in order to debug my server side code. The problem is that the
superdevmode server is also started in debug mode and the time needed for
the initial compilation is very very bad. This is an example of time needed
by the first compilation with a small application:

Linking per-type JS with 3891 new types.
prelink JS size = 8177175
prelink sourcemap = 8177175 bytes and 194766 lines
postlink JS size = 8054573
postlink sourcemap = 8054573 bytes and 191812 lines
Source Maps Enabled
Compile of permutations succeeded
Compilation succeeded -- 418,016s
Linking into
/var/folders/qc/ktqtdtdx6790j436xz3jqw3rgn/T/gwt-codeserver-5506406643949710211.tmp/com.caerus.kaam.KaamSdm/compile-3/war/kaam;
Writing extras to
/var/folders/qc/ktqtdtdx6790j436xz3jqw3rgn/T/gwt-codeserver-5506406643949710211.tmp/com.caerus.kaam.KaamSdm/compile-3/extras/kaam
Link succeeded
Linking succeeded -- 10,692s
430,813s total -- Compile completed

If you don't change anything to the code and recompilation of the
application takes 2,147s.

For your info, the same application running not in debug mode takes 20s
for the initial compilation.

That makes simply the debug mode impossible to use and you are not able to
debug your server side code anymore. The workaround is to run two separate
processes, one with -superDevMode and --nostartServer flags and another
without the -superDevMode flag that you can start in debug mode.

I don't know if we can do something on the superdevmode side, maybe the
solution can come from the IDE directly where the superdevmode process is
never launched in debug mode ?

Any thought ?

Julien

PS: I'm using Intellij13

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7DgGmkkQVe3mQgXxT%2B7rjbM%2BMOCv7TVjRPa08h%3DDPiEw%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7DgGmkkQVe3mQgXxT%2B7rjbM%2BMOCv7TVjRPa08h%3DDPiEw%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8tiSVZPm5XV08TPK%3Dm6v6cKxdFeLZ0QUZ_iYHPGTZcBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.7 release plan

2014-10-02 Thread 'John Stalcup' via GWT Contributors

-XjsInteropMode JS

On Thu, Oct 2, 2014 at 2:46 PM, confile michael.gorsk...@googlemail.com
wrote:

How can JsInterop be activated in GWT 2.7? What flag does it?

Am Donnerstag, 2. Oktober 2014 03:22:56 UTC+2 schrieb Brian Slesinsky:

It's experimental and hidden behind a flag, but it's there.

On Wed, Oct 1, 2014 at 6:20 PM, Cristian Rinaldi csri...@gmail.com
wrote:

- JsInterop Preview is part of the release?

El miércoles, 1 de octubre de 2014 16:15:26 UTC-3, Daniel Kurka escribió:

Hi all,

we just settled on a GWT 2.7 release plan:

- We *code freeze* on *October 7th* and branch for GWT 2.7.
- As soon as we have the *remaining patches submitted*, we put out a
beta1 build, this should be no later than *October 7th.*
- Putting out a *beta1 externally* allows us to collect feedback on
the new super dev mode integration externally as well.
- We are going to *flip incremental to default* tomorrow and *wait
for 1-2 weeks* for google internal feedback, if there is no serious
issues we are going to *put out RC1*
- GWT 2.7 will still be compatible with Java 6.

Patches / Fixes that need to go in:
- Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/ (
dankurka)
- Sending the wrong permutation to the client in SDM, if no files have
changed (dankurka).
- Investigate why some people are seeing errors with incremental not
restricting to one permutation (dankurka).
- Public directories are not copied o the war directory when using SDM
(skybrian).
- Restore Java 6 compatibility (skybrian).
- Document limitations of JsonUtils.safeEval and discourage usage
(goktug) (promote Json.parse)

Patches that are nice to have:
- Improve exception logging in SDM (goktug).

*If you have any outstanding patches that you thing need to go into GWT
2.7, please bring them to our attention, by replying to this thread or
adding me as a reviewer on Gerrit and setting the topic to GWT2.7.*

-Daniel

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/1d5a4369-e03d-
47ba-b8dd-5031e5460751%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/1d5a4369-e03d-47ba-b8dd-5031e5460751%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/48e8f729-b645-4534-af9d-c5a9947dffd2%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/48e8f729-b645-4534-af9d-c5a9947dffd2%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_CC8ZdaEMie2QTvqRkKT0T-e0K%2BqzN%2BGyUx6jt2kJCVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: JsInterop

2014-10-01 Thread 'John Stalcup' via GWT Contributors

Make sure turn turn on -XjsInteropMode JS

On Tue, Sep 30, 2014 at 9:18 AM, 'Chris DiGiano' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:

Have you enabled jsInterop mode via the compiler flag? It looks like this
on the command line:
-XjsInteropMode JS

Chris

On Tue Sep 30 2014 at 7:05:23 AM Michael Vogt mich...@michaelvogt.eu
wrote:

Btw, when calling parse() out of jsni or in the browser console, it works
fine. So the Javascript side is ok.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/443bbcf0-bc50-4c3e-aacb-bc38c6c1c85d%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/443bbcf0-bc50-4c3e-aacb-bc38c6c1c85d%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAHbZCdNdV4jAcSmssxiJQL%2BxgH1oenQqUbgbzL4d0Ba%2BJm7mzg%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAHbZCdNdV4jAcSmssxiJQL%2BxgH1oenQqUbgbzL4d0Ba%2BJm7mzg%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_PjHJ0K89e%2B6Li1dL21TubXRoG%2B9aA-H4d5YWMcWjcEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

2014-10-01 Thread 'John Stalcup' via GWT Contributors

We have a short list of issues that have to be addressed before 2.7 RC, and
this is on the list.

On Wed, Oct 1, 2014 at 1:13 AM, Julien Dramaix julien.dram...@gmail.com
wrote:

I confirm, I just add GXT to one of my test project and I'm not able to
use sdm anymore:
[ERROR] Current binding properties are expanding to more than one
permutation but per-file compilation requires that each compile operate on
only one permutation.

On Wed, Oct 1, 2014 at 2:34 AM, Colin Alworth niloc...@gmail.com wrote:

The 'test runner' in this case is just the name of a regular module file,
which happens to be used for running lots of tests, most of which look like
EntryPoints. Nothing too magic going on here, and I've gotten this error by
running modules for more 'normal' gwt apps as well, typically when I stop
SDM, restart it, and then refresh the browser or click Compile without
first using the SDM off bookmarklet.

I'm not completely aware of your configuration but... it appears that
you're using incremental compiles from a test runner, and this test runner
isn't restricting the permutations to just 1. And that is being caught by
an assertion.

You can fix this by adding some set-property tags to your test
.gwt.xml files.

I hadn't thought of this use case, so I'm not sure if it's fair to tell
people to restrict their permutation or if we need to find a better way.
Thoughts?

Does this mean that we expect all projects to already be confined to one
permutation, either via set-property or collapse-all-permutations? Is there
no way to achieve that synthetically?

Further, does this mean that one cannot test in multiple browsers
simultaneously, for example re-compiling in FF until some behavior is
satisfactory, then moving to Chrome (at least without stopping and
restarting SDM)?

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/cdf99604-44c9-41b5-9cca-4f45227a3c89%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/cdf99604-44c9-41b5-9cca-4f45227a3c89%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6fovE52iouAswSHFpQ8dp1sLZYDTUmqBD--bhtvC0akg%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6fovE52iouAswSHFpQ8dp1sLZYDTUmqBD--bhtvC0akg%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8iBDL7p9FObj2F0ax0N9bQ15iSdi2cY4_WOKOKyO%2BKSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

2014-09-30 Thread 'John Stalcup' via GWT Contributors

I can explain what's going here I think.

Incremental compile is made possible by storing and reusing data in a new
object called a MinimalRebuildCache. Since some of the analysis that
incremental compilation is much simpler when there is only one permutation
being compiled and since the contents of a MinimalRebuildCache instance are
specific to a single permutation we decided to put in a requirement that
when compiling incrementally the compiler be invoked with a binding
property set that restricts permutations to just 1.

To make sure this worked out fine for everyone we also turn on the
-noPrecompile option so that all compiles are triggered from the browser,
which ensures that the binding property set is specific to a single
permutation.

You can fix this by adding some set-property tags to your test .gwt.xml
files.

I hadn't thought of this use case, so I'm not sure if it's fair to tell
people to restrict their permutation or if we need to find a better way.
Thoughts?

John

On Tue, Sep 30, 2014 at 11:31 AM, Brandon Donnelson branflake2...@gmail.com
wrote:

I'm not sure whats going on yet, but I've got some recompile issue coming
up when trying to start dev mode. (This isn't using in browser recompile
button)

After moving to Java 1.7 because of a Java 1.6 error I got stuck with this
error. Not sure whats going on yet, but I thought I'd post it for those who
are interested. I've heard turning on and off dev mode fixes it. I'll test
more later.

Runing CodeServer with parameters: [-noprecompile, -port, 9876,
-sourceLevel, 1.7, -bindAddress, 127.0.0.1, -logLevel, INFO,
com.sencha.gxt.test.TestRunner]
Super Dev Mode starting up
workDir:
/var/folders/x8/9wz7qtw96t7grkdyjw1l61p4gn/T/gwt-codeserver-362446698832754749.tmp
Loading Java files in com.sencha.gxt.test.TestRunner.
Ignored 90 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
errors.
To compile the module 'testrunner' , visit:
http://127.0.0.1:9876/recompile/testrunner?user.agent=safari
Module setup completed in 5256 ms

The code server is ready.
Next, visit: http://127.0.0.1:9876/
GET /recompile/testrunner
Job com.sencha.gxt.test.TestRunner_1_0
starting job: com.sencha.gxt.test.TestRunner_1_0
binding: user.agent=safari
Compiling module com.sencha.gxt.test.TestRunner
[ERROR] Current binding properties are expanding to more than one
permutation but per-file compilation requires that each compile operate on
only one permutation.
[WARN] recompile failed
[WARN] continuing to serve previous version

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/90b99fa9-e7f2-4908-ad36-28b775f24edb%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/90b99fa9-e7f2-4908-ad36-28b775f24edb%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9b%3Dp_H-DfdqmvjkYUOVWTn699hkQPGMejaZmLpsH%3DCzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Change the superDevMode to be the default for dev-mode?

2014-09-30 Thread 'John Stalcup' via GWT Contributors

Yeah I kind of agree.

If DevMode support is removed in Chrome soon after the 2.7 release, we'll
be wishing we'd made DevMode launches default to turning superDevMode on.

On Tue, Sep 30, 2014 at 11:54 AM, 'Goktug Gokdogan' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:

Thinking about it, we should probably make superDevMode opt-out instead of
opt-in and make it work out of the box for existing users instead of asking
them to add the -superDevMode.

So what do you think about making superDevMode the default for dev-mode in
2.7 release?

PS: BTW, if you haven't already, take a look at the Daniel's video here:
https://plus.sandbox.google.com/+DanielKurka/posts/JsVKoQ9nvn5

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2K2J_MBVVcwyFiBT54riyH_Wh_QL1ES0uXHP_YAn7yRg%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2K2J_MBVVcwyFiBT54riyH_Wh_QL1ES0uXHP_YAn7yRg%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8r9YCmzk_C9QaEFtDrVn%2BPmKnRgVGcenuWd57pitUV4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Change the superDevMode to be the default for dev-mode?

2014-09-30 Thread 'John Stalcup' via GWT Contributors

Goktug mentioned that he thinks the option should be on be default in GWT,
which would mean no change necessary in GPE. And I agree.

On Tue, Sep 30, 2014 at 4:21 PM, Brandon Donnelson branflake2...@gmail.com
wrote:

Should I make this default behavior in GPE? On by default?

On Tuesday, September 30, 2014 3:40:15 PM UTC-7, Thomas Broyer wrote:

Fwiw, we made it the default in the gwt-maven-plugin.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/bf5eda80-7c71-4daa-9e84-98521c108b69%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/bf5eda80-7c71-4daa-9e84-98521c108b69%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-Yf_EPi%3Dv%2BRk0y7O2jW4nt_97gQYi8q2Yixyn511Bo0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Change the superDevMode to be the default for dev-mode?

2014-09-30 Thread 'John Stalcup' via GWT Contributors

Brandon and I talked a bit about if offline and just the summarize:

If we want to accomplish making SuperDevMode on as the default behavior in
the DevMode launcher in GPE it is going to require some changes in
Brandon's work regardless of whether we do it via updating the default
value of the flag in GWT (because he'll need to start adding
-nosuperDevMode when Classic DevMode is selected) or instead update the
default setting of the radio button in the GPE launcher.

So since it's the same amount of work either way, and since updating the
default value of the flag in GWT has the advantage of having an effect for
command line users as well, this option is preferable.

On Tue, Sep 30, 2014 at 4:31 PM, Brandon Donnelson branflake2...@gmail.com
wrote:

Gotcha. Well, I baked in -superDevMode program arg switch, and this is
also backported in an embedded jar. I would have to take into account some
switch to turn back on DevMode. I was hoping to alleviate the pain of
changing the program args by hand.

On Tuesday, September 30, 2014 4:28:18 PM UTC-7, John Stalcup wrote:

Goktug mentioned that he thinks the option should be on be default in
GWT, which would mean no change necessary in GPE. And I agree.

On Tue, Sep 30, 2014 at 4:21 PM, Brandon Donnelson branfl...@gmail.com
wrote:

Should I make this default behavior in GPE? On by default?

On Tuesday, September 30, 2014 3:40:15 PM UTC-7, Thomas Broyer wrote:

Fwiw, we made it the default in the gwt-maven-plugin.

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/bf5eda80-7c71-
4daa-9e84-98521c108b69%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/bf5eda80-7c71-4daa-9e84-98521c108b69%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/cf5783b0-a94a-48b4-a92c-15c85e318e18%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/cf5783b0-a94a-48b4-a92c-15c85e318e18%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9pXqq5xL3CTNb0ESurFPHmT1SKsOnSWEXjNF%3DGAETOoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Vaadin and GWT 2.7 compilePerFile

2014-09-12 Thread 'John Stalcup' via GWT Contributors

Just to close the loop on the conversation, this is fixed in
https://gwt-review.googlesource.com/#/c/9131/

Thanks for the report Artur.

On Wed, Sep 10, 2014 at 9:06 AM, John Stalcup stal...@google.com wrote:

Ah, i didn't see that bug report. Thanks. Taking a look.

On Wed, Sep 10, 2014 at 12:36 AM, Artur Signell ar...@vaadin.com wrote:

Hi,

There is some issue with -XcompilerPerFile and the generators used in
Vaadin. There was a problem with “stale types” previously, but this was
fixed a while back. Today you consistently get a ClassCastException after
the first partial recompilation.

SEVERE: undefinedjava.lang.ClassCastException
at Unknown.Throwable_1_g$(com.vaadin.DefaultWidgetSet-0.js@8:8546)
at Unknown.Exception_1_g$(com.vaadin.DefaultWidgetSet-0.js@18:8704)
at Unknown.RuntimeException_1_g$(com.vaadin.DefaultWidgetSet-0.js@18:8745)
at
Unknown.ClassCastException_1_g$(com.vaadin.DefaultWidgetSet-0.js@25:154772)
at Unknown.dynamicCast_0_g$(com.vaadin.DefaultWidgetSet-0.js@11:600)
at Unknown.createWidget_0_g$(com.vaadin.DefaultWidgetSet-0.js@12:102047)
at Unknown.getWidget_7_g$(com.vaadin.DefaultWidgetSet-0.js@29:102094)

I don’t have any good way of extracting a small test case so I created
https://code.google.com/p/google-web-toolkit/issues/detail?id=8880 already
a while back with instructions on how it can be reproduced using the Vaadin
project.

Would be great to get this sorted out before GWT 2.7 - is there anything
I can do to help getting this forward?

- Artur
--
Artur Signell, CTO
Vaadin.com - +358 40 567 0089 - Skype:artursignell

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CBDB0261-D4A0-470B-8538-089C89F1D598%40vaadin.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CBDB0261-D4A0-470B-8538-089C89F1D598%40vaadin.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-5i3CjufC3p_B5B8zZE2T08G%3DrQueeXAGRCnJ3a2cqDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Vaadin and GWT 2.7 compilePerFile

2014-09-10 Thread 'John Stalcup' via GWT Contributors

Ah, i didn't see that bug report. Thanks. Taking a look.

On Wed, Sep 10, 2014 at 12:36 AM, Artur Signell ar...@vaadin.com wrote:

Hi,

SEVERE: undefinedjava.lang.ClassCastException
at Unknown.Throwable_1_g$(com.vaadin.DefaultWidgetSet-0.js@8:8546)
at Unknown.Exception_1_g$(com.vaadin.DefaultWidgetSet-0.js@18:8704)
at Unknown.RuntimeException_1_g$(com.vaadin.DefaultWidgetSet-0.js@18:8745)
at Unknown.ClassCastException_1_g$(com.vaadin.DefaultWidgetSet-0.js@25:154772)
at Unknown.dynamicCast_0_g$(com.vaadin.DefaultWidgetSet-0.js@11:600)
at Unknown.createWidget_0_g$(com.vaadin.DefaultWidgetSet-0.js@12:102047)
at Unknown.getWidget_7_g$(com.vaadin.DefaultWidgetSet-0.js@29:102094)

Would be great to get this sorted out before GWT 2.7 - is there anything I
can do to help getting this forward?

- Artur
--
Artur Signell, CTO
Vaadin.com - +358 40 567 0089 - Skype:artursignell

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CBDB0261-D4A0-470B-8538-089C89F1D598%40vaadin.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CBDB0261-D4A0-470B-8538-089C89F1D598%40vaadin.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8%2BO5xoG3q6MU6Rdwkf3OdDQAuy4yFiOnivC%2B3qJQ_CJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-09-08 Thread 'John Stalcup' via GWT Contributors

Any new bugs to report?

On Tue, Sep 2, 2014 at 2:07 PM, Arnaud TOURNIER ltea...@gmail.com wrote:

Hi Daniel,

I made some more serious tests on a production project with which i used
to develop using the classic DevMode.
Those are the numbers that come from the CodeServer with or without the
-XcompilePerFile flag, and they are quite impressive :

Standard Compile per file Reduction
1st compile 101s 41s 59%
Change 1 string and recompile 16s 5,8s 64%
Change 1 string and recompile 18s 3,6s 80%

First compile Unification traversed 60072 fields and methods and 6179
types. 6139 are considered part of the current module and 6139 had all of
their fields and methods traversed.
Second compile Unification traversed 2528 fields and methods and 2650
types. 124 are considered part of the current module and 124 had all of
their fields and methods traversed.

I did not use the Chrome dev tools to debug the application but the SDBG
plugin for Eclipse.
The experience is almost incredible, perfectly usable and much faster than
the classic DevMode. The only bad thing is not having the Java fields
inspected correctly (although one can guess the javascript equivalents most
of the time) and little things that can be covered with time... Everything
needs a compromise and having that debugging experience brought back to
Eclipse is really what i was fearing to lose with the SuperDevMode. So i
will adopt the SuperDevMode for a while !
Ray, Brian, John and Robert, Ivan, James and you all made a really
impressive work ! The future of GWT is assured ! Now i can't wait to have
the Java 8 features to be tried ;)

Now i have a question about the message Unification traversed... : first
what means the message exactly (i need to see the code) and second why some
many fields and methods are traversed if only change one file ?

Next i had ideas but no time to implement them, maybe i dump them here
with the hope they can be useful ;)
- Recompile on file change. The time the user switches to the browser, the
compile is almost finished.
- Tool to benchmark.
- Recompile on F5, standard SuperDevMode linker
- GWT plugin for eclipse : GWT tools + SDBG
- Sample including the experience

Thanks a lot again for all the work and the good things coming out !
Arnaud

Le lundi 1 septembre 2014 12:25:38 UTC+2, Daniel Kurka a écrit :

Hi Arnaud,

are those 10s after the changes we made or before?

-Daniel

On Mon, Sep 1, 2014 at 12:02 PM, Arnaud TOURNIER lte...@gmail.com
wrote:

Thanks to all of you who participated to this very good things !

I am now able (from the trunk) to have a great experience debugging with
Gwt + Eclipse + Sdbg + Chrome.

I cannot be quantitatively very precise but the latest optimization
(-XcompilePerFile) seems to give good results. My project on which i test
that is not so big so the compilation takes about 10 seconds. Improvements
are obvious !

Thanks a lot!

Le vendredi 29 août 2014 18:16:40 UTC+2, juan_pablo_gardella a écrit :

Great news!! Thanks a lot for the effort.

On 29 August 2014 13:02, Ivan Markov ivan@gmail.com wrote:

BTW using a more recent laptop seems to make a difference and nearly
doubles the performance:
MacBook Pro model 2013 (I7 2.7 GHz):
- 2 to 3 seconds for recompiling changes to a single file
- 2 to 3 seconds for linking
- Changes to more types of course again results in a growth of the
recompilation time; this time it is 8 instead of 13 seconds for the same
set of around 10 changed files. Linking still 3 seconds.

I think you are getting there!

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscribe@
googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/c646cebb-005a-42fd-9f9d-
62334e1a3189%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/c646cebb-005a-42fd-9f9d-62334e1a3189%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/2e4c1342-cd60-
48c8-b6c0-eb286350b36b%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2e4c1342-cd60-48c8-b6c0-eb286350b36b%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Google Germany GmbH
*Dienerstr. 12*
*80331 München*

Registergericht und -nummer: Hamburg, HRB

Re: [gwt-contrib] -XcompilePerFile feedback

2014-09-08 Thread 'John Stalcup' via GWT Contributors

You had mentioned that you'd seen two other issues as well but hadn't
gotten around to making a repro case.

Are these issues still around? Thanks for the two repro cases you've
already supplied. They were very helpful.

John

On Wed, Sep 3, 2014 at 7:06 PM, John Stalcup stal...@google.com wrote:

Thanks for the repo update.

This is fixed now (https://gwt-review.googlesource.com/#/c/9004/)

On Wed, Sep 3, 2014 at 1:15 AM, Julien Dramaix julien.dram...@gmail.com
wrote:

Sorry I had forgot to push my last change. The file is there now.

On Wed, Sep 3, 2014 at 2:51 AM, 'John Stalcup' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:

I don't see style.gss in the repo.

On Fri, Aug 29, 2014 at 2:45 PM, Julien Dramaix
julien.dram...@gmail.com wrote:

Dear GWT team,

I'm now using the GWT 2.7 snapshot and I'm testing the per file
compilation and I found one issue.

Consider a UiBinder template using an external ClientBundle containing
a GssResource. If you change something on the .gss file and hit the button
to recompile the application. The application fails to run with this error:
Uncaught com.google.gwt.event.shared.UmbrellaException: Exception
caught: Exception caught: (ReferenceError) :
HomePageView_BinderImpl$Widgets_1_g$ is not defined

To reproduce this error, use this small application:
https://github.com/jDramaix/gwtpgwt27, change something in
the file be/jdramaix/test/client/resources/style.gss and recompile the
application.

I found also two others issues, but I was not able to reproduce them
with the simple application. I will try to investigate Monday in order to
get you an example.

Julien

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-z8mfPgytZQzPUYNVzb1JBP7yw4KRYGmqs5_HtrmXUAA%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-z8mfPgytZQzPUYNVzb1JBP7yw4KRYGmqs5_HtrmXUAA%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7AqA9ahHt4vmF1kVDAcjwDkHS4buFWFMrQnscEf8UDrQ%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7AqA9ahHt4vmF1kVDAcjwDkHS4buFWFMrQnscEf8UDrQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9xrZ8N5NpJESKyLE1sropX8xrJbmVBLU2r125nZnu_dQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-09-08 Thread 'John Stalcup' via GWT Contributors

Thanks for the feedback Jens.


On Mon, Sep 8, 2014 at 1:31 PM, Jens jens.nehlme...@gmail.com wrote:

 Any new bugs to report?


 Some things we have observed at work while using latest trunk SDM (compile
 per file):

 1.) If we don't use -noprecompile then SDM does not start because it says
 it has found more than one permutation. If we use -noprecompile then SDM
 starts and the first compile through the bookmarklet works as well. Our
 trunk build from 1st Sep still worked in both situations. With current
 trunk the precompile says that it can not set the locale property to en
 because only de was allowed, then tries a fallback value and finally the
 precompile fails.

I'm working on a CL right now to opt -XcompilePerFile into the
-noprecompile behavior for just the reason. Should be in today.


 2.) From time to time it happens that a recompile through the bookmarklet
 breaks the app because some JS isn't emitted correctly. For example we have
 a factory that creates a specific Ginjector and that factory has rebind
 rules that are triggered by a form factor property. Just today a colleague
 http://www.dict.cc/englisch-deutsch/colleague.html has recompiled the
 app and got DesktopGinjectorProvider is undefined. Another example is
 that a custom composite stopped working with error undefined is not a
 function. Taking a look at the JS code is seems like the problem happened
 in the constructor function that wanted to call the clinit function for
 that class. The machine that had the issue also had Chrome beta so I wasn't
 able to debug the pure JS because of 4.)

I've fixed two Gin generator related breakages like this so far. Are you
sure this is occurring with HEAD? If so then there's definitely a bug in
the stale types marking code that needs finding. If you can make a repro
case I'll figure it out.


 3.) On one machine the first compilation after starting SDM with
 -noprecompile never finishes. The CodeServer java process does some heavy
 work for the first minute or so and then goes to sleep and thats it. I call
 it SDM progress dots of death. The CodeServer arguments are exactly the
 same as on other machines which work without issue. I have no idea why this
 is happening. Also this only happens with latest trunk, a build from 1st
 Sep works.

Hmmm, that's really strange. It doesn't sound -XcompilePerFIle related so I
probably won't take a look at it for now. Maybe Brian will want to take a
look.


 4.) Not directly GWT related but you might want to know it: The new Chrome
 beta contains the change that Brian asked for which marks lines without
 source maps in gray so you know that you can not put a breakpoint on these
 lines. However for some reasons Chrome now also forbids setting breakpoints
 in the pure JS file (e.g. app-0.js) if no source map entry was found for
 that JS line. That can be quite annoying. For example I couldn't set a
 breakpoint inside a class constructor function because the whole JS
 function wasn't source mapped.

+skybrian



 -- J.

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/5b8b733b-ef6c-4aaa-a071-d0bf4b027ca6%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/5b8b733b-ef6c-4aaa-a071-d0bf4b027ca6%40googlegroups.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ9AjhxBfycmbkuYnh461MnsACpP96PULbJ%2B2LOViyXzyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-09-08 Thread 'John Stalcup' via GWT Contributors

On Mon, Sep 8, 2014 at 1:48 PM, John Stalcup stal...@google.com wrote:

 Thanks for the feedback Jens.


 On Mon, Sep 8, 2014 at 1:31 PM, Jens jens.nehlme...@gmail.com wrote:

 Any new bugs to report?


 Some things we have observed at work while using latest trunk SDM
 (compile per file):

 1.) If we don't use -noprecompile then SDM does not start because it says
 it has found more than one permutation. If we use -noprecompile then SDM
 starts and the first compile through the bookmarklet works as well. Our
 trunk build from 1st Sep still worked in both situations. With current
 trunk the precompile says that it can not set the locale property to en
 because only de was allowed, then tries a fallback value and finally the
 precompile fails.

 I'm working on a CL right now to opt -XcompilePerFile into the
 -noprecompile behavior for just the reason. Should be in today.

this is in now.


 2.) From time to time it happens that a recompile through the bookmarklet
 breaks the app because some JS isn't emitted correctly. For example we have
 a factory that creates a specific Ginjector and that factory has rebind
 rules that are triggered by a form factor property. Just today a
 colleague http://www.dict.cc/englisch-deutsch/colleague.html has
 recompiled the app and got DesktopGinjectorProvider is undefined. Another
 example is that a custom composite stopped working with error undefined is
 not a function. Taking a look at the JS code is seems like the problem
 happened in the constructor function that wanted to call the clinit
 function for that class. The machine that had the issue also had Chrome
 beta so I wasn't able to debug the pure JS because of 4.)

 I've fixed two Gin generator related breakages like this so far. Are you
 sure this is occurring with HEAD? If so then there's definitely a bug in
 the stale types marking code that needs finding. If you can make a repro
 case I'll figure it out.


 3.) On one machine the first compilation after starting SDM with
 -noprecompile never finishes. The CodeServer java process does some heavy
 work for the first minute or so and then goes to sleep and thats it. I call
 it SDM progress dots of death. The CodeServer arguments are exactly the
 same as on other machines which work without issue. I have no idea why this
 is happening. Also this only happens with latest trunk, a build from 1st
 Sep works.

 Hmmm, that's really strange. It doesn't sound -XcompilePerFIle related so
 I probably won't take a look at it for now. Maybe Brian will want to take a
 look.


 4.) Not directly GWT related but you might want to know it: The new
 Chrome beta contains the change that Brian asked for which marks lines
 without source maps in gray so you know that you can not put a breakpoint
 on these lines. However for some reasons Chrome now also forbids setting
 breakpoints in the pure JS file (e.g. app-0.js) if no source map entry was
 found for that JS line. That can be quite annoying. For example I couldn't
 set a breakpoint inside a class constructor function because the whole JS
 function wasn't source mapped.

 +skybrian



 -- J.

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/5b8b733b-ef6c-4aaa-a071-d0bf4b027ca6%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/5b8b733b-ef6c-4aaa-a071-d0bf4b027ca6%40googlegroups.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ83UH_BHS6mZTPmuL%2BrbfSGWRK3Z4-Pw6R_PzDoW1Rumg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-09-08 Thread 'John Stalcup' via GWT Contributors

On Mon, Sep 8, 2014 at 3:00 PM, Jens jens.nehlme...@gmail.com wrote:

I'm working on a CL right now to opt -XcompilePerFile into the
-noprecompile behavior for just the reason. Should be in today.

Cool will try it tomorrow.

I've fixed two Gin generator related breakages like this so far. Are you
sure this is occurring with HEAD? If so then there's definitely a bug in
the stale types marking code that needs finding. If you can make a repro
case I'll figure it out.

Currently I am not sure, need to ask colleague tomorrow. Can you tell me
the commit hashes of your two fixes so I can see which of our builds
contain them?

recentish ones are:
267ad5efd00aae9b0f69eca793891e9fdad28e45 Opts compilePerFile into
noPrecompile to avoid 1 permutation.
a43aa788cc2b78904c1bf6f0de9b8a1ebe78a6d2 Fixes cascaded generator
invalidation for inner classes.
9da4d05b62d7d3cb48ccd03de7b4ad676e2318bd Makes SDM+perFileCompile
correctly handle switching browsers.
7365570209426063bbc7fa4745e0b422e4fb4850 Marks types generated by
invalidated generators as modified.

And a last question just popped up again: Is there any way to force
embedded Jetty of CodeServer to not print out request logs at DEBUG level?
Kind of annoying when all these progress requests show up between GWT logs.

i don't know, +skybrian

-- J.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/b841ccc9-4bea-4e73-9333-c9861308b33d%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/b841ccc9-4bea-4e73-9333-c9861308b33d%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-qxvhsi8LBLsSkhsjYqpfKqdz6ZrGajg2%3DbJPJ3vZUtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] -XcompilePerFile feedback

2014-09-03 Thread 'John Stalcup' via GWT Contributors

Thanks for the repo update.

This is fixed now (https://gwt-review.googlesource.com/#/c/9004/)

On Wed, Sep 3, 2014 at 1:15 AM, Julien Dramaix julien.dram...@gmail.com
wrote:

Sorry I had forgot to push my last change. The file is there now.

On Wed, Sep 3, 2014 at 2:51 AM, 'John Stalcup' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com wrote:

I don't see style.gss in the repo.

On Fri, Aug 29, 2014 at 2:45 PM, Julien Dramaix julien.dram...@gmail.com
wrote:

Dear GWT team,

I'm now using the GWT 2.7 snapshot and I'm testing the per file
compilation and I found one issue.

Consider a UiBinder template using an external ClientBundle containing a
GssResource. If you change something on the .gss file and hit the button to
recompile the application. The application fails to run with this error:
Uncaught com.google.gwt.event.shared.UmbrellaException: Exception
caught: Exception caught: (ReferenceError) :
HomePageView_BinderImpl$Widgets_1_g$ is not defined

To reproduce this error, use this small application:
https://github.com/jDramaix/gwtpgwt27, change something in
the file be/jdramaix/test/client/resources/style.gss and recompile the
application.

I found also two others issues, but I was not able to reproduce them
with the simple application. I will try to investigate Monday in order to
get you an example.

Julien

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-z8mfPgytZQzPUYNVzb1JBP7yw4KRYGmqs5_HtrmXUAA%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-z8mfPgytZQzPUYNVzb1JBP7yw4KRYGmqs5_HtrmXUAA%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7AqA9ahHt4vmF1kVDAcjwDkHS4buFWFMrQnscEf8UDrQ%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D7AqA9ahHt4vmF1kVDAcjwDkHS4buFWFMrQnscEf8UDrQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ8ZMYBqqe5gWzv0dDCpyOOTNaD%2BLVxuLFSALt8m6JWPuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] -XcompilePerFile feedback

2014-09-02 Thread 'John Stalcup' via GWT Contributors

I don't see style.gss in the repo.

On Fri, Aug 29, 2014 at 2:45 PM, Julien Dramaix julien.dram...@gmail.com
wrote:

Dear GWT team,

I'm now using the GWT 2.7 snapshot and I'm testing the per file
compilation and I found one issue.

Consider a UiBinder template using an external ClientBundle containing a
GssResource. If you change something on the .gss file and hit the button to
recompile the application. The application fails to run with this error:
Uncaught com.google.gwt.event.shared.UmbrellaException: Exception caught:
Exception caught: (ReferenceError) : HomePageView_BinderImpl$Widgets_1_g$
is not defined

To reproduce this error, use this small application:
https://github.com/jDramaix/gwtpgwt27, change something in
the file be/jdramaix/test/client/resources/style.gss and recompile the
application.

I found also two others issues, but I was not able to reproduce them with
the simple application. I will try to investigate Monday in order to get
you an example.

Julien

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-z8mfPgytZQzPUYNVzb1JBP7yw4KRYGmqs5_HtrmXUAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-01 Thread 'John Stalcup' via GWT Contributors

you could try changing line 182 in Recompiler.java to register the std
linker
https://gwt.googlesource.com/gwt.git/+/2.5.1/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java

On Mon, Sep 1, 2014 at 2:43 AM, Ivan Markov ivan.mar...@gmail.com wrote:

Ray,

Using the xs linker seems like a bad idea, as it combines the
disadvantages of sso and the xsiframe: :)
(a) Like xsiframe, it injects script tags in the document body via
JavaScript, which makes these script tags uneditable via Chrome LiveEdit
(b) Like sso, it uses the Module Pattern to wrap all GWT code in a
function closure. I doubt that LiveEdit can replace the so-wrapped
functions, even if problem (a) was solved somehow.

I think a better starting point would be the xsiframe linker, as it at
least does not use the Module Pattern (right?) so at least problem (b) is
gone.

31 август 2014, неделя, 20:33:13 UTC+3, Ray Cromwell написа:

Try using the xs linker instead.

On Sun, Aug 31, 2014 at 10:15 AM, Ivan Markov ivan@gmail.com wrote:

(Background: I'm trying to further shorten the edit-compile-debug cycle
by playing with hot-code swapping of recompiled JavaScript in Chrome (via
Eclipse / SDBG))

GWT 2.7.0-SNAPSHOT, SDM mode, xsiframe linker (obviously), playing with
LiveEdit from within Chromedevtools initially:
- Editing module.nocache.js works
- However editing module-0.js does not work (big surprise)

Problem 1: I think the sourceURL=module-0.js line at the end of the
script should be present only if CrossSiteIframeLinker is running in
non-pretty / production mode. In pretty mode, where the script tag src
attribute is directly modified to point to the CAGFG...AB.cache.js
permutation this is probably just bringing confusion, no?

Unfortunately, fixing Problem 1 alone did not enable LiveEdit.
I think another issue (let's call it Problem 2) is that the xsiframe
linker is creating the iframe script tags dynamically using
JavaScript DOM manipulations. There is some evidence on the internet that
editing scripts injected that way is not supported.

I was thinking of solving Problem 2 by just switching to the sso
(SingleScriptLinker) linker, but then:
(a) It is still not supported in SuperDevMode -
https://code.google.com/p/google-web-toolkit/issues/detail?id=7722
(b) By looking at the source, it seems it is wrapping all the generated
GWT code in enclosing functions, which are then called at the end of the
script block. I don't think LiveEdit will be re-evaluating these, so this
wrapping has to go somehow...

Any ideas?

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/033a0106-49a2-
4d66-aed0-5ee07d515c4d%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d7bf5da-0ba5-48a1-b2f7-2dec9e74370b%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d7bf5da-0ba5-48a1-b2f7-2dec9e74370b%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ-iyyncF%3D5%3DB%2B3bwE2pEWX%2BcJ2APAEOqZWQmXa-cEwNMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

2014-09-01 Thread 'John Stalcup' via GWT Contributors

err, in master that would be
https://gwt.googlesource.com/gwt.git/+/master/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java
and line 327


On Mon, Sep 1, 2014 at 12:58 PM, John Stalcup stal...@google.com wrote:

 you could try changing line 182 in Recompiler.java to register the std
 linker
 https://gwt.googlesource.com/gwt.git/+/2.5.1/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java


 On Mon, Sep 1, 2014 at 2:43 AM, Ivan Markov ivan.mar...@gmail.com wrote:

 Ray,

 Using the xs linker seems like a bad idea, as it combines the
 disadvantages of sso and the xsiframe: :)
 (a) Like xsiframe, it injects script tags in the document body via
 JavaScript, which makes these script tags uneditable via Chrome LiveEdit
 (b) Like sso, it uses the Module Pattern to wrap all GWT code in a
 function closure. I doubt that LiveEdit can replace the so-wrapped
 functions, even if problem (a) was solved somehow.

 I think a better starting point would be the xsiframe linker, as it at
 least does not use the Module Pattern (right?) so at least problem (b) is
 gone.


 31 август 2014, неделя, 20:33:13 UTC+3, Ray Cromwell написа:

 Try using the xs linker instead.



 On Sun, Aug 31, 2014 at 10:15 AM, Ivan Markov ivan@gmail.com
 wrote:

 (Background: I'm trying to further shorten the edit-compile-debug cycle
 by playing with hot-code swapping of recompiled JavaScript in Chrome (via
 Eclipse / SDBG))

 GWT 2.7.0-SNAPSHOT, SDM mode, xsiframe linker (obviously), playing with
 LiveEdit from within Chromedevtools initially:
 - Editing module.nocache.js works
 - However editing module-0.js does not work (big surprise)

 Problem 1: I think the sourceURL=module-0.js line at the end of the
 script should be present only if CrossSiteIframeLinker is running in
 non-pretty /  production mode. In pretty mode, where the script tag src
 attribute is directly modified to point to the CAGFG...AB.cache.js
 permutation this is probably just bringing confusion, no?

 Unfortunately, fixing Problem 1 alone did not enable LiveEdit.
 I think another issue (let's call it Problem 2) is that the xsiframe
 linker is creating the iframe  script tags dynamically using
 JavaScript DOM manipulations. There is some evidence on the internet that
 editing scripts injected that way is not supported.

 I was thinking of solving Problem 2 by just switching to the sso
 (SingleScriptLinker) linker, but then:
 (a) It is still not supported in SuperDevMode -
 https://code.google.com/p/google-web-toolkit/issues/detail?id=7722
 (b) By looking at the source, it seems it is wrapping all the generated
 GWT code in enclosing functions, which are then called at the end of the
 script block. I don't think LiveEdit will be re-evaluating these, so this
 wrapping has to go somehow...

 Any ideas?

  --
 You received this message because you are subscribed to the Google
 Groups GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit-contributors+unsubscribe@
 googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/google-web-toolkit-contributors/033a0106-49a2-
 4d66-aed0-5ee07d515c4d%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.


  --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
  To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d7bf5da-0ba5-48a1-b2f7-2dec9e74370b%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d7bf5da-0ba5-48a1-b2f7-2dec9e74370b%40googlegroups.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_%2BFHVkZwZm%2B%3Dn2EF_OxULxucUViHLefbs2DtohWvXPag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-09-01 Thread 'John Stalcup' via GWT Contributors

Such a small time makes me think that you have particularly slow linkers.
What's the time split between compiling and linking?

On Mon, Sep 1, 2014 at 3:32 AM, Arnaud TOURNIER ltea...@gmail.com wrote:

Basically the compile took 10s before and 9s now, but this is a very tiny
project, so that's why i am saying the improvement is here but not
quantitatively measurable on my particular project. I will send better
stats when working with bigger projects.

Thanks
Arnuad

2014-09-01 12:25 GMT+02:00 'Daniel Kurka' via GWT Contributors
google-web-toolkit-contributors@googlegroups.com:

Hi Arnaud,

are those 10s after the changes we made or before?

-Daniel

On Mon, Sep 1, 2014 at 12:02 PM, Arnaud TOURNIER ltea...@gmail.com
wrote:

Thanks to all of you who participated to this very good things !

I am now able (from the trunk) to have a great experience debugging with
Gwt + Eclipse + Sdbg + Chrome.

Thanks a lot!

Le vendredi 29 août 2014 18:16:40 UTC+2, juan_pablo_gardella a écrit :

Great news!! Thanks a lot for the effort.

On 29 August 2014 13:02, Ivan Markov ivan@gmail.com wrote:

I think you are getting there!

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscribe@
googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/google-web-toolkit-contributors/c646cebb-005a-
42fd-9f9d-62334e1a3189%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/c646cebb-005a-42fd-9f9d-62334e1a3189%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2e4c1342-cd60-48c8-b6c0-eb286350b36b%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2e4c1342-cd60-48c8-b6c0-eb286350b36b%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Google Germany GmbH
*Dienerstr. 12*
*80331 München*

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

--
You received this message because you are subscribed to a topic in the
Google Groups GWT Contributors group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit-contributors/1EYSq2QZ51s/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujipnmokiRVxtpE1g%2BF%2BccZbkt0nZYf3jKsDm3ogvmN52%3DA%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujipnmokiRVxtpE1g%2BF%2BccZbkt0nZYf3jKsDm3ogvmN52%3DA%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANjaDneM-U8n56Kjr36Ce5D7_HRvaCcCqExFM4QB%2B-TsQdKNTg%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANjaDneM-U8n56Kjr36Ce5D7_HRvaCcCqExFM4QB%2B-TsQdKNTg%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to

Re: [gwt-contrib] Re: SDM -XcompilePerFile: initial feedback

2014-08-28 Thread 'John Stalcup' via GWT Contributors

Hey Ivan

We just finished fixing a couple of issues in this compile mode (one around
JSOs and a couple around rerunning Generators).

Any more feedback you have would be appreciated. If you see any bugs please
report them.

Thanks!

John

On Tue, Aug 19, 2014 at 1:07 AM, Ivan Markov ivan.mar...@gmail.com wrote:

(a) Javascript hot-swapping
One disadvantage of the current SDM recompilation is that it triggers
page reload in the browser.
If the application being debugged is a stateful, single-paged one, this
means that even for a very small change, the developer essentially
starts-over the debugging, as the application state is lost.

Now, the debugging protocol of Blink allows the debugger to hot-swap a
piece of JavaScript with a newer version, right?
If the incremental compiler preserves the names of the generated
Javascript types/functions, then a debugger like SDBG can detect the SDM
recompilation and can pro-actively push the newly generated JavaScript into
the browser. Imagine how cool is this: you stay on the page, spot a bug
(say, in an onclick event handler), fix the bug in the Java code, hit the
Recompile button (or Eclipse/SDBG does it for you behind the scenes when
you save your Java file!) and there you have it - you can click again and
now the correct, recompiled event handler will be triggered. All of this
without leaving the application page and starting over.

Of course, for the above to work, additional changes may be necessary.
For example, contrary to production, the generated javascript file should
probably always be named the same way. Perhaps, it should also not contain
one big eval statement. Finally, for big changes, the above hot-swapping
will likely not work, but the idea is not to make it work in all cases, but
for the majority of the small, incremental changes.

It does sound like an interesting idea. If at some point the browser
reload time (as opposed to the compile time) is the longest part then we
will start looking at ways to speed that up. One similarish idea we've
discussed is to change the linkers so that the output JS exists as
separates files. This would allow the browser to hold on to it's
precompiled javascript cache for parts of the application that haven't
changed (thus reload much faster). But as Ray mentions, we're pretty heads
down on an earlier stage of development right now. So I probably won't be
looking at something like this any time soon, but patches welcome.

The javascript hot swapping is not (only) addressing the browser page
reload time. Rather, it is addressing the frustration of the user that he
has lost the state of the app due to the page reload, and now she has to
potentially do lots of manual clicks and types *inside* the app until it is
brought again to the state where the bug happens. But for sure this is a
much lower priority than having a very fast incremental recompilation and
relinking. Once I have some time myself, I may start looking into hot
swapping in the context of SDBG.

(BTW, If outputting the 30+ MB javascript file does take some time then
looking into outputting instead a delta javascript file as you hint is
probably worth it even if we put aside my dreams for hot-code swapping via
the debugger... but then I'm only speculating here...)

What I am working on is trying to flesh out the maturity of this current
approach. At the moment we do not notice when you change the content of
resource files which were inputs to Generators and so as a result we fail
to rerun those Generators when we should. Once this is corrected there will
be a while spent on general bug finding.

After that we will probably start looking at remaining performance
bottlenecks. Roberto is already looking at Linkers and we think that the
next big opportunity after that will be in improving the TypeOracle
construction time (see https://gwt.googlesource.
com/gwt/+/master/dev/core/src/com/google/gwt/dev/javac/
CompilationUnitTypeOracleUpdater.java and related classes). But there
will probably be other opportunities as well.

Sounds great. I am already happy with the current 7 seconds recompile (as
long as the 18 seconds of relinking go down to 2 or so :-) ), but faster is
always better.

--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/1132c1d4-0ac7-4d1e-a1ad-7575e6dadab5%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/1132c1d4-0ac7-4d1e-a1ad-7575e6dadab5%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups GWT

38 matches

Mail list logo