from:"bruce"


Exactly :-)

On Wednesday, August 12, 2009, Joel Webber j...@google.com wrote:
 Makes sense to me. So the first one will be gwt-2.0.0-m0, right?

 On Tue, Aug 11, 2009 at 11:40 PM, Bruce Johnson br...@google.com wrote:
 Mostly, this writeup is aimed at people who have been working on GWT's own 
 build-related stuff, but if anyone else has objections, now would be a good 
 time to raise them (though it seems unlikely anyone would).


 In the past, we've never had a good naming scheme for distros other than the 
 general availability distro. 
 For milestones, we used the convention 0.0.rev, which probably scares people off and isn't at all self-descriptive. For RCs
  and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1 
 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing.


 Here's the new proposal:
 major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2)= This is an official, 
 supported build. Every new minor (or bigger) release would start with a 
 bugfix number of 0.


 major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2)= This is release 
 candidate build n for the specified upcoming GWT release
 major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2)= This is milestone 
 build n for the specified upcoming GWT release
 In other words, the stream of announced code drops for 2.0 will look like 
 this (assuming 2 milestone and 1 rc):


 1) gwt-2.0.0-m1.zip2) gwt-2.0.0-m2.zip3) gwt-2.0.0-rc1.zip4) gwt-2.0.0.zip
 Note that we would always include the RC number, even if there's just one 
 (because you never know if another one is coming).


 I'm very happy to report that there seems to be no need to change even a 
 single line of code, as best I can tell. (Thank you to whomever wrote the 
 version string parsing code to ignore non-digit prefixes and suffixes.) Thus, 
 by simply following this convention when we set GWT_VERSION in the continuous 
 build, everything should work just fine.


 -- Bruce
 P.S. No, Joel, we can't start counting at 0, even though it makes more sense 
 :-) I can read your mind.





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

[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases

Duh, Kelly. Everybody knows that you always start counting at 1 when there's
a number immediately following a space or a non-digit and you start counting
at 0 when there's a number that immediately follows a period. It's such a
logical and obvious system that I thought the rules would be self-evident.
On Wed, Aug 12, 2009 at 9:24 AM, Kelly Norton knor...@google.com wrote:

 No, no, Joel, we will start counting at 1 not 0. The first release will be
 gwt-2.1.1-m1.
 I think the naming scheme is good (even if sometimes starts with 0, other
 times with 1).

 /kel

 On Wed, Aug 12, 2009 at 9:12 AM, Joel Webber j...@google.com wrote:

 Makes sense to me. So the first one will be gwt-2.0.0-m0, right?


 On Tue, Aug 11, 2009 at 11:40 PM, Bruce Johnson br...@google.com wrote:

 Mostly, this writeup is aimed at people who have been working on GWT's
 own build-related stuff, but if anyone else has objections, now would be a
 good time to raise them (though it seems unlikely anyone would).

 In the past, we've never had a good naming scheme for distros other than
 the general availability distro.
 For milestones, we used the convention 0.0.rev, which probably scares 
 people off and isn't at all self-descriptive. For RCs
 and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1
 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing.

 Here's the new proposal:

 major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2)
 = This is an official, supported build. Every new minor (or bigger)
 release would start with a bugfix number of 0.

 major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2)
 = This is release candidate build n for the specified upcoming GWT
 release

 major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2)
 = This is milestone build n for the specified upcoming GWT release

 In other words, the stream of announced code drops for 2.0 will look like
 this (assuming 2 milestone and 1 rc):

 1) gwt-2.0.0-m1.zip
 2) gwt-2.0.0-m2.zip
 3) gwt-2.0.0-rc1.zip
 4) gwt-2.0.0.zip

 Note that we would always include the RC number, even if there's just one
 (because you never know if another one is coming).

 I'm very happy to report that there seems to be no need to change even a
 single line of code, as best I can tell. (Thank you to whomever wrote the
 version string parsing code to ignore non-digit prefixes and suffixes.)
 Thus, by simply following this convention when we set GWT_VERSION in the
 continuous build, everything should work just fine.

 -- Bruce

 P.S. No, Joel, we can't start counting at 0, even though it makes more
 sense :-) I can read your mind.



 



 --
 If you received this communication by mistake, you are entitled to one free
 ice cream cone on me. Simply print out this email including all relevant
 SMTP headers and present them at my desk to claim your creamy treat. We'll
 have a laugh at my emailing incompetence, and play a game of ping pong.
 (offer may not be valid in all States).


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

[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases

Senator Blum,

Do you mean disturbing as in
1) revolting,
2) distressing, or
3) disordering?

It seems that mathematics has successfully survived similar notational
issues, such as the whole X vs. X' thing.

Willing to give it a chance?

On Wed, Aug 12, 2009 at 4:47 PM, Scott Blum sco...@google.com wrote:

 I find the fact that 2.0.0 is now ambiguous to be disturbing, admiral.

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

[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases

The version update notification thing is admittedly a problem, and so it's
true we maybe would need to tweak that. Not changing code most certaily
wasn't the justification for the naming scheme I proposed (slap me the day I
let that be a reason to justify a lame approach).

Alternate proposals, naysayers?

On Wed, Aug 12, 2009 at 6:49 PM, John Tamplin j...@google.com wrote:

 On Wed, Aug 12, 2009 at 6:39 PM, Bruce Johnson br...@google.com wrote:

 Senator Blum,

 Do you mean disturbing as in
 1) revolting,
 2) distressing, or
 3) disordering?

 It seems that mathematics has successfully survived similar notational
 issues, such as the whole X vs. X' thing.


 I dislike the fact that normal ordering rules do no apply here.  For
 example, you promoted the fact that version checking code doesn't have to
 change, it does -- otherwise, you won't get prompted to upgrade from
 2.0.0-rc1 to 2.0.0.

 I would also prefer 2.0.0-ms1 rather than -m1 for better clarity and
 symmetry with -rc1.


 Willing to give it a chance?


 I don't feel strongly enough to fight hard for something different, but I
 would prefer having a straightforward comparison do the right thing.  We can
 certainly make the comparator understand the particular naming scheme, but
 that doesn't do well when/if we decide to change it (as it happens, that
 isn't a problem for older versions but it might be for future versions if we
 change the scheme).

 --
 John A. Tamplin
 Software Engineer (GWT), Google


 


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

[gwt-contrib] Re: Fix non-fatal WeakMapping compile errors

2009-08-11 Thread bruce


LGTM

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

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

[gwt-contrib] Re: DTO compiler optimization

2009-08-11 Thread Bruce Johnson

There's sometimes an important difference between the kind of object model
that is appropriate to send to the client and one you'd use on the server.
That's the reason we haven't historically tried to make it easier to do
no-brainer sharing of server-side object models to the client (i.e.
because it seems likely on average there would be way too much wasted data
transferred, which would lead to slowness). Clearly, you see that issue,
too, based on your suggestion.
How well would the transient keyword or the @GwtTransient annotation
satisfy the use case you gave?

On Mon, Aug 10, 2009 at 1:10 PM, Nathan Wells nwwe...@gmail.com wrote:


 I have hesitated to bring this up, since I'm relatively new to GWT,
 and I would hate to waste anyone's time with explaining what is
 hopefully common knowledge to me.

 Specifically, I thinking about the DTO problem. I think the general
 opinion about DTOs is that they are a necessary evil when working with
 GWT. And let me say, they are a very minor blemish on a life-saving
 framework. But, It seems to me that the problem has a more elegant
 solution. I would propose that all we need to do is increase the
 granularity of GWT compiler control.

 For clarification, I would like to be able to tell the compiler at the
 class member level (either through annotations or *.gwt.xml) what
 should be client-side and what should be server-side. As an example,
 compiling the following class wouldn't be a problem:

 class Foo implements Serializable {

  @ServerOnly
  static long serialVersionUID = 325490285;

  //default, of course compiles to java byte-code and js.
  String bar;

  @ServerOnly
  void setBar(String bar) {
//a method which might reference un-emulated JRE classes
  }

  String getBar() {
return bar;
  }

 }

 I hope that makes sense... that way, our the same class could be used
 on server and client side. Hurray for OO!

 Again, I'm sure there are some unforeseen consequences of this design,
 not the least of which is the possibility that it would require
 basically rebuilding the GWT compiler. I'm just hoping that this
 discussion might answer other n00b questions in the future :)

 


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

[gwt-contrib] Prettier GWT version names for upcoming 2.0 releases

2009-08-11 Thread Bruce Johnson

Mostly, this writeup is aimed at people who have been working on GWT's own
build-related stuff, but if anyone else has objections, now would be a good
time to raise them (though it seems unlikely anyone would).

In the past, we've never had a good naming scheme for distros other than the
general availability distro.
For milestones, we used the convention 0.0.rev, which probably
scares people off and isn't at all self-descriptive. For RCs
and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1
was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing.

Here's the new proposal:

major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2)
= This is an official, supported build. Every new minor (or bigger) release
would start with a bugfix number of 0.

major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2)
= This is release candidate build n for the specified upcoming GWT
release

major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2)
= This is milestone build n for the specified upcoming GWT release

In other words, the stream of announced code drops for 2.0 will look like
this (assuming 2 milestone and 1 rc):

1) gwt-2.0.0-m1.zip
2) gwt-2.0.0-m2.zip
3) gwt-2.0.0-rc1.zip
4) gwt-2.0.0.zip

Note that we would always include the RC number, even if there's just one
(because you never know if another one is coming).

I'm very happy to report that there seems to be no need to change even a
single line of code, as best I can tell. (Thank you to whomever wrote the
version string parsing code to ignore non-digit prefixes and suffixes.)
Thus, by simply following this convention when we set GWT_VERSION in the
continuous build, everything should work just fine.

-- Bruce

P.S. No, Joel, we can't start counting at 0, even though it makes more sense
:-) I can read your mind.

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

[gwt-contrib] Re: Add GWT#getUserAgentProperty()

Let me play devil's advocate, at least against the idea of returning the
string directly. I fear that making this value easily accessible will
encourage people to write conditional tests all over the place, which is
brittle (i.e. because we're very subtly locked into particular user.agent
values) and less optimal (because it isn't clear that the resulting patterns
will optimize well). I guarantee you people will create maps of (user agent
string key) = (functor), which will thoroughly default compiler
optimizations.
Can you talk a bit more about the motivation, so we could consider
alternatives?

On Fri, Aug 7, 2009 at 10:50 AM, Ray Ryan rj...@google.com wrote:

 I say where's the unit test?


 On Fri, Aug 7, 2009 at 7:14 AM, j...@google.com wrote:


 On 2009/08/07 13:56:08, jlabanca wrote:


 So there's one problem here: The GWT class is in the Core module, which
 doesn't (and shouldn't) depend upon the UserAgent module. I think that
 to get this right, we'll need to do one of the following things:
 - Add this code to some class in User. Not my favorite option.
 - Add a new UserAgent module that lives in its own package, so that we
 can add UserAgent-related stuff to a class there. Perhaps
 com.google.gwt.ua.UserAgent?
   - I kind of like this option, because (a) it gets UserAgent out of the
 user packgage, where it never should have been in the first place, and
 (b) it gives me a place to put other UserAgent-related methods I need to
 add.

 What say you?

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




 


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

[gwt-contrib] Re: Inlining nocache.js

2 requests is very impressive, Arthur! This is the sort of conscientiousness
(i.e. for optimizing user experience) I hope all GWT developers would strive
for. Nice work.
And yes, we'd like to help you get that down to 1, too.

On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson arthur.k...@gmail.comwrote:


 I'd love to see this in the trunk too. We have only 2 round trips on
 start up now, thanks to ClientBundle. Getting it down to one will be
 very slick!

 --
 Arthur Kalmenson



 On Fri, Aug 7, 2009 at 8:41 AM, Cameron Braidcame...@braid.com.au wrote:
  I'd be keen to see this land in trunk !
 
  Cam
 
  2009/8/7 John Tamplin j...@google.com
 
  On Fri, Aug 7, 2009 at 3:51 AM, George Georgovassilis
  g.georgovassi...@gmail.com wrote:
 
  I'd like to save first time visitors that roundtrip to fetch
  nocache.js. Instead I've declared the module HTML page as non-
  cacheable (works nice thanks to E-Tag) and moved images and GWT-
  compiler output to a fully cacheable directory.
 
  After inlining nocache.js into the module HTML I had to change the
  paths to the XYZ.cache.html permutations, but couldn't get RPC to work
  reliably across all browsers.
 
  Is there a way to do this cleanly?
 
  There is a Google-internal linker that does this, and will be cleaned up
  and moved to GWT itself in the near future.  I don't know an exact
 timeframe
  for this however.
 
  --
  John A. Tamplin
  Software Engineer (GWT), Google
 
 
 
 
  
 

 


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

[gwt-contrib] Re: Inlining nocache.js

The best you can do for a cold cache is 2 round-trips (including the host
page) if you inline the selection script (.nocache.js) in the host page. You
definitely do want the compiled script (.cache.html) *not* embedded in the
host page, so that it can have cache forever semantics. Then, when users
have a warm cache, it's literally exactly 1 round-trip for the module to
start.
BTW, once you do inline the selection script, it will be more important to
get the HTTP semantics just right. Although it says nocache, the proper
semantics are must-revalidate, so typically, the host page won't have
changed on the server, and thus it becomes an If-Modified-Since (IMS)
request with a Not-Modified (NM) response.

In other words, the best case for a warm cache is this 1 round-trip: IMS =
NM, which is very cheap because there's no response payload. Your code can
start essentially instantly on a decent network.

On Fri, Aug 7, 2009 at 11:39 AM, Arthur Kalmenson arthur.k...@gmail.comwrote:


  Are you counting fetching the host HTML page?  With this approach, the
  selection script is done away with but you still have a fetch for the
  compiled script so that it can remain permanently cacheable.  You could
  theoretically inline it into the host page, but since none of that is
  cacheable that would only make sense for very tiny compiled outputs.

 I don't think firebug counts the initial request to fetch the host
 page, so two requests. One for the nocache.js and another for the
 cachable HTML. With the inlining of the nocache.js file, you could get
 it down to 0 requests if the retrieved page is cached forever.

 Are you saying to inline the generated JS in the host page too? How
 could you do that? Don't you need the selector script to pick the
 correct compiled version? Maybe I'm just not understanding what you
 mean.

  2 requests is very impressive, Arthur! This is the sort of
 conscientiousness
  (i.e. for optimizing user experience) I hope all GWT developers would
 strive
  for. Nice work.
  And yes, we'd like to help you get that down to 1, too.

 Thanks Bruce! But it's really all thanks to Bob's ClientBundle :)

 --
 Arthur Kalmenson



 On Fri, Aug 7, 2009 at 9:57 AM, John Tamplinj...@google.com wrote:
  On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson arthur.k...@gmail.com
  wrote:
 
  I'd love to see this in the trunk too. We have only 2 round trips on
  start up now, thanks to ClientBundle. Getting it down to one will be
  very slick!
 
  Are you counting fetching the host HTML page?  With this approach, the
  selection script is done away with but you still have a fetch for the
  compiled script so that it can remain permanently cacheable.  You could
  theoretically inline it into the host page, but since none of that is
  cacheable that would only make sense for very tiny compiled outputs.
 
  Note that there is a cost, as your host HTML page now can't be cached
 (since
  the selection script essentially runs in the server).  If your host page
 is
  complex, this may be a net loss.  You could try leaving it cacheable but
  setting Vary headers for the pieces that you use to make the decision,
 but
  my understanding is that many caches do not handle this properly.
 
  Also, you cannot use any deferred binding properties that can't be
  determined by the HTTP fetch of your host page.
 
  --
  John A. Tamplin
  Software Engineer (GWT), Google
 
  
 

 


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

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

On Fri, Aug 7, 2009 at 12:20 PM, Lex Spoon sp...@google.com wrote:

 One place I would quibble about is compiler transforms that we
 consider to be optimizations, because an optimization should preserve
 behavior.  Thus, a test case should not have any easy way to be
 sensitive to the choice.  Going back to the code splitting example, it
 would be within spec for the code splitter *not* to generate a
 download event for a particular split point, even though it's not that
 clever right now.  That flexibility makes it very hard to think up an
 API for querying the code splitter's settings.  Certainly on and
 off isn't enough information, at least going forward.


The sorts of compiler optimizations tests I was referring to were
to-be-written tests of complex optimizations where the whole point of the
test is to ensure the compiler is doing exactly the transform we intend it
to. IOW, the sort of stuff Scott is working on testing infrastructure for.

I mostly see your point about the splitter, and in cases like that where you
aren't trying to test the exact decisions/implementation, then it seems
reasonable to have something that's a bit looser. OTOH, one could argue that
it's good to have tests that verify specific behavior that is intended for
the current implementation rather than adherence to the spec.


 Would anyone see anything bad, for the narrow code splitting example,
 with adding a LWM event saying split point requested, but code
 already present?  This approach would mean I can finish up the
 runAsync LWM patch on Monday or Tuesday.


No objections here, especially if the code already present event is
meaningful for web
mode where indeed the needed code has already been downloaded. That
could be useful thing to know at runtime in production.


 Looks good to me.  For the short term, how does it strike you to also
 have a way to query config and binding properties?  While it might not
 be what we want in the long run, it looks very practical right now.
 For example, disable this test when user.agent=opera.  Another
 example would be, disable this test if class metadata is off.  Given
 the near-term state of module specifications, querying the property
 looks more direct than needing to define a class that corresponds to
 them.


I like the pragmatism, but I fear the repercussions of a intermediate
generalized solution that would encouraged the string literal names of
properties and flags all over client code. I'd rather we switched things
over to The Right Way (whatever we deem that to be) rather than have a
half-done waypoint. However, The Right Thing could be something very
different than what I proposed -- see the JUnit discussion below.

Also, while thinking about how to set up the annotations, or and
 and would seem helpful in some cases.  Run this test if the agent is
 iphone *or* the agent is android.  Run this test if the agent is
 iphone *and* class metadata is on.  So it would be good to include
 them, or something equally powerful, in the supported annotations.


My idea here might be considered a hack. I was thinking that and could be
represented as pairs of (to, from) tuples, and that or could be
represented as separate test cases that simply delegate, such as

@RunWhen(Browser.class, Browser_IPhone.class)
public void testIPhone() {
  doTestIPhoneOrAndroid();
}

@RunWhen(Browser.class, Browser_Android.class)
public void testAndroid() {
  doTestIPhoneOrAndroid();
}

private void doTestIPhoneOrAndroid() {
   ...
}

Now that I look at it, it's kinda hacky, but then again it may not be very
common. Hopefully not, or we're not doing a good job of creating portable
APIs.

On the downside, using assumeThat() means that the test runner still
 has to run the tests.  With annotations, the test runner can know
 ahead of time which tests are relevant on which platforms.  Would our
 test runners make good use of that information?  Enough to merit the
 implementation time and the larger GWT user manual?


I think assumeThat() might indeed be a good general solution, along the
lines of your examples. It subsumes the annotations I proposed, and it's
nice that it could be generalized easily to any sort of tests. Also, it
*might* be possible for the compiler to optimize it statically somewhat such
that if a test contained assumeThat(X) where X was statically know to be
false, the whole method could go away. (Of course, we'd need that behavior
to be generalized somehow -- I'm not proposing JUnit-specific compiler
behavior, which would be way too hacky).

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

[gwt-contrib] Re: Questions and concerns with HandlerManager

Are there lots of folks on the list that have the same sorts of feedback on
HandlerManager? I ask because, as a fly on the wall here, this conversation
doesn't sound like it's converging, and I'd like to declare this thread dead
for now so that we can move onto other things. We have a lot of other things
to be giving attention to so that we can get GWT 2.0 out. If we need to
revisit these issues in the future, we certainly can.

-- Bruce

On Fri, Aug 7, 2009 at 4:43 PM, Ed post2edb...@hotmail.com wrote:


class HandlerManagerSource { ... }

 Interesting how you put Generics in the  HandlerManager 
 Of course this is a no go area as you explained.
 Try my HandlerManager scenario like I described above; only the event
 contains the actual source generics, and of course not he
 HandlerManager...
 Let me know if you want some code of this ?  So I can grep something
 together... I might need a bit of time for that... and let me know
 where to send it to?

  To be honest, I'm having a really hard time understanding the structure
  you're describing. Maybe a bit of (heavily elided) code would help
 clarify
  it?

 H... I could give some code, but I think in words the need for the
 interceptor is clear:
 The user selects something and the interceptor will indicate if the
 selection is allowed to be committed (like a 2-phase db transaction)
 or not..
 Can you give me more details about what you not understand here
 please?
 I am afraid that the code only make it less understandable as it's
 complex.. due to the asynchrone behavior.


  If you could describe *precisely* what you think should be opened up in
  HandlerManager, it would help me to make a reasonable judgment. As it
  stands, it all seems very vague to me.


 H... can't remember the *precise* details anymore... it was
 already some time ago... :(
 One thing I remember was that I wanted to change the source in the
 HandlerManager, which wasn't possible as it can only be set through
 the constructor..




 On Aug 7, 10:07 pm, Joel Webber j...@google.com wrote:
  On Fri, Aug 7, 2009 at 1:34 PM, Ed post2edb...@hotmail.com wrote:
 
   It costs me a bit to go back in time as these issues are already from
   some time back..
   Let me try to give some input on these points.
 
   2) I don't fully understand what the problem is here. Could you give
   an example that shows that it breaks?
 
  It's actually worse than I thought. If I add a type parameter to
  HandlerManager, I get something like
 
class HandlerManagerSource { ... }
 
  But I have no way to specify the source type when it's declared in
 Widget:
 
class Widget {
  HandlerManager??? handlerManager;
}
 
  The Source type parameter would force me to declare a separate
  HandlerManager field in each subclass of Widget. But then I can't
 subclass a
  widget and get the source type correct -- I'd need *another*
 handlerManager
  field.
 
  3) Ok, let me give an example and hope I have some luck here... ;) I
 
 
 
   remember we had this same discussion about primitive-simple Widget
   interfaces, you asked me the same thing (together with Bruce), I gave
   some concrete interfaces.. and never heard anyting :(...
 
   My app is very simple in layout: a menu on the left and the content on
   the right. You can navigate to another piece of content by clicking on
   the next/prev button in the content screen part or by clicking in the
   menu.
   If the user navigates away from the current content screen (by
   clicking next/previous... or the menu), and the current shown content
   isn't valid, he will be asked for a confirmation. If yes, the action
   (=going to the new content and saving the current shown content) will
   be performed, if no, the action is canceled and he stays on the same
   content screen.
   I implement this through an interceptor (aynchrone in this case) that
   will take care of the confirmation and some other side-actions. It
   makes it clean and transparent.
 
  What I do roughly: I inject the interceptor in the presenter. When the
 
   select value in the model changes it will first inform the interceptor
   with a callback. The call back contains different methods that are
   called by the HandlerManager implementation to indicate success/
   cancelation. In case of success (the user clicks Ok), it will inform
   the callback about this such that the property change can be made
   permanent. The handlermanager will then inform the listeners and after
   that call the callback to indicate that they are all informed
   If you need more details, let me know ?
 
  To be honest, I'm having a really hard time understanding the structure
  you're describing. Maybe a bit of (heavily elided) code would help
 clarify
  it?
 
  After describing the above, you might understand that it's desirable
 
   to open up the GWT Handlermanager to add these functionality directly
   to it, instead of making a copy and changing it.. Probably this is
   need

[gwt-contrib] Re: Questions and concerns with HandlerManager

Dead! (for now)

On Fri, Aug 7, 2009 at 5:10 PM, Ed post2edb...@hotmail.com wrote:


 Then I would declare it dead Bruce!

 With all do respect: I do very complex things with GWT and do walk on
 his boundaries...
 And to my experience - I am a bit lonely out here... (yes I know
 it sounds a bit arrogant...)
 And yes, I agree that you guys have better things to do to make GWT
 first more mature before they support these complex things...

 Buttt... it would be nice if these things aren't forgotten and put on
 the nice-to-have list... and not on the forget-list.

 I think that adding (more) primitive (characteristic) widget/panel
 interfaces, like we discussed before has an higher priority, so I hope
 you guys add this to gwt 2.0. I am still suprised about the few people
 complain about this. But I have pointed out concrete clear cases that
 show the need for this...(like you asked before)

 Just my thoughts...
 BTW: Joe if you want some code about my HandlerManager to be able to
 define the source through generics, let me know...


 On Aug 7, 10:55 pm, Bruce Johnson br...@google.com wrote:
  Are there lots of folks on the list that have the same sorts of feedback
 on
  HandlerManager? I ask because, as a fly on the wall here, this
 conversation
  doesn't sound like it's converging, and I'd like to declare this thread
 dead
  for now so that we can move onto other things. We have a lot of other
 things
  to be giving attention to so that we can get GWT 2.0 out. If we need to
  revisit these issues in the future, we certainly can.
 
  -- Bruce
 
  On Fri, Aug 7, 2009 at 4:43 PM, Ed post2edb...@hotmail.com wrote:
 
  class HandlerManagerSource { ... }
 
   Interesting how you put Generics in the  HandlerManager 
   Of course this is a no go area as you explained.
   Try my HandlerManager scenario like I described above; only the event
   contains the actual source generics, and of course not he
   HandlerManager...
   Let me know if you want some code of this ?  So I can grep something
   together... I might need a bit of time for that... and let me know
   where to send it to?
 
To be honest, I'm having a really hard time understanding the
 structure
you're describing. Maybe a bit of (heavily elided) code would help
   clarify
it?
 
   H... I could give some code, but I think in words the need for the
   interceptor is clear:
   The user selects something and the interceptor will indicate if the
   selection is allowed to be committed (like a 2-phase db transaction)
   or not..
   Can you give me more details about what you not understand here
   please?
   I am afraid that the code only make it less understandable as it's
   complex.. due to the asynchrone behavior.
 
If you could describe *precisely* what you think should be opened
 up in
HandlerManager, it would help me to make a reasonable judgment. As it
stands, it all seems very vague to me.
 
   H... can't remember the *precise* details anymore... it was
   already some time ago... :(
   One thing I remember was that I wanted to change the source in the
   HandlerManager, which wasn't possible as it can only be set through
   the constructor..
 
   On Aug 7, 10:07 pm, Joel Webber j...@google.com wrote:
On Fri, Aug 7, 2009 at 1:34 PM, Ed post2edb...@hotmail.com wrote:
 
 It costs me a bit to go back in time as these issues are already
 from
 some time back..
 Let me try to give some input on these points.
 
 2) I don't fully understand what the problem is here. Could you
 give
 an example that shows that it breaks?
 
It's actually worse than I thought. If I add a type parameter to
HandlerManager, I get something like
 
  class HandlerManagerSource { ... }
 
But I have no way to specify the source type when it's declared in
   Widget:
 
  class Widget {
HandlerManager??? handlerManager;
  }
 
The Source type parameter would force me to declare a separate
HandlerManager field in each subclass of Widget. But then I can't
   subclass a
widget and get the source type correct -- I'd need *another*
   handlerManager
field.
 
3) Ok, let me give an example and hope I have some luck here... ;) I
 
 remember we had this same discussion about primitive-simple Widget
 interfaces, you asked me the same thing (together with Bruce), I
 gave
 some concrete interfaces.. and never heard anyting :(...
 
 My app is very simple in layout: a menu on the left and the content
 on
 the right. You can navigate to another piece of content by clicking
 on
 the next/prev button in the content screen part or by clicking in
 the
 menu.
 If the user navigates away from the current content screen (by
 clicking next/previous... or the menu), and the current shown
 content
 isn't valid, he will be asked for a confirmation. If yes, the
 action
 (=going to the new content and saving the current shown content

[gwt-contrib] Re: UIBinder

2009-08-05 Thread Bruce Johnson


We're shooting for a milestone drop in a few weeks, and we're planning
for an RC by the end of the quarter. But, you know how predicting
dates goes...

On 8/4/09, Claudemir  Todo Bom claude...@gmail.com wrote:

 is there an ETA for 2.0?

 On Aug 4, 10:42 am, Ray Ryan rj...@google.com wrote:
 How does today strike you? It's headed into gwt trunk, and will be
 part of the 2.0 release.

 On Tuesday, August 4, 2009, brett.wooldridge brett.wooldri...@gmail.com
 wrote:

  Ping.  This not this month any more, it's early next.  Got a
  revised (rough) ETA for UIBinder in SVN?  I would even love to hear
  definitely this month, but we don't know when.

  -Brett

  On Jul 15, 1:25 am, Ray Ryan rj...@google.com wrote:
  It's coming RSN. We're trying to get UiBinder into GWT 2.0. It will
  certainly be in SVN this month or early next.
  I know I've been saying that for a while, but now we're actually, like,
  working to make it happen.

  On Mon, Jul 13, 2009 at 11:05 PM, brett.wooldridge 

  brett.wooldri...@gmail.com wrote:

   I've read the docs for UIBinder in the wiki, and like everyone else
   who has read it, I am anxious to start using it.  However, even
   though
   the doc and examples are in the wiki, I am unable to find the
   UIBinder
   code in svn.  Is it available?   Or can it be made available?  Rough
   or not, documented or not, there are many developers who would like
   to
   start playing with it (and helping to fix issues).

   Thanks
   Brett



 


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

[gwt-contrib] Re: Async interface black magic

2009-08-03 Thread Bruce Johnson

Although it feels less convenient, the async nature of RPC is actually
valuable for usability. It forces you to think about what to do in the
application UI while a potentially long-running activity is taking place.
When you consider that a network round-trip combined with time spent on the
server could easily take multiple seconds on
average, that's an awful long time to have the UI thread blocked doing
nothing. If it were possible to write blocking
(or even, seemingly blocking) calls, it would be too tempting to not think
about the user experience -- in other words, in most apps the UI would
simply hang --  and it's probably prescibing a horrible user experience.

On Mon, Aug 3, 2009 at 6:57 AM, John Patterson jdpatter...@gmail.comwrote:



 On 3 Aug 2009, at 20:53, Miroslav Pokorny wrote:

 
  The Async interface is necessary because one does not want to use sync
  (blocking) rpc calls back to the server. When using blocking calls the
  entire browser freezes which is especially bad give responses arenot
  instantwous.

 I was suggesting the use of continuations to _mimic_ blocking calls
 but allow the thread to continue.  Then from your Java code you would
 not need to worry about passing in a callback to every service method.

 


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

[gwt-contrib] Re: faster size breakdown with non-fractional billing

2009-08-03 Thread Bruce Johnson

Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag more
like -style in that it has multiple values rather than having two separate
flags? Or is there a rationale for this style that I'm missing.
When Bob V's permutation control changes land, we want to make all of this
sort of stuff fall into the category of deferred binding properties, so that
you could, for example, create one permutaiton with style PRETTY, another
with style DETAILED, etc. Having the -soyc flag follow a name/value pattern
would make it more amenable to this change.

On Mon, Aug 3, 2009 at 8:53 AM, kpro...@google.com wrote:


 On 2009/07/16 22:28:18, Lex wrote:


 I think this is a great step forward.  This version of Soyc is much more
 intuitive, and will make it much easier to explain.  There are a couple
 of things that occurred to me, but otherwise it LGTM:

 1. Is the detailed output truly a more detailed version of the version
 that uses JavaToJavaScriptMaps?  I think that because of inlining, etc.,
 and the resulting partial billing, you will end up with different
 cumulative sizes for fragments.  This is probably fine, but if I were
 using Soyc and wanted to get more detailed information, and got
 different numbers, I would think that there is a bug.  How can we set
 expectations correctly?

 2) I'm not the biggest fan of having two compiler flags, -soyc and
 -soycExtra, but if you are, then it's fine.

 A few small comments are in the code.

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

 


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

[gwt-contrib] Re: faster size breakdown with non-fractional billing

2009-08-03 Thread Bruce Johnson

Based on what you said, I like a lot as is. Thanks for explaining it.

On Mon, Aug 3, 2009 at 2:52 PM, Lex Spoon sp...@google.com wrote:

 On Mon, Aug 3, 2009 at 1:58 PM, Bruce Johnsonbr...@google.com wrote:
  Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag
 more
  like -style in that it has multiple values rather than having two
 separate
  flags? Or is there a rationale for this style that I'm missing.
  When Bob V's permutation control changes land, we want to make all of
 this
  sort of stuff fall into the category of deferred binding properties, so
 that
  you could, for example, create one permutaiton with style PRETTY, another
  with style DETAILED, etc. Having the -soyc flag follow a name/value
 pattern
  would make it more amenable to this change.

 There is no immediate use case for the detailed information.  However,
 I hated to remove all that code when we might need it later.  Thus, I
 left -soyc as the normal use case, and added -XsoycExtra for those use
 cases that might conceivably need it in the future.  It's not a
 documented option, and it's not listed when you run the compiler with
 -help.

 How does that sound, Bruce and Kathrin (and anyone else interested)?

 It seems very helpful if -soyc is the only option users need to
 supply.  There is even talk of having the -soyc option go ahead and
 run the dashboard generator, thus giving you final HTML output without
 needing to add the second step.


 On a related note, I agree with Kathrin that it's not precisely
 detailed or extra information that this flag gives you.  It's
 different information, different enough that you can't compute one
 from the other.  I named it extra in a hurry.  Can anyone think of
 anything that would be less misleading?


 -Lex


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

[gwt-contrib] Re: Web mode stack traces - propose stackElement.getFileName() return 'JavaScript' instead of 'Unknown'

2009-07-31 Thread Bruce Johnson

I prefer Unknown because it's an indication you are looking at suboptimal
stack trace output. JavaScript makes it sound like we actually intend for
you to be looking at that output, when in fact, you really want to use
symbol maps to reverse lookup the Java idents.
On Fri, Jul 31, 2009 at 2:42 PM, Fred Sauer fre...@google.com wrote:

 Web mode stack traces are steadily improving. You can even get line numbers
 (by inheriting com.google.gwt.core.EmulateJsStack).

 Without the extra instrumentation you web mode stack traces might look
 something like this:
 at Unknown.$NullPointerException()
 at Unknown.onClick_6()
 at Unknown.dispatch()
 at Unknown.$fireEvent()
 at Unknown.$fireEvent_0()
 at Unknown.$fireEvent_1()
 at Unknown.fireNativeEvent()
 at Unknown.onBrowserEvent()
 at Unknown.dispatchEventImpl()
 at Unknown.dispatchEventAndCatch()
 at Unknown.anonymous()

 I was thinking it might make slightly more sense if we replaced 'Unknown'
 with 'JavaScript', e.g.

 at JavaScript.$NullPointerException()
 at JavaScript.onClick_6()
 at JavaScript.dispatch()
 at JavaScript.$fireEvent()
 at JavaScript.$fireEvent_0()
 at JavaScript.$fireEvent_1()
 at JavaScript.fireNativeEvent()
 at JavaScript.onBrowserEvent()
 at JavaScript.dispatchEventImpl()
 at JavaScript.dispatchEventAndCatch()
 at JavaScript.anonymous()


 Anyone have strong opinions wither way?

 --
 Fred Sauer
 Developer Advocate
 Google Inc. 1600 Amphitheatre Parkway
 Mountain View, CA 94043
 fre...@google.com




 


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

[gwt-contrib] Re: Web mode stack traces - propose stackElement.getFileName() return 'JavaScript' instead of 'Unknown'

2009-07-31 Thread Bruce Johnson

)



 On Fri, Jul 31, 2009 at 5:00 PM, Fred Sauer fre...@google.com wrote:

 I can't wait!


 On Fri, Jul 31, 2009 at 4:58 PM, Bruce Johnson br...@google.com wrote:

 4 cheers for Bob! w00t, w00t, w00t and w00t.
 Also, note that this is phase 1 in a larger plan. For Bob's next feat of
 magic, he's going to provide better control over permutations, allowing you
 to, say, include the (expensive) stack traces below for only a small
 percentage of users -- as well as all sorts of other cool, unrelated
 things that involve carving up your permutation space more powerfully


 On Fri, Jul 31, 2009 at 4:36 PM, Ray Cromwell cromwell...@gmail.comwrote:



 On Fri, Jul 31, 2009 at 4:33 PM, Fred Sauer fre...@google.com wrote:


 You get the following, which notably can be pasted into Eclipse's
 Stack Trace Console view so that the filename:lineNumber pairs become
 clickable hyperlinks:



 That's just awesome beyond belief.









 --
 Fred Sauer
 Developer Advocate
 Google Inc. 1600 Amphitheatre Parkway
 Mountain View, CA 94043
 fre...@google.com






 --
 Fred Sauer
 Developer Advocate
 Google Inc. 1600 Amphitheatre Parkway
 Mountain View, CA 94043
 fre...@google.com




 


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

[gwt-contrib] Re: patch to enable web tests using HtmlUnit

2009-07-30 Thread Bruce Johnson

Fantastic!

On Thu, Jul 30, 2009 at 1:52 PM, Ray Ryan rj...@google.com wrote:

 WAHOO!


 On Thu, Jul 30, 2009 at 1:48 PM, Amit Manjhi amitman...@google.comwrote:

 Thanks Scott. Commited the changes at r5844 with a fix the first thing and
  a TODO for the second thing.

 On Thu, Jul 30, 2009 at 10:48 AM, sco...@google.com wrote:

 LGTM with nits.


 http://gwt-code-reviews.appspot.com/54809/diff/1096/1130
 File user/src/com/google/gwt/junit/JUnitShell.java (right):

 http://gwt-code-reviews.appspot.com/54809/diff/1096/1130#newcode220
 Line 220: + e.g. IE6,IE7,FF2,FF3...;
 Could the exact list be gotten from RunStyleHtmlUnit?  Then you don't
 need to update this message if the set of browsers changes.

 http://gwt-code-reviews.appspot.com/54809/diff/1096/1129
 File user/src/com/google/gwt/junit/RunStyleHtmlUnit.java (right):

 http://gwt-code-reviews.appspot.com/54809/diff/1096/1129#newcode149
 Line 149: threads.add(hut);
 Is there any way to, say, pause here waiting for the other thread to get
 to an okay state that would could call a successful launch?  Might be
 nice to detect  report errors early.


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






 


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

[gwt-contrib] Re: Force emulated stack traces when running JUnit tests?

2009-07-23 Thread Bruce Johnson

Yes, I think we would want to. My point is that we also would want to run
the non-instrumented code. I have to think there could be subtle downstream
behavioral differences (e.g. compiler optimizations that do/don't happen)
based on whether the stack trace code is generated. Thus, I'm saying we
should test both.

On Thu, Jul 23, 2009 at 1:09 PM, BobV b...@google.com wrote:


  Technically, wouldn't it just mean we should not pin down the value of
 the
  deferred binding property that controls it? It would double the number of
  permutations, tho.

 But wouldn't we actually want to run the instrumented code, to make
 sure that the instrumentation itself doesn't break something?

 --
 Bob Vawter
 Google Web Toolkit Team

 


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

GWT 1.7 Now Available

2009-07-22 Thread Bruce Johnson

Hi everyone,

(Most people are probably already quite aware of the new GWT 1.7 release,
but we wanted to send out an official announcement we could pin to the top
of the message list.)

GWT 1.7 is a minor update that adds better support for Internet Explorer 8,
Firefox 3.5, and Safari 4. Each of these new browser versions introduced at
least one change that negatively impacted compiled GWT modules, so we
recommend that you do update to GWT 1.7 and recompile your existing
applications to ensure that they work with the latest versions of browsers.
No source code changes on your part should be required.

Normally, a minor update such as this would have been named 1.6.5 (the
previous latest version of GWT was 1.6.4), but we did add the value ie8 to
the user.agent deferred binding property, which could impact projects
using custom deferred binding rules that are sensitive to that property.
Thus, we went withGWT 1.7 rather than GWT 1.6.5, to indicate that you may
need to pay attention to that change. Details are in the release notes.

In every other respect, this is just a bugfix release, so in the vast
majority of cases, the update-recompile process should be nearly effortless.

Download here:
http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=GWT+1.7.0

Cheers,
Bruce, on behalf of your friendly GWT Team

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Generators and hosted mode refresh

2009-07-22 Thread Bruce Johnson

@Scott: Hasn't there been a subtle shift in this regard? With GWT 1.5,
didn't we conclude that loading classes at least for annotations would make
the most sense?
I think now that we have enhanced the CCL, for deRPC, to delegate to grey
area classes that aren't strictly in the client space, maybe we actually
could run generators in the CCL.

On Wed, Jul 22, 2009 at 10:24 AM, Brian Stoler bsto...@google.com wrote:

 Hi Scott,
 Gin uses reflection because it reuses the heavy lifting from Guice, which
 is not GWT-aware.

 Seems like both issues could be resolved if generators were loaded in the
 client code ClassLoader. Is there a technical or philosophical problem with
 doing so? I can understand it might not be at the top of the priority list
 right now, but wanted to know if it would be a bad thing if someone were to
 propose a patch.

 -brian


 On Wed, Jul 22, 2009 at 7:20 AM, Scott Blum sco...@google.com wrote:

 Generally speaking, you do not want to use reflection inside a generator
 to try to view the client code.  That's what TypeOracle is for, that's the
 supported way of viewing client code.
 As for the separate issue of modifying and recompiling a generator itself
 while running, you're right in that we don't explicitly support it.  Using
 unit tests during generator development as you suggest sounds like a good
 strategy to me.  In some cases, you might also get your IDE to do a
 hot-replace if you modify the code while debugging, but this can be flaky.

 On Wed, Jul 22, 2009 at 6:45 AM, Alen Vrecko alen_vre...@yahoo.comwrote:


 Hi,

 continuing from
 http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/c65457fa4df351c1
 . Sorry for the added garbage could have known better to post it here
 in the first place.

 I see generators as en extension to client code therefore I expect
 them to behave a bit like client code namely refresh recompiles the
 generator and client class code changes are visible to the generator.

 As recompiling the generator feature goes maybe it is a bit like
 fairytale i.e. not really needed. Will just write the unit tests for
 generators in any case before running the hosted mode and not play
 with the generator on the fly with change code shutdown-start hosted
 mode repeat.

 But seeing the latest class files inside generator is needed for
 refresh to work in some cases. Sure you can do much with TypeOracle
 but you can't instantiate the JType. Afaik there is no bridge between
 a JType and Class type.

 What do you think?

 Cheers
 Alen





 


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

[gwt-contrib] Re: Force emulated stack traces when running JUnit tests?

2009-07-22 Thread Bruce Johnson

On Wed, Jul 22, 2009 at 4:57 PM, Scott Blum sco...@google.com wrote:

 On Wed, Jul 22, 2009 at 4:46 PM, BobV b...@google.com wrote:

 Should running a web-mode test case always turn on the emulated stack
 trace code?


Would always on mean that it generates code even for browsers that have
native stack traces (i.e. FF)?

Generally, as much as I hate to say it, it seems we'd want variations of the
tests both with and without stack trace code, so that we don't inadvertently
break one mode or the other. It is much like -draftCompile in this
respect.

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

[gwt-contrib] GWT 1.7 Now Available

2009-07-13 Thread Bruce Johnson

Hi everyone,

GWT 1.7 is a minor update that adds better support for Internet Explorer 8,
Firefox 3.5, and Safari 4. Each of these new browser versions introduced at
least one change that negatively impacted compiled GWT modules, so we
recommend that you do update to GWT 1.7 and recompile your existing
applications to ensure that they work with the latest versions of browsers.
No source code changes on your part should be required.

Normally, a minor update such as this would have been named 1.6.5 (the
previous latest version of GWT was 1.6.4), but we did add the value ie8 to
the user.agent deferred binding property, which could impact projects
using custom deferred binding rules that are sensitive to that property.
Thus, we went with GWT 1.7 rather than GWT 1.6.5, to indicate that you may
need to pay attention to that change. Details are in the release notes.

In every other respect, this is just a bugfix release, so in the vast
majority of cases, the update-recompile process should be nearly effortless.

Download here:
http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=GWT+1.7.0

Cheers,
Bruce, on behalf of your friendly GWT Team

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

[gwt-contrib] Re: SOYC generates more dependency trees

2009-07-06 Thread Bruce Johnson

On Mon, Jul 6, 2009 at 10:11 AM, kpro...@google.com wrote:

 I see two options: a) a
 full-blown query language (far off, but would be very cool), or b) a UI
 driven by use cases and/or specific questions, which we spell out
 explicitly for the user, either in the UI itself or else in an
 accompaying doc. What do you think?


We can break it into phases. For GWT 2.0, we ought to polish up the
aesthetics of what we already have. Post-2.0, I think a query language makes
the most sense, but only if it is a reasonable amount of effort (a few
weeks). Once we have a query engine on SOYC data, then we can build any kind
of out-of-the-box HTML reports we want, formulated as a set of canned
queries.

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

Re: Horizontal tabs in a TabPanel

2009-06-30 Thread Bruce Choi


Just looked at some of the option avaliable, I think i'm going to add
options into a stackpanel then putting the tabl panel and stackpanel
into a dock panel. Just wondering how to incorporate it so everything
looks awhole is it all done through a CSS?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Horizontal tabs in a TabPanel

2009-06-29 Thread Bruce Choi


Instead of having the tabs in a tab panel alight to the top left
corner, is there anyway to align them to the right?

(not right hand corner but to the right-hand side)

Kinda like what they're doing right now with this discussion group...?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Error installing GWT plugin for Eclipse

2009-06-28 Thread Bruce Choi


I can't the eclipse pligin to instal... i keep getting this error!

http://i616.photobucket.com/albums/tt248/chukkii_2009/error-1.jpg

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Make i18n generator use ResourceOracle

On Wed, Jun 24, 2009 at 1:59 PM, Scott Blum sco...@google.com wrote:

 Lots.  Like, a whole lot.  I had a measurement at one time but lost them.
 :(  Would take a while to remeasure.


Sold.

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

[gwt-contrib] Re: naming runAsync calls

On Wed, Jun 24, 2009 at 5:08 PM, Lex Spoon sp...@google.com wrote:

 Thoughts?  The main downside I know of is the one John Tamplin has
 pointed out: if there are multiple runAsync calls within a single
 class -- as sometimes happens -- then the programmer has to code up
 some new classes that will only be used for naming.  Can we live with
 that?


I think so. It's less anxiety-inducing to create a class as a moniker (even
if it's a bit artificial) rather than fret about picking a good string
literal (will it collide?, what naming scheme should I use?, I wish I
hadn't used that other naming scheme in that other part of the code...should
I go fix it up right now?). Plus, your IDE can help you create moniker
classes and, when needed, efficiently rename/refactor them.

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

[gwt-contrib] Re: naming runAsync calls

Four additional arguments in favor of using split point moniker classes is
that they
1) are easier to find within an IDE (i.e. Show References in your IDE from
a moniker class declaration would show you the associated runAsync call),
2) can take advantage of inheritance as a way to group split points into
meaningful families (which would make them more easily browsable and
navigable in javadoc and in an IDE),
3) can be javadoc'ed to explain what they do, and
4) they could potentially be augmented with additional hints to the code
splitter using annotations (these are a stretch; Lex might be able to think
of more realistic example annotations)

/**
 * Split points in this hierarchy relate to the email functionality within
the office suite.
 */
class EmailSplitPoint extends OfficeSuiteSplitPoint {
}

/**
 * This split point carves out all heavyweight functionality related to
composing emails,
 * most importantly, the rich text area clases.
 */
@ProhibitPreloading
@MustBeExclusiveFragment
class EmailCompositionSplitPoint extends EmailSplitPoint {
}

// ... elsewhere ...

void onComposeButtonClicked() {
  GWT.runAsync(EmailCompositionSplitPoint.class, new AsyncCallback() {
public void onError(Throwable e) { ... }
public void onSucess() {
  new EmailCompositionView().activate();
}
  });
}

On Wed, Jun 24, 2009 at 6:50 PM, Cameron Braid came...@braid.com.au wrote:

 Each of these different libraries would be enclosed within a unique GWT
 module therefore when you refer to the split point name, can't you just use
 the module name + split point name ?

 in module ThirdParty :

 GWT.runAsync(one, new RunAsyncCallback() { ... });

 in MyModule :

 GWT.runAsync(one, new RunAsyncCallback() { ... });

 extend-configuration-property name=compiler.splitpoint.initial.sequence
 value=MyModule#one /
 extend-configuration-property name=compiler.splitpoint.initial.sequence
 value=ThirdParty#one /

 Cam

 2009/6/25 Lex Spoon sp...@google.com


 On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoonsp...@google.com wrote:
  Overall, unless I missed something,

 Okay, Bruce pointed out a new constraint to me: if different libraries
 name their runAsync calls, then we want to able to refer to those
 calls reliably even if different libraries choose the same name.  This
 isn't an issue immediately, but it likely will be in the future.

 Thinking about libraries, I would add another constraint: we don't
 want libraries to have to expose their implementation.  Library
 writers should ideally be able to document a named runAsync call
 without exposing the precise arrangement of their internal classes.

 After some discussion at the office, a tweak to option 4 fixes things
 up handily.  Instead of passing in a string to the method, act like a
 Java framework and require passing in a class literal.  A typical use
 in application code would pass in the enclosing top-level class:

 package org.foodity.impl;
 class Cookies {
  ...
  GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
  ...
 }

 A library writer could instead specify a public class, so as not to
 expose their internal factoring.

 A user of the name in a gwt.xml file would use the fully qualified
 version:

 extend-configuration-property
  name=compiler.splitpoint.initial.sequence
  value=org.foodity.impl.Cookies /

 A user in another Java file would use imports to make the name short:

 import org.foodity.impl.Cookies;

 RunAsyncQueue.startPrefetching(Cookies.class);


 Thoughts?  The main downside I know of is the one John Tamplin has
 pointed out: if there are multiple runAsync calls within a single
 class -- as sometimes happens -- then the programmer has to code up
 some new classes that will only be used for naming.  Can we live with
 that?

 Lex




 


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

[gwt-contrib] Re: naming runAsync calls


 I guess the compiler would have to verify that each call to runAsync uses a
 unique moniker - is there anything else ?


I think that's it. Pretty easy to check, and pretty easy for a developer to
reason about, too.

Must the moniker class exists in your own module ?


I don't think it ought to be so restricted unless anyone can think of a
reason to. It would actually be a good bit harder to implement to enforce
that rule.


 Would you only allow leaf classes to be used as monikers, i.e. could you
 use OfficeSuiteSplitPoint.class as a moniker ?


This would also work, although it's still too new an idea to say whether it
would be wise to use such a pattern in practice.

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

[gwt-contrib] Re: i18n support for concrete default locale

2009-06-23 Thread Bruce Johnson

Apologies that I'm wy late to this party, but the whole template
search/replace thing doesn't seem ideal in that something like a typo in the
template name could cause some seriously hard-to-debug code.

Did you consider the case that if a property provider returns null, then the
fallback would get used? I like that idea because (1) it doesn't rely on
textual search/replace and (2) it seems like a good pattern to form the
basis of property provider chaining, which is a long-standing problem for
properties that get extended. That is, if a derived module extends a
property, it usually wants to also extend the property provider, which today
involves brittle copy/paste. It would be great to figure out some protocol
for calling each property provider -- most-derived to least -- such that the
first one that return non-null is taken to be the official answer, and
returning null means ask the next most derived provider for this same
property.

-- Bruce

On Mon, Jun 15, 2009 at 11:03 PM, Freeland Abbott fabb...@google.comwrote:

 Revision to the concept, for design review: See
 http://code.google.com/p/google-web-toolkit/wiki/DefaultLocaleBinding, but
 the short-and-sweet is:

- Introduction of XML tag set-property-fallback name=*propname*
value=*fallbackString*/.  It's fine, and expected, to set this zero,
one, or many times for any given property.
- A new field gets added in BindingProperty, with setter and getter,
and a default value of empty string
- getPropertyProvider() is rewritten to return, not the literal
property provider string, but the result of replacing all instances of
/*-FALLBACK-*/ with the fallback string, whether empty or otherwise.
- For my default locale use case, our I18N.gwt.xml sets the locale
fallback to default, and user code sets it to something real if the user
doesn't like that.


 On Wed, Jun 10, 2009 at 11:49 AM, Freeland Abbott fabb...@google.comwrote:

 Yes, he and I already discussed it.  I was initially trying to avoid
 needing a new XML tag when the existing one was such a near fit, but the
 legacy linker support issues convinced me we needed it.




 On Tue, Jun 9, 2009 at 5:37 PM, Bruce Johnson br...@google.com wrote:

 I like what jat said. Freeland?

 On Tue, Jun 9, 2009 at 5:33 PM, j...@google.com wrote:


 The alternative to this would be Bruce's suggestion of defining a
 specific fallback value for a selection property rather than using
 config properties for it.  That would narrow the scope to exactly what
 we know we want to support and simplify the linker changes and avoids
 the breaking API change for existing linkers (where they have to supply
 the config properties to avoid breaking, which means the same linker
 can't work for GWT 1.6 and GWT 2.0).

 Something like:
   set-property-fallback name=locale value=default/
 and the last set value wins.


 http://gwt-code-reviews.appspot.com/34832/diff/1/2
 File

 dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/2#newcode194
 Line 194: new TreeSetConfigurationProperty());
 It seems like allowing this could cause incorrect behavior.  I know it
 is a tradeoff of not breaking existing code, but if there is a linker
 which calls this method, any code depending on config property lookup
 will just break.

 http://gwt-code-reviews.appspot.com/34832/diff/1/2#newcode223
 Line 223: }
 It looks like we are just substituting the empty string for unknown
 properties, which is especially bad if the call is relayed through the
 above method.

 http://gwt-code-reviews.appspot.com/34832/diff/1/4
 File dev/core/src/com/google/gwt/dev/cfg/StaticPropertyOracle.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/4#newcode149
 Line 149: for (String v : prop.getAllowedValues()) {
 setValues.addAll(cprop.getAllowedValues())?

 Also, maybe this should be computed in getPossibleValues() instead.

 http://gwt-code-reviews.appspot.com/34832/diff/1/5
 File
 dev/core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/5#newcode127
 Line 127: for (String v : cprop.getAllowedValues()) {
 setValues.addAll(cprop.getAllowedValues())?

 Also, maybe this should be computed in getPossibleValues() instead.

 http://gwt-code-reviews.appspot.com/34832/diff/1/7
 File user/src/com/google/gwt/i18n/I18N.gwt.xml (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/7#newcode51
 Line 51: $wnd['__gwt_Locale'] = locale ||
 '/*-GWTCONFIGPROP(default.locale)-*/';
 I think we haven't nailed this down enough that we want anyone else
 using it and expecting it to keep working.  So, I would suggest a
 comment here to that effect.

 http://gwt-code-reviews.appspot.com/34832/diff/1/7#newcode55
 Line 55: return /*-GWTCONFIGPROP(default.locale)-*/;
 Since these can all be empty strings, I would suggest storing
 /*-GWTCONFIGPROP(default.locale)-*/ || 'default

[gwt-contrib] Re: i18n support for concrete default locale

2009-06-23 Thread Bruce Johnson

It couldn't have been that easy. Surely someone disagrees?

On Tue, Jun 23, 2009 at 11:57 AM, John Tamplin j...@google.com wrote:

 On Tue, Jun 23, 2009 at 11:52 AM, Freeland Abbott fabb...@google.comwrote:

 I like the general idea, yes.

 A complication is that one of the changes John asked for, specific for the
 i18n provider, was to return */*-FALLBACK-*/ || default*, with the idea
 that a null/undefined fallback should be gracefully handled, since an
 invalid locale return is going to break the generators.  I'm personally a
 bit less concerned there (user both overrode the default and also
 misconfigured = generator should test for and gracefully explain), but in
 the i18n case we do have a fallback fallback to return, so I said okay.
 That wouldn't work for chaining, first because you don't always have such a
 fallback, and second because with a chain you couldn't put the fallback into
 the provider, and having set-property-fallback-fallback / or
 set-property-fallback exponent=n ... / is silly.


 Maybe if null gets all the way beck to the top, just replace it with an
 empty string, and the i18n code should treat that equivalently to default
 (it already does in many places).

 --
 John A. Tamplin
 Software Engineer (GWT), Google


 


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

[gwt-contrib] GWTTestCase/JUnit tweak to make mixing TestCase and GWTTestCase easier

2009-06-23 Thread bruce


Reviewers: scottb, amitmanjhi,

Description:
This patch treats any GWTTestCase-derived classes that return 'null'
from getModuleName() as if they were simply pure Java tests.

Why does this matter? Suppose you're writing tests for code that has
both a pure Java implementation and a super-sourced version of the same
types. Naturally, you want to re-use the same tests for both
implementations. With this patch, you can have the common tests extend
GWTTestCase but return 'null' from getModuleName(), thus causing the
pure Java version of the code to be tested. Then you can create a
subclass that actually does return a module name, which causes the same
tests to run in a proper GWT environment.


Please review this at http://gwt-code-reviews.appspot.com/47804

Affected files:
   user/src/com/google/gwt/junit/client/GWTTestCase.java
   user/src/com/google/gwt/junit/tools/GWTTestSuite.java



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

[gwt-contrib] Re: GWTTestCase/JUnit tweak to make mixing TestCase and GWTTestCase easier

2009-06-23 Thread Bruce Johnson

Thanks, r5617.

On Tue, Jun 23, 2009 at 8:23 PM, amitman...@google.com wrote:

 LGTM with one inline comment and one design question Is it better to
 have a special case handling of null or is it better to introduce a
 default non-null value for this purpose?


 http://gwt-code-reviews.appspot.com/47804/diff/1/3
 File user/src/com/google/gwt/junit/client/GWTTestCase.java (right):

 http://gwt-code-reviews.appspot.com/47804/diff/1/3#newcode122
 Line 122: */
 Update the javadoc with the null use case?


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


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

[gwt-contrib] Re: naming runAsync calls

2009-06-22 Thread Bruce Johnson

Great writeup. Thanks for bringing some organization to the thread. I agree
with you that #1 seems overall best after the analysis.
Now can we bikeshed about the annotation name? @RunAsyncName() seems harder
to understand than something that says code splitting, such as
@SplitPointName(Foo). After all, we do call these things split points.

On Mon, Jun 22, 2009 at 5:08 PM, Lex Spoon sp...@google.com wrote:


 Okay, we now have a suite of options.  Does anyone see any
 particularly strong reason to pick among them?

 The options I see are:
 1. Annotate the surrounding method with something like @RunAsyncName(Foo)
 2. Use the fully-qualified method name surrounding the call.
 3. Use the fully-qualified type name of the callback object.
 4. Use a new parameter to runAsync indicating the name.

 #2 is what's in trunk right now, but it is quite verbose.  I think we
 shouldn't stick with that unless we can make it more concise.  One way
 to do htat would be to make JSNI references more concise if they refer
 to a method that isn't overloaded.  We could let * be used as the
 parameter list in that case.  As much as I like that idea, it would
 take a few days to implement, so the opportunity cost would be high.

 For #3, it's not necessarily unambiguous, as pointed out.  Thus, it
 loses one of the main feature of #2.  Additionally, it looks harder to
 spec to me.  We would have to tell people something like: to name a
 runAsync call, make sure to put the call within a method with at least
 one argument, and then specify the type of that first argument.  Can
 anyone tighten up that spec and make it competitive?

 Overall, both #2 and #3 take extra work compared to the others.  #2
 requires implementation work, and #3 requires at the least some extra
 working to spec it.

 #1 and #4 both look good to me, though I admit a slight preference for
 #1.  That slight preference is mainly because it would mean we get to
 stick with a single GWT.runAsync method in the magic GWT class, which
 seems better for a few small reasons.  That said, we could certaily go
 that route if there's a reason to prefer it.

 Thoughts welcome.  I still think the annotations (option 1) look good,
 but don't want to push for that it if will cause some trouble or miss
 some opportunity.  Is there a reason to prefer 4 over 1?  Is 2 or 3
 worth the extra work, or else, does anyone see how to make 2 or 3
 easier to implement?


 Lex

 


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

[gwt-contrib] Re: naming runAsync calls

2009-06-22 Thread Bruce Johnson


+1 Ian! Great point. Not sure why we didn't think of that before.

On Monday, June 22, 2009, Ian Petersen ispet...@gmail.com wrote:

 On Mon, Jun 22, 2009 at 2:08 PM, Lex Spoonsp...@google.com wrote:
 The options I see are:
 1. Annotate the surrounding method with something like @RunAsyncName(Foo)
 2. Use the fully-qualified method name surrounding the call.
 3. Use the fully-qualified type name of the callback object.
 4. Use a new parameter to runAsync indicating the name.

 One possible refinement to option 1, since it seems likely to win:
 put the annotation on the onSuccess rather than on the method that
 contains the runAsync invocation.

 Here's what I mean:

    // ... surrounding code ...
    GWT.runAsync(new AsyncCallback() {

      public void onFailure(Throwable caught) {
        // deal with failure
      }

      @SplitPointName(I like Bruce's idea)
      public void onSuccess() {
        // deal with success
      }
    });
    // ... surrounding code ...

 I'm not sure if it's better or worse, but it seems more flexible than
 requiring a surrounding method.

 To be a little bit forgiving to the developer, you could make it a
 compile-time warning if onFailure is annotated and an error if both
 onFailure and onSuccess are annotated with different names--it makes
 the generator code more complex but lets the user be a little bit
 forgetful.  Not sure if that's really necessary, though.

 Ian

 


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

[gwt-contrib] Re: naming runAsync calls

2009-06-19 Thread Bruce Johnson

A slight tweak to what Ian said: What if we got this effect by simpy
requiring you to use interfaces that extend
AsyncCallback as a way to reify split points?
interface EmailCompositionView extends AsyncCallback {
   ...
}

Then you definitely have a fully-qualified name for a split point if you
need it: the name of the interface itself. My worry about Ian's proposal is
that method overloading complicate things (would you use JSNI-style refs to
disambiguate?). And my worry with user-assigned names is that actually may
conflict, when you consider that library writers probably will want to ship
libraries with split points. Again, using interfaces guarantees we don't
introduce a new axis of name conflict.

-- Bruce

On Fri, Jun 19, 2009 at 11:44 AM, Ian Petersen ispet...@gmail.com wrote:


 On Fri, Jun 19, 2009 at 8:33 AM, Lex Spoonsp...@google.com wrote:
  This looks like a straightforward and easily understood way to name
  calls to runAsync.  What do others think?

 As a brainstorm-quality idea, what about requiring that runAsync
 invocations are in their own methods (as you mentioned) but not
 requiring an annotation?  Any given method already has a fully
 qualified name (it's even globally unique within the program) so why
 introduce yet another name in the annotation?

 Some compiler magic to make this happen might be a nice-to-have:

 RunAsyncRef ref = new RunAsyncRef(ClassContainingMethod.class,
 methodName);

 You could statically determine that it's valid, use ref as a token to
 refer to fragments as necessary, and avoid having to specify
 package.ClassName.methodName because you take advantage of the import
 statements.  Dunno what you'd do with it, of course.

 Ian

 


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

Re: Two Questions around flex table sizing and

2009-06-18 Thread Bruce Petro

OK, I hate to answer my own question, but I think I found how to solve
question #2 - which more or less solves Question #1 (although if anyone has
another technique I'd love to hear about it).  So, if anyone else is
researching this - here's a solution to maintaining cell sizing after hiding
its contents.

Performing the following on the cell itself appears to then maintain it's
size after the link is hidden.

flexTable.getCellFormatter().setWidth( 0, 0, 150);


On Thu, Jun 18, 2009 at 4:33 PM, bpetro brucepe...@gmail.com wrote:


 I'm creating a header which has three columns - the middle of which is
 the main title.  The left is a logout link and the right is an
 image...

 Question1:  Is there a way to force centering the middle column to the
 page instead of just within the cell itself?  One approach is to
 ensure the cells on the left and right are equal sizes... is there
 another solution as well?

 Working on trying to make two outside cells being equal sizes leads to
 another question.  If I hide the logout link during the login screen
 - the remaining two cells shift around.  Is there a way to hide the
 contents of a cell but keep its sizing as is?

 THANKS!
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

++

 z = x + y


 you can rename each variable on assignment, yielding the following


 x1 = 1

 y1 = 2

 z1 = x1 + y1

 x2 = x1 + 1

 y2 = y1 + 1

 z2 = x2 + y2


 This produces an SSA-like form, with each variable defined only once. At
 first glance, it looks like a de-optimization, but a later pass that does
 constant folding, copy propagation, and dead elimination will clean this up.
 As an example, after copy propagation


 x1 = 1

 y1 = 1

 z1 = 1 + 2

 x2 = 1 + 1

 y2 = 2 + 1

 z2 = x2 + y2


 after constant folding

 x1 = 1

 y1 = 1

 z1 = 3

 x2 = 2

 y2 = 3

 z2 = x2 + y2


 after DCE (x1/y1/z1 no longer referenced)

 x2 = 2

 y2 = 3

 z2 = x2 + y2


 after copy prop

 x2 = 2

 y2 = 3

 z2 = 2 + 3


 after constant fold

 x2 = 2

 y2 = 3

 z2 = 5


 after DCE

 z2 = 5


 Finally, after renaming registers back to their original names

 z = 5


 A register allocation style pass can further eliminate temporaries later.


 However, do to proper CFA/DFA, we may want to build a real SSA form,
 complete with phi functions, so we may do cross-block optimizations.


 Effects on the Builder Pattern

 Another recent list discussion concerned optimizing the Builder Pattern.
 Flattening the AST and using SSA techniques can have a positive effect on
 this as well. Consider:


 Builder b = new Builder();

 b.setA(10).setB(20).setC(30);


 After conversion to static methods.

 setC(setB(setA(b, 10), 20), 30);


 Flattening/SSA:

 t1 = setA(b, 10)

 t2 = setB(t1, 20)

 t3 = setC(t2, 30)


 After inlining:

 b.A = 10;

 t1 = b;

 t1.B = 20;

 t2 = t1

 t2.C = 30

 t3 = t2


 After copy prop:

 b.A = 10

 t1 = b

 b.B = 20

 t2 = b

 b.C = 30


 After dead code elimination:

 b.A = 10

 b.B = 20

 b.C = 30


 On Tue, Jun 16, 2009 at 6:30 PM, Bruce Johnsonbr...@google.com wrote:
  Re: Wave access, I was really mostly just being playful, but I'll most
  certainly beg and plead to get this group early in the line if at all
  possible.
 
  Meanwhile, I agree with Cameron that we should make sure to discuss the
  major ideas here on the mailing list, even if some of the initial
 specifics
  are fleshed out in a wave. I definitely don't want people who don't yet
 have
  Wave accounts to feel penalized just because they weren't able to go to
 I/O.
  (But if you didn't go to I/O this year, I really hope you can next year
 --
  it's fantastic to meet together in person.)
 
  On Tue, Jun 16, 2009 at 9:22 PM, Cameron Braid came...@braid.com.au
 wrote:
 
  Unfortunately I wasn't able to attend Google I/O, however I did watch
 a
  few of the sessions online.
 
  I signed up for the sandbox, but it appears that google aren't going
 to
  grant access to non IO attendees for a little while yet.
 
  I'd appreciate an invite, but I understand if that's not feasible.
 
  Cheers
 
  Cameron
 
  2009/6/17 Ray Cromwell cromwell...@gmail.com
 
  Cameron, were you at Google I/O or did you sign up for the sandbox? I
 can
  ask a Googler to invite you if not.
  -Ray
 
  On Mon, Jun 15, 2009 at 6:21 PM, Cameron Braid came...@braid.com.au
 
  wrote:
 
  2009/6/16 Bruce Johnson br...@google.com
 
  I'm starting to make a bit o' progress on this. I'll send out a
 design
  doc real soon now.
 
  BTW, anyone on the Contributors list here have Wave sandbox
 accounts?
  Sure would be easier to discuss this in a wave...
 
  No :(
 
  But if you are offering invites, send one this way :)  Otherwise,
 its
  probably wise to keep the discussion in a place where all interested
 parties
  can participate.
 
 
  Cam
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 




 --
 Miguel




 


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

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

On Wed, Jun 17, 2009 at 1:16 PM, Ray Cromwell cromwell...@gmail.com wrote:

 One of the things that interested me about the potential of building a
 limited whole-program CFG was the ability to aggressively (and correctly)
 prune clinits. Now, if the eager clinit hoisting is acceptable, than this
 would be overkill, but if not, then the way to do it is to compute the
 immediate dominator hierarchy for each block.


I have to think that we should do eager clinit hoisting as a first step and
focus on just intraprocedural at first. We can always get better from there.
(I will argue in some future thread that up-front clinits is actually the
model Java ought to use anyway.)

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

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

On Wed, Jun 17, 2009 at 3:01 PM, Ray Cromwell cromwell...@gmail.com wrote:

 Bruce,  By type cloning, do you mean using typeflow information to compute
 a set of types for a given reference, and then speculatively type
 tightening?


I'm talking about something else, but you're right about the  Will explain
more in the bottom section.



 We can compute the set of potential concrete types for 'list' as
 {LinkedList, ArrayList}. Therefore, we can inline the call to list.get(n),
 as:


This is what Scott and Lex have been calling something like, set-base type
tightening.

If someNonInlineableMethod() is only ever reached from blocks where the
 parameter is ArrayList, then the 'l' parameter can be tightened to
 ArrayList. You need CFG/flow analysis because methodA(List l) might call
 methodB(List l) where the chain is only ever invoked with ArrayList.


We do a CFG-independent version of what you're talking about. We do tighten
parameter types, but only based on the (tightened) types of all the call
sites, without regard to control flow.

=== Type Cloning ===
What I mean by type cloning is this: for every unique (lexical) occurrence
of an allocation of type T, clone T into T' as if it were an independent
type, but arrange that T' is indistinguishable from T w.r.t. casts,
instanceof, and getClass(). In other words, you could never determine at
runtime that the object wasn't actually a genuine T. Now, optimize as
normal. To see how this could play out:

class BasicListE {

  private E[] elems;


  @SuppressWarnings(unchecked)

  public void add(E elem) {

if (elems == null) {

  elems = (E[]) new Object[] {elem};

} else {

  E[] newElems = (E[]) new Object[elems.length + 1];

  System.arraycopy(elems, 0, newElems, 0, elems.length);

  newElems[newElems.length - 1] = elem;

  elems = newElems;

}

  }


  public int size() {

return elems == null ? 0 : elems.length;

  }



  public IteratorE iterator() {

final int n = size();


return new IteratorE() {

  private final int i = 0;


  public boolean hasNext() {

return i  n;

  }


  public E next() {

return elems[i];

  }


  public void remove() {

// nothing

  }

};

  }

}

// Then in some other code, you could write...
void foo() {
  BasicListString b = new BasicListString();
  for (int i = 0, n = b.size(); i  n; ++i) {
// Removed by dead code elim.
  }

  for (String s: b) {
// Also removed by dead code elim.
  }
}

In the above, b is of type BasicList' (a clone of BasicList that can be
independently optimized). Thus, you can see that BasicList' does not have
the add() method called, which means that, for this particular use of the
type, the 'elems' field will always be null. Consequently, size() can be
statically known to return 0. Similarly, the iterator's hasNext() method can
be statically shown to always return false in the for/each loop.

The key point is that the usage of a type in one context would not affect
how the type itself could be optimized in other contexts. As it stands
today, we can't do the above optimization if anywhere in the program someone
calls BasicList#add(). A great practical example is Widgets firing events.
You want widgets to be *able* to fire events *if* someone actually wants to
listen to them. In the cases where you can see that there are no listeners
to a widget, you'd really like the entirely of the even-firing infrastructur
to completely disappear. So, I think it can be a big win.

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

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

Stefan, if it's really urgent, I would suggest just forking JsArray into
your own project packages for a while. They're simple enough that it won't
be much trouble to unfork when something better comes along -- the
collections I have in mind for core GWT are a little more ambitious, and so
they will inevtiably take longer than you'll want to wait.
On Wed, Jun 17, 2009 at 6:37 PM, Stefan Haustein haust...@google.comwrote:

 On Tue, Jun 16, 2009 at 12:54 AM, Stefan Haustein haust...@google.comwrote:

 Ray,

 I think we can improve the class over time -- any reasonable starting
 point (even without iterators or with non-optimal iterators) would help
 significantly.


 Ray,

 I am blocking on this for other size optimizations. Do you know when you
 would have some kind of starting point ready to submit?

 If it is still a while away, I'd like to move ahead with a copy of JsArray
 that is not limited to JSO content.

 Stefan



 Stefan


 On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell cromwell...@gmail.comwrote:

 BTW, the last proposal is very unsafe with some form of escape
 analysis since it is unsafe to pass references to classes which
 reference local scope to other scopes. Another possibility is a form
 of 'destructuring' of Iterator classes by inlining them completely
 into local scope vs escape analysis and then forgoing separate
 construction.

 A simpler way to maintain for-each with JRE collections without
 creating objects is to change the way that for-each deals with
 IterableT when T is a List.

 The compiler could change:
 for(T x : foo) { ... }

 where foo is a ListT

 into

 for(int i=0; ifoo.size(); ++i) {
   T x = foo.get(i);
 }

 instead of calling foo.iterator() and using Iterator methods.

 -Ray

 On Fri, Jun 12, 2009 at 7:31 PM, Ray Cromwellcromwell...@gmail.com
 wrote:
  I'm in the process of some final tweaks on GQuery, so I'll look at how
  much of my private JSArray class I can move over as a patch.
 
  One possibility for avoiding Iterator object creation without using
  flyweights is to introduce a new Iterator type which contains methods
  which are parameterized by the collection and which use my Extension
  Method/Category method JSO trick.
 
  public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS  list) {
   return (FastIteratorS)(GWT.isScript() ? makeWeb() :
 makeHosted());
}
 
private final native FastIterator makeWeb() /*-{
   return 0;
}-*/;
 
private final native FastIterator makeHosted() /*-{
  return [0];
}-*/;
 
public final  int value() {
  return GWT.isScript() ? valueWeb() : valueHosted();
}
 
public native int valueWeb() /*-{
  return this;
}-*/;
 
public native int valueHosted() /*-{
  return this[0];
}-*/;
 
public native hasNext(ListT list) {
  return value()  list.size();
}
 
public native T next(ListT list) {
  return list.get(value()++); // unsure if using value() as rvalue
  will work here
}
  }
 
  then you should be able to write code like
 
  ListString foo = getList();
  FastIteratorString iter = FastIterator.make(foo);
 
  while(iter.hasNext(foo)) {
   String s = iter.next(foo);
  }
 
  Why doesn't this create any additional objects? Because
  'iter'/FastIterator is actually a native JS number/scalar type, and
  what this is really doing is simulating the addition of
  hasNext()/next() to the number's prototype.
 
  We could dispense with the need for an additional parameter if GWT had
  a magic method for allocating new local variables/symbols in the local
  scope. Imagine if writing
 
  VariableT x = GWT.createVariable(0);
 
  was a magic method that just generated a 'var x = 0' declaration, only
  it promised to always be inlined and do so in the caller's scope.
  'Variable' would be a magic class that never creates fields on the
  actual object themselves and are pruned/removed at runtime.
 
  Then you could have FastIterator impersonate a reference to the
  underlying ListT, and rewrite hasNext()/next() as:
 
  VariableInt x = GWT.createVariableInt(0);
  public boolean hasNext() {
return x.get()  this.size();
  }
 
  public T next() {
return this.get(x.get()++); // or x.postIncrement()
  }
 
  this would produce code that would create no additional objects as
  well as maintain Iterator-like interface.
 
  -Ray
 
 
  On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
 wrote:
  +1 Ray
  Could you contribute your implementation(s)?
 
  On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com wrote:
 
  +1 Ray. Now here's the really tricky question. Is there any way we
 can
  take advantage of Javascript's for (x in y) { ... } syntax (and
 should we,
  given its spotty performance)? My intuition tells me that the only
 way we
  could use it would be through a callback, because there's nothing
 like .NET
  generators/yield in Javascript.
  On Wed, Jun

[gwt-contrib] Re: Reducing noise in GWT compiler output

2009-06-16 Thread Bruce Johnson

That would be marvelous. I hadn't thought through the implications of IHM,
but it seems like it might solve the problem.
What about types that aren't IHM compatible, such as those containing JSNI?
Could those still cause spurious errors?

On Tue, Jun 16, 2009 at 6:29 PM, Scott Blum sco...@google.com wrote:

 Instant hosted mode should really change the game, right?  We will no
 longer be speculatively compiling anything for TypeOracle since we'll be
 using class files that should already exist.


 On Mon, Jun 15, 2009 at 11:21 PM, John Tamplin j...@google.com wrote:

 On Mon, Jun 15, 2009 at 11:11 PM, Bruce Johnson br...@google.com wrote:

 We've known for a while that the GWT compiler is spammy, even at default
 log levels. There is a reason for this behavior, believe it or not:
 TypeOracle's JClassType#getSubtypes() call. Because generators can ask for
 the subtypes of any type, the compiler has to parse essentially everything,
 not just those types that are statically reachable from a module's entry
 point(s). We sometimes refer to it as speculative parsing. Overall, the
 behavior is vitally useful for code generators, especially RPC and I18n, and
 it's generally useful anytime you need to do something factory-like, where
 you might have used Class.forName() if it were available. So, I'm not
 proposing that we change that behavior. The problem is that in the process
 of speculatively parsing everything on the client source path, inevitably we
 end up encountering source files that can't actually be meaninfully compiled
 given the current client source path and other various reasons for
 mismatches. It can happen when you have more than one module.gwt.xml in
 the same location with different sets of inherited modules.
 We ought to find a way to keep quieter about problems we find during that
 speculative parse. We want to *not* spam the log when the source file was
 found speculatively but definitely still report errors when they really
 are relevant to getting a clean compile.

 This isn't as simple as it might sound. It isn't just a how do we code
 it question. Imagine you have a GWT module that needs RPC. Because RPC can
 use polymorphism, you might have an RPC method whose return type is Shape
 (vs. concrete subtypes Circle, Square, Triangle). This is handled magically
 in the GWT RPC generator because it can see those subtypes of Shape and
 quietly generate deserializers in the generated RPC proxy. The tricky bit is
 when Circle.java has a syntax error, say. The type Circle won't be found
 as a subtype of Shape in the type oracle, so the GWT RPC generator won't
 know to emit a deserializer for it. (To be precise, it won't even know that
 it *ought* to try to do so.) We have a choice: either we emit a string of
 non-fatal errors regarding the failure to parse Circle.java or we don't. If
 we do, we get the spam we hate today, but at least we've informed the
 developer that something fishy may happen, since it wasn't a perfectly clean
 compile. If we don't emit such errors, then a module will quietly appear to
 compile, even when there are compilation problems that might affect the
 intended behavior (in this case, when a server responds to the client with a
 Circle object, the client won't know how to deserialize it).

 All that said, I don't think it will be big a problem in practice if we
 log less and risk the kind of surprise failure I described with something
 like RPC. After all, javac (or your IDE) would complain about Cirlce.java
 not compiling anyway, so the only real failure mode happens if you *only*
 compile with the GWT compiler -- and that seems pretty unlikely, especially
 if you're working in an IDE.

 Here's a proposal for the new behavior. When the GWT compile invokes JDT
 to do the front-end compile, capture the errors in an in-memory data
 structure (keyed by type name?) but do not log them right away. After the
 JDT front-end compile settles, create a set of known statically reachable
 types from the entry point classes (the entry point classes are reachable
 from themselves by definition). Only log errors on compilation unit in that
 set of dependencies, and do not log errors in an other case.

 Anybody see any problems with this idea? I think this would omit log
 messages that make you say, What on earth does NumberFormat_fr_Test.java
 have to do with my compiling Hello.java?


 How does that fit with instant hosted mode?

 --
 John A. Tamplin
 Software Engineer (GWT), Google





 


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

[gwt-contrib] Re: Comment on OverlayTypes in google-web-toolkit

2009-06-15 Thread Bruce Johnson

+1 to field overlays. Just need to schedule the work.

On Mon, Jun 15, 2009 at 9:23 AM, BobV b...@google.com wrote:


 On Mon, Jun 15, 2009 at 7:26 AM, Joel Webberj...@google.com wrote:
  I'm assuming we'd have to rewrite new and field access operators to these
  classes in the hosted-mode classloader, right? I haven't messed with the
  hosted-mode classloader in a *very* long time, so we may be doing this
  already for all I know. If that's feasible, this sounds like it would be
  pretty useful. In particular, it seems that it would be particularly nice
  for JSON overlays.

 Rewriting get/setField opcodes to call into JsValueGlue wouldn't be
 any harder than anything else HostedModeRewriter currently does.

 --
 Bob Vawter
 Google Web Toolkit Team

 


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

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

2009-06-15 Thread Bruce Johnson

I'm starting to make a bit o' progress on this. I'll send out a design doc
real soon now.

BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure
would be easier to discuss this in a wave...

On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein haust...@google.comwrote:

 Ray,

 I think we can improve the class over time -- any reasonable starting point
 (even without iterators or with non-optimal iterators) would help
 significantly.

 Stefan


 On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell cromwell...@gmail.comwrote:

 BTW, the last proposal is very unsafe with some form of escape
 analysis since it is unsafe to pass references to classes which
 reference local scope to other scopes. Another possibility is a form
 of 'destructuring' of Iterator classes by inlining them completely
 into local scope vs escape analysis and then forgoing separate
 construction.

 A simpler way to maintain for-each with JRE collections without
 creating objects is to change the way that for-each deals with
 IterableT when T is a List.

 The compiler could change:
 for(T x : foo) { ... }

 where foo is a ListT

 into

 for(int i=0; ifoo.size(); ++i) {
   T x = foo.get(i);
 }

 instead of calling foo.iterator() and using Iterator methods.

 -Ray

 On Fri, Jun 12, 2009 at 7:31 PM, Ray Cromwellcromwell...@gmail.com
 wrote:
  I'm in the process of some final tweaks on GQuery, so I'll look at how
  much of my private JSArray class I can move over as a patch.
 
  One possibility for avoiding Iterator object creation without using
  flyweights is to introduce a new Iterator type which contains methods
  which are parameterized by the collection and which use my Extension
  Method/Category method JSO trick.
 
  public class FastIteratorT extends JavaScriptObject {
protected FastIterator() {}
public S, T extends ListS FastIteratorS make(TS  list) {
   return (FastIteratorS)(GWT.isScript() ? makeWeb() :
 makeHosted());
}
 
private final native FastIterator makeWeb() /*-{
   return 0;
}-*/;
 
private final native FastIterator makeHosted() /*-{
  return [0];
}-*/;
 
public final  int value() {
  return GWT.isScript() ? valueWeb() : valueHosted();
}
 
public native int valueWeb() /*-{
  return this;
}-*/;
 
public native int valueHosted() /*-{
  return this[0];
}-*/;
 
public native hasNext(ListT list) {
  return value()  list.size();
}
 
public native T next(ListT list) {
  return list.get(value()++); // unsure if using value() as rvalue
  will work here
}
  }
 
  then you should be able to write code like
 
  ListString foo = getList();
  FastIteratorString iter = FastIterator.make(foo);
 
  while(iter.hasNext(foo)) {
   String s = iter.next(foo);
  }
 
  Why doesn't this create any additional objects? Because
  'iter'/FastIterator is actually a native JS number/scalar type, and
  what this is really doing is simulating the addition of
  hasNext()/next() to the number's prototype.
 
  We could dispense with the need for an additional parameter if GWT had
  a magic method for allocating new local variables/symbols in the local
  scope. Imagine if writing
 
  VariableT x = GWT.createVariable(0);
 
  was a magic method that just generated a 'var x = 0' declaration, only
  it promised to always be inlined and do so in the caller's scope.
  'Variable' would be a magic class that never creates fields on the
  actual object themselves and are pruned/removed at runtime.
 
  Then you could have FastIterator impersonate a reference to the
  underlying ListT, and rewrite hasNext()/next() as:
 
  VariableInt x = GWT.createVariableInt(0);
  public boolean hasNext() {
return x.get()  this.size();
  }
 
  public T next() {
return this.get(x.get()++); // or x.postIncrement()
  }
 
  this would produce code that would create no additional objects as
  well as maintain Iterator-like interface.
 
  -Ray
 
 
  On Thu, Jun 11, 2009 at 7:25 AM, Stefan Hausteinhaust...@google.com
 wrote:
  +1 Ray
  Could you contribute your implementation(s)?
 
  On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber j...@google.com wrote:
 
  +1 Ray. Now here's the really tricky question. Is there any way we can
  take advantage of Javascript's for (x in y) { ... } syntax (and
 should we,
  given its spotty performance)? My intuition tells me that the only way
 we
  could use it would be through a callback, because there's nothing like
 .NET
  generators/yield in Javascript.
  On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell cromwell...@gmail.com
  wrote:
 
  My take on this is that there is many places where I'd like to avoid
  JRE collections, but the basic JsArray is too much of a downgrade. I
  don't mind changing it to T if it doesn't effect performance cause
  then I could subclass it, but as an example of the stuff I would like
  in a 'FastArrayList' that is not a collections derivative:
 
  1) add() instead of just set(length(), item) (e.g. push)
  2)

[gwt-contrib] Reducing noise in GWT compiler output

2009-06-15 Thread Bruce Johnson

We've known for a while that the GWT compiler is spammy, even at default log
levels. There is a reason for this behavior, believe it or not: TypeOracle's
JClassType#getSubtypes() call. Because generators can ask for the subtypes
of any type, the compiler has to parse essentially everything, not just
those types that are statically reachable from a module's entry point(s). We
sometimes refer to it as speculative parsing. Overall, the behavior is
vitally useful for code generators, especially RPC and I18n, and it's
generally useful anytime you need to do something factory-like, where you
might have used Class.forName() if it were available. So, I'm not proposing
that we change that behavior. The problem is that in the process of
speculatively parsing everything on the client source path, inevitably we
end up encountering source files that can't actually be meaninfully compiled
given the current client source path and other various reasons for
mismatches. It can happen when you have more than one module.gwt.xml in
the same location with different sets of inherited modules.
We ought to find a way to keep quieter about problems we find during that
speculative parse. We want to *not* spam the log when the source file was
found speculatively but definitely still report errors when they really
are relevant to getting a clean compile.

This isn't as simple as it might sound. It isn't just a how do we code it
question. Imagine you have a GWT module that needs RPC. Because RPC can use
polymorphism, you might have an RPC method whose return type is Shape (vs.
concrete subtypes Circle, Square, Triangle). This is handled magically in
the GWT RPC generator because it can see those subtypes of Shape and quietly
generate deserializers in the generated RPC proxy. The tricky bit is when
Circle.java has a syntax error, say. The type Circle won't be found as a
subtype of Shape in the type oracle, so the GWT RPC generator won't know to
emit a deserializer for it. (To be precise, it won't even know that it
*ought* to try to do so.) We have a choice: either we emit a string of
non-fatal errors regarding the failure to parse Circle.java or we don't. If
we do, we get the spam we hate today, but at least we've informed the
developer that something fishy may happen, since it wasn't a perfectly clean
compile. If we don't emit such errors, then a module will quietly appear to
compile, even when there are compilation problems that might affect the
intended behavior (in this case, when a server responds to the client with a
Circle object, the client won't know how to deserialize it).

All that said, I don't think it will be big a problem in practice if we log
less and risk the kind of surprise failure I described with something like
RPC. After all, javac (or your IDE) would complain about Cirlce.java not
compiling anyway, so the only real failure mode happens if you *only*
compile with the GWT compiler -- and that seems pretty unlikely, especially
if you're working in an IDE.

Here's a proposal for the new behavior. When the GWT compile invokes JDT to
do the front-end compile, capture the errors in an in-memory data structure
(keyed by type name?) but do not log them right away. After the JDT
front-end compile settles, create a set of known statically reachable
types from the entry point classes (the entry point classes are reachable
from themselves by definition). Only log errors on compilation unit in that
set of dependencies, and do not log errors in an other case.

Anybody see any problems with this idea? I think this would omit log
messages that make you say, What on earth does NumberFormat_fr_Test.java
have to do with my compiling Hello.java?

-- Bruce

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

[gwt-contrib] Re: DockLayoutPanel

2009-06-11 Thread Bruce Johnson

No, it's not checked in yet, but I think Joel might started a branch to land
it before t long.

It isn't literally the same code as in Wave, but it's logically equivalent.
Joel can say a lot more about it than me.

On Thu, Jun 11, 2009 at 5:36 PM, dflorey daniel.flo...@gmail.com wrote:


 Is the DockLayoutPanel presented at Google IO already in svn? The one
 that is being used by the wave client?
 I've not been able to find it...
 


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

[gwt-contrib] Re: Moving PagingScrollTable Friends to Trunk

2009-06-10 Thread Bruce Johnson

I'll be the bad guy and try to lower expectations: whatever we end up doing,
it has to be fast. We've seen some *horrible* usability problems with fancy
tables -- even at a small number of rows -- and so don't be surprised if we
have to pare back features and reduce API flexibility to ensure that a few
key use cases are sufficiently high performance.

-- Bruce

On Tue, Jun 9, 2009 at 10:12 AM, John LaBanca jlaba...@google.com wrote:

 We'll definitely keep these things in mind when moving stuff over to GWT
 trunk.  We've also found a lot of general usability problems, such as the
 fact the the table doesn't layout naturally, which means apps require active
 layout.  During the transfer, we'll refactor quite a few things to make them
 more usable.  Specifically, we'd like to provide a version that allows you
 to bulk renderer the header and footer into the same table element,
 eliminated the three separate tables and fixed layout.  You would lose the
 scrolling feature, but you would not have to use active layout.

 When we start moving stuff into trunk or while its in my branch (as in
 right now), thats a good time to point out specific problems or requests.
 Its much harder to change the API after we make an official release.

 Thanks,
 John LaBanca
 jlaba...@google.com



 On Tue, Jun 9, 2009 at 5:01 AM, David david.no...@gmail.com wrote:


 Jay,

 We are experiencing the same ideas here. We store column ordering and
 widths on the server but we have no way of getting events in the UI to
 know when changes have been complete.

 wouldn't it be nice that the dnd was included as well, I could really
 use the DND of columns! Was it hard to implement ? We did not yet
 bother to investigate since we have to focus on getting functionality
 complete first.

 David

 On Tue, Jun 9, 2009 at 10:00 AM, jayjay.gin...@gmail.com wrote:
 
  As I see that this has begun (yeah), I'd like to throw out a few
  requests:
 
   * Please, please, please -- ensure that this is as extensible as
  possible. Here's just one example--I've integrated the gwt-dnd library
  to allow drag-n-drop re-ordering of columns. There are a couple of
  funny corner cases, though, because I have no way of knowing when a
  column resize has completed. Obviously, if you're resizing the column,
  you're not interested in dragging it to a new location. I strongly
  encourage you to think three, four, five times about making a method
  private or package protected. Liberal use of JavaDoc with strongly
  worded warnings to those of us who need to customize the widgets. I
  know this cuts down on your ability to make under-the-cover changes
  from release to release, but it makes it so that folks like me don't
  have to resort to things like JSNI trickery or copying the entire
  class or set of classes into our own code base.
 
   * As a direct follow up to #1, fire some more events. For example,
  fire an event when a column resize starts and when it ends.
 
   * Flexibility is great, but often I'm just interested in the simple
  cases...simple. My example here is the multiple-row header stuff. It's
  GREAT! I LOVE it! (And better yet, our customers have been screaming
  for this!) But, I don't always need/want it. And, it can make things
  more complex. One idea would be to overload methods like getHeader()
  on AbstractColumnDefinition...add a version that doesn't take a 'row'
  parameter, and so just assumes there's only 1 row.
 
   * More use of generics, less casting (for me). Some examples:
 o AbstractColumnDefinition returns Object for the getHeader()
  method. Why not declare this as class
  AbstractColumnDefinitionRowType, ColType, HeaderType?
 o Rather than: public TableDefinitionRowType getTableDefinition
  (), how about adding a TABLE_DEFINITION type to the class (e.g.,
  class PagingScrollTableTABLE_DEFINITION extends
  TableDefinitionRowType, so that the method could be declared as
  public TABLE_DEFINITION getTableDefinition()?
 
 
  I apologize if I'm being overly simplistic or if I'm asking too much.
  I definitely apologize for not following up my suggestions with
  proposed patches. And I sincerely hope that my suggestions are taken
  only as the most positive form of feedback possible. I LOVE GWT. We've
  bet our company on the fact that GWT is *the* best way for writing the
  kind of interactive and rich apps our users are demanding. I want to
  do whatever I can (with my limited time outside of my job) to help
  make this toolkit even better.
 
  Thanks!
 
  jay
  
 




 


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

[gwt-contrib] Re: HashMap Optimization: return null for put and remove

2009-06-09 Thread Bruce Johnson

Yes, please do create an issue for it, and reply to this thread with the
issue id.

On Tue, Jun 9, 2009 at 11:21 AM, Damon Lundin damon.lun...@gmail.comwrote:


 I don't expect this to necessarily be done any time soon, but is there
 anything I need to do to make sure that it doesn't get lost?  Should I
 file a feature request?
 


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

[gwt-contrib] Re: i18n support for concrete default locale

2009-06-09 Thread Bruce Johnson

I like what jat said. Freeland?

On Tue, Jun 9, 2009 at 5:33 PM, j...@google.com wrote:


 The alternative to this would be Bruce's suggestion of defining a
 specific fallback value for a selection property rather than using
 config properties for it.  That would narrow the scope to exactly what
 we know we want to support and simplify the linker changes and avoids
 the breaking API change for existing linkers (where they have to supply
 the config properties to avoid breaking, which means the same linker
 can't work for GWT 1.6 and GWT 2.0).

 Something like:
   set-property-fallback name=locale value=default/
 and the last set value wins.


 http://gwt-code-reviews.appspot.com/34832/diff/1/2
 File
 dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/2#newcode194
 Line 194: new TreeSetConfigurationProperty());
 It seems like allowing this could cause incorrect behavior.  I know it
 is a tradeoff of not breaking existing code, but if there is a linker
 which calls this method, any code depending on config property lookup
 will just break.

 http://gwt-code-reviews.appspot.com/34832/diff/1/2#newcode223
 Line 223: }
 It looks like we are just substituting the empty string for unknown
 properties, which is especially bad if the call is relayed through the
 above method.

 http://gwt-code-reviews.appspot.com/34832/diff/1/4
 File dev/core/src/com/google/gwt/dev/cfg/StaticPropertyOracle.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/4#newcode149
 Line 149: for (String v : prop.getAllowedValues()) {
 setValues.addAll(cprop.getAllowedValues())?

 Also, maybe this should be computed in getPossibleValues() instead.

 http://gwt-code-reviews.appspot.com/34832/diff/1/5
 File
 dev/core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/5#newcode127
 Line 127: for (String v : cprop.getAllowedValues()) {
 setValues.addAll(cprop.getAllowedValues())?

 Also, maybe this should be computed in getPossibleValues() instead.

 http://gwt-code-reviews.appspot.com/34832/diff/1/7
 File user/src/com/google/gwt/i18n/I18N.gwt.xml (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/7#newcode51
 Line 51: $wnd['__gwt_Locale'] = locale ||
 '/*-GWTCONFIGPROP(default.locale)-*/';
 I think we haven't nailed this down enough that we want anyone else
 using it and expecting it to keep working.  So, I would suggest a
 comment here to that effect.

 http://gwt-code-reviews.appspot.com/34832/diff/1/7#newcode55
 Line 55: return /*-GWTCONFIGPROP(default.locale)-*/;
 Since these can all be empty strings, I would suggest storing
 /*-GWTCONFIGPROP(default.locale)-*/ || 'default' in a variable and
 reusing that.  Things will fall over if the property provider returns a
 value that is not valid.

 http://gwt-code-reviews.appspot.com/34832/diff/1/8
 File
 user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java
 (right):

 http://gwt-code-reviews.appspot.com/34832/diff/1/8#newcode136
 Line 136: logger.log(Type.WARN, default.locale has more than one value,
 using 
 Is this even possible since the config property definition says it isn't
 multivalued?

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

 


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

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

2009-06-08 Thread Bruce Johnson

Please also look at the compiled JS. I think the less restrictive bound will
cause the compiler to generate worse code (e.g. dynamic casts in some or all
contexts) which would make it a non-starter.

On Mon, Jun 8, 2009 at 6:22 PM, Stefan Haustein haust...@google.com wrote:

 Hi,

 I'd like to submit a patch (see below) that changes  JsArrayT extends
 JavaScriptObject to JsArrayT

 Motivation:
 Support more lightweight code in places where we depend on Javascript
 anyway.
 In particular, I would like to remove the dependency on LinkedList in
 AsyncFragmentLoader in a follow-up change.

 I have verified that this change does not introduce any new test failures.

 Stefan


 Index: user/src/com/google/gwt/core/client/JsArray.java
 ===
 --- user/src/com/google/gwt/core/client/JsArray.java(revision 5522)
 +++ user/src/com/google/gwt/core/client/JsArray.java(working copy)
 @@ -34,7 +34,7 @@
   *
   * @param T the concrete type of object contained in this array
   */
 -public class JsArrayT extends JavaScriptObject extends JavaScriptObject
 {
 +public class JsArrayT extends JavaScriptObject {

protected JsArray() {
}


 --
 Stefan Haustein
 Google UK Limited

 Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
 9TQ; Registered in England Number: 3977902


 


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

[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT

2009-06-08 Thread Bruce Johnson

What you describe, Ray, is definitely going to happen. It has to. I have
begun a design doc for that very thing. I'll float it for comments as soon
as I'm finished with the first draft.

On Mon, Jun 8, 2009 at 8:02 PM, Ray Cromwell cromwell...@gmail.com wrote:


 In particular, I use my own JsArray/JsMap implementation to avoid JRE
 collections in GQuery. Perhaps rather than patching JsArray, there
 should just be something like FastArrayList and FastMap which do not
 implement JRE Collections, but are nothing more than wrappers around
 JS arrays and objects for storing arbitrary Java objects. I suspect
 this is what motivates the patch?

 -Ray


 On Tue, Jun 9, 2009 at 8:16 AM, John Tamplinj...@google.com wrote:
  On Mon, Jun 8, 2009 at 6:22 PM, Stefan Haustein haust...@google.com
 wrote:
 
  I'd like to submit a patch (see below) that changes  JsArrayT extends
  JavaScriptObject to JsArrayT
 
  Motivation:
  Support more lightweight code in places where we depend on Javascript
  anyway.
  In particular, I would like to remove the dependency on LinkedList in
  AsyncFragmentLoader in a follow-up change.
 
  I have verified that this change does not introduce any new test
 failures.
 
  What does it mean to store non-JS values in a pure JS array?  What sort
 of
  things do you want to store that aren't JSO's but would reasonably work?
 
  --
  John A. Tamplin
  Software Engineer (GWT), Google
 
  
 

 


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

[gwt-contrib] Re: slow startup of hosted mode

2009-06-05 Thread Bruce Johnson

Sounds like an easy patch waiting to be made? Takers?

On Fri, Jun 5, 2009 at 12:21 PM, Freeland Abbott fabb...@google.com wrote:

 Since we later use outFile.setLastModified(artifact.getLastModified()),
 thus ensuring equality, yeah, that = is wrong


 On Fri, Jun 5, 2009 at 9:45 AM, Joel Webber j...@google.com wrote:

 Agreed, this comparison looks wrong, though it's not immediately obvious
 to me how this affects hosted-mode startup (linking the compiled output, I
 could see being affected). @bob, scott: Any thoughts on this?


 On Fri, Jun 5, 2009 at 8:14 AM, Sanjiv Jivan sanjiv.ji...@gmail.comwrote:


 Hi,
 Some of the users of SmartGWT have reported slow startup in hosted
 mode. A user narrowed down the problem to the following call in
 StandardLinkerContext.

 outFile.lastModified() = artifact.getLastModified()

 When changed to outFile.lastModified()  artifact.getLastModified(),
 the startup is normal.

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

 Can you guys comment on whether this is a valid change?

 One other thing that I noticed was that when I moved the resources
 (skin images) from the public path of my main module (SmartGwt), to
 a secondary module (SmartGwtXXXSkin), and the user is required to
 inherit both these modules, the hosted mode startup slowed down a fair
 bit compared to when he inherited only one module that also had the
 skins resources. Does this ring a bell? If not, I'll try to dig a
 little deeper into this and provide more information.

 Thanks,
 Sanjiv






 


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

[gwt-contrib] Re: A big GWT splash made by Wave

2009-06-05 Thread Bruce Johnson

Hi Gary,

We're happy to share both of those. In fact, neither one of those is really
considered proprietary; it's more just that they aren't really generalized
properly for widespread use. We'll put them in trunk as soon as time allows
(which is likely on the order of weeks at a minimum).

On Thu, Jun 4, 2009 at 11:34 PM, Gary Miller miller.ga...@gmail.com wrote:


 Hey All

 Now that the outside world has been give a peek at how Google is using
 GWT ...
   http://code.google.com/events/io/sessions/GoogleWavePoweredByGWT.html
 I was wondering if / when some of the propriety stuff might be made
 available to the outside world
 e.g.
 - Declarative UI / UiBinder
 - Server-side script selection
 -

 My applause to the GWT team from their involvement in Wave.

 Regards
 Gary
 


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

Re: GWT Compile error

2009-06-01 Thread bruce


I do have this class (com.extjs.gxt.ui.client.data.BeanModelLookup) in
my classpath. any idea?

On Apr 19, 4:25 pm, Salvador Diaz diaz.salva...@gmail.com wrote:
 If you read the whole stacktrace you'll see that there are other
 errors:

  Scanning for additional dependencies: jar:file:/D:/Program%20Files/
 gxt-2.0-m1/gxt.jar!/com/extjs/gxt/ui/client/data/BeanModelLookup.java
       Computing all possible rebind results for
 'com.extjs.gxt.ui.client.data.BeanModelLookup'
          Rebinding com.extjs.gxt.ui.client.data.BeanModelLookup
             Invoking generate-with
 class='com.extjs.gxt.ui.rebind.core.BeanModelGenerator'/
                [ERROR] Class
 com.extjs.gxt.ui.client.data.BeanModelLookup not found.

 It looks like it's a problem with your module declarations but without
 more details I can't be sure.

 Cheers,

 Salvador

 On Apr 18, 1:22 pm, bruce bruce.gao@gmail.com wrote:

  when I try compile a sample of Extjs-GWT. it hit the follow exception.
  but I have the missing class
  com.pipnet.resources.client.model.Customer in the same project.
  anybody can tell me why? thanks a lot

  Compiling module com.pipnet.desktop.Desktop
     Refreshing module from source
        Refreshing TypeOracle
           Processing types in compilation unit: file:/C:/Documents%20and
  %20Settings/bruce.gao/workspace_3.4/Desktop/src/com/pipnet/resources/
  client/model/CustomerBeanModel.java
              Found type 'CustomerBeanModel'
                 Resolving annotation '@BEAN
  (com.pipnet.resources.client.model.Customer.class)'
                    [ERROR]
  java.lang.ClassNotFoundException:
  com.pipnet.resources.client.model.Customer
          at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
          at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
          at java.lang.Class.forName0(Native Method)
          at java.lang.Class.forName(Class.java:242)
          at com.google.gwt.dev.javac.TypeOracleMediator.getClassLiteral
  (TypeOracleMediator.java:763)
          at
  com.google.gwt.dev.javac.TypeOracleMediator.getAnnotationElementValue
  (TypeOracleMediator.java:674)
          at
  com.google.gwt.dev.javac.TypeOracleMediator.createAnnotationInstance
  (TypeOracleMediator.java:442)
          at com.google.gwt.dev.javac.TypeOracleMediator.resolveAnnotation
  (TypeOracleMediator.java:836)
          at com.google.gwt.dev.javac.TypeOracleMediator.resolveAnnotations
  (TypeOracleMediator.java:857)
          at 
  com.google.gwt.dev.javac.TypeOracleMediator.resolveTypeDeclaration
  (TypeOracleMediator.java:1384)
          at com.google.gwt.dev.javac.TypeOracleMediator.addNewUnits
  (TypeOracleMediator.java:389)
          at com.google.gwt.dev.javac.TypeOracleMediator.refresh
  (TypeOracleMediator.java:417)
          at com.google.gwt.dev.javac.CompilationState.refresh
  (CompilationState.java:179)
          at com.google.gwt.dev.javac.CompilationState.init
  (CompilationState.java:93)
          at com.google.gwt.dev.cfg.ModuleDef.getCompilationState
  (ModuleDef.java:264)
          at com.google.gwt.dev.Precompile.precompile(Precompile.java:283)
          at com.google.gwt.dev.Compiler.run(Compiler.java:170)
          at com.google.gwt.dev.Compiler$1.run(Compiler.java:124)
          at 
  com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:
  84)
          at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger
  (CompileTaskRunner.java:78)
          at com.google.gwt.dev.Compiler.main(Compiler.java:131)
     Scanning for additional dependencies: jar:file:/D:/Program%20Files/
  gxt-2.0-m1/gxt.jar!/com/extjs/gxt/ui/client/data/BeanModelLookup.java
        Computing all possible rebind results for
  'com.extjs.gxt.ui.client.data.BeanModelLookup'
           Rebinding com.extjs.gxt.ui.client.data.BeanModelLookup
              Invoking generate-with
  class='com.extjs.gxt.ui.rebind.core.BeanModelGenerator'/
                 [ERROR] Class
  com.extjs.gxt.ui.client.data.BeanModelLookup not found.
  java.lang.NullPointerException
          at com.extjs.gxt.ui.rebind.core.BeanModelGenerator.getMarkerBean
  (BeanModelGenerator.java:170)
          at com.extjs.gxt.ui.rebind.core.BeanModelGenerator.generate
  (BeanModelGenerator.java:53)
          at com.google.gwt.dev.cfg.RuleGenerateWith.realize
  (RuleGenerateWith.java:49)
          at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.tryRebind
  (StandardRebindOracle.java:113)
          at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind
  (StandardRebindOracle.java:62)
          at com.google.gwt.dev.shell.StandardRebindOracle.rebind

[gwt-contrib] Re: Speedups for -soyc compilation

2009-05-26 Thread Bruce Johnson

Any numbers on the amount of improvement?

On Tue, May 26, 2009 at 11:04 AM, r...@google.com wrote:


 Reviewers: spoon, kprobst, scottb,

 Description:
 This patch incorporates Kathrin's StringBuilder work along with other
 miscellaneous speedups found by using JProfiler.

 Please review this at http://gwt-code-reviews.appspot.com/34818

 Affected files:
   dev/core/src/com/google/gwt/core/ext/soyc/Range.java
   dev/core/src/com/google/gwt/core/ext/soyc/Story.java
   dev/core/src/com/google/gwt/core/ext/soyc/impl/DependencyRecorder.java
   dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardClassMember.java
   dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryImpl.java
   dev/core/src/com/google/gwt/core/ext/soyc/impl/StoryRecorder.java
   dev/core/src/com/google/gwt/dev/CompilePerms.java
   dev/core/src/com/google/gwt/dev/jjs/CorrelationFactory.java
   dev/core/src/com/google/gwt/dev/jjs/InternalCompilerException.java
   dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
   dev/core/src/com/google/gwt/dev/jjs/SourceInfo.java
   dev/core/src/com/google/gwt/dev/jjs/SourceInfoCorrelation.java
   dev/core/src/com/google/gwt/dev/jjs/SourceOrigin.java
   dev/core/src/com/google/gwt/dev/jjs/ast/JField.java
   dev/core/src/com/google/gwt/dev/jjs/ast/JModVisitor.java
   dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
   dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
   dev/core/src/com/google/gwt/dev/jjs/impl/ArrayNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/AssertionNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/AssertionRemover.java
   dev/core/src/com/google/gwt/dev/jjs/impl/CastNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/CatchBlockNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java

 dev/core/src/com/google/gwt/dev/jjs/impl/CompoundAssignmentNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java
   dev/core/src/com/google/gwt/dev/jjs/impl/EqualityNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/Finalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
   dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
   dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
   dev/core/src/com/google/gwt/dev/jjs/impl/JavaScriptObjectNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/JsoDevirtualizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/LongCastNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/LongEmulationNormalizer.java
   dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
   dev/core/src/com/google/gwt/dev/jjs/impl/MethodCallTightener.java
   dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
   dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
   dev/core/src/com/google/gwt/dev/jjs/impl/RecordRebinds.java
   dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRebinds.java
   dev/core/src/com/google/gwt/dev/jjs/impl/ReplaceRunAsyncs.java
   dev/core/src/com/google/gwt/dev/jjs/impl/ResolveRebinds.java
   dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java



 


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

Re: Cannot iterate HashSet

2009-05-25 Thread Bruce Hatt


The difference is in how your string is created.
I would make a guess that getValue() returns null at some point and
the call to toString() generates a NPE type error in javascript.
Concatenation like in your second snippet, will create a new string
and concatenate the return of getValue(). Null is okay to
concatenate.

To verify, do a check for null or look for null in your output.


On May 24, 8:05 am, Yulia yuli...@gmail.com wrote:
 After all day beating my head against the keybord I found where the
 problem was. I reverted all changes to stable version and statrted to
 add code bit by bit and noticed that after changes in
 AttributeValue.toString() method my program started to fail again.

 This code doesn't work:
     @Override
     public String toString() {
         return getValue().toString();
     }

 But this code works:
     @Override
     public String toString() {
         return +getValue();
     }

 But it should be the same... Maybe I misunderstand something, can
 somebody explain me the difference?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Fix for issue 3649 (parallel script loading in iframe liner)

2009-05-14 Thread Bruce Johnson


candidate for 1.6.5?

On Thursday, May 14, 2009,  knor...@google.com wrote:
 LGTM++

 A few new spacing issues showed up. It could be tabs.


 http://gwt-code-reviews.appspot.com/33808/diff/1005/1007
 File dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js (right):

 http://gwt-code-reviews.appspot.com/33808/diff/1005/1007#newcode47
 Line 47: // The frame that will contain the compiled script (created in
 There's some weird extra spacing here.

 http://gwt-code-reviews.appspot.com/33808/diff/1005/1007#newcode322
 Line 322: scriptFrame.id = '__MODULE_NAME__';
 More weird spacing.

 http://gwt-code-reviews.appspot.com/33808/diff/1005/1007#newcode359
 Line 359: // Mark this module's script as done loading and (possibly)
 start the
 Is there extra space at the end of this line?

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


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

[gwt-contrib] Re: GWT String's hashCode is not random enough

2009-05-14 Thread Bruce Johnson

It's worth mentioning that, while this algorithm is surely a lot slower than
before, it won't slow down HashMap, which already has a fast-path for string
keys that does not actually use hashCode().

On Thu, May 14, 2009 at 8:33 PM, amitman...@google.com wrote:


 LGTM except the simple changes for the test code. Once everyone has
 weighed in and the patch is ready to go in, I volunteer to commit it on
 your behalf.

 Thanks for the patch!


 http://gwt-code-reviews.appspot.com/34811/diff/1/3
 File user/super/com/google/gwt/emul/java/lang/String.java (right):

 http://gwt-code-reviews.appspot.com/34811/diff/1/3#newcode134
 Line 134: }
 LGTM++

 http://gwt-code-reviews.appspot.com/34811/diff/1/2
 File user/test/com/google/gwt/emultest/java/lang/StringTest.java
 (right):

 http://gwt-code-reviews.appspot.com/34811/diff/1/2#newcode218
 Line 218: int[] savedHash = new int[testStrings.length];
 LGTM except 2 minor comments:
 (i) formatting of the line with int[] javaHashes is not consistent
 with what we follow for Gwt.
 (ii) You can rewrite this function to get rid of the savedHash array.

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

 


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

[gwt-contrib] Re: Incubator Questions

2009-05-01 Thread Bruce Johnson

We do expect to start moving a cluster of the most popular widgets from the
incubator into the GWT trunk this quarter, so things like the paging table,
etc. will almost certainly be in the next GWT major release.

On Fri, May 1, 2009 at 1:53 AM, Gilles B gilles.broch...@gmail.com wrote:


 I am currently using gen2 tables. It's realy a good stuff and this
 part realy miss in GWT widgets with paging (or not), columns sort and
 such cool mechanisms.

 I have tried other tables implementations but this one is not so big
 and work fine for me. As example, Smart GWT offers a realy good and
 more beautifull component but I doesn't want to include such full
 framework implying some js library extra dependance (half commercial).
 The gwt as a toolkit approach seems better and its avoid the big
 library syndrom (Including hundred of script, css, resources, javacode
 in your app if you only want a single component)

 As 1.6 only provide an additionnal calendar I was a little bit
 disappointed expected more widgets in this version. Is there a plan to
 add such widgets in future releases or is it a choice to provide a
 basic set and opening the field to third party libraries ?

 


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

[gwt-contrib] Re: Feature idea

2009-04-27 Thread Bruce Johnson

It seems like the general functionality (i.e. GWT.isLiteral()) ought to be
implemented at the same time as method cloning. That's what makes me excited
about the whole thing. Otherwise, at least for me, it's hard to wrap my head
around how you could usefully emit different code for the same method for
different call sites. Maybe I'm missing something.

A similar but related concept that I think would be the best first step is a
parameter annotation called @MustBeLiteral. Then any method could become a
GWT.create() indirectly because you'd be able to write:

public T T myFactory(@MustBeLiteral Class? extends T classLit) {
  T t = GWT.create(classLit);
  // do some stuff to tweak the t instance
  return t;
}

That seems way useful and perhaps the easiest of everything to implement.

On Mon, Apr 27, 2009 at 9:30 AM, Joel Webber j...@google.com wrote:

 Cool, I had no idea GCC provided that information. I won't claim to be one
 of the compiler gurus, but this sounds pretty feasible to me, and to Ray's
 point, might be a useful way of loosening the GWT.create() magic a bit.

 @Lex, Scott: What do you think? Is this relatively easy and useful?

 On Mon, Apr 27, 2009 at 4:49 AM, Vitali Lovich vlov...@gmail.com wrote:

 Yeah, probably from a compiler's perspective, the value check may be more
 complicated (the value may only be available after the AST stage depending
 on when optimization is done)

 It can possibly bloat the resultant code (since I believe you may have to
 build different implementations of each function and you may get overhead,
 even if you inline).  However, I think this might be an OK tradeoff since
 the assumption would be that you are optimizing for speed as opposed to size
 if you use something like GWT.isLiteral.


 On Mon, Apr 27, 2009 at 3:45 AM, Ray Cromwell cromwell...@gmail.comwrote:


 +1

 I suggested a similar feature a few days ago privately, I called it
 GWT.isLiteral(), since the underlying check is if its an AST literal
 in the compiler, although in my example, you can't do value
 comparisons, just assertions on the literal. The value checks would be
 done via traditional operators.




 On Mon, Apr 27, 2009 at 12:33 AM, Vitali Lovich vlov...@gmail.com
 wrote:
  Kinda like with GCC, allow detection of constant values (i.e.
  __builtin_constant_p).  This way, you could do something like
 
  void addParameter (HashMap h, int size, String key, Object value)
  {
 if (GWT.isConstantValue(h, null)) {
if (GWT.isConstantValue(size, 0))
   size = 10;
h = new HashMap(size);
 }
 h.put(key, value).
  }
 
   you could have the performance of
 
  void addParameter (HashMap h?, int size?, String key, Object value)
 
  as if you wrote overloaded methods without needing to write several
  different methods that just supply default values back  forth.
 Sometimes,
  it's also possible to use a better algorithm if parameters have a known
  constant value.
 
  
 







 


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

[gwt-contrib] RR: Design doc for multi-valued configuration properties

2009-04-24 Thread Bruce Johnson

Hi GWT community,

At a recent meeting intended to be a discussion of how to design blacklist
support for RPC, we realized that we wanted to make some changes to the new
set-configuration-property module XML support. It ended up becaming a
prerequisite to continuing with RPC blacklist support. In an effort to get
these changes made quickly so that we can get on with blacklist support,
I've written up notes from that meeting into the following design doc:

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

Please comment in the design doc or on this thread if you have thoughts.

-- Bruce

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

[gwt-contrib] Re: subtree logging for problems

2009-04-22 Thread Bruce Johnson

Would you be willing to drop a before and after example of the output
for those of watching from the stands?

On Wed, Apr 22, 2009 at 1:55 PM, Freeland Abbott fabb...@google.com wrote:

 Thanks.  Typo fixed, submit at r5269.


 On Tue, Apr 21, 2009 at 6:27 PM, Lex Spoon sp...@google.com wrote:

 LGTM.  There's a typo in ProblemReport: accessir.

 -Lex


 On 4/21/09, Freeland Abbott fabb...@google.com wrote:
  Here's the promised follow-on to my earlier, fixing the subtype logging
 to
  be a subtree logger.
 
  I'm still bothered by the multiple entries for E extends
 java.lang.Object,
  but I'm not sure which is the better way to fix it... I think I would
 like
  to change JType constructors and/or .equals, to generalize to e.g. id1
  extends java.lang.Object or id1 extends Mapid2 extends KeyType, id3
  implements ValType, but I'm not sure how such a change might impact
 other
  uses of JType and children elsewhere... I would like to think it was
  beneficial.
 
  The other, more localized approach would be to change the TIC map key
 from
  JClassType to String, and to do the identifier-abstraction as types were
  stringified in STOB, only.  Thoughts?
 
 
 



 


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

[gwt-contrib] Re: Java source transformation

2009-04-21 Thread Bruce Johnson

On Tue, Apr 21, 2009 at 12:38 PM, nicolas de loof
nicolas.del...@gmail.comwrote:

 The only critism I'd have is the requirement to use GWT.create() to get
 code from a generator. This is a requirement when the generated code doesn't
 extend the source type (for example for Async interfaces) but not when the
 genrator is used to add some capabilities (ie acts as a decorator), for
 example to add PropertyChangeListener to a model bean.


Perhaps if you could distill down a more concrete example, it could get the
wheels turning. Enhancements to GWT.create() certainly aren't off the table.
Ray Cromwell has made some pretty useful-sounding suggestions in the past.
We just have to find large-group consensus on what makes the most sense,
striking a balance between power, clarity, and of course, optimizability.

Here's a quick back-of-envelope pattern that could possibly work:

class PersonBean {
  void setName(String name):
  String getName();
}

interface MethodCallLogger {
}

class MyEntryPoint {
  class PersonBeanWithMethodCallLogger extends PersonBean implements
MethodCallLogger {
// empty, but a subclass gets generated
  }

  public void onModuleLoad() {
// Have a generate-with rule for MethodCallLoggerGenerator, triggered by
assignability to MethodCallLogger
PersonBean pb = GWT.create(PersonBeanWithMethodCallLogger.class);
pb.setName(Nicolas);
  }
}

// Generated...
class PersonBeanWithMethodCallLoggerImpl extends
PersonBeanWithMethodCallLogger {
  void setName(String name) {
someLogger.log(setName(' + name + ') called);
super.setName(name);
  }

  ...
}

As formulated above, this pattern doesn't compose well. But it might be that
we can forge a pattern like this into something everyone likes eventually.

-- Bruce



 This makes unit testing more difficult as code that uses GWT.create cannot
 run in classic jUnit. It would be great to have the compiler use
 generator-extended classes even when created using the standard new
 keyword.

 Thanks a lot for the explanation.
 Nicolas

 2009/4/21 Bruce Johnson br...@google.com

 A sort of philosophical meta-point that may or may not be of interest...

 When we started GWT, we were worried about managing the complexity of
 compile-time code generation, so we tried to find the simplest, most
 easy-to-debug approach we could think of. GWT's model of never changing
 existing code[1], but only adding new Java source during the compile, is
 really a design choice, not a technical limitation. The benefit of the
 current design is that you can add -gen to hosted mode and map the
 corresponding folder into your source path, and then easily step through all
 your code, both handwritten and generated, in the debugger. This avoids
 tricky or confusing situations wherein the source code you see appears to be
 doing something different than the bytecode that's running. It seems good to
 avoid that kind of dichotomy, on the principle that
 straightforward-though-verbose is generally better than fancy-but-confusing.

 [1] Overlay types were the first time we ever even did bytecode rewriting,
 and that support is implemented at a very deep level. Also, JSOs are
 intended to be among only a very few magic things in GWT (basically, JSNI,
 GWT.create(), GWT.runAsync(), and JSOs). We went to a lot of effort to
 ensure that JSOs worked according to a fixed set of rules that are not hard
 to comply with, even if people don't fully understand why the implementation
 requires it.


 On Mon, Apr 20, 2009 at 11:11 AM, Thomas Broyer t.bro...@gmail.comwrote:




 On 20 avr, 08:43, nicolas de loof nicolas.del...@gmail.com wrote:
I wonder if there is any way to also pre-process Java sources,
 for
   example
this would enable support for Aspect Oriented Programming or maybe
 some
DataBinding framework.
 
   Depends what you mean by pre-process... Generally, generators
   analyze the class they're called for (for example, looking for
   specific annotations on methods or on the class itself) and according
   to this generate a Java class extending the one they've been called
   for.
   (is this understandable? is this at least no-so-bad english?)
 
  In many case the generator will create from MyClassX some MyClassXImpl
 or
  equivalent that extends the original one, bu not REPLACE it as Java
 source.
  This is what I mean by pre-process.
 
  For example, to implement a AOP framework I'd like to instrument all
 calls
  to some method. For this reason I'd like a generator / pre-processor to
  check the source files and detect the matching pointcuts to add some
 adived
  code. Many other example can apply, including annotation processing for
  declarative coding (ex : @Property annotation to automagically
 introduce the
  required PropertyChangeListeners)

 You would generate a subclass that delegates to super.method() after/
 before the aspect(s) code.

  I never tried it myself, but I'n not sure a generator can REPLACE the
  original Java Source.

 AFAICT

[gwt-contrib] Re: UiBinder

2009-04-14 Thread Bruce Johnson

No update yet, unfortunately. We have to get ourselves organized again now
that GWT 1.6 is out the door, and then we'll have a better idea of when it
will be available.

On Tue, Apr 14, 2009 at 12:54 AM, Gary Miller miller.ga...@gmail.comwrote:


 Any news on when UiBinder will be available to the outside world?

 Thanks
 Gary

 


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

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

2009-04-14 Thread Bruce Johnson

It still sounds to me like the route Scott suggested and Bob agreed with
would be better, so as to avoid the whole issue of re-lexing the JS during
link.

On Tue, Apr 14, 2009 at 1:19 AM, Vitali Lovich vlov...@gmail.com wrote:

Should've mentioned this in the original post, but probably the
TokenStream.javahttp://mxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/javascript/TokenStream.javaclass
is the scanner you would be interested in I believe.

On Tue, Apr 14, 2009 at 1:14 AM, Vitali Lovich vlov...@gmail.com wrote:

Hey guys,

Rhino http://www.mozilla.org/rhino/ (one of Mozilla's javascript
engines) is written entirely in Java supports JS 1.7 if that helps. I'm
sure there's a parser component in there that can be extracted if the
license is compatible (MPL/GPL).

There's also GromJS http://www.bauk.ws/gromjs.html (public domain I
think).

On the other hand these are probably overkill for your needs.

On Tue, Apr 14, 2009 at 12:33 AM, Lex Spoon sp...@google.com wrote:

On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin j...@google.com wrote:
On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum sco...@google.com wrote:

If we were playing Mao, I would give you a card penalty for stating
the
obvious. :-)

But uh, reliably tracking whether or not you're in a string literal is
about as much fun as writing a JavaScript parser. In fact, it might
be
*exactly* as fun, if you know what I mean.

String literals have to be known at parse time, so it seems to me all
you
have to look for is start/stop quotes (of both sorts) while handling
embedded ones of the wrong variety and escaped ones of the right
variety.
That looks like it can be handled with a single character lookahead
scanner,
and very little complexity -- what am I missing?

It would be awesome if there were a simple lexer available for
JavaScript. Given a token stream, brace counting would sound
feasible.

However, from what I hear it's pretty complicated even to tokenize
JavaScript. I don't know exactly what is so hard, but last time I
asked, regex literals came up.

Lex

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

[gwt-contrib] Re: UiBinder

2009-04-14 Thread Bruce Johnson

On Tue, Apr 14, 2009 at 12:12 PM, Chris chrish...@gmail.com wrote:


 As you get organized for the next release(s), It would be nice to have
 more frequent releases with one or two major features.  There are some
 major enhancements sitting in trunk (RunAsync is the one I'm really
 looking forward too).  I realize this might not be possible with this
 type of project and the resources required to put out a releases.


I hear ya, but you're right that doing an actual release does require a lot
of effort, so there's a natural lower-limit as to how often we really can do
official releases.

No promises, but it's worth noting that trunk is quite stable these days.
Teams within Google are using the trunk all the time, so we have an
incentive to keep it stable on average.

-- Bruce

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

[gwt-contrib] Re: One last memory review

2009-04-09 Thread Bruce Johnson

w00t! Vacation commits FTW! (Just kidding; @Scott: please rest)

On Thu, Apr 9, 2009 at 11:52 AM, Scott Blum sco...@google.com wrote:

 FYI: I just committed the last of my outstanding memory work to trunk.  Lex
 kindly agreed to watch the build and do a roll-back for me if something
 breaks.


 On Tue, Apr 7, 2009 at 10:33 PM, Scott Blum sco...@google.com wrote:

 On Tue, Apr 7, 2009 at 4:12 PM, Lex Spoon sp...@google.com wrote:

  5178: Also tightened up the recursive method slightly, and managing the
  computed set better.  This works because once a class transitions
 from
  hasClinit - !hasClinit, there's no possible way it can ever go back.

 Small problem: I believe line 644-646 in the patched version is
 intended to test target, not type.  If that sounds right, then the
 rest LGTM.  Otherwise, let's discuss how this is supposed to work.


 Nice catch!  I botched a manual inlining of lines 636-641 in the original.


 By the way, this algorithm could be sped up if, it mattered for
 performance.  Instead of repeatedly recursing for each type, start by
 marking classes where hasLiveCode() as having clinits.  Then,
 propagate clinit-ness backwards along the getClinitTargets() graph.
 Any class not reached does not needs its clinit. The advantage
 probably doesn't matter in this case in practice, but I mention it
 because this funny algorithm pattern keeps coming up.


 That is a better approach, I'll have to remember that next time I run into
 this pattern.

 Thanks,
 Scott



 


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

Announcing GWT 1.6...and quite a bit more

2009-04-07 Thread Bruce Johnson

Hi Folks!

Exciting news today. Rather than attempting to describe everything here, let
me point you to some blog posts that hopefully you will find interesting:

GWT 1.6 and friends:
http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-friends.html

Seriously this time, the new language on App Engine: Java
http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

Google Plugin for Eclipse -- Peanut Butter to Eclipse's Chocolate
http://googlewebtoolkit.blogspot.com/2009/04/google-plugin-for-eclipse-peanut-butter.html

-- Bruce, on behalf of the GWT, App Engine, and Google Plugin teams

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: [google-web-toolkit commit] r5193 - Fix error message to include the property name when a binding vs. configuration property ...

2009-04-07 Thread Bruce Johnson

@Bob: Kudos for fixing this instead of just observing the problem and moving
on. You rock for setting this kind of example.

On Tue, Apr 7, 2009 at 1:52 PM, codesite-nore...@google.com wrote:


 Author: b...@google.com
 Date: Tue Apr  7 10:47:05 2009
 New Revision: 5193

 Modified:
trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java

 Log:
 Fix error message to include the property name when a binding vs.
 configuration property mismatch occurs.

 Patch by: bobv
 Review by: jgw (TBR)


 Modified: trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java

 ==
 --- trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java
 (original)
 +++ trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java  Tue
 Apr
 7 10:47:05 2009
 @@ -791,8 +791,8 @@
  if (concreteType.isInstance(prop)) {
return prop;
  }
 -logger.log(TreeLogger.ERROR, The specified property ' + attr
 -+ ' is not of the correct type; found '
 +logger.log(TreeLogger.ERROR, The specified property '
 ++ prop.getName() + ' is not of the correct type; found '
  + prop.getClass().getSimpleName() + ' expecting '
  + concreteType.getSimpleName() + ');
} else {

 


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

[gwt-contrib] Announcing GWT 1.6...and quite a bit more

2009-04-07 Thread Bruce Johnson

Hi Folks!

Exciting news today. Rather than attempting to describe everything here, let
me point you to some blog posts that hopefully you will find interesting:

GWT 1.6 and friends:
http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-friends.html

Seriously this time, the new language on App Engine: Java
http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

Google Plugin for Eclipse -- Peanut Butter to Eclipse's Chocolate
http://googlewebtoolkit.blogspot.com/2009/04/google-plugin-for-eclipse-peanut-butter.html

-- Bruce, on behalf of the GWT, App Engine, and Google Plugin teams

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

[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files

Sounds pretty useful. We should lock its behavior down more, though. Maybe
just

deprecated superceded-by=othermodule/

where superceded-by is optional.

It would be helpful to have consistent-looking deprecation messages, so we
probably shouldn't leave the text open-ended.

On Mon, Apr 6, 2009 at 11:57 AM, BobV b...@google.com wrote:


 I'm in the process of migrating ClientBundle into trunk and it
 occurred to me that even if you remove the use of all deprecated types
 from your code, your module might still inherit an otherwise-unused
 module.

 What do you think about adding another tag to gwt.xml as follows?

 module
  deprecated href=http://google.com/more_info; This module has been
 replaced by blah-blah-blah./deprecated
 /module

 --
 Bob Vawter
 Google Web Toolkit Team

 


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

[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files

On Mon, Apr 6, 2009 at 1:35 PM, BobV b...@google.com wrote:


 On Mon, Apr 6, 2009 at 1:28 PM, Bruce Johnson br...@google.com wrote:
  Sounds pretty useful. We should lock its behavior down more, though.
 Maybe

 Locking it down is just going to get in the way because we can't cover
 all of the types of messages that you'd necessarily want to be able to
 convey in tag attributes.


I may not be thinking about the spectrum clearly enough. Do you have some
examples in mind? It seems like the 99% case is people saying Don't use
this anymore; use that instead.


  Developers will just have to be judicious
 in their use of a free-form message; it more-or-less works for
 JavaDoc. (tangent: ModuleDoc?)


In javadoc, it has always seemed like an un-usefully underconstrained tag.
Everbody says exactly the same things, phrased every-so-slightly
differently.


 If you want to lock it down, the most useful thing to be able to
 specify is a URL with additional information.


I don't think that handles the most common use case, though. Wouldn't the
most common thing be, Don't use this; use that? Most people will go to
the absolute minimum trouble necessary, so it's unlikely people would be
included to create an actual URL to point to. (IMHO)

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

[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files

On Mon, Apr 6, 2009 at 4:17 PM, BobV b...@google.com wrote:

 I'm thinking of the case that I have where transitioning from
 ImmutableResourceBundle to ClientBundle could use some documentation
 to indicate where there have been changes.

 So how about use this instead and more information here and lose
 the free-form data?


How does that manifest as XML?

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

[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files

(BTW, I could be wrong about the whole let's not have freeform text. It
was just one guy's opinion that it makes things too inconsistent. I'd like
to hear if other people agree/disagree.)

@Other people: agree/disagree?

Assuming people do agree that it's a bit better to avoid freeform text, then
Bob, I like your most recent suggestion with John's addendum.

On Mon, Apr 6, 2009 at 4:37 PM, John Tamplin j...@google.com wrote:

 On Mon, Apr 6, 2009 at 4:26 PM, BobV b...@google.com wrote:


  How does that manifest as XML?

 deprecated superceded-by=othermodule href=http://google.com/something;
 /

 where both attributes are optional.  The URL will be presented by
 using the AbstractTreeLogger.log() method that takes a HelpInfo
 object.


 superceded-by should probably accept a comma-separated list of modules in
 case the functionality gets split up.

 --
 John A. Tamplin
 Software Engineer (GWT), Google

 


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

[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files