[gwt-contrib] Re: RR : Make runAsync split point information accessible to SOYC

2008-12-15 Thread Lex Spoon

On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst kpro...@google.com 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: RR : Make runAsync split point information accessible to SOYC

2008-12-15 Thread Katharina Probst

Thank you!  Committed as revision 4344.

kathrin

On Mon, Dec 15, 2008 at 6:08 PM, Lex Spoon sp...@google.com wrote:

 On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst kpro...@google.com 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: RR : Make runAsync split point information accessible to SOYC

2008-12-11 Thread Lex Spoon

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
MapInteger,SourceInfo rather than a MapInteger,String.  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
-~--~~~~--~~--~--~---