[gwt-contrib] Re: UnifyAst correctly handles polymorphic overrides with mixed default/public access. (issue1470803)

[Scott Blum]

On Wed, Jul 6, 2011 at 12:07 PM, Eric Ayers  wrote:

> So, the tests in the back-end issue are valid, but the GwtAstBuilder patch
> is superceded.  Could you roll the tests into issue 1470803?


Lemme clarify.

The tests in the back-end are valid tests, which fail both with
GwtAstBuilder and without it.  It's a latent, existing bug in our back end
which 1470803 doesn't fix.  1469804 was my initial attempt to fix it, but
doesn't work.  We cannot commit the tests right now as we have no fix for
them.

1470803 merely brings GwtAstBuilder up to parity with the old compiler to
solve the front end issue.  This solves SOME currently broken cases, but not
all possible cases as the tests in 1469804 demonstrate.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Bug triggered in SourceFileCompilationUnit.asCachedCompilation() (issue1461803)

[Scott Blum]

Now that's a good answer!  So the real is is just to close the result of
sourceFile.openContents()?

I would update the doc on DiskCache.tranferTo/FromStream that they don't
close the stream, and then look at all the callers and make sure they do the
right thing.

On Fri, Jun 24, 2011 at 10:36 PM,  wrote:

> Found the reason it fixes it.
> The machine I'm testing on is not tuned for lots of files:
>
>  [java] Caused by: java.io.FileNotFoundException:
> /home/testing/gwt-orig/us\
> er/src/com/google/gwt/i18n/**client/impl/cldr/**
> DateTimeFormatInfoImpl_eu.java
> (Too\
>  many open files)
> [java] at java.io.FileInputStream.open(**Native Method)
> [java] at
> java.io.FileInputStream.**(FileInputStream.java:137)
> [java] at
> com.google.gwt.dev.resource.**impl.FileResource.**openContents(F\
> ileResource.java:63)
> [java] ... 7 more
>
> The root cause is that the the original code doesn't close the stream
> returned from Resource.openContents().  Everywhere else that
> diskCache.transferFromStream() is used, its in the context of a
> readObject() override, so this is the only place where this would cause
> a problem.
>
> FYI, here's the original stack trace.  I've seen them before but not in
> such a reproducable way
>
>  [java] [ERROR] Unexpected internal compiler error
> [java] java.lang.NullPointerException
> [java] at
> com.google.gwt.dev.util.**DiskCache.transferFromStream(**
> DiskCache.java:154)
> [java] at
> com.google.gwt.dev.javac.**SourceFileCompilationUnit.**
> asCachedCompilationUnit(**SourceFileCompilationUnit.**java:59)
> [java] at
> com.google.gwt.dev.javac.**CompilationUnitArchive.**addUnit(**
> CompilationUnitArchive.java:**88)
> [java] at
> com.google.gwt.dev.**CompileModule.run(**CompileModule.java:283)
> [java] at
> com.google.gwt.dev.**CompileModule$1.run(**CompileModule.java:162)
> [java] at
> com.google.gwt.dev.**CompileTaskRunner.doRun(**CompileTaskRunner.java:88)
> [java] at
> com.google.gwt.dev.**CompileTaskRunner.**runWithAppropriateLogger(**
> CompileTaskRunner.java:82)
> [java] at
> com.google.gwt.dev.**CompileModule.main(**CompileModule.java:165)
>
>
>
>
>
>
>
>
> http://gwt-code-reviews.**appspot.com/1461803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Suppress additional JDT compile problems (issue1461804)

[Scott Blum]

On Fri, Jun 24, 2011 at 10:02 PM,  wrote:

> Sounds good; I was hoping for some kind of "for good measure" reason
> like that. I've been translating GwtAstBuilder/ReferenceMapper to
> jribble versions and had to skip over this part because jribble only has
> textual ASTs, so when I come across external types, I can't fill these
> in.


Definitely hack around, and if everything works ok without resolving the
hierarchy, great! :)

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Ignore invalid types in heirarchy (issue1466806)

[Scott Blum]

On Fri, Jun 24, 2011 at 8:35 AM,  wrote:

> So, what you are saying is that we are getting lots of unrelated errors
> for units that reference foo that are obscuring the real problem?


The unrelated units are actually causing a blow-up.  When we try to
construct the type hierarchy to represent Foo (as seen by the valid units),
it blows up.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add concrete SourceInfo for varargs in method calls (issue1454801)

[Scott Blum]

SGTM, I'll double-check my settings.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: This patch substantially reduces the overhead of Java types in the output by minimizing vtable s... (issue1447821)

[Scott Blum]

Don't worry about it, since I'm punting the review over to Jason and Eric.
:P

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: JavaAstConstructor uses UnifyAst. (issue1453810)

[Scott Blum]

What Eric said.  I haven't nailed down all the error reporting yet (although
it's closer now), but the idea is that we really can avoid reporting errors
on unreachable types.  And not reaching code means fewer deserialized types,
which is better for memory and takes less time.  But there's an even bigger
one...

When code flow reaches GWT.create() calls, we have to run rebinds, and
therefore generators, and reach even more code.  So there's a spiraling
effect.  JDT used to limit the total reach by only pulling in the types
necessarily to finish a compilation.  If we didn't do SOME kind of prune
off, we might end up being SLOWER than before.  Since we have to do some
prune off then, it makes sense to do a good job with it.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: I don't believe in magic, but as Scott points out, there are consistent (issue1453804)

[Scott Blum]

LOL

On Sun, Jun 5, 2011 at 1:50 PM,  wrote:

> srsly, we don't want this kind of thing to be happening:
>
> http://www.wsbtv.com/news/**28127904/detail.html
>
>
>
> http://gwt-code-reviews.**appspot.com/1453804/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add concrete SourceInfo for varargs in method calls (issue1454801)

[Scott Blum]

Be sure to get the one in GwtAstBuilder too.  But don't makeChild() there,
just use the existing reference.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Dollar sign and binary types

[Scott Blum]

You wouldn't have to hack TypeOracle. You could just look for your
particular annotation to see what was a Jribble type.

On Sun, May 29, 2011 at 1:47 PM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> 2011/5/29 Scott Blum 
>
>> On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski <
>> grzegorz.kossakow...@gmail.com> wrote:
>>
>>> I cannot comment on your proposals because I don't know gwt internals
>>> enough. I decided to add a method to TypeOracle that allows me to ask if
>>> given type comes from Java or Jribble. If it's Jribble I don't try to do any
>>> conversions.
>>>
>>> This is ugly and fragile method but seems to be the only viable strategy
>>> for now. If you guys can come up with systematic solution to this problem it
>>> would be awesome.
>>>
>>
>> Use an annotation.
>>
>
> You mean putting annotation to every Jribble type? How that would help?
>
> Also, I thought you'd enjoy this question:
> http://stackoverflow.com/questions/6167326/java-class-name-containing-dollar-sign
>
> Seems like javac can confuse itself about dollar sign, sigh.
>
> --
> Grzegorz Kossakowski
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Dollar sign and binary types

[Scott Blum]

On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> I cannot comment on your proposals because I don't know gwt internals
> enough. I decided to add a method to TypeOracle that allows me to ask if
> given type comes from Java or Jribble. If it's Jribble I don't try to do any
> conversions.
>
> This is ugly and fragile method but seems to be the only viable strategy
> for now. If you guys can come up with systematic solution to this problem it
> would be awesome.
>

Use an annotation.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Dollar sign and binary types

[Scott Blum]

The compiler internals could be coded to use binary names.  Obviously,
generators would do something sensible.

For example, I know that rebind rules in gwt.xml are tracked by source name.
 Well, those could get looked up in TypeOracle and translated to the
appropriate binary name and tracked that way.  You would always to one-way
conversions from source->binary and never back.

On Fri, May 27, 2011 at 1:01 PM, John Tamplin  wrote:

> On Fri, May 27, 2011 at 12:53 PM, Scott Blum  wrote:
>
>> On Fri, May 27, 2011 at 10:12 AM, John Tamplin  wrote:
>>
>>> I don't think that solves the problem -- let's say we store Foo/Bar$Baz
>>> internally and convert it to a source name where needed.  How do we know
>>> whether the class name is Bar$Baz or Baz inside of Bar?  The problem is
>>> simply if you allow $ in a class name, binary and internal names are lossy
>>> too as they no longer encode the difference.
>>>
>>
>> My point is to NOT convert it to source names, do everything in binary.
>>
>
> So when you generate source code, how do you do that?  Or let's just say
> you want to get the simple class name -- in the example, is it Bar$Baz or
> Baz?  The point is you don't have the information necessary to tell.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Dollar sign and binary types

[Scott Blum]

On Fri, May 27, 2011 at 10:12 AM, John Tamplin  wrote:

> I don't think that solves the problem -- let's say we store Foo/Bar$Baz
> internally and convert it to a source name where needed.  How do we know
> whether the class name is Bar$Baz or Baz inside of Bar?  The problem is
> simply if you allow $ in a class name, binary and internal names are lossy
> too as they no longer encode the difference.
>

My point is to NOT convert it to source names, do everything in binary.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Dollar sign and binary types

[Scott Blum]

What John said.  Blame Java for the fact that with some lookup oracle, it's
impossible to distinguish the cases.  We've always assumed that users would
not use '$' in class names in places where it matters.

That being said, let's assume that a user isn't allowed to have both A.B and
A$B like Toby said, as the binary names would collide.  Given that, I
*think* the only place source type name really matters is resolving rebind
requests and results.  So maybe it's possible we could use only binary name
or internal name everywhere and move away from using source name except in
output messages.

On Fri, May 27, 2011 at 9:50 AM, John Tamplin  wrote:

> On Fri, May 27, 2011 at 4:45 AM, Grzegorz Kossakowski <
> grzegorz.kossakow...@gmail.com> wrote:
>
>> 2011/5/26 Eric Ayers :
>> > Unfortunately, I tried removing the replace('$',".") and it failed
>> > miserably.  Looking at it in the debugger, those really are binary
>> names.
>> > e.g.:
>> > com.google.gwt.core.client.impl.AsyncFragmentLoader$LoadingStrategy
>>
>> Thanks guys for you answers. I moved on with my work-around. It would
>> be great if those binary names were converted to source names as soon
>> as possible so number of places in gwt code where we have to consider
>> both options is minimized.
>>
>
> The problem is conversion to source names is lossy -- given Foo.Bar.Baz,
> you don't know where the split between the package name, enclosing class
> name, and class name is (compare to Foo/Bar$Baz and Foo/Bar/Baz).  I think
> the only way you could avoid this problem is if you kept a structured type
> with those pieces of information rather than a simple string, but that would
> be expensive in terms of allocating several additional objects for every
> class name in the program, plus many uses don't care about the distinctions
> and just wand the source name.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Autoformats user/super and user/test-super (issue1442805)

[Scott Blum]

I'm not sure what all that means, but shouldn't GPE be able to just turn the
code formatter on automatically?

On Tue, May 24, 2011 at 1:00 PM, Eric Ayers  wrote:

> Alex added a new eclipse application to GPE.  If you've got his latest
> and greatest (not sure if its public yet)
>
>  eclipse -nosplash -application
> com.google.gwt.eclipse.core.GWTCodeFormatterApplication  formatting opts>[ list of files and/or dirs ]
>
>
> On Tue, May 24, 2011 at 12:55 PM,   wrote:
> > Whoa, do you really have autoformatting JSNI working?  If so, that is
> > totally awesome!
> >
> > http://gwt-code-reviews.appspot.com/1442805/
> >
>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re-implement runAsync to improve code size. (issue1442807)

[Scott Blum]

Yeah, sorry.  "old" = what is now committed and "new" = this patch.

On Fri, May 20, 2011 at 9:41 AM,  wrote:

> I'm missing some contect here.  I  don't know what you mean by 'new' and
> old implementations of runAsync.  How new is new (this cl? something
> already committed or a project in the works?)
>
>
>
> http://gwt-code-reviews.appspot.com/1442807/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Pruner runs only once. (issue1436802)

[Scott Blum]

Cool beans.

On Mon, May 16, 2011 at 8:14 PM, Ray Cromwell wrote:

> I've done a quick scan of this and it looks ok, but I'd like to take
> some time tonight to review it in more detail. I like the
> 'membersLiveExceptForInstantiability' change, I was going the suggest
> something like that when I was doing the JSO CFA overhaul last time.
> Also the checks in Pruner are simpler now.
>
>
>
> On Fri, May 13, 2011 at 11:37 AM, Scott Blum  wrote:
> > On Fri, May 13, 2011 at 11:15 AM, Eric Ayers  wrote:
> >>
> >> I've been reading the code and talking to Scott about it.  The loop
> >> being removed is the while() loop in execImpl().  The "jitter" is the
> >> fact that the ControlFlowAnalyzer might return one result for liveness
> >> before the Pruner runs, and a different result after Pruner runs.  If
> >> you don't loop inside of Pruner, then the entire optimization pass may
> >> have to run extra times.
> >
> > Great explanation!
> > The last time we tried to naively remove the while loop from Pruner, the
> > outer optimization loop went from ~7 passes to ~10 passes for Showcase,
> and
> > the total optimization time went up.
> > You can think of my patch as "converging faster".  With my patch in and
> the
> > Pruner loop gone, you still only get ~7 outer optimization loops, and the
> > total optimization time goes down.
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Decentralize nullmethod/nullfield (issue1442802)

[Scott Blum]

On Sat, May 14, 2011 at 9:22 AM,  wrote:

> I know I've asked this before, but if code isn't live in the runer, we
> replace it with null.nullMethod(), null.nullField or the likes.  Why do
> we keep this around?  Dead Code elimination usually gets rid of it (but
> not always?) is it just left there to trip over at run time in case
> there is a bug in our liveness tests?


It's a correct translation of code where static analysis proves that a
qualifier is null.

User code:
String s = null;
s.toCharArray();

Translation:
null.nullMethod();

That way, we throw an NPE in the correct place at runtime.  Or more
technically, it generates an implicit null ref JavaScriptException.  If it
weren't for the desire to match the platform semantics, we could just as
easily replace it with "throw new NullPointerException()".

Arguably, we could just leave it as "null.toCharArray()", but the whole idea
is to remove 'toCharArray()" from the AST, and we wouldn't want to leave a
dangling reference to it that we'd have to worry about later.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Pruner runs only once. (issue1436802)

[Scott Blum]

On Fri, May 13, 2011 at 11:15 AM, Eric Ayers  wrote:

> I've been reading the code and talking to Scott about it.  The loop
> being removed is the while() loop in execImpl().  The "jitter" is the
> fact that the ControlFlowAnalyzer might return one result for liveness
> before the Pruner runs, and a different result after Pruner runs.  If
> you don't loop inside of Pruner, then the entire optimization pass may
> have to run extra times.


Great explanation!

The last time we tried to naively remove the while loop from Pruner, the
outer optimization loop went from ~7 passes to ~10 passes for Showcase, and
the total optimization time went up.

You can think of my patch as "converging faster".  With my patch in and the
Pruner loop gone, you still only get ~7 outer optimization loops, and the
total optimization time goes down.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Enables on the persistent unit cache by default. (issue1448801)

[Scott Blum]

SGTM.  At some point I'll have to deal with versioning for the embedded GWT
ASTs, but I can burn that bridge when I come to it.

On Thu, May 12, 2011 at 6:48 PM,  wrote:

> I know the paint is still drying on the last patch I submitted for the
> Persistent Unit Cache, but no real problems have been reported in...
> weeks!  I think its ready to be on by default.
>
>
> http://gwt-code-reviews.appspot.com/1448801/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Rescues cached entries from jar files that are the same, save for the timestamp. (issue1441803)

[Scott Blum]

On Wed, May 11, 2011 at 10:57 PM,  wrote:

> this needs to return a copy. all other implementations of
> asCachedCompilationUnit() already return a copy.


That would make CachedCompilationUnit.writeReplace() be weird tho, right?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)

[Scott Blum]

I mean only super-sourced.  Does Object come through as
'com/google/gwt/emul/java/lang/Object.java' or merely
'java/lang/Object.java'?

On Tue, May 3, 2011 at 2:56 PM,  wrote:

> On 2011/05/03 18:45:15, scottb wrote:
>
>> LGTM.  Like Toby said, this is much better.
>>
>
>  Can you confirm that re-rooted resources retain their original
>>
> (non-rerooted)
>
>> path location?
>>
>
> What do you mean by re-rooted resources? super sourced resources?  One
> thing I looked at was that generated resources create their path from
> the type name, but I don't think they get re-rooted if what you mean
> that is items that have been super sourced.
>
>
>
> http://gwt-code-reviews.appspot.com/1428805/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix a class of compiler bugs related to staticImpl. (issue1428804)

[Scott Blum]

On Wed, Apr 27, 2011 at 3:20 PM,  wrote:

> If I understand correctly, part of staticification is that all
> call-sites to myVar.foo(x) will be replaced by $foo(myVar, x), and thus
> foo(x) will be unused, and thus pruned.  So, the delegation issues goes
> away, no?


Yes, as long as all call sites can be devirtualized, the instance method
goes away.

On Wed, Apr 27, 2011 at 3:51 PM,  wrote:

> It looks like there might be some logic in
> ControlFlowAnalyzer.RescueVisitor.Rescue, which can also be removed if
> inlining staticImpl's is not an issue.


Whoops!  Yes, I need to remove that, my bad.

On Wed, Apr 27, 2011 at 4:34 PM,  wrote:

> I see now (looking at MakeCallsStatic.RewriteCallSites) that not all
> call sites get replaced, there are a few edge cases, relating to split
> points, etc., where the call sites are not replacedBut I'm guessing
> it won't be a large number of cases.


Yes, there will be cases where both the instance and static method make it
into the final output.  In some of those cases, JsInliner will actually do
the inlining.  In others, my theory is that not inlining them won't have a
negative effect on code size.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix a class of compiler bugs related to staticImpl. (issue1428804)

[Scott Blum]

If the Java MethodInliner kept call counts, I would have special-cased it to
allow inlining the static into the instance when it's the only caller.  But
since call counts aren't already computed, I decided it would be best to try
it out as is and see if it actually increases code size in practice.

On Wed, Apr 27, 2011 at 2:20 PM, Ray Cromwell wrote:

>
> As long as the JsInliner can still clean it up, I'm fine, otherwise, it
> seems like it would introduce some bloat by having trivial delegations. I'm
> actually wondering if we should detect the case when a static method ONLY is
> referenced by the instance method it was created from via delegation, and
> *anti-staticify* it, e.g.
>
> function foo(x) {
>foo$(this, x);
> }
>
> function foo$(this$static, x) {
>this$static.x=x;
> }
>
> becomes
>
> function foo(x) {
>   this.x=x;
> }
>
> -Ray
>
>
> On Mon, Apr 25, 2011 at 6:46 PM,  wrote:
>
>> Reviewers: cromwellian, jbrosenberg,
>>
>> Message:
>> Ran into this general class of issue... originally I set out to add
>> staticImpl handling logic to a couple more places, such as
>> ImplicitUpcastAnalyzer.  But the more I thought about it, the more it
>> struck me as a real wart, and one that's not giving us much value.
>> Perhaps even negative value by causing code bloat.  I think it's much
>> simpler to just never inline staticImpls into the calling virtual
>> method.
>>
>>
>>
>> Please review this at http://gwt-code-reviews.appspot.com/1428804/
>>
>> Affected files:
>>  M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
>>  M dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
>>  M
>> dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
>>  M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
>>
>>
>> Index: dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
>> diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
>> b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
>> index
>> d7f5f3fecfdb50302c7a723d3d9ead02d30d9e50..92eb2bb156eaee1683049a95472d1d7f9ce09c0d
>> 100644
>> --- a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
>> +++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
>> @@ -145,6 +145,20 @@ public class MethodInliner {
>> @Override
>> public boolean visit(JMethod x, Context ctx) {
>>   currentMethod = x;
>> +  if (program.getStaticImpl(x) != null) {
>> +/*
>> + * Never inline a static impl into the calling instance method.
>> We used
>> + * to allow this, and it required all kinds of special logic in
>> the
>> + * optimizers to keep the AST sane. This was because it was
>> possible to
>> + * tighten an instance call to its static impl after the static
>> impl had
>> + * already been inlined, this meant any "flow" type optimizer
>> would have
>> + * to fake artifical flow from the instance method to the static
>> impl.
>> + *
>> + * TODO: allow the inlining if we are the last remaining call
>> site, and
>> + * prune the static impl? But it might tend to generate more
>> code.
>> + */
>> +return false;
>> +  }
>>   return true;
>> }
>>
>> Index: dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
>> diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
>> b/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
>> index
>> 0ffdcf40faefc2fdc8b3c4ecf293c2ac372d5568..0b67077fe1db9ca11caf48e0fd5be80f15815e0e
>> 100644
>> --- a/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
>> +++ b/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
>> @@ -360,7 +360,8 @@ public class Pruner {
>>
>>   for (int i = 0; i < type.getMethods().size(); ++i) {
>> JMethod method = type.getMethods().get(i);
>> -if (!methodIsReferenced(method) ||
>> pruneViaNoninstantiability(isInstantiated, method)) {
>> +if (!referencedNonTypes.contains(method)
>> +|| pruneViaNoninstantiability(isInstantiated, method)) {
>>   // Never prune clinit directly out of the class.
>>   if (i > 0) {
>> type.removeMethod(i);
>> @@ -394,7 +395,7 @@ public class Pruner {
>>   for (int i = 1; i < type.getMethods().size(); ++i) {
>> JMethod method = type.getMethods().get(i);
>> // all other interface methods are instance and abstract
>> -if (!isInstantiated || !methodIsReferenced(method)) {
>> +if (!isInstantiated || !referencedNonTypes.contains(method)) {
>>   type.removeMethod(i);
>>   madeChanges();
>>   --i;
>> @@ -426,6 +427,8 @@ public class Pruner {
>>  * devirtualizations. If the instance method has been pruned, then
>> it's
>>  * okay. Also, it's okay on the final pass since no more
>>  * devirtualizations will occur.
>> + *
>> + * TODO: prune params; MakeCallsStatic smarter to account for it.
>>  */
>> JMethod stat

[gwt-contrib] Re: EnumOrdinalizer cleanup & better interop. (issue1426804)

[Scott Blum]

Based on your comments, I'm going to rework the patch.  You're right, I was
totally confused about the difference between
ReplaceEnumTypesWithInteger & ReplaceOrdinalFieldAndMethodRefsWithOrdinal.
 I think the JField / JFieldRef replacements in the former are what threw
me.  I'll rework the patch.

By valid state of the AST, I had run into a case in some work I was doing
where you had by analogy the equivalent of EnumType x = 3, and TypeTightener
was needing to clean up after.  But I think now that what I needed to do in
my patch was update TypeRemapper instead.  Lemme rework this and see what
falls out.

On Tue, Apr 26, 2011 at 3:12 PM,  wrote:

> Scott, would you mind, for my own edification, outlining how this
> improves the "valid state" of the AST after EnumOrdinalizer runs?
> Thanks.
>
>
> http://gwt-code-reviews.appspot.com/1426804/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re-architect how overrides are handled. (issue1422810)

[Scott Blum]

It actually does fix the abstract getClass() problem, I was noticing in the
generated output.  I'll mark my change as fixing this issue.

On Tue, Apr 26, 2011 at 4:03 AM,  wrote:

> Hey, it looks like it would fix this issue, cool!
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4893
> According to my tests at the time, it would enable pruning of most
> getClass() methods (at a minimum all those for abstract classes, which
> are always overridden in the concrete classes, and then never executed):
> http://gwt-code-reviews.appspot.com/609801/show
>
>
> http://gwt-code-reviews.appspot.com/1422810/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Small generator testing framework (issue1424805)

[Scott Blum]

Yeah, they're in an impl package.

On Tue, Apr 19, 2011 at 11:12 AM,  wrote:

> I think the idea here is that no one (outside the existing GWT tests)
> should reference the *Resource classes directly - that's why we have the
> new interface Source. This way, you should be able to refactor the
> *Resource classes without breaking anyone, especially the original
> Resource interface.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Supress errors when building the Type Oracle. (issue1385810)

[Scott Blum]

On Thu, Mar 31, 2011 at 7:38 PM, Eric Ayers  wrote:

> It was kind of disruptive to pass the suppressErrors setting around
> through method parameters.  I assume that's what you're talking about.
>

Yeah.


> The good thing about logging inside of CompilationStateBuilder is that
> there is a concious decision about what to do with errors when you
> build the CompliationState.


Yeah, but this sort of flips it around and says, "If you want errors, log
them."


> Another small
> wrinkle is that in JavaToJavaScript compiler we've ditched the
> CompilationState to save memory before the time we want to report
> errors (but we could always just keep it or some subset of the data
> and log them at a TRACE/DEBUG level like this patch does.)


The new translator stuff I'm working on is going to get rid of that code
path, however.  It will work a lot more like CompilingClassLoader, and
explicitly log errors one unit at a time as you need to reference a unit
that had errors.  The compilation state will have to be around until after
we have the AST built out.

Scott

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: LongLibBase improperly stomps on global 'a' variable. This patch reuses globalTemp (_) instead. (issue1389803)

[Scott Blum]

Sounds good.  Now that I think about it, it may not make much performance
difference if time tends to be dominated by the actual math ops, but I
suppose every bit helps?

On Tue, Mar 29, 2011 at 10:35 AM, Daniel Rice (דניאל רייס)
wrote:

> I did the reimplementation.  Being less familiar with the intricacies of
> JavaScript, it seems likely that I missed an opportunity to preserve the
> nativeness of the array.  I'd be happy to take a look at this after the 2.3
> release.
>
> On Mon, Mar 28, 2011 at 5:52 PM, Scott Blum  wrote:
>
>> Something smells fishy here.  I'm quite certain that this used to be
>> implemented strictly as a two-double array in web mode, a true array.  At
>> some point it was modified to use 3 elements instead of 2, but I don't think
>> it should have lost its nativity.
>>
>>
>> On Mon, Mar 28, 2011 at 5:36 PM,  wrote:
>>
>>>
>>>
>>> http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java
>>> File dev/core/super/com/google/gwt/lang/LongLibBase.java (right):
>>>
>>>
>>> http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java#newcode325
>>> dev/core/super/com/google/gwt/lang/LongLibBase.java:325: _.l = l, _.m =
>>> m, _.h = h, _);
>>> On 2011/03/28 21:31:25, scottb wrote:
>>>
>>>> Stupid question, but why can't we just return {l:l, m:m, h:h}?
>>>>
>>>
>>> Good question. It looks like LongEmul is not a JSO, because they want to
>>> reuse it in both JVM and ProdMode, so it's a Java type. This code may
>>> have existed before @GwtScriptOnly or SingleJsoImpl. If I were during
>>> this today, I'd make LongEmul an interface, use JSO for ProdMode, and
>>> JRE impl for everything else.
>>>
>>> I guess we'll revisit it later.
>>>
>>>
>>> http://gwt-code-reviews.appspot.com/1389803/
>>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: LongLibBase improperly stomps on global 'a' variable. This patch reuses globalTemp (_) instead. (issue1389803)

[Scott Blum]

Something smells fishy here.  I'm quite certain that this used to be
implemented strictly as a two-double array in web mode, a true array.  At
some point it was modified to use 3 elements instead of 2, but I don't think
it should have lost its nativity.

On Mon, Mar 28, 2011 at 5:36 PM,  wrote:

>
>
> http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java
> File dev/core/super/com/google/gwt/lang/LongLibBase.java (right):
>
>
> http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java#newcode325
> dev/core/super/com/google/gwt/lang/LongLibBase.java:325: _.l = l, _.m =
> m, _.h = h, _);
> On 2011/03/28 21:31:25, scottb wrote:
>
>> Stupid question, but why can't we just return {l:l, m:m, h:h}?
>>
>
> Good question. It looks like LongEmul is not a JSO, because they want to
> reuse it in both JVM and ProdMode, so it's a Java type. This code may
> have existed before @GwtScriptOnly or SingleJsoImpl. If I were during
> this today, I'd make LongEmul an interface, use JSO for ProdMode, and
> JRE impl for everything else.
>
> I guess we'll revisit it later.
>
>
> http://gwt-code-reviews.appspot.com/1389803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add a buffered input stream when reading persistent unit cache (issue1386807)

[Scott Blum]

Oh, did I?  LOL, I have no recollection.  I don't remember that and meant my
comment seriously. :)

On Mon, Mar 28, 2011 at 5:40 PM,  wrote:

> On 2011/03/28 20:45:46, scottb wrote:
>
>> LGTM, good cache on the BufferedInputStream
>>
>
> Yes, Scott, that was a good catch you made.
>
> Submitted as r9904
>
>
>
> http://gwt-code-reviews.appspot.com/1386807/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add missing tests to JavaCompilationSuite (issue1385808)

[Scott Blum]

Thanks, it is really nice for Eclipse testing.

On Fri, Mar 25, 2011 at 9:56 PM, Eric Ayers  wrote:

> LGTM
>
> I didn't think maintaining this suite was a priority - the ant build
> searches for *Test.java and ignores the suite.  I guess if you are
> manually testing from eclipse its useful.
>
> On Fri, Mar 25, 2011 at 8:10 PM,   wrote:
> > Reviewers: zundel,
> >
> >
> >
> > Please review this at http://gwt-code-reviews.appspot.com/1385808/
> >
> > Affected files:
> >  M dev/core/test/com/google/gwt/dev/javac/JavaCompilationSuite.java
> >
> >
> > Index: dev/core/test/com/google/gwt/dev/javac/JavaCompilationSuite.java
> > diff --git
> > a/dev/core/test/com/google/gwt/dev/javac/JavaCompilationSuite.java
> > b/dev/core/test/com/google/gwt/dev/javac/JavaCompilationSuite.java
> > index
> >
> dc61d2436d7d032cf05b6a88bbbd22b59d7a53f8..40730954464cc12237d9a293d4454582f0a5f20c
> > 100644
> > --- a/dev/core/test/com/google/gwt/dev/javac/JavaCompilationSuite.java
> > +++ b/dev/core/test/com/google/gwt/dev/javac/JavaCompilationSuite.java
> > @@ -42,15 +42,20 @@ public class JavaCompilationSuite {
> >
> > suite.addTestSuite(ArtificialRescueCheckerTest.class);
> > suite.addTestSuite(BinaryTypeReferenceRestrictionsCheckerTest.class);
> > +suite.addTestSuite(BytecodeSignatureMakerTest.class);
> > suite.addTestSuite(CompilationStateTest.class);
> > suite.addTestSuite(CompilationUnitFileReferenceTest.class);
> > +suite.addTestSuite(CompiledClassTest.class);
> > suite.addTestSuite(GWTProblemTest.class);
> > suite.addTestSuite(JavaSourceParserTest.class);
> > suite.addTestSuite(JdtBehaviorTest.class);
> > suite.addTestSuite(JdtCompilerTest.class);
> > -suite.addTestSuite(JSORestrictionsTest.class);
> > suite.addTestSuite(JsniCheckerTest.class);
> > suite.addTestSuite(JsniCollectorTest.class);
> > +suite.addTestSuite(JSORestrictionsTest.class);
> > +suite.addTestSuite(MemoryUnitCacheTest.class);
> > +suite.addTestSuite(PersistentUnitCacheTest.class);
> > +suite.addTestSuite(TypeOracleMediatorFromByteCodeTest.class);
> > suite.addTestSuite(TypeOracleMediatorFromSourceTest.class);
> >
> > suite.addTestSuite(CollectClassDataTest.class);
> >
> >
> >
>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds a cache (PersistenUnitCache) to store CompilationUnits (issue1375802)

[Scott Blum]

On Wed, Mar 23, 2011 at 1:02 PM, Eric Ayers  wrote:

> FYI: I am adding a call to return the resource location to the
> CompilationUnit to handle changing the key.


That's what CompilationUnitBuilder.getLocation() was used for and in
practice, CompilationUnit.getDisplayLocation() returns exactly the same
value and serves exactly the same purpose, although you'd need to update the
antiquated Javadoc that suggests otherwise.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds a cache (PersistenUnitCache) to store CompilationUnits (issue1375802)

[Scott Blum]

On Wed, Mar 23, 2011 at 9:57 AM,  wrote:

> If we only write the cache to the same war dir subdirectory, then I
> think my concerns with purging the cache are solved (the cache will be
> in a well known place).  I'm still going to make an exception so that
> setting a system property will allow the cache to be written to a
> specific dir so we can support the caching from GWTShell invocations,
> but I'll remove it from GWTCompiler, Precompile and PrecompileOneShard.
>

SGTM.

I'll change the key to lookup by resource name, but that's going to
> cause some indigestion for the "spam error message" reduction patch I've
> been working on.  If there is ambiguity caused by super source, then
> that problem needs to be resolved anyway.


It's not a true ambiguity  imagine you're running two apps at once in
dev mode.  The first module has a "com.example.Foo" at
'com/example/Foo.java'.  The second module has a totally different
implementation because it uses super source to get the copy at
'com/example/super/com/example/Foo.java'.  These are literally two different
compilation units with different source, mod times, and outputs.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Are there any docs describing internals of gwtc?

[Scott Blum]

On Mon, Mar 21, 2011 at 10:10 AM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> The problem I described above (broken polymorphic calls) was caused by
> superClass field being equal to null for nodes representing
> interfaces. That would lead to broken overrides calculations for an
> interface containing method called toString (that overrides one from
> java.lang.Object) and thus to broken JS output. That was fairly
> non-trivial to find because you need toString being called through an
> interface to trigger that behaviour.
>
> Now, I'm wondering if it wouldn't make sense to have an assertion in
> some place checking that whether interfaces have java.lang.Object as
> their superClass as it seems to be invariant for GWT.


I seem to recall at one point we actually put some thought into not having
super interfaces have a superClass field at all, and just always have the
compiler implicitly assume Object.  Not sure where that idea went, or why we
ended up not doing that.

Scott

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Moving UnitTestTreeLogger from dev/core/src to dev/core/tests, so gwt-dev (issue1383804)

[Scott Blum]

I was thinking you'd want to remove junit.jar from the non-test build path
for gwt-dev.

On Fri, Mar 18, 2011 at 1:52 PM, Freeland Abbott  wrote:

> Turns out that ant is already covered: user/build.xml has, in part:
>
>   
>   
> 
> etc.
>
>
> so dev/bin-test is already available.  I guess source code wouldn't be, but
> translatable tests seem unlikely to mess with TreeLoggers, and empirically
> when I ran "ant tests," the only problem I got was was from
> com.google.gwt.validation.tck.ConstraintCompositionGwtSuite.xml
> (draft-htmlunit and nometa-htmlunit only, dev, emma, and web were all
> fine)... I assumed that was a system flake, not something symptomatic of my
> change.  The error was "Testcase: Monitor file
> (blahblahblah/junitvmwatcher6602185781037387809.properties) missing,
> location not writable, testcase not started or mixing ant versions?", which
> seemed unlikely to be related to migration of UserTestTreeLogger, especially
> with the others passing.
>
> On Fri, Mar 18, 2011 at 1:40 PM, Scott Blum  wrote:
>
>> LGTM.  Shouldn't some ant build rules want to change, though?
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Moving UnitTestTreeLogger from dev/core/src to dev/core/tests, so gwt-dev (issue1383804)

[Scott Blum]

LGTM.  Shouldn't some ant build rules want to change, though?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Are there any docs describing internals of gwtc?

[Scott Blum]

On Mon, Mar 14, 2011 at 4:41 PM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> So, if my GWT app doesn't have any generators exact contents of
> TypeOracle doesn't matter? I'm asking because I'm thinking of creating
> some stub data structures for jribble units and just move on to fixing
> some other issues and come back only once I want to support Generators
> written in Scala or Generators referring Scala.
>

That *may* be true but you'd have to try it and find out.  I know we use
TypeOracle for a couple of other purposes in dev mode, but I don't *think*
we use it for anything else in web mode..


> > 2) The GWT AST, which is essentially a source-level representation of the
> > user's Java code, including method bodies, which is optimized and
> translated
> > into JavaScript.  May be referred to as GWTC, the compiler, the web-mode
> > compiler, etc.  Mostly lives in com.google.gwt.dev.jjs (which stands for
> > 'Java to JavaScript').  TypeMap is a small implementation detail that's
> only
> > useful for the JDT AST -> GWT AST translation.
>
> I see. It happens that TypeMap is quite interesting from my point of
> view because I'm translating Jribble AST to GWT AST by following JDT
> AST -> GWT AST translation (more or less).
>

Eek... to be honest, JDT AST -> GWT AST is some of the nastiest code around,
mostly due to JDT.  If you're going to follow a pattern, you might look at
the new GwtAstBuilder, which is at least marginally cleaner than
BuildTypeMap/GenerateJavaAST.


> Is there one class that is dealing specifically with emulating object
> orientation or it's scattered around many classes? I'm asking because
> toString() call get's translated to toString_2() javascript call and
> this method is not being defined anywhere in js source code. I'm
> trying to pinpoint location where this stuff is handled to understand
> why I get a call to non-existing place.
>

Hmm, I'm not completely sure what you're asking.  GenerateJavaScriptAST is
the place to look for how precisely the Java AST is transformed into
JavaScript.


> I've got another question. Do you have any tool for checking
> correctness of GWT's ASTs or a tool that allows one to dump ASTs and
> compare them? The scenario I have in mind is like this:
> 1. I have minimal jribble example that exhibits some obscure problem
> like with toString described above and I fail to find a bug but I
> suspect that GWT ASTs I get out of Jribble are broken.
> 2. I prepare corresponding Java code that imitate code from jribble.
> This should work (or I found a bug in gwtc itself but this is highly
> unlikely). Now I'd like to compare those two ASTs. Such comparison
> should immediately reveal the source of my problems.
>

You can always call toSource() on any GWT AST node to get the source
representation.  GwtAstBuilderTest utilizes this to verify that the new
GwtAstBuilder is mostly source-compatible with the old translator.  We also
have a bunch of unit tests derived from JJSTestBase that all generally
verify that a certain input source + certain transformations turns into
expected output.

Other that that, we use JUnit / GWTTestCase to actually execute the compiled
output and verify correctness JUnit style.

Scott



>
> Do you have anything handy that would help me with this or do you have
> some other idea how to solve my problem?
>
> --
> Best regards,
> Grzegorz Kossakowski
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Are there any docs describing internals of gwtc?

[Scott Blum]

On Mon, Mar 14, 2011 at 3:03 PM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> 1. What's the difference between TypeMap and TypeOracle and why they
> seem to have overlapping functionality?
>

In GWT, there are two major pieces of infrastructure that deal with
representing Java language input.

1) A reflection of the user's type model for the purposes of running
generators.  Approximately equivalent to the kind of information you can get
via Java reflection.  Models types, fields, and methods, but not method
bodies.  The entire machinery around this can be loosely referred to as
"TypeOracle", which is the primary interface for accessing this type model.
 Generators use this type model to generate code.  This infrastructure is
used in both dev mode and web mode, as Generators run in both contexts.

2) The GWT AST, which is essentially a source-level representation of the
user's Java code, including method bodies, which is optimized and translated
into JavaScript.  May be referred to as GWTC, the compiler, the web-mode
compiler, etc.  Mostly lives in com.google.gwt.dev.jjs (which stands for
'Java to JavaScript').  TypeMap is a small implementation detail that's only
useful for the JDT AST -> GWT AST translation.


> 2. Why TypeOracleMediator operates on bytecode whereas gwtc is
> supposed to work with java source, or jdt's asts?
>

Historically, we've run JDT twice.  Once to build TypeOracle, and once to
build the GWT AST.  Efforts have been made to transition TypeOracle to be
built from bytecode, which would eliminate one of these JDT runs in favor of
using external (presumably IDE-built) class files.


> 3. How emulation of object orientation is implemented in gwt?
>

Using JavaScript prototype chains, and mangling method signatures such that
any given override of a method has a globally unique name in the compiled
output.  Try compiling with -style PRETTY or DETAILED and inspect the
output.


> 4. What are main phases in gwtc's execution. What are dependencies?
>

JavaToJavaScriptCompiler .precompile() is what I would consider the main
high-level algorithm.  But here's a text overview.

1) Build TypeOracle from the initial set of available source units
(CompilationStateBuilder).
2) Begin running the web mode compile (WebModeCompilerFrontEnd).
3) As the web mode compile runs, we encounter GWT.create() calls
(FindDeferredBindingSitesVisitor).
4) Use the rebind infrastructure to resolve rebind requests.  This may
entail running Generators, which generate new code.
5) Newly-generated types get added to CompilationState + TypeOracle in a bit
of a loop-back process.
6) Newly-generated types may themselves contain GWT.create() calls, looping
back through step 4.
7) Eventually, all our code is generated.  Get rid of TypeOracle, we don't
need it anymore.
8) GenerateJavaAST turns the JDT AST into the GWT AST.
9) Normalize certain difficult constructs.
10) Optimize.
11) Post-optimization normalizes to turn high-level Java constructs into
JS-specific implementation details (but still Java AST).
12) GenerateJavaScriptAST
13) Optimize JS AST
14) Produce JS source text.


> I'd like to know where TypeMap is being built and why it's done twice.
>

It should only get built once.


> Also, TypeOracle seems to be highly mutable data structure. When it
> gets updated and why?
>

>From the outside, it should be seen as "append only".  Existing state should
be effectively immutable.  It gets updated because Generators produce new
types as the compile proceeds.


> Do you guys have anything (slides, blog posts, discussions, etc.) that
> would help me to better understand those matters?
>

Here's wiki entries for TypeOracle / CompilationState.  The first is
outdated by useful to understand the second one.

http://code.google.com/p/google-web-toolkit/wiki/CompilationUnit_1_5
http://code.google.com/p/google-web-toolkit/wiki/CompilationUnit

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Decentralize JClassLiterals. (issue1375801)

[Scott Blum]

Yay! Submitted!

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)

[Scott Blum]

On Thu, Mar 3, 2011 at 1:47 PM,  wrote:

>
>
> http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
> File
> dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
> (right):
>
>
> http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java#newcode218
> dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java:218:
> null, getByteCode(aClass), System.currentTimeMillis());
> On 2011/03/03 17:36:26, zundel wrote:
>
>> On 2011/03/03 17:14:07, scottb wrote:
>> > Unrelated, but shouldn't this be getLastModified() instead of
>>
> current time?
>
>  I dunno, do you want it to use caching?
>>
>
> Its intended to represent the timestamp of the source file or class file
> resource as you mention, but in order to compute dependency between
> types at the type oracle level.  The idea is to use it for determining
> when to re-run generators or to use the cache of the previous generator
> run.
>
> I figured for unit testing we would want to invalidate any previous
> cache.


Ahh, gotcha.  Mind throwing a comment there while you're in there?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)

[Scott Blum]

On Thu, Mar 3, 2011 at 12:36 PM,  wrote:

>
>
> http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
> File
> dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
> (right):
>
>
> http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java#newcode218
> dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java:218:
> null, getByteCode(aClass), System.currentTimeMillis());
> On 2011/03/03 17:14:07, scottb wrote:
>
>> Unrelated, but shouldn't this be getLastModified() instead of current
>>
> time?
>
> I dunno, do you want it to use caching?


U... your question makes me realize I have no actual clue how that test
works or what the significance of that timestamp is!

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Formatting changes with updated Eclipse GWT Format settings for issue 1373803 (issue1371806)

[Scott Blum]

LGTM

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)

[Scott Blum]

On Thu, Mar 3, 2011 at 10:04 AM, Eric Ayers  wrote:

> After sleeping on the static rogue setter, I don't like it much either and
> came up with some alternatives:
>
> 1) Would it be more palatable to turn setJavaScriptObjectClass() it into an
> instance method?  That way, we wouldn't have to reset the static variable
> each time in tearDown and the override would last for only one instance of a
> TypeOracle.  That is the simplest thing I can think of.
>

I think that would definitely be an improvement on the static method.


> 2) We could make the setter just add to a static list of alternative class
> names to be treated like JavaScriptObject.  That would incur a slight
> run-time penalty in computeSingleJsoImplData() to check against a list of
> strings instead of just a single one.  But then we wouldn't have to worry
> about resetting the name.
>

Nah, instance method is better than this.


> 3) Do you think it would be feasable to taking
> com.google.gwt...mediatortest.JavaScriptObject.class object's bytecode and
> re-write the package using ASM?
>

Actually, that might not be too hard at all.


> 4) You suggested squirreling away a copy of
> com/google/gwt/core/client/JavaScriptObject.class somewhere on the classpath
> for the gwt-dev project and using it as the source for the bytecode.  This
> would require some minor refactoring of CheckedJavaResource and subclasses
> in TypeOracleMediatorTest.  To me, this is kind of obscure black magic
> (comparted to how the rest of the tests are implemented.)
>

Hmm, MutableJavaResource is a bit of a beast these days.  Kind of cumbersome
that reified Class objects are the primary api there.  If Class objects were
a convenience, and the underlying api was in terms of stuff you could get
from a Class object, then you could have a Class convenience constructor for
most of the cases, and special-case JavaScriptObject to work from bytes.
 You could get the bytes easily enough by instantiating a
CompilationStateTestBase and grabbings its 'state', which will already
contain a Unit for JSO, the one from JavaResourceBase.JAVASCRIPTOBJECT.

I guess it all depends on how serious you are about removing
TypeOracleMediatorFromByteCodeTest.  If you are going to get rid of that
anyway, MutableJavaResource gets a lot simpler, and it becomes pretty easy
to just utilize JavaResourceBase.JAVASCRIPTOBJECT.

Scott

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)

[Scott Blum]

On Wed, Mar 2, 2011 at 7:21 PM, Eric Ayers  wrote:

> @Scott: I was not planning to revert the diff cheese. This uses the
> recently updated official gwt-format.xml autoformatting for Eclipse.  I've
> already volunteered to go through and run the autoformatter to bring
> existing source up to date.


Right, I'm just making the point that it would be great if you could land
that first, so that when you submit this change, it won't mix the formatting
& semantic changes into one CL.

Per our face to face, it'd also be good if you could leave a TODO in
TypeOracle to remove the rogue setter once
TypeOracleMediatorFromByteCodeTest is gone.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Tweak JType memory/serialization footprint. (issue1367801)

[Scott Blum]

Enums should be almost exactly the same, I think.

On Mon, Feb 28, 2011 at 5:00 PM, Eric Ayers  wrote:

> I was trying to think of a way to use enum support (which serializes kind
> of compactly), but I don't think it would be any more compact than this.
>
>
> On Mon, Feb 28, 2011 at 4:52 PM,  wrote:
>
>> http://gwt-code-reviews.appspot.com/1367801/
>>
>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
> DO NOT FORWARD
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] [RFC] GWT Widgets that ROCK!

[Scott Blum]

Hi John,

If my question is stupid or makes incorrect assumptions, feel free to
completely ignore me.  My question relates to render and how the
SafeHtmlBuilder is constructed:

@Override
public void render(Context context, SafeHtml data, SafeHtmlBuilder sb) {
  sb.appendHtmlConstant("");
  if (data != null) {
sb.append(data);
  }
  sb.appendHtmlConstant("");
}

At a glance, this seems to imply that any inner content has to already be
"baked" HTML.  To me, that seems to imply that for a complex hierarchy, you
have to construct a bunch of SafeHtmlBuilders as you go, bake them, and pass
the result into yet more builders.  I don't know how this fits into the
existing model, but would it be possible to do something more visitor like?

@Override
public void render(Context context, SafeHtmlBuilder sb) {
  sb.appendHtmlConstant("");
  context.doChildren(sb);
  sb.appendHtmlConstant("");
}


In effect, you run the SafeHtmlBuilder in 'one shot'.

Just a comment from the peanut gallery, :)
Scott

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Adds a 10 second flush timer to the Speed Tracer logger. (issue1361801)

[Scott Blum]

On Wed, Feb 23, 2011 at 1:16 PM, Toby Reyelts  wrote:

> I'm concerned about how this might impact logging results. For example,
> even if the results are written out on a separate thread (and assuming the
> box has an entirely free processor to deal with it), you can still cause the
> disk to be busy with I/O during the writes, slowing down the real time of
> the even thread if it's also doing I/O. Basically, we already have enough
> problems with reproducible results, so I hate the idea of adding even more
> non-deterministic behavior to the mix.


FWIW, the LogWriterThread already is going to randomly flush itself when the
buffers fill up, so it's probably not any less deterministic to flush it on
a regular basis.  The "streamed output from dev mode" seems like a
reasonable use case, even flushing every second or two shouldn't impact
performance.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Eliminates empty constructor seed functions by using 2 helper functions to setup (issue1360802)

[Scott Blum]

On Thu, Feb 17, 2011 at 6:43 PM, Ray Cromwell wrote:

> So your proposal is something like this:
>
> setupVtable(castableTypeMap, someSuperCtor, ctor1, ctor2);
>
>
> function setupVtable(ctm, supCtor) {
> var newProto = {};
> copyProtoFields(someSuperCtor.prototype, newProto);
> for(var i = 2; i < arguments.length; i++) {
>  arguments[i].prototype = newProto;
>}
>newProto.castableTypeMap = ctm;
>newProto.getClass = getLazyLiteral(...n);
> }
>

Something like that, yep.  Just need to figure out what to do if there
aren't any super ctors (maybe they got inlined?).
- Use ids after all?
- Make a synthetic super ctor just for this purpose?
- Just attach super symbols directly to concrete type.

Actually, #3 might be a reasonable speed vs. size tradeoff, maybe we should
get rid of even virtual proto chaining.


> One of the other things I want to do is eliminate global class literal
> fields in favor of lazily constructed ones, so that Foo.class is replaced
> with getLazyLiteral(someToken), and Object.getClass() is setup dynamically
> as well. Class literals are responsible for enormous bloat currently.
>

SG.


> However, my fear is copying prototype fields might hurt V8 optimizations,
> or be atrociously slow on mobile browsers.
>

Will need to test and find out.  It might actually be better than having to
go through a multi-level lookup chain.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Recompute whether an interface is dual-implemented by JSO and Java types after each compiler opt... (issue1351801)

[Scott Blum]

On Thu, Feb 17, 2011 at 6:29 PM, Ray Cromwell wrote:

> That sounds better, but is there a reason why JavaScriptObjectNormalizer
> was doing this pre-optimization in the first place?
>

I dunno Bob?


> Anyway, in favor of keeping the 'null instanceof JSO' behavior is that the
> following code currently will not do a null check either:
>
> SomeJso foo = getNull();
> foo.someMethod() -> translates to jso$someMethod(foo), even if foo is null;
>
> In most cases, you'll still get an NPE, when interior of the function tries
> to deref 'this'. I'll look at re-rolling this using your proposal.
>

Yeah, that's not so much my issue.  My issue is more that a user writing
"null instanceof JSO" should NOT get a 'yes' back.

Scott

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: A Class that creates a string hash out of the public API of a (issue1359802)

[Scott Blum]

On Thu, Feb 17, 2011 at 12:22 AM,  wrote:

> Scott makes sense, however, would it not also make sense to have a
> signature that can also used by generators to determine whether a type
> has changed (and prevent the need for an alternate signature being
> maintained for that purpose)?  Currently, we have a dumbed down version
> of generating a signature from the full bytecode (in JRealClassType).
> That would benefit from an asm based signature that only looks at api
> level structurePerhaps this present code could be modified to
> alternately accept a flag to consider annotations as well, if desired.
>

I have to agree that this should be separate.  For example, TypeOracle cares
about parameter names, annotations, etc; none of which would force recompile
propagation.


> I'm wondering if handling the case where some methods have been
> re-ordered in a source file is worth incurring the overhead of sorting
> and managing multiple StringBuilders, etc.  This could add up if we have
> a large number of classes to consider, etc.  I'm not sure how often a
> source file has some fields/methods re-ordered, vs. other api changing
> edits, or how important it is to seamlessly handle that case (I think
> the user expects some recompiling when editing code).  Maybe it's not
> too expensive though (in which case I'll go jump off a cliff)?
>

I'm sure it's not terribly expensive, and I'm generally not a fan of trying
to micro optimize on the front end.  If it becomes a source of sluggishness,
it'll show up on profiling at some point.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: A Class that creates a string hash out of the public API of a (issue1359802)

[Scott Blum]

To give some context, this signature is used for the purpose of deciding if
a class's API has changed... *as far as other Java source files are
concerned for the purposes of running javac*.  It has no effect on
TypeOracle or the data presented there, it's not being used to cache old
TypeOracle models.

Using sort order means a user can sort a file without changing its API and
not have to recompile the dependent files.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Recompute whether an interface is dual-implemented by JSO and Java types after each compiler opt... (issue1351801)

[Scott Blum]

On Wed, Feb 9, 2011 at 4:20 PM, Ray Cromwell  wrote:

> Is this kind of like how regular static methods have an upref to the
> instance methods they came from? Could we reuse the same
> program.staticToInstanceMap?
>

Actually, I mean JMethod.overrides and therefore
JTypeOracle.getAllOverrides().

If you search for all callers to JTypeOracle.getAllOverrides() it'll give
you a good idea how this is used.  Heck, maybe we're already hooking that up
for JSO interface implementors and this would just work out of the box.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Recompute whether an interface is dual-implemented by JSO and Java types after each compiler opt... (issue1351801)

[Scott Blum]

On Wed, Feb 9, 2011 at 3:36 PM,  wrote:

> It is strange, then again, it is strange that a JSO that is null can
> still be invoked. :) However, I think I've come back to sanity on
> rethinking this. Since it is only used for a single use case in my Json
> library (JsonNull), I think I'll just change the API slightly. I wanted
> an "unwrapped" JsonNull to represent json nulls (most APIs use a Java
> wrapper). Instead, I'll just use the real 'null', and add an extra
> method to check for the difference between 'null' and undefined.


Thanks. :)  It would seem really strange if all Java nulls were implicitly
treated as JSOs!


> This is a different issue, and my gut says they will only partially get
> cleaned up. Consider:
>
> Cast.isJavaObject(foo) ? foo.method() : Jso$foo$method();
>

Maybe that pass is simply generating the wrong code.  I'm not saying this,
by itself, would work, but maybe the right solution involves generating
something like:

(foo instanceof JavaScriptObject) ? JsoFoo.$method(foo) : foo.method()

So that dead code can optimize the instanceof test at some point.

Or, maybe we should leave the call site alone initially...

If we model the JSO method as having an upref to the interface method, CFA
and TypeTightener might do the right things implicitly, then we modify the
appropriate optimizer pass to convert the interface call into the JSO direct
call if that's the only viable option.

Then we add the appropriate logic to JsoDevirtualizer to handler this
post-optimization for cases that still exist.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Compiler doesnt check for compatible Types after generation due to deferred binding: Bug or Feature?

[Scott Blum]

The result of a GWT.create() does not have to be assignable to the input
type, it just usually is.  This has been true forever, actually.  There are
certain uses for it.

On Wed, Feb 9, 2011 at 9:00 AM, ep  wrote:

> hi,
>
> in 2.1.1 (release) when writing a generator I noticed that compiler
> does not perform type checking for the result, causing the application
> to break during runtime. Afair the compiler did that check in 2.0.4
> unless I'm mistaken...
> 
> sample:
>
> interface A {
>  id();
> }
>
> class Foo {
>  A a = GWT.create(A.class);
> }
>
> MyGenerator creates a class:
>
> A_Impl {
> }
>
> Compiler is fine with that result, whereas that A_Impl shall be
> implementing A? The self-(syntax) validation of A_Impl however, works
> fine. But missing type check against expected class.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Make SOYC produce consistent output (issue1338805)

[Scott Blum]

Thanks, done.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Make SOYC produce consistent output (issue1338805)

[Scott Blum]

Yes, it directly affects SOYC output; it causes tons of useless "clinit"
dependencies on interfaces to get recorded, when in reality there is no
actual method in the output.

On Fri, Feb 4, 2011 at 2:18 PM,  wrote:

> Did you mean to include the clinit fixes in this patch?
>
>
> http://gwt-code-reviews.appspot.com/1338805/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Remove useless templatization from JS AST. (issue1310805)

[Scott Blum]

Sure thing.

The original intent was that JsContext would get parameterized with the
"compatible" node type.  So all JsExpression subclasses used a
JsContext, which means, essentially, "I can be replaced only
with other expressions".  There was a tiny amount of usefulness in being
able to see this statically.

In practice though, it's too much crazy futzing with generics.  You'll get a
ClassCastException at runtime anyhow if you screw something up, and our test
coverage is really good these days.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds option to override JsInliner's max complexity ratio heuristic with JVM property 'gwt.jsinli... (issue1341802)

[Scott Blum]

SGTM.

Call it "gwt.js.inlinerRatio" maybe?  There's wiki page somewhere that has
all the existing ones... there's probably a pattern that will emerge.  (And
yours should be added.)

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add JREIndex optimization to JdtCompiler (issue1318802)

[Scott Blum]

Point taken; I killed the old one and made it reference the new one.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Adds accessibility to certain GWT AST nodes (issue1304802)

[Scott Blum]

No hard commitments, but I'm looking on the order of a month or thereabout.

On Wed, Jan 26, 2011 at 3:25 PM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> Thanks Scott for this. It's enough for me to understand motivation and (at
> least some) implications of this change.
>
> This is something which is certainly within my interest. Actually, what you
> described is exactly what I wanted to see for a long time. I parse jribble
> nodes twice for exactly the same reason you are running jdt twice.
>
> When do you plan to finish work on this? It looks like it's a time for me
> to catch up with GWT's trunk in my scalagwt fork.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add JREIndex optimization to JdtCompiler (issue1318802)

[Scott Blum]

I plan to kill AbstractCompiler soon :D

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Adds accessibility to certain GWT AST nodes (issue1304802)

[Scott Blum]

I don't have anything great written up, but here's the gist of it:

Currently, when you do a web mode compile, JDT actually runs twice.  First,
it runs from CompilationStateBuilder and compiles all the source code in
your project.  The output of this is used to build TypeOracle, which is a
reflection-like view of your type model, used by Generators.  This output is
also used for running dev mode.

After all this is done and the JavaToJavaScriptCompiler starts to run, it
actually fires up a second JDT compile-- this recompiles your source files
into one giant, interconnected GWT AST.

The change I'm working on would cut this down to one JDT compile.  During
CompilationState's build, the plan is to analyze each independent unit
(compiled .java file) and produce one partial, disconnected AST per
compilation unit.  Then when it's time to kick off the compiler, we just
grab those independent ASTs and stitch them together, resolving all
references to create the interconnected AST.

This should hopefully cut down on compile time, especially for draft
compiles.  It would also enable us to do a few more tricks in the future,
such as caching compiled .ast files on disk, or even embedded precompiled
.ast files into, say, gwt-user.jar so we don't have to recompile the source
files included with GWT.


On Wed, Jan 26, 2011 at 2:59 PM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> It looks like you are working on something that might be interesting to me.
>
> Is there any place I can find more information on this change?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Fix handling of null passed into varargs (issue1309801)

[Scott Blum]

Is that SGTM or LGTM?  I uploaded a patch.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Remove list of JavaScriptException object properties when compiler.stackTrace = emulated (issue1310802)

[Scott Blum]

LGTM

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: [GWT Designer] Memory leak in ResourceOracleImpl (issue1308801)

[Scott Blum]

LGTM

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: DevMode generates a default web.xml when tags are present and no web.xml exists. (issue1266801)

[Scott Blum]

That seems good to me as a mid-term goal.  Wouldn't this still be a useful
stop-gap moving in that direction but with the current servlet spec?

On Fri, Jan 7, 2011 at 1:41 PM, Toby Reyelts  wrote:

> It sounds to me as if we should be integrating with the facilities in
> Servlet 3.0, since it has been final now for over a year. Specifically see:
>
> Section 4.4: Configuration methods - An API to add and configure servlets,
> filters, and listeners at runtime.
> Chapter 8: Annotations and Pluggability - Capabilities for configuring
> web.xml behavior piecemeal through annotations and web.xml fragments
> separate from web.xml
>
>
> On Fri, Jan 7, 2011 at 1:21 PM, John Tamplin  wrote:
>
>> On Fri, Jan 7, 2011 at 1:11 PM,   wrote:
>> > I don't see any problem with the code.
>> >
>> > Is this really something we want to happen by default?  I'm concerned it
>> > will be baffling to a user why a web.xml gets created only some of the
>> > time.  It seems to me that an external tool that could parse xml could
>> > create such a file if it was needed without too much work.  There's
>> > nothing in here that couldn't be done in a python script with access to
>> > the module files.
>>
>> I think we lost useful functionality when we lost the ability to put
>> servlet tags in a module (think about a self-contained module that
>> contains client code and the servlet needed for the server-side piece
>> - it would be nice to just inherit it and it works, such as for
>> server-side script selection).
>>
>> Should we reconsider the decision to have web.xml authoritive and
>> instead have a template which is used to generate the web.xml file?
>> If there is already a web.xml file, we keep the behavior of today, and
>> if not then we are always generating a web.xml file, whether from
>> web-template.xml (or whatever) or creating a default one if the user
>> didn't supply one.
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds a unit test for the TypeOracleMediator that feeds byte code instead of source. (issue1254801)

[Scott Blum]

On Wed, Jan 5, 2011 at 2:13 PM,  wrote:

> On 2011/01/05 18:59:02, scottb wrote:
>
>> LGTM, I think.
>>
>
> What is that supposed to mean?!?
>

Sorry, it means I didn't scrutinize this to the Nth degree, just looked over
it at a high level.


> I assume all the new units are being moved from code snippets embedded
>> in exist test code?
>>
>
> More or less.  The only difference I remember are the names, and that
> there are some types that were embedded in the same compilation unit
> that I moved to be separate types in order to make the
> CheckedJavaResource to bytecode mapping work without many changes.
>
> The snippets are actually copied - the compiler gets run on the .java
> files to make byte code.  The constant strings in the
> TypeOracleMediatorTestBase.java still get used when the
> TypeOracleMediatorFromSourceTest gets run.  I wasn't sure how to get
> both byte code and the body of the .java file at run time.


Ahh... that's what I was concerned about.  Having two versions of the source
seems bad.  Do you plan to remove the TypeOracleMediatorFromSourceTest in
the near future, or will they exist side by side indefinitely?

If it's the latter, it's worth mentioning that some of our tests do require
test source code to be on the classpath to run, so we could make the Java
files canonical.


> I did work hard to land this in multiple patches. I changed the names of
> some of the identifiers because I just couldn't keep track of names like
> "Class1", "Class2", ... which got mapped onto different
> CheckedJavaResource identifiers.  Do you want me to un-sort the file?


No no, I was just explaining why I was being less thorough.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] A couple of questions before getting started

[Scott Blum]

On Thu, Dec 2, 2010 at 1:35 PM, Luis Solano  wrote:

> I have checked out the trunk and configured my eclipse as said here:
>
> http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt
> .
> I have set the checkstyle and the error/warning configuration and then
> imported the gwt-user and gwt-dev projects. The problem is that I get
> 33 checkstyle problems and 3314 Java Problems (all warnings and the
> first 100 are raw type warnings) in revision 9344. is this ok? if yes,
> should this warnings be solved? And just in case, it's ok to send
> patches with warnings? (I guess the answer is NO)


It's sort of a known-issue broken-window.  Some of them stem from
third-party code that has come into GWT, such as Rhino or ASM.  Removing
warnings in original GWT code is generally a Good Thing.


> The other question is about the workspace encoding. I'm on a mac.
> Should I leave the MacRoman encoding for my workspace or should I
> change it to another like utf-8?
>

All GWT java source is UTF-8, so definitely use that.

Scott

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Factors out TypeOracleMediator.computeBinaryClassName() into a separate class file. (issue1144801)

[Scott Blum]

Like, LGTM++

On Wed, Dec 1, 2010 at 7:12 PM,  wrote:

> On 2010/12/01 16:03:22, scottb wrote:
>
>> Perfect!
>>
>
> Is that perfect as in, "Sounds great I'll look at it later!" or "LGTM"?
>
>
> http://gwt-code-reviews.appspot.com/1144801/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Factors out TypeOracleMediator.computeBinaryClassName() into a separate class file. (issue1144801)

[Scott Blum]

Works for me.

On Mon, Nov 29, 2010 at 6:43 PM, Eric Ayers  wrote:

> how about SerializationUtils.getRpcTypeName()
>
> On Mon, Nov 29, 2010 at 4:53 PM, Scott Blum  wrote:
> > On Mon, Nov 29, 2010 at 2:50 PM,  wrote:
> >>
> >> other references to JType.getQualifiedBinaryName() depend on the
> >> primitive type names being "boolean", "int", ...
> >
> > This seems just wrong to me.  "boolean" isn't a binary name.
> >
>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Factors out TypeOracleMediator.computeBinaryClassName() into a separate class file. (issue1144801)

[Scott Blum]

On Mon, Nov 29, 2010 at 2:50 PM,  wrote:
>
> other references to JType.getQualifiedBinaryName() depend on the
> primitive type names being "boolean", "int", ...


This seems just wrong to me.  "boolean" isn't a binary name.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics

[Scott Blum]

Hmmm what happens if you turn down the log level, say to "WARN"?

Are you invoking from the command line, or are you using the Google Plugin
for Eclipse?

On Wed, Nov 10, 2010 at 4:16 PM, yves  wrote:

> Scott,
> Thx for the tip. Anyway I can't allocate more than -Xmx1590M and I get
> exactly the same error.
> Yves
>
>
> On 9 nov, 07:47, Scott Blum  wrote:
> > Hmm can you increase your virtual memory?
> >
> > On Mon, Nov 8, 2010 at 5:13 PM, yves  wrote:
> > > I can't, I only have 2GB RAM, I get this error as from -Xmx1024M
> > > [java] Error occurred during initialization of VM
> > > [java] Could not reserve enough space for object heap
> > > [java] Could not create the Java virtual machine.
> >
> > > and the log level is INFO
> > > Yves
> >
> > > On 8 nov, 22:53, Scott Blum  wrote:
> > > > What if you turn the heap up to -Xmx2048M?
> >
> > > > What log level are you using?
> >
> > > > On Mon, Nov 8, 2010 at 4:44 PM, yves  wrote:
> > > > > Hi,
> >
> > > > > I had a class named "ResultNode" and the project compiled fine.
> > > > > In order to improve the code, I changed this class by adding
> generic
> > > > > stuff like that : ResultNode>.
> > > > > Of course I adapted the entire project where needed to take
> advantage
> > > > > of this change.
> >
> > > > > Now I get an "Internal compiler error"
> >
> > > > > This is produced with java memory settings "-Xmx768M" and "-Xss32M"
> .
> > > > > (usually the settings are -Xmx128M and default value for -Xss and I
> > > > > never had such problem).
> >
> > > > > BTW : a "javac" compilation on the project is succesfull, so it is
> not
> > > > > a java error.
> >
> > > > > Any suggestion ? If more information is needed do not hesitate to
> ask.
> > > > > Thanks in advance
> > > > > Yves
> >
> > > > > [java] Compiling module com.mycompany.myproject.MyProject
> > > > > [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/
> > > > > src/com/mycompany/myproject/client/model/AppActivityMapper.java'
> > > > > [java]   [ERROR]  Internal compiler error
> > > > > [java] java.lang.OutOfMemoryError: Java heap space
> > > > > [java] at java.util.Arrays.copyOf(Arrays.java:2882)
> > > > > [java] at
> >
> > >
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:
> > > > > 100)
> > > > > [java] at
> > > > >
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> > > > > [java] at
> > > java.lang.StringBuilder.append(StringBuilder.java:119)
> > > > > [java] at
> >
> > >
> com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java:
> > > > > 59)
> > > > > [java] at
> >
> > >
> com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java:
> > > > > 126)
> > > > > [java] at
> > > > > com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222)
> > > > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> > > > > 939)
> > > > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> > > > > 1412)
> > > > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> > > > > 1219)
> > > > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
> > > > > 1309)
> > > > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> > > > > 1011)
> > > > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuild

Re: [gwt-contrib] Fix permgen exhaustion due to classloader memory leak across server refresh. (issue1097801)

[Scott Blum]

>
> -Restart the server, not just the WebAppContext, on refresh
>

Can you be more specific in the change description when you submit?  Like:

- On server restart, restart the whole Jetty server, not just the
WebAppContext.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics

[Scott Blum]

Hmm can you increase your virtual memory?

On Mon, Nov 8, 2010 at 5:13 PM, yves  wrote:

> I can't, I only have 2GB RAM, I get this error as from -Xmx1024M
> [java] Error occurred during initialization of VM
> [java] Could not reserve enough space for object heap
> [java] Could not create the Java virtual machine.
>
> and the log level is INFO
> Yves
>
>
> On 8 nov, 22:53, Scott Blum  wrote:
> > What if you turn the heap up to -Xmx2048M?
> >
> > What log level are you using?
> >
> > On Mon, Nov 8, 2010 at 4:44 PM, yves  wrote:
> > > Hi,
> >
> > > I had a class named "ResultNode" and the project compiled fine.
> > > In order to improve the code, I changed this class by adding generic
> > > stuff like that : ResultNode>.
> > > Of course I adapted the entire project where needed to take advantage
> > > of this change.
> >
> > > Now I get an "Internal compiler error"
> >
> > > This is produced with java memory settings "-Xmx768M" and "-Xss32M" .
> > > (usually the settings are -Xmx128M and default value for -Xss and I
> > > never had such problem).
> >
> > > BTW : a "javac" compilation on the project is succesfull, so it is not
> > > a java error.
> >
> > > Any suggestion ? If more information is needed do not hesitate to ask.
> > > Thanks in advance
> > > Yves
> >
> > > [java] Compiling module com.mycompany.myproject.MyProject
> > > [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/
> > > src/com/mycompany/myproject/client/model/AppActivityMapper.java'
> > > [java]   [ERROR]  Internal compiler error
> > > [java] java.lang.OutOfMemoryError: Java heap space
> > > [java] at java.util.Arrays.copyOf(Arrays.java:2882)
> > > [java] at
> > >
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:
> > > 100)
> > > [java] at
> > > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> > > [java] at
> java.lang.StringBuilder.append(StringBuilder.java:119)
> > > [java] at
> >
> > >
> com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java:
> > > 59)
> > > [java] at
> >
> > >
> com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java:
> > > 126)
> > > [java] at
> > > com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> > > 939)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> > > 1412)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> > > 1219)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
> > > 1309)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> > > 1011)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java:
> > > 1107)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> > > 977)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> > > 1412)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> > > 1219)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
> > > 1309)
> > > [java] at
> >
> > >
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstanti

Re: [gwt-contrib] Internal compiler error with GWT 2.1.0 RC1 when using generics

[Scott Blum]

What if you turn the heap up to -Xmx2048M?

What log level are you using?

On Mon, Nov 8, 2010 at 4:44 PM, yves  wrote:

> Hi,
>
> I had a class named "ResultNode" and the project compiled fine.
> In order to improve the code, I changed this class by adding generic
> stuff like that : ResultNode>.
> Of course I adapted the entire project where needed to take advantage
> of this change.
>
> Now I get an "Internal compiler error"
>
> This is produced with java memory settings "-Xmx768M" and "-Xss32M" .
> (usually the settings are -Xmx128M and default value for -Xss and I
> never had such problem).
>
> BTW : a "javac" compilation on the project is succesfull, so it is not
> a java error.
>
> Any suggestion ? If more information is needed do not hesitate to ask.
> Thanks in advance
> Yves
>
> [java] Compiling module com.mycompany.myproject.MyProject
> [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/
> src/com/mycompany/myproject/client/model/AppActivityMapper.java'
> [java]   [ERROR]  Internal compiler error
> [java] java.lang.OutOfMemoryError: Java heap space
> [java] at java.util.Arrays.copyOf(Arrays.java:2882)
> [java] at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:
> 100)
> [java] at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> [java] at java.lang.StringBuilder.append(StringBuilder.java:119)
> [java] at
>
> com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java:
> 59)
> [java] at
>
> com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java:
> 126)
> [java] at
> com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 939)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> 1412)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> 1219)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
> 1309)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 1011)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java:
> 1107)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 977)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> 1412)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> 1219)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
> 1309)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 1011)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java:
> 1107)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 977)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> 1412)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> 1219)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
> 1309)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 1011)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java:
> 1107)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
> 977)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
> 1412)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
> 1219)
> [java] at
>
> com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeO

[gwt-contrib] Re: Modifies the GWT compiler sharded entry points to support an alternative (issue1074801)

[Scott Blum]

On Thu, Nov 4, 2010 at 4:57 PM,  wrote:

> A second entry point for compile makes a lot of sense - and maybe for
> CompilePerms too. Keep looking and tell me what you think.
>
> I'm thinking of these names:
>
> PrecompileOnePerm for the new precompile entry point.
> CompileOnePerm for the new compile perms entry point
>

I'm liking these.  Is it really exactly one, though?  Maybe
PrecompileSpecificPerms would be closer to the mark?

I'd like to see how this shakes out.  I definitely think Precompile wants to
be split.  Less sure that CompilePerms and Link actually need to be split.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds an -XcompilerMetrics flag to the compiler. This will (issue1045801)

[Scott Blum]

LGTM

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] RPC using getCause instead of getTarget

[Scott Blum]

My JDK says:

*Throwable java.lang.reflect.InvocationTargetException.getTargetException()*

Get the thrown target exception.

This method predates the general-purpose exception chaining facility. The
Throwable.getCause() method is now the preferred means of obtaining this
information.

Returns:
 the thrown target exception (cause of this exception).


On Fri, Oct 22, 2010 at 3:48 PM, Sebastian  wrote:

> Hi,
>
> the RPC.java has a method   public static String
> invokeAndEncodeResponse which does catch an InvocationTargetException
> and tries to encode the error.
>
> Here a snippet:
>
> catch (InvocationTargetException e) {
>  // Try to encode the caught exception
>  //
>  Throwable cause = e.getCause();
>  responsePayload = encodeResponseForFailure(serviceMethod, cause,
>  serializationPolicy, flags);
>}
>return responsePayload;
>
> The disadvantage is that the information about the exception is
> actually in e.getTarget. As a consequence no detailed are carried to
> the server. It indicates the normal "error on server" message.
> e.getCause is null.
>
> Is there any motivation behind using the e.getCause or is this
> actually a bug.
>
> Best Regards
>
> Sebastian Hennebrueder
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Reformulate RPC generated TypeHandlers to create fewer classes. (issue1037801)

[Scott Blum]

Well, I had to pick something that wouldn't conflict with the names of the
established static methods.  My names are pretty lame.  Suggestions?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Prevent non-null null types from appearing. (issue1028801)

[Scott Blum]

Hmm... not really sure how to recreate it. :/

On Mon, Oct 18, 2010 at 7:19 PM,  wrote:

> On 2010/10/18 22:52:22, scottb wrote:
>
>
> perhaps we should add a test for this too?
>
>
> http://gwt-code-reviews.appspot.com/1028801/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: DeadCodeElimination should only run once. (issue983802)

[Scott Blum]

Okay, so when I drill down, optimization is net faster with my patch.  A
typical example, on one particular optimize loop, before DCE would take
 ~15-20ms, but with my patch more like ~7-15ms.  On the down side,
MethodInliner seems very slightly slower, but it appears to be a decent net
win.

On Wed, Oct 13, 2010 at 2:46 PM, Scott Blum  wrote:

> On Wed, Oct 13, 2010 at 2:39 PM, Eric Ayers  wrote:
>
>> This is good, it confirms that the number of changes to the AST hasn't
>> changed (or haven't changed much).  I was thinking of the speedtracer logs
>> which would show a change in the real-time performance of each pass the
>> optimizers. (re-run with -Dgwt.speedtracerlog=/tmp/speedtracer-trunk.html )
>
>
> I did that first, but I found the results kind of hard to understand for
> the particular application relative to using the logs.  Lemme put a bit more
> effort in.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: DeadCodeElimination should only run once. (issue983802)

[Scott Blum]

On Wed, Oct 13, 2010 at 2:39 PM, Eric Ayers  wrote:

> This is good, it confirms that the number of changes to the AST hasn't
> changed (or haven't changed much).  I was thinking of the speedtracer logs
> which would show a change in the real-time performance of each pass the
> optimizers. (re-run with -Dgwt.speedtracerlog=/tmp/speedtracer-trunk.html )


I did that first, but I found the results kind of hard to understand for the
particular application relative to using the logs.  Lemme put a bit more
effort in.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: DeadCodeElimination should only run once. (issue983802)

[Scott Blum]

On Tue, Oct 12, 2010 at 4:07 PM,  wrote:

> FYI, I like the refactoring of JModVisitor
>

Thanks!


> I have no idea how you came up with these changes other than to pick up
> a huge piece of code and start setting break points in the compiler and
> iterating until you fixed them.  That's a difficult tasks for mere
> mortal coders to repeat.
>

I actually just added a 'passes' field to DeadCodeElimination, and
incremented it each pass through the while loop.  Then I removed all the
direct increment field accesses in JModVisitor and forced them to all call
the madeChanges() method, which I then override, and set a breakpoint / did
a System.out.println when passes > 1.  That shook things out fairly quickly.

I'm working on patches for some other visitors using the same technique.


> At the very least, the DeadCodeEliminationTest needs a TODO for someone
> to add new test() methods for the types of things you found that took
> more than one pass to resolve.


Will do, thanks.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?

[Scott Blum]

It sounds like the problem really boils down to less-than-useful stack
traces when a native exception is thrown in Dev mode.  Ironically, if you
ran this in Prod mode, you'd probably get a better stack trace, because we
emulate the stack over there.

We could probably implement the same sort of stack trace emulation feature
in Dev mode + some other stack cleanup to make the exception traceback much
nicer.

CC'ing Kelly so he can see about prioritizing this.

On Fri, Oct 1, 2010 at 1:00 PM, Damon Lundin  wrote:

> Thanks for the help Scott.  The problem is not with the
> delayTestFinish.  Apparently our tests are throwing uncaught
> exceptions which causes the test to finish.  The exception does appear
> in our logs, but it's one of these:
>
> Caused by: com.google.gwt.core.client.JavaScriptException: (Error):
> Unspecified error.
>  number: -2147467259
>  description: Unspecified error.
>at
>
> com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:
> 237)
>
> Which are not terribly useful (if you have any useful suggestions on
> dealing with these, I'm all ears) so I moved on to the next exception
> which was an NPE in our code.  That NPE is caused by the tests running
> on top of each other.  So I guess this was my fault for not paying
> closer attention to the first exception.
>
> There is perhaps one possible recommendation that could come out of
> this and maybe that is that when a test begins (or finishes) it
> cancels all outstanding timers, commands and pending async callbacks
> (perhaps optionally).  The confusion occurred here because even though
> the previous test threw an uncaught exception and finished allowing
> the next test to begin, the outstanding commands started by the
> previous test were still allowed to run and when they did, they messed
> up the shared state used by the next test.
>
> Of course now I have to go figure out what's causing this uncaught
> exception to be thrown :-(.  And I'm also still confused why the tests
> pass when run one at a time.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?

[Scott Blum]

Ok, that's pretty strange, but there is a way to debug.

- Unzip gwt-user.jar somewhere.
- Inside where you extracted it, there should be a folder
"com/google/gwt/junit/translatable/"
- Go edit your launch config and add that folder to the Source Lookup Path,
under the "Source" tab, "Add." a "File System Directory", and select that
folder named "translatable".  Move it UP above the default path.
- Put a breakpoint where you call delayTestFinish()
- Launch

You should now be able to step into delayTestFinish() and/or step out of
your test method and see what the client code is doing.


On Fri, Oct 1, 2010 at 11:13 AM, Damon Lundin wrote:

> On Oct 1, 9:11 am, Scott Blum  wrote:
> > Is this in dev mode or prod mode?  Do the tests succeed if you run them
> > individually?
>
> This is in dev mode.  If I disable all of the tests and run them
> individually they all pass.  I've never tried running tests in prod
> mode but I think I know how and I can give that a try.  The next thing
> to try as well would be to chain all the test methods together.  So
> instead of having test01...testN, I can have the end of test00 start
> test01 and the end of test01 start test02, etc.  Of course that's
> problematic if a test fails, the next one won't run.  And if the
> delayTestFinish isn't working, the whole thing might just stop before
> it gets all the way through.  But something to try.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?

[Scott Blum]

Is this in dev mode or prod mode?  Do the tests succeed if you run them
individually?

On Thu, Sep 30, 2010 at 7:54 PM, Damon Lundin wrote:

> We are trying to upgrade from 2.0.4 to 2.1.0.m3 because of some bugs
> in 2.0.4 but in doing so our GWT test cases have begun failing and I
> have determined it's because the next test is beginning before the
> previous one is complete and they are messing each other up.  I know
> that delayTestFinish is meant to allow for tests to make use of async
> calls and it's been working for us but now it's not.
>
> We have a number of tests that roughly look like this:
>
> public void test03 {
>  delayTestFinish(12);
>  rpcService.someServerCall(new AsyncCallback() {
>public void onSuccess() {
>  // Do some stuff
>  DeferredCommand.addCommand(new Command() {
>public void execute() {
>  // More stuff
>  finishTest();
>}
>  }
>}
>  }
> }
>
> public void test04 {
>  delayTestFinish(12);
>  ...
> }
>
> Our code actually uses DeferredCommands in a long chain of calls but
> in short, test04 begins executing before we call finishTest() in the
> previous test and I don't think that's supposed to happen.
>
> I could further debug this if someone could explain to me what
> "implemented in the translatable version of this class" means and how
> I would debug this "translatable version".  Any advice on how to
> proceed?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Remove misleading change record from MethodInliner. (issue934801)

[Scott Blum]

It is the last reference to the (int) version.  There are refs to the no-arg
version in my copy.  I can definitely remove it.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Remove the output from the link step before attempting to (issue928801)

[Scott Blum]

I'm also not sure this is a bug.  If it's set read-only, why would we try to
clobber it?

On Tue, Sep 28, 2010 at 11:18 AM,  wrote:

> Assuming we like the concept, I have two issues noted here.
>
> At the larger level, people should be doing this today in e.g. build.xml
> as a wrapper, which also works... I'm not sure whether I'd be more
> annoyed to fail on existing dirt, or to have something I'd tried to
> preserve be overwritten.  The first, however, is annoying; the second is
> potentially costly!
>
>
> http://gwt-code-reviews.appspot.com/928801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: If Java optimizers are not run to full completion (part of another proposed patch), (issue897803)

[Scott Blum]

This actually gives me pause.  What kind of code can leave primitives on one
side but not the other?

I'm concerned because in Java, I think this should be true:

Integer.valueOf(1) == 1

Because the RHS gets autoboxed.  If we're translating this as-is into JS
triple-equals without boxing it, the test would fail.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Guidance needed: unit tests and TypeOracle, ModuleDefLoader vs. CompilerStateBuilder

[Scott Blum]

What Bob said.  You can write much, much faster unit tests using just
CompStateBuilder, since it's easy to build a very small world that only
contains just what you need.  If you don't care about speed, it's probably
less work to go with ModuleDefLoader.

Some of the UiBinder tests are really great examples of the pattern.

On Tue, Sep 14, 2010 at 9:07 AM, BobV  wrote:

> > I've noticed that c.g.g.editor.rebind.model.EditorModelTest has a
> > nested RealJavaResource class that reads a Java file from the
> > classpath so you can use an existing class with CompilerStateBuilder.
> > This is similar to what ModuleDefLoader would do, just without the
> > super-source override. It'd solve the @Annotation issue, but it's
> > currently a nested class in a particular test, i.e. not something to
> > be reused in other tests.
>
> If you wind up using ModuleDefLoader, it will be easy to wind up
> pulling in all of User.gwt.xml, which would really slow the test down.
>  The helper classes in EditorModelTests are private only because I
> didn't have a lot of time to think about how to turn them into a good
> public API.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds a -strict option to the GWT compiler. If this option is specified, (issue853801)

[Scott Blum]

LGTM

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Enum name obfuscation option. Addresses issue 2387369 (issue827802)

[Scott Blum]

LGTM

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds a -strict option to the GWT compiler. If this option is specified, (issue853801)

[Scott Blum]

High-level comments:

- CompilationState doesn't really need the extra API, because you can always
just iterate through the returned collection looking for errors.  Arguably,
this would take a few extra cycles, but I've kinda been wanting to move the
error reporting out  CompilationState anyway and let the callers handle it,
which would eliminate the extra cost since we'd have to loop through
reporting errors anyhow.

- On the test class, it might be easier to just check a Good and Bad module
into dev/test instead of mucking around with temp dirs and class loaders.
 This is the pattern we use for TypeOracleTest.gwt.xml, and One.gwt.xml, for
example.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Public: Modify checkstyle config to allow formating of Fluent style builders (issue812801)

[Scott Blum]

Will our Eclipse formatter settings respect this?  Or will it auto-format
such a construct into something else?

On Mon, Aug 30, 2010 at 1:53 PM,  wrote:

> On 2010/08/30 17:51:52, rjrjr wrote:
>
>> LGTM
>>
>
>  Nice, thanks.
>>
>
>  You're sure this works with the checkstyle 4.whatever we're still
>>
> using?
>
>  On 2010/08/30 17:22:28, Nick Chalko wrote:
>> >
>>
>
>
> I tested it locally on my laptop.
>
> cd .../user; ant checkstyle
>
> and the smoke tests pass.
>
>
>
>
>
> http://gwt-code-reviews.appspot.com/812801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: CurrencyList now uses pure Java in dev mode. (issue771803)

[Scott Blum]

On Fri, Aug 27, 2010 at 11:21 AM, John Tamplin  wrote:

> Why do that every time you run the generator rather than once when you
> import the CLDR data?


Oh, you know what, I kind of forgot that we're the only ones who actually
implement currency list.

Which actually brings up another interesting point... why have a generator
at all?  Why not have the CLDR data importer produce static java files one
time?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: CurrencyList now uses pure Java in dev mode. (issue771803)

[Scott Blum]

On Thu, Aug 26, 2010 at 9:40 PM,  wrote:

> Hmm, the code is fine, but the property files aren't.  If you remove all
> but AUD and USD from the CurrencyData_en_AU.properties file, you can see
> the generated CurrencyList_en_AU.java contains only the modified values.
>
> I'll work on updating the properties files next week.
>
> I could swear I remember looking at generated files and verifying it,
> but maybe those were never checked in.
>
>
Still, shouldn't the generator be able to detect the dups at generation
time?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Always use unix-style line endings in Generators. (issue776803)

[Scott Blum]

On Fri, Aug 20, 2010 at 2:25 PM,  wrote:

> Change LGTM, but why is this a problem in practice?  Isn't the generated
> source transient?


It is, except when you use the -gen flag because you actually want to see
the generated output. What I was seeing is that, in some cases, the line
endings wouldn't even be consistent within the same file!  Parts of it that
were generated by one subsystem would be one way, and some nested code
generated in a temp buffer in another subsystem would be the other.

Fixing this gets rid of some annoying diff behavior when comparing generator
outputs.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: TypeOracle transitive invalidation based only on API types (issue775804)

[Scott Blum]

On Thu, Aug 19, 2010 at 11:41 AM,  wrote:

> Why do we no longer visit annotation types?


We visit annotation types; what we don't visit is annotation elements on
other types.  IE, we don't visit the @Override on a method.  The reasoning
has to do with how the actual dependencies work in TypeOracle.  As it turns
out, there's no reference from a JClassType or JMethod to the
JAnnotationType that happens to be annotating it.  Instead, it's modeled
using java.lang.Class and AnnotationProxies.  So for the purpose of
constructing a well-formed TypeOracle, the ability to resolve a
JAnnotationType for @Override is totally incidental to resolving a method
that happens to be annotated with it.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Report CompilationState errors deterministically. (issue773802)

[Scott Blum]

Not exactly.  I was trying to figure out *why* my patch broke the test, and
the non-deterministic error reporting made it very difficult to compare the
logs.  I have a fix for the other issue (review coming soon), but this
seemed like a useful partial.

On Wed, Aug 18, 2010 at 4:16 PM,  wrote:

> LGTM.
>
> Is this designed to fix the test broken by issue 756802 (Change to
> CompilationStateBuilder to prevent recursive invalidation on changed
> units)?
>
>
> http://gwt-code-reviews.appspot.com/773802/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors