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

['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

['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

['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  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 
> 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
>> 
>> 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
>> 
>> .
>> 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
> 
> .
> 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

['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
> 
> .
> 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

['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 
wrote:

> I use GWT 2.8 SnapShot with an app that runs with CSS only no GSS. Then I
> switched to GSS using:
>
> 
>
>  
>
>  "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
> 
> .
> 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

['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  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
> 
> .
> 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] Re: two errors in master

['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
> 
> .
> 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] 2 new libraries

['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  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
> 
> .
> 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: SDM + gin + generated GinModule not working well together

['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:*
> 
> 
> 
>
>  value="com.project.GeneratedGinModule"/>
>
> 
> 
> 
> 
>
> *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  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
>> . The "normal" compilation
>> works but not the incremental compile from SDM.
>>
>> I made a simple example available here
>> .
>>
>> From what I saw, the RestGinModule that gin is trying to load is
>> generated by a GWT generator (VelocityGenerator
>> 
>> .generateRestGinModule()) and passed to gin through the property
>>  "gin.ginjector.modules".
>> It seems unconventional but was working before.
>> Any ideas what is going on please ?
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google 

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

['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  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  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 
>> 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.

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

['John Stalcup' via GWT Contributors]

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  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  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/CAFw3gJ_CmanNCe7r06cj4TL1J6uojxanEeAqmPGCcHAv0%3D0VWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

['John Stalcup' via GWT Contributors]

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  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/CAFw3gJ_VLjqvDaEXeCZ-jsFjWx5MJ-92EcEAOpdLqLPjYmzcZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

['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 
wrote:

> i followed below steps to start super dev mode in my project
>   my project name is phoenix and it has total 14 moduls
>
> 
> phoenix-main
> phoenix-core
> phoenix-common
> phoenix-ocean
> 
> phoenix-admin
> 
> phoenix-framework
> phoenix-reports
> 
> 
> 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
> 
> .
> 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] stylesheet ignored/not handled in SDM 2.7.0-rc1

['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  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 true
> 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:
>
> 
> 
> 
>  />
> 
>
> 
> 
>
>
> 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:
> ...
> 
> ${project.build.directory}/${project.
> build.finalName}
> 
> ...
>
> 
> 
> org.codehaus.mojo
> gwt-maven-plugin
> ${gwtVersion}
> 
> 
> 
> compile
> i18n
> 
> 
> 
> 
> ${webappDirectory}
> GUI/GUI.html
> true
> 8080
> 8008
> 8
>
> de.company.department.project.
> client.util.i18n.Translation
>
> 
> -Xmx1024M -XX:+CMSClassUnloadingEnabled
> -XX:+UseConcMarkSweepGC -XX:MaxPermSize=256M
> 
>
> true
> true
>
> true
> false
> 9
> 
> 
>
>  --
> 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
> 
> .
> 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] Re: GWT 2.7 SDM incremental output too large

['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 
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] GWT 2.7 : precompile and incremental flags

['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] GWT 2.7 : precompile and incremental flags

['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 
> 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
>> 
>> .
>>
>> 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
> 
> .
> 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] Re: odd super dev mode times

['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 
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/20141020233903.2a9a93d1%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_tqOMHrG7Jon6521UZquTkQyexbH%3DzerjJmnKmsOequQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

['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] Re: GWT 2.7 release plan

['John Stalcup' via GWT Contributors]

-XjsInteropMode JS

On Thu, Oct 2, 2014 at 2:46 PM, confile 
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 
>> 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
>>> 
>>> .
>>>
>>> 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
> 
> .
>
> 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] Starting super dev mode in debug : performance very bad

['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 
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
> 
> .
> 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] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

['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 
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  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  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
>> 
>> .
>>
>> 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
> 
> .
>
> 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] Re: JsInterop

['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 
> 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
>> 
>> .
>> 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
> 
> .
>
> 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] Re: Change the superDevMode to be the default for dev-mode?

['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 
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 
>> 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
>>> 
>>> .
>>>
>>> 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
> 
> .
>
> 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] Re: Change the superDevMode to be the default for dev-mode?

['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 
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
> 
> .
>
> 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] Change the superDevMode to be the default for dev-mode?

['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
> 
> .
> 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] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

['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.

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  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  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
> 
> .
> 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] Vaadin and GWT 2.7 compilePerFile

['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  wrote:

> Ah, i didn't see that bug report. Thanks. Taking a look.
>
> On Wed, Sep 10, 2014 at 12:36 AM, Artur Signell  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
>> 
>> .
>> 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

['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  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
> 
> .
> 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

['John Stalcup' via GWT Contributors]

On Mon, Sep 8, 2014 at 3:00 PM, Jens  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
> 
> .
>
> 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] Re: SDM "-XcompilePerFile": initial feedback

['John Stalcup' via GWT Contributors]

On Mon, Sep 8, 2014 at 1:48 PM, John Stalcup  wrote:

> Thanks for the feedback Jens.
>
>
> On Mon, Sep 8, 2014 at 1:31 PM, Jens  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  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
>> 
>> .
>>
>> 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

['John Stalcup' via GWT Contributors]

Thanks for the feedback Jens.


On Mon, Sep 8, 2014 at 1:31 PM, Jens  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
>  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
> 
> .
>
> 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] -XcompilePerFile feedback

['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  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 
> 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=email&utm_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=email&utm_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=email&utm_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

['John Stalcup' via GWT Contributors]

Any new bugs to report?


On Tue, Sep 2, 2014 at 2:07 PM, Arnaud TOURNIER  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 
>> 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  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
> 
> .
>
> 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
>>> 

Re: [gwt-contrib] -XcompilePerFile feedback

['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 
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 > > 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=email&utm_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=email&utm_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=email&utm_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

['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 
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
> 
> .
> 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] Re: SDM "-XcompilePerFile": initial feedback

['John Stalcup' via GWT Contributors]

On Mon, Sep 1, 2014 at 3:55 AM, Seamus McMorrow 
wrote:

> Hi guys,
>
> I have just tried out the 2.7-SNAPSHOT. I have a fairly large multi-module
> maven project.
> For development, I am using STS 3.6, windows7, SSD, i7 3720qm 2.6Ghz,
>
> Starting SuperDevmode:
> Unification traversed 147422 fields and methods and 11825 types. 11773 are
> considered part of the current module and 11773 had all of their fields and
> methods traversed.
> Compilation succeeded -- 113.359s
> Linking succeeded -- 2.768s
> 120.982s total -- Compile completed
>
The first compile in -XcompilePerFile is slower than a regular compile
since it has to traverse a larger set of types and traverse them more fully
(to ensure later cache accesses are correct). I'm guessing that normally
you get about an 80s first compile? Eventually we should be able to make
even this first compile faster by persisting the MinimalRebuildCache to
disk and reusing it between different SDM process launches. Also (as
Roberto pointed out recently) if we switche from whole-type linking to
per-function linking then we could probably get away with doing the
old-style partial-class traversal, which would mean faster first compiles
and a little bit smaller output.


> Changing One File in one module project/jar:
> Unification traversed 5282 fields and methods and 2440 types. 238 are
> considered part of the current module and 238 had all of their fields and
> methods traversed.
>  Compilation succeeded -- 9.081s
>  Linking succeeded -- 1.566s
>  13.436s total -- Compile completed
>
> Some other things to note:
>
> When using GWT 2.6.1, a recompile used to take about 45 secs or so.
> Sourcemap debugging in Chrome now works perfectly! I can now debug the
> javascript via java in chrome and all the line numbers match. (This was not
> the case with 2.6.1)
> On the third compile I tried changing 3 files, however it gave me errors
> about not finding some class files.
>
Can you post these error messages and whether they are related to a
Generator? Are you weren't seeing the new warning about resources being
loaded via ClassLoader instead of being registered in the .gwt.xml file and
loaded via ResourceOracle?


> I will try to keep using this, and report any other findings.
>
> Keep up the great work guys, GWT development is going to get so much
> cooler. :)
> Looking forward to the official release
>
Great! Any bugs/repro cases you can report will help us get this to
release-worthy, sooner.

>
>
> --
> 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/f300a560-19e8-44bd-ba39-b2e48abb8522%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_%2BMPO3eWemLf6OBqO5W8KMoPeMrKGktgm2UMiwZa7cAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

['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  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 
>> 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  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
> 
> .
>
> 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
>>> 
>>> .
>>>
>>> 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
>> 
>> .
>>
>> 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
> 

Re: [gwt-contrib] Chrome LiveEdit and SDM

['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  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  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 

Re: [gwt-contrib] Chrome LiveEdit and SDM

['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  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 

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

['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  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
> 
> 

Re: [gwt-contrib] Some separate compilation errors/questions

['John Stalcup ' via GWT Contributors]

I have a patch in review at
https://gwt-review.googlesource.com/#/c/7290/to make that error
message more helpful when strict source inclusion is
turned on.


On Thu, Apr 24, 2014 at 12:02 PM, John Stalcup  wrote:

> Incremental builds are strict about source paths.
>
> Normal compiles implicitly include "client", but incremental builds do not
> because doing so would create massive amounts of duplicate source inclusion.
>
> Based on the error message i think you need to add a " path="client" />" to the biz/codr/gwt/incremental/Inremental.gwt.xml file.
> Let me know if this fixes it for you.
>
>
> On Thu, Apr 24, 2014 at 1:37 AM, Jens  wrote:
>
>> Thanks for trying it out.
>>>
>>> I would open bugs for these issues.
>>>
>>
>> After fixing all errors in my small app I encountered a final error I am
>> unable to solve. The incremental compiler can't seem to find the EntryPoint
>> of my app. After some debugging it looks like that all classes pulled in by
>> my entry point module (root module) are missing in the corresponding
>> LibraryTypeOracle. In case I did something strange I created a new empty
>> project with EntryPoint and this fails to compile as well:
>>
>> https://code.google.com/p/google-web-toolkit/issues/detail?id=8686
>>
>> -- J.
>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Some separate compilation errors/questions

['John Stalcup ' via GWT Contributors]

Incremental builds are strict about source paths.

Normal compiles implicitly include "client", but incremental builds do not
because doing so would create massive amounts of duplicate source inclusion.

Based on the error message i think you need to add a "" to the biz/codr/gwt/incremental/Inremental.gwt.xml file. Let me know if
this fixes it for you.


On Thu, Apr 24, 2014 at 1:37 AM, Jens  wrote:

> Thanks for trying it out.
>>
>> I would open bugs for these issues.
>>
>
> After fixing all errors in my small app I encountered a final error I am
> unable to solve. The incremental compiler can't seem to find the EntryPoint
> of my app. After some debugging it looks like that all classes pulled in by
> my entry point module (root module) are missing in the corresponding
> LibraryTypeOracle. In case I did something strange I created a new empty
> project with EntryPoint and this fails to compile as well:
>
> https://code.google.com/p/google-web-toolkit/issues/detail?id=8686
>
> -- J.
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Some separate compilation errors/questions

['John Stalcup ' via GWT Contributors]

Also, I just want to mention that the incremental compile is behind an
experimental flag because it's still very raw.

There are some low hanging fruit improvements that should make a big
difference:
* Teach IncrementalBuilder to run the compiles in parallel.
* Add stricter freshness checking so that we don't have to recompile all of
the modules that depend on module Foo, if the change in module Foo didn't
change the interface of any of its source files.
* Stop deleting the old library directory on every launch of SuperDevMode
* Improve ModuleDef parsing so that we can do an initial freshness check on
existing library files on disk, even on a fresh launch of SuperDevMode.
* more things...

I'll file some GWT issues for these and maybe get some community
involvement on splitting up the work.




On Tue, Apr 22, 2014 at 2:38 PM, 'Goktug Gokdogan ' via
GWT Contributors  wrote:

>
>
> On Tue, Apr 22, 2014 at 2:28 PM, 'John Stalcup ' via
> GWT Contributors  wrote:
>
>> If you're depending directly on anything (in this case DOM) then that
>> thing needs to be separately compilable. Which means it's .gwt.xml file
>> needs to *not* be marked with type=fileset at the top.
>>
>> If you look at User.gwt.xml and Core.gwt.xml you'll see that these are
>> already not filesets, since they have been verified to be compilable on
>> their own (meaning they accurately include their dependencies).
>>
>> You can try changing DOM.gwt.xml by removing the type=fileset marker, and
>> then deal with any compile failures that result. (Likely DOM.gwt.xml does
>> not accurately include all its dependencies and fixing it will require
>> adding some references and breaking some resulting circular references.
>> This is what Goktug has been doing recently with some other modules).
>>
>
> I untangled a lot of dependencies for this modules and made most them
> separately compilable but I'll need some time before sending out the
> patches.
>
>
>>
>> John
>>
>>
>> On Tue, Apr 22, 2014 at 2:25 PM, John Stalcup  wrote:
>>
>>> Hey Jens
>>>
>>> Thanks for trying it out.
>>>
>>> I would open bugs for these issues. Separate compilation does not assume
>>> that c.g.g.user.User is inherited. (It does secretly add an implicit
>>> c.g.g.core.Core dependency, but the user doesn't need to do anything for
>>> that).
>>>
>>>
>>> On Tue, Apr 22, 2014 at 2:22 PM, Jens  wrote:
>>>
>>>> I just tried separate compilation from gwt trunk on a very small
>>>> project. In this project I never inherited c.g.g.user.User directly but
>>>> only the most specific modules I need.
>>>>
>>>> One such module is c.g.g.dom.DOM which fails with separate compilation
>>>> as MediaElement needs classes from c.g.g.media.dom.client but c.g.g.dom.DOM
>>>> does not inherit it.
>>>>
>>>> Should we open bugs for such problems or does separate compilation
>>>> expect users to always inherit c.g.g.user.User?
>>>>
>>>> When I do so the compilation works again because it seems like it does
>>>> not want to compile the DOM module directly anymore but only the User
>>>> module which has c.g.g.d.DOM and (indirectly) c.g.g.media.dom.DOM
>>>> inherited. I guess the different compilation behavior is because of the
>>>> type="fileset" attribute on all these specific modules?
>>>>
>>>> Can anyone explain what type="fileset" exactly does? Are there other
>>>> types?
>>>>
>>>>
>>>> I also noticed that gwteventbinder does not work with separate
>>>> compilation and it seems like it is only fixable with a breaking change.
>>>> Anyone who is interested in it can take a look at
>>>> https://github.com/google/gwteventbinder/issues/20
>>>>
>>>>
>>>> -- J.
>>>>
>>>> --
>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>> ---
>>>> 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.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

Re: [gwt-contrib] Some separate compilation errors/questions

['John Stalcup ' via GWT Contributors]

Going into a little bit of detail on the meaning of type=fileset:

You can think of a type=fileset module as being just a bag of source files
and properties. It exists only to forward those source files and properties
onward to some library module which will actually do the compilation.

The reason filesets exist right now is that the standard GWT libraries
contain roughly 150 module files forming a graph with extensive circular
references in the modules and in the source. Filesets allow us to bundle
circularly referent areas together into a single chunk which can be
compiled as a group. At the moment there are only a couple of modules (Core
and User) which have been cleaned up to be compilable on their own. Over
time we will break these circular references and will have more independent
chunks that are independently compilable.

The existence of filesets create a danger that two different libraries
depend on the same fileset, and result in having duplicate copies of the
compiled source in the output. But the incremental build system will detect
this situation and throw an error (pointing out the two libraries that are
supplying duplicate source).



On Tue, Apr 22, 2014 at 2:28 PM, John Stalcup  wrote:

> If you're depending directly on anything (in this case DOM) then that
> thing needs to be separately compilable. Which means it's .gwt.xml file
> needs to *not* be marked with type=fileset at the top.
>
> If you look at User.gwt.xml and Core.gwt.xml you'll see that these are
> already not filesets, since they have been verified to be compilable on
> their own (meaning they accurately include their dependencies).
>
> You can try changing DOM.gwt.xml by removing the type=fileset marker, and
> then deal with any compile failures that result. (Likely DOM.gwt.xml does
> not accurately include all its dependencies and fixing it will require
> adding some references and breaking some resulting circular references.
> This is what Goktug has been doing recently with some other modules).
>
> John
>
>
> On Tue, Apr 22, 2014 at 2:25 PM, John Stalcup  wrote:
>
>> Hey Jens
>>
>> Thanks for trying it out.
>>
>> I would open bugs for these issues. Separate compilation does not assume
>> that c.g.g.user.User is inherited. (It does secretly add an implicit
>> c.g.g.core.Core dependency, but the user doesn't need to do anything for
>> that).
>>
>>
>> On Tue, Apr 22, 2014 at 2:22 PM, Jens  wrote:
>>
>>> I just tried separate compilation from gwt trunk on a very small
>>> project. In this project I never inherited c.g.g.user.User directly but
>>> only the most specific modules I need.
>>>
>>> One such module is c.g.g.dom.DOM which fails with separate compilation
>>> as MediaElement needs classes from c.g.g.media.dom.client but c.g.g.dom.DOM
>>> does not inherit it.
>>>
>>> Should we open bugs for such problems or does separate compilation
>>> expect users to always inherit c.g.g.user.User?
>>>
>>> When I do so the compilation works again because it seems like it does
>>> not want to compile the DOM module directly anymore but only the User
>>> module which has c.g.g.d.DOM and (indirectly) c.g.g.media.dom.DOM
>>> inherited. I guess the different compilation behavior is because of the
>>> type="fileset" attribute on all these specific modules?
>>>
>>> Can anyone explain what type="fileset" exactly does? Are there other
>>> types?
>>>
>>>
>>> I also noticed that gwteventbinder does not work with separate
>>> compilation and it seems like it is only fixable with a breaking change.
>>> Anyone who is interested in it can take a look at
>>> https://github.com/google/gwteventbinder/issues/20
>>>
>>>
>>> -- J.
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>> ---
>>> 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
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Some separate compilation errors/questions

['John Stalcup ' via GWT Contributors]

If you're depending directly on anything (in this case DOM) then that thing
needs to be separately compilable. Which means it's .gwt.xml file needs to
*not* be marked with type=fileset at the top.

If you look at User.gwt.xml and Core.gwt.xml you'll see that these are
already not filesets, since they have been verified to be compilable on
their own (meaning they accurately include their dependencies).

You can try changing DOM.gwt.xml by removing the type=fileset marker, and
then deal with any compile failures that result. (Likely DOM.gwt.xml does
not accurately include all its dependencies and fixing it will require
adding some references and breaking some resulting circular references.
This is what Goktug has been doing recently with some other modules).

John


On Tue, Apr 22, 2014 at 2:25 PM, John Stalcup  wrote:

> Hey Jens
>
> Thanks for trying it out.
>
> I would open bugs for these issues. Separate compilation does not assume
> that c.g.g.user.User is inherited. (It does secretly add an implicit
> c.g.g.core.Core dependency, but the user doesn't need to do anything for
> that).
>
>
> On Tue, Apr 22, 2014 at 2:22 PM, Jens  wrote:
>
>> I just tried separate compilation from gwt trunk on a very small project.
>> In this project I never inherited c.g.g.user.User directly but only the
>> most specific modules I need.
>>
>> One such module is c.g.g.dom.DOM which fails with separate compilation as
>> MediaElement needs classes from c.g.g.media.dom.client but c.g.g.dom.DOM
>> does not inherit it.
>>
>> Should we open bugs for such problems or does separate compilation expect
>> users to always inherit c.g.g.user.User?
>>
>> When I do so the compilation works again because it seems like it does
>> not want to compile the DOM module directly anymore but only the User
>> module which has c.g.g.d.DOM and (indirectly) c.g.g.media.dom.DOM
>> inherited. I guess the different compilation behavior is because of the
>> type="fileset" attribute on all these specific modules?
>>
>> Can anyone explain what type="fileset" exactly does? Are there other
>> types?
>>
>>
>> I also noticed that gwteventbinder does not work with separate
>> compilation and it seems like it is only fixable with a breaking change.
>> Anyone who is interested in it can take a look at
>> https://github.com/google/gwteventbinder/issues/20
>>
>>
>> -- J.
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Some separate compilation errors/questions

['John Stalcup ' via GWT Contributors]

Hey Jens

Thanks for trying it out.

I would open bugs for these issues. Separate compilation does not assume
that c.g.g.user.User is inherited. (It does secretly add an implicit
c.g.g.core.Core dependency, but the user doesn't need to do anything for
that).


On Tue, Apr 22, 2014 at 2:22 PM, Jens  wrote:

> I just tried separate compilation from gwt trunk on a very small project.
> In this project I never inherited c.g.g.user.User directly but only the
> most specific modules I need.
>
> One such module is c.g.g.dom.DOM which fails with separate compilation as
> MediaElement needs classes from c.g.g.media.dom.client but c.g.g.dom.DOM
> does not inherit it.
>
> Should we open bugs for such problems or does separate compilation expect
> users to always inherit c.g.g.user.User?
>
> When I do so the compilation works again because it seems like it does not
> want to compile the DOM module directly anymore but only the User module
> which has c.g.g.d.DOM and (indirectly) c.g.g.media.dom.DOM inherited. I
> guess the different compilation behavior is because of the type="fileset"
> attribute on all these specific modules?
>
> Can anyone explain what type="fileset" exactly does? Are there other types?
>
>
> I also noticed that gwteventbinder does not work with separate compilation
> and it seems like it is only fixable with a breaking change. Anyone who is
> interested in it can take a look at
> https://github.com/google/gwteventbinder/issues/20
>
>
> -- J.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
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.
For more options, visit https://groups.google.com/d/optout.