[gwt-contrib] [google-web-toolkit commit] r4344 - in trunk/dev/core/src/com/google/gwt: core/ext/linker core/ext/linker/impl core/linker/so...
Author: kpro...@google.com
Date: Mon Dec 15 18:47:24 2008
New Revision: 4344
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
trunk/dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java
trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
Log:
Added functionality to map runAsync split points and fragment numbers to
the methods that they are placed in. This information is accessed by SOYC
and displayed in the SOYC dashboard.
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
Mon Dec 15 18:47:24 2008
@@ -21,6 +21,7 @@
import com.google.gwt.core.ext.soyc.Range;
import com.google.gwt.core.ext.soyc.Story;
+import java.util.Map;
import java.util.SortedSet;
/**
@@ -74,6 +75,11 @@
* Ranges, plus the overhead of constructing an ordered Map.
*/
public abstract Iterable getSnippets(int fragmentNumber);
+
+ /**
+ * Returns splitPointMap.
+ */
+ public abstract Map getSplitPointMap();
/**
* Returns all Stories.
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
Mon Dec 15 18:47:24 2008
@@ -55,6 +55,7 @@
import java.util.Set;
import java.util.SortedSet;
import java.util.Stack;
+import java.util.TreeMap;
import java.util.TreeSet;
/**
@@ -115,17 +116,25 @@
private transient Map membersByCorrelation = new
IdentityHashMap();
/**
+ * Map from split point numbers to the method where they were set
+ */
+ private Map splitPointMap = new TreeMap();
+
+ /**
* Constructed by PermutationCompiler.
*/
public StandardCompilationAnalysis(TreeLogger logger,
- List> sourceInfoMaps)
+ List> sourceInfoMaps,
+ Map splitPointMap)
throws UnableToCompleteException {
super(StandardLinkerContext.class);
logger = logger.branch(TreeLogger.INFO,
"Creating CompilationAnalysis (this may take some time)");
data = new Data();
-
+
+this.splitPointMap = splitPointMap;
+
/*
* Don't retain beyond the constructor to avoid lingering references
to AST
* nodes.
@@ -197,6 +206,11 @@
};
}
+ @Override
+ public Map getSplitPointMap(){
+return splitPointMap;
+ }
+
@Override
public SortedSet getStories() {
return data.stories;
Modified:
trunk/dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java
==
---
trunk/dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java
Mon Dec 15 18:47:24 2008
@@ -65,7 +65,6 @@
@LinkerOrder(Order.PRE)
public class SoycReportLinker extends AbstractLinker {
- int curNumIndents = 0;
public String escapeXml(String unescaped) {
String escaped = unescaped.replaceAll("\\&", "&");
@@ -161,32 +160,29 @@
if (methodAliases.size() > 0) {
htmlOut.indentIn();
htmlOut.indentIn();
- curNumIndents++;
curLine = "";
- htmlOut.printRawOpt(curLine);
- htmlOut.newlineOpt();
+ htmlOut.printRaw(curLine);
+ htmlOut.newline();
htmlOut.indentIn();
htmlOut.indentIn();
- curNumIndents++;
}
for (String methodAlias : methodAliases) {
curLine = "";
- htmlOut.printRawOpt(curLine);
- htmlOut.newlineOpt();
+ htmlOut.printRaw(curLine);
+ htmlOut.newline();
}
if (methodAliases.size() > 0) {
htmlOut.indentOut();
htmlOut.indentOut();
- curNumIndents--;
-
+
curLine = "";
- htmlOut.printRawOpt(curLine);
- htmlOut.newlineOpt();
+ htmlOut.printRaw(curLine);
+ htmlOut.newline();
htmlOut.indentOut();
htmlOut.indentOut();
- curNumIndents--;
+
}
}
@@ -205,7 +201,7 @@
for (String className : sortedClasses.keySet()) {
ClassMember classMember = sortedClasses.get(className);
curLine = " 0) {
htmlOut.indentIn();
htmlOut.indentIn();
- curNumIndents++;
curLine = "";
- h
[gwt-contrib] Re: RR : Make runAsync split point information accessible to SOYC
Thank you! Committed as revision 4344. kathrin On Mon, Dec 15, 2008 at 6:08 PM, Lex Spoon wrote: > > On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst wrote: >> Hi Lex, >> >> I've made all the changes you requested except the first, which we >> have decided not to do for now (reason: SourceInfo does not contain a >> pointer to the node, so instead we would have to keep JMethod around >> until link time, which seemed overkill). >> >> Please let me know what you think. > > LGTM. > > Lex > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Looking for Incubator sponsor for AxisPanel (2nd try)
Sony, even if this doesn't make it into the incubator there is nothing
stopping you from placing it in your own Google Code project and publicizing
it here and on users. I imagine there are a lot of DSL fans out there who
might be interested.
rjrjr
On Tue, Dec 16, 2008 at 9:29 AM, Sony wrote:
>
> For more info on this topic refer to my Article: Fluent DSL for Rich
> UI
> on theServerSide.com:
> http://www.theserverside.com/news/thread.tss?thread_id=52241
> on my blog:
> http://sonymathew.blogspot.com/2008/12/fluent-dsl-for-rich-ui.html
>
> Thanks
> Sony
>
>
> On Oct 27, 11:55 am, Sony wrote:
> > dflorey, Isaac
> > Thank you for your comments. First off, I want to make sure I am
> > going about this the right way. Was I supposed to post AxisPanel
> > myself or wait for a reply from a sponsor? I didn't join the group
> > itself till after my 2nd email attempt. Thanks again for posting this
> > for me.
> >
> > Regarding: IDE Formatting:
> > Good point - but to me the gain in readability with the manual
> > indentation is worth not auto formatting select packages. Most people
> > use manual indentation anyways and resort to Auto formatting when
> > files are checked in.
> >
> > Regarding: Unconventional method names:
> > I expected this to be the main opposition from the GWT team. See
> > Martin Fowler's DomainSpecificLanugage and FluentInterfaces. Some
> > would argue against the conventional setter/getter/add method names
> > for a complex domain. What I have used is a Domain-Specific-Language
> > (DSL) or a Fluent Interface (language within a language) to handle the
> > complex domain of UI layouts.
> > --
> > Checkout Martin Fowler's entries.
> http://www.martinfowler.com/bliki/DomainSpecificLanguage.htmlhttp://www.martinfowler.com/bliki/FluentInterface.html
> > --
> > I would in-fact argue that using Fluent layouts all-around would
> > benefit GWT greatly and bring about even greater usage - such Fluent
> > layouts could out-do any framework with XML or HTML layouts if
> > properly supported.
> >
> > Regarding: Just a helper class, no advantage over exiting panels:
> > Yes, AxisPanel can be viewed as a helper class - nothing too
> > innovative. The innovative parts if any are: 1) combining Vertical/
> > Horizontal layout concepts under one hood to create a very powerful
> > layout in my experience - capable of laying out almost any complex
> > layout needs and 2) providing a succinct readable DSL ("Fluent
> > language within a language") for almost any complex layout needs.
> > --
> > I would in-fact argue against the need for several layout panels
> > existing in GWT today - they could all be replaced with one
> > AxisPanel. I would like to push this same concept out to Swing as
> > well - where layouts can be quite cumbersome.
> >
> > Regarding: GXT BorderLayout,
> > The GXT BorderLayout you linked to is fantastic - especially the nifty
> > pin/collapse functionality for each border panel. I would have coded
> > a border layout quite quickly as follows: (without the nifty pin/
> > collapse of-course)
> >
> > AxisPanel p = new AxisPanel()
> > .y().width("100%")
> > .x(new ContentPanel()).css("north").width("100%").q()
> > .x().width("100%")
> > .y(new ContentPanel()).css("east").width("25%).q()
> > .x(new ContentPanel()).css("center").width("50%).q()
> > .y(new ContentPanel()).css("west").width("25%).q()
> > .q()
> > .x(new ContentPanel()).css("south").width("100%").q()
> > .q()
> >
> > Also consider: a different version: PinAxisPanel
> > Say PinAxisPanel had a Fluent AxisPanel like interface with properties
> > like collapse(true) (why restrict to just the border layout, any Panel
> > could be made Pinnable/Collapsible). I think this would be even more
> > fabulous.
> >
> > Also consider: if layout requirements changed:
> > Say the business wants to split the contents of the south panel into 3
> > parts and move them adjacent to the contents of the east, center and
> > west panels respectively (perhaps inside them place them at the top,
> > center, and bottom respectively) and add different styling and so on.
> > If my south panel's contents were laid out using the same AxisPanel in
> > the same expression (instead of new ContentPanel()) - I could easily
> > move the contents around until I obtained the right look and results -
> > rather than creating new wrapper panels with new variable names,
> > changing panel insertions etc. Overall readability of my layout is
> > easily grasped and modified.
> >
> > I'll chill, you relax, we'll just chillax,
> > Sony
> >
> > On Oct 24, 5:04 pm, "Sony Mathew" wrote:
> >
> > > Hello again, I am still looking for a sponsor for AxisPanel. I would
> > > appreciate any feedback - good or bad.
> >
> > > I am currently evaluating GWT for our team as we would like to make the
> jump
> > > over to Rich UI. Other frameworks we are evaluating include Flex and
> > > Laszlo.
[gwt-contrib] Re: RR : Make runAsync split point information accessible to SOYC
On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst wrote: > Hi Lex, > > I've made all the changes you requested except the first, which we > have decided not to do for now (reason: SourceInfo does not contain a > pointer to the node, so instead we would have to keep JMethod around > until link time, which seemed overkill). > > Please let me know what you think. LGTM. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
> This isn't a compiler bug, it's caused by hosted mode being perhaps slightly
> overeager? The deal is, the custom field serializer for Arrays.asList()
> (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer),
> has a method getArray0() that uses a JSNI reference that's only valid
> against our own JRE emulation classes... it's not valid against a real JRE.
> This is okay, because the call to that method is guarded by a
> GWT.isScript() block.
> Bob, thoughts?
The problem here is that we need to rewrite the JSNI method with the
numeric dispatch ids before we inject the code into the browser.
Previously, dispatch was string-based so it wasn't a problem. We
could add an @SuppressWarnings("jsni") to the method to squelch
warnings like this.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Looking for Incubator sponsor for AxisPanel (2nd try)
For more info on this topic refer to my Article: Fluent DSL for Rich
UI
on theServerSide.com:
http://www.theserverside.com/news/thread.tss?thread_id=52241
on my blog: http://sonymathew.blogspot.com/2008/12/fluent-dsl-for-rich-ui.html
Thanks
Sony
On Oct 27, 11:55 am, Sony wrote:
> dflorey, Isaac
> Thank you for your comments. First off, I want to make sure I am
> going about this the right way. Was I supposed to post AxisPanel
> myself or wait for a reply from a sponsor? I didn't join the group
> itself till after my 2nd email attempt. Thanks again for posting this
> for me.
>
> Regarding: IDE Formatting:
> Good point - but to me the gain in readability with the manual
> indentation is worth not auto formatting select packages. Most people
> use manual indentation anyways and resort to Auto formatting when
> files are checked in.
>
> Regarding: Unconventional method names:
> I expected this to be the main opposition from the GWT team. See
> Martin Fowler's DomainSpecificLanugage and FluentInterfaces. Some
> would argue against the conventional setter/getter/add method names
> for a complex domain. What I have used is a Domain-Specific-Language
> (DSL) or a Fluent Interface (language within a language) to handle the
> complex domain of UI layouts.
> --
> Checkout Martin Fowler's
> entries.http://www.martinfowler.com/bliki/DomainSpecificLanguage.htmlhttp://www.martinfowler.com/bliki/FluentInterface.html
> --
> I would in-fact argue that using Fluent layouts all-around would
> benefit GWT greatly and bring about even greater usage - such Fluent
> layouts could out-do any framework with XML or HTML layouts if
> properly supported.
>
> Regarding: Just a helper class, no advantage over exiting panels:
> Yes, AxisPanel can be viewed as a helper class - nothing too
> innovative. The innovative parts if any are: 1) combining Vertical/
> Horizontal layout concepts under one hood to create a very powerful
> layout in my experience - capable of laying out almost any complex
> layout needs and 2) providing a succinct readable DSL ("Fluent
> language within a language") for almost any complex layout needs.
> --
> I would in-fact argue against the need for several layout panels
> existing in GWT today - they could all be replaced with one
> AxisPanel. I would like to push this same concept out to Swing as
> well - where layouts can be quite cumbersome.
>
> Regarding: GXT BorderLayout,
> The GXT BorderLayout you linked to is fantastic - especially the nifty
> pin/collapse functionality for each border panel. I would have coded
> a border layout quite quickly as follows: (without the nifty pin/
> collapse of-course)
>
> AxisPanel p = new AxisPanel()
> .y().width("100%")
> .x(new ContentPanel()).css("north").width("100%").q()
> .x().width("100%")
> .y(new ContentPanel()).css("east").width("25%).q()
> .x(new ContentPanel()).css("center").width("50%).q()
> .y(new ContentPanel()).css("west").width("25%).q()
> .q()
> .x(new ContentPanel()).css("south").width("100%").q()
> .q()
>
> Also consider: a different version: PinAxisPanel
> Say PinAxisPanel had a Fluent AxisPanel like interface with properties
> like collapse(true) (why restrict to just the border layout, any Panel
> could be made Pinnable/Collapsible). I think this would be even more
> fabulous.
>
> Also consider: if layout requirements changed:
> Say the business wants to split the contents of the south panel into 3
> parts and move them adjacent to the contents of the east, center and
> west panels respectively (perhaps inside them place them at the top,
> center, and bottom respectively) and add different styling and so on.
> If my south panel's contents were laid out using the same AxisPanel in
> the same expression (instead of new ContentPanel()) - I could easily
> move the contents around until I obtained the right look and results -
> rather than creating new wrapper panels with new variable names,
> changing panel insertions etc. Overall readability of my layout is
> easily grasped and modified.
>
> I'll chill, you relax, we'll just chillax,
> Sony
>
> On Oct 24, 5:04 pm, "Sony Mathew" wrote:
>
> > Hello again, I am still looking for a sponsor for AxisPanel. I would
> > appreciate any feedback - good or bad.
>
> > I am currently evaluating GWT for our team as we would like to make the jump
> > over to Rich UI. Other frameworks we are evaluating include Flex and
> > Laszlo. At a minimum we needed to demonstrate that we can layout our
> > current web-pages easily with a few sprinkles of rich widgets here and
> > there.
>
> > The drawbacks several developers pointed out immediately were 1) verbosity
> > of the Java code 2) Layout structure not clear from the Java code and 3)
> > Layout modifications required tedious wrapping in additional panels to
> > achieve desired look. The last point was the most painful - needing to come
> > up with more variable name
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
> Bob, do you have any idea how hard it would be to trigger off of > module settings rather than a command line flag? I believe this will > require threading through the module meta-data into parts of the > compiler that currently don't have access to it. I looked at making it deferred-binding aware, so you could, if you wanted, get runAsync and non-runAsync builds simultaneously. I didn't go this route for the patch because Permutations are differentiated only by differences in rebind results and all I was really after was the ability to show the differences between two builds. If folks would like a binding-aware version, I can change the Permutation code to make this happen. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Review request: add super source dir to incubator demo build
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher wrote:
> LGTM.
>
> On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett wrote:
>>
>> Good enough for me. Here's the patch for building demos off of the jar:
>>
>> Index: build.xml
>> ===
>> --- build.xml (revision 1316)
>> +++ build.xml (working copy)
>> @@ -371,8 +371,7 @@
>> vmMaxMemory="${gwtc.vm.maxMemory}">
>>
>>
>> -
>> -
>> +
>>
>>
>>
>>
>>
>> Any objections?
>>
>>
>> On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher wrote:
>> > The reasons I would prefer to use the gwt-incubator.jar is because that
>> > gives us a quick sanity check that the gwt-incubator jar is actually
>> > including everything needed to run the demos!
>> >
>> >>
>> >> + project.src and project.bin can be overridden, if desired (super
>> >> could be overridden if it used a variable, which it probably should)
>> >
>> > If project.src or project.bin was overridden, those changes should be
>> > reflected in the gwt-incubator jar, if they are not, that is definitely
>> > a
>> > problem we would want to catch sooner rather then later.
>> >
>> >>
>> >> + build-demos doesn't depend on building a jar first
>> >
>> >
>> > The gwt-incubator jar currently takes 12 seconds to compile on my
>> > relatively
>> > slow laptop, so depending upon the gwt-incubator build running first
>> > does
>> > not seem like it introduces an undue burden on the developer.
>> >
>> >
>> > cheers,
>> >
>> > Emily
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Review request: add super source dir to incubator demo build
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett wrote:
>
> Good enough for me. Here's the patch for building demos off of the jar:
>
> Index: build.xml
> ===
> --- build.xml (revision 1316)
> +++ build.xml (working copy)
> @@ -371,8 +371,7 @@
>vmMaxMemory="${gwtc.vm.maxMemory}">
>
>
> -
> -
> +
>
>
>
>
>
> Any objections?
>
>
> On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher wrote:
> > The reasons I would prefer to use the gwt-incubator.jar is because that
> > gives us a quick sanity check that the gwt-incubator jar is actually
> > including everything needed to run the demos!
> >
> >>
> >> + project.src and project.bin can be overridden, if desired (super
> >> could be overridden if it used a variable, which it probably should)
> >
> > If project.src or project.bin was overridden, those changes should be
> > reflected in the gwt-incubator jar, if they are not, that is definitely a
> > problem we would want to catch sooner rather then later.
> >
> >>
> >> + build-demos doesn't depend on building a jar first
> >
> >
> > The gwt-incubator jar currently takes 12 seconds to compile on my
> relatively
> > slow laptop, so depending upon the gwt-incubator build running first does
> > not seem like it introduces an undue burden on the developer.
> >
> >
> > cheers,
> >
> > Emily
> >
> > >
> >
>
> >
>
--
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Review request: add super source dir to incubator demo build
Good enough for me. Here's the patch for building demos off of the jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory="${gwtc.vm.maxMemory}">
-
-
+
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher wrote:
> The reasons I would prefer to use the gwt-incubator.jar is because that
> gives us a quick sanity check that the gwt-incubator jar is actually
> including everything needed to run the demos!
>
>>
>> + project.src and project.bin can be overridden, if desired (super
>> could be overridden if it used a variable, which it probably should)
>
> If project.src or project.bin was overridden, those changes should be
> reflected in the gwt-incubator jar, if they are not, that is definitely a
> problem we would want to catch sooner rather then later.
>
>>
>> + build-demos doesn't depend on building a jar first
>
>
> The gwt-incubator jar currently takes 12 seconds to compile on my relatively
> slow laptop, so depending upon the gwt-incubator build running first does
> not seem like it introduces an undue burden on the developer.
>
>
> cheers,
>
> Emily
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Make runAsync split point information accessible to SOYC
Hi Lex,
I've made all the changes you requested except the first, which we
have decided not to do for now (reason: SourceInfo does not contain a
pointer to the node, so instead we would have to keep JMethod around
until link time, which seemed overkill).
Please let me know what you think.
Thanks,
kathrin
On Thu, Dec 11, 2008 at 6:09 PM, Lex Spoon wrote:
> Hi, this patch records some information that makes the final report
> much easier to read. The internal fragment numbers are really
> obscure, so the less they show up in the reports, the better.
>
> It looks generally good but I think there should be a few small modifications.
>
> First, it looks like it does not handle the case that two calls to
> runAsync happen in the same method. In such a case, the report
> generator should probably assign unique names to them, perhaps simply
> by adding " #1" and " #2" to the end of the names.
>
> Second, I do think it is cleaner to have JProgram keep a
> Map rather than a Map. It is not
> important for the application of presenting information in the report,
> but it seems a pity to drop information when it's not necessary. If
> this is much trouble, then don't bother, but I suspect it will be a
> very simple change.
>
> There are also some minor nits:
>
> Several files use the type TreeMap, when Map seems less committal and
> thus slightly better.
>
> Two files need an auto-format for spacing issues: CompilationAnalysis
> and JavaToJavaScriptCompiler
>
>
> I guess the updates are large enough that I'd like to rereview it, but
> just barely. I'll try to get to it much faster than this initial
> review!
>
> -Lex
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
===
--- dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java (revision 4342)
+++ dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java (working copy)
@@ -55,6 +55,7 @@
import java.util.Set;
import java.util.SortedSet;
import java.util.Stack;
+import java.util.TreeMap;
import java.util.TreeSet;
/**
@@ -115,17 +116,25 @@
private transient Map membersByCorrelation = new IdentityHashMap();
/**
+ * Map from split point numbers to the method where they were set
+ */
+ private Map splitPointMap = new TreeMap();
+
+ /**
* Constructed by PermutationCompiler.
*/
public StandardCompilationAnalysis(TreeLogger logger,
- List> sourceInfoMaps)
+ List> sourceInfoMaps,
+ Map splitPointMap)
throws UnableToCompleteException {
super(StandardLinkerContext.class);
logger = logger.branch(TreeLogger.INFO,
"Creating CompilationAnalysis (this may take some time)");
data = new Data();
-
+
+this.splitPointMap = splitPointMap;
+
/*
* Don't retain beyond the constructor to avoid lingering references to AST
* nodes.
@@ -198,6 +207,11 @@
}
@Override
+ public Map getSplitPointMap(){
+return splitPointMap;
+ }
+
+ @Override
public SortedSet getStories() {
return data.stories;
}
Index: dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
===
--- dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java (revision 4342)
+++ dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java (working copy)
@@ -21,6 +21,7 @@
import com.google.gwt.core.ext.soyc.Range;
import com.google.gwt.core.ext.soyc.Story;
+import java.util.Map;
import java.util.SortedSet;
/**
@@ -76,6 +77,11 @@
public abstract Iterable getSnippets(int fragmentNumber);
/**
+ * Returns splitPointMap.
+ */
+ public abstract Map getSplitPointMap();
+
+ /**
* Returns all Stories.
*/
public abstract SortedSet getStories();
Index: dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java
===
--- dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java (revision 4342)
+++ dev/core/src/com/google/gwt/core/linker/soyc/SoycReportLinker.java (working copy)
@@ -65,7 +65,6 @@
@LinkerOrder(Order.PRE)
public class SoycReportLinker extends AbstractLinker {
- int curNumIndents = 0;
public String escapeXml(String unescaped) {
String escaped = unescaped.replaceAll("\\&", "&");
@@ -161,32 +160,29 @@
if (methodAliases.size() > 0) {
htmlOut.indentIn();
htmlOut.indentIn();
- curNumIndents++;
curLine = "";
- htmlOut.printRawOpt(curLine);
- htmlOut.newlineOpt();
+ htmlOut.printRaw(curLine);
+ htmlOut.newline();
htmlOut.indentIn();
htmlOut.indentIn();
- curNumIndents++;
}
for
[gwt-contrib] Re: Review request: add super source dir to incubator demo build
The reasons I would prefer to use the gwt-incubator.jar is because that gives us a quick sanity check that the gwt-incubator jar is actually including everything needed to run the demos! > > > + project.src and project.bin can be overridden, if desired (super > could be overridden if it used a variable, which it probably should) If project.src or project.bin was overridden, those changes should be reflected in the gwt-incubator jar, if they are not, that is definitely a problem we would want to catch sooner rather then later. > > + build-demos doesn't depend on building a jar first > The gwt-incubator jar currently takes 12 seconds to compile on my relatively slow laptop, so depending upon the gwt-incubator build running first does not seem like it introduces an undue burden on the developer. cheers, Emily --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Review request: add super source dir to incubator demo build
This change addresses gwt-incubator issue #208. The build-demos Ant
target fails to compile demos that depend on super-source. The change
(see below) places 'super' in the classpath before src. Another
solution, suggested by Emily, is to use the fully formed
gwt-incubator.jar instead of the individual directories.
I prefer the non-jar solution for the following (fairly flimsy) reasons:
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a variable, which it probably should)
+ build-demos doesn't depend on building a jar first
And I see one potential drawback:
- Any other super-source style legerdemain, current or future, would
have to be anticipated and reflected in the demo build
Any thoughts?
- Isaac
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,6 +371,7 @@
vmMaxMemory="${gwtc.vm.maxMemory}">
+
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Code review, renaming logging property for gen2 widgets.
John, could you review the following change? GWT has a fatal error if you try to redefine the same property twice. This means that gen2 logging and libideas.logging cannot live side by side, it also spells trouble for any project using gwt-log or other solutions. This code change renames the logging property from logging = all/none/minimal to gwt.logging=enabled/disabled/production. Code can be found at: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1317 -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4342 - in releases/1.6/distro-source: linux mac windows
Author: amitman...@google.com Date: Mon Dec 15 11:25:42 2008 New Revision: 4342 Modified: releases/1.6/distro-source/linux/build.xml releases/1.6/distro-source/mac/build.xml releases/1.6/distro-source/windows/build.xml Log: Adds api-checker to the distro. Patch by: amitmanjhi Review by: zundel Modified: releases/1.6/distro-source/linux/build.xml == --- releases/1.6/distro-source/linux/build.xml (original) +++ releases/1.6/distro-source/linux/build.xml Mon Dec 15 11:25:42 2008 @@ -12,6 +12,7 @@ + Modified: releases/1.6/distro-source/mac/build.xml == --- releases/1.6/distro-source/mac/build.xml(original) +++ releases/1.6/distro-source/mac/build.xmlMon Dec 15 11:25:42 2008 @@ -12,6 +12,7 @@ + Modified: releases/1.6/distro-source/windows/build.xml == --- releases/1.6/distro-source/windows/build.xml(original) +++ releases/1.6/distro-source/windows/build.xmlMon Dec 15 11:25:42 2008 @@ -12,6 +12,7 @@ + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: adding api-checker to the distro
Thanks Eric. Commited as r4342. Yes, it is meant to patch against 1.6. The trunk build files in the distro have additional lines for soyc, which caused the patch to fail. On Mon, Dec 15, 2008 at 1:59 PM, Eric Ayers wrote: > LGTM, Assuming its meant to patch against 1.6 (didn't work when I > tried to apply it against trunk) > > On Mon, Dec 15, 2008 at 10:39 AM, Amit Manjhi > wrote: > > Hi Eric, > > > > Please review the attached patch to the build files that add api-checker > to > > the distro. > > > > Regards, > > Amit > > > > > > -- > Eric Z. Ayers - GWT Team - Atlanta, GA USA > http://code.google.com/webtoolkit/ > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: adding api-checker to the distro
LGTM, Assuming its meant to patch against 1.6 (didn't work when I tried to apply it against trunk) On Mon, Dec 15, 2008 at 10:39 AM, Amit Manjhi wrote: > Hi Eric, > > Please review the attached patch to the build files that add api-checker to > the distro. > > Regards, > Amit > -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Relax JSO restrictions?
Sorry Joel, it was a typo. Should be com.google.gwt.xml.client.* instead of com.google.gwt.dom.client.* - Andrés On 15 dic, 14:31, Joel Webber wrote: > @mP: I completely agree that it's worth seeing if these things can be done > *without* changing the compiler. In this case, though, I'd have to agree > with your "Cons" section, that it's pretty weird to have two versions of a > class. Makes debugging really suck, too :) > > @Andrés: This would indeed make it possible to implement org.w3c.dom.* > directly (though it's a little bit of a minefield, because anybody else > trying to implement those interfaces in the same app would likely trip the > "one-implementor" restriction). However, it's not entirely clear to me how > this could be used to optimize the code in c.g.g.dom.client.*. Am I missing > something here (I hope so, because I just love a good optimization!)? > joel. > > On Fri, Dec 12, 2008 at 10:28 PM, Andrés Testi > wrote: > > > > > Or even, implementing org.w3c.dom.* natively ;-) > > > On 13 dic, 00:21, Andrés Testi wrote: > > > Great news! > > > This will allow a faster implementation of com.google.gwt.dom.client.* > > > > On 12 dic, 20:05, Bruce Johnson wrote: > > > > > Ray, great timing. Bob was just talking about having started a patch to > > > > allow this. > > > > @Bob: care to comment? > > > > > On Fri, Dec 12, 2008 at 6:01 PM, Ray Cromwell > > wrote: > > > > > > So, I've got these JSON formats that I use both in my Android code > > and > > > > > my GWT code. I originally implemented them as Overlay JSOs, and there > > > > > are classes that consume these OverlayJSOs to configure other parts > > of > > > > > the app. However, this makes the consumption code (which is really > > > > > quite generic and portable) unable to run in non-GWT environments. > > > > > > Thus, I need the consumption code to be able to consume interfaces > > > > > instead. I refactored the Overlay JSOs into interfaces (e.g. > > > > > JsonDataset) and provided a wrapper implementation (GwtJsonDataset) > > > > > that uses private overlay types. I then implemented a J2SE version > > > > > which uses the org.json APIs, which runs in the servlet/android > > > > > versions. > > > > > > However, it slightly annoys me that: > > > > > > 1) I have to use a wrapper, so all of the generated consumption code > > > > > looks like "foo.jso.range" instead of "foo.range" > > > > > 2) There is never more then one implementation of the interface > > active > > > > > in a GWT compile, so it is trivially type-tighten-able to the > > > > > implementation class. > > > > > > Couldn't the JSO restrictions checker, as a first pass, visit every > > > > > instantiation of interfaces implemented by the JSO, and verify that > > > > > only a single concrete type of the interface is instantiated? This > > > > > would allow JSOs to implement interfaces as long as there is > > > > > effectively only one implementation active. > > > > > > I'm thinking the logic would go something like this: > > > > > > for each interface of JSO > > > > > lookup all implementing classes in oracle > > > > > for each implementating class > > > > > find all types instantiated > > > > > if > 1, error > > > > > > Now, this can change subject to pruning passes, but I would settle > > for > > > > > the restriction that only one concrete instantiation must exist prior > > > > > to DCE/Pruning. > > > > > > -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
On Mon, Dec 15, 2008 at 11:11 AM, Bruce Johnson wrote: > One thing we need to reconcile before it gets away from us: for things like > this (and anticipated additional settings), should these be command-line > compiler flags or module settings? > I am more in favor of using module settings (specifically, deferred binding > properties that the compiler is sensitive to) for this purpose because you > might actually want deferred binding to be configured to support a > particular choice of settings. For example, imagine a property > "preferSmallToFast" set to "true". You could imagine choosing among two > different implementations of a class *and* having the compiler do different > optimizations. There is also the minor benefit of making these things more > hermetic. Another advantage is that it is analogous to specifying which linker to use. In fact, what runAsync does should ideally be influenced by the choice of linker, anyway. Bob, do you have any idea how hard it would be to trigger off of module settings rather than a command line flag? I believe this will require threading through the module meta-data into parts of the compiler that currently don't have access to it. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Relax JSO restrictions?
@mP: I completely agree that it's worth seeing if these things can be done *without* changing the compiler. In this case, though, I'd have to agree with your "Cons" section, that it's pretty weird to have two versions of a class. Makes debugging really suck, too :) @Andrés: This would indeed make it possible to implement org.w3c.dom.* directly (though it's a little bit of a minefield, because anybody else trying to implement those interfaces in the same app would likely trip the "one-implementor" restriction). However, it's not entirely clear to me how this could be used to optimize the code in c.g.g.dom.client.*. Am I missing something here (I hope so, because I just love a good optimization!)? joel. On Fri, Dec 12, 2008 at 10:28 PM, Andrés Testi wrote: > > Or even, implementing org.w3c.dom.* natively ;-) > > On 13 dic, 00:21, Andrés Testi wrote: > > Great news! > > This will allow a faster implementation of com.google.gwt.dom.client.* > > > > On 12 dic, 20:05, Bruce Johnson wrote: > > > > > Ray, great timing. Bob was just talking about having started a patch to > > > allow this. > > > @Bob: care to comment? > > > > > On Fri, Dec 12, 2008 at 6:01 PM, Ray Cromwell > wrote: > > > > > > So, I've got these JSON formats that I use both in my Android code > and > > > > my GWT code. I originally implemented them as Overlay JSOs, and there > > > > are classes that consume these OverlayJSOs to configure other parts > of > > > > the app. However, this makes the consumption code (which is really > > > > quite generic and portable) unable to run in non-GWT environments. > > > > > > Thus, I need the consumption code to be able to consume interfaces > > > > instead. I refactored the Overlay JSOs into interfaces (e.g. > > > > JsonDataset) and provided a wrapper implementation (GwtJsonDataset) > > > > that uses private overlay types. I then implemented a J2SE version > > > > which uses the org.json APIs, which runs in the servlet/android > > > > versions. > > > > > > However, it slightly annoys me that: > > > > > > 1) I have to use a wrapper, so all of the generated consumption code > > > > looks like "foo.jso.range" instead of "foo.range" > > > > 2) There is never more then one implementation of the interface > active > > > > in a GWT compile, so it is trivially type-tighten-able to the > > > > implementation class. > > > > > > Couldn't the JSO restrictions checker, as a first pass, visit every > > > > instantiation of interfaces implemented by the JSO, and verify that > > > > only a single concrete type of the interface is instantiated? This > > > > would allow JSOs to implement interfaces as long as there is > > > > effectively only one implementation active. > > > > > > I'm thinking the logic would go something like this: > > > > > > for each interface of JSO > > > > lookup all implementing classes in oracle > > > > for each implementating class > > > > find all types instantiated > > > > if > 1, error > > > > > > Now, this can change subject to pruning passes, but I would settle > for > > > > the restriction that only one concrete instantiation must exist prior > > > > to DCE/Pruning. > > > > > > -Ray > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
One thing we need to reconcile before it gets away from us: for things like this (and anticipated additional settings), should these be command-line compiler flags or module settings? I am more in favor of using module settings (specifically, deferred binding properties that the compiler is sensitive to) for this purpose because you might actually want deferred binding to be configured to support a particular choice of settings. For example, imagine a property "preferSmallToFast" set to "true". You could imagine choosing among two different implementations of a class *and* having the compiler do different optimizations. There is also the minor benefit of making these things more hermetic. On Mon, Dec 15, 2008 at 4:09 AM, BobV wrote: > I was trying to demonstrate the practical difference that runAsync > would make when compared to a monolithic deployment to someone today, > and there was no simple way to turn off runAsync that wasn't the > -disableAggressiveOptimizations flag. > > This patch adds an undocumented flag -disableRunAsync that just > disables code-splitting when compiling an app. > > Diffstat: > GWTShell.java |2 2 + 0 - 0 ! > Precompile.java | 10 10 +0 - 0 ! > jjs/JJSOptions.java |4 3 + 1 - 0 ! > jjs/JJSOptionsImpl.java | 10 10 +0 - 0 ! > jjs/JavaToJavaScriptCompiler.java |4 2 + 2 - 0 ! > util/arg/ArgHandlerDisableRunAsync.java | 51 51 +0 - 0 ! > util/arg/OptionRunAsyncEnabled.java | 26 26 +0 - 0 ! > 7 files changed, 104 insertions(+), 3 deletions(-) > > -- > Bob Vawter > Google Web Toolkit Team > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR: adding api-checker to the distro
Hi Eric, Please review the attached patch to the build files that add api-checker to the distro. Regards, Amit --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- Index: distro-source/linux/build.xml === --- distro-source/linux/build.xml (revision 4280) +++ distro-source/linux/build.xml (working copy) @@ -12,6 +12,7 @@ + Index: distro-source/mac/build.xml === --- distro-source/mac/build.xml (revision 4280) +++ distro-source/mac/build.xml (working copy) @@ -12,6 +12,7 @@ + Index: distro-source/windows/build.xml === --- distro-source/windows/build.xml (revision 4280) +++ distro-source/windows/build.xml (working copy) @@ -12,6 +12,7 @@ +
[gwt-contrib] Re: Add NativePreviewEvent to replace current EventPreview system (version 3)
Actually, hold off on this review please. In my haste, forgot to update MenuBar and SuggestBox to take advantage of the new alwaysAutoHide boolean. http://gwt-code-reviews.appspot.com/814 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
On Sun, Dec 14, 2008 at 6:45 PM, Cameron Braid wrote: > a) bug in compiler - see attached oophm-stacktrace.txt > This isn't a compiler bug, it's caused by hosted mode being perhaps slightly overeager? The deal is, the custom field serializer for Arrays.asList() (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer), has a method getArray0() that uses a JSNI reference that's only valid against our own JRE emulation classes... it's not valid against a real JRE. This is okay, because the call to that method is guarded by a GWT.isScript() block. Bob, thoughts? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Adding the happy event
I'm not sure I agree with your basic premise, for instance, ironically enough, the first Google link for the keywords "java example custom events" is indeed another example of a happy event: ( http://www.javaworld.com/javaworld/javaqa/2002-03/01-qa-0315-happyevent.html ). That said, I am not opposed to changing the event type, though probably not for one that could be so easily represented by ValueChangeEvent :-). Cheers, Emily On Sat, Dec 13, 2008 at 10:47 AM, wrote: > Sorry to be the naysayer, but isn't it more cute than useful? > > I've found myself (and heard others) cursing abstract/unrealistic > examples that don't have much clarifying power. > > How about an example that would resonate more readily, such as > "ColorSchemeChangedEvent" -- or anything in that sort of vein that a > developer could easily imagine actually doing. > > > http://gwt-code-reviews.appspot.com/813 > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Extendable GWT localization - crosscutting concern ?
Thanks for responses. We will create own jar with LocalizableResource, Messages, Constants, and ConstantsWithLookup for usage of the same interfaces in GWT, Swing and server side. With regards Marek --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR : A compiler option to disable runAsync sharding
I was trying to demonstrate the practical difference that runAsync would make when compared to a monolithic deployment to someone today, and there was no simple way to turn off runAsync that wasn't the -disableAggressiveOptimizations flag. This patch adds an undocumented flag -disableRunAsync that just disables code-splitting when compiling an app. Diffstat: GWTShell.java |2 2 + 0 - 0 ! Precompile.java | 10 10 +0 - 0 ! jjs/JJSOptions.java |4 3 + 1 - 0 ! jjs/JJSOptionsImpl.java | 10 10 +0 - 0 ! jjs/JavaToJavaScriptCompiler.java |4 2 + 2 - 0 ! util/arg/ArgHandlerDisableRunAsync.java | 51 51 +0 - 0 ! util/arg/OptionRunAsyncEnabled.java | 26 26 +0 - 0 ! 7 files changed, 104 insertions(+), 3 deletions(-) -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- disable_run_async_r4303.patch Description: Binary data
