> 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 lik
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:
@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
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 l
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
unconsi
>
> 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 ther
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 po
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
Hi Colin, please find my answers inline:
On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth wrote:
> I got a tweet from you asking for a donation (or rather a 'partner', which
> apparently means 'money'), but couldn't frame a useful response in 140
> chars, so since this thread is coming back, I th
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
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 po
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:
theB
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 m
13 matches
Mail list logo
