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 <[email protected]> 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 [email protected]. > 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=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFw3gJ_GD%3Dqa-6RQZOeG_Q9CfJ6ARv-HdHiki9k_-CsUR35kjw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
