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

['John Stalcup' via GWT Contributors]

Any new bugs to report?


On Tue, Sep 2, 2014 at 2:07 PM, Arnaud TOURNIER  wrote:

> Hi Daniel,
>
> I made some more serious tests on a production project with which i used
> to develop using the classic DevMode.
> Those are the numbers that come from the CodeServer with or without the
> -XcompilePerFile flag, and they are quite impressive :
>
>Standard Compile per file Reduction
> 1st compile  101s 41s  59%
> Change 1 string and recompile 16s 5,8s  64%
> Change 1 string and recompile 18s 3,6s  80%
>
> First compile Unification traversed 60072 fields and methods and 6179
> types. 6139 are considered part of the current module and 6139 had all of
> their fields and methods traversed.
> Second compile Unification traversed 2528 fields and methods and 2650
> types. 124 are considered part of the current module and 124 had all of
> their fields and methods traversed.
>
> I did not use the Chrome dev tools to debug the application but the SDBG
> plugin for Eclipse.
> The experience is almost incredible, perfectly usable and much faster than
> the classic DevMode. The only bad thing is not having the Java fields
> inspected correctly (although one can guess the javascript equivalents most
> of the time) and little things that can be covered with time... Everything
> needs a compromise and having that debugging experience brought back to
> Eclipse is really what i was fearing to lose with the SuperDevMode. So i
> will adopt the SuperDevMode for a while !
> Ray, Brian, John and Robert, Ivan, James and you all made a really
> impressive work ! The future of GWT is assured ! Now i can't wait to have
> the Java 8 features to be tried ;)
>
> Now i have a question about the message "Unification traversed..." : first
> what means the message exactly (i need to see the code) and second why some
> many fields and methods are traversed if only change one file ?
>
> Next i had ideas but no time to implement them, maybe i dump them here
> with the hope they can be useful ;)
> - Recompile on file change. The time the user switches to the browser, the
> compile is almost finished.
> - Tool to benchmark.
> - Recompile on F5, standard SuperDevMode linker
> - GWT plugin for eclipse : GWT tools + SDBG
> - Sample including the experience
>
> Thanks a lot again for all the work and the good things coming out !
> Arnaud
>
>
>
> Le lundi 1 septembre 2014 12:25:38 UTC+2, Daniel Kurka a écrit :
>>
>> Hi Arnaud,
>>
>> are those 10s after the changes we made or before?
>>
>> -Daniel
>>
>>
>> On Mon, Sep 1, 2014 at 12:02 PM, Arnaud TOURNIER 
>> wrote:
>>
>>> Thanks to all of you who participated to this very good things !
>>>
>>> I am now able (from the trunk) to have a great experience debugging with
>>> Gwt + Eclipse + Sdbg + Chrome.
>>>
>>> I cannot be quantitatively very precise but the latest optimization
>>> (-XcompilePerFile) seems to give good results. My project on which i test
>>> that is not so big so the compilation takes about 10 seconds. Improvements
>>> are obvious !
>>>
>>> Thanks a lot!
>>>
>>> Le vendredi 29 août 2014 18:16:40 UTC+2, juan_pablo_gardella a écrit :

 Great news!! Thanks a lot for the effort.


 On 29 August 2014 13:02, Ivan Markov  wrote:

> BTW using a more recent laptop seems to make a difference and nearly
> doubles the performance:
> MacBook Pro model 2013 (I7 2.7 GHz):
> - 2 to 3 seconds for recompiling changes to a single file
> - 2 to 3 seconds for linking
> - Changes to more types of course again results in a growth of the
> recompilation time; this time it is 8 instead of 13 seconds for the same
> set of around 10 changed files. Linking still 3 seconds.
>
> I think you are getting there!
>
>  --
> You received this message because you are subscribed to the Google
> Groups "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-web-toolkit-contributors+unsubscribe@
> googlegroups.com.
>  To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/c646cebb-005a-42fd-9f9d-
> 62334e1a3189%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] -XcompilePerFile feedback

['John Stalcup' via GWT Contributors]

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

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

John


On Wed, Sep 3, 2014 at 7:06 PM, John Stalcup  wrote:

> Thanks for the repo update.
>
> This is fixed now (https://gwt-review.googlesource.com/#/c/9004/)
>
>
> On Wed, Sep 3, 2014 at 1:15 AM, Julien Dramaix 
> wrote:
>
>> Sorry I had forgot to push my last change. The file is there now.
>>
>>
>> On Wed, Sep 3, 2014 at 2:51 AM, 'John Stalcup' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> I don't see style.gss in the repo.
>>>
>>>
>>> On Fri, Aug 29, 2014 at 2:45 PM, Julien Dramaix <
>>> julien.dram...@gmail.com> wrote:
>>>
 Dear GWT team,

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

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

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

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

 Julien

  --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D63%3D4dAGGLf3M-izC55GmE4Lr7i50FxW408Ye6P5G8JzQ%40mail.gmail.com
 
 .
 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.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-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
>> 
>> .
>>
>> 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

[Jens]

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

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

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.

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.


-- J.

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

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

['John Stalcup' via GWT Contributors]

Thanks for the feedback Jens.


On Mon, Sep 8, 2014 at 1:31 PM, Jens  wrote:

> Any new bugs to report?
>>
>
> Some things we have observed at work while using latest trunk SDM (compile
> per file):
>
> 1.) If we don't use -noprecompile then SDM does not start because it says
> it has found more than one permutation. If we use -noprecompile then SDM
> starts and the first compile through the bookmarklet works as well. Our
> trunk build from 1st Sep still worked in both situations. With current
> trunk the precompile says that it can not set the locale property to "en"
> because only "de" was allowed, then tries a fallback value and finally the
> precompile fails.
>
I'm working on a CL right now to opt -XcompilePerFile into the
-noprecompile behavior for just the reason. Should be in today.

>
> 2.) From time to time it happens that a recompile through the bookmarklet
> breaks the app because some JS isn't emitted correctly. For example we have
> a factory that creates a specific Ginjector and that factory has rebind
> rules that are triggered by a form factor property. Just today a colleague
>  has recompiled the
> app and got "DesktopGinjectorProvider is undefined". Another example is
> that a custom composite stopped working with error "undefined is not a
> function". Taking a look at the JS code is seems like the problem happened
> in the constructor function that wanted to call the clinit function for
> that class. The machine that had the issue also had Chrome beta so I wasn't
> able to debug the pure JS because of 4.)
>
I've fixed two Gin generator related breakages like this so far. Are you
sure this is occurring with HEAD? If so then there's definitely a bug in
the "stale types marking" code that needs finding. If you can make a repro
case I'll figure it out.

>
> 3.) On one machine the first compilation after starting SDM with
> -noprecompile never finishes. The CodeServer java process does some heavy
> work for the first minute or so and then goes to sleep and thats it. I call
> it "SDM progress dots of death". The CodeServer arguments are exactly the
> same as on other machines which work without issue. I have no idea why this
> is happening. Also this only happens with latest trunk, a build from 1st
> Sep works.
>
Hmmm, that's really strange. It doesn't sound -XcompilePerFIle related so I
probably won't take a look at it for now. Maybe Brian will want to take a
look.

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

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

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

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

['John Stalcup' via GWT Contributors]

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

> Thanks for the feedback Jens.
>
>
> On Mon, Sep 8, 2014 at 1:31 PM, Jens  wrote:
>
>> Any new bugs to report?
>>>
>>
>> Some things we have observed at work while using latest trunk SDM
>> (compile per file):
>>
>> 1.) If we don't use -noprecompile then SDM does not start because it says
>> it has found more than one permutation. If we use -noprecompile then SDM
>> starts and the first compile through the bookmarklet works as well. Our
>> trunk build from 1st Sep still worked in both situations. With current
>> trunk the precompile says that it can not set the locale property to "en"
>> because only "de" was allowed, then tries a fallback value and finally the
>> precompile fails.
>>
> I'm working on a CL right now to opt -XcompilePerFile into the
> -noprecompile behavior for just the reason. Should be in today.
>
this is in now.

>
>> 2.) From time to time it happens that a recompile through the bookmarklet
>> breaks the app because some JS isn't emitted correctly. For example we have
>> a factory that creates a specific Ginjector and that factory has rebind
>> rules that are triggered by a form factor property. Just today a
>> colleague  has
>> recompiled the app and got "DesktopGinjectorProvider is undefined". Another
>> example is that a custom composite stopped working with error "undefined is
>> not a function". Taking a look at the JS code is seems like the problem
>> happened in the constructor function that wanted to call the clinit
>> function for that class. The machine that had the issue also had Chrome
>> beta so I wasn't able to debug the pure JS because of 4.)
>>
> I've fixed two Gin generator related breakages like this so far. Are you
> sure this is occurring with HEAD? If so then there's definitely a bug in
> the "stale types marking" code that needs finding. If you can make a repro
> case I'll figure it out.
>
>>
>> 3.) On one machine the first compilation after starting SDM with
>> -noprecompile never finishes. The CodeServer java process does some heavy
>> work for the first minute or so and then goes to sleep and thats it. I call
>> it "SDM progress dots of death". The CodeServer arguments are exactly the
>> same as on other machines which work without issue. I have no idea why this
>> is happening. Also this only happens with latest trunk, a build from 1st
>> Sep works.
>>
> Hmmm, that's really strange. It doesn't sound -XcompilePerFIle related so
> I probably won't take a look at it for now. Maybe Brian will want to take a
> look.
>
>>
>> 4.) Not directly GWT related but you might want to know it: The new
>> Chrome beta contains the change that Brian asked for which marks lines
>> without source maps in gray so you know that you can not put a breakpoint
>> on these lines. However for some reasons Chrome now also forbids setting
>> breakpoints in the pure JS file (e.g. app-0.js) if no source map entry was
>> found for that JS line. That can be quite annoying. For example I couldn't
>> set a breakpoint inside a class constructor function because the whole JS
>> function wasn't source mapped.
>>
> +skybrian
>
>>
>>
>> -- J.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/5b8b733b-ef6c-4aaa-a071-d0bf4b027ca6%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

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

[Jens]

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


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.

-- J.

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

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

['John Stalcup' via GWT Contributors]

On Mon, Sep 8, 2014 at 3:00 PM, Jens  wrote:

> I'm working on a CL right now to opt -XcompilePerFile into the
>> -noprecompile behavior for just the reason. Should be in today.
>>
>
> Cool will try it tomorrow.
>
>
> I've fixed two Gin generator related breakages like this so far. Are you
>> sure this is occurring with HEAD? If so then there's definitely a bug in
>> the "stale types marking" code that needs finding. If you can make a repro
>> case I'll figure it out.
>>
>
> Currently I am not sure, need to ask colleague tomorrow. Can you tell me
> the commit hashes of your two fixes so I can see which of our builds
> contain them?
>
recentish ones are:
267ad5efd00aae9b0f69eca793891e9fdad28e45  "Opts compilePerFile into
noPrecompile to avoid >1 permutation."
a43aa788cc2b78904c1bf6f0de9b8a1ebe78a6d2 "Fixes cascaded generator
invalidation for inner classes."
9da4d05b62d7d3cb48ccd03de7b4ad676e2318bd "Makes SDM+perFileCompile
correctly handle switching browsers."
7365570209426063bbc7fa4745e0b422e4fb4850 "Marks types generated by
invalidated generators as "modified"."

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

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

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

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

['Brian Slesinsky' via GWT Contributors]

>
>
> On Mon, Sep 8, 2014 at 3:00 PM, Jens  wrote:
>
>>
>>> 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
>

Maybe by configuring java.util.Logger? What does the message look like? (I
assume you're passing -logLevel DEBUG to CodeServer? If so I haven't used
DEBUG level.)

- Brian

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-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%2B%2BRBT86KXXZUEWvgVLMUpXeEBeBHW23hdbVV72qto_baojAEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.