[gwt-contrib] Re: UnifyAst correctly handles polymorphic overrides with mixed default/public access. (issue1470803)
On Wed, Jul 6, 2011 at 12:07 PM, Eric Ayers zun...@google.com wrote: So, the tests in the back-end issue are valid, but the GwtAstBuilder patch is superceded. Could you roll the tests into issue 1470803? Lemme clarify. The tests in the back-end are valid tests, which fail both with GwtAstBuilder and without it. It's a latent, existing bug in our back end which 1470803 doesn't fix. 1469804 was my initial attempt to fix it, but doesn't work. We cannot commit the tests right now as we have no fix for them. 1470803 merely brings GwtAstBuilder up to parity with the old compiler to solve the front end issue. This solves SOME currently broken cases, but not all possible cases as the tests in 1469804 demonstrate. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Ignore invalid types in heirarchy (issue1466806)
On Fri, Jun 24, 2011 at 8:35 AM, zun...@google.com wrote: So, what you are saying is that we are getting lots of unrelated errors for units that reference foo that are obscuring the real problem? The unrelated units are actually causing a blow-up. When we try to construct the type hierarchy to represent Foo (as seen by the valid units), it blows up. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Suppress additional JDT compile problems (issue1461804)
On Fri, Jun 24, 2011 at 10:02 PM, stephen.haber...@gmail.com wrote: Sounds good; I was hoping for some kind of for good measure reason like that. I've been translating GwtAstBuilder/ReferenceMapper to jribble versions and had to skip over this part because jribble only has textual ASTs, so when I come across external types, I can't fill these in. Definitely hack around, and if everything works ok without resolving the hierarchy, great! :) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Bug triggered in SourceFileCompilationUnit.asCachedCompilation() (issue1461803)
Now that's a good answer! So the real is is just to close the result of sourceFile.openContents()? I would update the doc on DiskCache.tranferTo/FromStream that they don't close the stream, and then look at all the callers and make sure they do the right thing. On Fri, Jun 24, 2011 at 10:36 PM, zun...@google.com wrote: Found the reason it fixes it. The machine I'm testing on is not tuned for lots of files: [java] Caused by: java.io.FileNotFoundException: /home/testing/gwt-orig/us\ er/src/com/google/gwt/i18n/**client/impl/cldr/** DateTimeFormatInfoImpl_eu.java (Too\ many open files) [java] at java.io.FileInputStream.open(**Native Method) [java] at java.io.FileInputStream.init**(FileInputStream.java:137) [java] at com.google.gwt.dev.resource.**impl.FileResource.**openContents(F\ ileResource.java:63) [java] ... 7 more The root cause is that the the original code doesn't close the stream returned from Resource.openContents(). Everywhere else that diskCache.transferFromStream() is used, its in the context of a readObject() override, so this is the only place where this would cause a problem. FYI, here's the original stack trace. I've seen them before but not in such a reproducable way [java] [ERROR] Unexpected internal compiler error [java] java.lang.NullPointerException [java] at com.google.gwt.dev.util.**DiskCache.transferFromStream(** DiskCache.java:154) [java] at com.google.gwt.dev.javac.**SourceFileCompilationUnit.** asCachedCompilationUnit(**SourceFileCompilationUnit.**java:59) [java] at com.google.gwt.dev.javac.**CompilationUnitArchive.**addUnit(** CompilationUnitArchive.java:**88) [java] at com.google.gwt.dev.**CompileModule.run(**CompileModule.java:283) [java] at com.google.gwt.dev.**CompileModule$1.run(**CompileModule.java:162) [java] at com.google.gwt.dev.**CompileTaskRunner.doRun(**CompileTaskRunner.java:88) [java] at com.google.gwt.dev.**CompileTaskRunner.**runWithAppropriateLogger(** CompileTaskRunner.java:82) [java] at com.google.gwt.dev.**CompileModule.main(**CompileModule.java:165) http://gwt-code-reviews.**appspot.com/1461803/http://gwt-code-reviews.appspot.com/1461803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add concrete SourceInfo for varargs in method calls (issue1454801)
SGTM, I'll double-check my settings. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: JavaAstConstructor uses UnifyAst. (issue1453810)
What Eric said. I haven't nailed down all the error reporting yet (although it's closer now), but the idea is that we really can avoid reporting errors on unreachable types. And not reaching code means fewer deserialized types, which is better for memory and takes less time. But there's an even bigger one... When code flow reaches GWT.create() calls, we have to run rebinds, and therefore generators, and reach even more code. So there's a spiraling effect. JDT used to limit the total reach by only pulling in the types necessarily to finish a compilation. If we didn't do SOME kind of prune off, we might end up being SLOWER than before. Since we have to do some prune off then, it makes sense to do a good job with it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: This patch substantially reduces the overhead of Java types in the output by minimizing vtable s... (issue1447821)
Don't worry about it, since I'm punting the review over to Jason and Eric. :P -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: I don't believe in magic, but as Scott points out, there are consistent (issue1453804)
LOL On Sun, Jun 5, 2011 at 1:50 PM, zun...@google.com wrote: srsly, we don't want this kind of thing to be happening: http://www.wsbtv.com/news/**28127904/detail.htmlhttp://www.wsbtv.com/news/28127904/detail.html http://gwt-code-reviews.**appspot.com/1453804/http://gwt-code-reviews.appspot.com/1453804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add concrete SourceInfo for varargs in method calls (issue1454801)
Be sure to get the one in GwtAstBuilder too. But don't makeChild() there, just use the existing reference. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: I cannot comment on your proposals because I don't know gwt internals enough. I decided to add a method to TypeOracle that allows me to ask if given type comes from Java or Jribble. If it's Jribble I don't try to do any conversions. This is ugly and fragile method but seems to be the only viable strategy for now. If you guys can come up with systematic solution to this problem it would be awesome. Use an annotation. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
You wouldn't have to hack TypeOracle. You could just look for your particular annotation to see what was a Jribble type. On Sun, May 29, 2011 at 1:47 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: 2011/5/29 Scott Blum sco...@google.com On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: I cannot comment on your proposals because I don't know gwt internals enough. I decided to add a method to TypeOracle that allows me to ask if given type comes from Java or Jribble. If it's Jribble I don't try to do any conversions. This is ugly and fragile method but seems to be the only viable strategy for now. If you guys can come up with systematic solution to this problem it would be awesome. Use an annotation. You mean putting annotation to every Jribble type? How that would help? Also, I thought you'd enjoy this question: http://stackoverflow.com/questions/6167326/java-class-name-containing-dollar-sign Seems like javac can confuse itself about dollar sign, sigh. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
What John said. Blame Java for the fact that with some lookup oracle, it's
impossible to distinguish the cases. We've always assumed that users would
not use '$' in class names in places where it matters.
That being said, let's assume that a user isn't allowed to have both A.B and
A$B like Toby said, as the binary names would collide. Given that, I
*think* the only place source type name really matters is resolving rebind
requests and results. So maybe it's possible we could use only binary name
or internal name everywhere and move away from using source name except in
output messages.
On Fri, May 27, 2011 at 9:50 AM, John Tamplin j...@google.com wrote:
On Fri, May 27, 2011 at 4:45 AM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
2011/5/26 Eric Ayers zun...@google.com:
Unfortunately, I tried removing the replace('$',.) and it failed
miserably. Looking at it in the debugger, those really are binary
names.
e.g.:
com.google.gwt.core.client.impl.AsyncFragmentLoader$LoadingStrategy
Thanks guys for you answers. I moved on with my work-around. It would
be great if those binary names were converted to source names as soon
as possible so number of places in gwt code where we have to consider
both options is minimized.
The problem is conversion to source names is lossy -- given Foo.Bar.Baz,
you don't know where the split between the package name, enclosing class
name, and class name is (compare to Foo/Bar$Baz and Foo/Bar/Baz). I think
the only way you could avoid this problem is if you kept a structured type
with those pieces of information rather than a simple string, but that would
be expensive in terms of allocating several additional objects for every
class name in the program, plus many uses don't care about the distinctions
and just wand the source name.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote: I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. My point is to NOT convert it to source names, do everything in binary. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
The compiler internals could be coded to use binary names. Obviously, generators would do something sensible. For example, I know that rebind rules in gwt.xml are tracked by source name. Well, those could get looked up in TypeOracle and translated to the appropriate binary name and tracked that way. You would always to one-way conversions from source-binary and never back. On Fri, May 27, 2011 at 1:01 PM, John Tamplin j...@google.com wrote: On Fri, May 27, 2011 at 12:53 PM, Scott Blum sco...@google.com wrote: On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote: I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. My point is to NOT convert it to source names, do everything in binary. So when you generate source code, how do you do that? Or let's just say you want to get the simple class name -- in the example, is it Bar$Baz or Baz? The point is you don't have the information necessary to tell. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Autoformats user/super and user/test-super (issue1442805)
I'm not sure what all that means, but shouldn't GPE be able to just turn the code formatter on automatically? On Tue, May 24, 2011 at 1:00 PM, Eric Ayers zun...@google.com wrote: Alex added a new eclipse application to GPE. If you've got his latest and greatest (not sure if its public yet) eclipse -nosplash -application com.google.gwt.eclipse.core.GWTCodeFormatterApplication java xml formatting opts js .prefs file [ list of files and/or dirs ] On Tue, May 24, 2011 at 12:55 PM, sco...@google.com wrote: Whoa, do you really have autoformatting JSNI working? If so, that is totally awesome! http://gwt-code-reviews.appspot.com/1442805/ -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Re-implement runAsync to improve code size. (issue1442807)
Yeah, sorry. old = what is now committed and new = this patch. On Fri, May 20, 2011 at 9:41 AM, zun...@google.com wrote: I'm missing some contect here. I don't know what you mean by 'new' and old implementations of runAsync. How new is new (this cl? something already committed or a project in the works?) http://gwt-code-reviews.appspot.com/1442807/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Pruner runs only once. (issue1436802)
Cool beans. On Mon, May 16, 2011 at 8:14 PM, Ray Cromwell cromwell...@google.comwrote: I've done a quick scan of this and it looks ok, but I'd like to take some time tonight to review it in more detail. I like the 'membersLiveExceptForInstantiability' change, I was going the suggest something like that when I was doing the JSO CFA overhaul last time. Also the checks in Pruner are simpler now. On Fri, May 13, 2011 at 11:37 AM, Scott Blum sco...@google.com wrote: On Fri, May 13, 2011 at 11:15 AM, Eric Ayers zun...@google.com wrote: I've been reading the code and talking to Scott about it. The loop being removed is the while() loop in execImpl(). The jitter is the fact that the ControlFlowAnalyzer might return one result for liveness before the Pruner runs, and a different result after Pruner runs. If you don't loop inside of Pruner, then the entire optimization pass may have to run extra times. Great explanation! The last time we tried to naively remove the while loop from Pruner, the outer optimization loop went from ~7 passes to ~10 passes for Showcase, and the total optimization time went up. You can think of my patch as converging faster. With my patch in and the Pruner loop gone, you still only get ~7 outer optimization loops, and the total optimization time goes down. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Decentralize nullmethod/nullfield (issue1442802)
On Sat, May 14, 2011 at 9:22 AM, zun...@google.com wrote: I know I've asked this before, but if code isn't live in the runer, we replace it with null.nullMethod(), null.nullField or the likes. Why do we keep this around? Dead Code elimination usually gets rid of it (but not always?) is it just left there to trip over at run time in case there is a bug in our liveness tests? It's a correct translation of code where static analysis proves that a qualifier is null. User code: String s = null; s.toCharArray(); Translation: null.nullMethod(); That way, we throw an NPE in the correct place at runtime. Or more technically, it generates an implicit null ref JavaScriptException. If it weren't for the desire to match the platform semantics, we could just as easily replace it with throw new NullPointerException(). Arguably, we could just leave it as null.toCharArray(), but the whole idea is to remove 'toCharArray() from the AST, and we wouldn't want to leave a dangling reference to it that we'd have to worry about later. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Pruner runs only once. (issue1436802)
On Fri, May 13, 2011 at 11:15 AM, Eric Ayers zun...@google.com wrote: I've been reading the code and talking to Scott about it. The loop being removed is the while() loop in execImpl(). The jitter is the fact that the ControlFlowAnalyzer might return one result for liveness before the Pruner runs, and a different result after Pruner runs. If you don't loop inside of Pruner, then the entire optimization pass may have to run extra times. Great explanation! The last time we tried to naively remove the while loop from Pruner, the outer optimization loop went from ~7 passes to ~10 passes for Showcase, and the total optimization time went up. You can think of my patch as converging faster. With my patch in and the Pruner loop gone, you still only get ~7 outer optimization loops, and the total optimization time goes down. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables on the persistent unit cache by default. (issue1448801)
SGTM. At some point I'll have to deal with versioning for the embedded GWT ASTs, but I can burn that bridge when I come to it. On Thu, May 12, 2011 at 6:48 PM, zun...@google.com wrote: I know the paint is still drying on the last patch I submitted for the Persistent Unit Cache, but no real problems have been reported in... weeks! I think its ready to be on by default. http://gwt-code-reviews.appspot.com/1448801/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Rescues cached entries from jar files that are the same, save for the timestamp. (issue1441803)
On Wed, May 11, 2011 at 10:57 PM, zun...@google.com wrote: this needs to return a copy. all other implementations of asCachedCompilationUnit() already return a copy. That would make CachedCompilationUnit.writeReplace() be weird tho, right? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
I mean only super-sourced. Does Object come through as 'com/google/gwt/emul/java/lang/Object.java' or merely 'java/lang/Object.java'? On Tue, May 3, 2011 at 2:56 PM, zun...@google.com wrote: On 2011/05/03 18:45:15, scottb wrote: LGTM. Like Toby said, this is much better. Can you confirm that re-rooted resources retain their original (non-rerooted) path location? What do you mean by re-rooted resources? super sourced resources? One thing I looked at was that generated resources create their path from the type name, but I don't think they get re-rooted if what you mean that is items that have been super sourced. http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix a class of compiler bugs related to staticImpl. (issue1428804)
If the Java MethodInliner kept call counts, I would have special-cased it to
allow inlining the static into the instance when it's the only caller. But
since call counts aren't already computed, I decided it would be best to try
it out as is and see if it actually increases code size in practice.
On Wed, Apr 27, 2011 at 2:20 PM, Ray Cromwell cromwell...@google.comwrote:
As long as the JsInliner can still clean it up, I'm fine, otherwise, it
seems like it would introduce some bloat by having trivial delegations. I'm
actually wondering if we should detect the case when a static method ONLY is
referenced by the instance method it was created from via delegation, and
*anti-staticify* it, e.g.
function foo(x) {
foo$(this, x);
}
function foo$(this$static, x) {
this$static.x=x;
}
becomes
function foo(x) {
this.x=x;
}
-Ray
On Mon, Apr 25, 2011 at 6:46 PM, sco...@google.com wrote:
Reviewers: cromwellian, jbrosenberg,
Message:
Ran into this general class of issue... originally I set out to add
staticImpl handling logic to a couple more places, such as
ImplicitUpcastAnalyzer. But the more I thought about it, the more it
struck me as a real wart, and one that's not giving us much value.
Perhaps even negative value by causing code bloat. I think it's much
simpler to just never inline staticImpls into the calling virtual
method.
Please review this at http://gwt-code-reviews.appspot.com/1428804/
Affected files:
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
M dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
M
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
Index: dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
index
d7f5f3fecfdb50302c7a723d3d9ead02d30d9e50..92eb2bb156eaee1683049a95472d1d7f9ce09c0d
100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
@@ -145,6 +145,20 @@ public class MethodInliner {
@Override
public boolean visit(JMethod x, Context ctx) {
currentMethod = x;
+ if (program.getStaticImpl(x) != null) {
+/*
+ * Never inline a static impl into the calling instance method.
We used
+ * to allow this, and it required all kinds of special logic in
the
+ * optimizers to keep the AST sane. This was because it was
possible to
+ * tighten an instance call to its static impl after the static
impl had
+ * already been inlined, this meant any flow type optimizer
would have
+ * to fake artifical flow from the instance method to the static
impl.
+ *
+ * TODO: allow the inlining if we are the last remaining call
site, and
+ * prune the static impl? But it might tend to generate more
code.
+ */
+return false;
+ }
return true;
}
Index: dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
b/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
index
0ffdcf40faefc2fdc8b3c4ecf293c2ac372d5568..0b67077fe1db9ca11caf48e0fd5be80f15815e0e
100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
@@ -360,7 +360,8 @@ public class Pruner {
for (int i = 0; i type.getMethods().size(); ++i) {
JMethod method = type.getMethods().get(i);
-if (!methodIsReferenced(method) ||
pruneViaNoninstantiability(isInstantiated, method)) {
+if (!referencedNonTypes.contains(method)
+|| pruneViaNoninstantiability(isInstantiated, method)) {
// Never prune clinit directly out of the class.
if (i 0) {
type.removeMethod(i);
@@ -394,7 +395,7 @@ public class Pruner {
for (int i = 1; i type.getMethods().size(); ++i) {
JMethod method = type.getMethods().get(i);
// all other interface methods are instance and abstract
-if (!isInstantiated || !methodIsReferenced(method)) {
+if (!isInstantiated || !referencedNonTypes.contains(method)) {
type.removeMethod(i);
madeChanges();
--i;
@@ -426,6 +427,8 @@ public class Pruner {
* devirtualizations. If the instance method has been pruned, then
it's
* okay. Also, it's okay on the final pass since no more
* devirtualizations will occur.
+ *
+ * TODO: prune params; MakeCallsStatic smarter to account for it.
*/
JMethod staticImplFor = program.staticImplFor(x);
// Unless the instance method has already been pruned, of course.
@@ -485,31 +488,6 @@ public class Pruner {
return false;
}
[gwt-contrib] Re: Fix a class of compiler bugs related to staticImpl. (issue1428804)
On Wed, Apr 27, 2011 at 3:20 PM, jbrosenb...@google.com wrote: If I understand correctly, part of staticification is that all call-sites to myVar.foo(x) will be replaced by $foo(myVar, x), and thus foo(x) will be unused, and thus pruned. So, the delegation issues goes away, no? Yes, as long as all call sites can be devirtualized, the instance method goes away. On Wed, Apr 27, 2011 at 3:51 PM, jbrosenb...@google.com wrote: It looks like there might be some logic in ControlFlowAnalyzer.RescueVisitor.Rescue, which can also be removed if inlining staticImpl's is not an issue. Whoops! Yes, I need to remove that, my bad. On Wed, Apr 27, 2011 at 4:34 PM, jbrosenb...@google.com wrote: I see now (looking at MakeCallsStatic.RewriteCallSites) that not all call sites get replaced, there are a few edge cases, relating to split points, etc., where the call sites are not replacedBut I'm guessing it won't be a large number of cases. Yes, there will be cases where both the instance and static method make it into the final output. In some of those cases, JsInliner will actually do the inlining. In others, my theory is that not inlining them won't have a negative effect on code size. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Re-architect how overrides are handled. (issue1422810)
It actually does fix the abstract getClass() problem, I was noticing in the generated output. I'll mark my change as fixing this issue. On Tue, Apr 26, 2011 at 4:03 AM, t.bro...@gmail.com wrote: Hey, it looks like it would fix this issue, cool! http://code.google.com/p/google-web-toolkit/issues/detail?id=4893 According to my tests at the time, it would enable pruning of most getClass() methods (at a minimum all those for abstract classes, which are always overridden in the concrete classes, and then never executed): http://gwt-code-reviews.appspot.com/609801/show http://gwt-code-reviews.appspot.com/1422810/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: EnumOrdinalizer cleanup better interop. (issue1426804)
Based on your comments, I'm going to rework the patch. You're right, I was totally confused about the difference between ReplaceEnumTypesWithInteger ReplaceOrdinalFieldAndMethodRefsWithOrdinal. I think the JField / JFieldRef replacements in the former are what threw me. I'll rework the patch. By valid state of the AST, I had run into a case in some work I was doing where you had by analogy the equivalent of EnumType x = 3, and TypeTightener was needing to clean up after. But I think now that what I needed to do in my patch was update TypeRemapper instead. Lemme rework this and see what falls out. On Tue, Apr 26, 2011 at 3:12 PM, jbrosenb...@google.com wrote: Scott, would you mind, for my own edification, outlining how this improves the valid state of the AST after EnumOrdinalizer runs? Thanks. http://gwt-code-reviews.appspot.com/1426804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Small generator testing framework (issue1424805)
Yeah, they're in an impl package. On Tue, Apr 19, 2011 at 11:12 AM, schm...@google.com wrote: I think the idea here is that no one (outside the existing GWT tests) should reference the *Resource classes directly - that's why we have the new interface Source. This way, you should be able to refactor the *Resource classes without breaking anyone, especially the original Resource interface. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Supress errors when building the Type Oracle. (issue1385810)
On Thu, Mar 31, 2011 at 7:38 PM, Eric Ayers zun...@google.com wrote: It was kind of disruptive to pass the suppressErrors setting around through method parameters. I assume that's what you're talking about. Yeah. The good thing about logging inside of CompilationStateBuilder is that there is a concious decision about what to do with errors when you build the CompliationState. Yeah, but this sort of flips it around and says, If you want errors, log them. Another small wrinkle is that in JavaToJavaScript compiler we've ditched the CompilationState to save memory before the time we want to report errors (but we could always just keep it or some subset of the data and log them at a TRACE/DEBUG level like this patch does.) The new translator stuff I'm working on is going to get rid of that code path, however. It will work a lot more like CompilingClassLoader, and explicitly log errors one unit at a time as you need to reference a unit that had errors. The compilation state will have to be around until after we have the AST built out. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: LongLibBase improperly stomps on global 'a' variable. This patch reuses globalTemp (_) instead. (issue1389803)
Sounds good. Now that I think about it, it may not make much performance
difference if time tends to be dominated by the actual math ops, but I
suppose every bit helps?
On Tue, Mar 29, 2011 at 10:35 AM, Daniel Rice (דניאל רייס)
r...@google.comwrote:
I did the reimplementation. Being less familiar with the intricacies of
JavaScript, it seems likely that I missed an opportunity to preserve the
nativeness of the array. I'd be happy to take a look at this after the 2.3
release.
On Mon, Mar 28, 2011 at 5:52 PM, Scott Blum sco...@google.com wrote:
Something smells fishy here. I'm quite certain that this used to be
implemented strictly as a two-double array in web mode, a true array. At
some point it was modified to use 3 elements instead of 2, but I don't think
it should have lost its nativity.
On Mon, Mar 28, 2011 at 5:36 PM, cromwell...@google.com wrote:
http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java
File dev/core/super/com/google/gwt/lang/LongLibBase.java (right):
http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java#newcode325
dev/core/super/com/google/gwt/lang/LongLibBase.java:325: _.l = l, _.m =
m, _.h = h, _);
On 2011/03/28 21:31:25, scottb wrote:
Stupid question, but why can't we just return {l:l, m:m, h:h}?
Good question. It looks like LongEmul is not a JSO, because they want to
reuse it in both JVM and ProdMode, so it's a Java type. This code may
have existed before @GwtScriptOnly or SingleJsoImpl. If I were during
this today, I'd make LongEmul an interface, use JSO for ProdMode, and
JRE impl for everything else.
I guess we'll revisit it later.
http://gwt-code-reviews.appspot.com/1389803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: LongLibBase improperly stomps on global 'a' variable. This patch reuses globalTemp (_) instead. (issue1389803)
Something smells fishy here. I'm quite certain that this used to be
implemented strictly as a two-double array in web mode, a true array. At
some point it was modified to use 3 elements instead of 2, but I don't think
it should have lost its nativity.
On Mon, Mar 28, 2011 at 5:36 PM, cromwell...@google.com wrote:
http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java
File dev/core/super/com/google/gwt/lang/LongLibBase.java (right):
http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java#newcode325
dev/core/super/com/google/gwt/lang/LongLibBase.java:325: _.l = l, _.m =
m, _.h = h, _);
On 2011/03/28 21:31:25, scottb wrote:
Stupid question, but why can't we just return {l:l, m:m, h:h}?
Good question. It looks like LongEmul is not a JSO, because they want to
reuse it in both JVM and ProdMode, so it's a Java type. This code may
have existed before @GwtScriptOnly or SingleJsoImpl. If I were during
this today, I'd make LongEmul an interface, use JSO for ProdMode, and
JRE impl for everything else.
I guess we'll revisit it later.
http://gwt-code-reviews.appspot.com/1389803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add missing tests to JavaCompilationSuite (issue1385808)
Thanks, it is really nice for Eclipse testing.
On Fri, Mar 25, 2011 at 9:56 PM, Eric Ayers zun...@google.com wrote:
LGTM
I didn't think maintaining this suite was a priority - the ant build
searches for *Test.java and ignores the suite. I guess if you are
manually testing from eclipse its useful.
On Fri, Mar 25, 2011 at 8:10 PM, sco...@google.com 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)
On Wed, Mar 23, 2011 at 9:57 AM, zun...@google.com wrote: If we only write the cache to the same war dir subdirectory, then I think my concerns with purging the cache are solved (the cache will be in a well known place). I'm still going to make an exception so that setting a system property will allow the cache to be written to a specific dir so we can support the caching from GWTShell invocations, but I'll remove it from GWTCompiler, Precompile and PrecompileOneShard. SGTM. I'll change the key to lookup by resource name, but that's going to cause some indigestion for the spam error message reduction patch I've been working on. If there is ambiguity caused by super source, then that problem needs to be resolved anyway. It's not a true ambiguity imagine you're running two apps at once in dev mode. The first module has a com.example.Foo at 'com/example/Foo.java'. The second module has a totally different implementation because it uses super source to get the copy at 'com/example/super/com/example/Foo.java'. These are literally two different compilation units with different source, mod times, and outputs. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds a cache (PersistenUnitCache) to store CompilationUnits (issue1375802)
On Wed, Mar 23, 2011 at 1:02 PM, Eric Ayers zun...@google.com wrote: FYI: I am adding a call to return the resource location to the CompilationUnit to handle changing the key. That's what CompilationUnitBuilder.getLocation() was used for and in practice, CompilationUnit.getDisplayLocation() returns exactly the same value and serves exactly the same purpose, although you'd need to update the antiquated Javadoc that suggests otherwise. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Are there any docs describing internals of gwtc?
On Mon, Mar 21, 2011 at 10:10 AM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: The problem I described above (broken polymorphic calls) was caused by superClass field being equal to null for nodes representing interfaces. That would lead to broken overrides calculations for an interface containing method called toString (that overrides one from java.lang.Object) and thus to broken JS output. That was fairly non-trivial to find because you need toString being called through an interface to trigger that behaviour. Now, I'm wondering if it wouldn't make sense to have an assertion in some place checking that whether interfaces have java.lang.Object as their superClass as it seems to be invariant for GWT. I seem to recall at one point we actually put some thought into not having super interfaces have a superClass field at all, and just always have the compiler implicitly assume Object. Not sure where that idea went, or why we ended up not doing that. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Moving UnitTestTreeLogger from dev/core/src to dev/core/tests, so gwt-dev (issue1383804)
I was thinking you'd want to remove junit.jar from the non-test build path
for gwt-dev.
On Fri, Mar 18, 2011 at 1:52 PM, Freeland Abbott fabb...@google.com wrote:
Turns out that ant is already covered: user/build.xml has, in part:
!--
Classpaths added for test cases
--
path id=test.extraclasspath
pathelement location=${gwt.build}/out/dev/bin-test /
etc.
so dev/bin-test is already available. I guess source code wouldn't be, but
translatable tests seem unlikely to mess with TreeLoggers, and empirically
when I ran ant tests, the only problem I got was was from
com.google.gwt.validation.tck.ConstraintCompositionGwtSuite.xml
(draft-htmlunit and nometa-htmlunit only, dev, emma, and web were all
fine)... I assumed that was a system flake, not something symptomatic of my
change. The error was Testcase: Monitor file
(blahblahblah/junitvmwatcher6602185781037387809.properties) missing,
location not writable, testcase not started or mixing ant versions?, which
seemed unlikely to be related to migration of UserTestTreeLogger, especially
with the others passing.
On Fri, Mar 18, 2011 at 1:40 PM, Scott Blum sco...@google.com wrote:
LGTM. Shouldn't some ant build rules want to change, though?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Moving UnitTestTreeLogger from dev/core/src to dev/core/tests, so gwt-dev (issue1383804)
LGTM. Shouldn't some ant build rules want to change, though? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Are there any docs describing internals of gwtc?
On Mon, Mar 14, 2011 at 3:03 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: 1. What's the difference between TypeMap and TypeOracle and why they seem to have overlapping functionality? In GWT, there are two major pieces of infrastructure that deal with representing Java language input. 1) A reflection of the user's type model for the purposes of running generators. Approximately equivalent to the kind of information you can get via Java reflection. Models types, fields, and methods, but not method bodies. The entire machinery around this can be loosely referred to as TypeOracle, which is the primary interface for accessing this type model. Generators use this type model to generate code. This infrastructure is used in both dev mode and web mode, as Generators run in both contexts. 2) The GWT AST, which is essentially a source-level representation of the user's Java code, including method bodies, which is optimized and translated into JavaScript. May be referred to as GWTC, the compiler, the web-mode compiler, etc. Mostly lives in com.google.gwt.dev.jjs (which stands for 'Java to JavaScript'). TypeMap is a small implementation detail that's only useful for the JDT AST - GWT AST translation. 2. Why TypeOracleMediator operates on bytecode whereas gwtc is supposed to work with java source, or jdt's asts? Historically, we've run JDT twice. Once to build TypeOracle, and once to build the GWT AST. Efforts have been made to transition TypeOracle to be built from bytecode, which would eliminate one of these JDT runs in favor of using external (presumably IDE-built) class files. 3. How emulation of object orientation is implemented in gwt? Using JavaScript prototype chains, and mangling method signatures such that any given override of a method has a globally unique name in the compiled output. Try compiling with -style PRETTY or DETAILED and inspect the output. 4. What are main phases in gwtc's execution. What are dependencies? JavaToJavaScriptCompiler .precompile() is what I would consider the main high-level algorithm. But here's a text overview. 1) Build TypeOracle from the initial set of available source units (CompilationStateBuilder). 2) Begin running the web mode compile (WebModeCompilerFrontEnd). 3) As the web mode compile runs, we encounter GWT.create() calls (FindDeferredBindingSitesVisitor). 4) Use the rebind infrastructure to resolve rebind requests. This may entail running Generators, which generate new code. 5) Newly-generated types get added to CompilationState + TypeOracle in a bit of a loop-back process. 6) Newly-generated types may themselves contain GWT.create() calls, looping back through step 4. 7) Eventually, all our code is generated. Get rid of TypeOracle, we don't need it anymore. 8) GenerateJavaAST turns the JDT AST into the GWT AST. 9) Normalize certain difficult constructs. 10) Optimize. 11) Post-optimization normalizes to turn high-level Java constructs into JS-specific implementation details (but still Java AST). 12) GenerateJavaScriptAST 13) Optimize JS AST 14) Produce JS source text. I'd like to know where TypeMap is being built and why it's done twice. It should only get built once. Also, TypeOracle seems to be highly mutable data structure. When it gets updated and why? From the outside, it should be seen as append only. Existing state should be effectively immutable. It gets updated because Generators produce new types as the compile proceeds. Do you guys have anything (slides, blog posts, discussions, etc.) that would help me to better understand those matters? Here's wiki entries for TypeOracle / CompilationState. The first is outdated by useful to understand the second one. http://code.google.com/p/google-web-toolkit/wiki/CompilationUnit_1_5 http://code.google.com/p/google-web-toolkit/wiki/CompilationUnit -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Are there any docs describing internals of gwtc?
On Mon, Mar 14, 2011 at 4:41 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: So, if my GWT app doesn't have any generators exact contents of TypeOracle doesn't matter? I'm asking because I'm thinking of creating some stub data structures for jribble units and just move on to fixing some other issues and come back only once I want to support Generators written in Scala or Generators referring Scala. That *may* be true but you'd have to try it and find out. I know we use TypeOracle for a couple of other purposes in dev mode, but I don't *think* we use it for anything else in web mode.. 2) The GWT AST, which is essentially a source-level representation of the user's Java code, including method bodies, which is optimized and translated into JavaScript. May be referred to as GWTC, the compiler, the web-mode compiler, etc. Mostly lives in com.google.gwt.dev.jjs (which stands for 'Java to JavaScript'). TypeMap is a small implementation detail that's only useful for the JDT AST - GWT AST translation. I see. It happens that TypeMap is quite interesting from my point of view because I'm translating Jribble AST to GWT AST by following JDT AST - GWT AST translation (more or less). Eek... to be honest, JDT AST - GWT AST is some of the nastiest code around, mostly due to JDT. If you're going to follow a pattern, you might look at the new GwtAstBuilder, which is at least marginally cleaner than BuildTypeMap/GenerateJavaAST. Is there one class that is dealing specifically with emulating object orientation or it's scattered around many classes? I'm asking because toString() call get's translated to toString_2() javascript call and this method is not being defined anywhere in js source code. I'm trying to pinpoint location where this stuff is handled to understand why I get a call to non-existing place. Hmm, I'm not completely sure what you're asking. GenerateJavaScriptAST is the place to look for how precisely the Java AST is transformed into JavaScript. I've got another question. Do you have any tool for checking correctness of GWT's ASTs or a tool that allows one to dump ASTs and compare them? The scenario I have in mind is like this: 1. I have minimal jribble example that exhibits some obscure problem like with toString described above and I fail to find a bug but I suspect that GWT ASTs I get out of Jribble are broken. 2. I prepare corresponding Java code that imitate code from jribble. This should work (or I found a bug in gwtc itself but this is highly unlikely). Now I'd like to compare those two ASTs. Such comparison should immediately reveal the source of my problems. You can always call toSource() on any GWT AST node to get the source representation. GwtAstBuilderTest utilizes this to verify that the new GwtAstBuilder is mostly source-compatible with the old translator. We also have a bunch of unit tests derived from JJSTestBase that all generally verify that a certain input source + certain transformations turns into expected output. Other that that, we use JUnit / GWTTestCase to actually execute the compiled output and verify correctness JUnit style. Scott Do you have anything handy that would help me with this or do you have some other idea how to solve my problem? -- Best regards, Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)
On Thu, Mar 3, 2011 at 10:04 AM, Eric Ayers zun...@google.com wrote: After sleeping on the static rogue setter, I don't like it much either and came up with some alternatives: 1) Would it be more palatable to turn setJavaScriptObjectClass() it into an instance method? That way, we wouldn't have to reset the static variable each time in tearDown and the override would last for only one instance of a TypeOracle. That is the simplest thing I can think of. I think that would definitely be an improvement on the static method. 2) We could make the setter just add to a static list of alternative class names to be treated like JavaScriptObject. That would incur a slight run-time penalty in computeSingleJsoImplData() to check against a list of strings instead of just a single one. But then we wouldn't have to worry about resetting the name. Nah, instance method is better than this. 3) Do you think it would be feasable to taking com.google.gwt...mediatortest.JavaScriptObject.class object's bytecode and re-write the package using ASM? Actually, that might not be too hard at all. 4) You suggested squirreling away a copy of com/google/gwt/core/client/JavaScriptObject.class somewhere on the classpath for the gwt-dev project and using it as the source for the bytecode. This would require some minor refactoring of CheckedJavaResource and subclasses in TypeOracleMediatorTest. To me, this is kind of obscure black magic (comparted to how the rest of the tests are implemented.) Hmm, MutableJavaResource is a bit of a beast these days. Kind of cumbersome that reified Class objects are the primary api there. If Class objects were a convenience, and the underlying api was in terms of stuff you could get from a Class object, then you could have a Class convenience constructor for most of the cases, and special-case JavaScriptObject to work from bytes. You could get the bytes easily enough by instantiating a CompilationStateTestBase and grabbings its 'state', which will already contain a Unit for JSO, the one from JavaResourceBase.JAVASCRIPTOBJECT. I guess it all depends on how serious you are about removing TypeOracleMediatorFromByteCodeTest. If you are going to get rid of that anyway, MutableJavaResource gets a lot simpler, and it becomes pretty easy to just utilize JavaResourceBase.JAVASCRIPTOBJECT. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Formatting changes with updated Eclipse GWT Format settings for issue 1373803 (issue1371806)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)
On Thu, Mar 3, 2011 at 12:36 PM, zun...@google.com wrote: http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java File dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java (right): http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java#newcode218 dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java:218: null, getByteCode(aClass), System.currentTimeMillis()); On 2011/03/03 17:14:07, scottb wrote: Unrelated, but shouldn't this be getLastModified() instead of current time? I dunno, do you want it to use caching? U... your question makes me realize I have no actual clue how that test works or what the significance of that timestamp is! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)
On Thu, Mar 3, 2011 at 1:47 PM, zun...@google.com wrote: http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java File dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java (right): http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java#newcode218 dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java:218: null, getByteCode(aClass), System.currentTimeMillis()); On 2011/03/03 17:36:26, zundel wrote: On 2011/03/03 17:14:07, scottb wrote: Unrelated, but shouldn't this be getLastModified() instead of current time? I dunno, do you want it to use caching? Its intended to represent the timestamp of the source file or class file resource as you mention, but in order to compute dependency between types at the type oracle level. The idea is to use it for determining when to re-run generators or to use the cache of the previous generator run. I figured for unit testing we would want to invalidate any previous cache. Ahh, gotcha. Mind throwing a comment there while you're in there? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Decentralize JClassLiterals. (issue1375801)
Yay! Submitted! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds unit tests for extending JavaScriptObject. Tests a loosening of the (issue1369805)
On Wed, Mar 2, 2011 at 7:21 PM, Eric Ayers zun...@google.com wrote: @Scott: I was not planning to revert the diff cheese. This uses the recently updated official gwt-format.xml autoformatting for Eclipse. I've already volunteered to go through and run the autoformatter to bring existing source up to date. Right, I'm just making the point that it would be great if you could land that first, so that when you submit this change, it won't mix the formatting semantic changes into one CL. Per our face to face, it'd also be good if you could leave a TODO in TypeOracle to remove the rogue setter once TypeOracleMediatorFromByteCodeTest is gone. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Tweak JType memory/serialization footprint. (issue1367801)
Enums should be almost exactly the same, I think. On Mon, Feb 28, 2011 at 5:00 PM, Eric Ayers zun...@google.com wrote: I was trying to think of a way to use enum support (which serializes kind of compactly), but I don't think it would be any more compact than this. On Mon, Feb 28, 2011 at 4:52 PM, sco...@google.com wrote: http://gwt-code-reviews.appspot.com/1367801/ -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA DO NOT FORWARD -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [RFC] GWT Widgets that ROCK!
Hi John,
If my question is stupid or makes incorrect assumptions, feel free to
completely ignore me. My question relates to render and how the
SafeHtmlBuilder is constructed:
@Override
public void render(Context context, SafeHtml data, SafeHtmlBuilder sb) {
sb.appendHtmlConstant(button type=\button\ tabindex=\-1\);
if (data != null) {
sb.append(data);
}
sb.appendHtmlConstant(/button);
}
At a glance, this seems to imply that any inner content has to already be
baked HTML. To me, that seems to imply that for a complex hierarchy, you
have to construct a bunch of SafeHtmlBuilders as you go, bake them, and pass
the result into yet more builders. I don't know how this fits into the
existing model, but would it be possible to do something more visitor like?
@Override
public void render(Context context, SafeHtmlBuilder sb) {
sb.appendHtmlConstant(button type=\button\ tabindex=\-1\);
context.doChildren(sb);
sb.appendHtmlConstant(/button);
}
In effect, you run the SafeHtmlBuilder in 'one shot'.
Just a comment from the peanut gallery, :)
Scott
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Adds a 10 second flush timer to the Speed Tracer logger. (issue1361801)
On Wed, Feb 23, 2011 at 1:16 PM, Toby Reyelts to...@google.com wrote: I'm concerned about how this might impact logging results. For example, even if the results are written out on a separate thread (and assuming the box has an entirely free processor to deal with it), you can still cause the disk to be busy with I/O during the writes, slowing down the real time of the even thread if it's also doing I/O. Basically, we already have enough problems with reproducible results, so I hate the idea of adding even more non-deterministic behavior to the mix. FWIW, the LogWriterThread already is going to randomly flush itself when the buffers fill up, so it's probably not any less deterministic to flush it on a regular basis. The streamed output from dev mode seems like a reasonable use case, even flushing every second or two shouldn't impact performance. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: A Class that creates a string hash out of the public API of a (issue1359802)
On Thu, Feb 17, 2011 at 12:22 AM, jbrosenb...@google.com wrote: Scott makes sense, however, would it not also make sense to have a signature that can also used by generators to determine whether a type has changed (and prevent the need for an alternate signature being maintained for that purpose)? Currently, we have a dumbed down version of generating a signature from the full bytecode (in JRealClassType). That would benefit from an asm based signature that only looks at api level structurePerhaps this present code could be modified to alternately accept a flag to consider annotations as well, if desired. I have to agree that this should be separate. For example, TypeOracle cares about parameter names, annotations, etc; none of which would force recompile propagation. I'm wondering if handling the case where some methods have been re-ordered in a source file is worth incurring the overhead of sorting and managing multiple StringBuilders, etc. This could add up if we have a large number of classes to consider, etc. I'm not sure how often a source file has some fields/methods re-ordered, vs. other api changing edits, or how important it is to seamlessly handle that case (I think the user expects some recompiling when editing code). Maybe it's not too expensive though (in which case I'll go jump off a cliff)? I'm sure it's not terribly expensive, and I'm generally not a fan of trying to micro optimize on the front end. If it becomes a source of sluggishness, it'll show up on profiling at some point. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Recompute whether an interface is dual-implemented by JSO and Java types after each compiler opt... (issue1351801)
On Thu, Feb 17, 2011 at 6:29 PM, Ray Cromwell cromwell...@google.comwrote: That sounds better, but is there a reason why JavaScriptObjectNormalizer was doing this pre-optimization in the first place? I dunno Bob? Anyway, in favor of keeping the 'null instanceof JSO' behavior is that the following code currently will not do a null check either: SomeJso foo = getNull(); foo.someMethod() - translates to jso$someMethod(foo), even if foo is null; In most cases, you'll still get an NPE, when interior of the function tries to deref 'this'. I'll look at re-rolling this using your proposal. Yeah, that's not so much my issue. My issue is more that a user writing null instanceof JSO should NOT get a 'yes' back. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Eliminates empty constructor seed functions by using 2 helper functions to setup (issue1360802)
On Thu, Feb 17, 2011 at 6:43 PM, Ray Cromwell cromwell...@google.comwrote:
So your proposal is something like this:
setupVtable(castableTypeMap, someSuperCtor, ctor1, ctor2);
function setupVtable(ctm, supCtor) {
var newProto = {};
copyProtoFields(someSuperCtor.prototype, newProto);
for(var i = 2; i arguments.length; i++) {
arguments[i].prototype = newProto;
}
newProto.castableTypeMap = ctm;
newProto.getClass = getLazyLiteral(...n);
}
Something like that, yep. Just need to figure out what to do if there
aren't any super ctors (maybe they got inlined?).
- Use ids after all?
- Make a synthetic super ctor just for this purpose?
- Just attach super symbols directly to concrete type.
Actually, #3 might be a reasonable speed vs. size tradeoff, maybe we should
get rid of even virtual proto chaining.
One of the other things I want to do is eliminate global class literal
fields in favor of lazily constructed ones, so that Foo.class is replaced
with getLazyLiteral(someToken), and Object.getClass() is setup dynamically
as well. Class literals are responsible for enormous bloat currently.
SG.
However, my fear is copying prototype fields might hurt V8 optimizations,
or be atrociously slow on mobile browsers.
Will need to test and find out. It might actually be better than having to
go through a multi-level lookup chain.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: A Class that creates a string hash out of the public API of a (issue1359802)
To give some context, this signature is used for the purpose of deciding if a class's API has changed... *as far as other Java source files are concerned for the purposes of running javac*. It has no effect on TypeOracle or the data presented there, it's not being used to cache old TypeOracle models. Using sort order means a user can sort a file without changing its API and not have to recompile the dependent files. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Recompute whether an interface is dual-implemented by JSO and Java types after each compiler opt... (issue1351801)
On Wed, Feb 9, 2011 at 3:36 PM, cromwell...@google.com wrote: It is strange, then again, it is strange that a JSO that is null can still be invoked. :) However, I think I've come back to sanity on rethinking this. Since it is only used for a single use case in my Json library (JsonNull), I think I'll just change the API slightly. I wanted an unwrapped JsonNull to represent json nulls (most APIs use a Java wrapper). Instead, I'll just use the real 'null', and add an extra method to check for the difference between 'null' and undefined. Thanks. :) It would seem really strange if all Java nulls were implicitly treated as JSOs! This is a different issue, and my gut says they will only partially get cleaned up. Consider: Cast.isJavaObject(foo) ? foo.method() : Jso$foo$method(); Maybe that pass is simply generating the wrong code. I'm not saying this, by itself, would work, but maybe the right solution involves generating something like: (foo instanceof JavaScriptObject) ? JsoFoo.$method(foo) : foo.method() So that dead code can optimize the instanceof test at some point. Or, maybe we should leave the call site alone initially... If we model the JSO method as having an upref to the interface method, CFA and TypeTightener might do the right things implicitly, then we modify the appropriate optimizer pass to convert the interface call into the JSO direct call if that's the only viable option. Then we add the appropriate logic to JsoDevirtualizer to handler this post-optimization for cases that still exist. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make SOYC produce consistent output (issue1338805)
Yes, it directly affects SOYC output; it causes tons of useless clinit dependencies on interfaces to get recorded, when in reality there is no actual method in the output. On Fri, Feb 4, 2011 at 2:18 PM, b...@google.com wrote: Did you mean to include the clinit fixes in this patch? http://gwt-code-reviews.appspot.com/1338805/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Remove useless templatization from JS AST. (issue1310805)
Sure thing. The original intent was that JsContext would get parameterized with the compatible node type. So all JsExpression subclasses used a JsContextJsExpression, which means, essentially, I can be replaced only with other expressions. There was a tiny amount of usefulness in being able to see this statically. In practice though, it's too much crazy futzing with generics. You'll get a ClassCastException at runtime anyhow if you screw something up, and our test coverage is really good these days. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds option to override JsInliner's max complexity ratio heuristic with JVM property 'gwt.jsinli... (issue1341802)
SGTM. Call it gwt.js.inlinerRatio maybe? There's wiki page somewhere that has all the existing ones... there's probably a pattern that will emerge. (And yours should be added.) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Adds accessibility to certain GWT AST nodes (issue1304802)
I don't have anything great written up, but here's the gist of it: Currently, when you do a web mode compile, JDT actually runs twice. First, it runs from CompilationStateBuilder and compiles all the source code in your project. The output of this is used to build TypeOracle, which is a reflection-like view of your type model, used by Generators. This output is also used for running dev mode. After all this is done and the JavaToJavaScriptCompiler starts to run, it actually fires up a second JDT compile-- this recompiles your source files into one giant, interconnected GWT AST. The change I'm working on would cut this down to one JDT compile. During CompilationState's build, the plan is to analyze each independent unit (compiled .java file) and produce one partial, disconnected AST per compilation unit. Then when it's time to kick off the compiler, we just grab those independent ASTs and stitch them together, resolving all references to create the interconnected AST. This should hopefully cut down on compile time, especially for draft compiles. It would also enable us to do a few more tricks in the future, such as caching compiled .ast files on disk, or even embedded precompiled .ast files into, say, gwt-user.jar so we don't have to recompile the source files included with GWT. On Wed, Jan 26, 2011 at 2:59 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: It looks like you are working on something that might be interesting to me. Is there any place I can find more information on this change? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add JREIndex optimization to JdtCompiler (issue1318802)
I plan to kill AbstractCompiler soon :D -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Adds accessibility to certain GWT AST nodes (issue1304802)
No hard commitments, but I'm looking on the order of a month or thereabout. On Wed, Jan 26, 2011 at 3:25 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: Thanks Scott for this. It's enough for me to understand motivation and (at least some) implications of this change. This is something which is certainly within my interest. Actually, what you described is exactly what I wanted to see for a long time. I parse jribble nodes twice for exactly the same reason you are running jdt twice. When do you plan to finish work on this? It looks like it's a time for me to catch up with GWT's trunk in my scalagwt fork. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add JREIndex optimization to JdtCompiler (issue1318802)
Point taken; I killed the old one and made it reference the new one. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Remove list of JavaScriptException object properties when compiler.stackTrace = emulated (issue1310802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Fix handling of null passed into varargs (issue1309801)
Is that SGTM or LGTM? I uploaded a patch. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: [GWT Designer] Memory leak in ResourceOracleImpl (issue1308801)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: DevMode generates a default web.xml when servlet tags are present and no web.xml exists. (issue1266801)
That seems good to me as a mid-term goal. Wouldn't this still be a useful stop-gap moving in that direction but with the current servlet spec? On Fri, Jan 7, 2011 at 1:41 PM, Toby Reyelts to...@google.com wrote: It sounds to me as if we should be integrating with the facilities in Servlet 3.0, since it has been final now for over a year. Specifically see: Section 4.4: Configuration methods - An API to add and configure servlets, filters, and listeners at runtime. Chapter 8: Annotations and Pluggability - Capabilities for configuring web.xml behavior piecemeal through annotations and web.xml fragments separate from web.xml On Fri, Jan 7, 2011 at 1:21 PM, John Tamplin j...@google.com wrote: On Fri, Jan 7, 2011 at 1:11 PM, zun...@google.com wrote: I don't see any problem with the code. Is this really something we want to happen by default? I'm concerned it will be baffling to a user why a web.xml gets created only some of the time. It seems to me that an external tool that could parse xml could create such a file if it was needed without too much work. There's nothing in here that couldn't be done in a python script with access to the module files. I think we lost useful functionality when we lost the ability to put servlet tags in a module (think about a self-contained module that contains client code and the servlet needed for the server-side piece - it would be nice to just inherit it and it works, such as for server-side script selection). Should we reconsider the decision to have web.xml authoritive and instead have a template which is used to generate the web.xml file? If there is already a web.xml file, we keep the behavior of today, and if not then we are always generating a web.xml file, whether from web-template.xml (or whatever) or creating a default one if the user didn't supply one. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds a unit test for the TypeOracleMediator that feeds byte code instead of source. (issue1254801)
On Wed, Jan 5, 2011 at 2:13 PM, zun...@google.com wrote: On 2011/01/05 18:59:02, scottb wrote: LGTM, I think. What is that supposed to mean?!? Sorry, it means I didn't scrutinize this to the Nth degree, just looked over it at a high level. I assume all the new units are being moved from code snippets embedded in exist test code? More or less. The only difference I remember are the names, and that there are some types that were embedded in the same compilation unit that I moved to be separate types in order to make the CheckedJavaResource to bytecode mapping work without many changes. The snippets are actually copied - the compiler gets run on the .java files to make byte code. The constant strings in the TypeOracleMediatorTestBase.java still get used when the TypeOracleMediatorFromSourceTest gets run. I wasn't sure how to get both byte code and the body of the .java file at run time. Ahh... that's what I was concerned about. Having two versions of the source seems bad. Do you plan to remove the TypeOracleMediatorFromSourceTest in the near future, or will they exist side by side indefinitely? If it's the latter, it's worth mentioning that some of our tests do require test source code to be on the classpath to run, so we could make the Java files canonical. I did work hard to land this in multiple patches. I changed the names of some of the identifiers because I just couldn't keep track of names like Class1, Class2, ... which got mapped onto different CheckedJavaResource identifiers. Do you want me to un-sort the file? No no, I was just explaining why I was being less thorough. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] A couple of questions before getting started
On Thu, Dec 2, 2010 at 1:35 PM, Luis Solano luissolan...@gmail.com wrote: I have checked out the trunk and configured my eclipse as said here: http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt . I have set the checkstyle and the error/warning configuration and then imported the gwt-user and gwt-dev projects. The problem is that I get 33 checkstyle problems and 3314 Java Problems (all warnings and the first 100 are raw type warnings) in revision 9344. is this ok? if yes, should this warnings be solved? And just in case, it's ok to send patches with warnings? (I guess the answer is NO) It's sort of a known-issue broken-window. Some of them stem from third-party code that has come into GWT, such as Rhino or ASM. Removing warnings in original GWT code is generally a Good Thing. The other question is about the workspace encoding. I'm on a mac. Should I leave the MacRoman encoding for my workspace or should I change it to another like utf-8? All GWT java source is UTF-8, so definitely use that. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Factors out TypeOracleMediator.computeBinaryClassName() into a separate class file. (issue1144801)
Like, LGTM++ On Wed, Dec 1, 2010 at 7:12 PM, zun...@google.com wrote: On 2010/12/01 16:03:22, scottb wrote: Perfect! Is that perfect as in, Sounds great I'll look at it later! or LGTM? http://gwt-code-reviews.appspot.com/1144801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Factors out TypeOracleMediator.computeBinaryClassName() into a separate class file. (issue1144801)
Works for me. On Mon, Nov 29, 2010 at 6:43 PM, Eric Ayers zun...@google.com wrote: how about SerializationUtils.getRpcTypeName() On Mon, Nov 29, 2010 at 4:53 PM, Scott Blum sco...@google.com wrote: On Mon, Nov 29, 2010 at 2:50 PM, zun...@google.com 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
Re: [gwt-contrib] Fix permgen exhaustion due to classloader memory leak across server refresh. (issue1097801)
-Restart the server, not just the WebAppContext, on refresh Can you be more specific in the change description when you submit? Like: - On server restart, restart the whole Jetty server, not just the WebAppContext. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics
Hmmm what happens if you turn down the log level, say to WARN? Are you invoking from the command line, or are you using the Google Plugin for Eclipse? On Wed, Nov 10, 2010 at 4:16 PM, yves yves.ko...@gmail.com wrote: Scott, Thx for the tip. Anyway I can't allocate more than -Xmx1590M and I get exactly the same error. Yves On 9 nov, 07:47, Scott Blum sco...@google.com wrote: Hmm can you increase your virtual memory? On Mon, Nov 8, 2010 at 5:13 PM, yves yves.ko...@gmail.com wrote: I can't, I only have 2GB RAM, I get this error as from -Xmx1024M [java] Error occurred during initialization of VM [java] Could not reserve enough space for object heap [java] Could not create the Java virtual machine. and the log level is INFO Yves On 8 nov, 22:53, Scott Blum sco...@google.com wrote: What if you turn the heap up to -Xmx2048M? What log level are you using? On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com wrote: Hi, I had a class named ResultNode and the project compiled fine. In order to improve the code, I changed this class by adding generic stuff like that : ResultNodeT extends ResultNode?. Of course I adapted the entire project where needed to take advantage of this change. Now I get an Internal compiler error This is produced with java memory settings -Xmx768M and -Xss32M . (usually the settings are -Xmx128M and default value for -Xss and I never had such problem). BTW : a javac compilation on the project is succesfull, so it is not a java error. Any suggestion ? If more information is needed do not hesitate to ask. Thanks in advance Yves [java] Compiling module com.mycompany.myproject.MyProject [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/ src/com/mycompany/myproject/client/model/AppActivityMapper.java' [java] [ERROR] Internal compiler error [java] java.lang.OutOfMemoryError: Java heap space [java] at java.util.Arrays.copyOf(Arrays.java:2882) [java] at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java: 100) [java] at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) [java] at java.lang.StringBuilder.append(StringBuilder.java:119) [java] at com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java: 59) [java] at com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java: 126) [java] at com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 939) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java
Re: [gwt-contrib] Internal compiler error with GWT 2.1.0 RC1 when using generics
What if you turn the heap up to -Xmx2048M? What log level are you using? On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com wrote: Hi, I had a class named ResultNode and the project compiled fine. In order to improve the code, I changed this class by adding generic stuff like that : ResultNodeT extends ResultNode?. Of course I adapted the entire project where needed to take advantage of this change. Now I get an Internal compiler error This is produced with java memory settings -Xmx768M and -Xss32M . (usually the settings are -Xmx128M and default value for -Xss and I never had such problem). BTW : a javac compilation on the project is succesfull, so it is not a java error. Any suggestion ? If more information is needed do not hesitate to ask. Thanks in advance Yves [java] Compiling module com.mycompany.myproject.MyProject [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/ src/com/mycompany/myproject/client/model/AppActivityMapper.java' [java] [ERROR] Internal compiler error [java] java.lang.OutOfMemoryError: Java heap space [java] at java.util.Arrays.copyOf(Arrays.java:2882) [java] at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java: 100) [java] at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) [java] at java.lang.StringBuilder.append(StringBuilder.java:119) [java] at com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java: 59) [java] at com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java: 126) [java] at com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 939) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at
Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics
Hmm can you increase your virtual memory? On Mon, Nov 8, 2010 at 5:13 PM, yves yves.ko...@gmail.com wrote: I can't, I only have 2GB RAM, I get this error as from -Xmx1024M [java] Error occurred during initialization of VM [java] Could not reserve enough space for object heap [java] Could not create the Java virtual machine. and the log level is INFO Yves On 8 nov, 22:53, Scott Blum sco...@google.com wrote: What if you turn the heap up to -Xmx2048M? What log level are you using? On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com wrote: Hi, I had a class named ResultNode and the project compiled fine. In order to improve the code, I changed this class by adding generic stuff like that : ResultNodeT extends ResultNode?. Of course I adapted the entire project where needed to take advantage of this change. Now I get an Internal compiler error This is produced with java memory settings -Xmx768M and -Xss32M . (usually the settings are -Xmx128M and default value for -Xss and I never had such problem). BTW : a javac compilation on the project is succesfull, so it is not a java error. Any suggestion ? If more information is needed do not hesitate to ask. Thanks in advance Yves [java] Compiling module com.mycompany.myproject.MyProject [java][ERROR] Errors in 'file:/C:/java/workspace/MyProject/ src/com/mycompany/myproject/client/model/AppActivityMapper.java' [java] [ERROR] Internal compiler error [java] java.lang.OutOfMemoryError: Java heap space [java] at java.util.Arrays.copyOf(Arrays.java:2882) [java] at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java: 100) [java] at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) [java] at java.lang.StringBuilder.append(StringBuilder.java:119) [java] at com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java: 59) [java] at com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java: 126) [java] at com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 939) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable(SerializableTypeOracleBuilder.java: 1107) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 977) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java: 1412) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java: 1219) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java: 1309) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java: 1011) [java] at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkArrayInstantiable
[gwt-contrib] Re: Modifies the GWT compiler sharded entry points to support an alternative (issue1074801)
On Thu, Nov 4, 2010 at 4:57 PM, zun...@google.com wrote: A second entry point for compile makes a lot of sense - and maybe for CompilePerms too. Keep looking and tell me what you think. I'm thinking of these names: PrecompileOnePerm for the new precompile entry point. CompileOnePerm for the new compile perms entry point I'm liking these. Is it really exactly one, though? Maybe PrecompileSpecificPerms would be closer to the mark? I'd like to see how this shakes out. I definitely think Precompile wants to be split. Less sure that CompilePerms and Link actually need to be split. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds an -XcompilerMetrics flag to the compiler. This will (issue1045801)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RPC using getCause instead of getTarget
My JDK says:
*Throwable java.lang.reflect.InvocationTargetException.getTargetException()*
Get the thrown target exception.
This method predates the general-purpose exception chaining facility. The
Throwable.getCause() method is now the preferred means of obtaining this
information.
Returns:
the thrown target exception (cause of this exception).
On Fri, Oct 22, 2010 at 3:48 PM, Sebastian use...@laliluna.de wrote:
Hi,
the RPC.java has a method public static String
invokeAndEncodeResponse which does catch an InvocationTargetException
and tries to encode the error.
Here a snippet:
catch (InvocationTargetException e) {
// Try to encode the caught exception
//
Throwable cause = e.getCause();
responsePayload = encodeResponseForFailure(serviceMethod, cause,
serializationPolicy, flags);
}
return responsePayload;
The disadvantage is that the information about the exception is
actually in e.getTarget. As a consequence no detailed are carried to
the server. It indicates the normal error on server message.
e.getCause is null.
Is there any motivation behind using the e.getCause or is this
actually a bug.
Best Regards
Sebastian Hennebrueder
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Reformulate RPC generated TypeHandlers to create fewer classes. (issue1037801)
Well, I had to pick something that wouldn't conflict with the names of the established static methods. My names are pretty lame. Suggestions? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Prevent non-null null types from appearing. (issue1028801)
Hmm... not really sure how to recreate it. :/ On Mon, Oct 18, 2010 at 7:19 PM, con...@google.com wrote: On 2010/10/18 22:52:22, scottb wrote: perhaps we should add a test for this too? http://gwt-code-reviews.appspot.com/1028801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: DeadCodeElimination should only run once. (issue983802)
On Wed, Oct 13, 2010 at 2:39 PM, Eric Ayers zun...@google.com wrote: This is good, it confirms that the number of changes to the AST hasn't changed (or haven't changed much). I was thinking of the speedtracer logs which would show a change in the real-time performance of each pass the optimizers. (re-run with -Dgwt.speedtracerlog=/tmp/speedtracer-trunk.html ) I did that first, but I found the results kind of hard to understand for the particular application relative to using the logs. Lemme put a bit more effort in. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: DeadCodeElimination should only run once. (issue983802)
Okay, so when I drill down, optimization is net faster with my patch. A typical example, on one particular optimize loop, before DCE would take ~15-20ms, but with my patch more like ~7-15ms. On the down side, MethodInliner seems very slightly slower, but it appears to be a decent net win. On Wed, Oct 13, 2010 at 2:46 PM, Scott Blum sco...@google.com wrote: On Wed, Oct 13, 2010 at 2:39 PM, Eric Ayers zun...@google.com wrote: This is good, it confirms that the number of changes to the AST hasn't changed (or haven't changed much). I was thinking of the speedtracer logs which would show a change in the real-time performance of each pass the optimizers. (re-run with -Dgwt.speedtracerlog=/tmp/speedtracer-trunk.html ) I did that first, but I found the results kind of hard to understand for the particular application relative to using the logs. Lemme put a bit more effort in. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: DeadCodeElimination should only run once. (issue983802)
On Tue, Oct 12, 2010 at 4:07 PM, zun...@google.com wrote: FYI, I like the refactoring of JModVisitor Thanks! I have no idea how you came up with these changes other than to pick up a huge piece of code and start setting break points in the compiler and iterating until you fixed them. That's a difficult tasks for mere mortal coders to repeat. I actually just added a 'passes' field to DeadCodeElimination, and incremented it each pass through the while loop. Then I removed all the direct increment field accesses in JModVisitor and forced them to all call the madeChanges() method, which I then override, and set a breakpoint / did a System.out.println when passes 1. That shook things out fairly quickly. I'm working on patches for some other visitors using the same technique. At the very least, the DeadCodeEliminationTest needs a TODO for someone to add new test() methods for the types of things you found that took more than one pass to resolve. Will do, thanks. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
Is this in dev mode or prod mode? Do the tests succeed if you run them
individually?
On Thu, Sep 30, 2010 at 7:54 PM, Damon Lundin damon.lun...@gmail.comwrote:
We are trying to upgrade from 2.0.4 to 2.1.0.m3 because of some bugs
in 2.0.4 but in doing so our GWT test cases have begun failing and I
have determined it's because the next test is beginning before the
previous one is complete and they are messing each other up. I know
that delayTestFinish is meant to allow for tests to make use of async
calls and it's been working for us but now it's not.
We have a number of tests that roughly look like this:
public void test03 {
delayTestFinish(12);
rpcService.someServerCall(new AsyncCallback() {
public void onSuccess() {
// Do some stuff
DeferredCommand.addCommand(new Command() {
public void execute() {
// More stuff
finishTest();
}
}
}
}
}
public void test04 {
delayTestFinish(12);
...
}
Our code actually uses DeferredCommands in a long chain of calls but
in short, test04 begins executing before we call finishTest() in the
previous test and I don't think that's supposed to happen.
I could further debug this if someone could explain to me what
implemented in the translatable version of this class means and how
I would debug this translatable version. Any advice on how to
proceed?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
Ok, that's pretty strange, but there is a way to debug. - Unzip gwt-user.jar somewhere. - Inside where you extracted it, there should be a folder com/google/gwt/junit/translatable/ - Go edit your launch config and add that folder to the Source Lookup Path, under the Source tab, Add. a File System Directory, and select that folder named translatable. Move it UP above the default path. - Put a breakpoint where you call delayTestFinish() - Launch You should now be able to step into delayTestFinish() and/or step out of your test method and see what the client code is doing. On Fri, Oct 1, 2010 at 11:13 AM, Damon Lundin damon.lun...@gmail.comwrote: On Oct 1, 9:11 am, Scott Blum sco...@google.com wrote: Is this in dev mode or prod mode? Do the tests succeed if you run them individually? This is in dev mode. If I disable all of the tests and run them individually they all pass. I've never tried running tests in prod mode but I think I know how and I can give that a try. The next thing to try as well would be to chain all the test methods together. So instead of having test01...testN, I can have the end of test00 start test01 and the end of test01 start test02, etc. Of course that's problematic if a test fails, the next one won't run. And if the delayTestFinish isn't working, the whole thing might just stop before it gets all the way through. But something to try. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
It sounds like the problem really boils down to less-than-useful stack traces when a native exception is thrown in Dev mode. Ironically, if you ran this in Prod mode, you'd probably get a better stack trace, because we emulate the stack over there. We could probably implement the same sort of stack trace emulation feature in Dev mode + some other stack cleanup to make the exception traceback much nicer. CC'ing Kelly so he can see about prioritizing this. On Fri, Oct 1, 2010 at 1:00 PM, Damon Lundin damon.lun...@gmail.com wrote: Thanks for the help Scott. The problem is not with the delayTestFinish. Apparently our tests are throwing uncaught exceptions which causes the test to finish. The exception does appear in our logs, but it's one of these: Caused by: com.google.gwt.core.client.JavaScriptException: (Error): Unspecified error. number: -2147467259 description: Unspecified error. at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: 237) Which are not terribly useful (if you have any useful suggestions on dealing with these, I'm all ears) so I moved on to the next exception which was an NPE in our code. That NPE is caused by the tests running on top of each other. So I guess this was my fault for not paying closer attention to the first exception. There is perhaps one possible recommendation that could come out of this and maybe that is that when a test begins (or finishes) it cancels all outstanding timers, commands and pending async callbacks (perhaps optionally). The confusion occurred here because even though the previous test threw an uncaught exception and finished allowing the next test to begin, the outstanding commands started by the previous test were still allowed to run and when they did, they messed up the shared state used by the next test. Of course now I have to go figure out what's causing this uncaught exception to be thrown :-(. And I'm also still confused why the tests pass when run one at a time. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Remove misleading change record from MethodInliner. (issue934801)
It is the last reference to the (int) version. There are refs to the no-arg version in my copy. I can definitely remove it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Remove the output from the link step before attempting to (issue928801)
I'm also not sure this is a bug. If it's set read-only, why would we try to clobber it? On Tue, Sep 28, 2010 at 11:18 AM, fabb...@google.com wrote: Assuming we like the concept, I have two issues noted here. At the larger level, people should be doing this today in e.g. build.xml as a wrapper, which also works... I'm not sure whether I'd be more annoyed to fail on existing dirt, or to have something I'd tried to preserve be overwritten. The first, however, is annoying; the second is potentially costly! http://gwt-code-reviews.appspot.com/928801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: If Java optimizers are not run to full completion (part of another proposed patch), (issue897803)
This actually gives me pause. What kind of code can leave primitives on one side but not the other? I'm concerned because in Java, I think this should be true: Integer.valueOf(1) == 1 Because the RHS gets autoboxed. If we're translating this as-is into JS triple-equals without boxing it, the test would fail. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Guidance needed: unit tests and TypeOracle, ModuleDefLoader vs. CompilerStateBuilder
What Bob said. You can write much, much faster unit tests using just CompStateBuilder, since it's easy to build a very small world that only contains just what you need. If you don't care about speed, it's probably less work to go with ModuleDefLoader. Some of the UiBinder tests are really great examples of the pattern. On Tue, Sep 14, 2010 at 9:07 AM, BobV b...@google.com wrote: I've noticed that c.g.g.editor.rebind.model.EditorModelTest has a nested RealJavaResource class that reads a Java file from the classpath so you can use an existing class with CompilerStateBuilder. This is similar to what ModuleDefLoader would do, just without the super-source override. It'd solve the @Annotation issue, but it's currently a nested class in a particular test, i.e. not something to be reused in other tests. If you wind up using ModuleDefLoader, it will be easy to wind up pulling in all of User.gwt.xml, which would really slow the test down. The helper classes in EditorModelTests are private only because I didn't have a lot of time to think about how to turn them into a good public API. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds a -strict option to the GWT compiler. If this option is specified, (issue853801)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds a -strict option to the GWT compiler. If this option is specified, (issue853801)
High-level comments: - CompilationState doesn't really need the extra API, because you can always just iterate through the returned collection looking for errors. Arguably, this would take a few extra cycles, but I've kinda been wanting to move the error reporting out CompilationState anyway and let the callers handle it, which would eliminate the extra cost since we'd have to loop through reporting errors anyhow. - On the test class, it might be easier to just check a Good and Bad module into dev/test instead of mucking around with temp dirs and class loaders. This is the pattern we use for TypeOracleTest.gwt.xml, and One.gwt.xml, for example. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enum name obfuscation option. Addresses issue 2387369 (issue827802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Public: Modify checkstyle config to allow formating of Fluent style builders (issue812801)
Will our Eclipse formatter settings respect this? Or will it auto-format such a construct into something else? On Mon, Aug 30, 2010 at 1:53 PM, ncha...@google.com wrote: On 2010/08/30 17:51:52, rjrjr wrote: LGTM Nice, thanks. You're sure this works with the checkstyle 4.whatever we're still using? On 2010/08/30 17:22:28, Nick Chalko wrote: I tested it locally on my laptop. cd .../user; ant checkstyle and the smoke tests pass. http://gwt-code-reviews.appspot.com/812801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: CurrencyList now uses pure Java in dev mode. (issue771803)
On Thu, Aug 26, 2010 at 9:40 PM, j...@google.com wrote: Hmm, the code is fine, but the property files aren't. If you remove all but AUD and USD from the CurrencyData_en_AU.properties file, you can see the generated CurrencyList_en_AU.java contains only the modified values. I'll work on updating the properties files next week. I could swear I remember looking at generated files and verifying it, but maybe those were never checked in. Still, shouldn't the generator be able to detect the dups at generation time? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: CurrencyList now uses pure Java in dev mode. (issue771803)
On Fri, Aug 27, 2010 at 11:21 AM, John Tamplin j...@google.com wrote: Why do that every time you run the generator rather than once when you import the CLDR data? Oh, you know what, I kind of forgot that we're the only ones who actually implement currency list. Which actually brings up another interesting point... why have a generator at all? Why not have the CLDR data importer produce static java files one time? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Always use unix-style line endings in Generators. (issue776803)
On Fri, Aug 20, 2010 at 2:25 PM, b...@google.com wrote: Change LGTM, but why is this a problem in practice? Isn't the generated source transient? It is, except when you use the -gen flag because you actually want to see the generated output. What I was seeing is that, in some cases, the line endings wouldn't even be consistent within the same file! Parts of it that were generated by one subsystem would be one way, and some nested code generated in a temp buffer in another subsystem would be the other. Fixing this gets rid of some annoying diff behavior when comparing generator outputs. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: TypeOracle transitive invalidation based only on API types (issue775804)
On Thu, Aug 19, 2010 at 11:41 AM, kplatf...@google.com wrote: Why do we no longer visit annotation types? We visit annotation types; what we don't visit is annotation elements on other types. IE, we don't visit the @Override on a method. The reasoning has to do with how the actual dependencies work in TypeOracle. As it turns out, there's no reference from a JClassType or JMethod to the JAnnotationType that happens to be annotating it. Instead, it's modeled using java.lang.Class and AnnotationProxies. So for the purpose of constructing a well-formed TypeOracle, the ability to resolve a JAnnotationType for @Override is totally incidental to resolving a method that happens to be annotated with it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Report CompilationState errors deterministically. (issue773802)
Not exactly. I was trying to figure out *why* my patch broke the test, and the non-deterministic error reporting made it very difficult to compare the logs. I have a fix for the other issue (review coming soon), but this seemed like a useful partial. On Wed, Aug 18, 2010 at 4:16 PM, kplatf...@google.com wrote: LGTM. Is this designed to fix the test broken by issue 756802 (Change to CompilationStateBuilder to prevent recursive invalidation on changed units)? http://gwt-code-reviews.appspot.com/773802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
On Thu, Aug 12, 2010 at 10:21 AM, b...@google.com wrote: @Scott, Do you have any further input on the implementation changes to the JS runtime in the patch as it stands (modulo any future optimizations)? No further comments, beyond what you said. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
On Wed, Aug 11, 2010 at 12:56 PM, jbrosenb...@google.com wrote:
I think this makes sense, and would reduce the size of the generated
code, e.g. [12,35,123] vs. {12:1,35:1,123:1}. The Cast.canCast()
methods would have to iterate through the array explicitly to test for
existence though, instead of a simple object property lookup. Thoughts?
RayC suggested something similar as well.
Hmm, dunno. The generate size won't change much after compression, I'd
guess. Hate to have to introduce an O(n) lookup there, but the only way to
know for sure if it's a win would be to test it in real apps. My suggestion
of int[] was actually based on the current data structure. Even though that
looks like Object literal syntax, for practical purposes it could
theoretically be treated as a sparse int[]. But that change wouldn't add
anything to your patch except perhaps readability.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: GWT Development shell no longer cuts off the Launch Default Browser and Copy to Clipboard (issue758801)
This should be jat. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] devmode classloader retention
Thanks so much for digging into this, Stephen. @John, Bob, Ray: can you guys take a look at this and maybe create yourselves issues? It seems like this is a real performance issue, with the user ending up in sluggish performance or else having to restart DevMode, which is certainly slower than refresh. On Tue, Aug 10, 2010 at 1:32 AM, Stephen Haberman step...@exigencecorp.comwrote: Is the number of JRealClassType instances just going up and up each refresh? Yep. I didn't explicitly check until you asked, but comparing heap diffs before/after multiple refreshes, each refresh was adding ~1800 new JRealClassTypes that never went away. Can you figure out who is holding references to them (referrants)? Turns out I can. Thank you for the rather logical suggestion--I had looked at the GC root paths and, once I saw AppClassLoader, had given up thinking it was going to be an PITA classloader issue. But, no, its just some static caches. It took a few tries, but the attached patch fixes the leaks and I can now run my whole test suite and DevMode stays snappy. Note that I use the term fixes very loosely as: * ResourceFactory.cache just needs a WeakHashMap, pretty easy * OwnerFieldClass.FIELD_CLASSES needs a hash map that is weak on both keys and values. Or some way to explicitly clear the values when the TypeOracle is done with. I tried a WeakHashMap and it was not enough as the OwnerFieldClass value is what holds the JRealClassType reference. What did work, was a stupid, ugly hack of clearing the cache on each new oracle seen (which is a bad idea, it would break multiple clients use DevMode concurrently, but it proved the point). * AbstractResourceContext.CACHES is already a WeakHashMap, however, the values end up being IdentityHashMaps with JRealClassTypes keys, which reference the oracle, so, contrary to the javadoc, it does actually keep TypeOracles from being GC'd. The same ugly hack from issue 2 also solved this final one. As my hacks obviously show, I don't know of a good way to deal with the 2nd or 3rd issues. If you have a suggestion, I can try and run with it, but I'd also be just fine with someone more knowledgeable about the codebase finding an elegant solution. :-) Thanks! - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: When dev mode fails to load a module, update the $wnd.title with a summary of the (issue750802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
