[gwt-contrib] ModuleDefLoader changes and CompilerContext
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. 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? 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.
Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext
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
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.comjavascript: 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.comjavascript: . 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
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.
