from:"John Stalcup"

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

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

Konstantin:

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

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

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

John


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

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

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

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

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

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

To be specific:

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


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

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

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

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

 Please share your feedback.

 Thanks,

 Goktug

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

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

Re: [gwt-contrib] Java to WebAssembly Compiler

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

My thoughts are pretty much exactly what Colin said.

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

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

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

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

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

/2cents

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

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

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

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

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

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

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

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

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

Done

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

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

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

 Bhaskar

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


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

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

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

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

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

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

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

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

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


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


  Compiling 1 permutation

 Compiling permutation 0...

 [ERROR] Unexpected internal compiler error

 java.lang.NullPointerException

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 [ERROR] Unrecoverable exception, shutting down

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

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

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

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

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

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

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

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

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

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

   [WARN] recompile failed

   [WARN] continuing to serve previous version


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


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

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

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

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

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

Hello,

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

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

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

Thanks

Christian

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

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

Re: [gwt-contrib] 2 new libraries

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

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

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

Hi all,

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

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

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

Tal.

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

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

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

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

Glad you like the cache reuse speedup!

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

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

Wow. It's awesome. Great work!

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

- Stephen

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

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

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

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

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

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


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

 Hi,

 I'm gonna add some more background here.

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

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

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

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

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

 *EntryPointToGenerate:*
 public interface EntryPointToGenerate extends EntryPoint {}

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

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

 @Override
 public void onModuleLoad() {}
 }

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

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

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

 Hi,

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

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

 The full stack trace is available in attachment.

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

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

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

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

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

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

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


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

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

 Here's what's going on:

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

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

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

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

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


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

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

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

 [+cc stalcup@]

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

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


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

 Hello guys,

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

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

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

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


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


 Cheers,

 Jan



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

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

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

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

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

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

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

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

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

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

I start devmode with:
mvn gwt:run

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

from my model file GUI.gwt.xml:

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

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

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

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

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

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

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

disableClassMetadatatrue/disableClassMetadata
disableCastCheckingtrue/disableCastChecking

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

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

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

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

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

This is with GWT 2.6.1?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Stephen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

 - Stephen

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


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

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

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

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

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


  depends on how many files are modified [+ invalidations]

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

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

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

 - Stephen

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


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

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

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

Hey

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

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

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

Hi,

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

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

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

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

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

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

Any thought ?

Julien

PS: I'm using Intellij13

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

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

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

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

-XjsInteropMode JS

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

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

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

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

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

- JsInterop Preview is part of the release?

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

Hi all,

we just settled on a GWT 2.7 release plan:

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

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

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

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

-Daniel

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

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

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

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

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

Re: [gwt-contrib] Re: JsInterop

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

Make sure turn turn on -XjsInteropMode JS

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

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

Chris

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I can explain what's going here I think.

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

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

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

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

John

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

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

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

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

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

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

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

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

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

Yeah I kind of agree.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for the report Artur.

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

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

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

Hi,

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

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

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

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

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

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

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

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

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

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

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

Hi,

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

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

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

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

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

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

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

Any new bugs to report?

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

Hi Daniel,

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

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

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

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

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

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

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

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

Hi Arnaud,

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

-Daniel

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

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

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

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

Thanks a lot!

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

Great news!! Thanks a lot for the effort.

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

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

I think you are getting there!

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

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

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

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

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

Registergericht und -nummer: Hamburg, HRB

Re: [gwt-contrib] -XcompilePerFile feedback

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

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

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

John

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

Thanks for the repo update.

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

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

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

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

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

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

Dear GWT team,

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

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

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

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

Julien

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

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

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

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

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

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

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

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

Thanks for the feedback Jens.


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

 Any new bugs to report?


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

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

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


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

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


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

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


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

+skybrian



 -- J.

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

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


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

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

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

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

 Thanks for the feedback Jens.


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

 Any new bugs to report?


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

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

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

this is in now.


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

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


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

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


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

 +skybrian



 -- J.

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

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




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

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

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

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

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

Cool will try it tomorrow.

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

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

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

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

i don't know, +skybrian

-- J.

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

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

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

Re: [gwt-contrib] -XcompilePerFile feedback

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

Thanks for the repo update.

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

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

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

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

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

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

Dear GWT team,

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

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

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

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

Julien

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

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

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

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

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

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

Re: [gwt-contrib] -XcompilePerFile feedback

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

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

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

Dear GWT team,

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

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

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

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

Julien

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

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

Re: [gwt-contrib] Chrome LiveEdit and SDM

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

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

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

Ray,

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

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

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

Try using the xs linker instead.

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

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

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

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

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

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

Any ideas?

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

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

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

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

Re: [gwt-contrib] Chrome LiveEdit and SDM

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

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


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

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


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

 Ray,

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

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


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

 Try using the xs linker instead.



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

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

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

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

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

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

 Any ideas?

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


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

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




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

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

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

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

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

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

Thanks
Arnuad

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

Hi Arnaud,

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

-Daniel

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

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

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

Thanks a lot!

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

Great news!! Thanks a lot for the effort.

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

I think you are getting there!

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

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

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

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

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

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

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

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

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

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

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

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

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

Hey Ivan

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

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

Thanks!

John

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2014-08-18 Thread John Stalcup

On Monday, August 18, 2014 7:14:38 AM UTC-7, Ivan Markov wrote:

Dear GWT team (and John in particular),

Lately I was checking from time to time the progress of the SDM
incremental compiler in GWT 2.7.0.

Let me first say - great work so far!
This morning our project was - for the first time - compilable with the
new incremental SDM code-path, without internal compiler errors or visible
malfunctioning.

That's great to hear :). We're pretty happy with the recent progress as
well.

And this with NO changes to the codebase. Also the fact that I don't have
to split our codebase into very many small acyclic modules (not that it is
not a good practice anyway) is obviously a HUGE PLUS.

What I am observing in terms of recompilation times is encouraging (25
seconds with 2.7 vs. 47 with 2.6.1) but what is even more interesting is
that the compilation itself (up until where it says Compile of
permutations succeeded) seems to take only 7 seconds, which is less than
30% of the recompilation time.

In other words, with the new incremental compiler, the biggest slowdown
during recompilation seems to be the linker now, right?

Yes, we've come to the same conclusion and Roberto is working on the linker
speed right now.

If the linking time can go down to, say, a couple of seconds, then SDM is
there (IMO).

So out of pure curiosity - are there obvious optimizations in the linker
which are still pending?

For example, I noticed that a huge amount of time ( 50% of the whole
linking time) is spend in Saving source with extras, i.e. SourceSaver.
Given that these sources are only needed by the browser during a
sourcemap-based debugging session, can't they be served on the fly by the
code server rather than being pregenerated on disk during the
recompilation? There are debugging scenarios (in-IDE debugging with SDBG),
where these source files are not even needed and never requested from the
codeserver.

Also, is there any way to accelerate the linker which is in the control of
the developer?
For example, can I turn off the above source files pregeneration to see
how much time is saved during recompilation?

Finally one side question:
Does the incremental compiler preserve the names of the generated
JavaScript types/functions across recompiles? Including the names of the
types/functions which ARE recompiled (as long as the programmer did not
change the name of the corresponding Java method/class, that is)?

Yes, names in this mode are now consistent for the life of that
SuperDevMode process (see
https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/js/JsPersistentPrettyNamer.java).

Because if it does, this opens interesting possibilities:

(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.

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.

What I am working on is

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

2014-04-24 Thread 'John Stalcup stal...@google.com' 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 source 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 jens.nehlme...@gmail.com 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

2014-04-24 Thread 'John Stalcup stal...@google.com' 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 stal...@google.com 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 source
 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 jens.nehlme...@gmail.com 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

2014-04-22 Thread 'John Stalcup stal...@google.com' 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 jens.nehlme...@gmail.com 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

2014-04-22 Thread 'John Stalcup stal...@google.com' 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 stal...@google.com 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 jens.nehlme...@gmail.com 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

2014-04-22 Thread 'John Stalcup stal...@google.com' 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 stal...@google.com 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 stal...@google.com 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 jens.nehlme...@gmail.com 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

2014-04-22 Thread 'John Stalcup stal...@google.com' 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 gok...@google.com' via
GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote:



 On Tue, Apr 22, 2014 at 2:28 PM, 'John Stalcup stal...@google.com' via
 GWT Contributors google-web-toolkit-contributors@googlegroups.com 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 stal...@google.com 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 jens.nehlme...@gmail.com 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.


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

Re: [gwt-contrib] Cannot build my project since 779627ac

2014-03-24 Thread John Stalcup

reconstructing the failure chain:
com.promis.weblink.client.ui.SplashFrm.java // victim
  com.promis.weblink.client.ui.SplashFrm_SplashFrmUiBinderImpl // victim
com.promis.ui.client.bundles.Images // victim
  com.promis.ui.client.bundles.Images_cs_InlineClientBundleGenerator //
actually is missing

I believe your bundle failed to be created because of changes I made in
that patch in
https://gwt-review.googlesource.com/#/c/6552/2/user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.javaand
corrected a week later in
https://gwt-review.googlesource.com/#/c/6574/1/user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java.

Have you synced recently? I think your issue goes away as long as you are
synced to at least 6d4d8a2.


On Sat, Mar 22, 2014 at 2:55 AM, Honza Rameš rame...@gmail.com wrote:

 Hello everyone,
 recently, after updating GWT master I wasn't able to neither compile nor
 debug my project in DevMode. I tracked the problem down to commit 779627ac
 after which I'm getting errors (see bellow) while generating UiBinder glue
 to one of my widgets it complains one of my interfaces isn't a type, but
 its there on the class path. The interface is a ClientBundle that I use
 from within the UiBinder template to load image from. Weird think is that I
 have similar ClientBundle placed elsewhere and used in another UiBinder
 template which works OK. This is not a problem with not having some modules
 included in my gwt.xml, the project setup remained the same. The app I'm
 compiling (I tried eclipse compile/DevMode and running the compiler from
 command line by hand as well) is a multi-project setup having two separate
 eclipse projects used as sources, but it never posed a problem. I tried to
 revert the changes from 779627ac and compiled on top of current HEAD
 (f6d098fc) and the project compiles OK.

 The UiBinder template usage is pretty standard:
 ...
 ui:with field='res' type='com.promis.ui.client.bundles.Images'/
 ...
 g:Image resource={res.information}/

 public class SplashFrm extends DecoratedPopupPanel implements
 CenterHelper.Client
 {
 private static SplashFrmUiBinder uiBinder =
 GWT.create(SplashFrmUiBinder.class);
 interface SplashFrmUiBinder extends UiBinderWidget, SplashFrm {}
 ...

 During compile this produces following error log:
   Validating units:
  Errors in
 'generated://5CF227F805D1F55776CDB49692D603C5/com/promis/weblink/client/ui/SplashFrm_SplashFrmUiBinderImpl.java'
 See snapshot:
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\com.promis.weblink.client.ui.SplashFrm_SplashFrmUiBinderImpl77307997322787911.java
  Ignored 1 unit with compilation errors in first pass.
 Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
 errors.
[ERROR] Errors in
 'generated://5CF227F805D1F55776CDB49692D603C5/com/promis/weblink/client/ui/SplashFrm_SplashFrmUiBinderImpl.java'
   [ERROR] Line 15: com.promis.ui.client.bundles.Images cannot be
 resolved to a type
   [ERROR] Line 15: com.promis.ui.client.bundles.Images cannot be
 resolved to a type
   [ERROR] Line 15: com.promis.ui.client.bundles.Images cannot be
 resolved to a type
   See snapshot:
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\com.promis.weblink.client.ui.SplashFrm_SplashFrmUiBinderImpl4533299510520776392.java
[ERROR] Errors in 'com/promis/weblink/client/ui/SplashFrm.java'
   [ERROR] Line 17: Rebind result
 'com.promis.weblink.client.ui.SplashFrm_SplashFrmUiBinderImpl' could not be
 found
Adding '2' new generated units
   Validating units:
  Errors in
 'generated://488AE7991663EA6C1F032A3C1B0EE609/com/promis/ui/client/bundles/Images_cs_InlineClientBundleGenerator.java'
 See snapshot:
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\com.promis.ui.client.bundles.Images_cs_InlineClientBundleGenerator6947991448159430337.java
  Errors in
 'generated://F74F74BA6B19A984D800E9A65EDA2E2B/com/promis/ui/client/bundles/Images_en_InlineClientBundleGenerator.java'
 See snapshot:
 C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\com.promis.ui.client.bundles.Images_en_InlineClientBundleGenerator4281512586235817971.java
  Ignored 2 units with compilation errors in first pass.
 Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
 errors.
[ERROR] Errors in
 'generated://488AE7991663EA6C1F032A3C1B0EE609/com/promis/ui/client/bundles/Images_cs_InlineClientBundleGenerator.java'
   [ERROR] Line 136: Referencing class
 'com.promis.ui.client.bundles.Images': unable to resolve class
   [ERROR] Line 137: Referencing class
 'com.promis.ui.client.bundles.Images': unable to resolve class
   [ERROR] Line 138: Referencing class
 'com.promis.ui.client.bundles.Images': unable to resolve class
   [ERROR] Line 139: Referencing class
 'com.promis.ui.client.bundles.Images': unable to resolve class
   [ERROR] Line 140: Referencing class
 'com.promis.ui.client.bundles.Images': unable

[gwt-contrib] One time whitespace cleanup.

2014-02-12 Thread John Stalcup

I'm going to do a one time automated whitespace cleanup of the GWT codebase.

If you have a large (1000+ line) code review in progress, let me know and
I'll hold off for a day or two to avoid conflicts.

You can ignore whitespace changes in blame with git blame -w.

John

-- 
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/groups/opt_out.

Re: [gwt-contrib] One time whitespace cleanup.

2014-02-12 Thread John Stalcup

sure


On Wed, Feb 12, 2014 at 6:07 PM, Goktug Gokdogan gok...@google.com wrote:

 I have plenty of patches that were waiting for apichecker. Can you hold of
 until next week?


 On Wed, Feb 12, 2014 at 12:35 PM, John Stalcup stal...@google.com wrote:

 I'm going to do a one time automated whitespace cleanup of the GWT
 codebase.

 If you have a large (1000+ line) code review in progress, let me know and
 I'll hold off for a day or two to avoid conflicts.

 You can ignore whitespace changes in blame with git blame -w.

 John

 --
 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/groups/opt_out.


  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext

2014-02-10 Thread John Stalcup

On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth niloc...@gmail.com wrote:

 Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but
 I've also seen this trying to understand the general compiler changes that
 are happening in trunk gwt - is the CompilerContext really an essential
 part of ModuleDefLoader in general? From what I can see it is tracked as a
 local variable, but only used in the enforceStrictResources() check, which
 could just as easily be a boolean. For any synthetic module (which can't
 have any resources at all), this is a moot point so the context could be
 skipped entirely, and more generally it *seems* to just be a flag.

not all changers are in. there are more uses coming.


 CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and
 passes it to the JdtCompiler, which doesn't actually use it at all - that
 seems to be the extent of its use when you do a
 ModuleDef.getCompilationState (which now requires that context as an
 argument, even though the ModuleDef already should have that state from the
 previously mentioned ModuleDefLoader?). Precompile takes it to get the
 module and the options (instead of taking the module and the options), and
 the J2JSCompiler takes it just to read options.

 At least as of 2.6 branch, haven't done the same tracing through master
 just yet.

 So my question is two-fold: Is this the new way of avoiding too many sets
 of config types to track, and if so, why restore the old APIs so that the
 designer can use them in 2.6.1 instead of updating the designer to generate
 a simple context for its own needs?

updating the designer code would leave existing designer installs broken.


 Assuming this is the future way of dealing with options/etc, won't the
 designer just break again as this becomes more and more necessary to hook
 into the compiler from outside?

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext

2014-02-10 Thread John Stalcup

the ModuleDefLoader/DOM downgrade was in the GWT 2.6 release branch only
(since 2.6 is strictly expected to maintain compatibility).

The GWT 3.0 branch was not changed. GWT 3.0 is more open to backwards
incompatible changes and I agree/fully expect that for the 3.0 release the
right thing to do will be to update the Designer code base to account for
to match the GWT 3.0 release.


On Mon, Feb 10, 2014 at 3:55 PM, Colin Alworth niloc...@gmail.com wrote:

 Thanks for the reply - I'll keep watching ;).

 W.R.T. designer, since existing installs are already broken and GWT 3+ is
 going to again remove these deprecated methods, wouldn't it make more sense
 to upgrade designer rather than downgrade ModuleDefLoader/DOM? (Keeping in
 mind that I don't know what other upcoming changes are coming, but I'm
 assuming that code like ModuleDefLoader will eventually have some
 advantages from the context objects, and designer can't just keep using
 this now-deprecated method forever.)

 On Monday, February 10, 2014 3:02:00 PM UTC-8, John Stalcup wrote:




 On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth nilo...@gmail.com wrote:

 Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by,
 but I've also seen this trying to understand the general compiler changes
 that are happening in trunk gwt - is the CompilerContext really an
 essential part of ModuleDefLoader in general? From what I can see it is
 tracked as a local variable, but only used in the enforceStrictResources()
 check, which could just as easily be a boolean. For any synthetic module
 (which can't have any resources at all), this is a moot point so the
 context could be skipped entirely, and more generally it *seems* to just be
 a flag.

 not all changers are in. there are more uses coming.


 CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and
 passes it to the JdtCompiler, which doesn't actually use it at all - that
 seems to be the extent of its use when you do a
 ModuleDef.getCompilationState (which now requires that context as an
 argument, even though the ModuleDef already should have that state from the
 previously mentioned ModuleDefLoader?). Precompile takes it to get the
 module and the options (instead of taking the module and the options), and
 the J2JSCompiler takes it just to read options.

 At least as of 2.6 branch, haven't done the same tracing through master
 just yet.

 So my question is two-fold: Is this the new way of avoiding too many
 sets of config types to track, and if so, why restore the old APIs so that
 the designer can use them in 2.6.1 instead of updating the designer to
 generate a simple context for its own needs?

 updating the designer code would leave existing designer installs broken.


 Assuming this is the future way of dealing with options/etc, won't the
 designer just break again as this becomes more and more necessary to hook
 into the compiler from outside?

 --
 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/groups/opt_out.


  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Cannot build any project since 5a972863

2014-01-23 Thread John Stalcup

Honza, I reverted the original breaking change yesterday. You shouldn't be
still broken (if you sync to master), let me know if you are.


On Thu, Jan 23, 2014 at 2:54 AM, Honza Rameš rame...@gmail.com wrote:

 That's great, as I said I'm using GPE to build the project. I also tried
 to compile by command line, but the compiler exited mysteriously in the
 middle of the compilation without any message at all (I did use
 com.google.gwt.dev.Compiler), all the generators were executed and just
 before compilation of permutations should be started, nothing happened
 (maybe it's not related and there is only a problem in my command line and
 classpath).

 Honza

 PS: And this is more general question, is there a way how to run the
 compiler directly from GWT sources without compiling? Of course given that
 I compiled GWT before to make all the thirdparty JARs. That would certainly
 simplify testing for me (but I don't want to run it from Eclipse).


 On Wednesday, January 22, 2014 8:39:45 PM UTC+1, John Stalcup wrote:

 Yeah. It seems that CompilePermsServer doesn't have a ModuleDef instance,
 so it's not populating compilerContext.getModule(), which laters causes
 compilerContext.getModule().isMonolithic() to fail.

 I'm working on a fix.


 On Wed, Jan 22, 2014 at 11:26 AM, Andrés Testi andres@gmail.comwrote:

 Hi John:

 I'm running ant without explicit target (build by default). No
 explicit flags. I got the same exception in two isolated environments
 (ubuntu 13.10 with OpenJDK, and Windows 8 with Oracle JDK). The exception
 is throwed when the script tries to compile the DynaTable sample.
  CompilerContext.getModule() seems to return null here:
 https://github.com/gwtproject/gwt/blob/master/
 dev/core/src/com/google/gwt/dev/jjs/UnifiedAst.java#L137

 - Andrés Testi

 El miércoles, 22 de enero de 2014 15:45:35 UTC-3, John Stalcup escribió:

 Yeah that does look to be related to my commit.

 Which compiler entry point are you launching and with what flags? I
 updated Compiler.java, CompilePerms.java, etc etc to property setup the
 module property of the compilerContext object, but it looks like I missed
 somewhere.

 John


 On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš ram...@gmail.com wrote:

 Hello everyone,
 I'm using master for my projects and after I updated to commit
 5a972863 (Added monolithic/separate branching to JavaToJavaScriptCompiler)
 suddenly I wasn't able to compile any of my GWT projects (in Eclipse, see
 error message bellow). I'm using jdk_1.7 and older commit (8ef35362) works
 just fine. Did any of you encountered build breakage recently, is there
 some workaround you know of?

 DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1.
 While compiling simple project I noticed that some of the permutations
 compile just fine. Could this be caused by IE6 permutation, I do have some
 deferred binding rules in my module targeting the IE6.

 Error messge:
  [ERROR] Compile failed
  java.lang.NullPointerException
  at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(
 UnifiedAst.java:137)
  at com.google.gwt.dev.CompilePerms.compile(
 CompilePerms.java:196)
  at com.google.gwt.dev.CompilePermsServer.
 compilePermutation(CompilePermsServer.java:307)
  at com.google.gwt.dev.CompilePermsServer.run(
 CompilePermsServer.java:274)
  at com.google.gwt.dev.CompilePermsServer.main(
 CompilePermsServer.java:237)
   [ERROR] Error from external worker
 java.lang.NullPointerException
 at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(Unified
 Ast.java:137)
 at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196)
 at com.google.gwt.dev.CompilePermsServer.compilePermutation(Com
 pilePermsServer.java:307)
 at com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer
 .java:274)
 at com.google.gwt.dev.CompilePermsServer.main(CompilePermsServe
 r.java:237)
   [ERROR] Unrecoverable exception, shutting down
 com.google.gwt.core.ext.UnableToCompleteException: (see previous log
 entries)
 at com.google.gwt.dev.ExternalPermutationWorkerFactory$
 ExternalPermutationWorker.compile(ExternalPermutationWorkerFacto
 ry.java:156)
 at com.google.gwt.dev.PermutationWorkerFactory$Manager$
 WorkerThread.run(PermutationWorkerFactory.java:73)
 at java.lang.Thread.run(Thread.java:744)

 Any help would be appreciated.

 Regards

 Honza Rames

 --
 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+unsubscribe@
 googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google
 Groups GWT

Re: [gwt-contrib] Cannot build any project since 5a972863

2014-01-22 Thread John Stalcup

Yeah that does look to be related to my commit.

Which compiler entry point are you launching and with what flags? I updated
Compiler.java, CompilePerms.java, etc etc to property setup the module
property of the compilerContext object, but it looks like I missed
somewhere.

John


On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš rame...@gmail.com wrote:

 Hello everyone,
 I'm using master for my projects and after I updated to commit 5a972863
 (Added monolithic/separate branching to JavaToJavaScriptCompiler)  suddenly
 I wasn't able to compile any of my GWT projects (in Eclipse, see error
 message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just
 fine. Did any of you encountered build breakage recently, is there some
 workaround you know of?

 DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1. While
 compiling simple project I noticed that some of the permutations compile
 just fine. Could this be caused by IE6 permutation, I do have some deferred
 binding rules in my module targeting the IE6.

 Error messge:
  [ERROR] Compile failed
  java.lang.NullPointerException
  at
 com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137)
  at
 com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196)
  at
 com.google.gwt.dev.CompilePermsServer.compilePermutation(CompilePermsServer.java:307)
  at
 com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer.java:274)
  at
 com.google.gwt.dev.CompilePermsServer.main(CompilePermsServer.java:237)
   [ERROR] Error from external worker
 java.lang.NullPointerException
 at
 com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137)
 at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196)
 at
 com.google.gwt.dev.CompilePermsServer.compilePermutation(CompilePermsServer.java:307)
 at
 com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer.java:274)
 at
 com.google.gwt.dev.CompilePermsServer.main(CompilePermsServer.java:237)
   [ERROR] Unrecoverable exception, shutting down
 com.google.gwt.core.ext.UnableToCompleteException: (see previous log
 entries)
 at
 com.google.gwt.dev.ExternalPermutationWorkerFactory$ExternalPermutationWorker.compile(ExternalPermutationWorkerFactory.java:156)
 at
 com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
 at java.lang.Thread.run(Thread.java:744)

 Any help would be appreciated.

 Regards

 Honza Rames

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Cannot build any project since 5a972863

2014-01-22 Thread John Stalcup

Yeah. It seems that CompilePermsServer doesn't have a ModuleDef instance,
so it's not populating compilerContext.getModule(), which laters causes
compilerContext.getModule().isMonolithic() to fail.

I'm working on a fix.


On Wed, Jan 22, 2014 at 11:26 AM, Andrés Testi andres.a.te...@gmail.comwrote:

 Hi John:

 I'm running ant without explicit target (build by default). No explicit
 flags. I got the same exception in two isolated environments (ubuntu 13.10
 with OpenJDK, and Windows 8 with Oracle JDK). The exception is throwed when
 the script tries to compile the DynaTable sample.
  CompilerContext.getModule() seems to return null here:
 https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/UnifiedAst.java#L137

 - Andrés Testi

 El miércoles, 22 de enero de 2014 15:45:35 UTC-3, John Stalcup escribió:

 Yeah that does look to be related to my commit.

 Which compiler entry point are you launching and with what flags? I
 updated Compiler.java, CompilePerms.java, etc etc to property setup the
 module property of the compilerContext object, but it looks like I missed
 somewhere.

 John


 On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš ram...@gmail.com wrote:

 Hello everyone,
 I'm using master for my projects and after I updated to commit 5a972863
 (Added monolithic/separate branching to JavaToJavaScriptCompiler)  suddenly
 I wasn't able to compile any of my GWT projects (in Eclipse, see error
 message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just
 fine. Did any of you encountered build breakage recently, is there some
 workaround you know of?

 DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1.
 While compiling simple project I noticed that some of the permutations
 compile just fine. Could this be caused by IE6 permutation, I do have some
 deferred binding rules in my module targeting the IE6.

 Error messge:
  [ERROR] Compile failed
  java.lang.NullPointerException
  at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(
 UnifiedAst.java:137)
  at com.google.gwt.dev.CompilePerms.compile(
 CompilePerms.java:196)
  at com.google.gwt.dev.CompilePermsServer.
 compilePermutation(CompilePermsServer.java:307)
  at com.google.gwt.dev.CompilePermsServer.run(
 CompilePermsServer.java:274)
  at com.google.gwt.dev.CompilePermsServer.main(
 CompilePermsServer.java:237)
   [ERROR] Error from external worker
 java.lang.NullPointerException
 at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(
 UnifiedAst.java:137)
 at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196)
 at com.google.gwt.dev.CompilePermsServer.compilePermutation(
 CompilePermsServer.java:307)
 at com.google.gwt.dev.CompilePermsServer.run(
 CompilePermsServer.java:274)
 at com.google.gwt.dev.CompilePermsServer.main(
 CompilePermsServer.java:237)
   [ERROR] Unrecoverable exception, shutting down
 com.google.gwt.core.ext.UnableToCompleteException: (see previous log
 entries)
 at com.google.gwt.dev.ExternalPermutationWorkerFacto
 ry$ExternalPermutationWorker.compile(ExternalPermutationWorkerFacto
 ry.java:156)
 at com.google.gwt.dev.PermutationWorkerFactory$
 Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
 at java.lang.Thread.run(Thread.java:744)

 Any help would be appreciated.

 Regards

 Honza Rames

 --
 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/groups/opt_out.


  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Some random modularization/cleanup-related news

2013-11-15 Thread John Stalcup

sounds *very* promising


On Fri, Nov 15, 2013 at 11:56 AM, Matthew Dempsky mdemp...@google.comwrote:

 Last night I wrote a quick one-off javac-based tool to parse and analyze
 all of GWT's source code, and to extract out inter-file dependencies (e.g.,
 dev/core/src/com/google/gwt/dev/GWTShell.java depends on
 dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java).  I then ran a
 strongly-connected components analysis on the resulting graph to form a DAG.

 My expectation was our interdependencies would be hairy and cyclic enough
 that the DAG would probably already be pretty constrained.  But it turns
 out that our 6022 source files form 5206 SCCs.  If I first collapse all
 source files into a single vertex, then our 502 packages still form 394
 SCCs.  Ignoring test sources, I still get 246 packages grouped into 138
 SCCs.

 I think that's still too many to be immediately useful, so probably my
 next step is to write a tool to let me interactively find components that
 share a lot of incoming and outgoing edges and merge them together.

 If anyone has suggestions on additional criteria I can easily take into
 account, I'm interested.  (E.g., I know I should probably take into account
 super source and/or gwt.xml files, but javac doesn't know about those, so I
 just skipped them for now for simplicity. ;))


 Also, as something maybe interesting, here's a map from our third party
 libraries to source directories where we use them.  (For simplicity, I'm
 running this against the copy of GWT we're using within Google; e.g., we
 haven't merged the HtmlUnit/Jetty/JSON changes yet.  Oh, and this skips
 JUnit and Selenium for no particular reason, but JUnit uses are pretty
 obvious and Selenium is only used by RunStyleSelenium.)

 lib/apache/ant-1.6.5.jar:
   dev/core/src/com/google/gwt/dev/resource/impl
   dev/core/src/com/google/gwt/dev/shell/jetty
   dev/core/test/com/google/gwt/dev/resource/impl

 lib/apache/commons/commons-collections-3.2.1.jar:
   dev/core/test/org/apache/commons/collections/iterators
   dev/core/test/org/apache/commons/collections/map
   user/test/com/google/gwt/i18n
   user/test/org/apache/commons/collections

 lib/apache/tapestry-util-text-4.0.2.jar:
   user/src/com/google/gwt/i18n/rebind

 lib/cldr/21/icu4j.jar:
   user/src/com/google/gwt/i18n/rebind

 lib/easymock/easymock-3.0.jar:
   user/test/com/google/gwt/resources/rg
   user/test/com/google/gwt/uibinder/rebind

 lib/eclipse/jdtCompilerAdapter-3.8.3.v20130121-145325.jar:
   dev/core/src/com/google/gwt/dev/shell/jetty

 lib/eclipse/org.eclipse.jdt.core_3.8.3.v20130121-145325.jar:
   dev/core/src/com/google/gwt/dev/javac
   dev/core/src/com/google/gwt/dev/jdt
   dev/core/src/com/google/gwt/dev/jjs/ast
   dev/core/src/com/google/gwt/dev/jjs/impl
   dev/core/test/com/google/gwt/dev/javac

 lib/guava/guava-15.0/guava-15.0-rebased.jar:
   dev/codeserver/java/com/google/gwt/dev/codeserver
   dev/core/src/com/google/gwt/core/ext
   dev/core/src/com/google/gwt/core/ext/linker/impl
   dev/core/src/com/google/gwt/core/linker
   dev/core/src/com/google/gwt/dev
   dev/core/src/com/google/gwt/dev/cfg
   dev/core/src/com/google/gwt/dev/javac
   dev/core/src/com/google/gwt/dev/javac/asm
   dev/core/src/com/google/gwt/dev/javac/typemodel
   dev/core/src/com/google/gwt/dev/jjs
   dev/core/src/com/google/gwt/dev/jjs/ast
   dev/core/src/com/google/gwt/dev/jjs/ast/js
   dev/core/src/com/google/gwt/dev/jjs/impl
   dev/core/src/com/google/gwt/dev/jjs/impl/codesplitter
   dev/core/src/com/google/gwt/dev/jjs/impl/gflow
   dev/core/src/com/google/gwt/dev/jjs/impl/gflow/cfg
   dev/core/src/com/google/gwt/dev/jjs/impl/gflow/constants
   dev/core/src/com/google/gwt/dev/jjs/impl/gflow/copy
   dev/core/src/com/google/gwt/dev/jjs/impl/gflow/liveness
   dev/core/src/com/google/gwt/dev/jjs/impl/gflow/unreachable
   dev/core/src/com/google/gwt/dev/js
   dev/core/src/com/google/gwt/dev/js/ast
   dev/core/src/com/google/gwt/dev/resource/impl
   dev/core/src/com/google/gwt/dev/shell
   dev/core/src/com/google/gwt/dev/util
   dev/core/src/com/google/gwt/dev/util/arg
   dev/core/src/com/google/gwt/soyc
   dev/core/test/com/google/gwt/core/ext/linker/impl
   dev/core/test/com/google/gwt/dev/cfg
   dev/core/test/com/google/gwt/dev/javac
   dev/core/test/com/google/gwt/dev/jjs/impl
   dev/core/test/com/google/gwt/dev/jjs/impl/codesplitter
   dev/core/test/com/google/gwt/dev/jjs/impl/gflow
   dev/core/test/com/google/gwt/dev/jjs/impl/gflow/cfg
   dev/core/test/com/google/gwt/dev/js
   user/src/com/google/gwt/editor/rebind
   user/src/com/google/gwt/i18n/rebind
   user/src/com/google/gwt/junit
   user/src/com/google/gwt/resources/rg
   user/src/com/google/gwt/safecss/shared
   user/src/com/google/gwt/safehtml/rebind
   user/src/com/google/gwt/safehtml/shared
   user/src/com/google/gwt/uibinder/rebind
   user/src/com/google/gwt/useragent/rebind
   user/src/com/google/gwt/user/rebind
   user/src/com/google/gwt/user/rebind/rpc
   user/src/com/google/gwt/user/rebind/ui

Re: [gwt-contrib] String concatenation

2013-10-31 Thread John Stalcup

That comment is from the original version of the file committed in 2009.
None of the original members from that time are still on the project. So
here's an educated guess.

As John Tamplin said, repeated string concatenation will make some part of
the AST tree particularly deep and since our visitor passes (which we use
for optimization and java-javascript semantic transformation) work by
walking the AST tree with recursive function calls. Getting to the tip of
that long string concatenation  chain will require a lot of recursion, and
it might be enough to run out of stack space.

Most JVMs will run out of stack space after about 1000 recursions. I
believe each AST node traversal costs us 2-3 function calls of stack depth
(some combination of accept(), traverse() and visit()) and each extra
concatenation is 2 AST nodes (1 for the + and one for the string) so
somewhere around 166-250 consecutive string concatenations will be enough
to overflow the stack.

So yes, it's probably still a good idea for your generator to go out of
it's way to limit consecutive string concatenations in its output.



On Thu, Oct 31, 2013 at 1:59 AM, Julien Dramaix julien.dram...@gmail.comwrote:

 Yep sorry it is in CssResourceGenerator line 266
 And there is a TODO at line 347 : TODO: Fix the compiler to better handle
 arbitrarily long concatenation expressions.

 So I was just wondering if something was done or not.


 On Wednesday, October 30, 2013 9:23:02 PM UTC+1, John Stalcup wrote:

 oh you mean in CssResourceGenerator.java

 found it, taking a look


 On Wed, Oct 30, 2013 at 1:22 PM, John Stalcup sta...@google.com wrote:

 can you link me to that comment? i'm unfamiliar.


 On Wed, Oct 30, 2013 at 1:10 PM, Julien Dramaix julien@gmail.comwrote:

 Dear GWT lovers,

 I have a question for the compiler guys : in the CssResource I see a
 comment mentioning that very large string concatenation expressions using
 '+' cause the GWT compiler to overflow the stack due to deep AST nesting.
 So it's preferable to use intermediate concatenation groupings in order to
 force the AST to be more balanced.

 I'm just wondering if this issue is still present with the actual
 version of the compiler or if it was fixed to better handle large
 concatenation ?

 Thanks,

 Julien

 --
 http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://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+unsubscribe@**
 googlegroups.com.
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .



  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] String concatenation

2013-10-30 Thread John Stalcup

oh you mean in CssResourceGenerator.java

found it, taking a look


On Wed, Oct 30, 2013 at 1:22 PM, John Stalcup stal...@google.com wrote:

 can you link me to that comment? i'm unfamiliar.


 On Wed, Oct 30, 2013 at 1:10 PM, Julien Dramaix 
 julien.dram...@gmail.comwrote:

 Dear GWT lovers,

 I have a question for the compiler guys : in the CssResource I see a
 comment mentioning that very large string concatenation expressions using
 '+' cause the GWT compiler to overflow the stack due to deep AST nesting.
 So it's preferable to use intermediate concatenation groupings in order to
 force the AST to be more balanced.

 I'm just wondering if this issue is still present with the actual version
 of the compiler or if it was fixed to better handle large concatenation ?

 Thanks,

 Julien

 --
 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/groups/opt_out.




-- 
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/groups/opt_out.

Re: [gwt-contrib] String concatenation

2013-10-30 Thread John Stalcup

can you link me to that comment? i'm unfamiliar.


On Wed, Oct 30, 2013 at 1:10 PM, Julien Dramaix julien.dram...@gmail.comwrote:

 Dear GWT lovers,

 I have a question for the compiler guys : in the CssResource I see a
 comment mentioning that very large string concatenation expressions using
 '+' cause the GWT compiler to overflow the stack due to deep AST nesting.
 So it's preferable to use intermediate concatenation groupings in order to
 force the AST to be more balanced.

 I'm just wondering if this issue is still present with the actual version
 of the compiler or if it was fixed to better handle large concatenation ?

 Thanks,

 Julien

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] What is the porpouse of ReboundTypeRecorder?

2013-10-25 Thread John Stalcup

it's purpose is described in https://gwt-review.googlesource.com/#/c/4981/


On Fri, Oct 25, 2013 at 12:13 PM, Andrés Testi andres.a.te...@gmail.comwrote:

 I just found this class in the master but I can't find references to it.
 Where is ReboundTypeRecorder intended to be used?
 Thanks.

 - Andrés Testi

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] What is the porpouse of ReboundTypeRecorder?

2013-10-25 Thread John Stalcup

Mmmm, yes and no.

as you know GWT.create() rebinding right now in our monolithic build pass
is statically calculated at compile time.

i'm working on adding a separate build pass and this pass requires that
GWT.create() handling be done dynamically at runtime.

the monolithic pass has smaller output and longer compile time and is best
for production releases.
the separate pass has larger output and shorter compile time and is best
for developer productivity.

so monolithic compilation and it's compile time GWT.create() rebinding will
never completely go away since it is key to smallest possible output size.

that being said, any extension of GWT.create() functionality that can't
also be implemented at runtime for the separate compilation pass, will not
be approved, at least not by me.



On Fri, Oct 25, 2013 at 12:25 PM, Andrés Testi andres.a.te...@gmail.comwrote:

 Thanks for the clarification, John. Does this mean that
 UnifyAst.UnifyVisitor.handleGwtCreate() will be deprecated/removed? I'm
 afraid because I'm working on a prototype with heavy changes on
 handleGwtCreate().

 - Andrés Testi

 El viernes, 25 de octubre de 2013 16:17:55 UTC-3, John Stalcup escribió:

 it's purpose is described in https://gwt-review.**
 googlesource.com/#/c/4981/https://gwt-review.googlesource.com/#/c/4981/


 On Fri, Oct 25, 2013 at 12:13 PM, Andrés Testi andres@gmail.comwrote:

 I just found this class in the master but I can't find references to it.
 Where is ReboundTypeRecorder intended to be used?
 Thanks.

 - Andrés Testi

 --
 http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://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+unsubscribe@**
 googlegroups.com.
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .


  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] What is the porpouse of ReboundTypeRecorder?

2013-10-25 Thread John Stalcup

since we're both making changes to the rebinding system, there's a very
good chance that our changes are going to collide.

i'm in the process of breaking my separate compilation prototype into small
pieces (generally 200-500 lines), cleaning them up, testing them, getting
them reviewed, and then committed. i've got about 5500 lines remaining to
run through this process.

it sounds like you have a lot of outstanding changes as well. maybe yours
and my changes will merge best if you do the same thing (iteratively commit
in lots of small chunks).


On Fri, Oct 25, 2013 at 12:41 PM, John Stalcup stal...@google.com wrote:

 Mmmm, yes and no.

 as you know GWT.create() rebinding right now in our monolithic build pass
 is statically calculated at compile time.

 i'm working on adding a separate build pass and this pass requires that
 GWT.create() handling be done dynamically at runtime.

 the monolithic pass has smaller output and longer compile time and is best
 for production releases.
 the separate pass has larger output and shorter compile time and is best
 for developer productivity.

 so monolithic compilation and it's compile time GWT.create() rebinding
 will never completely go away since it is key to smallest possible output
 size.

 that being said, any extension of GWT.create() functionality that can't
 also be implemented at runtime for the separate compilation pass, will not
 be approved, at least not by me.



 On Fri, Oct 25, 2013 at 12:25 PM, Andrés Testi 
 andres.a.te...@gmail.comwrote:

 Thanks for the clarification, John. Does this mean that
 UnifyAst.UnifyVisitor.handleGwtCreate() will be deprecated/removed? I'm
 afraid because I'm working on a prototype with heavy changes on
 handleGwtCreate().

 - Andrés Testi

 El viernes, 25 de octubre de 2013 16:17:55 UTC-3, John Stalcup escribió:

 it's purpose is described in https://gwt-review.**
 googlesource.com/#/c/4981/https://gwt-review.googlesource.com/#/c/4981/


 On Fri, Oct 25, 2013 at 12:13 PM, Andrés Testi andres@gmail.comwrote:

 I just found this class in the master but I can't find references to
 it. Where is ReboundTypeRecorder intended to be used?
 Thanks.

 - Andrés Testi

 --
 http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://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+unsubscribe@**
 googlegroups.com.
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .


  --
 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/groups/opt_out.




-- 
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/groups/opt_out.

Re: [gwt-contrib] build of the master branch is broken ?

2013-10-23 Thread John Stalcup

I'll take a look
On Oct 23, 2013 8:00 AM, Julien Dramaix julien.dram...@gmail.com wrote:

 Hi all,

 I've just synchronized my master branch with the remote one and try to
 build gwt by invoking ant but I receive the following error :

 build.alldeps.jar:

 compile:

 -filter.props:

 build:

 compile:

 precompile.modules:
  [java] Loading inherited module 'com.google.gwt.core.Core'
  [java]Loading inherited module 'com.google.gwt.emul.Emulation'
  [java]   Loading inherited module 'com.google.gwt.logging.LogImpl'
  [java]  [ERROR] Line 14: Unexpected exception while
 processing element 'replace-with'
  [java] java.lang.NoSuchMethodError:
 com.google.gwt.dev.cfg.ConditionAll: method init()V not found
  [java] at com.google.gwt.dev.cfg.Rule.init(Rule.java:29)
  [java] at
 com.google.gwt.dev.cfg.RuleReplaceWith.init(RuleReplaceWith.java:31)
  [java] at
 com.google.gwt.dev.cfg.ModuleDefSchema$BodySchema.__replace_with_begin(ModuleDefSchema.java:570)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
  [java] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

 the full compilation log can be found there :
 https://docs.google.com/file/d/0BwVGJUurq6uVZ1N0MXJLaFVnRFk/edit?usp=sharing

 Does anyone have an idea ?

 Thanks,

 Julien

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] build of the master branch is broken ?

2013-10-23 Thread John Stalcup

It appears that runtime execution is resulting from trying to use the old
zero-args constructor when it should be using the new varargs constructor.
I think it's likely that you need to recompile the class files that refer
to ConditionAll/CompoundCondition etc.

does it work for you after an ant clean ?


On Wed, Oct 23, 2013 at 8:13 AM, Julien Dramaix julien.dram...@gmail.comwrote:

 ok John keep me inform. FYI, my environment seems to be correct (ant 1.9.2
 with java 1.7) and the git history tells me that this class was modified
 recently.

 Thanks,

 Julien


 On Wed, Oct 23, 2013 at 5:02 PM, John Stalcup stal...@google.com wrote:

 I'll take a look
 On Oct 23, 2013 8:00 AM, Julien Dramaix julien.dram...@gmail.com
 wrote:

 Hi all,

 I've just synchronized my master branch with the remote one and try to
 build gwt by invoking ant but I receive the following error :

 build.alldeps.jar:

 compile:

 -filter.props:

 build:

 compile:

 precompile.modules:
  [java] Loading inherited module 'com.google.gwt.core.Core'
  [java]Loading inherited module 'com.google.gwt.emul.Emulation'
  [java]   Loading inherited module
 'com.google.gwt.logging.LogImpl'
  [java]  [ERROR] Line 14: Unexpected exception while
 processing element 'replace-with'
  [java] java.lang.NoSuchMethodError:
 com.google.gwt.dev.cfg.ConditionAll: method init()V not found
  [java] at com.google.gwt.dev.cfg.Rule.init(Rule.java:29)
  [java] at
 com.google.gwt.dev.cfg.RuleReplaceWith.init(RuleReplaceWith.java:31)
  [java] at
 com.google.gwt.dev.cfg.ModuleDefSchema$BodySchema.__replace_with_begin(ModuleDefSchema.java:570)
  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
  [java] at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

 the full compilation log can be found there :
 https://docs.google.com/file/d/0BwVGJUurq6uVZ1N0MXJLaFVnRFk/edit?usp=sharing

 Does anyone have an idea ?

 Thanks,

 Julien

 --
 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/groups/opt_out.

  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 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/W33ekCUisa0/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.

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


  --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread John Stalcup

GWTAR files are okay, but are an incomplete solution to the problem of
incremental compilation.

During a normal monolithic GWT compile:

   - ~50% of the time is spent loading Java source off disk, compiling it
   with JDT, translating the JDT Java AST to a GWT Java AST (1 AST per type),
   and populating type oracles.
   - the other ~50% of the time is spent stitching the individual type
   ASTs into one combined tree, running GWT and Javascript semantic
   normalization passes, running optimization passes, translating GWT Java AST
   to GWT Javascript AST, translating GWT Javascript AST to Javascript Source
   and linking to disk.

GWTAR has impact by effectively running that first ~50% chunk once per
module (using just the Java source available to that module) and
serializing the resulting GWT Java ASTs to disk, and reusing these per
module GWTAR caches for subsequent compiles.

So as a result, in the best possible world the maximum impact it can have
on compile time, is ~50%. In practice it has a little less than that
because reading and deserializing these GWT Java ASTs from disk takes some
(smaller) amount of time and because in large modular projects there's a
tendency for duplicate copies of the AST for the same type to accumulate in
multiple GWTAR files (thus resulting in wasted duplicate deserialization
time).

Unlike GWTAR files the incremental compilation approach i'm working on
makes/will make 90+% of the compile time split by module (the only time
left in the monlithic phase should be a small percentage of generators and
the final linking).

I don't want to discourage you from using GWTAR files, since they do have
positive impact. But I'm just saying that I'm not putting work into making
them easier to use or building easier build system integration for them,
since their maximum impact is limited.




On Wed, Aug 21, 2013 at 12:05 AM, James Nelson ja...@wetheinter.net wrote:

 re: Heiko Braun


 it means having an optional compilation path that does not recompile the
 entire world (as the current monolithic compile path does) and instead
 tries to recompile just files (or or modules) that have changed.

 it is exploratory work for me right now as there are very many issues
 standing in its way.

 if/when it is done and ready it should make a big impact on SuperDev mode
 refresh time by reducing compile time (when compiles are run
 non-monolithically)


 I've long felt like highly modular projects could greatly benefit from
 producing gwtar files so that unchanged code does not require recompiling.
 I've thought about using a maven plugin to add .gwtar to my jars, though
 this would not be a portable solution for all GWT developers.

 Any portable solution using gwtar would be to create one per module (using
 a flag to enable support while still experimental), or one per java package
 (maybe not a good idea given the size of some projects).

 Given that the compiler already knows to remove invalidated units, this
 does seem like a feasible option.
 Producing .gwtars could also be done periodically for the whole project at
 the developers whim, perhaps through a flag to a standard full compile?

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread John Stalcup

I agree that the fastest executing approach is the approach that does the
least amount of computation. And so yes, your suggestion to keep a warm
version of the AST loaded in memory, and update that AST on the fly with
just new AST's of changed classes is a fast design. But there are some
unconsidered questions: do you still have to retranslate the *entire* AST
to Javascript source (and is the resulting process still fast if you have
to do so)? Do the modified files need to trigger generator reruns? How do
you know which generators are/are not affected by the change? When
implementing this incremental generator support, how much duplication will
there be with existing generator logic in the main compile path?

If you follow this mutative/truly incremental approach in memory in
SuperDev mode, then it's unclear how to reuse this work to also speed up
normal compilation triggered by a build system or continuous integration
server (such as Maven or Jenkins).

The approach i'm working on is to make change normal compiles to be
incremental at the per module level. This should transparently speed up
not just build systems, but also SuperDev mode.

In a nutshell my approach (leaving out lots and lots of edge cases) is
this: run the GWT compiler on Module A with *just* the Java source for
Module A and the bytecode for its dependencies provided to the JDT
compiler. Take the results of this compilation and do all of the normal
transformations on it except for optimization (which are currently
inherently global) and write out the resulting Javascript (for just the
types that were provided as Java source) using a special namer that names
types/functions/variables in a globally stable way (so that cross modules
references will resolve at runtime) and write this Javascript into a
.gwtlib file. Repeat this for every module in the dependency tree,
starting at the leaf nodes. When you get to the root of the tree, run
global generators and link these precompiled Javascript chunks (that you
pull out of the accumulated .gwtlib files) into one big chunk.

This (should be) fast for 2 reasons: the amount of IO and computation for
each stage is kept to the minimum, and the the global phase is never
analyzing/transforming/outputting a global size AST (it's just
concatenating together the previously compiled Javascript for each of the
dependent modules). It's basically the same process as normal Java
compilation with separate Jar files being constructed.

It can make cold compiles better by making it possible to parallelize the
compilation of different modules in the module tree, and it can of course
make warm compiles better by requiring only the recompilation of the
particular module that contains the changed file (as well as the rerun of
global generators and linking). User.gwt.xml registers 16 generators, but
I'm expecting that I'll be able to annotate some of them as known to be
local so that they can be kept out of the global phase and for the
remaining ones it should be possible to run them partially locally and
partially globally (so as to minimize the size of the global phase).
Eventually it would be nice to deprecate and replace all generators that
require some global phase.




On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman
step...@exigencecorp.comwrote:

 Hey John,

  it means having an optional compilation path that does not recompile
  the entire world (as the current monolithic compile path does) and
  instead tries to recompile just files (or or modules) that have
  changed.

 Spiffy! Out of curiosity, would the API look something like:

 theBackendCompile.recompile(ListFile filesThatChanged)

 Such that the existing ResourceOracle/TypeOracle instances are mutated
 with the updated state, instead of being rebuilt?

 AFAIK, historically most of the optimizations around incremental
 compiles have always required going back to building ResourceOracle,
 TypeOracle from scratch, but speeding it up with caching.

 ...IIRC. It's been a little while since I've poked at the code.

 I know I'm being a broken record, but I think the mutative/truly
 incremental approach, while a (large) PITA to build, in the long run is
 the only solution that would be fast enough to get SuperDevMode fast
 enough such that it's hit save in Eclipse, the js file is updated,
 done!, just like Java (and web) developers are used to.

 (I know Brian really doesn't like solutions that require Eclipse, but I
 think the same mutative/incremental compiler API could just as well be
 called by an Eclipse plugin or an IDEA plugin or even a Java daemon
 polling the file system for changes. It's not IDE-specific.)

 Feel free to ignore my musings given I'm not actually contributing
 anything to the effort; just curious as to how things are going.

 - Stephen

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

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread John Stalcup

I guess i forgot to address your question about what the API would look
like. At this moment it looks like this:

!. Invoke GWT compiler on Module A
2. Invoke GWT compiler on Module B
3. Invoke GWT compiler on Module C, passing it .gwtlibs from Module's A
and B

When compiling Module A I'm not paying attention to which files are or are
not modified *at all*. I'm just recompiling every source file known to be
part of Module A. I'm leaving it the reponsibility of the build system that
is driving the compiler, to know which files have changed and thus know
which Modules should be recompiled as a result.

I may need to revisit some of that responsibility though, since the current
GWT Eclipse plugin owns/manages the GWT compile triggering process. I'm
toying with the idea of implementing this iterative compilation triggering
responsibility in Maven and (since GWT shouldn't try to act like a build
system) then integrating this into the GWT Eclipse plugin? I haven't
thought all the way through this part and haven't implemented any of this
part yet, so would appreciate suggestions.



On Wed, Aug 21, 2013 at 4:29 PM, John Stalcup stal...@google.com wrote:

 I agree that the fastest executing approach is the approach that does the
 least amount of computation. And so yes, your suggestion to keep a warm
 version of the AST loaded in memory, and update that AST on the fly with
 just new AST's of changed classes is a fast design. But there are some
 unconsidered questions: do you still have to retranslate the *entire* AST
 to Javascript source (and is the resulting process still fast if you have
 to do so)? Do the modified files need to trigger generator reruns? How do
 you know which generators are/are not affected by the change? When
 implementing this incremental generator support, how much duplication will
 there be with existing generator logic in the main compile path?

 If you follow this mutative/truly incremental approach in memory in
 SuperDev mode, then it's unclear how to reuse this work to also speed up
 normal compilation triggered by a build system or continuous integration
 server (such as Maven or Jenkins).

 The approach i'm working on is to make change normal compiles to be
 incremental at the per module level. This should transparently speed up
 not just build systems, but also SuperDev mode.

 In a nutshell my approach (leaving out lots and lots of edge cases) is
 this: run the GWT compiler on Module A with *just* the Java source for
 Module A and the bytecode for its dependencies provided to the JDT
 compiler. Take the results of this compilation and do all of the normal
 transformations on it except for optimization (which are currently
 inherently global) and write out the resulting Javascript (for just the
 types that were provided as Java source) using a special namer that names
 types/functions/variables in a globally stable way (so that cross modules
 references will resolve at runtime) and write this Javascript into a
 .gwtlib file. Repeat this for every module in the dependency tree,
 starting at the leaf nodes. When you get to the root of the tree, run
 global generators and link these precompiled Javascript chunks (that you
 pull out of the accumulated .gwtlib files) into one big chunk.

 This (should be) fast for 2 reasons: the amount of IO and computation for
 each stage is kept to the minimum, and the the global phase is never
 analyzing/transforming/outputting a global size AST (it's just
 concatenating together the previously compiled Javascript for each of the
 dependent modules). It's basically the same process as normal Java
 compilation with separate Jar files being constructed.

 It can make cold compiles better by making it possible to parallelize the
 compilation of different modules in the module tree, and it can of course
 make warm compiles better by requiring only the recompilation of the
 particular module that contains the changed file (as well as the rerun of
 global generators and linking). User.gwt.xml registers 16 generators, but
 I'm expecting that I'll be able to annotate some of them as known to be
 local so that they can be kept out of the global phase and for the
 remaining ones it should be possible to run them partially locally and
 partially globally (so as to minimize the size of the global phase).
 Eventually it would be nice to deprecate and replace all generators that
 require some global phase.




 On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman 
 step...@exigencecorp.com wrote:

 Hey John,

  it means having an optional compilation path that does not recompile
  the entire world (as the current monolithic compile path does) and
  instead tries to recompile just files (or or modules) that have
  changed.

 Spiffy! Out of curiosity, would the API look something like:

 theBackendCompile.recompile(ListFile filesThatChanged)

 Such that the existing ResourceOracle/TypeOracle instances are mutated
 with the updated state, instead of being rebuilt

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread John Stalcup

@Johannes Barop

Your approach is interesting since it allows you to avoid cache the results
of generator execution and not have to reparse and recompile generated code
during every monolithic compile. But since it's all based on GWTAR, you're
still limited to a maximum possible impact of 50%.

The approach i'm working on should be limited only by the number of modules
you define (the more the better) and the cost of global phase generator
execution (most of which I should be able to automatically move into local
phases, aka part of specific modules). So, while I can't guarantee that
your setup will be easily adoptable to the new compiler, it shouldn't
matter since the new incremental compilation path should be faster than
your setup and thus make it unnecessary.

There's not a lot you can do to help right now but I could eventually use
some help setting up support in external build systems (like Maven and Ant,
and possibly integrated with the GWT Eclipse plugin) for triggering the GWT
compiler once per module and/or once per modified module. I'll also
probably eventually want some external testers before this goes live. So
i'll keep you in mind.



On Wed, Aug 21, 2013 at 1:46 PM, Johannes Barop j...@barop.de wrote:


 Am 21.08.2013 um 09:05 schrieb James Nelson ja...@wetheinter.net:

  I've long felt like highly modular projects could greatly benefit from
 producing gwtar files so that unchanged code does not require recompiling.
  I've thought about using a maven plugin to add .gwtar to my jars, though
 this would not be a portable solution for all GWT developers.
 
  Any portable solution using gwtar would be to create one per module
 (using a flag to enable support while still experimental), or one per java
 package (maybe not a good idea given the size of some projects).
 
  Given that the compiler already knows to remove invalidated units, this
 does seem like a feasible option.
  Producing .gwtars could also be done periodically for the whole project
 at the developers whim, perhaps through a flag to a standard full compile?

 As far as I know a usual gwtar contains only a precompiled Java AST from
 the first compilation phase. You still need to run the generators on all
 the visible code. It saves some seconds but for me the most time consuming
 part is the code generation and JavaScript compilation.

 I've currently playing around with a project where I have multiple
 modules. For each module I generate the initial Java AST, run code
 generators and throw the precompiled code in a gwttar. When building the
 final application only a small code generator which discovers all
 precomputed code runs.

 It's a special use case because I have defined decoupled modules which I
 want to link together. I'm unsure if this is any help for an intelligent
 approach :-)

 @John Stalcup
 Is it possible to contribute in this area? For example I want to ensure
 that the code for the project is easily adoptable to the new compiler.


 BTW:
 I agree with Stephen that Java IDE's also should be supported well. Yes
 SuperDevMode enabled to debug in the browser but the IDE is the tool I'm
 used too and I have to use the IDE for server code anyway.

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-21 Thread John Stalcup

Agreed. The TypeOracle (actually there are many TypeOracles) indexes, AST
references, JProgram indexes, after optimization, etc etc, are extensive
and complex. Updating them in place when swapping out the AST for a
particular Type would be very tricky and failure prone.


On Wed, Aug 21, 2013 at 2:09 PM, John A. Tamplin j...@jaet.org wrote:

 On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman 
 step...@exigencecorp.com wrote:

 AFAIK, historically most of the optimizations around incremental
 compiles have always required going back to building ResourceOracle,
 TypeOracle from scratch, but speeding it up with caching.


 The problem is let's say you change file A.  How do you know what all
 needs to be updated in TypeOracle?  I am sure you can keep track of it, but
 it will require keeping much more data than is currently kept so you can
 incrementally update TypeOracle's data structures.  For example, let's say
 you remove an interface from a class.  Even if you walk down the
 inheritance tree, you can't just remove that interface, because some other
 ancestor might have implemented it.  The same sort of thing goes in many
 other places.

 Note that TypeOracle memory requirements has been a problem in the past
 for large internal apps.

 --
 John A. Tamplin

 --
 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/groups/opt_out.


-- 
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/groups/opt_out.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

2013-08-19 Thread John Stalcup

re: Heiko Braun

it means having an optional compilation path that does not recompile the
entire world (as the current monolithic compile path does) and instead
tries to recompile just files (or or modules) that have changed.

it is exploratory work for me right now as there are very many issues
standing in its way.

if/when it is done and ready it should make a big impact on SuperDev mode
refresh time by reducing compile time (when compiles are run
non-monolithically)


On Sat, Aug 10, 2013 at 12:01 AM, Heiko Braun ike.br...@googlemail.comwrote:

 Regarding hello world app running using separate compilation:  can you
 elaborate on that? Do you mean support for two distinct compilation units
 within the same page?

 Regards,Heiko

 --
 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/groups/opt_out.




-- 
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Super Dev Mode: deemphasize unused Java lines in codeserver'...

2013-06-28 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: Super Dev Mode: deemphasize unused Java lines in  
codeserver's UI

..


Patch Set 1:

(6 comments)

most of these comments are just suggestions.


File dev/codeserver/java/com/google/gwt/dev/codeserver/ReverseSourceMap.java
Line 12:   private final SourceMapConsumerV3 consumer;
i think consumer is too vague


Line 20:* If it can't be loaded, logs an error and returns null.
logs a warning


Line 29:   logger.log(TreeLogger.WARN, can't parse source map, e);
seems like maybe the decision about whether a parse exception is fatal,  
should be deferred to the caller of load() not to load() itself?




File dev/codeserver/java/com/google/gwt/dev/codeserver/SourceHandler.java
Line 189:   private void sendSourceFileAsHtml(String moduleName, String  
fileName, BufferedReader lines,
is source html highlighting out of scope for the responsibilities of this  
file? Serves Java source files so that a browser's debugger can display  
them.



Line 194: File file = new File(fileName);
s/fileName/sourceFileName

s/file/sourceFile


Line 200: out.startTag(html).nl();
it might not be worth the hassle, but did you consider using some sort of  
string templating library instead?



--
To view, visit https://gwt-review.googlesource.com/3600
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Id16bcd2287630cebf7afb8bbbe0a198b28f5ada9
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-HasComments: Yes

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Adds a regression test for fragment splitting

2013-06-28 Thread John Stalcup


John Stalcup has submitted this change and it was merged.

Change subject: Adds a regression test for fragment splitting
..


Adds a regression test for fragment splitting

Test to verifies that future changes don't accidentally
push *all* code into the leftover fragment.

Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Review-Link: https://gwt-review.googlesource.com/#/c/3590/
---
M user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
M user/test/com/google/gwt/dev/jjs/CompilerSuite.java
A user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
A user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
A user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
6 files changed, 200 insertions(+), 3 deletions(-)

Approvals:
  Matthew Dempsky: Looks good to me, but someone else must approve
  Leeroy Jenkins: Verified
  Goktug Gokdogan: Looks good to me, approved



diff --git  
a/user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java  
b/user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java

index 130200c..5c0d38b 100644
--- a/user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
+++ b/user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
@@ -57,7 +57,7 @@
* RequestData's tryInstall() function, and if it fails, it should call  
it's

* RequestData's onLoadError() function.
*/
-  interface DownloadStrategy {
+  protected interface DownloadStrategy {
 void tryDownload(final RequestData request);
   }

@@ -110,8 +110,12 @@
   this.downloadStrategy = downloadStrategy;
 }

+public LoadTerminatedHandler getErrorHandler() { return errorHandler; }
+
 public int getFragment() { return fragment; }

+public int getRetryCount() { return retryCount; }
+
 public String getUrl() { return url; }

 public void onLoadError(Throwable e, boolean mayRetry) {
diff --git  
a/user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java  
b/user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java

index 1ced92f..e6054ff 100644
--- a/user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
+++ b/user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
@@ -29,7 +29,7 @@
   /**
* Uses XHR's to download the code.
*/
-  protected static class XhrDownloadStrategy implements DownloadStrategy {
+  public static class XhrDownloadStrategy implements DownloadStrategy {
 @Override
 public void tryDownload(final RequestData request) {
   final XMLHttpRequest xhr = XMLHttpRequest.create();
diff --git a/user/test/com/google/gwt/dev/jjs/CompilerSuite.java  
b/user/test/com/google/gwt/dev/jjs/CompilerSuite.java

index 1e35dd0..47e4018 100644
--- a/user/test/com/google/gwt/dev/jjs/CompilerSuite.java
+++ b/user/test/com/google/gwt/dev/jjs/CompilerSuite.java
@@ -22,8 +22,8 @@
 import com.google.gwt.dev.jjs.test.BlankInterfaceTest;
 import com.google.gwt.dev.jjs.test.ClassCastTest;
 import com.google.gwt.dev.jjs.test.ClassObjectTest;
-import com.google.gwt.dev.jjs.test.CompilerTest;
 import com.google.gwt.dev.jjs.test.CompilerMiscRegressionTest;
+import com.google.gwt.dev.jjs.test.CompilerTest;
 import com.google.gwt.dev.jjs.test.CoverageTest;
 import com.google.gwt.dev.jjs.test.EnhancedForLoopTest;
 import com.google.gwt.dev.jjs.test.EnumsTest;
@@ -47,6 +47,7 @@
 import com.google.gwt.dev.jjs.test.MiscellaneousTest;
 import com.google.gwt.dev.jjs.test.NativeLongTest;
 import com.google.gwt.dev.jjs.test.ObjectIdentityTest;
+import com.google.gwt.dev.jjs.test.RunAsyncContentTest;
 import com.google.gwt.dev.jjs.test.RunAsyncFailureTest;
 import com.google.gwt.dev.jjs.test.RunAsyncMetricsIntegrationTest;
 import com.google.gwt.dev.jjs.test.RunAsyncTest;
@@ -97,6 +98,7 @@
 suite.addTestSuite(MiscellaneousTest.class);
 suite.addTestSuite(NativeLongTest.class);
 suite.addTestSuite(ObjectIdentityTest.class);
+suite.addTestSuite(RunAsyncContentTest.class);
 suite.addTestSuite(RunAsyncFailureTest.class);
 suite.addTestSuite(RunAsyncMetricsIntegrationTest.class);
 suite.addTestSuite(RunAsyncTest.class);
diff --git a/user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml  
b/user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml

new file mode 100644
index 000..a123392
--- /dev/null
+++ b/user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
@@ -0,0 +1,21 @@
+!-- 
--
+!-- Copyright 2013 Google  
Inc. --
+!-- Licensed under the Apache License, Version 2.0 (the License);  
you--
+!-- may not use this file except in compliance with the License. You  
may   --
+!-- may obtain a copy of the License

[gwt-contrib] Change in gwt[master]: adds type tightening (and tests) for casts inside of RunAsyn...

2013-06-28 Thread John Stalcup


John Stalcup has submitted this change and it was merged.

Change subject: adds type tightening (and tests) for casts inside of  
RunAsync onSuccessCalls, resulting in smaller leftover fragments

..


adds type tightening (and tests) for casts inside of RunAsync  
onSuccessCalls, resulting in smaller leftover fragments


Change-Id: I7b454db222da054834aa0d78b1a769100bf9da9b
Review-Link: https://gwt-review.googlesource.com/#/c/3460/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
M dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
2 files changed, 56 insertions(+), 9 deletions(-)

Approvals:
  Roberto Lublinerman: Looks good to me, approved
  Leeroy Jenkins: Verified



diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java

index 5ac6ea7..0c13a7a 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
@@ -45,6 +45,7 @@
 import com.google.gwt.dev.jjs.ast.JProgram;
 import com.google.gwt.dev.jjs.ast.JReferenceType;
 import com.google.gwt.dev.jjs.ast.JReturnStatement;
+import com.google.gwt.dev.jjs.ast.JRunAsync;
 import com.google.gwt.dev.jjs.ast.JTryStatement;
 import com.google.gwt.dev.jjs.ast.JType;
 import com.google.gwt.dev.jjs.ast.JTypeOracle;
@@ -625,6 +626,13 @@
 }

 @Override
+public boolean visit(JRunAsync x, Context ctx) {
+  // JRunAsync's onSuccessCall is not normally traversed but should be  
here.

+  x.traverseOnSuccess(this);
+  return true;
+}
+
+@Override
 public boolean visit(JClassType x, Context ctx) {
   // don't mess with classes used in code gen
   if (program.codeGenTypes.contains(x)) {
diff --git  
a/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java  
b/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java

index 70eaa5e..bc8b1b6 100644
--- a/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
+++ b/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
@@ -83,13 +83,14 @@

   private JProgram jProgram = null;
   private JsProgram jsProgram = null;
-
-  public void setUp() throws Exception{
+
+  @Override
+  public void setUp() throws Exception {
 super.setUp();
 stackMode.addDefinedValue(new ConditionNone(), STRIP);
 jsProgram = new JsProgram();
   }
-
+
   public void testSimple() throws UnableToCompleteException {
 StringBuffer code = new StringBuffer();
 code.append(package test;\n);
@@ -127,6 +128,34 @@

 // functionC must be in the initial fragment.
 assertInFragment(functionC, 0);
+  }
+
+  public void testOnSuccessCallCast() throws UnableToCompleteException {
+StringBuffer code = new StringBuffer();
+code.append(package test;\n);
+code.append(import com.google.gwt.core.client.GWT;\n);
+code.append(import com.google.gwt.core.client.RunAsyncCallback;\n);
+code.append(public class EntryPoint {\n);
+code.append(   + functionA);
+code.append(   + functionB);
+code.append(   + functionC);
+code.append(  public static void onModuleLoad() {\n);
+code.append(functionC(););
+code.append( +  
createRunAsync((RunAsyncCallback), functionA();));
+code.append( +  
createRunAsync((RunAsyncCallback), functionB();));

+code.append(  }\n);
+code.append(}\n);
+compileSnippet(code.toString());
+
+// init + 2 fragments + leftover.
+assertFragmentCount(4);
+
+assertInFragment(functionA, 1);
+assertInFragment(functionB, 2);
+
+// Verify that functionA and B aren't in the leftover.
+assertNotInFragment(functionA, 3);
+assertNotInFragment(functionB, 3);
   }

   public void testMergeLeftOvers() throws UnableToCompleteException {
@@ -292,6 +321,8 @@
 jProgram.addEntryMethod(findMethod(jProgram, onModuleLoad));
 CastNormalizer.exec(jProgram, false);
 ArrayNormalizer.exec(jProgram);
+TypeTightener.exec(jProgram);
+MethodCallTightener.exec(jProgram);
 MapStandardSymbolData, JsName symbolTable =
   new TreeMapStandardSymbolData, JsName(new  
SymbolData.ClassIdentComparator());

 JavaToJavaScriptMap map = GenerateJavaScriptAST.exec(
@@ -332,13 +363,21 @@
 mergeLimit);
   }

-
-  private static String createRunAsync(String body) {
-return GWT.runAsync(new RunAsyncCallback() { +
-   public void onFailure(Throwable reason) {} +
-   public void onSuccess() { + body + }});;
+  private static String createRunAsync(String cast, String body) {
+StringBuffer code = new StringBuffer();
+code.append(GWT.runAsync( + cast + new RunAsyncCallback() {\n);
+code.append(  public void onFailure(Throwable reason) {}\n);
+code.append(  public void onSuccess() {\n);
+code.append( + body);
+code.append(  }\n);
+code.append(});\n);
+return code.toString

[gwt-contrib] Change in gwt[master]: adds regression testing against future changes that might ac...

2013-06-27 Thread John Stalcup


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3590

to look at the new patch set (#5).

Change subject: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

..

adds regression testing against future changes that might accidentally push  
all fragment code into the leftover fragment


Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Review-Link: https://gwt-review.googlesource.com/#/c/3590/
---
M user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
M user/test/com/google/gwt/dev/jjs/CompilerSuite.java
A user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
A user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
A user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
6 files changed, 200 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds regression testing against future changes that might ac...

2013-06-27 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

..


Patch Set 4:

(4 comments)


File user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
Line 32:   protected class XhrDownloadStrategy implements DownloadStrategy {
Done



File user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
Line 44:   public void onFailure(Throwable caught) {}
Done


Line 55:   public void testUniqueContentRegular() {
Done



File user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java
Line 250: }
Done


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-HasComments: Yes

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Adds a regression test for fragment splitting

2013-06-27 Thread John Stalcup


Hello Roberto Lublinerman, Leeroy Jenkins, Goktug Gokdogan,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3590

to look at the new patch set (#6).

Change subject: Adds a regression test for fragment splitting
..

Adds a regression test for fragment splitting

Test to verifies that future changes don't accidentally
push *all* code into the leftover fragment.

Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Review-Link: https://gwt-review.googlesource.com/#/c/3590/
---
M user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
M user/test/com/google/gwt/dev/jjs/CompilerSuite.java
A user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
A user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
A user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
6 files changed, 200 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Adds a regression test for fragment splitting

2013-06-27 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: Adds a regression test for fragment splitting
..


Patch Set 5:

(5 comments)


Commit Message
Line 7: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

Done


Line 7: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

Done



File user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
Line 114:
i'm being consistent with the file.

do you want me to:
1. reformat the whole file,
2. be different from the rest of the file, or
3. be consistent with the file?



File user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
Line 49: super.tryDownload(new  
com.google.gwt.core.client.impl.LoadingStrategyBase.RequestData(
it was conflicting with  
com.google.web.bindery.requestfactory.shared.impl.RequestData and something  
to do with the class hierarchy (before the most recent change you  
requested) was making the wrong one resolve first and organize import fail  
repeatedly


seems to be working correctly now. i've removed the FQN



File user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
Line 66: String sharedContent = Same String in multiple  
fragments.;
it can't be that, because then it ends up in the initial fragment (i tried  
it that way first). also i can't check for the existence of a class or  
field because the names are obfuscated randomly. i think we're kind of  
stuck with this shared interned String



--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds regression testing against future changes that might ac...

2013-06-26 Thread John Stalcup


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3590

to look at the new patch set (#2).

Change subject: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

..

adds regression testing against future changes that might accidentally push  
all fragment code into the leftover fragment


Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Review-Link: https://gwt-review.googlesource.com/#/c/3590/
---
M user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
M user/test/com/google/gwt/dev/jjs/CompilerSuite.java
A user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
M user/test/com/google/gwt/dev/jjs/RunAsyncFailure.gwt.xml
A user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
A user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
M user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java
8 files changed, 186 insertions(+), 10 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds regression testing against future changes that might ac...

2013-06-26 Thread John Stalcup


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3590

to look at the new patch set (#3).

Change subject: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

..

adds regression testing against future changes that might accidentally push  
all fragment code into the leftover fragment


Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Review-Link: https://gwt-review.googlesource.com/#/c/3590/
---
M user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
M user/test/com/google/gwt/dev/jjs/CompilerSuite.java
A user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
M user/test/com/google/gwt/dev/jjs/RunAsyncFailure.gwt.xml
A user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
A user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
M user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java
8 files changed, 187 insertions(+), 10 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds regression testing against future changes that might ac...

2013-06-26 Thread John Stalcup


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3590

to look at the new patch set (#4).

Change subject: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

..

adds regression testing against future changes that might accidentally push  
all fragment code into the leftover fragment


Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Review-Link: https://gwt-review.googlesource.com/#/c/3590/
---
M user/src/com/google/gwt/core/client/impl/LoadingStrategyBase.java
M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
M user/test/com/google/gwt/dev/jjs/CompilerSuite.java
A user/test/com/google/gwt/dev/jjs/RunAsyncContent.gwt.xml
A user/test/com/google/gwt/dev/jjs/test/LoggingXhrLoadingStrategy.java
A user/test/com/google/gwt/dev/jjs/test/RunAsyncContentTest.java
M user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java
7 files changed, 185 insertions(+), 6 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds regression testing against future changes that might ac...

2013-06-26 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: adds regression testing against future changes that might  
accidentally push all fragment code into the leftover fragment

..


Patch Set 4:

offline you mentioned you'd rather this test be done in it's own dedicated  
test file. i've made that change. PTAL


--
To view, visit https://gwt-review.googlesource.com/3590
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I34d21081ea4e90b95f5b2d77a7a647e388e25335
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-HasComments: No

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds type tightening (and tests) for casts inside of RunAsyn...

2013-06-19 Thread John Stalcup


Hello Roberto Lublinerman, Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3460

to look at the new patch set (#2).

Change subject: adds type tightening (and tests) for casts inside of  
RunAsync onSuccessCalls, resulting in smaller leftover fragments

..

adds type tightening (and tests) for casts inside of RunAsync  
onSuccessCalls, resulting in smaller leftover fragments


Change-Id: I7b454db222da054834aa0d78b1a769100bf9da9b
Review-Link: https://gwt-review.googlesource.com/#/c/3460/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
M dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
2 files changed, 56 insertions(+), 9 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3460
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I7b454db222da054834aa0d78b1a769100bf9da9b
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: replaces stale jProgram runAsync references and fixes JRunAs...

2013-06-19 Thread John Stalcup


John Stalcup has uploaded a new change for review.

  https://gwt-review.googlesource.com/3520


Change subject: replaces stale jProgram runAsync references and fixes  
JRunAsync method inlining to occasionally benefit from tighter types

..

replaces stale jProgram runAsync references and fixes JRunAsync method  
inlining to occasionally benefit from tighter types


Change-Id: I930a31272a5f9b689e8cb68971d7ffb77389488a
---
M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
M dev/core/src/com/google/gwt/dev/jjs/ast/JRunAsync.java
M dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
M dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
A dev/core/src/com/google/gwt/dev/jjs/impl/RunAsyncsTightener.java
7 files changed, 116 insertions(+), 4 deletions(-)



diff --git  
a/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java  
b/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java

index 78fb2ca..ae47527 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
@@ -97,6 +97,7 @@
 import com.google.gwt.dev.jjs.impl.ReplaceGetClassOverrides;
 import com.google.gwt.dev.jjs.impl.ReplaceRunAsyncs;
 import com.google.gwt.dev.jjs.impl.ResolveRebinds;
+import com.google.gwt.dev.jjs.impl.RunAsyncsTightener;
 import com.google.gwt.dev.jjs.impl.SameParameterValueOptimizer;
 import com.google.gwt.dev.jjs.impl.SourceInfoCorrelator;
 import com.google.gwt.dev.jjs.impl.TypeTightener;
@@ -350,6 +351,8 @@
   // prune all Object.getClass() overrides and replace with inline  
field ref

   ReplaceGetClassOverrides.exec(jprogram);

+  RunAsyncsTightener.exec(jprogram);
+
   // (7) Generate a JavaScript code DOM from the Java type declarations
   jprogram.typeOracle.recomputeAfterOptimizations();
   Pair? extends JavaToJavaScriptMap, SetJsNode genAstResult =
diff --git a/dev/core/src/com/google/gwt/dev/jjs/ast/JRunAsync.java  
b/dev/core/src/com/google/gwt/dev/jjs/ast/JRunAsync.java

index 50cd058..9cc0a39 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/ast/JRunAsync.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/ast/JRunAsync.java
@@ -82,6 +82,14 @@
 return true;
   }

+  public void setOnSuccessCall(JExpression onSuccessCall) {
+this.onSuccessCall = onSuccessCall;
+  }
+
+  public void setRunAsyncCall(JExpression runAsyncCall) {
+this.runAsyncCall = runAsyncCall;
+  }
+
   public void traverse(JVisitor visitor, Context ctx) {
 if (visitor.visit(this, ctx)) {
   /*
diff --git  
a/dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java

index d1089da..26c2e15 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java
@@ -227,11 +227,10 @@

   @Override
   public boolean visit(JRunAsync x, Context ctx) {
-// Only the runAsync call itself needs cloning, the onSuccess can be  
shared.

 JExpression runAsyncCall = cloneExpression(x.getRunAsyncCall());
-expression =
-new JRunAsync(x.getSourceInfo(), x.getSplitPoint(), x.getName(),  
runAsyncCall, x

-.getOnSuccessCall());
+JExpression onSuccessCall = cloneExpression(x.getOnSuccessCall());
+expression = new JRunAsync(
+x.getSourceInfo(), x.getSplitPoint(), x.getName(), runAsyncCall,  
onSuccessCall);

 return false;
   }

diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java

index 88cfd1c..3132ef0 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
@@ -30,6 +30,7 @@
 import com.google.gwt.dev.jjs.ast.JParameterRef;
 import com.google.gwt.dev.jjs.ast.JProgram;
 import com.google.gwt.dev.jjs.ast.JReturnStatement;
+import com.google.gwt.dev.jjs.ast.JRunAsync;
 import com.google.gwt.dev.jjs.ast.JStatement;
 import com.google.gwt.dev.jjs.ast.JThisRef;
 import com.google.gwt.dev.jjs.ast.JType;
@@ -113,6 +114,13 @@
   }

   @Override
+  public boolean visit(JRunAsync x, Context ctx) {
+x.setRunAsyncCall(accept(x.getRunAsyncCall()));
+x.setOnSuccessCall(accept(x.getOnSuccessCall()));
+return false;
+  }
+
+  @Override
   public void endVisit(JParameterRef x, Context ctx) {
 JParameter param = varMap.get(x.getTarget());
 JParameterRef paramRef = new JParameterRef(x.getSourceInfo(),  
param);
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java

[gwt-contrib] Change in gwt[master]: adds type tightening (and tests) for casts inside of RunAsyn...

2013-06-19 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: adds type tightening (and tests) for casts inside of  
RunAsync onSuccessCalls, resulting in smaller leftover fragments

..


Patch Set 1:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
Line 631:   return super.visit(x, ctx);
Done


--
To view, visit https://gwt-review.googlesource.com/3460
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I7b454db222da054834aa0d78b1a769100bf9da9b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: replaces stale jProgram runAsync references and fixes JRunAs...

2013-06-19 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: replaces stale jProgram runAsync references and fixes  
JRunAsync method inlining to occasionally benefit from tighter types

..


Patch Set 1:

i'll add a CodeSplitter2Test for this once  
https://gwt-review.googlesource.com/#/c/3460/ is in


--
To view, visit https://gwt-review.googlesource.com/3520
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I930a31272a5f9b689e8cb68971d7ffb77389488a
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-HasComments: No

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: replaces stale jProgram runAsync references and fixes JRunAs...

2013-06-19 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: replaces stale jProgram runAsync references and fixes  
JRunAsync method inlining to occasionally benefit from tighter types

..


Patch Set 1:

addresses part of  
https://code.google.com/p/google-web-toolkit/issues/detail?id=7874


--
To view, visit https://gwt-review.googlesource.com/3520
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I930a31272a5f9b689e8cb68971d7ffb77389488a
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-HasComments: No

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: adds type tightening (and tests) for casts inside of RunAsyn...

2013-06-17 Thread John Stalcup


John Stalcup has uploaded a new change for review.

  https://gwt-review.googlesource.com/3460


Change subject: adds type tightening (and tests) for casts inside of  
RunAsync onSuccessCalls, resulting in smaller leftover fragments

..

adds type tightening (and tests) for casts inside of RunAsync  
onSuccessCalls, resulting in smaller leftover fragments


Change-Id: I7b454db222da054834aa0d78b1a769100bf9da9b
---
M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
M dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
2 files changed, 55 insertions(+), 9 deletions(-)



diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java

index 5ac6ea7..5fb0f82 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
@@ -45,6 +45,7 @@
 import com.google.gwt.dev.jjs.ast.JProgram;
 import com.google.gwt.dev.jjs.ast.JReferenceType;
 import com.google.gwt.dev.jjs.ast.JReturnStatement;
+import com.google.gwt.dev.jjs.ast.JRunAsync;
 import com.google.gwt.dev.jjs.ast.JTryStatement;
 import com.google.gwt.dev.jjs.ast.JType;
 import com.google.gwt.dev.jjs.ast.JTypeOracle;
@@ -625,6 +626,12 @@
 }

 @Override
+public boolean visit(JRunAsync x, Context ctx) {
+  x.traverseOnSuccess(this);
+  return super.visit(x, ctx);
+}
+
+@Override
 public boolean visit(JClassType x, Context ctx) {
   // don't mess with classes used in code gen
   if (program.codeGenTypes.contains(x)) {
diff --git  
a/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java  
b/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java

index 70eaa5e..bc8b1b6 100644
--- a/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
+++ b/dev/core/test/com/google/gwt/dev/jjs/impl/CodeSplitter2Test.java
@@ -83,13 +83,14 @@

   private JProgram jProgram = null;
   private JsProgram jsProgram = null;
-
-  public void setUp() throws Exception{
+
+  @Override
+  public void setUp() throws Exception {
 super.setUp();
 stackMode.addDefinedValue(new ConditionNone(), STRIP);
 jsProgram = new JsProgram();
   }
-
+
   public void testSimple() throws UnableToCompleteException {
 StringBuffer code = new StringBuffer();
 code.append(package test;\n);
@@ -127,6 +128,34 @@

 // functionC must be in the initial fragment.
 assertInFragment(functionC, 0);
+  }
+
+  public void testOnSuccessCallCast() throws UnableToCompleteException {
+StringBuffer code = new StringBuffer();
+code.append(package test;\n);
+code.append(import com.google.gwt.core.client.GWT;\n);
+code.append(import com.google.gwt.core.client.RunAsyncCallback;\n);
+code.append(public class EntryPoint {\n);
+code.append(   + functionA);
+code.append(   + functionB);
+code.append(   + functionC);
+code.append(  public static void onModuleLoad() {\n);
+code.append(functionC(););
+code.append( +  
createRunAsync((RunAsyncCallback), functionA();));
+code.append( +  
createRunAsync((RunAsyncCallback), functionB();));

+code.append(  }\n);
+code.append(}\n);
+compileSnippet(code.toString());
+
+// init + 2 fragments + leftover.
+assertFragmentCount(4);
+
+assertInFragment(functionA, 1);
+assertInFragment(functionB, 2);
+
+// Verify that functionA and B aren't in the leftover.
+assertNotInFragment(functionA, 3);
+assertNotInFragment(functionB, 3);
   }

   public void testMergeLeftOvers() throws UnableToCompleteException {
@@ -292,6 +321,8 @@
 jProgram.addEntryMethod(findMethod(jProgram, onModuleLoad));
 CastNormalizer.exec(jProgram, false);
 ArrayNormalizer.exec(jProgram);
+TypeTightener.exec(jProgram);
+MethodCallTightener.exec(jProgram);
 MapStandardSymbolData, JsName symbolTable =
   new TreeMapStandardSymbolData, JsName(new  
SymbolData.ClassIdentComparator());

 JavaToJavaScriptMap map = GenerateJavaScriptAST.exec(
@@ -332,13 +363,21 @@
 mergeLimit);
   }

-
-  private static String createRunAsync(String body) {
-return GWT.runAsync(new RunAsyncCallback() { +
-   public void onFailure(Throwable reason) {} +
-   public void onSuccess() { + body + }});;
+  private static String createRunAsync(String cast, String body) {
+StringBuffer code = new StringBuffer();
+code.append(GWT.runAsync( + cast + new RunAsyncCallback() {\n);
+code.append(  public void onFailure(Throwable reason) {}\n);
+code.append(  public void onSuccess() {\n);
+code.append( + body);
+code.append(  }\n);
+code.append(});\n);
+return code.toString();
   }
-
+
+  private static String createRunAsync(String body) {
+return createRunAsync(, body);
+  }
+
   /**
* Add some of the compiler intrinsic
*/

--
To view, visit

[gwt-contrib] Change in gwt[master]: adds type tightening (and tests) for casts inside of RunAsyn...

2013-06-17 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: adds type tightening (and tests) for casts inside of  
RunAsync onSuccessCalls, resulting in smaller leftover fragments

..


Patch Set 1:

addresses part of  
https://code.google.com/p/google-web-toolkit/issues/detail?id=7874


--
To view, visit https://gwt-review.googlesource.com/3460
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I7b454db222da054834aa0d78b1a769100bf9da9b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-HasComments: No

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...

2013-06-11 Thread John Stalcup


John Stalcup has submitted this change and it was merged.

Change subject: The job of defineSeed is to mark the existence of a class  
and associate its castMap with the class's various constructors.

..


The job of defineSeed is to mark the existence of a class and associate its  
castMap with the class's various constructors.


FragmentExtractor chooses whether and what part of a defineSeed call to  
include in a fragment.


Previously this logic would only include a defineSeed function in a  
fragment if the fragment was known to make the particular type in  
question live.
In this usage live means that if you have ALL other fragments loaded then  
you can not instantiate this type but the moment you additionally load

this fragment you become able to instantiate this type.

But it is possible that when you have ALL other fragments loaded you can  
already instantiate this type and so when you load this fragment you do not
expand the liveness of this type but you DO suddenly make certain of its  
constructors accessible that were not previously accessible. In this
situation previously logic would still not have included any defineSeed  
function at all and as a consequence these newly live constructors were  
never
getting their associated castMaps which led to runtime errors when casting  
an instance that had been created by one of these broken constructors.


This change relaxes the defineSeed inclusion restriction to include  
fragments that are expanding a type's constructors liveness and not just  
fragments

that expand a type's liveness.

Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Review-Link: https://gwt-review.googlesource.com/#/c/3300/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
M dev/core/src/com/google/gwt/dev/js/ast/JsName.java
M dev/core/src/com/google/gwt/dev/js/ast/JsRootScope.java
A dev/core/test/com/google/gwt/dev/jjs/impl/FragmentExtractorTest.java
4 files changed, 394 insertions(+), 79 deletions(-)

Approvals:
  Roberto Lublinerman: Looks good to me, approved
  Leeroy Jenkins: Verified



diff --git  
a/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java

index 8d75fc9..3a92c17 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
@@ -48,10 +48,25 @@
 import java.util.Set;

 /**
- * A class that extracts a fragment of code based on a supplied liveness
- * condition.
+ * Extracts multiple JS statements (called a fragment) out of the complete  
JS program based on

+ * supplied type/method/field/string liveness conditions.
+ *
+ * p
+ * bLiveness as defined here is not an intuitive concept./b A type or  
method (note that
+ * constructors are methods) is considered live for the current fragment  
when that type can only be
+ * instantiated or method executed when the current fragment has already  
been loaded. That does not
+ * always mean that it was caused by direct execution of the current  
fragment. It may instead mean
+ * that direction execution of some other fragment has been affected by  
the loading of the current
+ * fragment in a way that results in the instantiation of the type or  
execution of the method. It is
+ * this second case that can lead to seemingly contradictory but valid  
situations like having a type
+ * which is not currently live but which has a currently live constructor.  
For example it might be
+ * possible to instantiate type Foo even with fragment Bar being loaded  
(i.e. Foo is not live for
+ * Bar) but the loading of fragment Bar might be required to reach a  
particular one of Bar's

+ * multiple constructor (i.e. that constructor is live for Bar).
+ * /p
  */
 public class FragmentExtractor {
+
   /**
* A {@link LivenessPredicate} that bases liveness on a single
* {@link ControlFlowAnalyzer}.
@@ -63,23 +78,28 @@
   this.cfa = cfa;
 }

+@Override
 public boolean isLive(JDeclaredType type) {
   return cfa.getInstantiatedTypes().contains(type);
 }

+@Override
 public boolean isLive(JField field) {
   return cfa.getLiveFieldsAndMethods().contains(field)
   || cfa.getFieldsWritten().contains(field);
 }

+@Override
 public boolean isLive(JMethod method) {
   return cfa.getLiveFieldsAndMethods().contains(method);
 }

+@Override
 public boolean isLive(String string) {
   return cfa.getLiveStrings().contains(string);
 }

+@Override
 public boolean miscellaneousStatementsAreLive() {
   return true;
 }
@@ -132,38 +152,99 @@
* A {@link LivenessPredicate} where nothing is alive.
*/
   public static class NothingAlivePredicate implements LivenessPredicate {
+@Override
 public boolean isLive(JDeclaredType type) {
   return false;
 }

+@Override
 public

[gwt-contrib] Change in gwt[master]: fixes a compiler crash when parsing illegal runAsync definit...

2013-06-11 Thread John Stalcup


Hello Roberto Lublinerman, Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3320

to look at the new patch set (#2).

Change subject: fixes a compiler crash when parsing illegal runAsync  
definitions

..

fixes a compiler crash when parsing illegal runAsync definitions

Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Review-Link: https://gwt-review.googlesource.com/#/c/3320/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
M  
dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

2 files changed, 35 insertions(+), 2 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3320
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: fixes a compiler crash when parsing illegal runAsync definit...

2013-06-11 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: fixes a compiler crash when parsing illegal runAsync  
definitions

..


Patch Set 2:

tests were passing, but not with enable assertions. added an immediate  
return to avoid sticking a null method into a method ref (which was  
triggering the assertion failure)


--
To view, visit https://gwt-review.googlesource.com/3320
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: No

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: fixes a compiler crash when parsing illegal runAsync definit...

2013-06-11 Thread John Stalcup


John Stalcup has submitted this change and it was merged.

Change subject: fixes a compiler crash when parsing illegal runAsync  
definitions

..


fixes a compiler crash when parsing illegal runAsync definitions

Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Review-Link: https://gwt-review.googlesource.com/#/c/3320/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
M  
dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

2 files changed, 35 insertions(+), 2 deletions(-)

Approvals:
  Roberto Lublinerman: Looks good to me, approved
  Leeroy Jenkins: Verified



diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java

index 2e9222a..2f50843 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
@@ -112,7 +112,11 @@
 } else {
   callbackMethod =  
program.getIndexedMethod(RunAsyncCallback.onSuccess);

 }
-assert callbackMethod != null;
+if (callbackMethod == null) {
+  error(x.getSourceInfo(), Only a RunAsyncCallback with a defined  
onSuccess() can 

+  + be passed to runAsync().);
+  return;
+}
 JMethodCall onSuccessCall = new JMethodCall(info, asyncCallback,  
callbackMethod);


 JRunAsync runAsyncNode = new JRunAsync(info, splitPoint, name,  
runAsyncCall, onSuccessCall);
diff --git  
a/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java  
b/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

index 68044bc..af77749 100644
---  
a/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java
+++  
b/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

@@ -52,18 +52,48 @@
 });

 addSnippetImport(test.SplitPoint3);
+expectError(Errors in 'test/EntryPoint.java');
 expectError(Line 8: Multiple runAsync calls are named  
test.SplitPoint1);

 expectError(One call is at 'test/SplitPoint1.java:5');
 expectError(One call is at 'test/SplitPoint3.java:5');
 testSnippet(RunAsyncCode.runAsyncCode(SplitPoint1.class););
   }

+  public void testMissingOnSuccess() {
+sourceOracle.addOrReplace(new MockJavaResource(test.SplitPoint4) {
+@Override
+  public CharSequence getContent() {
+StringBuffer code = new StringBuffer();
+code.append(package test;\n);
+code.append(import com.google.gwt.core.client.GWT;\n);
+code.append(import  
com.google.gwt.core.client.RunAsyncCallback;\n);

+code.append(public class SplitPoint4 {\n);
+code.append(
+  public abstract class AbstractRunAsyncCallback implements  
RunAsyncCallback {\n);

+code.append(public void run() {\n);
+code.append(  GWT.runAsync(this);\n);
+code.append(}\n);
+code.append(  }\n);
+code.append(}\n);
+return code;
+  }
+});
+
+addSnippetImport(test.SplitPoint4);
+expectError(Errors in 'test/SplitPoint4.java');
+expectError(Line 7: Only a RunAsyncCallback with a defined  
onSuccess() can 

++ be passed to runAsync().);
+testSnippet(new SplitPoint4(););
+  }
+
   public void testNonClassLiteral() {
+expectError(Errors in 'test/EntryPoint.java');
 expectError(Line 7: Only a class literal may be passed to  
runAsyncCode);
 testSnippet(RunAsyncCode.runAsyncCode(new  
SplitPoint1().getClass()););

   }

   public void testNonExistentSplitPoint() {
+expectError(Errors in 'test/EntryPoint.java');
 expectError(Line 7: No runAsync call is named java.lang.String);
 testSnippet(RunAsyncCode.runAsyncCode(String.class););
   }
@@ -111,7 +141,6 @@
   private void initializeTestLoggerBuilder() {
 testLoggerBuilder = new UnitTestTreeLogger.Builder();
 testLoggerBuilder.setLowestLogLevel(TreeLogger.ERROR);
-expectError(Errors in 'test/EntryPoint.java');
   }

   private void testSnippet(String codeSnippet) {

--
To view, visit https://gwt-review.googlesource.com/3320
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com

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

[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...

2013-06-10 Thread John Stalcup


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3300

to look at the new patch set (#3).

Change subject: The job of defineSeed is to mark the existence of a class  
and associate its castMap with the class's various constructors.

..

The job of defineSeed is to mark the existence of a class and associate its  
castMap with the class's various constructors.


FragmentExtractor chooses whether and what part of a defineSeed call to  
include in a fragment.


Previously this logic would only include a defineSeed function in a  
fragment if the fragment was known to make the particular type in  
question live.
In this usage live means that if you have ALL other fragments loaded then  
you can not instantiate this type but the moment you additionally load

this fragment you become able to instantiate this type.

But it is possible that when you have ALL other fragments loaded you can  
already instantiate this type and so when you load this fragment you do not
expand the liveness of this type but you DO suddenly make certain of its  
constructors accessible that were not previously accessible. In this
situation previously logic would still not have included any defineSeed  
function at all and as a consequence these newly live constructors were  
never
getting their associated castMaps which led to runtime errors when casting  
an instance that had been created by one of these broken constructors.


This CL relaxes the defineSeed inclusion restriction to include fragments  
that are expanding a type's constructors liveness and not just fragments

that expand a type's liveness.

Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Review-Link: https://gwt-review.googlesource.com/#/c/3300/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
M dev/core/src/com/google/gwt/dev/js/ast/JsName.java
M dev/core/src/com/google/gwt/dev/js/ast/JsRootScope.java
A dev/core/test/com/google/gwt/dev/jjs/impl/FragmentExtractorTest.java
4 files changed, 394 insertions(+), 80 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3300
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...

2013-06-10 Thread John Stalcup


Hello Roberto Lublinerman, Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3300

to look at the new patch set (#4).

Change subject: The job of defineSeed is to mark the existence of a class  
and associate its castMap with the class's various constructors.

..

The job of defineSeed is to mark the existence of a class and associate its  
castMap with the class's various constructors.


FragmentExtractor chooses whether and what part of a defineSeed call to  
include in a fragment.


Previously this logic would only include a defineSeed function in a  
fragment if the fragment was known to make the particular type in  
question live.
In this usage live means that if you have ALL other fragments loaded then  
you can not instantiate this type but the moment you additionally load

this fragment you become able to instantiate this type.

But it is possible that when you have ALL other fragments loaded you can  
already instantiate this type and so when you load this fragment you do not
expand the liveness of this type but you DO suddenly make certain of its  
constructors accessible that were not previously accessible. In this
situation previously logic would still not have included any defineSeed  
function at all and as a consequence these newly live constructors were  
never
getting their associated castMaps which led to runtime errors when casting  
an instance that had been created by one of these broken constructors.


This change relaxes the defineSeed inclusion restriction to include  
fragments that are expanding a type's constructors liveness and not just  
fragments

that expand a type's liveness.

Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Review-Link: https://gwt-review.googlesource.com/#/c/3300/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
M dev/core/src/com/google/gwt/dev/js/ast/JsName.java
M dev/core/src/com/google/gwt/dev/js/ast/JsRootScope.java
A dev/core/test/com/google/gwt/dev/jjs/impl/FragmentExtractorTest.java
4 files changed, 394 insertions(+), 79 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3300
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...

2013-06-07 Thread John Stalcup


John Stalcup has uploaded a new change for review.

  https://gwt-review.googlesource.com/3300


Change subject: The job of defineSeed is to mark the existence of a class  
and associate its castMap with the class's various constructors.

..

The job of defineSeed is to mark the existence of a class and associate its  
castMap with the class's various constructors.


FragmentExtractor chooses whether and what part of a defineSeed call to  
include in a fragment.


Previously this logic would only include a defineSeed function in a  
fragment if the fragment was known to make the particular type in  
question live.
In this usage live means that if you have ALL other fragments loaded then  
you can not instantiate this type but the moment you additionally load

this fragment you become able to instantiate this type.

But it is possible that when you have ALL other fragments loaded you can  
already instantiate this type and so when you load this fragment you do not
expand the liveness of this type but you DO suddenly make certain of its  
constructors accessible that were not previously accessible. In this
situation previously logic would still not have included any defineSeed  
function at all and as a consequence these newly live constructors were  
never
getting their associated castMaps which led to runtime errors when casting  
an instance that had been created by one of these broken constructors.


This CL relaxes the defineSeed inclusion restriction to include fragments  
that are expanding a type's constructors liveness and not just fragments

that expand a type's liveness.

Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
---
M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
M dev/core/src/com/google/gwt/dev/js/ast/JsName.java
M dev/core/src/com/google/gwt/dev/js/ast/JsRootScope.java
A dev/core/test/com/google/gwt/dev/jjs/impl/FragmentExtractorTest.java
4 files changed, 332 insertions(+), 80 deletions(-)



diff --git  
a/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java

index 8d75fc9..d77b7d2 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
@@ -15,6 +15,7 @@
  */
 package com.google.gwt.dev.jjs.impl;

+import com.google.gwt.core.client.impl.AsyncFragmentLoader;
 import com.google.gwt.dev.jjs.SourceInfo;
 import com.google.gwt.dev.jjs.ast.JClassType;
 import com.google.gwt.dev.jjs.ast.JConstructor;
@@ -48,10 +49,25 @@
 import java.util.Set;

 /**
- * A class that extracts a fragment of code based on a supplied liveness
- * condition.
+ * Extracts multiple JS statements (called a fragment) out of the complete  
JS program based on

+ * supplied type/method/field/string liveness conditions.
+ *
+ * p
+ * bLiveness as defined here is not an intuitive concept./b A type or  
method (note that
+ * constructors are methods) is considered live for the current fragment  
when that type can only be
+ * instantiated or method executed when the current fragment has already  
been loaded. That does not
+ * always mean that it was caused by direct execution of the current  
fragment. It may instead mean
+ * that direction execution of some other fragment has been affected by  
the loading of the current
+ * fragment in a way that results in the instantiation of the type or  
execution of the method. It is
+ * this second case that can lead to seemingly contradictory but valid  
situations like having a type
+ * which is not currently live but which has a currently live constructor.  
For example it might be
+ * possible to instantiate type Foo even with fragment Bar being loaded  
(i.e. Foo is not live for
+ * Bar) but the loading of fragment Bar might be required to reach a  
particular one of Bar's

+ * multiple constructor (i.e. that constructor is live for Bar).
+ * /p
  */
 public class FragmentExtractor {
+
   /**
* A {@link LivenessPredicate} that bases liveness on a single
* {@link ControlFlowAnalyzer}.
@@ -63,23 +79,28 @@
   this.cfa = cfa;
 }

+@Override
 public boolean isLive(JDeclaredType type) {
   return cfa.getInstantiatedTypes().contains(type);
 }

+@Override
 public boolean isLive(JField field) {
   return cfa.getLiveFieldsAndMethods().contains(field)
   || cfa.getFieldsWritten().contains(field);
 }

+@Override
 public boolean isLive(JMethod method) {
   return cfa.getLiveFieldsAndMethods().contains(method);
 }

+@Override
 public boolean isLive(String string) {
   return cfa.getLiveStrings().contains(string);
 }

+@Override
 public boolean miscellaneousStatementsAreLive() {
   return true;
 }
@@ -132,38 +153,99 @@
* A {@link LivenessPredicate} where nothing is alive.
*/
   public static class NothingAlivePredicate

[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...

2013-06-07 Thread John Stalcup


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3300

to look at the new patch set (#2).

Change subject: The job of defineSeed is to mark the existence of a class  
and associate its castMap with the class's various constructors.

..

The job of defineSeed is to mark the existence of a class and associate its  
castMap with the class's various constructors.


FragmentExtractor chooses whether and what part of a defineSeed call to  
include in a fragment.


Previously this logic would only include a defineSeed function in a  
fragment if the fragment was known to make the particular type in  
question live.
In this usage live means that if you have ALL other fragments loaded then  
you can not instantiate this type but the moment you additionally load

this fragment you become able to instantiate this type.

But it is possible that when you have ALL other fragments loaded you can  
already instantiate this type and so when you load this fragment you do not
expand the liveness of this type but you DO suddenly make certain of its  
constructors accessible that were not previously accessible. In this
situation previously logic would still not have included any defineSeed  
function at all and as a consequence these newly live constructors were  
never
getting their associated castMaps which led to runtime errors when casting  
an instance that had been created by one of these broken constructors.


This CL relaxes the defineSeed inclusion restriction to include fragments  
that are expanding a type's constructors liveness and not just fragments

that expand a type's liveness.

Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Review-Link: https://gwt-review.googlesource.com/#/c/3300/
---
M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
M dev/core/src/com/google/gwt/dev/js/ast/JsName.java
M dev/core/src/com/google/gwt/dev/js/ast/JsRootScope.java
A dev/core/test/com/google/gwt/dev/jjs/impl/FragmentExtractorTest.java
4 files changed, 331 insertions(+), 80 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3300
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: The job of defineSeed is to mark the existence of a class an...

2013-06-07 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: The job of defineSeed is to mark the existence of a class  
and associate its castMap with the class's various constructors.

..


Patch Set 2:

yes this is in response to  
https://code.google.com/p/google-web-toolkit/issues/detail?id=7392


--
To view, visit https://gwt-review.googlesource.com/3300
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Idc87430b94338d289eae4760a1bef8ad127bd699
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-HasComments: No

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: fixes a compiler crash when parsing illegal runAsync definit...

2013-06-07 Thread John Stalcup


John Stalcup has uploaded a new change for review.

  https://gwt-review.googlesource.com/3320


Change subject: fixes a compiler crash when parsing illegal runAsync  
definitions

..

fixes a compiler crash when parsing illegal runAsync definitions

Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
---
M dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
M  
dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

2 files changed, 34 insertions(+), 2 deletions(-)



diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java

index 2e9222a..983c972 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
@@ -112,7 +112,10 @@
 } else {
   callbackMethod =  
program.getIndexedMethod(RunAsyncCallback.onSuccess);

 }
-assert callbackMethod != null;
+if (callbackMethod == null) {
+  error(x.getSourceInfo(), Only a RunAsyncCallback with a defined  
onSuccess() can 

+  + be passed to runAsync().);
+}
 JMethodCall onSuccessCall = new JMethodCall(info, asyncCallback,  
callbackMethod);


 JRunAsync runAsyncNode = new JRunAsync(info, splitPoint, name,  
runAsyncCall, onSuccessCall);
diff --git  
a/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java  
b/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

index 68044bc..af77749 100644
---  
a/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java
+++  
b/dev/core/test/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncsErrorMessagesTest.java

@@ -52,18 +52,48 @@
 });

 addSnippetImport(test.SplitPoint3);
+expectError(Errors in 'test/EntryPoint.java');
 expectError(Line 8: Multiple runAsync calls are named  
test.SplitPoint1);

 expectError(One call is at 'test/SplitPoint1.java:5');
 expectError(One call is at 'test/SplitPoint3.java:5');
 testSnippet(RunAsyncCode.runAsyncCode(SplitPoint1.class););
   }

+  public void testMissingOnSuccess() {
+sourceOracle.addOrReplace(new MockJavaResource(test.SplitPoint4) {
+@Override
+  public CharSequence getContent() {
+StringBuffer code = new StringBuffer();
+code.append(package test;\n);
+code.append(import com.google.gwt.core.client.GWT;\n);
+code.append(import  
com.google.gwt.core.client.RunAsyncCallback;\n);

+code.append(public class SplitPoint4 {\n);
+code.append(
+  public abstract class AbstractRunAsyncCallback implements  
RunAsyncCallback {\n);

+code.append(public void run() {\n);
+code.append(  GWT.runAsync(this);\n);
+code.append(}\n);
+code.append(  }\n);
+code.append(}\n);
+return code;
+  }
+});
+
+addSnippetImport(test.SplitPoint4);
+expectError(Errors in 'test/SplitPoint4.java');
+expectError(Line 7: Only a RunAsyncCallback with a defined  
onSuccess() can 

++ be passed to runAsync().);
+testSnippet(new SplitPoint4(););
+  }
+
   public void testNonClassLiteral() {
+expectError(Errors in 'test/EntryPoint.java');
 expectError(Line 7: Only a class literal may be passed to  
runAsyncCode);
 testSnippet(RunAsyncCode.runAsyncCode(new  
SplitPoint1().getClass()););

   }

   public void testNonExistentSplitPoint() {
+expectError(Errors in 'test/EntryPoint.java');
 expectError(Line 7: No runAsync call is named java.lang.String);
 testSnippet(RunAsyncCode.runAsyncCode(String.class););
   }
@@ -111,7 +141,6 @@
   private void initializeTestLoggerBuilder() {
 testLoggerBuilder = new UnitTestTreeLogger.Builder();
 testLoggerBuilder.setLowestLogLevel(TreeLogger.ERROR);
-expectError(Errors in 'test/EntryPoint.java');
   }

   private void testSnippet(String codeSnippet) {

--
To view, visit https://gwt-review.googlesource.com/3320
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com

--
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: fixes a compiler crash when parsing illegal runAsync definit...

2013-06-07 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: fixes a compiler crash when parsing illegal runAsync  
definitions

..


Patch Set 1:

see https://code.google.com/p/google-web-toolkit/issues/detail?id=6739

--
To view, visit https://gwt-review.googlesource.com/3320
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I3d3feb378a9595e1c3be091b2adf033df9ccae39
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-HasComments: No

--
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/groups/opt_out.

Re: [gwt-contrib] GWT Coding Style Update

2013-05-30 Thread John Stalcup

I'm a big fan of enforcement of static/non-static + alphabetical ordering,
as it stays consistent over time and can be automatically performed by
IDEs. I made it the rule in my last team.

I wish we were actually enforcing the GWT-SDK style rules!


On Thu, May 30, 2013 at 6:22 PM, Goktug Gokdogan gok...@google.com wrote:

 Hi folks.

 We currently have a coding style guide for GWT-SDK here:
   https://developers.google.com/web-toolkit/makinggwtbetter#codestyle
 The guide has some enforcements like static/non-static + alphabetical
 ordering. Alphabetical ordering is as good as no ordering in many cases and
 these rules are already broken in many places.

 I propose following Guava and many other java libs and just enforce
 logical ordering during code reviews (which is also internal recommendation
 at Google). One good approach for logical order is to group related public
 APIs and then slot in other methods and nested-classes to keep them close
 to the related context. This usually helps to follow the code with less
 jumps around the class.

 Anyway, I know this can quickly turn into a bikeshed discussion so please
 try to resist the urge to oppose unless you have a big concern =)

 Cheers!

 --
 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/groups/opt_out.




-- 
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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Make sub/superclass queries in JTypeOracle more efficient.

2013-05-14 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: Make sub/superclass queries in JTypeOracle  more efficient.
..


Patch Set 4: Code-Review+1

(8 comments)

seems like it would be nice to have a test to show that deserialized type  
oracles do recalculate these class hierarchy ids



File dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
Line 307:   private int declaredTypesSize;
declaredTypesCount


Line 706:
superflous multiple blank lines


Line 1042:
superflous blank line


Line 1045:* Compute class ids for efficient lookups.
for efficient subtype checking


Line 1058:   private transient int lastClassId = -1;
we already have seedIds, queryIds, and now classIds in the compiler.

the comments you have here are good but maybe we could make the classId  
name more specific as well to reduce ambiguity



Line 1061:   boolean isSubtype(JClassType sub, JClassType sup) {
can this be private?


Line 1072: maxDescendants = new int[declaredTypesSize];
both the words descendants and subclasses are being used in this  
change. maybe only one or the other should be used



Line 1077:   private void computeIdTraversal(JClassType type) {
s/computeIdTraversal/computeIdForClass


--
To view, visit https://gwt-review.googlesource.com/2701
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibe256bc07834b1518a9e90872fdd655e3e242790
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit 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/groups/opt_out.

[gwt-contrib] Change in gwt[master]: makes GWT boolean flags togglable

2013-05-14 Thread John Stalcup


John Stalcup has posted comments on this change.

Change subject: makes GWT boolean flags togglable
..


Patch Set 1:

yeah i was hesitant to change public class names since it would introduce  
the danger of breaking some external code


i'll defer that change to a later CL

--
To view, visit https://gwt-review.googlesource.com/2682
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I5eee53b0b50fde31f3e750ad85c3e089a52fcbab
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Stalcup stal...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: John Stalcup stal...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@gmail.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit 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/groups/opt_out.

1 2 >

1 - 100 of 104 matches

Mail list logo