[gwt-contrib] Re: A general purpose script injection class for injecting a script directly (issue1451818)

[Eric Ayers]

Sorry, this was shipped in GWT 2.4 without such a check, and such a check
would be inappropriate if the script were some sort of dynamically generated
content using a constant URL.  If someone were to want to add such a check,
I'd suggest that it be added as a builder option.

On Thu, Sep 8, 2011 at 10:15 AM,  wrote:

> Could this possibly include a check, whether the script at given URL was
> already loaded, and is attached to the DOM?
>
> http://gwt-code-reviews.**appspot.com/1451818/<http://gwt-code-reviews.appspot.com/1451818/>
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

[gwt-contrib] Re: Deprecate DeferredCommand and IncrementalCommand. (issue982802)

[Eric Ayers]

http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/client/DeferredCommand.html

has a pointer to the blessed alternative (Scheduler).

@Doug, can you flag this page as needing an update?

On Thu, Sep 8, 2011 at 4:43 PM,  wrote:

> Since this is deprecated what is the alternative to these classes?
>
> The documentation continues to provide these as examples.
> http://code.google.com/**webtoolkit/doc/latest/**
> DevGuideCodingBasicsDelayed.**html<http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsDelayed.html>
>
> On 2010/10/13 17:13:43, rjrjr wrote:
>
>> On Wed, Oct 13, 2010 at 5:28 AM, <mailto:zun...@google.com> wrote:
>>
>
>  >
>> > http://gwt-code-reviews.**appspot.com/982802/diff/1/5<http://gwt-code-reviews.appspot.com/982802/diff/1/5>
>> > File user/src/com/google/gwt/user/**client/DeferredCommand.java
>>
> (right):
>
>> >
>> > http://gwt-code-reviews.**appspot.com/982802/diff/1/5#**newcode27<http://gwt-code-reviews.appspot.com/982802/diff/1/5#newcode27>
>> > user/src/com/google/gwt/user/**client/DeferredCommand.java:**27: *
>> >  API prevents effective mocking.
>> > On 2010/10/13 03:50:36, rjrjr wrote:
>> >
>> >> I thought it was deprecated because it was redundant...TMI?
>> >>
>> >
>> > IMHO, I don't think you can give too much information on the impetus
>> > behind this change.  Its going to be painful to see all those
>> > deprecation warnings come out the first time for most users.
>>
>
>
>  We might want to provide more justification then. We're not just
>>
> deprecating
>
>> the thing for mockability, it's redundant code, right?
>>
>
>  >
>> >
>> > http://gwt-code-reviews.**appspot.com/982802/show<http://gwt-code-reviews.appspot.com/982802/show>
>> >
>>
>
>
>
> http://gwt-code-reviews.**appspot.com/982802/<http://gwt-code-reviews.appspot.com/982802/>
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] unit cache with binary annotations

[Eric Ayers]

I see how that could happen.  We don't take annotations into account
in the computing of dependencies in

BytecodeSignatureMaker.CompileDependencyVisitor.

Filed issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=6646

-Eric.

On Tue, Aug 2, 2011 at 2:57 PM, Stephen Haberman
 wrote:
> Hi,
>
> I ran into an odd boundary case with the unit cache today that I
> thought I'd report.
>
> I had a class, Foo, using a binary-only annotation, @Bar. Somehow
> my classpath was wrong, and so I got a (valid) compilation error
> from ecj that Foo couldn't be compiled without Bar.
>
> However, after fixing my classpath issue, the compilation error
> didn't go away. After several minutes of ensuring the classpath was,
> no really, really right now, I finally realized it's because binary
> only annotations are not captured by the CompilationUnit's Dependencies
> (being resolved against the valid classes found by the resource oracle,
> which won't have binary-only annotations), so I was really seeing
> cached compilation errors.
>
> Adding a blank line to Foo kicked off a real compilation and then
> all was well.
>
> I don't have any insights on how to recognize this case, nor if
> it's worth doing so, given it is likely/hopefully rare.
>
> - Stephen
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] misc cleanup

[Eric Ayers]

If you want to make one big rietveld issue out of that, I'll take it.

On Sun, Jul 24, 2011 at 4:53 PM, Stephen Haberman
 wrote:
> Hey,
>
> I've been poking around TypeOracle lately and, while seeing who called
> what, made a few minor changes, mostly deleting stuff that wasn't
> called, or removing used-once-by-tests overloads.
>
> I didn't want to bother making reitveld issues for these if they're not
> worth it, so the list is here:
>
> https://github.com/stephenh/google-web-toolkit/compare/master...misc2
>
> I can make one big issue or several small ones if any of these seem
> interesting, just let me know.
>
> - Stephen
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] persistent unit cache w/newer entries

[Eric Ayers]

I'm committing patch  now:
http://gwt-code-reviews.**appspot.com/1483803/<http://gwt-code-reviews.appspot.com/1483803/>

On Thu, Jul 14, 2011 at 2:28 PM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:

>
> > For example, you might load in a .gwtar file compiled on July 13, but
> > later you might read in a cached unit compiled on July 1.
>
> Ah, sure, that makes sense. I forgot that units could be coming from
> places other than just gwt-unitCache.
>
> > But I see your point about the unit being the same other than a
> > dependency update.  I'm wondering if it would be sufficient for the
> > test should be changed to >=?
>
> Yeah, that would handle what I was seeing, where the unit had two
> entries in the unit cache, and the 2nd one was correct.
>
> In your scenario, an archive could have a unit with the same timestamp
> but correct dependencies, and with >= could loose out to a unit cache
> unit same timestamp but older dependencies that came in later. But that
> would just mean the unit getting recompiled once and then the new unit
> cache entry (with the same deps as the archive unit) would win the next
> time around.
>
> I was thinking about the case where the archive unit had invalid
> dependencies, and, if loaded later than any unit cache entries, could
> cause a continual recompile. However, I imagine archive units having
> invalid dependencies is unlikely to happen.
>
> - Stephen
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] persistent unit cache w/newer entries

[Eric Ayers]

Hi Stephen,

The line of code you mentioned is used by a background thread that loads up
the persistent unit cache in the background while the compiler is off doing
other things.  Eventually, on the first request to retrieve from the cache,
the two threads sync up (see references to  unitCacheMapLoader.await();).

The logic you are looking at is trying to handle the case where the
MemoryCache might have been pre-populated by another mechanism  other than
reading them out of the log file directory.  For example, you might load in
a .gwtar file compiled on July 13, but later you might read in a cached unit
compiled on July 1.  The persistent unit cache is stale and should be
disregarded.

But I see your point about the unit being the same other than a dependency
update.  I'm wondering if it would be sufficient for the test should be
changed to >=?

On Wed, Jul 13, 2011 at 11:31 AM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:

> Hi,
>
> In PersistentUnitCache, if there are multiple units for the same path,
> this check (line 500-ish):
>
>if (oldEntry != null
>  && unit.getLastModified() > oldEntry.getUnit().getLastModified())
>
> Only uses the newer entry if its timestamp is newer. I don't think this
> is sufficient though.
>
> While messing around with dependencies, I ran into a situation where:
>
> * 1st compile
>  * UnitA is cached with apiRefs=X
> * Make changes
>  * apiRef X changes
> * 2nd compile
>  * UnitA is read from cache
>  * UnitA is seen invalid due to X changed, recompiled
>  * UnitA' (with updated dependencies) is written to cache
> * 3rd compile
>  * UnitA is read from cache
>  * UnitA' is read from cache, but skipped because the timestamp of
>UnitA didn't change, so UnitA' is not considered newer than UnitA
>  * UnitA is seen invalid, recompiled
>  * UnitA'' is written to cache
> * 4th compile
>  * Both UnitA' and UnitA'' are skipped, UnitA is invalidated,
>recompiled, etc.
>
> So, UnitA keeps getting recompiled on subsequent compiles, even though
> apiRef X is no longer changing, until after a certain number of times,
> the unit cache flushes, and AFAICT, UnitA' is kept over UnitA, so then
> it can finally stopped be recompiled.
>
> Basically, I think either newer units should always win, or the new vs.
> old check should consider more than just the timestamp, e.g. if
> dependencies changed. That being said, I don't know what other use
> cases the last modified check was for, other than just avoiding an
> unnecessary map update?
>
> Does that make sense, or am I missing something?
>
> Thanks,
> Stephen
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] Review for Issue 4862

[Eric Ayers]

Lining up and adding a specific reviewer helps, because then the review
shows up on their code review dashboard.  In this case,  I recommend you add
robertvaw...@google.com and rj...@google.com.  (Ray is on vacation)

On Mon, Jul 11, 2011 at 5:07 AM, Felix H. Dahlke  wrote:

> Hi,
>
> would someone mind reviewing my patch for issue 4862? I've submitted
> it almost 4 months ago:
>
> http://gwt-code-reviews.appspot.com/1382804/
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] Re: RR: Retiring Safari 3 in a future release of GWT

[Eric Ayers]

Any other sentiments?

On Tue, Jul 5, 2011 at 10:04 AM, Jeff Larsen  wrote:

> Good riddance. I wish it was possible to do the same with IE versions < 9.
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors




-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

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

[Eric Ayers]

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

On Wed, Jul 6, 2011 at 10:54 AM,  wrote:

> Sorry, the back-end issue is here:
> http://gwt-code-reviews.**appspot.com/1469804/<http://gwt-code-reviews.appspot.com/1469804/>
>
>
> http://gwt-code-reviews.**appspot.com/1470803/<http://gwt-code-reviews.appspot.com/1470803/>
>



-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

[gwt-contrib] RR: Retiring Safari 3 in a future release of GWT

[Eric Ayers]

Due to the declining popularity of the Safari 3 browser (around .1% of all
web users according to some sources) and increasing difficulties of keeping
test and development resources available, the GWT team would like to retire
official support for Safari 3 in an upcoming release.

I thought I float this to the GWT contributors first.  Does anyone have a
compelling use case to keep it under maintenance?

-- 
Eric Ayers | Software Engineer | zun...@google.com | +1 404 487 9229

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

Re: [gwt-contrib] gwtar serialVersionUID mismatch using eclipse/trunk

[Eric Ayers]

You don't really need the gwtar support with PersistentUnitCaching enabled,
which it should be by default.  The performance of the persistent unit cache
is usually as good or better, and the mechanism in play is pretty much the
same, only you don' t have to configure anything special to use the
persistent unit cache.   The purpose of the pre-compiled archives (.gwtar
files) is to distribute them with a versioned GWT distribution for users
that aren't building from source.

If you are routinely building and updating the GWT distribution, you need to
make sure to re-compile the modules every time you update the GWT
distribution.  There are so many things that could change, we don't plan to
try to offer backward compatibility guarantees with these files.



On Sat, Jun 18, 2011 at 2:14 PM, Stephen Haberman <
stephen.haber...@gmail.com <{subItem.from.uri}>> wrote:

> Hey,
>
> I'm debugging a GWT app while using the trunk Eclipse gwt-dev/gwt-user
> projects (so I can make changes to GWT and then start my app without
> rebuilding the gwt-user/gwt-dev jar files with ant).
>
> It turns out that, with this setup, I can't take advantage of the
> new gwtar functionality because of serialVersionUID mismatches.
>
> User.gwtar is built with ant+javac using javac's .class files, but when
> I run the app in Eclipse, using the Eclipse gwt-dev project's .class
> files, deserialization of the gwtar fails because Eclipse and javac
> generate different serialVersionUIDs, even if the source file is
> exactly the same:
>
>
> http://wiki.eclipse.org/FAQ_Why_does_the_Eclipse_compiler_create_a_different_serialVersionUID_from_javac%3F
>
> So I don't get the fancy new gwtar startup times. Which I miss.
>
> Granted, most of the time .gwtar files will be generated in the same
> build cycle as their .class files. And, granted, there are a whole
> bunch of classes that are being serialized.
>
> Hm...although, let's say I build my-library.gwtar with GWT x.y, so
> JDeclaredType/whatever has serialVersionUID=z. If a new release of GWT
> comes out, GWT x.y+1, the serialVersionUID might change unnecessarily
> (per the FAQ, due to a javac implementation change) and be z', causing
> my-library.gwtar to be unusable to projects using GWT x.y+1.
>
> Granted, recompiling my-library.gwtar would fix it. And, at times, would
> actually be necessary if the serialVersionUID changed not arbitrarily
> but due to a format change. So perhaps this isn't a big deal.
>
> Anyway, I thought I'd ask, are there any plans to add serialVersionUIDs?
>
> - Stephen
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Allow binary-only references for compile-time constants. (issue1447825)

[Eric Ayers]

LGTM
On Jun 13, 2011 6:04 PM,  wrote:
>
>
http://gwt-code-reviews.appspot.com/1447825/diff/1/dev/core/src/com/google/gwt/dev/javac/BinaryTypeReferenceRestrictionsChecker.java
> File
>
dev/core/src/com/google/gwt/dev/javac/BinaryTypeReferenceRestrictionsChecker.java
> (right):
>
>
http://gwt-code-reviews.appspot.com/1447825/diff/1/dev/core/src/com/google/gwt/dev/javac/BinaryTypeReferenceRestrictionsChecker.java#newcode97
>
dev/core/src/com/google/gwt/dev/javac/BinaryTypeReferenceRestrictionsChecker.java:97:
> if (expression.constant != null && expression.constant !=
> Constant.NotAConstant) {
> You mean the null check? Not sure, I copied the code from here:
>
>
http://www.google.com/codesearch#A1edwVHBClQ/dev/core/src/com/google/gwt/dev/jjs/impl/GwtAstBuilder.java&l=2634
>
> I must have run into a null case at some point.
>
> http://gwt-code-reviews.appspot.com/1447825/

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

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

[Eric Ayers]

@Scott

If you patch this in and follow the arcane directions, you can get the
incremental compile support in blaze.

https://mondrian.corp.google.com/changelist/21809612

-Eric.

On Thu, Jun 9, 2011 at 5:46 PM,  wrote:

>
> Overall LGTM. I had to update CFA in my recent CL on class literal
> optimization to treat an invocation of Object.getClass() as rescuing the
> class literals of any instantiated types as well as to handle the new
> Immortal CodeGenTypes.
>
> We may have to revisit the UnifyAstVisitor, since it may need special
> handling for the Immortal types, as well as class literal references,
> since GenerateJavaAST no longer overrides getClass() for every time in
> my latest patch.
>
>
>
> http://gwt-code-reviews.**appspot.com/1453810/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

On Wed, Jun 8, 2011 at 8:40 PM,  wrote:

> General question: I'm curious why this couldn't be simpler, that is, why
> does unification depend on control flow? Couldn't you unify everything
> without respect to control flow, and then run a pruning pass afterwards
> reusing the existing CFA code, or is doing it in an integrated pass an
> attempt to scope down the amount of work done?


I think that could be one good reason; In some cases, there can be thousands
of unreferenced types in a project.  stitching those units would be a waste
of time and memory.  Also, since we often encounter projects that include
untranslatable code on the source path, the JDT compile step and build Type
Oracle step doesn't show the errors (unless you turn on strict mode).  We
rely on the AST building stage to report the "important" errors.

-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

-- 
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)

[Eric Ayers]

On Tue, Jun 7, 2011 at 6:13 PM,  wrote:

>
>
> http://gwt-code-reviews.appspot.com/1453804/diff/1017/dev/core/test/com/google/gwt/lang/LongLibTestBase.java
> File dev/core/test/com/google/gwt/lang/LongLibTestBase.java (right):
>
>
> http://gwt-code-reviews.appspot.com/1453804/diff/1017/dev/core/test/com/google/gwt/lang/LongLibTestBase.java#newcode23
> dev/core/test/com/google/gwt/lang/LongLibTestBase.java:23: /**
> If we're going by that logic...
>
> http://www.google.com/search?q=compiler+magic
> http://en.wikipedia.org/wiki/Magic_(programming)
> http://en.wikipedia.org/wiki/Deep_magic_(programming)
>
> :P
>
>
> http://gwt-code-reviews.appspot.com/1453804/
>

I've you'd like to submit a patching changing all appropriate mentions of
"magic" to "compiler magic", I'll be happy to review it :P

-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Format comments to 100 columns to match code format (issue1450808)

[Eric Ayers]

Leaving comments at 80 was intentional as per the style guide, I thought.
On May 29, 2011 6:43 PM,  wrote:
> Reviewers: zundel, rjrjr,
>
> Description:
> Format comments to 100 columns to match code format
>
>
> Please review this at http://gwt-code-reviews.appspot.com/1450808/
>
> Affected files:
> M eclipse/settings/code-style/gwt-format.xml
>
>
> Index: eclipse/settings/code-style/gwt-format.xml
> ===
> --- eclipse/settings/code-style/gwt-format.xml (revision 10241)
> +++ eclipse/settings/code-style/gwt-format.xml (working copy)
> @@ -64,7 +64,7 @@
>  value="true"/>
> 
id="org.eclipse.jdt.core.formatter.comment.insert_new_line_before_root_tags"

> value="insert"/>
>  id="org.eclipse.jdt.core.formatter.comment.insert_new_line_for_parameter"
> value="do not insert"/>
> - value="80"/>
> + value="100"/>
>  id="org.eclipse.jdt.core.formatter.comment.new_lines_at_block_boundaries"
> value="true"/>
> 
id="org.eclipse.jdt.core.formatter.comment.new_lines_at_javadoc_boundaries"
> value="true"/>
> 
>
>

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

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

[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

On Thu, May 26, 2011 at 2:24 PM, John Tamplin  wrote:

> On Thu, May 26, 2011 at 2:03 PM, Grzegorz Kossakowski <
> grzegorz.kossakow...@gmail.com> wrote:
>
>> > The problematic place for me is ReplaceBindings.java, lines 154-155:
>> >
>> >// Rebinds are always on a source type name.
>> >String reqType = type.getName().replace('$', '.');
>>
>> Any comment on that one? Working-around it is possible but quite
>> involved. I'd love to know if I need some solid work-around or just
>> hack to keep me going because this will be removed upstream.
>
>
> There is a common place for these in c.g.g.dev.util.Name, that provides
> all the conversions between different name types.  So, this should be:
>
> String reqType = Name.BinaryName.toSourceName(type.getName())
>
> However, that doesn't solve your problem.
>
> The main problem is that once you get to a binary class name as a string,
> you can no longer distinguish these cases. You would have to have package,
> enclosing class, and class broken out separately in order to do anything
> more useful with this, or at least have an oracle of possible classes you
> can look up (though that would still fail if A.B and A$B were both present).
>  JReferenceType just takes a single string, so you can't get that
> information.
>
> However, I think in this case there is no need to replace $, since despite
> the lack of documentation I believe type.getName() is actually a source name
> (we have been really sloppy with the 3 types of names - a year or two ago I
> started to rewrite it all with type-safe wrappers but that was rejected
> because it dramatically increased memory usage in the compiler).  For
> example, if you look at ReferenceMapper.createType, it takes a JDT
> ReferenceBinding.compoundName and creates the names by simply joining the
> components with dots.  My guess is if you simply remove the .replace from
> that line, it will work fine (and in fact is removing a bug).  I wouldn't
> get your hopes up that that is the last time you will run into a problem,
> because anyplace that calls Name.isSourceName, for example, will fail on a
> class name with an embedded $.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

Hi again,

Can you point out any of places where you saw this assumption?  The
last time I was mucking around with binary type names I was told not
to assume that $ could not appear in source names, so it might be
unintentional.

-Eric.

On Wed, May 25, 2011 at 5:51 PM, Grzegorz Kossakowski
 wrote:
> Hi,
>
> Poking around a bit more I found that gwtc seems to assume internally
> that whenever type name contains '$' it's in "binary form" and if it
> doesn't contain dollar sign then it can be considered to be in "source
> form". It's worth noting (and it's admitted in gwtc's internals) that
> this condition doesn't split of all type names into disjoint union of
> two respective sets.
>
> Anyway, my question is: how much of gwt internals rely on this
> distinction? I noticed that gwtc is doing handful number of
> conversions between those two forms. This is particularly problematic
> for my work because jribble can have dollar sign in it's type name and
> this would be extremely hard to change.
>
> Also, it looks like Java allows type names containing dollar sign:
>
> mac-grek:javajunk grek$ echo 'class A$B {}' > A\$B.java
> mac-grek:javajunk grek$ javac 'A$B.java'
> mac-grek:javajunk grek$ javap 'A$B'
> Compiled from "A$B.java"
> class A$B extends java.lang.Object{
>    A$B();
> }
>
> Is gwtc handling those cases in pure java environment properly?
>
> --
> Grzegorz Kossakowski
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] Re: Fix expression ranges in detailed SOYC output (issue1451801)

[Eric Ayers]

LGTM

On Tue, May 24, 2011 at 4:55 PM,   wrote:
> LGTM
>
>
> http://gwt-code-reviews.appspot.com/1451801/
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

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 [ 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

Re: [gwt-contrib] gwtc classpath

[Eric Ayers]

On Tue, May 24, 2011 at 9:33 AM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> 2011/5/24 Eric Ayers :
> > Yes, that class does read bytecode, but the source of the bytecode isn't
> > usually compiled .class files from the classpath, its the result of
> running
> > JDT on the sources.  I think it might be confusing because I worked on a
> > project to try to build type oracle from bytecode from any compiler, but
> we
> > have kind of abandoned that effort in favor of creating an equivalent to
> > javac that spits out more than just bytecode with each compiled class.
>
> Do you want to say that gwtc doesn't read .class files from classpath
> at all? Or if it does in what cases and what for?
>
> > I think I see why you are having the problem, yes.   But since the
> > collections in B are only needed at the source level (Type Oracle does
> not
> > need .class files), your "dev" jar could just contain .class files and a
> >  separate "runtime" jar could just contain .java sources and not .class
> > files.  I think this would fix your build woes, but it might make
> debugging
> > the collections a bit tricky.
>
> The problem is that I don't have .java files for scala-library (it's
> written in scala but compiled to jribble[1]). If I have java class J
> referring to scala class S (that we have .jribble for) then in order
> to run JDT for J we need information about S. The idea was to use
> .class file corresponding to S so JDT can correctly resolve references
> to S from J and build it's AST. Then JDT could build AST nodes for
> Java files that would get converted to GWT nodes and for jribble we
> have our own logic that converts jribble directly to GWT nodes without
> JDT involved in a process. We would need to populate TypeOracle with
> data corresponding jribble classes but we could use the same .class
> files that JDT was using for Scala (jribble) code.
>
> To sum up:
>  * version A of scala-library is needed by gwtc itself and we need
> (and have) only .class files for it
>  * version B of scala-library is in two forms: .jribble files and
> .class files. Class files are needed by JDT in order to resolve
> references to scala-library from Java sources of application we are
> compiling and by special logic that populates TypeOracle for that
> application for .jribble files. We need .jribble files to build GWT
> AST nodes.
>
> Now the question is how can I make version B of .class files visible
> only to JDT and special logic in TypeOracleMediator? Sounds I need
> custom classloader but I fear that gwtc reads .class files somewhere
> else for whatever purpose and I would get some nasty inconsistencies
> that would be extremely hard to debug.
>

If you are in the guts of the compiler and want to populate the type oracle
form byte code, you can build a list of TypeOracleMediator.TypeData objects
from any bytecode you like (doesn't have to be on classpath).  This won't
feed into the building of the AST - that has to build from source.



> If it's not a case how can I plug my own classes that would be visible
> to JDT? Is AbstractCompiler. INameEnvironmentImpl what I should be
> looking at?
>
> [1] jribble contains similar information as java code but jdt doesn't
> know about it, obviously.
>
> --
> Grzegorz Kossakowski
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] gwtc classpath

[Eric Ayers]

On Tue, May 24, 2011 at 8:00 AM, Grzegorz Kossakowski <
grzegorz.kossakow...@gmail.com> wrote:

> 2011/5/24 Eric Ayers :
> > Hi Grzegorz,
> >
> > You mentioned the compiled classes in the class path are used to
> > populate the type orace.  For the most part, the type oracle types are
> > compiled from source.  Types that don't have source are then checked
> > to see if they are binary annotations and then a type oracle reference
> > is entered.
>
> I have addNewTypes method in mind:
>
> http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java&l=380
>
> It reads class file data and uses it to populate TypeOracle, right?
>

Yes, that class does read bytecode, but the source of the bytecode isn't
usually compiled .class files from the classpath, its the result of running
JDT on the sources.  I think it might be confusing because I worked on a
project to try to build type oracle from bytecode from any compiler, but we
have kind of abandoned that effort in favor of creating an equivalent to
javac that spits out more than just bytecode with each compiled class.


>
> > Could it be true that scala-library.jar contains both libraries to use
> > with the GWT compiler and some sort of runtime environment (sources)
> > to compile with your app?  If so, maybe the solution is to split
> > scala-library.jar into the equivalent of 'dev' and 'user' components,
> > such that 'user' is not needed for running the compiler and 'dev' is
> > not needed for the app to link against.
>
> I think the answer is no. Let me explain the issue a little bit more.
> The scala-library.jar contains the whole scala runtime library
> including things like scala collections, etc. Those classes are used
> by gwtc itself to handle jribble input (alternative to java input).
>
> Now, application written in Scala is going to use the same classes
> (e.g. collections) but of different version. Thus we need two versions
> of .class files on the classpath: one (call it A) used by gwtc
> implementation and one (call it B) used for application itself. We
> need B version of .class files on a classpath because JDT needs those
> classes in order to properly resolve references to Scala code
> (application code) from Java code. We also need B in order to populate
> TypeOracle in addNewTypes method.
>
> Does this explain the issue a bit better now?
>

I think I see why you are having the problem, yes.   But since the
collections in B are only needed at the source level (Type Oracle does not
need .class files), your "dev" jar could just contain .class files and a
 separate "runtime" jar could just contain .java sources and not .class
files.  I think this would fix your build woes, but it might make debugging
the collections a bit tricky.



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



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] gwtc classpath

[Eric Ayers]

Hi Grzegorz,

You mentioned the compiled classes in the class path are used to
populate the type orace.  For the most part, the type oracle types are
compiled from source.  Types that don't have source are then checked
to see if they are binary annotations and then a type oracle reference
is entered.

Could it be true that scala-library.jar contains both libraries to use
with the GWT compiler and some sort of runtime environment (sources)
to compile with your app?  If so, maybe the solution is to split
scala-library.jar into the equivalent of 'dev' and 'user' components,
such that 'user' is not needed for running the compiler and 'dev' is
not needed for the app to link against.

On Mon, May 23, 2011 at 6:29 PM, Grzegorz Kossakowski
 wrote:
> Hello,
>
> I run into a case when I want to have different classpath for running
> gwtc (through com.google.gwt.dev.Compiler class) from classpath
> containing source code that gwtc would compile.
>
> Let me give you a specific scenario. My fork of gwt is using
> scala-library.jar of some version A for implementing internals of
> gwtc. Now application that gwtc should compile uses different version
> B of scala-library.jar that is binary incompatible with A. Is it
> possible to run gwtc so it uses A for it's own execution but uses B
> for JDT execution, populating TypeOracle, etc.?
>
> One thing that's worth mentioning: I'm talking here about compiled
> classes in classpath because they are used to populate TypeOracle.
> Source code (used for constructing GWT AST nodes) is in one copy
> corresponding to version B.
>
> --
> Grzegorz Kossakowski
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Changed formatting of SOYC compiler report to use large number grouping (ex: 7,923,764), (issue1449803)

[Eric Ayers]

I'm looking at a sample report, and I see that the percentages don't line up
in columns on the first split point page.

I expected:

 (0.32%)
 (2.10%)

or

  (0.3%)
  (2.1%)

same thing on the Package Breakdown page.

On Wed, May 18, 2011 at 11:17 AM,  wrote:

> Reviewers: zundel,
>
> Description:
> Changed formatting of SOYC compiler report to use large number grouping
> (ex: 7,923,764),
> change milliseconds to decimal seconds, and use better column alignment.
>
> Review by: zun...@google.com
>
> Please review this at http://gwt-code-reviews.appspot.com/1449803/
>
> Affected files:
>  M dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
>  M dev/core/src/com/google/gwt/soyc/resources/soyc.css
>
>
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

Some background - some optimizers run themselves in a loop on each
pass of the optimizer.  During some performance investigations last
year, we tried to get some of these extra loops out, but Pruner was a
tough nut to crack.  The nasty thing about this looping behavior is
that the last pass through is always wasted (you know to exit the loop
when the optimizer doesn't change the tree.)

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.

On Fri, May 13, 2011 at 11:03 AM,   wrote:
> Can you clarify what you mean by "Pruner runs only once"?  It looks like
> it will still be invoked multiple times by the optimizeLoop, etc.  Can
> you provide some background on the "jitter" phenomena?
>
> http://gwt-code-reviews.appspot.com/1436802/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

I had to drag Alex into this.  I thought I'd move the process along by
mass formatting from eclipse UI on the package or project level, but
that also skips our GWT specific tweaks.

On Thu, May 12, 2011 at 12:24 PM,   wrote:
>
> http://gwt-code-reviews.appspot.com/1442805/diff/1/user/super/com/google/gwt/benchmarks/translatable/com/google/gwt/benchmarks/client/Benchmark.java
> File
> user/super/com/google/gwt/benchmarks/translatable/com/google/gwt/benchmarks/client/Benchmark.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1442805/diff/1/user/super/com/google/gwt/benchmarks/translatable/com/google/gwt/benchmarks/client/Benchmark.java#newcode28
> user/super/com/google/gwt/benchmarks/translatable/com/google/gwt/benchmarks/client/Benchmark.java:28:
> }-*/;
> On 2011/05/12 16:13:10, rjrjr wrote:
>>
>> Uh oh. The auto-formatter clobbers jsni. This seems pretty bad.
>
> Good Catch.  I'll see if there's something I can do...
>
> 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

Re: [gwt-contrib] Re: Wrap low-priorty log calls with an 'if' test to avoid unnecessary calls (issue1426802)

[Eric Ayers]

On Thu, Apr 21, 2011 at 1:50 PM, Daniel Rice (דניאל רייס)
 wrote:
>  I ran a Showcase compile with log level 'info' 4 times each way, and
> took the average of the 3 best times for each way:
>
> Without 'if' tests: 396 seconds
> With 'if' tests: 350 seconds


wow, this is fantastic.

>
> So this feels like a small but significant savings.
>
> My thinking about where to put guards is as follows (for comparison,
> in Android it was policy to always put guards):
>
> 1) For WARNING or ERROR messages, don't put a guard since these will
> usually be emitted anyway
> 2) For lower priorities, put a guard if there is any code more complex
> than simply passing a constant or pre-existing string
>  2a) If the message is not emitted, we perform one comparison against
> an object instance field, which
>         we would have done anyway inside of logger.log
>  2b) If the message is emitted, we have done one extra comparison,
> but the cost will be swamped by the cost
>         of actually emitting the message
>
> So, I don't think we can really make things slower in any realistic scenario.
>
> On Tue, Apr 19, 2011 at 3:08 PM,   wrote:
>> The actual code changes LGTM, but I am skeptical about the performance
>> benefits of guarding all the ones that do nothing more than string
>> concats.  If that is really too expensive, then virtually no log call
>> should be unguarded, and we should just require callers to insert their
>> own guards and remove the check from log/branch.
>>
>> Before committing the guards around just string concats, I would like to
>> see some measurements that suggest it is worth the cost of cluttering up
>> the code.
>>
>> http://gwt-code-reviews.appspot.com/1426802/
>>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Suppresses multiple warnings related to validation .jar file and (issue1424804)

[Eric Ayers]

Well you are right. This patch will suppress errors if you are missing
both .jar files, but if you add in
validation-api--sources.jar, you get a different slew of
non-fatal errors.

followup patch at: http://gwt-code-reviews.appspot.com/1422804

On Tue, Apr 19, 2011 at 11:24 AM, Rodrigo Chandia  wrote:
> On Tue, Apr 19, 2011 at 11:19 AM, Eric Ayers  wrote:
>>
>> good question.  I know that the -sources.jar file is needed to just
>> "make the errors go away" for legacy projects that don't reference any
>> classes that use javax.validation, but I haven't seen the messages for
>> a sample that actually needs validation.
>
> I think you are right. I was testing with the sample app webAppCreator (and
> GPE) generates for new projects, which uses javax.validation on the client.
>
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Suppresses multiple warnings related to validation .jar file and (issue1424804)

[Eric Ayers]

good question.  I know that the -sources.jar file is needed to just
"make the errors go away" for legacy projects that don't reference any
classes that use javax.validation, but I haven't seen the messages for
a sample that actually needs validation.

On Tue, Apr 19, 2011 at 11:13 AM,   wrote:
> I think gwtc also needs validation-api-.jar (no '-sources') in
> the classpath. Will this make users think only the sources jar is
> needed?
>
> On 2011/04/19 12:08:00, zundel wrote:
>>
>> Before this patch, compiling this app would return many lines of
>
> output of the
>>
>> form:
>
>>  [java]             Checking rule 
> class='com.google.gwt.validation.rebind.GwtSpecificValidatorGenerator'/>
>>
>>     [java]                [WARN] Unknown type
>> 'com.google.gwt.validation.client.impl.GwtSpecificValidator' specified
>> in deferred binding rule
>>     [java]             Checking rule > class='com.google.gwt.validation.rebind.ValidatorGenerator'/>
>>     [java]                [WARN] Unknown type
>> 'javax.validation.Validator' specified in deferred binding rule
>>     [java]          Rebinding
>> com.google.gwt.i18n.client.BidiPolicy.BidiPolicyImpl
>>     [java]             Checking rule > class='com.google.gwt.editor.rebind.SimpleBeanEditorDriverGenerator'/>
>>     [java]                [WARN] Unknown type
>> 'com.google.gwt.editor.client.SimpleBeanEditorDriver' specified in
>> deferred binding rule
>
>> With this patch, here is the updated output (using GWT SDK compiled
>
> from r10016
>>
>> trunk)
>
>>      [java] Compiling module
>> com.google.gwt.gadgets.sample.hellogadgets.HelloGadgets
>>      [java]    Validating newly compiled units
>>      [java]       Ignored 71 units with compilation errors in first
>
> pass.
>>
>> Specify -logLevel DEBUG to see all errors
>>      [java]    Computing all possible rebind results for
>> 'com.google.gwt.user.client.UserAgentAsserter'
>>      [java]       Rebinding
>
> com.google.gwt.user.client.UserAgentAsserter
>>
>>      [java]          Checking rule > class='com.google.gwt.editor.rebind.SimpleBeanEditorDriverGenerator'/>
>>      [java]             [WARN] Detected warnings related to
>> 'com.google.gwt.editor.client.SimpleBeanEditorDriver'.   Is
>> validation-api--sources.jar on the classpath?
>>      [java]             Specify -logLevel DEBUG to see all errors.
>>      [java]             [WARN] Unknown type
>> 'com.google.gwt.editor.client.SimpleBeanEditorDriver' specified in
>
> deferred
>>
>> binding rule
>>      [java]    Compiling 6 permutations
>>      [java]       Compiling permutation 0...
>>      [java]       Compiling permutation 1...
>>      [java]       Compiling permutation 2...
>>      [java]       Compiling permutation 3...
>>      [java]       Compiling permutation 4...
>>      [java]       Compiling permutation 5...
>>      [java]    Compile of permutations succeeded
>
>
>
> http://gwt-code-reviews.appspot.com/1424804/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Remove the ability to deduce the script base using the marker script in the xsiframe linker sinc... (issue1425801)

[Eric Ayers]

Hi Unnur,

When you say it won't work in FF 3.5, is it just that version only?
does it give a result that just wrong or does it just fail?  What is
the consequence of removing the marker script test for the other
browsers?   Where I'm going with this is to just excluding the test
specifically on FF35 and/or moving the order of the marker script test
might be less disruptive.

On Fri, Apr 15, 2011 at 3:33 PM,   wrote:
> Reviewers: zundel,
>
> Description:
> Remove the ability to deduce the script base using the marker script in
> the xsiframe linker since it doesn't work in FF3.5 and we can't make it
> work
> without sacrificing late loading
>
> Review by: zun...@google.com
>
> Please review this at http://gwt-code-reviews.appspot.com/1425801/
>
> Affected files:
>  A dev/core/src/com/google/gwt/core/ext/linker/impl/ComputeScriptBaseOld.js
>  M
> dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js
>
>
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Addresses ClassNotFoundException problems when the data structures serialized in (issue1412801)

[Eric Ayers]

I'm thinking about using ByteArrayOutputStream and serializing 2
special object with readObject() implemented to throw the exception I
want to test.

On Mon, Apr 11, 2011 at 5:30 PM,   wrote:
>
> http://gwt-code-reviews.appspot.com/1412801/diff/1/dev/core/test/com/google/gwt/dev/javac/PersistentUnitCacheTest.java
> File dev/core/test/com/google/gwt/dev/javac/PersistentUnitCacheTest.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1412801/diff/1/dev/core/test/com/google/gwt/dev/javac/PersistentUnitCacheTest.java#newcode41
> dev/core/test/com/google/gwt/dev/javac/PersistentUnitCacheTest.java:41:
> private final byte[] INVALID_CACHE_LOG = { //
> This seems kinda brittle?  I wonder if there's a way to generate an
> appropriate stream programmatically.
>
> Maybe something involving a pair of class loaders, A and B, which are
> children of the system class loader, but provide one additional class, a
> CompilationUnit subtype that isn't loaded in the system class loader.
> You write the stream using A and read it back using B.  In addition to
> testing a class that doesn't exist in B, you could test slightly
> different versions of the same class in A & B and test for the
> incompatible class change.  Not sure if it's worth all that trouble tho,
> just rambling here.
>
> http://gwt-code-reviews.appspot.com/1412801/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] Re: Autoformat the api-checker tool source (issue1405801)

[Eric Ayers]

On Wed, Apr 6, 2011 at 12:11 AM, John Tamplin  wrote:
> On Tue, Apr 5, 2011 at 8:35 PM, Ray Ryan  wrote:
>>
>> I don't think it's reasonable to ask Eric to tweak the auto formatter. We
>> had that conversation already. He's just doing the same thing we have
>> eclipse configured to do, right?
>
> Well, my understanding of the changes made to the formatter settings were:
>
> change the line width to 100
> let lines break at method invocations
>
> So, I am not sure why there are other changes which, IMHO, look really
> terrible.
> I thought the point of doing a few small blocks of code first was
> specifically to look for things like this that could be improved before we
> run it on everything.
>>
>> I can't look for real right now. Did you really find something aggregious?
>
> Well, I think it is pretty egregious, but YMMV.  In particular:
>
> the loss of the space in array initialization is a change for the worse that
> is one checkbox to fix

Fixed in another patch

> the assignment breaking is harder to fix, but I think the change is net for
> the worse because while the old settings allowed overly long lines,

The decision to turn that property on was due to the effects in:

  http://gwt-code-reviews.appspot.com/1368802

There were some internal discussions about this that culminated in the
gwt_format.xml change to turn on wrapping assignments at

http://gwt-code-reviews.appspot.com/1371802

> they
> seemed to occur only rarely in field initializers, and it is easy enough to
> work around that by initializing them in an initializer block instead of on
> the same line.  The current settings will screw up line breaks on
> assignments all over the place.
> The indentation issue I am talking about is like this.  Previous settings:
> logger.log(TreeLogger.log,
>     "A really long message "
>     + variable);
> while the new settings do this:
> logger.log(TreeLogger.log,
>     "A really long message "
>       + variable);
> however, I don't see where this is coming from.

>From what I can tell, this isn't a setting (at least not anymore),
maybe the eclipse formatter in Eclipse 3.6 has changed.

> Regarding detecting the builder pattern, it could detect multiple
> invocations a.foo().bar().foo().baz() etc, but I agree the current formatter
> doesn't have that capability and the new setting is better than the old
> setting.




-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Autoformat the api-checker tool source (issue1405801)

[Eric Ayers]

I asked Phil to go ahead and note what he found just so we could
verify that the formatter is doing what we want.

(can't edit rietveld right now...)

The 4 vs 2 space issue is spelled out in the "Making GWT Better" page
under indentation.
  http://code.google.com/webtoolkit/makinggwtbetter.html#codestyle
So I don't think anything's wrong there.

The breaking of the statement in the middle is not how most of us
would format that statement by hand, but there doesn't seem to be a
good way to tell the formatter to use builder formatting when the API
is  using builder pattern and something else when it isn't.  (How is
the formatter supposed to tell the difference?)


On Tue, Apr 5, 2011 at 8:35 PM, Ray Ryan  wrote:
> I don't think it's reasonable to ask Eric to tweak the auto formatter. We
> had that conversation already. He's just doing the same thing we have
> eclipse configured to do, right?
>
> I can't look for real right now. Did you really find something aggregious?
>
> On Apr 5, 2011 9:34 AM,  wrote:
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Log error instead of throwing when a generated unit cannot be transferred to a file. (issue1357804)

[Eric Ayers]

@Bob, Could we just generate a strong name seeded from the fully
parameterized type name  instead to solve both issues?

If this is going to have a good chance of affecting generators other
than the Editor Framework, I think we should make the file creation
non-fatal.

On Fri, Apr 1, 2011 at 8:00 PM,   wrote:
> http://gwt-code-reviews.appspot.com/1357804/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

On Thu, Mar 31, 2011 at 7:42 PM, Scott Blum  wrote:
> 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."

I was more concerned with, "this build failed silently. waah!"

I'll sleep on it

>>
>> 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
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

On Thu, Mar 31, 2011 at 6:35 PM,   wrote:
>
> http://gwt-code-reviews.appspot.com/1385810/diff/13011/dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java
> File dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java (right):
>
> http://gwt-code-reviews.appspot.com/1385810/diff/13011/dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java#newcode323
> dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java:323: public
> synchronized CompilationState getCompilationState(TreeLogger logger,
> boolean suppressErrors)
> Ouch... this is a far-reaching change. :(  One that makes me begin to
> wonder if the compilation state build should directly log errors at all.
>
> A different way to refactor, one I've thought about in the past, would
> be to never have errors get logged from the comp state build, and always
> have the caller log errors if desired, either by exposing a method on
> CompState or else making CompUnit.getErrors public.  This would remove
> the whole burden of error reporting from CompState and remove the need
> for the crazy threading of option strict all the way through the system.
>
> Thoughts, before I look at this in more detail?
>
> http://gwt-code-reviews.appspot.com/1385810/
>

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

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.   If you're going to move the burden
outside of CSB, I think the patch might look just as disruptive if you
were to log errors every place I passed 'false'.   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.)


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

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)

[Eric Ayers]

On Wed, Mar 23, 2011 at 12:23 PM, Scott Blum  wrote:
> 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.
>

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

-- 
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)

[Eric Ayers]

I didn't respond to Scott's initial comments:

> - My gut reaction is that it's odd to make it a command-line option.  It's not
> really a user-facing 'option' in the same way that draftCompile or 
> style=PRETTY
> is, it's just an internal implementation detail.  It would seem more like a 
> jvm
> flag, and perhaps later just always on.

Toby, Jason and I had planned to put all of these dev mode changes
behind a -X command line flag, but I went ahead and took out the
command line flag and made it a system property because it simplified
the API (enabled boolean flag in static api)

> - Same with having to encode the persistence dir into every single entry 
> point.
> Throwing it into WEB-INF in dev mode seems weird, and there's no fundamental
> reason dev mode and the compiler shouldn't share a unit cache anyway.  How 
> about
> just using / creating a well-known directory under the current directory?  If
> you fail to create the directory (permission problem) then you don't use the
> disk.

First, I want to let you know I put a lot of thought into where to put
the cache files and after discussions with Toby, we came up with the
WEB-INF solution.

There is precedent for putting the cache type files in WEB-INF (app
engine integration with GWT does this).  Also, its a terrific place
when you consider that with our GWT ant setup, the cache gets removed
when you run 'ant clean'.I've updated the Compiler entry point to
also use the war/WEB-INF dir so the cache can be shared with web mode.

The problem with using the current working directory is that
potentially we are going to splatter cache directories all over the
disk, and no user is going to thank us for that.   Also, where would
we tell users to clean things up?  How could they write a reliable
clean target?

The problem with a 'well known' place, like /tmp/gwt-unitCache is that
in a shared environment, that cache is not just going to be shared
between compiles (what we want), it is going to be shared between
different users on the same machine, and I'm pretty sure we don't want
that.

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

[gwt-contrib] Re: CompileModule / GwtAstBuilder (issue1373805)

[Eric Ayers]

On Tue, Mar 8, 2011 at 9:36 PM,  wrote:

> Okay.. so should I submit this?  That way, future reviews will be vs.
> trunk.
>
> Maybe I should add a basic unit test to make sure that this at least
> doesn't crash, and maybe even that the output is the same as the web
> mode compiler for some test file.
>
>
I'm in favor of that.


>
>
>
> http://gwt-code-reviews.appspot.com/1373805/diff/6001/dev/core/src/com/google/gwt/dev/jjs/impl/GwtAstBuilder.java
> File dev/core/src/com/google/gwt/dev/jjs/impl/GwtAstBuilder.java
> (right):
>
>
> http://gwt-code-reviews.appspot.com/1373805/diff/6001/dev/core/src/com/google/gwt/dev/jjs/impl/GwtAstBuilder.java#newcode1595
> dev/core/src/com/google/gwt/dev/jjs/impl/GwtAstBuilder.java:1595: // SEE
> NOTE ON JDT FORCED OPTIMIZATIONS
> Oops, must have lost it.  Will fix.
>
>
> http://gwt-code-reviews.appspot.com/1373805/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] CLA response

[Eric Ayers]

No, there is no automated acknowledgement, but I  just checked and can see
that it got here OK.

On Tue, Mar 8, 2011 at 4:53 AM, Jens  wrote:

> Hi,
>
> I signed the individual CLA through the online form (I think it was last
> friday) and just wondering if there is any response from Google when its
> accepted?
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors




-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

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.

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.

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?

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.)

On Wed, Mar 2, 2011 at 10:02 PM, Scott Blum  wrote:

> 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.
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

@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.

On Wed, Mar 2, 2011 at 7:12 PM,  wrote:

> You'll want to revert your diff-cheese anyhow before committing, but
> yes, that help.
>
> LG except for TypeOracle hack.  Just make your tests use the correct
> FQTN for JavaScriptObject.
>
>
>
>
> http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/src/com/google/gwt/dev/javac/typemodel/TypeOracle.java
> File dev/core/src/com/google/gwt/dev/javac/typemodel/TypeOracle.java
> (right):
>
>
> http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/src/com/google/gwt/dev/javac/typemodel/TypeOracle.java#newcode156
> dev/core/src/com/google/gwt/dev/javac/typemodel/TypeOracle.java:156: *
> @param className Overrides the fullly qualified class name for
> JavaScriptObject.
> fully
>
>
>
> 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#newcode599
> dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java:599:
> protected static final CheckedJavaResource CU_JavaScriptObject = new
> CheckedJavaResource(
> With a little kung-fu, you could make the fully-qualified type name here
> be the same as the REAL JavaScriptObject FQTN, and thus avoid the
> egregious for-testing hackery in TypeOracle.
>
>
> http://gwt-code-reviews.appspot.com/1369805/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

In TypeOracleMediatorTestBase, the only thing I changed was to add new unit
tests, and add a tearDown() method. The rest is reformatting cheese.  Does
that help?

On Wed, Mar 2, 2011 at 6:56 PM,  wrote:

> I'm getting lost in the diff cheese.  Can you post a review sans
> auto-format diffs?
>
>
> http://gwt-code-reviews.appspot.com/1369805/
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] Re: Fixes a bug in TypeOracle for computing information about single JSO impls. (issue1373803)

[Eric Ayers]

Unit test up for review at:

http://gwt-code-reviews.appspot.com/1369805

On Wed, Mar 2, 2011 at 11:32 AM,  wrote:

> On 2011/03/02 16:30:22, knorton wrote:
>
>> lgtm
>>
>
> me too
>
>
> http://gwt-code-reviews.appspot.com/1373803/
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

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] Re: Adds a 10 second flush timer to the Speed Tracer logger. (issue1361801)

[Eric Ayers]

@jbrosenberg: the existing flush mechanism is meant pretty much just for
unit tests (package protected method flush()).  It has extra tooling to
communicate from one thread over to the background thread.  To implement a
10 second flush in the writer thread, there is no need to synchronize
between threads and block the sender thread the way that
SpeedTracerLogger.flush() does.

@tobyr: The flush is once every 10 seconds.  If there is no data in the
buffer, flush should be a no-op.  Does that really sound burdensom?  I don't
think this flush is the same as an OS level sync to disk - its just pushing
the buffered data out from the JVM buffers into the OS.

   void java.io.Writer.flush() throws IOException

  Flushes the stream. If the stream has saved any characters from the
various write() methods in a buffer,
write them immediately to their intended destination. Then, if that
destination is another character or byte
stream, flush it. Thus one flush() invocation will flush all the buffers in
a chain of Writers and OutputStreams.
If the intended destination of this stream is an abstraction provided by the
underlying operating system, for
example a file, then flushing the stream guarantees only that bytes
previously written to the stream are
passed to the operating system for writing;* it does not guarantee that they
are actually written to a physical
device such as a disk drive.*

If we don't do this flush, you can't look at the log while the app is
running - the data just stays buffered until enough data fills the buffer or
the app closes.  In my case, I wanted to look at DevMode while DevMode was
still running.

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.
>
> On Wed, Feb 23, 2011 at 11:30 AM,  wrote:
>>
>> Chris, the problem Eric is trying to address here is that you are not
>> always guaranteed to get the shutdown sequence cleanly when you quit the
>> app, so this helps insure that data will be written out.
>>
>> Although, I'm wondering if 10 seconds is too long, Eric, how about 5
>> seconds?
>>
>>
>>
>>
http://gwt-code-reviews.appspot.com/1361801/diff/1/dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java
>> File
>>
>>
dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java
>> (right):
>>
>>
>>
http://gwt-code-reviews.appspot.com/1361801/diff/1/dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java#newcode352
>>
>>
dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:352:
>> public void run() {
>> Might it be a bit cleaner, to use a java.util.Timer, and have it
>> periodically call flush()?  This way, there's no separation between the
>> flush mechanism that's there, and this new auto-flush feature. (In
>> looking at it, might need to make the flushLatch thread conscious, a
>> separate issue here).
>>
>> http://gwt-code-reviews.appspot.com/1361801/
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

-- 
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)

[Eric Ayers]

We hadn't shut down yet, for one...

On Wed, Feb 23, 2011 at 11:07 AM,   wrote:
> On 2011/02/23 16:00:20, zundel wrote:
>>
>> The impetus for this patch was an issue where dev mode had a problem
>
> and stopped
>>
>> prematurely.  We saw no further events to the speedtracer log.
>
> Shouldn't the shutdown event be the catch-all for situations like this?
> There's probably value in flushing periodically anyways, but I'm curious
> why that didn't work for the case described.
>
> http://gwt-code-reviews.appspot.com/1361801/
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Follow on to svn r8671, which made the GWT code style allow whitespace (issue1346803)

[Eric Ayers]

Was the intention to require all expressions to be put on a new line,
or only when the dots are preceeded by whitespace?

On Wed, Feb 9, 2011 at 10:48 AM, Ray Ryan  wrote:
> That's pretty bad. I'll tweak. Even if we can't have perfect builders we can
> at least wrap long lines better.
>
> On Feb 9, 2011 7:43 AM,  wrote:
>> I did a spot check. There is one odd thing that happens with the new
>> settings on eclipse 3.5 (found in JsCatchScope)
>>
>> @Override
>> protected JsName findExistingNameNoRecurse(String ident) {
>> if (name.getIdent().equals(ident)) {
>> return name;
>> }
>> }
>>
>> becomes
>>
>> @Override
>> protected JsName findExistingNameNoRecurse(String ident) {
>> if (name.getIdent()
>> .equals(ident)) {
>> return name;
>> }
>> }
>>
>> http://gwt-code-reviews.appspot.com/1346803/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] Re: Follow on to svn r8671, which made the GWT code style allow whitespace (issue1346803)

[Eric Ayers]

The whitespace is me cutting and pasting. I trimmed the function of
some stuff that wasn't pertinent to the problem.

On Wed, Feb 9, 2011 at 10:50 AM, John Tamplin  wrote:
> On Wed, Feb 9, 2011 at 10:43 AM,  wrote:
>>
>> I did a spot check.  There is one odd thing that happens with the new
>> settings on eclipse 3.5  (found in JsCatchScope)
>>
>> @Override
>>  protected JsName findExistingNameNoRecurse(String ident) {
>>    if (name.getIdent().equals(ident)) {
>>      return name;
>>    }
>>  }
>>
>> becomes
>>
>> @Override
>>  protected JsName findExistingNameNoRecurse(String ident) {
>>    if (name.getIdent()
>>      .equals(ident)) {
>>      return name;
>>    }
>>  }
>
> Yes, we have lots of cases like this, where 2 or 3 method calls are chained
> but not in a builder pattern.  I suggest just letting it break before a dot
> if it needs to in order to fit on the line, but not force it.
> Also, shouldn't the .equals line be indented 2 more?  And where did the
> extra blank line come from?
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Decouple JsProgram; this allows the JS AST to serialize in pieces. (issue1342801)

[Eric Ayers]

I don't have anything else.

On Mon, Feb 7, 2011 at 2:24 PM,   wrote:
> Did you guys want to re-review, or having fixed the things you
> mentioned, is this LGTM?
>
> http://gwt-code-reviews.appspot.com/1342801/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Enhancements for SpeedTracerLogging within gwt (issue1336803)

[Eric Ayers]

LGTM2

On Fri, Feb 4, 2011 at 12:28 PM,   wrote:
> LGTM when LGTzundel
>
>
> http://gwt-code-reviews.appspot.com/1336803/diff/1/3
> File
> dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1336803/diff/1/3#newcode592
> dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:592:
> "Cummulative Collection Count",
> Long.toString(gcMXBean.getCollectionCount()));
> On 2011/02/04 15:56:46, jbrosenberg wrote:
>>
>> Yeah, what I am seeing is that the summaries can't be separated for
>
> individual
>>
>> timelines that overlap...You can only get a summary for a particular
>
> duration of
>>
>> time, and overlapping timelines will all contribute.  I think this is
>
> fine and
>>
>> desired behaviorThe speed tracer interface doesn't currently allow
>
> for
>>
>> separating things out otherwise...You can click on individual events,
>
> and the
>>
>> total time/self-time for that event appear accurate however, so I
>
> think it's
>>
>> been goodno?  Longer term, I'd have thought that making
>
> speedtracer support
>>
>> parallel timelines would be a goal anyway, no?
>
> I don't think parallell timelines are going to be supported any time
> soon. One alternative approach to consider would be to annotate the top
> level event with its GC time. I'm fine with this going in as is if it's
> more useful to have this data than to have accurate summary graphs
> whenever timelines intersect.
>
> http://gwt-code-reviews.appspot.com/1336803/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Fix CompilationStateBuilder's speed tracer logs. (issue1338803)

[Eric Ayers]

LGTM
On Feb 2, 2011 6:05 PM,  wrote:
>
> http://gwt-code-reviews.appspot.com/1338803/diff/1/2
> File dev/core/src/com/google/gwt/dev/javac/CompilationStateBuilder.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1338803/diff/1/2#newcode388
> dev/core/src/com/google/gwt/dev/javac/CompilationStateBuilder.java:388:
> Collection resultUnits =
> compileMoreLater.compile(logger,
> The deal is, all of the callers to this method already wrap this method
> inside the same event. That's why I was getting the trivial nesting
> where 0 time was spent in the parent. I'm just merging the child up into
> its parent.
>
> http://gwt-code-reviews.appspot.com/1338803/show

-- 
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)

[Eric Ayers]

This change removes the redundant copy of source in
TypeOracleMediatorTestBase.java (except for the mocks of a few system
classes)

On Thu, Jan 6, 2011 at 2:00 PM,  wrote:

> http://gwt-code-reviews.appspot.com/1254801/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: TypeOracle becomes interfaces (issue1113801)

[Eric Ayers]

Hey Alex,

Unfortunately, we realize this change created a binary
incompatibility.  The libraries should still be source compatible if
you recompile gwtext with the latest trunk.  Our plan is to announce
the change in the release notes for the next release.

-Eric.

On Fri, Dec 10, 2010 at 8:21 AM,   wrote:
> r9400 still doesn't work against pre-compiled third-party libraries, for
> example, GXT (ExtGWT).
> The error is:
>
> java.lang.IncompatibleClassChangeError: Found interface
> com.google.gwt.core.ext.typeinfo.JClassType, but class was expected
>        at
> com.extjs.gxt.ui.rebind.core.TemplatesGenerator$SourceGenerator.validateType(TemplatesGenerator.java:142)
>        at
> com.extjs.gxt.ui.rebind.core.TemplatesGenerator$SourceGenerator.generate(TemplatesGenerator.java:97)
>
>
> http://gwt-code-reviews.appspot.com/1113801/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Reduces size of the compile report (soyc) for large projects with many (issue1171801)

[Eric Ayers]

On Wed, Dec 1, 2010 at 1:49 PM,   wrote:
> LGTM, but please note my comments...
>
> SOYC is becoming smart!! One thing I'm wondering is whether we have a
> good way of making sure we still get the right information everywhere
> (the smarter it gets, the harder it gets to follow in some sense, e.g.,
> one-character function names, etc.).  There's SoycTest, but when I wrote
> it, it was pretty empty (just checking for the existence of a file or
> two).  Do you think medium term it would be worth it to add some tests
> to that to make sure we're getting the right entries in the different
> categories?


I forgot to answer this. I agree an automated test would be good.   I
don't have any great ideas on how to do it, but here are some
thoughts:

 - load a report page in HTML unit and start walking the DOM
 - perform some sort of automated broken link analysis on the report.

filed an issue

http://code.google.com/p/google-web-toolkit/issues/detail?id=5697
-- 
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)

[Eric Ayers]

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)

[Eric Ayers]

I commiserate.  But this patch has nothing to do with that method.

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)

[Eric Ayers]

Since the function isn't documented, I'm not sure what its supposed to
return, but it looks to me like  the getQualifiedBinaryName() method
returns the same string in all cases where it is actually used.  It
has a TODO(scottb): remove me... and is rarely used: only in some
error messages and as a key to a data structure in
MethodArgNamesLookup.  I added asserts() to test this in each instance
and they never tripped.

I can refactor one of the implementations out: which implementation do
you prefer?

On Tue, Nov 23, 2010 at 7:31 PM,   wrote:
>
> http://gwt-code-reviews.appspot.com/1144801/diff/6001/7001
> File dev/core/src/com/google/gwt/core/ext/typeinfo/JType.java (right):
>
> http://gwt-code-reviews.appspot.com/1144801/diff/6001/7001#newcode33
> dev/core/src/com/google/gwt/core/ext/typeinfo/JType.java:33: public
> String computeBinaryClassName() {
> So... my comment was going to be to rename this to getBinaryName().
> Then I saw getQualfiedBinaryName(), and I was like... wait, what?
> Shouldn't these basically be the same thing?  Our API makes me cry.
>
> http://gwt-code-reviews.appspot.com/1144801/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Fix AbstractDataTable.getValueTimeOfDay() to handle null (issue1067801)

[Eric Ayers]

This change LGTM, no need to roll back.

For future reference, you can commit be or more files by just listing the
file on the command line, but be warned that it recurses directories if you
pass a did name on the command line.
On Oct 30, 2010 8:55 PM,  wrote:
> So it was embarrassing. I submitted the Comparable change but it broke
> the build because it uses @Override on compareTo(), which is only
> supported since Java 6.
>
> I removed the @Override and committed using "--file ", trying to submit
> just that one fix. But svn went ahead and submitted this change as well.
>
> Guess this is what you get to have a contributor who doesn't know his
> svn command well.
>
> Should I rollback the change? Or we can continue the review and I can
> submit a follow-up change?
>
>
> http://gwt-code-reviews.appspot.com/1067801/show

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

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

[Eric Ayers]

This is an ugly recurring issue.  I left a somewhat similar bug for a
while and when I came back to it, either the compiler or the large
morphing codebase I was using as a repro class changed in such a way
as I couldn't recreate it.  I'm not sure if the bug is fixed or still
lurking somewhere.

On Mon, Oct 18, 2010 at 7:47 PM, Scott Blum  wrote:
> 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



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

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 )

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

> Eric,
>
> You mentioned before that I should run the trace logging to analyze the
> behavior of DeadCode before and after my change.  I did so, and my change
> resulted in the same number of top-level optimization loops.  The numbers
> are mostly identical, I think perhaps a small accounting change is the only
> discrepancy.  Logs attached.
>
> Scott
>
> On Tue, Oct 12, 2010 at 4:07 PM,  wrote:
>
>> FYI, I like the refactoring of JModVisitor
>>
>> 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.
>>
>> 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.
>
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

Scott,

>From what I can tell, is the last reference to
JModVisitor.madeChanges(), maybe we should remove that method.

On Wed, Sep 29, 2010 at 6:17 PM,   wrote:
> Reviewers: zundel,
>
> Description:
> The real AST isn't being mutated here, that happens a few lines below.
>
> Please review this at http://gwt-code-reviews.appspot.com/934801/show
>
> Affected files:
>  M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.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
> a74526e02494d58264952c640fa02187a894e0da..edb12572ba8660e014b1d42e05d53b5e09365e83
> 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
> @@ -371,7 +371,6 @@ public class MethodInliner {
>       // Replace all params in the target expression with the actual
> arguments.
>       ParameterReplacer replacer = new ParameterReplacer(x);
>       replacer.accept(targetExpr);
> -      madeChanges(replacer.getNumMods());
>
>       multi.exprs.add(targetExpr);
>       replaceWithMulti(ctx, multi);
>
>
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

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

[Eric Ayers]

The original code looks like:

class Foo {
  private int depth;

  void begin() {
depth++;
if (depth == 1)  {  //
  if (!isCondition) {
bar.baz();
  }
}
  }
}

depth is the lhs of the expression and is should be a primitive.

On Thu, Sep 23, 2010 at 5:15 PM, Chris Conroy  wrote:

> Comparing reference equality for Integer objects in Java is a bit of a
> minefield...
>
> Integer x = 1;
> Integer y = 1;
> System.out.println("1==1? " + (x==y ? "yes" : "no"));
>
> x = 127;
> y = 127;
> System.out.println("127==127? " + (x==y ? "yes" : "no"));
>
> x = 128;
> y = 128;
> System.out.println("128==128? " + (x==y ? "yes" : "no"));
>
> the above code produces:
> 1==1? yes
> 127==127? yes
> 128==128? no
>
> because Java interns integers from -127 to 127.
>
> On Thu, Sep 23, 2010 at 4:36 PM, Scott Blum  wrote:
>
>> 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
>>
>
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

-- 
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)

[Eric Ayers]

For more information, here's the exception.

Caused by: java.lang.ClassCastException:
com.google.gwt.dev.jjs.ast.JPrimitiveType cannot be cast to
com.google.gwt.dev.jjs.ast.JReferenceType
at com.google.gwt.dev.jjs.impl.EqualityNormalizer.endVisit(
EqualityNormalizer.java:85
)
at com.google.gwt.dev.jjs.ast.JBinaryOperation.traverse(
JBinaryOperation.java:84
)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(
JModVisitor.java:383
)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(
JModVisitor.java:283
)
... 41 more
  [ERROR] at PanelUpdateManager.java(152): null.nullField == 1
 com.google.gwt.dev.jjs.ast.JBinaryOperation
  [ERROR] at PanelUpdateManager.java(152): null.nullField == 1 &&
(null.nullField || null.nullMethod())
 com.google.gwt.dev.jjs.ast.JBinaryOperation
  [ERROR] at PanelUpdateManager.java(152): null.nullField == 1 &&
(null.nullField || null.nullMethod())
 com.google.gwt.dev.jjs.ast.JExpressionStatement
  [ERROR] at Panel.java(562): {
  null.nullMethod();
  ++null.nullField;
  ++null.nullField;
  null.nullField == 1 && (null.nullField || null.nullMethod());


According to Scott, "The right fix is, that 'null.nullField' ref needs its
type overridden"

On Thu, Sep 23, 2010 at 4:36 PM, Scott Blum  wrote:

> 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.
>
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] Re: Adds a way to tune the optimization level in steps from (issue915802)

[Eric Ayers]

On Thu, Sep 23, 2010 at 4:04 PM, Chris Conroy  wrote:

> Out of curiosity, which optimizer improves performance with a size increase
> side-effect? That might be worth exploring if the trade-off is sensible.


I believe that MethodInliner (java) and JsInliner could take a one line
function and stick the body in several places in the code, leading to an
overall larger output.  See optimizeLoop() in JavaToJavaScriptCompiler.java
for the list of optimizers that run.


> How does setting the number of passes to 3 affect optimizations that don't
> have an effect on code size? (I know this is harder to measure, but it's
> worth thinking about since that's essentially a hidden dimension on this
> graph)
>

Optimizers run serially, one after the other and there are interdependencies
between the changes made by one optimizer and the potential for new
optimizing by one that previously ran.  For example, the Pruner is limited
to pruning parameters for static methods only (I'm reading the comment here,
hope its not out of date).  There is another optimizer that runs later that
tries to make methods static.  Turning on statistics in the optimizationLoop
reveals that sometimes an optimizer 'unlocks' part of the tree that the
other optimizer can make a significant change on... but relative to the
overall size of the tree, I haven't seen anything large.

One thing that setting optimization to less than full is likely to do is to
tickle some bugs or "optimizations" in the rest of the code (JavaScript tree
optimizers or code generation) that expect the AST to be fully optimized.
 I've found a minor one at
http://gwt-code-reviews.appspot.com/897803/showand I'm sure there are
others out there.

-Eric.


> On Thu, Sep 23, 2010 at 3:55 PM, Eric Ayers  wrote:
>
>> On Thu, Sep 23, 2010 at 3:48 PM, Chris Conroy  wrote:
>>
>>> Why does the compiled size increase from 8 to 9? That would seem to
>>> indicate a bug with the optimizer in that step.
>>>
>>
>> Optimizers don't just reduce code size - they also attempt to improve
>> performance.
>>
>>
>>> On Thu, Sep 23, 2010 at 3:41 PM, Eric Ayers  wrote:
>>>
>>>> The attached graph shows an analysis of code size to compile time for
>>>> building a large application.  The code size is the total number of bytes
>>>> output for .cache.js files for all permutations added together.
>>>>
>>>> Somewhere between passes 2 to 4 is a "sweet spot", where further
>>>> optimization passes appear to be returning only marginal improvements.   At
>>>>  3 optimization passes,  Another way to verify that besides just the code
>>>> size metric is to look at the statistics I added in a week ago that show 
>>>> how
>>>> much the tree changes on each pass.  When we looked at the same 
>>>> application,
>>>> Changes were measured in the thousands on the first pass or two, then
>>>> trickled down into the tens in later passes.
>>>>
>>>> Previously, I had another implementation of this feature where the
>>>> DataflowOptimizer and SameParameterValueOptimizer were automatically turned
>>>> off until level 6 or higher (you can flip these off with a separate command
>>>> line flag).  In that case, code size was nearly the same, and compile time
>>>> was 220 seconds at optimization level 3.
>>>>
>>>> full optimization: 300s
>>>> 3 passes only: 250s
>>>> 3 passes - aggressive optimizations: 220s
>>>>
>>>> -Eric.
>>>>
>>>> On Thu, Sep 23, 2010 at 3:32 PM,  wrote:
>>>>
>>>>> Reviewers: scottb, fabbott, Lex,
>>>>>
>>>>> Description:
>>>>> Adds a way to tune the optimization level in steps from
>>>>> draft optimize to full optimization (the current default)
>>>>>
>>>>> Preliminary testing shows that optimization level '3'
>>>>> can give almost as good code size results (within 5%)
>>>>> as full optimization, with about 20% reduction in compile time.
>>>>>
>>>>>
>>>>> Please review this at http://gwt-code-reviews.appspot.com/915802/show
>>>>>
>>>>> Affected files:
>>>>>  M dev/core/src/com/google/gwt/dev/Precompile.java
>>>>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java
>>>>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java
>>>>>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>>>>&

Re: [gwt-contrib] Re: Adds a way to tune the optimization level in steps from (issue915802)

[Eric Ayers]

On Thu, Sep 23, 2010 at 3:48 PM, Chris Conroy  wrote:

> Why does the compiled size increase from 8 to 9? That would seem to
> indicate a bug with the optimizer in that step.
>

Optimizers don't just reduce code size - they also attempt to improve
performance.


> On Thu, Sep 23, 2010 at 3:41 PM, Eric Ayers  wrote:
>
>> The attached graph shows an analysis of code size to compile time for
>> building a large application.  The code size is the total number of bytes
>> output for .cache.js files for all permutations added together.
>>
>> Somewhere between passes 2 to 4 is a "sweet spot", where further
>> optimization passes appear to be returning only marginal improvements.   At
>>  3 optimization passes,  Another way to verify that besides just the code
>> size metric is to look at the statistics I added in a week ago that show how
>> much the tree changes on each pass.  When we looked at the same application,
>> Changes were measured in the thousands on the first pass or two, then
>> trickled down into the tens in later passes.
>>
>> Previously, I had another implementation of this feature where the
>> DataflowOptimizer and SameParameterValueOptimizer were automatically turned
>> off until level 6 or higher (you can flip these off with a separate command
>> line flag).  In that case, code size was nearly the same, and compile time
>> was 220 seconds at optimization level 3.
>>
>> full optimization: 300s
>> 3 passes only: 250s
>> 3 passes - aggressive optimizations: 220s
>>
>> -Eric.
>>
>> On Thu, Sep 23, 2010 at 3:32 PM,  wrote:
>>
>>> Reviewers: scottb, fabbott, Lex,
>>>
>>> Description:
>>> Adds a way to tune the optimization level in steps from
>>> draft optimize to full optimization (the current default)
>>>
>>> Preliminary testing shows that optimization level '3'
>>> can give almost as good code size results (within 5%)
>>> as full optimization, with about 20% reduction in compile time.
>>>
>>>
>>> Please review this at http://gwt-code-reviews.appspot.com/915802/show
>>>
>>> Affected files:
>>>  M dev/core/src/com/google/gwt/dev/Precompile.java
>>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java
>>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java
>>>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>>>  M dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerDraftCompile.java
>>>  A dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerOptimize.java
>>>  D dev/core/src/com/google/gwt/dev/util/arg/OptionDraftCompile.java
>>>  A dev/core/src/com/google/gwt/dev/util/arg/OptionOptimize.java
>>>
>>>
>>>
>>
>>
>> --
>> Eric Z. Ayers
>> Google Web Toolkit, Atlanta, GA USA
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors




-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Adds a way to tune the optimization level in steps from (issue915802)

[Eric Ayers]

The attached graph shows an analysis of code size to compile time for
building a large application.  The code size is the total number of bytes
output for .cache.js files for all permutations added together.

Somewhere between passes 2 to 4 is a "sweet spot", where further
optimization passes appear to be returning only marginal improvements.   At
 3 optimization passes,  Another way to verify that besides just the code
size metric is to look at the statistics I added in a week ago that show how
much the tree changes on each pass.  When we looked at the same application,
Changes were measured in the thousands on the first pass or two, then
trickled down into the tens in later passes.

Previously, I had another implementation of this feature where the
DataflowOptimizer and SameParameterValueOptimizer were automatically turned
off until level 6 or higher (you can flip these off with a separate command
line flag).  In that case, code size was nearly the same, and compile time
was 220 seconds at optimization level 3.

full optimization: 300s
3 passes only: 250s
3 passes - aggressive optimizations: 220s

-Eric.

On Thu, Sep 23, 2010 at 3:32 PM,  wrote:

> Reviewers: scottb, fabbott, Lex,
>
> Description:
> Adds a way to tune the optimization level in steps from
> draft optimize to full optimization (the current default)
>
> Preliminary testing shows that optimization level '3'
> can give almost as good code size results (within 5%)
> as full optimization, with about 20% reduction in compile time.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/915802/show
>
> Affected files:
>  M dev/core/src/com/google/gwt/dev/Precompile.java
>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java
>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java
>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>  M dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerDraftCompile.java
>  A dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerOptimize.java
>  D dev/core/src/com/google/gwt/dev/util/arg/OptionDraftCompile.java
>  A dev/core/src/com/google/gwt/dev/util/arg/OptionOptimize.java
>
>
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[Eric Ayers]

As far as the -Dgwt.speedtracerlog option goes, the most recent milestone
should have the feature I had in mind for diagnosing further.

On Mon, Sep 13, 2010 at 9:11 AM, David  wrote:

> Hi Eric,
>
> It would be acceptable for testing purpose only. releases to
> production have to be official versions. But it would make it soo much
> easier to already start using features that should normally be
> available by the time we go to production.
>
> David
>
> On Mon, Sep 13, 2010 at 3:02 PM, Joel Webber  wrote:
> > This is slightly off-topic, but I'm curious -- would having a formal
> nightly
> > build actually be acceptable for use within your locked-down environment?
> > And would the same go for "offline" dev-mode plugin installers?
> > Le 12 septembre 2010 08:43, David  a écrit :
> >>
> >> Eric,
> >>
> >> No I'm not using the draftCompile option, I will see if it improves even
> >> more.
> >>
> >> And yes, after removing the incubator from my project the whole
> >> project compile process only took 1/3rd of the time (7 minutes instead
> >> of 22 minutes). I guess the main reason is probably because we had to
> >> import both gen2 and widgetideas in.
> >>
> >> I am not able/allowed to get the trunk downloaded due to corporate
> >> policies. That's why in the past I asked if the GWT team did not want
> >> to consider daily builds/dev builds. So I will have to wait until 2.1
> >> is out.
> >>
> >> And when it is, I guess I will again have to ask for non installers
> >> for the IE/Firefox/Chrome plugins that do not mandate an internet
> >> connection :-S. So maybe for the poor corporate developers in very
> >> secure environments that fight to get GWT accepted: think about us!
> >> ;-)
> >>
> >> David
> >>
> >> On Fri, Sep 10, 2010 at 8:48 PM, Eric Ayers  wrote:
> >> > Hi David,
> >> >
> >> > Are you using the -draftCompile option? The reason I ask is that using
> >> > this
> >> > option cuts out the optimization steps to make the compile run faster.
> >> >  The
> >> > end result i that running the JDT compiler takes dominates the compile
> >> > time
> >> > when using it.   Everything on the sourcepath is compiled at least
> once
> >> > to
> >> > build the TypeOracle.  Every class that is actually used is run
> through
> >> > the
> >> > JDT compile library twice.  So, removing even unreferenced files from
> >> > the
> >> > source path should have a significant impact.
> >> >
> >> > We are considering all kinds of performance improvements, but keeping
> >> > modules small and independent and referencing the smallest number
> needed
> >> > is
> >> > going to always give the best compilation performance.  In the future,
> >> > if
> >> > you need one widget from a module that is full of unreferenced code,
> you
> >> > could define a custom one that includes just the paths you need to
> >> > minimize
> >> > compile time.
> >> >
> >> > If you like, run your build with a tip of trunk GWT and add
> >> > -Dgwt.speedtracerlog=/tmp/speedtracer.html both with and without the
> >> > incubator dependencies and I can tell more about why your compile time
> >> > improved so dramatically.
> >> >
> >> > -Eric.
> >> >
> >> > On Fri, Sep 10, 2010 at 11:02 AM, stuckagain 
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I managed to finally factor our the incubator widgets from my medium
> >> >> sized application and now that I have no dependencies left I saw the
> >> >> compile time decrease with 66%. Which is an amazing.
> >> >>
> >> >> We were only using 2 widgets yet this library had such a huge impact.
> >> >>
> >> >> Are there any plans to improve on this in the future ?
> >> >>
> >> >> David
> >> >>
> >> >> --
> >> >> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >> >
> >> >
> >> >
> >> > --
> >> > Eric Z. Ayers
> >> > Google Web Toolkit, Atlanta, GA USA
> >> >
> >> > --
> >> > 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
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[Eric Ayers]

Hi David,

Are you using the -draftCompile option? The reason I ask is that using this
option cuts out the optimization steps to make the compile run faster.  The
end result i that running the JDT compiler takes dominates the compile time
when using it.   Everything on the sourcepath is compiled at least once to
build the TypeOracle.  Every class that is actually used is run through the
JDT compile library twice.  So, removing even unreferenced files from the
source path should have a significant impact.

We are considering all kinds of performance improvements, but keeping
modules small and independent and referencing the smallest number needed is
going to always give the best compilation performance.  In the future, if
you need one widget from a module that is full of unreferenced code, you
could define a custom one that includes just the paths you need to minimize
compile time.

If you like, run your build with a tip of trunk GWT and add
-Dgwt.speedtracerlog=/tmp/speedtracer.html both with and without the
incubator dependencies and I can tell more about why your compile time
improved so dramatically.

-Eric.

On Fri, Sep 10, 2010 at 11:02 AM, stuckagain  wrote:

> Hi,
>
> I managed to finally factor our the incubator widgets from my medium
> sized application and now that I have no dependencies left I saw the
> compile time decrease with 66%. Which is an amazing.
>
> We were only using 2 widgets yet this library had such a huge impact.
>
> Are there any plans to improve on this in the future ?
>
> David
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)

[Eric Ayers]

I was thinking about how keeping track of the AST size on the fly could be
expensive and complicated.  The simplest thing to do would be to have to add
in a separate walk that just counted nodes, maybe once at the head of
optimizeLoop.  I wrote this dummy code earlier to measure the cost of just a
walk, and it turns out that walking the tree and counting all nodes is a
computationally significant amount of work - its like adding an extra
optimizer.  I didn't want to have too much observer effect if the change is
just for statistical purposes. (but maybe I could add that walk just in the
case of having tracing enabled.)

But I mis-spoke when describing my goal as tuning code size to compile time.
 I'm really just trying to find ways to shorten the compile time.   You've
 mentioned a couple of times about the optimizations being quadratic cost.
 I want to use this feature to add an option with a "decent" amount of
optimization and shave off a significant amount of the compile time.
 Something between draftCompile and fully optimized.  The decision point to
opt out of the build to could be specific to each optimizer.   For example,
if each optimizer declares that isn't doing "much"  through a single or two
consecutive passes, it might be time to throw in the towel.  We could have
users specify an optimization level:  -O, -O2, -O3, ... like c compilers and
gzip do to specify the amount of optimization desired.

At the water cooler we've speculated that there might be interaction between
optimizers we can predict.  e.g. dead code elimination isn't going to do
much if the pruner and type tightener weren't very effective on the last
pass (I just made that up).  Early in my investigations I was hoping that we
could just stop calling some of the optimizers that aren't very effective
after the first few passes, but the only visibility I had was the didChange
boolean.  Now we could do some statistics gathering on different apps and
see if that would be worth pursuing.

-Eric.

On Fri, Sep 3, 2010 at 12:02 AM, Ray Cromwell  wrote:

>
> I think it's useful to see the amount of work done vs time spent, but I
> don't think it will help  automate size-tradeoffs unless you keep track of
> the size of the AST as well, so that you can see roughly how much it's being
> reduced each pass. Some optimizations don't really shrink  the AST size, but
> enable other optimizations. e.g. type tightening, finalizing, and
> static-fying help method inliner, DCE, and pruner. It would be nice to
> correlate, for example, with and without those tightening/staticifying
> passes, how much worst the actual code-deleting passes would be, because
> that's the only real way if you know they're worth it.
>
> Some things have an effect far down the chain, for example, static-methods
> can be obfuscated better, because 'this' can't be obfuscated, so you don't
> see the code-size effect symbol obfuscation, as AST size doesn't tell the
> whole story.
>
> -Ray
>
>
> On Thu, Sep 2, 2010 at 8:48 PM, Eric Ayers  wrote:
>
>> I'm looking for feedback on this proposed change, mainly, is the
>> statistical information worth the added complexity?  Currently, this only
>> dumps out a diagnostic when you specify
>>
>>
>>   
>> -Dgwt.jjs.traceMethods=com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimize
>>
>> on the Compiler command line.  Here's a sample of what the statistical
>> output looks like on a minimal GWT app:
>>
>>   Pass 1    ( 0/ 0)
>>   Pruner 27.94% (  3132/ 11211)Finalizer 45.64% (  2455/
>>  5379) MakeCallsStatic  7.94% (   812/ 10229) TypeTightener  2.41% (  1226/
>> 50966) MethodCallTightener  1.96% (70/  3569) DeadCodeElimination  1.93%
>> (  1277/ 66324) MethodInliner 28.84% (  5430/ 18830)
>> SameParameterValueOptimizer  0.58% (44/  7588)
>>   Pass 2    ( 0/ 0)
>>   Pruner 12.24% (  1089/  8895)Finalizer  0.09% ( 4/
>>  4400) MakeCallsStatic  2.68% (   182/  6796) TypeTightener  0.80% (   272/
>> 33915) MethodCallTightener  1.36% (32/  2353) DeadCodeElimination  0.41%
>> (   166/ 40201) MethodInliner  9.95% (   956/  9609)
>> SameParameterValueOptimizer  0.24% (14/  5776)
>>   Pass 3    ( 0/ 0)
>>   Pruner  1.79% (   240/ 13392)Finalizer  0.00% ( 0/
>>  4036) MakeCallsStatic  0.50% (31/  6221) TypeTightener  0.31% (62/
>> 20088) MethodCallTightener  0.05% ( 1/  2190) DeadCodeElimination  0.20%
>> (74/ 37391) MethodInliner  2.90% (   250/  8608)
>> SameParameterValueOptimizer  0.11% ( 6/  5325)
>>   Pass 4    ( 0/

[gwt-contrib] Re: RR: Add statistics to optimizers (issue841801)

[Eric Ayers]

I'm looking for feedback on this proposed change, mainly, is the statistical
information worth the added complexity?  Currently, this only dumps out a
diagnostic when you specify

  
-Dgwt.jjs.traceMethods=com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimize

on the Compiler command line.  Here's a sample of what the statistical
output looks like on a minimal GWT app:

  Pass 1    ( 0/ 0)
  Pruner 27.94% (  3132/ 11211)Finalizer 45.64% (  2455/
 5379) MakeCallsStatic  7.94% (   812/ 10229) TypeTightener  2.41% (  1226/
50966) MethodCallTightener  1.96% (70/  3569) DeadCodeElimination  1.93%
(  1277/ 66324) MethodInliner 28.84% (  5430/ 18830)
SameParameterValueOptimizer  0.58% (44/  7588)
  Pass 2    ( 0/ 0)
  Pruner 12.24% (  1089/  8895)Finalizer  0.09% ( 4/
 4400) MakeCallsStatic  2.68% (   182/  6796) TypeTightener  0.80% (   272/
33915) MethodCallTightener  1.36% (32/  2353) DeadCodeElimination  0.41%
(   166/ 40201) MethodInliner  9.95% (   956/  9609)
SameParameterValueOptimizer  0.24% (14/  5776)
  Pass 3    ( 0/ 0)
  Pruner  1.79% (   240/ 13392)Finalizer  0.00% ( 0/
 4036) MakeCallsStatic  0.50% (31/  6221) TypeTightener  0.31% (62/
20088) MethodCallTightener  0.05% ( 1/  2190) DeadCodeElimination  0.20%
(74/ 37391) MethodInliner  2.90% (   250/  8608)
SameParameterValueOptimizer  0.11% ( 6/  5325)
  Pass 4    ( 0/ 0)
  Pruner  0.54% (57/ 10492)Finalizer  0.03% ( 1/
 3948) MakeCallsStatic  0.02% ( 1/  6086) TypeTightener  0.05% ( 8/
14660) MethodCallTightener  0.05% ( 1/  2147) DeadCodeElimination  0.47%
(   173/ 36545) MethodInliner  2.07% (   172/  8310)
SameParameterValueOptimizer  0.02% ( 1/  5126)
  Pass 5    ( 0/ 0)
  Pruner  0.67% (66/  9896)Finalizer  0.03% ( 1/
 3747) MakeCallsStatic  0.02% ( 1/  5732) TypeTightener  0.01% ( 2/
13845) MethodCallTightener  0.00% ( 0/  2012) DeadCodeElimination  0.05%
(19/ 35210) MethodInliner  0.20% (16/  8001)
SameParameterValueOptimizer  0.00% ( 0/  4976)
  Pass 6    ( 0/ 0)
  Pruner  0.30% (22/  7338)Finalizer  0.00% ( 0/
 3695) MakeCallsStatic  0.00% ( 0/  5691) TypeTightener  0.07% ( 9/
13660) MethodCallTightener  0.00% ( 0/  2001) DeadCodeElimination  0.06%
(13/ 23220) MethodInliner  0.00% ( 0/  2638)
SameParameterValueOptimizer  0.00% ( 0/  4938)
  Pass 7    ( 0/ 0)
  Pruner  0.10% ( 5/  4890)Finalizer  0.00% ( 0/
 3688) MakeCallsStatic  0.04% ( 2/  5690) TypeTightener  0.00% ( 0/
 4548) MethodCallTightener  0.00% ( 0/  2001) DeadCodeElimination  0.00%
( 0/ 11605) MethodInliner  0.38% (20/  5283)
SameParameterValueOptimizer  0.00% ( 0/  4937)
  Pass 8    ( 0/ 0)
  Pruner  0.04% ( 2/  4886)Finalizer  0.00% ( 0/
 3686) MakeCallsStatic  0.00% ( 0/  5684) TypeTightener  0.01% ( 1/
 9093) MethodCallTightener  0.00% ( 0/  1999) DeadCodeElimination  0.00%
( 0/ 11601) MethodInliner  0.00% ( 0/  2634)
SameParameterValueOptimizer  0.00% ( 0/  4933)
  Pass 9    ( 0/ 0)
  Pruner  0.00% ( 0/  2443)Finalizer  0.00% ( 0/
 3686) MakeCallsStatic  0.00% ( 0/  5684) TypeTightener  0.00% ( 0/
 4546) MethodCallTightener  0.00% ( 0/  1999) DeadCodeElimination  0.00%
( 0/ 11601) MethodInliner  0.00% ( 0/  2634)
SameParameterValueOptimizer  0.00% ( 0/  4933)
DataflowOptimizer  0.46% ( 5/  1080)

I think the information is interesting on its own, but it could prove useful
if we decide to implement a compiler option to allow users to make a
compilation time/code size output trade off.  Our current options are either
minimal optimization or maximum possible optimization.  We could probably
cut the production compile down a bit if we had an in-between option (and
maybe made it the default).

In a couple of places, I got rid of the didChange() overload on JModVisitor
subclasses.  I know that there is a difference, I'm wondering if it is
important.

My eclipse environment is a mess - please don't bother with code formatting
feedback until I dig myself out from under it.

-Eric.

On Thu, Sep 2, 2010 at 11:38 PM,  wrote:

> Reviewers: scottb, robertvawter, cromwellian,
>
> Description:
> RR: Add statistics to optimizers
>
> Updates the compiler optimizers to returns statistics about each pass
> instead of a simple boolean.   This could be used to analyze
> the effectiveness of an individual optimizer, tune the compiler
> for code size/ compile time trade offs, or predict the effectiveness
> of future passes of an optimizer.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/841801/show
>
> Affected files:
>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJ

[gwt-contrib] Re: Fixes a strange compiler bug where types generated into new packages may not be found. (issue831802)

[Eric Ayers]

LGTM2

On Thu, Sep 2, 2010 at 11:30 AM,  wrote:

>
> http://gwt-code-reviews.appspot.com/831802/diff/5001/3004
> File dev/core/src/com/google/gwt/dev/jdt/AbstractCompiler.java (right):
>
> http://gwt-code-reviews.appspot.com/831802/diff/5001/3004#newcode257
> dev/core/src/com/google/gwt/dev/jdt/AbstractCompiler.java:257: }
> The short answer is no: the looping behavior is intrinsic in how we
> interact with JDT.  Once we add the new types (as source), then once
> they get compiled by JDT we will visit the compiled units and look for
> more rebinds and jsni, iteratively.
>
> I did the reordering here because only Rebinds can actually generate any
> new types that weren't in CompilationState before.  JSNI can only
> reference existing type.
>
>
> http://gwt-code-reviews.appspot.com/831802/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Adds a hack to pre-initialize the Java Graphics2D library. (issue822801)

[Eric Ayers]

initGui() is invoked for running DevMode and running the compiler with the
GUI based logger enabled.

initGui() would be invoked first, before the threaded hack gets to run.
 I'll add a SpeedTracer annotation to initGui() and try it out on the mac to
see if there is a performance penalty that is worth acting on.

On Tue, Aug 31, 2010 at 5:56 PM,  wrote:

> This method used to be called by the compiler because of some
> "interesting" SWT/AWT interaction on mac. It might be worth looking to
> see where it is called these days:
>
>
> http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/dev/core/src/com/google/gwt/dev/BootStrapPlatform.java&%20package:http://google-web-toolkit%5C.googlecode%5C.com&sa=N&cd=1&ct=rc&l=38
>
>
> On 2010/08/31 21:47:43, zundel wrote:
>
>> I went over to my Mac and ran a compile under GPE and it worked fine
>>
> (I seemed
>
>> to get a measurable speedup too.)
>>
>
>  I consolidated the thread logic and removed the static member, but
>>
> left the
>
>> Thread subclass defined by itself just not to clutter the precompile()
>>
> method.
>
>  http://gwt-code-reviews.appspot.com/822801/diff/1/2
>> File dev/core/src/com/google/gwt/dev/Precompile.java (right):
>>
>
>  http://gwt-code-reviews.appspot.com/822801/diff/1/2#newcode390
>> dev/core/src/com/google/gwt/dev/Precompile.java:390:
>>
> createGraphicsEvent.end();
>
>> On 2010/08/31 21:11:48, scottb wrote:
>> > This looks fine, but my only comment is whether or not this can be
>>
> boiled down
>
>> > to something more general that would get the same effect? e.g.
>> > GraphicsEnvironment.getLocalGraphicsEnvironment().
>>
>
>  GraphicsEnvironment.getLocalGraphicsEnvironment() works. Updated.
>>
>
>  http://gwt-code-reviews.appspot.com/822801/diff/1/2#newcode401
>> dev/core/src/com/google/gwt/dev/Precompile.java:401: private static
>>
> Thread
>
>> graphicsInitThread = new GraphicsInitThread();
>> On 2010/08/31 21:13:05, scottb wrote:
>> > Oh yeah.. any particular reason to make this a field?  Should just
>>
> be a local
>
>> > var.  I'd almost argue for making the Thread a local class, too.
>>
>
>  Originally I had a graphicsInitThread.join() in a particular place.  I
>>
> decided I
>
>> didn't need that, so I removed it.
>>
>
>
>
> http://gwt-code-reviews.appspot.com/822801/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)

[Eric Ayers]

Hi Andre, I'm waiting on Ray C or Lex to give the LGTM, but I noticed
this last patch you uploaded left out the editdistance library files.

On Mon, Aug 9, 2010 at 4:48 PM,   wrote:
>
> http://gwt-code-reviews.appspot.com/669801/diff/33001/34006
> File dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java
> (right):
>
> http://gwt-code-reviews.appspot.com/669801/diff/33001/34006#newcode43
> dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java:43:
> Pattern.compile("function |[_a-zA-Z$][.$_a-zA-Z0-9]*=function");
> On 2010/08/06 02:12:25, cromwellian wrote:
>
>> This regex will incorrect match vtable declarations of the form:
>
>> _.name = function() { ... }
>
>> These prototype declarations cannot be re-ordered, so don't let it
>
> match a
>>
>> single '_' symbol.
>
>
> Fixed.
>
> http://gwt-code-reviews.appspot.com/669801/show
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: Adds a class to log performance information in a format (issue707802)

[Eric Ayers]

Hi Scott,

I implemented changes w/r/t your feedback:

http://gwt-code-reviews.appspot.com/719801/show

On Mon, Jul 26, 2010 at 11:33 AM, Scott Blum  wrote:
> On Fri, Jul 23, 2010 at 7:51 AM,  wrote:
>>
>> I agree that going back to static methods could save a little bit of
>> typing, but nevertheless, it is a common pattern for a logging class
>> (j.u.logging, log4j).  Also, if it is keystrokes that bother you, you
>> could save a lot of typing in the invocation with the following pattern:
>>
>> SpeedTracerLogging stl = SpeedTracerLogger.get().
>> stl.start(...);
>>  ...
>> stl.end(...);
>
> That feels kind of cumbersome, since you already have to track the Event
> instance in order to end the right instance.
>
>>
>> - Go back to all static invocations and then have the test grab
>> instances with new() or newInstance and use package protected methods
>> with names that don't collide with start() and stop() like startImpl()
>> stopImpl().  This doesn't feel right to me - it seems like the test is
>> sneaking around under the covers of the API.  It also guarantees a use
>> of multple speedtracer loggers will require a major refactor.
>
>
> I'm actually most in favor of this approach, because the whole idea of speed
> tracer logging entails the idea of a singleton -- at least per thread.  If
> we wanted to use multiple speed trace logs in the future, it seems almost
> certain to me that at least each thread would consistently use a single
> logger.  Because of this idea of thread locality implicit in the API, that
> means we wouldn't need a major refactor.  You could imagine:
> stl = SpeedTracerLogger.newLogger(outputFile);
> stl.setForThread(Thread.currentThread());
> I might also argue that comparing this to j.u.logging or log4j is not the
> right comparison.  Since this is for performance logging, a more apt
> comparison might be to the JProfiler API, which is a static API.
> Scott
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] JSIO vs Overlay Types

[Eric Ayers]

There are reports of success loading the v3 API with the AJAX Loader
(aka Common Loader).  The AjaxLoader Java support is API agnostic.
You should be able to provide the same parameters to
AjaxLoader.loadApi() as described in the forum post below:

http://www.devcomments.com/Loading-v3-with-google-load-at93219.htm

>From a performance perspective, the common loader will be slower than
just including the 

Re: [gwt-contrib] JSIO vs Overlay Types

[Eric Ayers]

Oh, and I meant to say that your contributions are welcome!

On Wed, Jul 7, 2010 at 7:38 AM, Eric Ayers  wrote:
> The author of that library has plans to migrate to overlay types.
> We've got a change branch going on
> http://code.google.com/p/gwt-google-apis under changes/vinays/.
>
> http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3
>
> On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell  wrote:
>> Thanks for the feedback. The reason I'm not using the official Maps API is
>> that I need to use version 3 of the JavaScript API, which isn't supported by
>> the GWT Google APIs project yet. The more developed of the GWT Maps
>> Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for
>> everything, rather than overlay types, so I'm concerned about performance in
>> the case that lots (hundreds or so) of objects are being rendered on the
>> map. At the moment it's looking like I'll contribute some changes there.
>> Thanks again,
>> Daniel
>>
>> On 7 July 2010 03:20, Eric Ayers  wrote:
>>>
>>> Overlay types are the way to go.  The gwt-maps API use jsio because it
>>> predates overlay types.
>>>
>>> On Jul 6, 2010 11:18 AM, "John Tamplin"  wrote:
>>> > On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell 
>>> > wrote:
>>> >
>>> >> I have a question for you about Overlay Types and the JSIO library.
>>> >> I'm working on a GWT interface to the Google Maps JavaScript API, and
>>> >> am wondering about the difference in performance between the two
>>> >> approaches.
>>> >> With JSIO I've been using wrapper objects that each contain an
>>> >> instance of a JavaScriptObject being wrapped, and contain a reference
>>> >> to a singleton instance of the flyweight wrapper. My guess is that the
>>> >> performance would be better if I used Overlay Types instead, but I am
>>> >> just guessing. Do you know (roughly) what the difference in
>>> >> performance is between the two approaches?
>>> >>
>>> >
>>> > First question - why aren't you using the official GWT APIs for Maps
>>> > instead
>>> > of writing your own? http://code.google.com/p/gwt-google-apis/ If there
>>> > is
>>> > something you need that isn't included, why not contribute to that
>>> > rather
>>> > than create your own from scratch?
>>> >
>>> > Overlay types are a bit more efficient and don't require a generator
>>> > running
>>> > which makes DevMode faster, but I don't think there is a lot of
>>> > difference.
>>> >
>>> > --
>>> > 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
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] JSIO vs Overlay Types

[Eric Ayers]

The author of that library has plans to migrate to overlay types.
We've got a change branch going on
http://code.google.com/p/gwt-google-apis under changes/vinays/.

http://code.google.com/p/gwt-google-apis/source/browse/#svn/changes/vinays/gwt-google-maps-v3

On Tue, Jul 6, 2010 at 10:08 PM, Daniel Bell  wrote:
> Thanks for the feedback. The reason I'm not using the official Maps API is
> that I need to use version 3 of the JavaScript API, which isn't supported by
> the GWT Google APIs project yet. The more developed of the GWT Maps
> Libraries (http://code.google.com/p/gwt-google-maps-v3/) uses JSIO for
> everything, rather than overlay types, so I'm concerned about performance in
> the case that lots (hundreds or so) of objects are being rendered on the
> map. At the moment it's looking like I'll contribute some changes there.
> Thanks again,
> Daniel
>
> On 7 July 2010 03:20, Eric Ayers  wrote:
>>
>> Overlay types are the way to go.  The gwt-maps API use jsio because it
>> predates overlay types.
>>
>> On Jul 6, 2010 11:18 AM, "John Tamplin"  wrote:
>> > On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell 
>> > wrote:
>> >
>> >> I have a question for you about Overlay Types and the JSIO library.
>> >> I'm working on a GWT interface to the Google Maps JavaScript API, and
>> >> am wondering about the difference in performance between the two
>> >> approaches.
>> >> With JSIO I've been using wrapper objects that each contain an
>> >> instance of a JavaScriptObject being wrapped, and contain a reference
>> >> to a singleton instance of the flyweight wrapper. My guess is that the
>> >> performance would be better if I used Overlay Types instead, but I am
>> >> just guessing. Do you know (roughly) what the difference in
>> >> performance is between the two approaches?
>> >>
>> >
>> > First question - why aren't you using the official GWT APIs for Maps
>> > instead
>> > of writing your own? http://code.google.com/p/gwt-google-apis/ If there
>> > is
>> > something you need that isn't included, why not contribute to that
>> > rather
>> > than create your own from scratch?
>> >
>> > Overlay types are a bit more efficient and don't require a generator
>> > running
>> > which makes DevMode faster, but I don't think there is a lot of
>> > difference.
>> >
>> > --
>> > 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
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] JSIO vs Overlay Types

[Eric Ayers]

Overlay types are the way to go.  The gwt-maps API use jsio because it
predates overlay types.

On Jul 6, 2010 11:18 AM, "John Tamplin"  wrote:
> On Tue, Jul 6, 2010 at 3:08 AM, Daniel Bell 
wrote:
>
>> I have a question for you about Overlay Types and the JSIO library.
>> I'm working on a GWT interface to the Google Maps JavaScript API, and
>> am wondering about the difference in performance between the two
>> approaches.
>> With JSIO I've been using wrapper objects that each contain an
>> instance of a JavaScriptObject being wrapped, and contain a reference
>> to a singleton instance of the flyweight wrapper. My guess is that the
>> performance would be better if I used Overlay Types instead, but I am
>> just guessing. Do you know (roughly) what the difference in
>> performance is between the two approaches?
>>
>
> First question - why aren't you using the official GWT APIs for Maps
instead
> of writing your own? http://code.google.com/p/gwt-google-apis/ If there is
> something you need that isn't included, why not contribute to that rather
> than create your own from scratch?
>
> Overlay types are a bit more efficient and don't require a generator
running
> which makes DevMode faster, but I don't think there is a lot of
difference.
>
> --
> 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] Re: DockLayoutPanel and Maps

[Eric Ayers]

I just wanted to note that a recent change to trunk should fix problems with
using the layout panel in trunk, and we'll be including it in the next
release.


On Fri, Nov 20, 2009 at 12:37 AM, jd  wrote:

> Just wanted to update this example by noting that with the recent
> changes this workaround no longer works.  This is because the calls to
> layout() are now delayed and scheduled after the current code
> executes.  I had to do this to get the map to layout correctly:
>
>
>root.animate(0, new AnimationCallback()
>{
>public void onLayout(Layer layer, double progress)
>{
>}
>
>public void onAnimationComplete()
>{
>map.checkResizeAndCenter();
>}
>});
>
>
> John
>
>
> On Oct 6, 2:09 am, Joel Webber  wrote:
> > Thanks for letting me know about this. I'll follow up on that thread.
> >
> >
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Google API Library for GWT updated for GWT 2.0

[Eric Ayers]

We are pleased to announce updates to the Google API Libraries for the
Google Web Toolkit  project. The Google API Libraries for GWT project
allows GWT developers to access some of Google's popular JavaScript
APIs. This release includes updates of five libraries: Visualization,
Gears, Gadgets, Search, Language, and AjaxLoader.

Highlights of this release include:
- Libraries updated to GWT 2.0 compatibility
- Samples refactored to use war project structure
- Added Eclipse project files and ant script to all samples
Visualization:
- Added support for all image-charts: ImageAreaChart, ImageBarChart,
ImageLineChart, ImagePieChart, ImageSparklineChart
- Added wrapper for Toolbar
- Updated Visualization API bindings to be up-to-date with published
documentation
Gears:
- Added support for the BlobBuilder class and Blob.getBytes() method
- Added support for the Gears Canvas and Desktop's BlobMetaData object
Gadgets:
- Added support for multiple views and the Views API mapping
Language:
- Added support for new languages (Amharic, Greek, Persian, Russian,
Sanskrit, Serbian, Tigrinya, Yiddish)
AjaxLoader:
- Added support for the google.loader.ClientLocation API
- Added support for custom hostnames for enterprise users

For more detailed information please refer to the release notes.

These updates are now available for download at the Google API
Libraries for GWT project hosted on Google Code.

http://code.google.com/p/gwt-google-apis/

-The Google API Library for GWT Team
-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

Re: [gwt-contrib] Support runAsync with the cross-site linker.

[Eric Ayers]

Something is screwy with riedvelt, and I can't leave a comment on
XSTemplate.js

My comment isn't really about your patch in particular, but the patterns we
are using in the linker templates.  I wish that stanzas of code common to
many linkers, like the calling of __gwtStatsEvent() could be extracted and
put into the template with variable substitution.  For example, adding the
sessionId field to the event works fine here, but there are several linkers
outside of GWT that will need to be updated to get the same fix.

-Eric.

On Mon, Mar 15, 2010 at 6:17 PM,  wrote:

> Reviewers: cromwellian,
>
> Description:
> Support runAsync with the cross-site linker.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/213801
>
> Affected files:
>  M
> dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
>  M dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
>  M dev/core/src/com/google/gwt/core/linker/XSLinker.java
>  M dev/core/src/com/google/gwt/core/linker/XSTemplate.js
>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>  M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
>  A
> dev/core/src/com/google/gwt/dev/jjs/impl/HandleCrossIslandReferences.java
>  M dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java
>  M dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
>  A dev/core/test/com/google/gwt/dev/js/JavaScriptStringTest.java
>  M user/src/com/google/gwt/core/CompilerParameters.gwt.xml
>  M user/src/com/google/gwt/core/Core.gwt.xml
>  A user/src/com/google/gwt/core/XSLinker.gwt.xml
>  user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java
>  A user/src/com/google/gwt/core/client/impl/CrossSiteLoadingStrategy.java
>  M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
>  M user/test/com/google/gwt/core/client/impl/AsyncFragmentLoaderTest.java
>  M user/test/com/google/gwt/core/client/impl/XhrLoadingStrategyTest.java
>  A user/test/com/google/gwt/dev/jjs/CompilerSuiteCrossSite.gwt.xml
>  A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncFailure.gwt.xml
>  A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncMetrics.gwt.xml
>  A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncSuite.java
>  M user/test/com/google/gwt/dev/jjs/RunAsyncFailure.gwt.xml
>  M user/test/com/google/gwt/dev/jjs/RunAsyncMetricsIntegrationTest.gwt.xml
>  user/test/com/google/gwt/dev/jjs/public/empty-gwt-stats.js
>  A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncFailureTest.java
>  A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncMetricsTest.java
>  A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncTest.java
>  M user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java
>  A
> user/test/com/google/gwt/user/client/runasync/CrossSiteLoadingStrategyForRunAsyncFailureTest.java
>  D
> user/test/com/google/gwt/user/server/runasync/RunAsyncFailureIFrameLinker.java
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA
Sign up now for Google I/O 2010: May 19-20, http://code.google.com/io

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

[gwt-contrib] Re: Can't build trunk

[Eric Ayers]

In msg 3 above, It looks like your generated files are going in:

c:\DOCUME~1\tfga\CONFIG~1\Temp
The 'addNorth(Widget, int)'  is the correct signature.  That other signature
(Shortcuts, int, int) being reported from the BinderImpl file is stale.

The directory .../Temp isn't going to get cleared out by 'ant clean' so
maybe you need to remove files from there manually (maybe a red herring,
this could just be a diagnostic from UiBinder).   Could be there is a
permissions problem and the old generated files aren't getting overwritten?
Maybe a stale version somewhere else on your classpath?

Search around for files with the name *Mail_BinderImpl*.java.  Those are
transient and can be deleted.


On Tue, Oct 6, 2009 at 2:35 AM, tfga  wrote:

>
> Thank you for you very detailed message, Freeland.
>
> Regarding [4] ("LONG compiler errors in Browser"):
>
> I only get those when I run ant from Eclipse. When I run it from the
> command line, I get a different set of errors (see message 3). What
> about these?
>
> I was using the ant that came with Eclipse; I tried using the
> "official", stand-alone one from apache and got the same result.
>
> On Oct 5, 12:29 am, Freeland Abbott  wrote:
> > Going back to some of your original questions:
> >
> >1. The default behavior is to build cross-platform.  If you only care
> >about the platform you're on, there's a *-one family of targets, and
> to
> >leave things like samples and tools behind, a *-dev family.  Try ant
> >dist-dev to make a one-platform distribution without samples or tools,
> >although you might find you actually *want* especially the tools.  But
> >most of us don't iterate on them as often, which is why they're left
> out
> >from those rules.  Or, use dist-one if you do want them.
> >2. As a hack to your svn issue, if you just pre-define the ant
> properties
> >it's supposed to set from svn info and svnversion, the SvnInfoTask
> will skip
> >over the work (and thus skip not finding svn).  That'd look something
> like:
> >   - ant -dgwt.svnrev=tr...@5678 dist-one
> >3. There's no reason cygwin shouldn't work for you, but you don't need
> it
> >either.  There's a perfectly good native Windows svn at
> >http://www.collab.net/downloads/subversion/.  If you're already using
> >cygwin, e.g. for git, of course, then as noted it *should* have worked
> >fine... we need[*] a svnversion and svn executable on the command
> line, but
> >we don't care which port or environment.
> >4. Your LONG compiler errors in Browser are screwy; as Eric says, we
> >don't see them... and we're desparately trying to retire our swt
> dependency
> >anyway.  But at a guess, I suspect you've got different Eclipse jars
> on your
> >classpath than you "should," especially if you're building from some
> >Eclipse.  I haven't done an exhaustive check in all the jars, but in
> >$GWT_TOOLS/lib/eclipse/org.eclipse.swt.gtk-linux-3.2.1.jar I see only
> the
> >...internal.gtk.LONG class, *not* the internal.LONG variant.  I
> suspect
> >you're getting a more modern Eclipse jar, and that they must have
> refactored
> >it up or somesuch.  Ant -v will report the classpath; I suspect you'll
> find
> >a stray jar from outside the GWT and GWT_TOOLS hierarchies which is
> messing
> >you up.  (My own ant -v is below, but you shouldn't need to do the 1:1
> >matching; just look for something from the wrong directories!)
> >   - [gwt.javac] 'C:\Documents and Settings\fabbott\My
> >   Documents\GWTs\collections\build\out\dev\linux\bin;C:\Documents and
> >   Settings\fabbott\My
> >
> Documents\GWTs\tools\lib\eclipse\org.eclipse.swt.gtk-linux-3.2.1.jar;C:\Documents
> >   and Settings\fabbott\My
> >   Documents\GWTs\collections\build\out\dev\core\bin;C:\Documents and
> >   Settings\fabbott\My
> >
> Documents\GWTs\collections\build\out\dev\core\alldeps.jar;C:\Program
> > Files\apache-ant-1.7.1\lib\ant-launcher.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-antlr.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-apache-bcel.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-apache-bsf.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-apache-log4j.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-apache-oro.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-apache-regexp.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-apache-resolver.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-commons-logging.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-commons-net.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-contrib-1.0b3.jar;C:\Program
> > Files\apache-ant-1.7.1\lib\ant-jai.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-javamail.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-jdepend.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-jmf.jar;C:\Program
> >   Files\apache-ant-1.7.1\lib\ant-jsc

[gwt-contrib] Re: Can't build trunk

[Eric Ayers]

at com.google.gwt.dev.CompileTaskRunner.doRun
> > > (CompileTaskRunner.java:89)
> > > [java] at
> > > com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger
> > > (CompileTaskRunner.java:83)
> > > [java] at com.google.gwt.dev.Compiler.main(Compiler.java:152)
> > > [java] Caused by:
> > > com.google.gwt.core.ext.UnableToCompleteException: (see previous log
> > > entries)
> > > [java] at
> > > com.google.gwt.dev.javac.StandardGeneratorContext.finish
> > > (StandardGeneratorContext.java:391)
> > > [java] at
> >
> > >
> com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds
> > > (WebModeCompilerFrontEnd.java:141)
> > > [java] ... 17 more
> > > [java]
> > > [java] [ERROR] Unexpected
> > > [java] java.lang.RuntimeException: Unable to commit generated
> > > files
> > > [java] at
> >
> > >
> com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds
> > > (WebModeCompilerFrontEnd.java:143)
> > > [java] at com.google.gwt.dev.jdt.AbstractCompiler
> > > $CompilerImpl.process(AbstractCompiler.java:161)
> > > [java] at org.eclipse.jdt.internal.compiler.Compiler.compile
> > > (Compiler.java:444)
> > > [java] at com.google.gwt.dev.jdt.AbstractCompiler
> > > $CompilerImpl.compile(AbstractCompiler.java:84)
> > > [java] at com.google.gwt.dev.jdt.AbstractCompiler
> > > $CompilerImpl.compile(AbstractCompiler.java:196)
> > > [java] at com.google.gwt.dev.jdt.AbstractCompiler
> > > $CompilerImpl.access$300(AbstractCompiler.java:70)
> > > [java] at com.google.gwt.dev.jdt.AbstractCompiler.compile
> > > (AbstractCompiler.java:481)
> > > [java] at
> > >
> com.google.gwt.dev.jdt.BasicWebModeCompiler.getCompilationUnitDeclarations
> > > (BasicWebModeCompiler.java:113)
> > > [java] at
> >
> > >
> com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclarations
> > > (WebModeCompilerFrontEnd.java:49)
> > > [java] at
> > > com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile
> > > (JavaToJavaScriptCompiler.java:415)
> > > [java] at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile
> > > (JavaScriptCompiler.java:32)
> > > [java] at com.google.gwt.dev.Precompile.precompile
> > > (Precompile.java:507)
> > > [java] at com.google.gwt.dev.Precompile.precompile
> > > (Precompile.java:408)
> > > [java] at com.google.gwt.dev.Compiler.run(Compiler.java:194)
> > > [java] at com.google.gwt.dev.Compiler$1.run(Compiler.java:
> > > 145)
> > > [java] at com.google.gwt.dev.CompileTaskRunner.doRun
> > > (CompileTaskRunner.java:89)
> > > [java] at
> > > com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger
> > > (CompileTaskRunner.java:83)
> > > [java] at com.google.gwt.dev.Compiler.main(Compiler.java:152)
> > > [java] Caused by:
> > > com.google.gwt.core.ext.UnableToCompleteException: (see previous log
> > > entries)
> > > [java] at
> > > com.google.gwt.dev.javac.StandardGeneratorContext.finish
> > > (StandardGeneratorContext.java:391)
> > > [java] at
> >
> > >
> com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds
> > > (WebModeCompilerFrontEnd.java:141)
> > > [java] ... 17 more
> >
> > > On Oct 4, 1:39 pm, Eric Ayers  wrote:
> > > > You need to run your build under the windows command shell.  That
> > > probably
> > > > means you need to get the native windows svn executable too.
> >
> > > > On Sun, Oct 4, 2009 at 1:23 AM, tfga  wrote:
> >
> > > > > Hi,
> >
> > > > > I'm trying to build trunk on Windows. I followed the instructions
> from
> >
> > > > >
> http://code.google.com/webtoolkit/makinggwtbetter.html#compiling
> >
> > > > > The 1st error I got was:
> >
> > > > >gwt\common.ant.xml:276: Unable to launch command: svn info
> >
> > > > > So I installed the Cygwin port of svn and added it's path to $PATH.
> > > > > Now I get this:
> >
> > > > > linux:
> > > > > compile:
> > > > >[mkdir] Created dir:

[gwt-contrib] Re: Can't build trunk

[Eric Ayers]

You need to run your build under the windows command shell.  That probably
means you need to get the native windows svn executable too.

On Sun, Oct 4, 2009 at 1:23 AM, tfga  wrote:

>
> Hi,
>
> I'm trying to build trunk on Windows. I followed the instructions from
>
>http://code.google.com/webtoolkit/makinggwtbetter.html#compiling
>
> The 1st error I got was:
>
>gwt\common.ant.xml:276: Unable to launch command: svn info
>
> So I installed the Cygwin port of svn and added it's path to $PATH.
> Now I get this:
>
> linux:
> compile:
>[mkdir] Created dir: C:\Documents and Settings\tfga\workspace\gwt
> \build\out\dev\linux\bin
> [gwt.javac] Compiling 11 source files to C:\Documents and Settings\tfga
> \workspace\gwt\build\out\dev\linux\bin
> [gwt.javac] C:\Documents and Settings\tfga\workspace\gwt\dev\linux\src
> \org\eclipse\swt\browser\Browser.java:620: reference to LONG is
> ambiguous, both class org.eclipse.swt.internal.gtk.LONG in
> org.eclipse.swt.internal.gtk and class org.eclipse.swt.internal.LONG
> in org.eclipse.swt.internal match
> [gwt.javac] getDisplay().setData(ADD_WIDGET_KEY, new
> Object[] {new
> LONG(mozillaHandle), this});
> [gwt.javac]
> ^
> [gwt.javac] C:\Documents and Settings\tfga\workspace\gwt\dev\linux\src
> \org\eclipse\swt\browser\Browser.java:1340: reference to LONG is
> ambiguous, both class org.eclipse.swt.internal.gtk.LONG in
> org.eclipse.swt.internal.gtk and class org.eclipse.swt.internal.LONG
> in org.eclipse.swt.internal match
> [gwt.javac] display.setData(ADD_WIDGET_KEY, new Object[] {new LONG
> (mozillaHandle), null});
> [gwt.javac]   ^
> [gwt.javac] 2 errors
>
> Why is it running the "linux" target if I'm using Windows? Do I have
> to install the windows native port of svn? And what about these
> compilation errors?
>
> Regards,
> Thiago
>
> >
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: GWT Trunk build broken?

[Eric Ayers]

Hi Papick,
Right after you posted your message last night, I updated my svn GWT repo
and tools, then did a sucessful build including samples on Windows Vista.

On Fri, Oct 2, 2009 at 3:08 AM, P.G.Taboada wrote:

>
> Oh, maybe my thread title is wrong. GWT is building, I can't build the
> samples. So if I try to do a full build it fails. The dev only build
> is working perfectly.
>
> brgds,
>
> Papick
>
> On 2 Okt., 04:06, John LaBanca  wrote:
> > Try doing an "ant clean" first.
> > Thanks,
> > John LaBanca
> > jlaba...@google.com
> >
> > On Thu, Oct 1, 2009 at 6:52 PM, P.G.Taboada  >wrote:
> >
> >
> >
> >
> >
> > > Hmm, it is up-to-date...
> >
> > >  [java] Compiling module com.google.gwt.sample.mail.Mail
> > > [java]Scanning for additional dependencies: file:/java/gwt/
> > > samples/mail/src/com/google/gwt/sample/mail/client/Mail.java
> > > [java]   Adding '2' new generated units
> > > [java]  Validating newly compiled units
> > > [java] Removing units with errors
> > > [java][ERROR] Errors in 'transient source for
> > > com.google.gwt.sample.mail.client.Mail_BinderImpl'
> > > [java]   [ERROR] Line 20: The method addNorth
> > > (Widget, double) in the type DockLayoutPanel is not applicable for the
> > > arguments (TopPanel, int, int)
> > > [java]   [ERROR] Line 21: The method addWest
> > > (Widget, double) in the type DockLayoutPanel is not applicable for the
> > > arguments (Shortcuts, int, int)
> > > [java]   [ERROR] Line 22: The method addNorth
> > > (Widget, double) in the type DockLayoutPanel is not applicable for the
> > > arguments (MailList, int, int)
> >
> > > The new sample is using the UIBinder and the new DockLayoutPanel. No
> > > java compile error (obviously), but GWT compilation fails.
> >
> > > brgds,
> >
> > > Papick
> >
> > > ps: thanks for the very interesting talk on the google io  :-)
> >
> > > On 2 Okt., 00:47, Ray Ryan  wrote:
> > > > Do you need to update your tools dir?
> >
> > > > On Thu, Oct 1, 2009 at 3:46 PM, P.G.Taboada <
> pgtabo...@googlemail.com>
> > > wrote:
> >
> > > > > Since the new Mail Sample was commited I can't do a full build.
> >
> > > > > Am I missing something?
> >
> > > > > brgds,
> >
> > > > > Papick G. Taboada
> >
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: DockLayoutPanel and Maps

[Eric Ayers]

I'll look into implementing RequiresResize, I created an issue:

  http://code.google.com/p/gwt-google-apis/issues/detail?id=308

The problem with the map not refreshing properly and having to call
checkResizeAndCenter() immediately after creating it has been around a
long time and there is a FAQ up for it.  I hope this works. Having a
way to automatically compensate would take some pain out of creating
maps applications!


On Sep 29, 12:29 am, Joel Webber  wrote:
> Having MapWidget implement RequiresResize would seem to be the right
> approach. I can see how the maps code would need to be informed when it is
> resized, as it needs to create the appropriate number of tiles on each axis.
> Does this sound reasonable to you, Eric?
>
>
>
> On Mon, Sep 28, 2009 at 9:18 PM, jd  wrote:
>
> > Yeah sorry I was not sure if this was more of a development topic or
> > typical user problem.
>
> > I tried your suggestion of map.checkResizeAndCenter() and it works
> > perfectly.  It also seems a better solution than my original
> > SimplePanel place holder.
>
> > It seems that the Google map object initializes its size as soon as it
> > is added to the document.  Perhaps MapWidget could also implement
> > RequiresResize?
>
> > So now a working example is:
>
> >        public void onModuleLoad()
> >        {
> >                DockLayoutPanel p = new DockLayoutPanel(Unit.PX);
> >                p.addNorth(new HTML("north"), 100);
> >                p.addSouth(new HTML("south"), 100);
> >                p.addEast(new HTML("east"), 100);
> >                p.addWest(new HTML("west"), 100);
>
> >                MapWidget map = new MapWidget(LatLng.newInstance(-41.1,
> > 174.8), 5);
> >                p.add(map);
>
> >                p.layout();
>
> >                RootLayoutPanel rp = RootLayoutPanel.get();
> >                rp.add(p);
>
> >                 rp.layout();
>
> >                map.checkResizeAndCenter();
> >        }
>
> > John
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: DockLayoutPanel and Maps

[Eric Ayers]

Also, this discussion would be more appropriate for the gwt-google-apis
group. GWT contributors is for the developers of the Google Web Toolkit core
product.

On Mon, Sep 28, 2009 at 10:13 AM, Eric Ayers  wrote:

> Have you tried the method map.checkResizeAndCenter()?
>
>
> On Mon, Sep 28, 2009 at 9:42 AM, jd  wrote:
>
>>
>> Actually I think that was a red herring - setting the parentElem style
>> just forced a re-render and changing the map size had the same effect.
>>
>> I think the problem is due to the map trying to initialize itself
>> before layout() is called.  If I add a holder panel like this:
>>
>>SimplePanel holder = new SimplePanel();
>>p.add(holder);
>>
>> and then add the map after layout() like:
>>
>>p.layout();
>>
>>MapWidget map = new MapWidget(LatLng.newInstance(50, 50),
>> 8);
>>map.setWidth("100%");
>>map.setHeight("100%");
>> holder.add(map);
>>
>> it works.
>>
>> I have one question about threading in the browser - I have used YUI
>> LayoutManager which is very similar to DockLayoutPanel.
>>
>> http://developer.yahoo.com/yui/examples/layout/nested_layout.html
>>
>> If you want to nest layouts or use a map inside a layout you need to
>> register a listener for an onrender event. When I asked why, Dave
>> Glass said that although the JS is single threaded, the DOM elements
>> will not be created by serially so you must wait until the event fires
>> before you can safely layout nested items that depend on the parent
>> layout.
>>
>> Could this be a problem here also?
>>
>> Thanks,
>>
>> John
>>
>> On Sep 28, 7:06 pm, jd  wrote:
>> > I have found the issue and am not sure how to fix it using the current
>> > API.  After setting 100% height and width on both the DockLayoutPanel
>> > and RootLayoutPanel the map still reported a span of 0 and did not
>> > render correctly.  In Safari's Inspector I could see that the only
>> > element without 100% height and width was the generated "layout
>> > parent" element but after changing this in using the inspector it
>> > worked.
>> >
>> > So I think I need to be able to access the Layout.parentElem to modify
>> > its style.
>> >
>> >>
>>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>



-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: DockLayoutPanel and Maps

[Eric Ayers]

Have you tried the method map.checkResizeAndCenter()?

On Mon, Sep 28, 2009 at 9:42 AM, jd  wrote:

>
> Actually I think that was a red herring - setting the parentElem style
> just forced a re-render and changing the map size had the same effect.
>
> I think the problem is due to the map trying to initialize itself
> before layout() is called.  If I add a holder panel like this:
>
>SimplePanel holder = new SimplePanel();
>p.add(holder);
>
> and then add the map after layout() like:
>
>p.layout();
>
>MapWidget map = new MapWidget(LatLng.newInstance(50, 50),
> 8);
>map.setWidth("100%");
>map.setHeight("100%");
> holder.add(map);
>
> it works.
>
> I have one question about threading in the browser - I have used YUI
> LayoutManager which is very similar to DockLayoutPanel.
>
> http://developer.yahoo.com/yui/examples/layout/nested_layout.html
>
> If you want to nest layouts or use a map inside a layout you need to
> register a listener for an onrender event. When I asked why, Dave
> Glass said that although the JS is single threaded, the DOM elements
> will not be created by serially so you must wait until the event fires
> before you can safely layout nested items that depend on the parent
> layout.
>
> Could this be a problem here also?
>
> Thanks,
>
> John
>
> On Sep 28, 7:06 pm, jd  wrote:
> > I have found the issue and am not sure how to fix it using the current
> > API.  After setting 100% height and width on both the DockLayoutPanel
> > and RootLayoutPanel the map still reported a span of 0 and did not
> > render correctly.  In Safari's Inspector I could see that the only
> > element without 100% height and width was the generated "layout
> > parent" element but after changing this in using the inspector it
> > worked.
> >
> > So I think I need to be able to access the Layout.parentElem to modify
> > its style.
> >
> >
>


-- 
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

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

[gwt-contrib] Re: New API proposal: BatchedCommand

[Eric Ayers]

The most important issue in my mind is that it isn't always
appreciated to take a minor feature change that very few developers
will ever use and use it as an excuse to mix up the existing API.
Take, in contrast, the xxxListener to xxxHandler change.  There was a
lot of pain in that one, but it resulted in significant benefits for a
majority of developers.

On Sun, Sep 6, 2009 at 9:18 PM,
brett.wooldridge wrote:
>
> As a long time Java programmer (since v0.9!), I'd just like to throw
> in that I don't see any particular practical benefit to leveraging
> Runnable or Callable.  Sure, they are just interfaces, and you
> could re-use them.  But beyond that, especially with respect to
> Callable, almost nothing execution related from
> java.util.concurrent is applicable to thread-less JavaScript.
> Borrowing one interface from java.util.concurrent because it has the
> same signature, yet not implementing any of the java.util.concurrent
> features is more confusing to a Java programmer coming to GWT.
>
> So while I appreciate Eric's point of view, I don't share it.  Jason's
> suggestion of re-using Executor and ExecutorService is also likely not
> practicable in GWT because of ExecutorService's blocking methods
> (invokeAll(), awaitTermination).
>
> Ray's last suggestion gets my vote.  It looks substantially like the
> existing pattern and does not inject unnecessary new controller or
> scheduler classes.  I'm of the "simplest thing that can possibly work"
> school of thought as of late.
>
> Brett Wooldridge
>
> >
>



-- 
Google Code Jam 2009
http://code.google.com/codejam

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

[gwt-contrib] Re: New API proposal: BatchedCommand

[Eric Ayers]

Just to flush out my dissention a little more, I don't see what
re-architecting it is going to do for the user experience, and I know
it is going to cause at least as much pain as benefit for the
developer experience.

I love writing shiny new APIs too, but going with the minimal screwing
with the API approach, you could just make a new
DeferredCommand.addBatchedCommand(Command cmd) and get this new
functionality and be done with it.

1) The new  dispatch-my-command-before-the-event-loop may be important
for the Css injection case, but I haven't seen any suggestion that its
going to be used for anything other than that - an important, but very
infrequently used feature.

2) If you want to make a new testable deferred/incremental command
class, fine, you can do that, but I don't think it requires yet
another round of deprecating deferred command stuff - you can write it
on top.  Again, most developers aren't going to be mocking out and
overriding timers for their test cases, yet the implication is that
all developers need this (they don't)

3) Look at what will happen to the API after the suggested round of
deprecations.  There will be more ways NOT to do something than the
recommended way to actually get work done.  And pedantic arguments
aside, it will be yet another collection of custom class names where
we could have used 'Runnable' and 'Callable' that java developers are
already familiar with.

All I'm asking is for us to think about, "Is a shiny new API it really
worth the ugliness for developers?  Do users get something significant
in return for developer pain?"

Signed,
A developer

On Fri, Sep 4, 2009 at 11:36 PM, Eric Ayers wrote:
> -1 for renaming and deprecating the DeferredCommand, etc calls unless
> there is really something significant other than the name change.   As
> a maintainer, I get sick of APIs moving around underneath my code and
> having someone else tell me its broken.  Furthermore, you'll make
> obsolete every good tutorial and blog post already written that tells
> you how to do fun stuff in GWT with these tools.
>
> On Fri, Sep 4, 2009 at 11:00 PM, Miroslav
> Pokorny wrote:
>>
>> Slightly off topic more of a design comment.
>>
>> For me Job would be a better name than Command. Command reminds me of
>> the command pattern while job is always a background task that might
>> execute sooner or later.
>>
>> It also seems like there are lots of "duplicate" add methods for lack
>> of a better of description, whereby each type of Command has it's own.
>> What about a central manager type class with a single add( Job,
>> JobType) where JobType is Incremental, Timed, etc.
>>
>> For the Timed version there would be factory to pass the when or how
>> often etc, or as in the previous email from Bruce AsapJob.
>>
>> I can also see a benefit of allowing developers to change the command
>> (job) type by changing the JobType parameter which seems simpler /
>> more flexible than the hard coded static adds and super type.
>>
>> Just an idea...
>>
>> On 05/09/2009, at 4:35 AM, Ray Ryan  wrote:
>>
>>> I like the Finally name.
>>>
>>> Since you have a single Command object used by Incremental along
>>> with everyone else, you're implying interface
>>>
>>> Command {
>>>   /**
>>>    * @return whether this command should be run again.
>>>    * Checked only by {...@link IncrementalCommands} and {...@link
>>> TimedCommands}
>>>    */
>>>   boolean execute();
>>>  }
>>>
>>> That's a bit redundant with the TimerController--would it even be
>>> honored by TimedCommands?
>>>
>>> Let me propose this (actually, I think steal it from Brian Brian
>>> Slesinsky) , to allow every command to reschedule itself or not.
>>>
>>> rjrjr
>>>
>>> interface Command {
>>>   /**
>>>    * @param dispatcher To allow this command to requeue
>>>    *    itself, or add other commands. Presto, it's
>>>    *    all three of timed, incremental and one off
>>>    */
>>>   void execute(CommandDispatcher dispatcher);
>>> }
>>>
>>> interface CommandDispatcher {
>>>   enum When {
>>>     FINALLY,
>>>     ASAP
>>>   }
>>>
>>>   public static CommandDispatcher get();
>>>
>>>   public void add(Command c);
>>>
>>>   public void add(Command c, When w);
>>>
>>>   public void addDeferred(Command c, int millis);
>>> }
>>>
>>> That's the whole thing. For convenience, w

[gwt-contrib] Re: New API proposal: BatchedCommand

[Eric Ayers]

-1 for renaming and deprecating the DeferredCommand, etc calls unless
there is really something significant other than the name change.   As
a maintainer, I get sick of APIs moving around underneath my code and
having someone else tell me its broken.  Furthermore, you'll make
obsolete every good tutorial and blog post already written that tells
you how to do fun stuff in GWT with these tools.

On Fri, Sep 4, 2009 at 11:00 PM, Miroslav
Pokorny wrote:
>
> Slightly off topic more of a design comment.
>
> For me Job would be a better name than Command. Command reminds me of
> the command pattern while job is always a background task that might
> execute sooner or later.
>
> It also seems like there are lots of "duplicate" add methods for lack
> of a better of description, whereby each type of Command has it's own.
> What about a central manager type class with a single add( Job,
> JobType) where JobType is Incremental, Timed, etc.
>
> For the Timed version there would be factory to pass the when or how
> often etc, or as in the previous email from Bruce AsapJob.
>
> I can also see a benefit of allowing developers to change the command
> (job) type by changing the JobType parameter which seems simpler /
> more flexible than the hard coded static adds and super type.
>
> Just an idea...
>
> On 05/09/2009, at 4:35 AM, Ray Ryan  wrote:
>
>> I like the Finally name.
>>
>> Since you have a single Command object used by Incremental along
>> with everyone else, you're implying interface
>>
>> Command {
>>   /**
>>    * @return whether this command should be run again.
>>    * Checked only by {...@link IncrementalCommands} and {...@link
>> TimedCommands}
>>    */
>>   boolean execute();
>>  }
>>
>> That's a bit redundant with the TimerController--would it even be
>> honored by TimedCommands?
>>
>> Let me propose this (actually, I think steal it from Brian Brian
>> Slesinsky) , to allow every command to reschedule itself or not.
>>
>> rjrjr
>>
>> interface Command {
>>   /**
>>    * @param dispatcher To allow this command to requeue
>>    *    itself, or add other commands. Presto, it's
>>    *    all three of timed, incremental and one off
>>    */
>>   void execute(CommandDispatcher dispatcher);
>> }
>>
>> interface CommandDispatcher {
>>   enum When {
>>     FINALLY,
>>     ASAP
>>   }
>>
>>   public static CommandDispatcher get();
>>
>>   public void add(Command c);
>>
>>   public void add(Command c, When w);
>>
>>   public void addDeferred(Command c, int millis);
>> }
>>
>> That's the whole thing. For convenience, we could also offer stuff
>> like the following. Perhaps
>> // better to see what evolves
>>
>> abstract class IncrementalCommand implements Command {
>>   public void execute(CommandDispatcher dispatcher) {
>>     if (doExecute()) {
>>       dispatcher.add(this);
>>     }
>>   }
>>
>>   /** @return true to keep going */
>>   abstract boolean doExecute();
>> }
>>
>> and
>>
>> public class TimedCommand implements Command {
>>   private final wrappedCommand;
>>   private final interval millis;
>>   private boolean stopped;
>>
>>   public TimedCommand(int millis, Command wrappedCommand) {
>>     this.wrappedCommand = wrappedCommand;
>>     this.millis = millis;
>>   }
>>
>>   public void stop() {
>>     stopped = true;
>>   }
>>
>>   public void execute(CommandDispatcher dispatcher) {
>>     if (!stopped) {
>>       wrappedCommand.execute(dispatcher);
>>       dispatcher.add(this, millis);
>>     }
>>   }
>> }
>>
>>
>> >
>
> >
>



-- 
Google Code Jam 2009
http://code.google.com/codejam

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

[gwt-contrib] Re: Regarding Transliteration - Incorrect output

[Eric Ayers]

Hi Jitesh,

Have you looked at the Google Language API for GWT?  It wraps up the
Google JavaScript translation and transliteration APIs and makes it
eaiser to use with GWT.  See:

http://code.google.com/p/gwt-google-apis

Thereis be sample code and documentation you can take a look at.  If
you need help with using that API, please post to the GWT-Google-Apis
google group.

Regards,
-Eric.

On Tue, Sep 1, 2009 at 3:29 AM, jitesh dundas wrote:
>
> Hi Friends,
>
>
> I need your help.
>
> I have written this code to get the transliteration in Java. BUt it
> gives me incorrect output for > 4 words...
>
>
> <%@ page language = "java" %>
> <%@ page import = "java.sql.*" %>
> <%@ page import = "java.util.*" %>
> <%@ page import = "java.io.*" %>
> <%@ page import="java.lang.*" %>
> <%@ page import="java.net.*" %>
> <%@ page import="java.nio.*" %>
>
> <%@ page contentType="text/html; charset=utf-8" pageEncoding="UTF-8"
> %>
>
> <%
>
>  try
>  {
>     out.println("Hello");
>
>     Properties systemSettings = System.getProperties();
>     systemSettings.put("*", "");
>     systemSettings.put("http.proxyPort", "");
>         systemSettings.put("sun.net.client.defaultConnectTimeout", "1");
>         systemSettings.put("sun.net.client.defaultReadTimeout",
> "1");
>         out.println("Properties Set");
>         Authenticator.setDefault(new Authenticator()
>         {
>                                protected PasswordAuthentication
> getPasswordAuthentication()
>                                {
>                                    return new PasswordAuthentication
> ("*", "".toCharArray()); // specify ur user name password of iitb
> login
>                                }
>         });
>        System.setProperties(systemSettings);
>        out.println("After Authentication & Properties Settings");
>
>        //the input to google api
>        //String str = "tlqt=1&langpair=en|hi&text=sdffdgdf sdfsd qwewq
> adfasw qeqewq asdfqw3ww adas adasdasd adasds &&tl_app=1";
>        //http://www.google.com/transliterate/indic?tlqt=1&langpair=en|
> hi&text=sdfsd%20qwewq%20adfasw%20qeqewq%20asdfqw3ww%20adas
> %20adasdasd&&tl_app=1
>        String str = "tlqt=1&langpair=en|hi&text=sdfsd%20qwewq%20adfasw
> %20qeqewq%20asdfqw3ww%20adas%20adasdasd&&tl_app=1";
>
>        String stringToReverse = "";
>        try
>        {
>                stringToReverse = "http://www.google.com/transliterate/indic?"; 
> +
> URLEncoder.encode(str, "UTF-8");
>        }
>        catch(Exception ex)
>        {}
>
>        out.println(stringToReverse);
>
>        URL url = new URL(stringToReverse);
>        URLConnection connection = url.openConnection();
>        //connection.setDoOutput(false);
>
>        BufferedReader in = new BufferedReader( new InputStreamReader
> ( connection.getInputStream()));
>
>        String decodedString;
>        String tempstr = "";
>        out.println("Decoded String Like->"+ URLDecoder.decode("\u0905\u092E
> \u093F\u0924\u093E\u092C\u091A\u0928","UTF-8") + "") ;
>
>        while ((decodedString = in.readLine()) != null)
>        {
>                tempstr = tempstr + decodedString;
>        }
>        out.println(tempstr);
>
>
>        //code ends.
>        String[] strval = tempstr.split("ew");
>        out.println("Length="+strval.length + "");
>
>        //loop through all the values of the string array.
>        for ( int j=0; j < strval.length; j++ )
>        {
>                String val = strval[j];
>
>                out.println("j=" + j + " & Array Val="+val+ "");
>
>                //next check for ":" sign.
>                if ( val.contains(":") )
>                {
>                  out.println(" It has colon");
>                  //check for first comma in this string.
>                  /*int commapos = val.indexOf(",");
>                     out.println(" Pos of comma is "+ commapos + "");
>                  */
>                  String[] strval2 = val.split(",");
>                  String strval3 = "";
>
>              for (int k=0; k < strval2.length; k++ )
>                        {
>                                out.println("k=" + k + " & Comma Array 
> Val="+ strval2[k] +
> "");
>                                //now replace all " and ":" characters.
>
>                                strval3 = strval2[k];
>                                strval3 = strval3.replaceAll("\"","");
>                                strval3 = strval3.replaceAll(":","");
>
>                                out.println("k=" + k + " & New Comma Array 
> Val="+ strval3 +
> "");
>
>                                out.println("Final value of 
> ew="+strval3);//value of ew
> obtained.
>                        }
>                  //code to get values of
>
>
>                  //next get the substring till first ","
>                }
>        }
>
>
>
>        in.close();
> }
> catch(Exception ex)
> {
>  out.println("Exception->"+ex);
>  PrintWriter pw = response.getWriter()

[gwt-contrib] Re: lightweight events for runAsync in draft mode

[Eric Ayers]

On Fri, Aug 7, 2009 at 11:11 AM, Lex Spoon wrote:
> Okay, I recently wrote a test for runAsync lightweight metrics, but --
> oops -- that test fails in draft mode.  In draft mode, no code
> splitting happens, so no events are generated, and so the test
> rightfully complains.  So, what should be done?
>
> I'm thinking to have draft mode generate some different events, and am
> wondering what people think.
>
> My first thought was to leave the events alone, because after all
> there are no actual downloads in draft mode.  However, there are
> several problems with that approach:
>
> 1. The test really should fail if no events are generated in regular
> compilation modes.  So it wouldn't be good to simply change the test
> to tolerate a complete lack of events.
>
> 2. It's awkward to have a test that only runs in certain compilation
> modes.  The list of exceptions would have to live somewhere, and where
> would that be?
>
> 3. It's also awkward to have the test disable itself, because it needs
> to query some API to figure out whether code splitting really
> happened.  What API would that be?  "Am I in draft compile mode"?
> "Did code splitting happen for real"?  I can't think of an API that
> wouldn't be fragile.

I don't think its terribly yucky to add a

GWT.isRunAsync() (pick your favorite name) method the way we have
GWT.isScript() and a host of other little similar static methods in
the GWT class.


>  It's fully intended that the compiler is
> flexible in the kinds of optimization it does, and it should be
> possible for the code splitter to have its own decision making as
> well.  It would be better if this test were robust against such
> changes.  Further, the API would be hard to keep private to the test;
> application code might start using it, thus locking GWT into
> supporting it for some amount of time.
>
> So, instead of enabling the test selectively, how about generating a
> different event when in draft compile mode?  The current event
> sequence for calling a single runAsync is as follows:
>
>  - leftoversDownload -- download of the leftovers fragment
>  - download1  --- download of code for split point 1
>  - runCallbacks1 -- run the callbacks for split point 1
>
>
> In draft compile mode, maybe the events could be like this:
>
>  - codeAlreadyLoaded1 -- code for split point 1 requested but already present
>  - runCallbacks1 -- run the callbacks for split point 1
>
>
> I could then update the test to tolerate either sequence.
>
>
> Thoughts?
>
> Lex
>



-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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

[gwt-contrib] Re: Add Gears' Blob::getBytes

[Eric Ayers]

(Reitveld is really on the fritz tonight and I can't submit my comments there)

Do you think this would make a good addition to the ArrayHelper class?

http://code.google.com/p/gwt-google-apis/source/browse/trunk/ajaxloader/ajaxloader/src/com/google/gwt/ajaxloader/client/ArrayHelper.java

On Sun, Jul 5, 2009 at 11:35 AM,  wrote:
>
> Reviewers: t.broyer,
>
> Description:
> This patch adds getBytes() method to Blob (Gears 0.5.21.0)
>
> Please review this at http://galgwt-reviews.appspot.com/41604
>
> Affected files:
>   gears/src/com/google/gwt/gears/client/blob/Blob.java
>
>
> Index: gears/src/com/google/gwt/gears/client/blob/Blob.java
> ===
> --- gears/src/com/google/gwt/gears/client/blob/Blob.java        (revision 
> 1519)
> +++ gears/src/com/google/gwt/gears/client/blob/Blob.java        (working copy)
> @@ -16,6 +16,7 @@
>  package com.google.gwt.gears.client.blob;
>
>  import com.google.gwt.core.client.JavaScriptObject;
> +import com.google.gwt.core.client.JsArrayInteger;
>
>  /**
>   * A Blob is a reference to an opaque block of binary data.
> @@ -57,6 +58,18 @@
>    protected Blob() {
>      // required for overlay types
>    }
> +
> +  public byte[] getBytes() {
> +    return toJavaArray(nativeGetBytes());
> +  }
> +
> +  public byte[] getBytes(int offset) {
> +    return toJavaArray(nativeGetBytes(offset));
> +  }
> +
> +  public byte[] getBytes(int offset, int length) {
> +    return toJavaArray(nativeGetBytes(offset, length));
> +  }
>
>    public native int getLength()/*-{
>      return this.length;
> @@ -65,4 +78,25 @@
>    public native Blob slice(int offset, int length)/*-{
>      return this.slice(offset, length);
>    }-*/;
> +
> +  private native JsArrayInteger nativeGetBytes() /*-{
> +    return this.getBytes();
> +  }-*/;
> +
> +  private native JsArrayInteger nativeGetBytes(int offset) /*-{
> +    return this.getBytes(offset);
> +  }-*/;
> +
> +  private native JsArrayInteger nativeGetBytes(int offset, int length) /*-{
> +    return this.getBytes(offset, length);
> +  }-*/;
> +
> +  private byte[] toJavaArray(JsArrayInteger bytes) {
> +    int length = bytes.length();
> +    byte[] ret = new byte[length];
> +    for (int i = 0; i < length; i++) {
> +      ret[i] = (byte) bytes.get(i);
> +    }
> +    return ret;
> +  }
>  }
>
>
>
> >
>



-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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

[gwt-contrib] Re: Add Gears' BlobBuilder

[Eric Ayers]

Hi Thomas,

It looks like something is wrong with the patch.  The 'Factory'
portion doesn't show up.  Probably just a hiccup with rietveld, could
you re-upload?  Also, set 'galgwt.reviews' (me, Eric Ayers) as a
reviewer and re-direct the -cc to gwt-google-a...@googlegroups.com

Thanks,
-Eric.

On Sun, Jul 5, 2009 at 11:37 AM, Thomas Broyer wrote:
>
> Reviewers: t.broyer,
>
> Description:
> This patch adds support for Gears 0.5.21 BlobBuilder API.
>
> Please review this at http://galgwt-reviews.appspot.com/41603
>
> Affected files:
>  gears/src/com/google/gwt/gears/client/Factory.java
>  gears/src/com/google/gwt/gears/client/blobbuilder/BlobBuilder.java
>  gears/src/com/google/gwt/gears/client/blobbuilder/package.html
>
> >
>



-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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

[gwt-contrib] Re: using string constants in @def

[Eric Ayers]

I uploaded a patch for consideration at:

  http://gwt-code-reviews.appspot.com/50804

On Tue, Jun 30, 2009 at 9:49 AM, Eric Ayers wrote:
> In this case, I'm trying to share color definitions between CSS and my
> source.  I have a palette of colors that I want to share.
>
> On Tue, Jun 30, 2009 at 9:13 AM, Bob Vawter wrote:
>> What you're asking for isn't too hard to implement, but I'm curious
>> about the actual use case.  In what circumstances would your Java code
>> care about string-valued properties?  Can @eval or the value()
>> function be used instead?
>>
>>
>> --
>> Bob Vawter
>> Google Web Toolkit Team
>>
>
>
>
> --
> Eric Z. Ayers - GWT Team - Atlanta, GA USA
> http://code.google.com/webtoolkit/
>



-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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

[gwt-contrib] Re: using string constants in @def

[Eric Ayers]

In this case, I'm trying to share color definitions between CSS and my
source.  I have a palette of colors that I want to share.

On Tue, Jun 30, 2009 at 9:13 AM, Bob Vawter wrote:
> What you're asking for isn't too hard to implement, but I'm curious
> about the actual use case.  In what circumstances would your Java code
> care about string-valued properties?  Can @eval or the value()
> function be used instead?
>
>
> --
> Bob Vawter
> Google Web Toolkit Team
>



-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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

[gwt-contrib] Re: using string constants in @def

[Eric Ayers]

Sorry, a little more context, I'm talking about the CssResource class.

On Mon, Jun 29, 2009 at 5:58 PM, Eric Ayers wrote:
> Bob,
>
> I would like to use a string constant in an @def.
>
> Would you be open to a patch that added a new Method annotation to
> distinguish this type of accessor from a class name?
>
> --
> Eric Z. Ayers - GWT Team - Atlanta, GA USA
> http://code.google.com/webtoolkit/
>



-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

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