Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
Hi John, Thanks for the great responses. > do you still have to retranslate the *entire* AST to Javascript source (and is > the resulting process still fast if you have to do so)? Yeah, good question...seems like in an ideal world you could cache the JS string for each compilation unit and then stream them to the target .js file on disk. I know that's not at all how GWT works today. > The approach i'm working on is to make change normal compiles to be > incremental at the "per module" level. This should transparently > speed up not just build systems, but also SuperDev mode. That is a good point. > In a nutshell my approach (leaving out lots and lots of edge cases) is > this: run the GWT compiler on "Module A" with *just* the Java source > for "Module A" and the bytecode for its dependencies provided to the > JDT compiler. [snip] That sounds similar to what I was thinking (although much more flushed out instead of random arm chair musing), except done on the module level instead of the compilation unit level. I get what you're saying, that if done with modules, you could output "gwtar v2" files :-), and speed both dev/prod mode up. ...well, and I'd wanted to pass in an GWT AST instead of Java source, because I think you could very quickly get a GWT (Java) AST from the Eclipse Java AST, so could skip the JDT step of the compilation process. Sounds pretty awesome. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
> I may need to revisit some of that responsibility though, since the > current GWT Eclipse plugin owns/manages the GWT compile triggering process. > I'm toying with the idea of implementing this iterative compilation > triggering responsibility in Maven and (since GWT shouldn't try to act like > a build system) then integrating this into the GWT Eclipse plugin? I > haven't thought all the way through this part and haven't implemented any > of this part yet, so would appreciate suggestions. > In my experience with eclipse plugins, the m2eclipse plugin is actually more user friendly to perform tasks with than the actual eclipse build process. Anything and everything that does work in maven can work with m2eclipse. The only gotcha is that not everyone is on the maven bandwagon. Still, it would be possible to setup a hidden "shadow project" based solely on source dependencies and .gwt.xml modules. Of course, requiring m2eclipse for the gwt plugin may be a little intrusive, but it could prevent duplication of labor (reuse in eclipse, and probably intelliJ as well). As for incremental recompiles, maven out-of-the-box does not have good support for this (yet). At work, we use a custom plugin that computes unique hashes of files to detect changes; every snapshot is compiled and deployed to a repo, so the plugin can use the existing jar if it is found, or compile and deploy a new one if needed. For gwt compiles, it would make sense to use a local-repo in /target or gwt-unitCache to do something similar; obviously the computing of these hashes would add a little overhead, but given that hashing a file is certainly faster than recompiling, visiting and translating the file, it would still be a win. I'd heard that maven 3 has extra support for something similar to this, but I have yet to see a production use case for it (and I'm pretty sure it depends on nexus setup, which is clearly way more overhead than necessary). If you had a spec for what you want a maven / eclipse plugin to do, I do have experience with both, and would be glad to help. Also, ant tends to have much better support for incremental builds using timestamps, which is fine for local development; we prefer the hash approach because it allows a dependency built by developer A to be reused by developer B, but if we're storing all this locally, timestamps would likely be the best of both worlds. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
Agreed. The TypeOracle (actually there are many TypeOracles) indexes, AST references, JProgram indexes, after optimization, etc etc, are extensive and complex. Updating them in place when swapping out the AST for a particular Type would be very tricky and failure prone. On Wed, Aug 21, 2013 at 2:09 PM, John A. Tamplin wrote: > On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman < > step...@exigencecorp.com> wrote: > >> AFAIK, historically most of the optimizations around "incremental" >> compiles have always required going back to building ResourceOracle, >> TypeOracle from scratch, but speeding it up with caching. >> > > The problem is let's say you change file A. How do you know what all > needs to be updated in TypeOracle? I am sure you can keep track of it, but > it will require keeping much more data than is currently kept so you can > incrementally update TypeOracle's data structures. For example, let's say > you remove an interface from a class. Even if you walk down the > inheritance tree, you can't just remove that interface, because some other > ancestor might have implemented it. The same sort of thing goes in many > other places. > > Note that TypeOracle memory requirements has been a problem in the past > for large internal apps. > > -- > John A. Tamplin > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
@Johannes Barop Your approach is interesting since it allows you to avoid cache the results of generator execution and not have to reparse and recompile generated code during every monolithic compile. But since it's all based on GWTAR, you're still limited to a maximum possible impact of 50%. The approach i'm working on should be limited only by the number of modules you define (the more the better) and the cost of global phase generator execution (most of which I should be able to automatically move into local phases, aka part of specific modules). So, while I can't guarantee that your setup will be "easily adoptable to the new compiler", it shouldn't matter since the new incremental compilation path should be faster than your setup and thus make it unnecessary. There's not a lot you can do to help right now but I could eventually use some help setting up support in external build systems (like Maven and Ant, and possibly integrated with the GWT Eclipse plugin) for triggering the GWT compiler once per module and/or once per modified module. I'll also probably eventually want some external testers before this goes live. So i'll keep you in mind. On Wed, Aug 21, 2013 at 1:46 PM, Johannes Barop wrote: > > Am 21.08.2013 um 09:05 schrieb James Nelson : > > > I've long felt like highly modular projects could greatly benefit from > producing gwtar files so that unchanged code does not require recompiling. > > I've thought about using a maven plugin to add .gwtar to my jars, though > this would not be a portable solution for all GWT developers. > > > > Any portable solution using gwtar would be to create one per module > (using a flag to enable support while still experimental), or one per java > package (maybe not a good idea given the size of some projects). > > > > Given that the compiler already knows to remove invalidated units, this > does seem like a feasible option. > > Producing .gwtars could also be done periodically for the whole project > at the developers whim, perhaps through a flag to a standard full compile? > > As far as I know a usual gwtar contains only a precompiled Java AST from > the first compilation phase. You still need to run the generators on all > the visible code. It saves some seconds but for me the most time consuming > part is the code generation and JavaScript compilation. > > I've currently playing around with a project where I have multiple > modules. For each module I generate the initial Java AST, run code > generators and throw the precompiled code in a gwttar. When building the > final application only a small code generator which discovers all > precomputed code runs. > > It's a special use case because I have defined decoupled modules which I > want to link together. I'm unsure if this is any help for an "intelligent" > approach :-) > > @John Stalcup > Is it possible to contribute in this area? For example I want to ensure > that the code for the project is easily adoptable to the new compiler. > > > BTW: > I agree with Stephen that Java IDE's also should be supported well. Yes > SuperDevMode enabled to debug in the browser but the IDE is the tool I'm > used too and I have to use the IDE for server code anyway. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
I guess i forgot to address your question about what the API would look like. At this moment it looks like this: !. 2. 3. When compiling Module A I'm not paying attention to which files are or are not modified *at all*. I'm just recompiling every source file known to be part of Module A. I'm leaving it the reponsibility of the build system that is driving the compiler, to know which files have changed and thus know which Modules should be recompiled as a result. I may need to revisit some of that responsibility though, since the current GWT Eclipse plugin owns/manages the GWT compile triggering process. I'm toying with the idea of implementing this iterative compilation triggering responsibility in Maven and (since GWT shouldn't try to act like a build system) then integrating this into the GWT Eclipse plugin? I haven't thought all the way through this part and haven't implemented any of this part yet, so would appreciate suggestions. On Wed, Aug 21, 2013 at 4:29 PM, John Stalcup wrote: > I agree that the fastest executing approach is the approach that does the > least amount of computation. And so yes, your suggestion to "keep a warm > version of the AST loaded in memory, and update that AST on the fly with > just new AST's of changed classes" is a fast design. But there are some > unconsidered questions: do you still have to retranslate the *entire* AST > to Javascript source (and is the resulting process still fast if you have > to do so)? Do the modified files need to trigger generator reruns? How do > you know which generators are/are not affected by the change? When > implementing this incremental generator support, how much duplication will > there be with existing generator logic in the main compile path? > > If you follow this mutative/truly incremental approach in memory in > SuperDev mode, then it's unclear how to reuse this work to also speed up > normal compilation triggered by a build system or continuous integration > server (such as Maven or Jenkins). > > The approach i'm working on is to make change normal compiles to be > incremental at the "per module" level. This should transparently speed up > not just build systems, but also SuperDev mode. > > In a nutshell my approach (leaving out lots and lots of edge cases) is > this: run the GWT compiler on "Module A" with *just* the Java source for > "Module A" and the bytecode for its dependencies provided to the JDT > compiler. Take the results of this compilation and do all of the normal > transformations on it except for optimization (which are currently > inherently global) and write out the resulting Javascript (for just the > types that were provided as Java source) using a special namer that names > types/functions/variables in a globally stable way (so that cross modules > references will resolve at runtime) and write this Javascript into a > ".gwtlib" file. Repeat this for every module in the dependency tree, > starting at the leaf nodes. When you get to the root of the tree, run > global generators and link these precompiled Javascript chunks (that you > pull out of the accumulated ".gwtlib" files) into one big chunk. > > This (should be) fast for 2 reasons: the amount of IO and computation for > each stage is kept to the minimum, and the the global phase is never > analyzing/transforming/outputting a global size AST (it's just > concatenating together the previously compiled Javascript for each of the > dependent modules). It's basically the same process as normal Java > compilation with separate Jar files being constructed. > > It can make cold compiles better by making it possible to parallelize the > compilation of different modules in the module tree, and it can of course > make warm compiles better by requiring only the recompilation of the > particular module that contains the changed file (as well as the rerun of > global generators and linking). User.gwt.xml registers 16 generators, but > I'm expecting that I'll be able to annotate some of them as "known to be > local" so that they can be kept out of the global phase and for the > remaining ones it should be possible to run them partially locally and > partially globally (so as to minimize the size of the global phase). > Eventually it would be nice to deprecate and replace all generators that > require some global phase. > > > > > On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman < > step...@exigencecorp.com> wrote: > >> Hey John, >> >> > it means having an optional compilation path that does not recompile >> > the entire world (as the current monolithic compile path does) and >> > instead tries to recompile just files (or or modules) that have >> > changed. >> >> Spiffy! Out of curiosity, would the API look something like: >> >> theBackendCompile.recompile(List filesThatChanged) >> >> Such that the existing ResourceOracle/TypeOracle instances are mutated >> with the updated state, instead of being rebuilt? >> >> AFAIK, historically most of the optimizations ar
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
I agree that the fastest executing approach is the approach that does the least amount of computation. And so yes, your suggestion to "keep a warm version of the AST loaded in memory, and update that AST on the fly with just new AST's of changed classes" is a fast design. But there are some unconsidered questions: do you still have to retranslate the *entire* AST to Javascript source (and is the resulting process still fast if you have to do so)? Do the modified files need to trigger generator reruns? How do you know which generators are/are not affected by the change? When implementing this incremental generator support, how much duplication will there be with existing generator logic in the main compile path? If you follow this mutative/truly incremental approach in memory in SuperDev mode, then it's unclear how to reuse this work to also speed up normal compilation triggered by a build system or continuous integration server (such as Maven or Jenkins). The approach i'm working on is to make change normal compiles to be incremental at the "per module" level. This should transparently speed up not just build systems, but also SuperDev mode. In a nutshell my approach (leaving out lots and lots of edge cases) is this: run the GWT compiler on "Module A" with *just* the Java source for "Module A" and the bytecode for its dependencies provided to the JDT compiler. Take the results of this compilation and do all of the normal transformations on it except for optimization (which are currently inherently global) and write out the resulting Javascript (for just the types that were provided as Java source) using a special namer that names types/functions/variables in a globally stable way (so that cross modules references will resolve at runtime) and write this Javascript into a ".gwtlib" file. Repeat this for every module in the dependency tree, starting at the leaf nodes. When you get to the root of the tree, run global generators and link these precompiled Javascript chunks (that you pull out of the accumulated ".gwtlib" files) into one big chunk. This (should be) fast for 2 reasons: the amount of IO and computation for each stage is kept to the minimum, and the the global phase is never analyzing/transforming/outputting a global size AST (it's just concatenating together the previously compiled Javascript for each of the dependent modules). It's basically the same process as normal Java compilation with separate Jar files being constructed. It can make cold compiles better by making it possible to parallelize the compilation of different modules in the module tree, and it can of course make warm compiles better by requiring only the recompilation of the particular module that contains the changed file (as well as the rerun of global generators and linking). User.gwt.xml registers 16 generators, but I'm expecting that I'll be able to annotate some of them as "known to be local" so that they can be kept out of the global phase and for the remaining ones it should be possible to run them partially locally and partially globally (so as to minimize the size of the global phase). Eventually it would be nice to deprecate and replace all generators that require some global phase. On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman wrote: > Hey John, > > > it means having an optional compilation path that does not recompile > > the entire world (as the current monolithic compile path does) and > > instead tries to recompile just files (or or modules) that have > > changed. > > Spiffy! Out of curiosity, would the API look something like: > > theBackendCompile.recompile(List filesThatChanged) > > Such that the existing ResourceOracle/TypeOracle instances are mutated > with the updated state, instead of being rebuilt? > > AFAIK, historically most of the optimizations around "incremental" > compiles have always required going back to building ResourceOracle, > TypeOracle from scratch, but speeding it up with caching. > > ...IIRC. It's been a little while since I've poked at the code. > > I know I'm being a broken record, but I think the mutative/truly > incremental approach, while a (large) PITA to build, in the long run is > the only solution that would be fast enough to get SuperDevMode fast > enough such that it's "hit save in Eclipse, the js file is updated, > done!", just like Java (and web) developers are used to. > > (I know Brian really doesn't like solutions that require Eclipse, but I > think the same mutative/incremental compiler API could just as well be > called by an Eclipse plugin or an IDEA plugin or even a Java daemon > polling the file system for changes. It's not IDE-specific.) > > Feel free to ignore my musings given I'm not actually contributing > anything to the effort; just curious as to how things are going. > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contribu
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
> > So as a result, in the best possible world the maximum impact it can have > on compile time, is ~50%. In practice it has a little less than that > because reading and deserializing these GWT Java ASTs from disk takes some > (smaller) amount of time and because in large modular projects there's a > tendency for duplicate copies of the AST for the same type to accumulate in > multiple GWTAR files (thus resulting in wasted duplicate deserialization > time). > > I did think of the duplicates in GWTAR, and that it might potentially cause problems if a type is updated in one GWTAR but not another. > Unlike GWTAR files the incremental compilation approach i'm working on > makes/will make 90+% of the compile time split by module (the only time > left in the monlithic phase should be a small percentage of generators and > the final linking). > > I can't wait to see it; when you are ready for testers, I would be glad to help out. > I don't want to discourage you from using GWTAR files, since they do have > positive impact. But I'm just saying that I'm not putting work into making > them easier to use or building easier build system integration for them, > since their maximum impact is limited. > Excellent. One other point is that the GWTAR speedup would help out on clean compiles, and not just recompiles. Obviously recompiles are where the real gold is at, in terms of development time, but anything that cuts down on CI hours at my work would definitely be much appreciated. @Johannes -> Your approach sounds like it has potential, and I would be glad to contribute to anything you are working on in that direction. Even if it won't help much or at all in the new compiler, we're all still using the old compiler, and anything I can do to drop our quarter-million/year CI bill would be time well spent. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
GWTAR files are okay, but are an incomplete solution to the problem of incremental compilation. During a normal monolithic GWT compile: - ~50% of the time is spent loading Java source off disk, compiling it with JDT, translating the JDT Java AST to a GWT Java AST (1 AST per type), and populating type oracles. - the other ~50% of the time is spent "stitching" the individual type ASTs into one combined tree, running GWT and Javascript semantic normalization passes, running optimization passes, translating GWT Java AST to GWT Javascript AST, translating GWT Javascript AST to Javascript Source and linking to disk. GWTAR has impact by effectively running that first ~50% chunk once per module (using just the Java source available to that module) and serializing the resulting GWT Java ASTs to disk, and reusing these per module GWTAR caches for subsequent compiles. So as a result, in the best possible world the maximum impact it can have on compile time, is ~50%. In practice it has a little less than that because reading and deserializing these GWT Java ASTs from disk takes some (smaller) amount of time and because in large modular projects there's a tendency for duplicate copies of the AST for the same type to accumulate in multiple GWTAR files (thus resulting in wasted duplicate deserialization time). Unlike GWTAR files the incremental compilation approach i'm working on makes/will make 90+% of the compile time split by module (the only time left in the monlithic phase should be a small percentage of generators and the final linking). I don't want to discourage you from using GWTAR files, since they do have positive impact. But I'm just saying that I'm not putting work into making them easier to use or building easier build system integration for them, since their maximum impact is limited. On Wed, Aug 21, 2013 at 12:05 AM, James Nelson wrote: > re: Heiko Braun > >> >> it means having an optional compilation path that does not recompile the >> entire world (as the current monolithic compile path does) and instead >> tries to recompile just files (or or modules) that have changed. >> >> it is exploratory work for me right now as there are very many issues >> standing in its way. >> >> if/when it is done and ready it should make a big impact on SuperDev mode >> refresh time by reducing compile time (when compiles are run >> non-monolithically) >> >> > I've long felt like highly modular projects could greatly benefit from > producing gwtar files so that unchanged code does not require recompiling. > I've thought about using a maven plugin to add .gwtar to my jars, though > this would not be a portable solution for all GWT developers. > > Any portable solution using gwtar would be to create one per module (using > a flag to enable support while still experimental), or one per java package > (maybe not a good idea given the size of some projects). > > Given that the compiler already knows to remove invalidated units, this > does seem like a feasible option. > Producing .gwtars could also be done periodically for the whole project at > the developers whim, perhaps through a flag to a standard full compile? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
Hi John, Thanks for reminding me about this... > The problem is let's say you change file A. Two things: First is that AFAIK GWT already does this...see the Dependencies class, which I became familiar with when trying to build a list of dependencies for Scala-GWT ASTs so they could fit in this workflow. Second is that I want GWT to *not* do this (right now it literally scans every classes saying "have your dependencies changed? nope. have your dependencies changed? nope." etc.). If I already have an IDE like Eclipse or IDEA sitting in front that is tracking this information--why do it twice? For example, if Eclipse sees A.java change and it knows that now B.java must be compiled too (let's say because a method signature changed), it could tell the GWT backend about both: gwtBackend.update(astForA); gwtBackend.update(astForB); The gwtBackend would blithely trust that the front-end (whether an IDE or a CLI daemon that has the extracted Dependencies logic in it) is submitting a series of ASTs that is eventually well-formed. Mutations could be done semi-non-destructively to the AST, like removing a method doesn't actually drop the method, it makes the body "alert(this method got deleted, you shouldn't see this message"). So the user could technically load the app at this point, but they'd get these alerts, just like in Eclipse if you run unit tests while methods aren't compiling you get little "btw this doesn't compile" runtime exceptions. Same idea. Eventually the user will fix all of their compile errors (that they're seeing in Eclipse/CLI), the udpated ASTs which now no longer call the method that went away will be submitted, and things will work again. > Even if you walk down the inheritance tree, you can't just remove that > interface, because some other ancestor might have implemented it. I'm making all of this up, but I would mark the interface as deleted and leave it at that. (Lots of hand waving.) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman wrote: > AFAIK, historically most of the optimizations around "incremental" > compiles have always required going back to building ResourceOracle, > TypeOracle from scratch, but speeding it up with caching. > The problem is let's say you change file A. How do you know what all needs to be updated in TypeOracle? I am sure you can keep track of it, but it will require keeping much more data than is currently kept so you can incrementally update TypeOracle's data structures. For example, let's say you remove an interface from a class. Even if you walk down the inheritance tree, you can't just remove that interface, because some other ancestor might have implemented it. The same sort of thing goes in many other places. Note that TypeOracle memory requirements has been a problem in the past for large internal apps. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
Am 21.08.2013 um 09:05 schrieb James Nelson : > I've long felt like highly modular projects could greatly benefit from > producing gwtar files so that unchanged code does not require recompiling. > I've thought about using a maven plugin to add .gwtar to my jars, though this > would not be a portable solution for all GWT developers. > > Any portable solution using gwtar would be to create one per module (using a > flag to enable support while still experimental), or one per java package > (maybe not a good idea given the size of some projects). > > Given that the compiler already knows to remove invalidated units, this does > seem like a feasible option. > Producing .gwtars could also be done periodically for the whole project at > the developers whim, perhaps through a flag to a standard full compile? As far as I know a usual gwtar contains only a precompiled Java AST from the first compilation phase. You still need to run the generators on all the visible code. It saves some seconds but for me the most time consuming part is the code generation and JavaScript compilation. I've currently playing around with a project where I have multiple modules. For each module I generate the initial Java AST, run code generators and throw the precompiled code in a gwttar. When building the final application only a small code generator which discovers all precomputed code runs. It's a special use case because I have defined decoupled modules which I want to link together. I'm unsure if this is any help for an "intelligent" approach :-) @John Stalcup Is it possible to contribute in this area? For example I want to ensure that the code for the project is easily adoptable to the new compiler. BTW: I agree with Stephen that Java IDE's also should be supported well. Yes SuperDevMode enabled to debug in the browser but the IDE is the tool I'm used too and I have to use the IDE for server code anyway. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
Hey John, > it means having an optional compilation path that does not recompile > the entire world (as the current monolithic compile path does) and > instead tries to recompile just files (or or modules) that have > changed. Spiffy! Out of curiosity, would the API look something like: theBackendCompile.recompile(List filesThatChanged) Such that the existing ResourceOracle/TypeOracle instances are mutated with the updated state, instead of being rebuilt? AFAIK, historically most of the optimizations around "incremental" compiles have always required going back to building ResourceOracle, TypeOracle from scratch, but speeding it up with caching. ...IIRC. It's been a little while since I've poked at the code. I know I'm being a broken record, but I think the mutative/truly incremental approach, while a (large) PITA to build, in the long run is the only solution that would be fast enough to get SuperDevMode fast enough such that it's "hit save in Eclipse, the js file is updated, done!", just like Java (and web) developers are used to. (I know Brian really doesn't like solutions that require Eclipse, but I think the same mutative/incremental compiler API could just as well be called by an Eclipse plugin or an IDEA plugin or even a Java daemon polling the file system for changes. It's not IDE-specific.) Feel free to ignore my musings given I'm not actually contributing anything to the effort; just curious as to how things are going. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
re: Heiko Braun > > it means having an optional compilation path that does not recompile the > entire world (as the current monolithic compile path does) and instead > tries to recompile just files (or or modules) that have changed. > > it is exploratory work for me right now as there are very many issues > standing in its way. > > if/when it is done and ready it should make a big impact on SuperDev mode > refresh time by reducing compile time (when compiles are run > non-monolithically) > > I've long felt like highly modular projects could greatly benefit from producing gwtar files so that unchanged code does not require recompiling. I've thought about using a maven plugin to add .gwtar to my jars, though this would not be a portable solution for all GWT developers. Any portable solution using gwtar would be to create one per module (using a flag to enable support while still experimental), or one per java package (maybe not a good idea given the size of some projects). Given that the compiler already knows to remove invalidated units, this does seem like a feasible option. Producing .gwtars could also be done periodically for the whole project at the developers whim, perhaps through a flag to a standard full compile? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
re: Heiko Braun it means having an optional compilation path that does not recompile the entire world (as the current monolithic compile path does) and instead tries to recompile just files (or or modules) that have changed. it is exploratory work for me right now as there are very many issues standing in its way. if/when it is done and ready it should make a big impact on SuperDev mode refresh time by reducing compile time (when compiles are run non-monolithically) On Sat, Aug 10, 2013 at 12:01 AM, Heiko Braun wrote: > Regarding "hello world" app running using separate compilation": can you > elaborate on that? Do you mean support for two distinct compilation units > within the same page? > > Regards,Heiko > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Google team meeting notes for August 7 (and earlier)
Regarding "hello world" app running using separate compilation": can you elaborate on that? Do you mean support for two distinct compilation units within the same page? Regards,Heiko -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Google team meeting notes for August 7 (and earlier)
I haven't been sending out emails for our meetings. Let's catch up: August 7th: - John got a "hello world" app running using separate compilation. We talked a bit about how it might get pulled back into GWT. - Brian: Firefox architecture changes may break the Development Mode plugin by the end of the year. (The ContextStack service went away [1] and word is that they will be making more architectural changes [2]. This isn't the end of Development Mode because we still have Chrome, but we should get moving on Super Dev Mode. - On the bright side, Firefox 23 has support for Source Maps. Need to try it out. - Brian will try out IntelliJ's support for Super Dev Mode. Also need to figure out Eclipse. - Need to look into support for variable names in Super Dev Mode. Ray: perhaps fix up pretty mode to work better? We can rename variables less often. - Fixing up stack traces is a project. We should save the original JavaScript exception and make sure that gets printed to the JavaScript console. Brian will start a design doc. - Talked about internal use of mgwt for mobile apps. - Need to figure out benefits of GWT.create() changes proposed by contributors. Concerned that it will prevent compiler improvements. [1] https://gwt-review.googlesource.com/#/c/3933/ [2] http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/ July 31: - Deadline for GWT.create() talks coming up. Talked about plans. - Brian: GWT.log() works in Super Dev Mode; working on GWT.debugger(), Firefox plugin release. - John and Ray talked about incremental compilation - Matthew: Gerritt working again. - Ray got automatic recompile working in Super Dev Mode for a Google team - Talked about Goktug's JsInterop proposal [3]. Ray: Elemental would be a lot simpler. - Would it work with Dev Mode? Not optimistic. - Talked about Web Components. [3] https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit July 24: - Talked about providing a benchmark to the v8 team to improve GWT performance. - Talked about JsInterop proposal. - Talked about code generation bug [4] - Gerrit server was messed up. [4] https://code.google.com/p/google-web-toolkit/issues/detail?id=8284 July 17: - Talked about JSInterop. - Can GSS be separately compiled/changed without recompiling the whole app? Put this into the build-time improvement bucked. - Talked about GWT.create conference. - Roberto: fixed issues with field initialization; initial fragment may be smaller. - Mike Brock not at Red Hat; effect on steering committee? -- 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.
