[gwt-contrib] Re: Proposal: Add/remove annotation via gwt.xml
*[to: +google-web-toolkit-contributors]* (I originally didn't think this thoroughly and considered it as the specifics of the implementation but actually it is not.) On Tue, Aug 19, 2014 at 7:00 PM, Thomas Broyer wrote: > Could we use the public gwt-contrib rather than the private > gwt-maintainers for these kinds of topics? > Le 20 août 2014 02:34, "'Goktug Gokdogan' via gwt-maintainers" < > gwt-maintain...@googlegroups.com> a écrit : > >> This is a proposal to deal with per-type meta information used by GWT >> compiler and generators in a generic way. The solution proposed is simply >> using annotation while also letting annotations be configurable via gwt.xml: >> >> https://docs.google.com/document/d/1YrAIEM593kuRr78kGcoZk1UmbBTjDuQEVdSxm1XDFe8/edit?usp=sharing >> >> -- >> You received this message because you are subscribed to the Google Groups >> "gwt-maintainers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to gwt-maintainers+unsubscr...@googlegroups.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/CAN%3DyUA16HXQJCyKjJ%2BOnWFru4p8t1enrenGE3_kD0ES1YybsSg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: SDM "-XcompilePerFile": initial feedback
> > >> >> (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. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: SDM "-XcompilePerFile": initial feedback
18 август 2014, понеделник, 21:10:17 UTC+3, Roberto Lublinerman написа: > > So out of pure curiosity - are there obvious optimizations in the linker >> which are still pending? >> > > We have been thinking about strategies to incrementalize the work done by > the linkers, one idea is to have a linker that outputs js for different > Java classes to different resources and that could be incrementalized. > Sounds interesting! However if you mean separate JavaScript file per Java class, wouldn't that generate too many Javascript files in case I have, say, refactor-renamed a heavily used method? Another approach is maybe each time to output a single JavaScript file, which contains the delta of the changes to the previous JavaScript file (i.e. some new functions and some function redefinitions). Then the browser uses the old JavaScript + the new one... Anyway, just thinking loud, you sure know the topic better than me... >> 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. >> >> I am currently working on this one. There are two options here: 1) > serving source code directly without copying and 2) copying only "changed" > sources. Option 1) would be the optimal in terms of compile time but it > might result of a worse debugging experience (if you modify a source while > debugging the source mapping will be out of date). > > I think the out-of-date problem in option (1) does not happen so often in practice. Also, even if you do (2), the out-of-date problem is impossible to avoid if you use an in-IDE debugger like SDBG. Reason: SDBG is not really using the source files' copies you generate in the code server, but rather is opening and using directly the source files in the Eclipse project (and that's how it should be or else the integration between editing and debugging won't be so seamless). The DART Editor does it too, and I would assume JIDEA does the same. So IMO the ideal solution would be if you serve the source files directly, and maybe keep the option to pregenerate the source files on disk if somebody is using an out-of-IDE debugger like ChromeDevTools and wants to avoid the out-of-date problem by all means. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a374638a-d924-4977-b14b-80b7615b9721%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
