Ah, thanks for getting to the bottom of it. I agree that we should opt to
use more RAM rather than have randomly slower compiles. And it would be
nice to cherry pick the change into the release branch.
On Mon, Oct 20, 2014, 9:39 PM Stephen Haberman
wrote:
>
> Well, this is somewhat anti-climatic
Well, this is somewhat anti-climatic, but, AFAICT, it was just
MemoryUnitCache's maps using soft values.
Instead of turning on TRACE everywhere, I upgraded
MinimalRebuildCache's "known modified type" output to WARN. (It would
be great to have log4j-style package-level knobs in the GWT log
output.
> I think that CL is only on master. Thats why I said try master and if
> it works send me a cherry pick for the CL :)
$ git branch -a --contains 14f27064497f11
master
* release/2.7
remotes/gerrit/HEAD -> gerrit/master
remotes/gerrit/master
remotes/gerrit/release/2.7
I also opened the 2.
I think that CL is only on master. Thats why I said try master and if it
works send me a cherry pick for the CL :)
On Tue, Oct 21, 2014 at 12:26 AM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:
>
> > However, right, it didn't actually make it into 2.7-beta1.
>
> Crap. Eclipse was lying t
> However, right, it didn't actually make it into 2.7-beta1.
Crap. Eclipse was lying to me, and had a 2.6.x source jar hooked up to
gwt-dev-2.7-beta1.jar (don't ask) when I pulled up PersisentUnitCache
in my project to check for the change.
So: a) 2.7-beta1 does have John's 14f2706 fix, and b) e
> I think it's in master now (commit 14f27064497f1171907d0ecbe01a4d2991a7a855)
Oh shoot; I was wondering if that's what Roberto was referring to.
I assumed 2.7-beta1 already had that fix, because I saw it on the
release/2.7 branch in gerrit (and a few commits down/non-cherry picked).
However, r
Stephen can you verify that this solved your problem and if so cherry pick
it to the branch and add me as a reviewer?
On Mon, Oct 20, 2014 at 10:02 PM, 'John Stalcup' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> I think it's in master now
> (commit 14f27064497
I think it's in master now (commit 14f27064497f1171907d0ecbe01a4d2991a7a855)
On Sun, Oct 19, 2014 at 7:51 PM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:
>
> > depends on how many files are modified [+ invalidations]
>
> Yeah, sorry, I should have mentioned I've only been changing one f
> depends on how many files are modified [+ invalidations]
Yeah, sorry, I should have mentioned I've only been changing one file,
just adding/removing a character in a string.
> John detected that behavior in the persistent unit cache and has a
> fix for it.
Great! I'll try it out when it hits
John detected that behavior in the persistent unit cache and has a fix for
it.
On Oct 19, 2014 7:16 PM, "Stephen Haberman"
wrote:
>
> > ...and, right now, I can't even get the 3s time to kick in again.
>
> Ah ha...seems to be something with the PersistentUnitCache.
>
> When the recompile is 10-20
> ...and, right now, I can't even get the 3s time to kick in again.
Ah ha...seems to be something with the PersistentUnitCache.
When the recompile is 10-20s every time, I see output of:
Wrote 4944 units to persistent cache
Wrote 1 units to persistent cache
(reload)
Wrote 4944 un
11 matches
Mail list logo
