from:"John"

Re: [ANN] (Unofficial) Elemental2 2.24 release

2019-06-12 Thread John Huss



> On Wed, Jun 12, 2019 at 8:29 AM Peter Donald  > wrote:
>
>> On Wed, Jun 12, 2019 at 7:31 AM John Huss > > wrote:
>>
>>> Out of curiosity, how did you get this project to build successfully? 
>>>
>>> When I try to build it I see this:
>>>
>>> $ ./bazel_build_test.sh 
>>>
>>> *ERROR: */Users/john/repos/elemental2/third_party/BUILD:21:1: no such 
>>> target '@com_google_javascript_closure_compiler//:externs': target 
>>> 'externs' not declared in package '' defined by 
>>> /private/var/tmp/_bazel_john/b729f51825638d22c4a92cfea6e4556d/external/com_google_javascript_closure_compiler/BUILD
>>>  
>>> and referenced by '//third_party:es6_collections'
>>>
>>>
>>>
>> My guess is that you need to do something like this
>>
>> bazel clean --expunge
>>  
>> This will remove all downloaded repositories (i.e. the closure-compiler 
>> source code as well as the other remote dependencies) and rebuild them. I 
>> believe after that it should build cleanly.
>>
>
> That said I just ran this and it seems to be running against the last 
> binary release of closure compiler ... not the current git repository ... 
> which will not produce the same jar as I generated as the closure externs 
> are outdated. I will need to poke around to figure out how to work arouns 
> this.
>

That worked, thanks! 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/5b43869e-8228-4649-a98b-8adab3bbe074%40googlegroups.com.

Re: [ANN] (Unofficial) Elemental2 2.24 release

2019-06-11 Thread John Huss

Out of curiosity, how did you get this project to build successfully? 

When I try to build it I see this:

$ ./bazel_build_test.sh 

*ERROR: */Users/john/repos/elemental2/third_party/BUILD:21:1: no such 
target '@com_google_javascript_closure_compiler//:externs': target 
'externs' not declared in package '' defined by 
/private/var/tmp/_bazel_john/b729f51825638d22c4a92cfea6e4556d/external/com_google_javascript_closure_compiler/BUILD
 
and referenced by '//third_party:es6_collections'


On Sunday, June 2, 2019 at 8:56:47 PM UTC-5, Peter Donald wrote:
>
> Elemental2 provides type checked access to browser APIs for Java
> code. This is done by using closure extern files and generating
> JsTypes, which are part of the new JsInterop specification that
> is implemented in both GWT and J2CL.
>
> https://github.com/google/elemental2
>
> This is an unofficial release to Maven Central under a different groupId.
> Please don't bug the original authors. Versions are released on demand.
>
> API Changes relative to Elemental2 version 2.23
>
> elemental2-core:
>   API Differences: 
> https://jsinterop.github.io/api-diff/?key=elemental2-core=2.23=2.24
>   - 39 non breaking changes.
>   - 19 potentially breaking changes.
>   - 49 breaking changes.
> elemental2-dom:
>   API Differences: 
> https://jsinterop.github.io/api-diff/?key=elemental2-dom=2.23=2.24
>   - 85 non breaking changes.
>   - 68 potentially breaking changes.
>   - 165 breaking changes.
> elemental2-indexeddb:
>   API Differences: 
> https://jsinterop.github.io/api-diff/?key=elemental2-indexeddb=2.23=2.24
>   - 1 non breaking changes.
> elemental2-svg:
>   API Differences: 
> https://jsinterop.github.io/api-diff/?key=elemental2-svg=2.23=2.24
>   - 1 breaking changes.
> elemental2-webassembly:
>   API Differences: 
> https://jsinterop.github.io/api-diff/?key=elemental2-webassembly=2.23=2.24
>   - 1 potentially breaking changes.
>
> The complete set of Elemental2 API differences is available at
>
>   https://jsinterop.github.io/api-diff/?key=elemental2=2.23=2.24
>
> The Maven dependencies can be added to your pom.xml via
>
> 
>   org.realityforge.com.google.elemental2
>   ${artifact-id}
>   2.24
> 
>
> where artifact-id is one of
>
> * elemental2-core
> * elemental2-dom
> * elemental2-promise
> * elemental2-indexeddb
> * elemental2-svg
> * elemental2-webgl
> * elemental2-media
> * elemental2-webstorage
> * elemental2-webassembly
>
> Hope this helps,
>
> Peter Donald
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/a7ddd14d-d72d-4f45-ab43-cecb13c267a0%40googlegroups.com.

[gwt-contrib] Re: Happy to announce general access for J2CL!

2018-11-29 Thread John Huss

Is there an example bazel WORKSPACE and BUILD file that pulls in 
elemental2?  I tried for a good while to figure out how to add it and 
didn't get anywhere.  The instructions on the project page seems out of 
date: https://github.com/google/elemental2

Thanks,
John

On Tuesday, November 13, 2018 at 7:39:13 PM UTC-6, Goktug Gokdogan wrote:
>
>
>
> -- Forwarded message -
> From: Goktug Gokdogan >
> Date: Tue, Nov 13, 2018 at 5:38 PM
> Subject: Happy to announce general access for J2CL!
> To: >
>
>
> Dear GWTers!
>
> We are happy to announce that we have opened up J2CL repository for 
> general access:
> http://github.com/google/j2cl
>
> Please see the README for details and instructions.
>
> I also would like to use this opportunity to thank all Googlers who 
> contributed over the years and made this happen.
>
> Enjoy!
>
> Goktug, on behalf of J2CL team
>
> PS: If you are using Windows, you might have a bumpy road but should get 
> better over time with your feedback and contributions.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/0dde7fef-9080-4f3f-bdc8-271c681a474d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: application compiles in 2.8 but does not run

2017-10-02 Thread John Malpas

I figured it out. The entry point class extended another class that 
implemented EntryPoint, but did not explicitly say that it implemented 
EntryPoint. This works fine in 2.6 but not in 2.8.

On Sunday, October 1, 2017 at 9:16:55 PM UTC-7, John Malpas wrote:
>
> I have a fairy complex web application (What Grows Here) with maps etc 
> that has been out for few years.
>
> I have been compiling it in GWT 2.6. It compiles and runs just fine in 2.6.
> This week I have been trying to move a bunch of GWT apps to 2.8.
> This one application compiles quietly in 2.8, but the sizes of all of the 
> output files are much smaller than the output files produced by 2.6.
> When I try to run it, nothing happens. I have deliberately simplified 
> onModuleLoad() so that all that happens is an alert with a message,
> but it will not even do that.
>
> Something is going wrong in the compile. I have compiled it with -logLevel 
> TRACE, and compared the TRACE log with the TRACE produced by a 2.6 compile.
> The two TRACE logs are very similar, until the very end, when it starts 
> saying things like
> Adding '16' generated units
>
> In the 2.8 log, the counts of generated units are lower than in the 2.6 
> log, and the sizes of the 2.8 output files are
> much smaller than the sizes of the 2.6 files.
>
> Has anyone else encountered this behavior? What should I be looking for in 
> the TRACE log for a clue
> as to why the compile succeeds, but produces nonsense output?
>
> Thank you.
>

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

application compiles in 2.8 but does not run

2017-10-01 Thread John Malpas

I have a fairy complex web application (What Grows Here) with maps etc that 
has been out for few years.

I have been compiling it in GWT 2.6. It compiles and runs just fine in 2.6.
This week I have been trying to move a bunch of GWT apps to 2.8.
This one application compiles quietly in 2.8, but the sizes of all of the 
output files are much smaller than the output files produced by 2.6.
When I try to run it, nothing happens. I have deliberately simplified 
onModuleLoad() so that all that happens is an alert with a message,
but it will not even do that.

Something is going wrong in the compile. I have compiled it with -logLevel 
TRACE, and compared the TRACE log with the TRACE produced by a 2.6 compile.
The two TRACE logs are very similar, until the very end, when it starts 
saying things like
Adding '16' generated units

In the 2.8 log, the counts of generated units are lower than in the 2.6 
log, and the sizes of the 2.8 output files are
much smaller than the sizes of the 2.6 files.

Has anyone else encountered this behavior? What should I be looking for in 
the TRACE log for a clue
as to why the compile succeeds, but produces nonsense output?

Thank you.

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

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-24 Thread John A. Tamplin

On Wed, May 24, 2017 at 1:14 AM, Learner Evermore <
learner.everm...@gmail.com> wrote:

> ... continuing the above - there is more. Let's now come back to the
> analysis part. Yes, it is possible to do the "whole-world analysis" outside
> the compiler. But what perspective should the analysis take? It is
> irrelevant if it cannot reduce the number of possible classes - we don't
> want all of Java runtime library in there, for example. We need to discover
> which parts are needed from the code that *could* be executed. GWT
> determines this based on entry points and other configuration in the
> *.gwt.xml files **and** what it finds in the compilation classpath, as
> configured, including its own version of the standard library. So, the
> pre-compilation analysis tool would have to configured exactly the same and
> process exactly the same configuration as the GWT compilation step. This
> would have to evolve in lockstep with GWT. It would also be doing the same
> processing and analysis that GWT already has to do - at least the step of
> deciding which bits of code to convert to JavaScript before any further
> optimization.
>

My point is simply if the Java->JS compiler is moving to separate
compilation, having hooks in it cannot help you if the things you want
require whole-world analysis.  If the reachability analysis is done at a
later "linking" stage, then clearly that cannot be available at the
compilation stage.

So I think what you want is fundamentally incompatible with the separate
compilation direction.  That means that either GWT3 is not for you or you
will have to build an external tool that basically does much of what the
existing GWT compiler does now to get what you want.

-- 
John A. Tamplin

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CAM5k6X-4sYX9-_rYTsQhB%2B1O%2Bc44iKyeJTGO84f7rakCmBkitQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread John A. Tamplin

On Tue, May 23, 2017 at 8:24 PM, Learner Evermore <
learner.everm...@gmail.com> wrote:

> And again, I for one, am not calling for GWT RPC to be resurrected in 3.0.
> I don't need it. But I do need the complete serialization instead of the
> half-baked, mostly-incapable external frameworks
> needing-a-ton-of-extra-code-and-still-can't-do-it in existence today. And
> I can even code that to work much faster than GWT RPC did (I do stuff like
> that all the time) but it isn't possible without dedicated hooks within
> J2CL.
>

Why is that so?  Can't you do your own whole-world analysis pass
independently of the compiler if that is what you want to do?  It does not
seem possible to have whole-world analysis in the compiler (hooks or not)
if the goal is to enable separate compilation at the Java layer.  So, if
that is important to you, it must necessarily be outside the compiler.

-- 
John A. Tamplin

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CAM5k6X8PsyPWaL3hHFjbMq5Xgve-7up6QWwX3xbr1jrVMWqhoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

2017-02-15 Thread John Huss

I agree about preferring "bean" style properties.  It's not a clear choice, 
but using bean style properties is more familiar to java programmers and 
makes the library fit in much better with the wider java ecosystem.  Also 
it would make conversions from elemental 1 much easier (though that is 
probably a very small group of users).

On Wednesday, February 15, 2017 at 3:05:01 PM UTC-6, Ming-Yee Iu wrote:
>
> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java 
> fields is the best choice. Sure, it "feels" more like the original 
> JavaScript, but a) it's inconsistent with Java semantics, b) I'd be afraid 
> that a Java compiler might apply some unexpected optimization there as a 
> result, c) it's harder to mock the behavior of the classes for unit tests 
> and d) alternate implementations of Elemental2 aren't possible (for 
> example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I 
> did with Elemental 1).
>
> 2. Personally, I would prefer if Elemental 2 used interfaces over classes 
> (for similar reason as above), though I understand that being able to use 
> "new ...()" syntax on things is nice too.
>
> 3. The number of callback classes is out-of-control. Can they be 
> consolidated somehow? 
>
> 4. Also, is it possible to supplement the typing information for some of 
> those callbacks from Typescript? Everyone knows that "onclick" handlers 
> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or 
> is sufficiently well-developed to generate the best API there.
>
> 5. Can there be some magic that makes elemental2.Iterable a real Java 
> Iterable?
>
> Otherwise, it seems nice. I like that there's a NodeList now!
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/10a89130-7d9a-4f48-8ab8-3387eefcab49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Experimental release of Elemental2

2017-02-02 Thread John Huss

I tried this out by converting a small project that was using elemental 1 
to elemental 2.  I was able to get it to compile both in dev mode and in a 
production compile.  But my event listeners weren't firing at all when I 
ran it.

Some feedback:

1) Lambda event listeners have to be cast into order to avoid an error from 
"javac": 

[javac] /Users/john/.../src/com/App.java:208: error: reference to 
addEventListener is ambiguous

[javac] doc.getElementById("list").addEventListener("click", event -> 
listPressed(event));

[javac]^

[javac]   both method 
addEventListener(String,AddEventListenerListenerCallback) in Node and 
method addEventListener(String,EventListener) in Node match

You can avoid this error with an explicit cast to EventListener (or 
AddEventListenerListenerCallback), but that isn't ideal: 

.addEventListener("click", (EventListener)event -> listPressed(event));

2) Some things weren't defined on HTMLElement that I needed, namely: 
"outerHTML" and "children". These were available in elemental 1. They can 
be added by extending the class like so and casting to it:

@JsType(isNative = true, namespace = JsPackage.GLOBAL)

public class HTMLElementEx extends HTMLElement {

 public String outerHTML;

public HTMLCollection children;

}


On Wednesday, June 29, 2016 at 7:23:51 PM UTC-5, Julien Dramaix wrote:
>
> A new experimental version of Elemental2 using the new JsInterop 
> specification has been pushed on Sonatype today.
>
> You can try it by downloading the jar file 
> <https://oss.sonatype.org/service/local/repositories/google-releases/content/com/google/gwt/elemental2-experimental/16-06-30/elemental2-experimental-16-06-30.jar>
>  
> or adding this following maven dependency:
>
> 
>
>  com.google.gwt
>
>  elemental2-experimental
>
>  16-06-30
>
> 
>
> Then, inherits the elemental2 module:
>
> 
>
> This experimental version works only with the last 2.8-snapshot release of 
> GWT.
>
> The goal of this release is to get feedback so don’t hesitate to report 
> any bugs, issues, concerns you have on this mailing list.
>
>
> Important note: This is an experimental release and without doubt the 
> future updates until the final release are going to break code!  
>
> - 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/d4cb6c43-cd40-494d-88eb-2aa786a18b6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/8d688945-563f-4c4e-befa-d31909deb0dc%40googlegroups.com?utm_medium=email_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/CAFw3gJ94yvCWawT1Hvf-9VV%2BNr4z2_6ofSTrZ_ButhekBmrwBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

non-updatable widget

2016-02-12 Thread John Harrison

I'm new to GWT and working with legacy code (GWT 2.4) I am trying to update 
the value of a textarea using setValue  via a valueChangeHandler, but the 
textArea seem to be updated when I look in debug but not refreshing on 
screen, I have tried removing the textArea from the view but this also 
doesn't seem to update the screen,Does anyone have any pointers please

John

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

[gwt-contrib] Error compiling with trunk and guava-gwt-18.0.jar

2015-11-20 Thread John Huss

I built GWT trunk locally today and I'm trying to compile my app that uses 
Java 8 lambdas along with guava-gwt-18.0,jar.  When I compile I get an 
error thrown because of guava:

 [java]Tracing compile failure path for type 
'com.google.common.collect.GwtPlatform'

 [java]   [ERROR] Errors in 
'jar:file:/Users/john/repos/styleware-net/Salondata/lib/guava-gwt-18.0.jar!/com/google/common/collect/super/com/google/common/collect/GwtPlatform.java'

 [java]  [ERROR] Line 38: *The method createFrom(T[], int) is 
undefined for the type Array*

 [java][ERROR] Aborting compile due to errors in some input files

 [java] Java Result: 1



For reference, this previously DID compile with an older version of GWT 
that I built in late January.


Thanks,

John

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/77dd538c-88c7-4cb7-906e-93c90c0da024%40googlegroups.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 2.7.0 is here

2015-08-20 Thread John Malpas

Hello, 


 I'm repsonsible for @ 50 GWT web apps. I develop
on Windows 7 on a command line, and the apps run
on a commercial Linux server.
Last month (July 2015) I switched from 2.6 to 2.7.
I small thing I noticed right away was that the deliverable file
sizes for 2.7 were uniformly slightly bigger, between 2 and 5%.
But the problem I'm having with 2.7 is when I put out
a newer version of a web app that has already been
loaded into a users' browser.

On the server, the update times for all relevant files (.html, .css, 
.js etc.) are set to one week. So if there is a new version of a
web app, users will typically get it within a week. For users who
ask for the latest version right away, I would tell them to 
force refresh the browser page.For 2.6 and earlier, this worked reliably 
on all browsers I tested (IE Firefox and Chrome on Windows, Firefox
and Chrome on Mac, Chrome on Android). With 2.7, it works sometimes,
but there have been several occasions where I asked the user to
refresh to get the latest version, they did, and they ended up with a dead 
page.
In other words, the GWT javascript page of the page did not load at all.
Faced with that, I have to tell users to delete their browsing history, and
try again (-- I never had to resort to that extreme step before 2.7).

Faced with that, I decided to go back to 2.6 today, and the problem 
completely
went away. I asked the same users who ended up with dead pages from the 2.7
version to refresh again to the just published 2.6 version, and the app 
worked
right away, no problem.

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

Re: [gwt-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 and Bazel

2015-04-03 Thread John A. Tamplin

On Fri, Apr 3, 2015 at 6:00 PM, Erik Kuefler ekuef...@gmail.com wrote:

 Is Google planning on releasing GWT rules for Bazel http://bazel.io/
 any time soon, or is there anyone external who's working on putting
 together some general-purpose rules? I've hacked together a couple for my
 use cases that might be reasonable starting points if not, though there's
 still a lot that would need to be cleaned up for them to work more
 generally.


I'm not sure why they didn't release them, since their are certainly BUILD
rules in Google's internal system for GWT.  Maybe they will come in a later
update.

-- 
John A. Tamplin

-- 
You received this message because you are subscribed to the Google Groups GWT 
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/CAM5k6X81MFP9mQ3ZJ%2BYg07%2BvkSrr2C3t3tqoVGntqMYrr9Zvqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java8 emulation

2015-03-25 Thread John A. Tamplin

On Wed, Mar 25, 2015 at 11:33 AM, Colin Alworth niloc...@gmail.com wrote:

The trick seems to be that it is not going to be possible to add Java8
emul code without actually using Java8 - while lambdas can be avoided,
defender methods cannot. If you need to provide a new interface like
Consumer, the supersource *must* have the `default` method(s), or it won't
actually be Consumer.

If it were just those types, it would be possible to move them into their
own module so developers would need to inherit's the Java8 module to get
access to them, but the Collection interface itself needs to be changed to
add `default StreamE stream()`, plus the implementation, or else all
implementors of Collection (and Set and List) need to have an
implementation added. Even then, Stream would need to be emulated, which
references Consumer, so we can't have it be a separate module...

...or am I over-complicating matters?

Well, certainly there are things which will require further support in GWT
and in the build, but things like adding j.u.Optional can be done without
that.

--
John A. Tamplin

--
You received this message because you are subscribed to the Google Groups GWT
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/CAM5k6X_k%2BwvoH_a_YquYcxY-uzbL%3DdANNn5eGZZJUombafbKBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java8 emulation

2015-03-25 Thread John A. Tamplin

On Wed, Mar 25, 2015 at 11:16 AM, Jens jens.nehlme...@gmail.com wrote:

 whats the current situation of adding Java8 emulations to GWT?

 I would like to fix the current emulation of @FunctionalInterface (wrong
 package and missing imports), add java.util.Optional[Int|Long|Double]
 emulation and like to see java.util.function interfaces in trunk committed.
 That would allow us to further work on stream API emulation which would be
 nice to have in GWT 2.8, right? Just having Java8 syntax support seems a
 little weak to me for a new release.


Adding new classes should be pretty straightforward.


 Currently my patch for java.util.function can not be verified by Jenkins
 because it runs the presubmit task with sourceLevel 1.7 (and Java7 I
 think). So I assume that the next GWT release should be compatible to
 Java7.

 Does this mean that any emulation of Java8 APIs should be done using Java7
 syntax ( = no lambdas in emulation code) ? What about default methods in
 emulated code when people use JDK 7 with GWT?


That would be my vote - we don't want to force people to use Java8 just yet.

-- 
John A. Tamplin

-- 
You received this message because you are subscribed to the Google Groups GWT 
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/CAM5k6X-xtnTX_xXPPr4M9AsFP_qNQHZU_9k_VJP5o4ZjLYknWw%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: ClassCastException when trying SuperDevMode on my application with 2.7

2014-11-22 Thread 'John Stalcup' via Google Web Toolkit

It sounds like one of the registered EntryPoint classes or something that
one of the EntryPoint classes is being rebound to does not implement the
EntryPoint interface.

On Sat, Nov 22, 2014, 1:29 AM Thomas Broyer t.bro...@gmail.com wrote:

 +cc stalcup@

 Any idea John?

 Roland, can you make a small repro-case?

 On Saturday, November 22, 2014 12:38:16 AM UTC+1, Roland wrote:

 With the advent of 2.7 I am determined to get going with SuperDevMode.
 However, once my development environment (Eclipse) is all set to run the
 code server when I try to load my application using SuperDevMode I get the
 following error. This actually happens whether I compile with debug mode on
 or debug mode off when loading the code this way. I don't know what piece
 of the tool chain is reporting the error, but this shows up in my
 JavaScript console.

 Uncaught java.lang.ClassCastExceptionCast.java:59

 dynamicCast_0_g$ gov_00046noaa_00046pmel_
 00046tmap_00046las_00046UI__EntryMethodHolder.java:3

 init_2_g$ModuleUtils.java:44

 initializeModules_0_g$   Impl.java:247

 apply_1_g$   Impl.java:306

 entry0_0_g$  Impl.java:72

 (anonymous function) ModuleUtils.java:55

 gwtOnLoad_0_g$   PeriodPrinter.java:40
 (anonymous function)

 This happens both when I try Firefox 33.0 and Chrome Version
 39.0.2171.65 (64-bit) as the browser. The application runs fine as a
 production app if I compile it and deploy it to the server from the command
 line. I could also debug it using Classic Development Mode using FF 24 just
 prior to now when I was using GWT 2.5. I run in MyEclipse 2015 on Ubuntu
 14.04 if that makes a difference.

 If this is a problem with the framework and not my application I'm happy
 to help try to gather the information to get it fixed, but I would need
 some guidance for how to gather the details needed to debug.

 Thanks,

 Roland



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

Re: [gwt-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

Re: Petition for a standalone Chome installer allowing DevMode

2014-06-14 Thread John Jerger

I am very reliant on the GWT DevMode plugin on Chrome Linux.  I have tried 
Super Dev Mode, and I do not find it nearly as useful as the standard 
DevMode.

On Thursday, June 12, 2014 11:24:44 AM UTC-7, Warren Baltz wrote:

 Many people were surprised that their DevMode no longer worked recently. I 
 am one of them.  I am aware of Super Dev Mode. It's not always the answer.

 After some digging I found that I can disable Chrome's auto update, but I 
 still need an older version to install. Google has made it very difficult 
 to get an older version. I understand their interest in security, stability 
 and new features. But it feels like the rug was pulled out from under 
 developers using DevMode.

 If anyone else would like a standalone installer for an older Chrome that 
 still allows DevMode, please leave a brief comment. I'd like this thread to 
 get some attention quickly and hopefully provide some relief.  I have a 
 major project derailed because of this change, and I imagine there are 
 others like me. Time is critical here.  What do you say, Google?  Help a 
 developer out?


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

Re: you can only use Chrome extensions that you get from the Chrome Web Store

2014-06-13 Thread john wolfe



On Thursday, June 12, 2014 6:59:02 AM UTC-5, AJ wrote:

 I started up Chrome today and received notification that the GWT Plugin 
 has been disabled

 For your protection, you can only use Chrome extensions that you get from 
 the Chrome Web Store

 At the moment I find no way to enable it, not even with developer mode 
 enabled


you can get around this by downloading the Dev Channel for Windows build 
of chrome here http://www.chromium.org/getting-involved/dev-channel

you may have to restart chrome or drag n drop .crx files again but i was 
able to just click enable on most disabled extensions.  shouldnt change 
your chrome experience. 

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

Re: [gwt-contrib] SafeHtml on the server/vm

2014-06-09 Thread John A. Tamplin

On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth niloc...@gmail.com wrote:

 Currently SafeHtml co live in gwt-user, though they are for the most part
 listed in a shared package, implying that a server can use them. However,
 gwt-user.jar also includes javax packages as well as hibernate, w3c, etc,
 so can't reasonably be imported to a server which already uses any of those
 packages (i.e. any servlet container). Is this an oversight in the publicly
 packaged GWT and is SafeHtml used by teams that package differently, or
 instead is this package not actually intended for server use, but instead
 just compile-time tasks where gwt-user is on the classpath like compiling
 or linking?

 I'm doing some work on a non-servlet server which hasn't so far seen
 concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy
 way to get server generated HTML from code that is shared with the client.
 This use case *appears* to be implied from the package name, but presently
 isn't possible for the majority of GWT backends.

 Ideas on why it is the way it is? Thoughts on how to make it available to
 the server (without giving it yet another jar a la requestfactory-server)?
 Interest in a contributed SafeHtmlTemplates implementation for JVM?


Yes, SafeHtml is intended to be usable on the server.  There have been
various discussions about splitting up gwt-user into parts for client-only,
shared (and perhaps server-only), but that wasn't ever done.

Mostly, putting gwt-user last on the classpath on your server won't cause
any issues, though at least one JVM used to be unhappy with native methods
without corresponding binaries.

-- 
John A. Tamplin

-- 
You received this message because you are subscribed to the Google Groups GWT 
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/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: who discusses the next features and adopts feature requests?

2014-05-21 Thread John A. Tamplin

A more general answer is that in any community project, whoever cares about
a feature the most is the one that designs it, convinces others it is worth
including, and implements it.  Just because something has a lot of votes
doesn't automatically mean it will get built -- someone has to be
interested enough to make it happen.  This was the case even when it was a
Google project, but is especially true now that it is fully owned by the
community.

-- 
John A. Tamplin

-- 
You received this message because you are subscribed to the Google Groups GWT 
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/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Emma or JaCoCo support needs some attention

2014-05-20 Thread John A. Tamplin

On Tue, May 20, 2014 at 1:12 PM, David david.no...@gmail.com wrote:

No I did not try that one. I tried GWT Mockito which looked promising and
I actually managed to test a few widgets until someone added CssResources
and other GWT features and then GWTMockito just exploded with a generic
error that I should try disabling the classloading cache.

I am using GIN and I never do a GWT.create directly (GIN does that for
you). That helps a lot in testing the higher level classes like Activities.
But it does not really help with widgets. (We have some customisations on
top of the DataGrid and CellTable and it does not look possible to automate
the testing of those.

It isn't clear how much you can do widget tests on the server anyway -- the
only way I see it would be useful is widgets that clearly delineate the
view from the rest of it, and allow you to test the model/controller.

If you are talking about testing your own code, then likewise you don't
test the view on the server.

--
John A. Tamplin

--
You received this message because you are subscribed to the Google Groups GWT
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/CAM5k6X9yC%2BSbkdPWwQL6aazdKLDhm3cdHwmUB%2BcZf03vAyKrqQ%40mail.gmail.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

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] Re: Changes in monthly GWT contributor hangout

2014-04-22 Thread John A. Tamplin

On Tue, Apr 22, 2014 at 12:12 PM, Bhaskar Janakiraman 
bjanakira...@google.com wrote:

 I didn't see any further requests for discussion, so I'm canceling this
 month's contributor hangout.


For me, doing it during work hours is hard.

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

GWT Displaying HTML Emails

2014-02-08 Thread John Kida

I have a GWT app that reads incoming emails. I need to solve the problem of 
how to strip out any poorly formatted or even malicious HTML tags from the 
emails. I do want to be able to render HTML emails like your common email 
client will, but what would a best practice be for allowing this without 
allowing for global CSS properties and javascript or anything that may 
effect the rest of the app? My only idea is to put it into an IFrame... but 
id like to find something that can just safely strip the text to atleast be 
friendly enough to be inserted into the page as an HTML widget.


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

Re: [gwt-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: Click handler for widgets in content panel for a DisclosurePanel does not work

2014-01-11 Thread John Preston

I instantiate the DisclosurePanel as follows.

g:DisclosurePanel ui:field=dp width=180px
g:customHeader width=100%
  g:HorizontalPanel width=100% horizontalAlignment=align_right
 verticalAlignment=align_middle
 styleName='{style.session_header}'
  g:HTML ui:field='sessionName'/g:HTML
  g:Image url='images/user-profile.png' /g:Image
  /g:HorizontalPanel
/g:customHeader
g:FlowPanel styleName='{style.body}'
  g:HTMLPanel
g:Anchor ui:field=link1 styleName='{style.link_item}'Link
1/g:Anchor
g:Anchor href=#userprofile ui:field=link2
styleName='{style.link_item}'User Profile/g:Anchor
g:Anchor ui:field=logout_link
styleName='{style.link_item}'Logout/g:Anchor
  /g:HTMLPanel
/g:FlowPanel
  /g:DisclosurePanel



public class ActiveSessionPanel extends Composite
{
  private static ActiveSessionUiBinder uiBinder =
GWT.create(ActiveSessionUiBinder.class);

  interface ActiveSessionUiBinder extends UiBinderWidget,
ActiveSessionPanel
  {
  }

  @UiField
  HTML sessionName;
  @UiField
  Label logout_link;
  @UiField
  Anchor link1;
  @UiField
  Anchor link2;

  public ActiveSessionPanel()
  {
initWidget(uiBinder.createAndBindUi(this));

sessionName.setHTML(Active session);

logout_link.addClickHandler(new ClickHandler()
{
  @Override
  public void onClick(ClickEvent event)
  {
Window.alert(logout link clicked);
  }
});

  }

}


However I see the panel and it opens ok, but the links do not produce any
response, although they present themselves with underlines, thus I think
they are being recognized as links.

Can't figure what I'm doing wrong.


On Sat, Jan 11, 2014 at 4:25 PM, Jens jens.nehlme...@gmail.com wrote:

 Works for me. I have DisclosurePanels that contain content widgets with
 lots of Buttons / Anchors having ClickHandler attached.

 -- J.

 --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/zx9JOwQVd20/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/groups/opt_out.


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

Any GWT.create videos available?

2013-12-19 Thread John Kida

Have they or will they be releasing the recordings from the GWT.create 
events? Does anyone know if there are any available yet?

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

Multipath/Branch Workflow Wizard

2013-11-28 Thread John Kida

Does anyone know of any GWT based Wizard project that will allow multiple 
questions that lead you down different paths in the wizard?

I want to create a sort of tree style wizard, which could be used for a 
number of things, but in my case to direct a support agent towards a 
solution for a particular problem. So you would basically be selecting from 
a list of answers for a question on each page, depending on the answer you 
selected would determine the next wizard screen to display, hopefully 
narrowing the problem down further and further until a solution is found.

I have seen a few GWT wizard projects out there, but they all seem to be 
set on 1 static screen path, and i need branching of the wizard path. If 
anyone knows of anything like this, or if there is any active GWT Wizard 
project out there that would be a really good candidate to extend for this 
functionality, please let me know. 

If nothing like this exists, I will go ahead and start a github project for 
it, let me know if anyone else is interested.
 
Thanks.

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

Re: [gwt-contrib] support for JSR 310 / java.time created

2013-11-26 Thread John A. Tamplin

On Mon, Nov 25, 2013 at 7:01 PM, Jörg Hohwiller 
joerg.hohwil...@googlemail.com wrote:

 Hi there,
 I posted in GWT community on g+ about my *JSR 310* backport I created and
 my super-sourced GWT code.
 Stephen Habermann posted:
   Wow, 13000 passing tests is amazing. Great work!  You should post about
 your progress on the gwt-contrib list

 (I am still unsure about when to post to groups and when g+)

 So here I am. You can find all my work and changes from here:
 https://github.com/m-m-m/mmm/issues/83

 I am looking forward for your feedback and discussion. It will be my
 pleasure to contribute my work to the GWT project.
 However, I am not clear about the permissions required from the original
 authors of threeten since I simply forked their codebase and keept their
 headers and copyrights in my project.
 For GWT this has to be transferred and I assume we would need permissions
 from Stephen Colebourne, Michael Santos and all the others.


The BSD-licensed parts shouldn't be any problem to import, but you have a
few files with Oracle licenses which aren't going to work.

Also, the GWT i18n code will need to be updated to support this as well.

There are a few things which are going to be very hard to support   As Jens
mentioned, ZoneRulesProvider needs an async API so it can fetch the
necessary data from a server, so we can't provide a compatible API.  We can
provide a GWT-specific version (under a different package), so shared code
can deal with ZoneRules/etc but getting them will be different in client vs
server code.

Have you looked at generated code size?  There are also a few places where
it appears to rely on overflow behavior, which isn't guaranteed in GWT as
an int is actually represented by a JS Number under the hood.

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

Re: [gwt-contrib] Re: support for JSR 310 / java.time created

2013-11-26 Thread John A. Tamplin

On Tue, Nov 26, 2013 at 4:35 AM, Jens jens.nehlme...@gmail.com wrote:

 Also if you copy the code from Java 8 (which might or might not be the
 same as the latest JSR 310 code) there should not be any permission issues
 as it's part of the JRE.


I do not believe this is correct - I am pretty sure Oracle's license is
incompatible with Apache2 by design.  In general GWT does not use any JRE
code from Oracle, and instead uses code from Harmony or implements it from
scratch.

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

Re: [gwt-contrib] Re: support for JSR 310 / java.time created

2013-11-26 Thread John A. Tamplin

On Tue, Nov 26, 2013 at 7:47 AM, Jens jens.nehlme...@gmail.com wrote:

 I do not believe this is correct - I am pretty sure Oracle's license is
 incompatible with Apache2 by design.  In general GWT does not use any JRE
 code from Oracle, and instead uses code from Harmony or implements it from
 scratch.


 Interesting. Glad I am not a lawyer but I am just curious how GWT deals
 with code that is so easy that you can not implement it differently than
 Oracle when super sourcing it. Removing/changing JavaDoc is probably not
 enough to justify changing the license header from x to Google? For example
 take Cloneable, ClassCastException and similar simple classes/interfaces.


IANAL, but my understanding is the API is public so you can always
reimplement the API - you just can't use their copyrighted code to do so.
 The simplicity of the implementation doesn't matter, it is whether you
used their source or not.  If there is only one reasonable way to implement
something, it is harder to show that you copied their code, but if it is
1000 lines of complex code the odds that it would be essentially the same
if you didn't copy it are very slim.

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

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] String concatenation

2013-10-30 Thread John A. Tamplin

On Wed, Oct 30, 2013 at 4:26 PM, Brian Slesinsky skybr...@google.comwrote:

 Not a compiler expert, but I wouldn't be surprised since in the AST it
 will be represented as a binary tree of JBinaryOperation nodes and the
 visitors walk the tree recursively. So balancing the tree should result in
 a smaller stack.


Right, the issue is that a long run of concatenation resulted in a
degenerate tree like concat(a,concat(b,concat(c,...))) and you could blow
out the stack on a recursive traversal.  I remember discussions about
special-casing string concatenation (it seemed unlikely to affect other
operators), either into a balanced tree or simply a multi-arg concat
operator.  I don't know if anything was ever done.

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

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] Re: Question about the source: how does GWT builds .translatable., .emul., etc. packages?

2013-10-22 Thread John A. Tamplin

On Tue, Oct 22, 2013 at 12:11 PM, Thomas Broyer t.bro...@gmail.com wrote:

 As far as modularization is concerned, we'd like to have dependencies
 always in the same direction: rebind-client-shared-server (or
 rebind-client-server-shared, depending on modules) so we can make a
 client artifact depending on a server artifact, or a client and
 server artifacts both depending on a shared artifact (but with no
 dependency between client and server). In some cases, we'll split
 packages into distinct artifacts (there are cycles at the package level,
 but not when looking only at the classes); e.g. c.g.g.user.client (Window,
 Timer, etc.) c.g.g.resources and c.g.g.junit to have a package not
 depending on I18N and other things, and another one (or several) with
 additional dependencies.


Why would it be acceptable to have shared code depend on server code?

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

Re: GWT Designer Internal Error in Design mode (Eclipse Juno)

2013-10-19 Thread John Flournoy

I had this problem after trying to resize a layout panel and even pulling 
the source files down from backup didn't resolve the issue.   GWT plugin 
must be saving the size information somewhere other than the XML file.

I resolved it by cleaning, then deleting the project and importing it again 
as existing source.
Once I did all that I was able to view the UIBinder file in the 
WindowBuilder design tab.

Regards

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

Re: [gwt-contrib] Re: Non-client apis and breaking changes

2013-10-18 Thread John A. Tamplin

On Fri, Oct 18, 2013 at 5:10 AM, Thomas Broyer t.bro...@gmail.com wrote:

 This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared
 being for things usable on server-side (included in gwt-servlet); and as
 a rule of thumb any class not listed in the javadocs we generate should be
 considered private.


I disagree with that -- I think unless the package includes impl or the
name or Javadoc clearly indicates it is an implementation class, any public
class should be considered public.

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

Re: [gwt-contrib] Re: Implement subpixels to support IE10

2013-10-15 Thread John A. Tamplin

On Tue, Oct 15, 2013 at 11:13 AM, Matthew Dempsky mdemp...@google.comwrote:

 I've been thinking about how we'd cope with this in Google's code base,
 and I think we could handle a change-return-type-to-double change
 reasonably gracefully.  I'd probably tackle it as (glossing over some
 logistics):

   1. Expose static int toInt32(double x) and probably a static int
 toInt32(int x) { return x; } methods in some appropriate utility class.
   2. Write an error-prone https://code.google.com/p/error-prone/ check
 to warn when elem.getFoo() is used somewhere that a double value wouldn't
 be accepted, and recommend using toInt32().


You could make this completely foolproof by introducing an extra step - add
a new wrapper type GwtInt which behaves just like Integer except it isn't
autoboxed.  Then have toInt32(GwtInt), and fix all the compile errors to
include that call.  Then replace GwtInt with double everywhere.

Now, that is a bit more complicated in a codebase the size of Google's, as
you will have lots of people making changes while this is going on, but as
long as you post about what is going on when they get compile errors they
can do it themselves.


   3. Convert all calls to elem.getFoo() into toInt32(elem.getFoo()).
   4. Once all warnings have been fixed, we can merge the patch.
   5. Turn off the error-prone check.

 My only concern at that point would be third-party GWT libraries.  If we
 exposed the toInt32() method(s) in GWT 2.6 and kept them at least for 3.0,
 then it would be possible for GWT libraries to be compatible with GWT 2.6
 and 3.0 by using (e.g.) GWT.toInt32().  So that might be worthwhile for us
 to consider for 2.6.


Third-party libraries are always going to have hard times supporting
multiple GWT versions.  I don't think this issue will be harder than any of
the others they will have to deal with.

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

Re: [gwt-contrib] Re: Implement subpixels to support IE10

2013-10-15 Thread John A. Tamplin

On Tue, Oct 15, 2013 at 11:51 AM, Matthew Dempsky mdemp...@google.comwrote:

 On Tue, Oct 15, 2013 at 8:18 AM, John A. Tamplin j...@jaet.org wrote:

 You could make this completely foolproof by introducing an extra step -
 add a new wrapper type GwtInt which behaves just like Integer except it
 isn't autoboxed.  Then have toInt32(GwtInt), and fix all the compile errors
 to include that call.  Then replace GwtInt with double everywhere.


 That begs the question though, doesn't it? :)

 The steps I outlined are how I'd cope with the return type changing from
 int to double without ever introducing compile errors and without
 needing to submit any global cleanup changelists.  Adding a GwtInt
 intermediary step means needing to instead cope with converting the return
 type from int to GwtInt and then again from GwtInt to double, which
 each seem as hard if not harder than the original problem.


No, because you can use foolproof automated refactoring tools.  Anyway,
just a suggestion if you wanted to replace the error-prone step with two
foolproof steps.

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

Re: [gwt-contrib] Re: Maven-ization Status

2013-09-24 Thread John A. Tamplin

On Tue, Sep 24, 2013 at 10:37 AM, Thomas Broyer t.bro...@gmail.com wrote:

 It means two things:

- replacing our hard-to-maintain Ant-based build (and Maven has the
best IDE tooling among build tools)

 Yeah, I guess that is why I spent half of yesterday getting a build to
work in IntelliJ when it worked running from the command line.  I have had
similar issues with Eclipse before.

Maven is great when it works, but you are just SOL when it doesn't.  You
resort to deleting your .m2/repository, re-importing maven in your IDE,
deleting your IDE project and recreating it, etc and (hopefully) it just
starts working again and you have superstitions about what actually fixed
it (so asking others for advice you get totally different suggestions for
how to fix it, none of which actually fix it by themselves).  That is
before you even get into all the useless work that Maven does, such as
downloading stuff to find out there is no work to do.

On the contrary, I have never once had an issue with ant, so I have no idea
why people say Ant is hard to maintain.

YMMV of course.

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

Re: Where i may to download update site archive for GWT Designer?

2013-09-10 Thread John Murphy

That page gives an XML error on all the P2 sites.

More to the point, I am trying to get the full version of GWT Designer as I 
have installed the lightweight version that comes with the Eclipse PDE. 
That version gives no access to the GWT Designer wizard that I want. Where 
is the GWT Designer full version to be found?



On Monday, November 21, 2011 2:40:10 PM UTC-8, Eric Clayberg (Google) wrote:

 Try these:

 http://code.google.com/p/gwt-designer/downloads/list


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

Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT

2013-08-28 Thread John A. Tamplin

On Wed, Aug 28, 2013 at 4:59 AM, Thomas Broyer t.bro...@gmail.com wrote:

 I like what Square did with Retrofit http://square.github.io/retrofit/,
 which looks a lot like Errai's JAX-RS. The net advantage of Errai's JAX-RS
 is that you can simply implement your interface on the server-side and have
 the annotations inherited from it. AFAICT this is the same as Resteasy's
 proxy framework:
 http://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/RESTEasy_Client_Framework.html,
 so your client interface could be shared by your GWT client, Android client
 (or anything running in a JVM) and server resource (whether Resteasy or
 Jersey). Errai's approach to asynchronous calls feels like an ugly hack
 too: they absolutely wanted to be able to use the exact same interface
 everywhere, when an async interface could be automatically generated from
 the synchronous one (e.g. using annotation processors so it works in any
 IDE and outside IDEs too). Compare that, for example, to gwt-jsonrpc from
 Gerrit, where everything looks asynchronous (and the server-side could
 possibly be *made* asynchronous with servlets 3).
 The problem with all of them (Retrofit, JAX-RS, Errai) is how to configure
 them (almost everything in Errai shouts “unoptimizable output” though;
 Errai puts the focus on the developer's productivity when GWT is about
 optimized JS), particularly how you configure such things like
 interceptors to inject headers or process error responses (e.g. to handle
 authentication; probably something similar to the RequestTransport of
 RequestFactory, or the RpcRequestBuilder of GWT-RPC) and
 marshallers/unmarshallers; and make that configuration GWT friendly.
 Maybe we should wait for the GWT.create() changes.

 Using Retrofit has a similar issue to GWT-RPC -- you want your server-side
interface to be synchronous, but your client-side interface to be async.
 So, I don't see a lot of benefit of being able to use the same interface
on the client and server because you don't actually want that.  We could
certainly have a GWT-RPC-like generator that works with an arbitrary REST
API using sync and async interfaces, and we could keep the GWT-specific
bits out of the sync interface so that code could easily be shared (even
though the generator would just verify that they are compatible).

All of these libraries that weren't written with GWT in mind also have the
problem of it having a bunch of GWT-incompatible stuff in the jar.

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1830 matches

Mail list logo