Re: [gwt-contrib] About GWT opinion in thoughtworks technology radar july 2011

[Bruce Johnson]

When you read opinions like this, you have to interpret the author's
perspective relative to his/her incentives. Thus, GWT consultants will
observe the reasons GWT is really good. Consultants skilled in things other
than GWT will find reasons that their solutions are better. There isn't a
"right" answer.

More inline below.

On Wed, Aug 3, 2011 at 2:53 AM, Emilio Bravo  wrote:

> "First, in many ways, JavaScript is more powerful and expressive than
> Java, so we suspect that the generation is going in the wrong
> direction."
>

It paints a picture, but there are no facts or evidence in the above
statement. Words like "powerful" and "expressive" are popular when
discussing these sorts of topics precisely because they're vague enough that
it's hard to argue with them.

You can pick literally any topic and find people eager to take all sides.
The question is how seriously you should take the assertion made by the
author.

Do you trust the author? Why? If so, take the judgment seriously. If you
don't have any particular reason to trust the author relative to others who
have a different conclusion, then ignore the article and judge for yourself
or listen to those with more direct experience using the technology in
question.

Someone's willingness to write down their assertion doesn't make it more
correct. And no tool is right or wrong for every project.

"Secondly, it is impossible to hide a complex abstraction difference
> like that from event-driven desktop to stateless-web without leaky
> abstraction headaches eventually popping up"
>

Of course abstractions leak. We knew that when we designed GWT and the
design accounts for that. GWT generally doesn't depend on isolating you from
JS or the DOM except in cases where memory leaks are the inevitable
by-product of not adding widget-like machinery. To put that another way: the
absence of GWT's "abstractions that leak" is UI code that very likely has
memory leaks. That there are many GWT libraries that interop with
handwritten JS is among the evidence that the above statement
seems under-informed and dismissively definitive (e.g. "impossible").

"Third, it suffers from the same shortcomings of many elaborate
> frameworks, where building simple, aligned applications is quick and
> easy, building more sophisticated but not supported functionality is
> possible but difficult, and building the level of sophistication
> required by any non-trivial application becomes either impossible or
> so difficult it isn’t reasonable."
>

This one is almost funny. GWT usually gets beat up for the precise opposite:
it's good for big apps but not easy enough for small ones. Among the tens of
thousands of apps that overcame the above-asserted "abstraction headaches"
and managed to do something "sophisticated" include Angry Birds, AdWords
(with hundreds of thousands of lines of browser code), Lombardi Blueprint
(acquired by IBM), DimDim (acquired by Salesforce.com), and, in the last
couple of weeks, Google Offers, Hotel Finder, and Web Fonts.

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

Re: [gwt-contrib] delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?

[Bruce Johnson]

[+Scott and Kelly from Google]

On Thu, Sep 30, 2010 at 4:54 PM, Damon Lundin wrote:

> We are trying to upgrade from 2.0.4 to 2.1.0.m3 because of some bugs
> in 2.0.4 but in doing so our GWT test cases have begun failing and I
> have determined it's because the next test is beginning before the
> previous one is complete and they are messing each other up.  I know
> that delayTestFinish is meant to allow for tests to make use of async
> calls and it's been working for us but now it's not.
>
> We have a number of tests that roughly look like this:
>
> public void test03 {
>  delayTestFinish(12);
>  rpcService.someServerCall(new AsyncCallback() {
>public void onSuccess() {
>  // Do some stuff
>  DeferredCommand.addCommand(new Command() {
>public void execute() {
>  // More stuff
>  finishTest();
>}
>  }
>}
>  }
> }
>
> public void test04 {
>  delayTestFinish(12);
>  ...
> }
>
> Our code actually uses DeferredCommands in a long chain of calls but
> in short, test04 begins executing before we call finishTest() in the
> previous test and I don't think that's supposed to happen.
>
> I could further debug this if someone could explain to me what
> "implemented in the translatable version of this class" means and how
> I would debug this "translatable version".  Any advice on how to
> proceed?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] RR: allow CheckBox to accept null?

[Bruce Johnson]

Fwiw, I don't actually care. It just seemed like something that needed
some devil's advocacy.

On Thursday, August 26, 2010, Ray Ryan  wrote:
> Andrew, how would this be?
>     CheckBox cb = new CheckBox();
>
>     cb.setValue(null);
>     assertFalse(cb.getValue());
> rjrjr
>
> On Thu, Aug 26, 2010 at 5:57 PM, Andrew Pietsch  
> wrote:
> I personally would like to see it support null, not because null is a
> valid UI state but just to be consistent with all the other widgets.
> As far as pectin is concerned the bindings always created before the
> real value arrives so wigets are aften set to null. I've tried to
> avoid wiget specific logic in the core bindings as much as possible
> (it's a slippery slope to ugliness) and CheckBox is the odd one out.
> As a somewhat silly thought would a marker interface be an option i.e.
> perhaps something like `CheckBox implements HasValue, BarfsOnNull` so
> there's at least a mechanism to find out?
>
> On Aug 26, 6:00 pm, Johan Rydberg  wrote:
>> On 8/25/10 6:16 PM, Ray Ryan wrote:> The use case is dealing with boolean 
>> values that may benull, and
>> > really a check box is just the wrong UI there. Withdrawn.
>>
>> I know of at least one data binding framework, gwt-pectin, that signals
>> "no value" usingnull. As a work-around gwt-pectin has it's ownCheckBox
>> impl that acceptsnull.
>>
>> Take this example; We have a master-detail interface.  aCheckBoxhas
>> been bound to "selectedElement.male".  If there is not a selected
>> element, a "no value" signal should be sent down through data binding,
>> not "False". Right?
>>
>> But then again, there's really no way to communicate something like a
>> placeholder value for acheckbox.  But I still thinkCheckBoxshouldacceptnull, 
>> for the interface to be consistent.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] RR: allow CheckBox to accept null?

[Bruce Johnson]

Glad I looked at it funny, then.

Micro-design reviews ftw.

On Wed, Aug 25, 2010 at 12:16 PM, Ray Ryan  wrote:

> Yeah, thinking about it by the light of day I think it's the wrong
> direction.
>
> The use case is dealing with boolean values that may be null, and really a
> check box is just the wrong UI there. Withdrawn.
>
>
> On Wed, Aug 25, 2010 at 7:01 AM, Bruce Johnson  wrote:
>
>> Can you provide a little more context for why it should work this way?
>>
>> On Tue, Aug 24, 2010 at 6:49 PM, Ray Ryan  wrote:
>>
>>> When we made the CheckBox widget implement HasValue, we had it throw an
>>> illegal argument exception when setValue() is called with null.
>>>
>>> I think we goofed.
>>>
>>> Can we get away with relaxing that? I'd like this to be the case:
>>>
>>> CheckBox cb = new CheckBox();
>>> cb.setValue(null);
>>> assertNull(cb.getValue());
>>>
>>>
>>> rjrjr
>>>
>>>  --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] RR: allow CheckBox to accept null?

[Bruce Johnson]

Can you provide a little more context for why it should work this way?

On Tue, Aug 24, 2010 at 6:49 PM, Ray Ryan  wrote:

> When we made the CheckBox widget implement HasValue, we had it throw an
> illegal argument exception when setValue() is called with null.
>
> I think we goofed.
>
> Can we get away with relaxing that? I'd like this to be the case:
>
> CheckBox cb = new CheckBox();
> cb.setValue(null);
> assertNull(cb.getValue());
>
>
> rjrjr
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re: Introducing the Abstractizer compiler optimization (issue 4893) (issue609801)

[Bruce Johnson]

50%? That would be astonishing, but I must admit I'm skeptical :-)

Thomas, have you tried it on a bigger app? Something like Showcase or the
Expense Report app?

On Mon, Jun 14, 2010 at 4:05 PM, Lex Spoon  wrote:

> It's a fun idea! Methods that are only there for their type signatures
> could have their bodies removed.
>
> Ideally, ControlFlowAnalyzer would be able to identify such methods, and
> Pruner would remove their bodies. With that arrangement, the CFA and the
> method abstracting would mutually benefit each other. It would also lead to
> better code splitting.
>
> ControlFlowAnalyzer already has a notion of "instantiable types". I believe
> it needs to be improved, though, to be effective at abstracting methods. To
> test that theory, set a break point in Pruner.execImpl right before it calls
> setInstantiableTypes. At that point, the question is whether the
> abstractable methods are marked as being called or not. I believe they will
> be marked as callable.
>
> To improve that, a new set could be added to hold the classes that are
> targets of "new". Then, when ControlFlowAnalyzer visits a virtual method
> call, it would have the information it needs to skip over the abstractable
> methods.
>
> I am still mulling over the general idea, but that's my initial reaction.
> If push comes to shove, we could certainly add another whole-tree walk like
> in this patch, and it would be an improvement. It would make a bigger
> improvement, though, if we can factor it into an existing optimization.
>
> Lex
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Bruce Johnson]

What John said. JSO cross-casts allow this.

On Thursday, March 25, 2010, John Tamplin  wrote:
> On Thu, Mar 25, 2010 at 6:07 PM, Rodrigo Chandia  wrote:
>
>
> (Sorry for the spam, Bruce. I forgot to press reply to all.)
>
> I seem to be missing some piece from the puzzle: in which way does
> freezing a MutableArray prevent the allocation of an ImmutableArray
> object?
>
> // This creates a new MutableArray instance
> MutableArray ma = CollectionsFactory.createMutableArray();
> ma.add("x");
> ma.add("y");
> ...
> // But freezing will also instantiate another object, right?
> ImmutableArray ia = ma.freeze();
>
> Internally, freeze will perform something like:
>
> return new ImmutableArrayImpl(elem);
>
> Or is it that in prod mode we can do special tricks to avoid the creation?
> In Javascript, you simply cast MutableArray to ImmutableArrayImpl and return 
> the same object.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to 
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
> email with the words "REMOVE ME" as the subject.
>

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

[gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Bruce Johnson]

On Thursday, March 25, 2010, Freeland Abbott  wrote:
> Am I right to think that the problem with builder.create() is that it implies 
> a defensive copy, to allow you to do builder.add() afterwards, and we want to 
> avoid that?  (If not, then what is the problem?)

Yes, or to avoid having people call build() multiple times. Using a
builder means at least two objects (builder + product(s)) for any
array creation.

> The solution to that could indeed be a more clever builder: at create() time, 
> we return the existing array as an ImmutableArray, and let go of it in the 
> builder, moving it to a previousList filed or somesuch.  If the user does 
> indeed later reuse the builder with some add() (or remove() or whatever), we 
> do the defensive copy then, lazily.  Presumably two back-to-back create() 
> calls could just return the same list, since it's immutable anyway.

These sorts of tricks usually bite us in both size and speed. Also, it
doesn't avoid the "multiple allocations to get just one array"
problem.


>
> I think I like that, personally.  Thoughts?
>
>
>
> On Thu, Mar 25, 2010 at 2:05 PM, Daniel Rice (דניאל רייס)  
> wrote:
>   I have the feeling that if we pushed on the API a bit we could satisfy all 
> the constraints without having to do anything weird.  The only downside would 
> be somewhat more interfaces to understand.  For example, the builder could 
> have create() and createFrozen() methods -- a clever builder implementation 
> could still manage to share state between created instances in some cases.
>
>
>
>
> Dan
>
> On Thu, Mar 25, 2010 at 1:58 PM, Bruce Johnson  wrote:
>
>
> On 3/25/10, Daniel Rice (דניאל רייס)  wrote:
>>   I disagree with point (1).  The APIs are not the same, just almost the
>> same.  IMHO the builder should have a freeze method while the MutableArray
>> should not.  This makes it clear that freezing is a build-time process.  It
>> seems to me that this could be done with a little interface inheritance and
>> probably wouldn't impact generated code size at all.  Thoughts?
>
> (How exactly would the builder and mutable array classes differ? All
> of the points below rest on there not being a meaningful difference.)
>
> I agree it's a little weird not to have a builder, but then again, it
> would be weird to have a builder with freeze() instead of create()
> that can be called multiple times. To me, it's worse to purport to
> follow a pattern people assume they understand intuitively (i.e.
> Builder in this case) but then have different functionality (freeze
> vs. create) than to simply say, "It's unusual, but easy to learn and
> maximally efficient".
>
> And there's also an argument to be made that fewer classes are easier,
> all else being equal. Which would favor not having a builder that is
> quite redundant to mutable array.
>
> -- Bruce
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to 
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
> email with the words "REMOVE ME" as the subject.
>
>
>
>
>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to 
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
> email with the words "REMOVE ME" as the subject.
>

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Bruce Johnson]

On 3/25/10, Daniel Rice (דניאל רייס)  wrote:
>   I disagree with point (1).  The APIs are not the same, just almost the
> same.  IMHO the builder should have a freeze method while the MutableArray
> should not.  This makes it clear that freezing is a build-time process.  It
> seems to me that this could be done with a little interface inheritance and
> probably wouldn't impact generated code size at all.  Thoughts?

(How exactly would the builder and mutable array classes differ? All
of the points below rest on there not being a meaningful difference.)

I agree it's a little weird not to have a builder, but then again, it
would be weird to have a builder with freeze() instead of create()
that can be called multiple times. To me, it's worse to purport to
follow a pattern people assume they understand intuitively (i.e.
Builder in this case) but then have different functionality (freeze
vs. create) than to simply say, "It's unusual, but easy to learn and
maximally efficient".

And there's also an argument to be made that fewer classes are easier,
all else being equal. Which would favor not having a builder that is
quite redundant to mutable array.

-- Bruce

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Bruce Johnson]

I think Rodrigo's point already subsumed what I'm about to say, but there
are three cases here:

1) A read-only reference to a collection that may or may not be mutable by
someone else. This is the purpose of the root type Array, which has not
mutators but doesn't make a guarantee about whether the referenced
collection is mutable or immutable.

2) A reference to a read-only collection whose contents are guaranteed to in
fact be immutable.

3) A normal, mutable array that is read/write.

@Ray: The idea of an immutableView() method doesn't seem to quite handle
these use cases, because either the returned object is a separate object
with a runtime wrapper (the equivalent of unmodifiableList()) or it's a
read-only interface to a collection that isn't really guaranteed to be
immutable, merely read-only. Also note that MutableArray extends the
read-only Array class, and so every MutableArray can be implicitly returned
as a read-only alias anywhere you want, which is even easier than
immutableView().

I would guess it would be fairly typical to use mostly MutableArray and
Array, but ImmutableArray has a real role, too. Imagine a MyPanel that takes
a list of Widgets in its constructor. You could declare the constructor like
this:

   public MyPanel(ImmutableArray widgets) { ... }

That's useful because you can code the class with full knowledge that the
set of widgets won't be changing out from under you from the calling code --
you can just directly assign that param to a field without making a copy.
Had the constructor been:

   public MyPanel(List widgets) { ... }

you could never be sure and would probably feel compelled to make a
defensive copy.

I'm going to guess this is how it would play out:

1) Constructors will often take ImmutableArray because it's nice to assign
ctor params directly to fields and know for a fact there's no reason to make
defensive copies.

2) Fields will be declared as MutableArray, and in getters the return type
will be Array, thus allowing getters to safely return references directly,
happy in the knowledge that there is neither a need to make a defensive
outgoing copy nor a risk that the caller can mutate your private field's
contents.

3) Library methods will take the least-specific type that can suffice for
the respective algorithm. For example, binarySearch(), find(), forEach(),
etc. would take a param of type Array, thus allowing either mutable or
immutable arrays to use the method. Then again, sort() would explicitly take
a MutableArray.

And of course, there is no desire to design all this in a vacuum -- and we
shouldn't argue against it in a vacuum either. This is a starting point
strawman, so I'd propose we use this design as a stake in the ground and
then see how it would play it if we retrofitted it into real code, both app
code and library code. Then we'll really get a feel for how useful vs.
confusing it is, and most importantly, we can get metrics on the speed and
size.



On Mon, Mar 22, 2010 at 6:34 PM, Rodrigo Chandia wrote:

> Immutability is a stronger assertion than read-only access. If I receive a
> read-only object I better make sure to handle the case of the data being
> changed by others; be it by tacit agreement, using other channels, locking
> or simply ignoring the issue. Immutability guarantees the data is stable and
> unchanging. The agreement is explicit. I will be able to read it to my
> heart's content without worry.
>
> Granted, being this a simple implementation it has some inconveniences:
>
> 1. The Immutability is achieved by "freezing" the original Mutable
> container while it may be useful to keep working with the original container
> instead.
> 2. The receiver of a MutableArray may find later that someone called freeze
> on the object causing an error.
>
> This is largely a matter of it being a lightweight implementation. There is
> no contract forcing the mutable view to be tied to the original mutable
> container. A more sophisticated implementation could copy the container,
> implement copy-on-write semantics, or any number of alternative
> implementations. Still the meaning of an immutable collection implies the
> contents will not change, while a read-only view makes no such promise.
>
> 2010/3/22 Ray Ryan 
>
>> My argument is that one is necessary and sufficient. Two is kind of
>> pointless if you have achieved one, and maybe even counterproductive.
>>
>>
>> On Mon, Mar 22, 2010 at 2:32 PM, Joel Webber  wrote:
>>
>>> I think we're talking about two different things here. Rodrigo's (valid)
>>> point is that implementing immutability sanely early on is a good idea. And
>>> this implementation is pretty much analogous to the one you describe from
>>> Cocoa.
>>>
>>> The question at hand is whether it makes sense to get an immutable
>>> collection from a mutable one, with no copies. There are two ways to do
>>> this:
>>> 1. Create an immutable "view" of a mutable list, but with no guarantees
>>> that the list won't be mutated by the original 

Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Bruce Johnson]

@John: I totally agree that's a risk, but then again, the situation you
describe would arguably be a bug anyway -- or at least I'd call it
under-specified. Indeed, I hope that in people's paranoia to avoid those
situations, that they are more thoughtful about the types they hand around
in their API, using the exactly the right semantics for the situation at
hand.

And, of course, there are always tradeoffs in design. The design of these
classes to enable people who are coding things correctly and clearly to not
suffer one iota of overhead for which they don't get commensurate value.
That's same reasoning is why it will use assertions instead of exceptions.

On Mon, Mar 22, 2010 at 3:05 PM, John Tamplin  wrote:

> On Mon, Mar 22, 2010 at 2:19 PM, Freeland Abbott wrote:
>
>> The claim is that you make an ImmutableFoo by "freezing" a MutableFoo,
>> after which the invariant is that no client will change that collection.  It
>> isn't a copy, it's a freeze of the thing, so the flag blocks you from
>> changing via the original MutableFoo handle.
>>
>> Contrast with vanilla Foo, which doesn't have an API for you to change it,
>> but is allowed to change by some other bit (e.g. I have a MutableFoo, and
>> return to you casting to Foo... I can change it, you can't).
>>
>> If you want a copy, copy it yourself (and pay the copy cost explicitly,
>> then freeze one, and you can go on changing the other).  Bruce wants to run
>> pretty close to the wire, so if you mess it up assertions will tell you
>> about the error, but optimized it doesn't, and YMMV w.r.t. the effects.
>>  Since devmode is always asssertions-on, the expectation is you'd find the
>> error soon.
>>
>
> There was a long discussion about this very point on the original wave of
> the design.
>
> The problem I have with it is a client may have been given a MutableFoo and
> then at some point later that same object gets frozen and it is no longer
> mutable, and MutableFoo operations will fail on that object without any
> notification of the client that got the MutableFoo that its contract had
> changed.
>
> You can work around it with conventions, but it seems
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

[gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Bruce Johnson]

Here's how freeze() got introduced.

You need to be able to have ImmutableArray without any mutators, and you
need to be able to create them, thus you need a builder. A very frequent
pattern will be to build up an array with a builder (the hypothetical
ImmutableArrayBuilder) and then want to get an ImmutableArray from it. So,
you'd often write this:

== BEGIN SNIPPET ==
ImmutableArrayBuilder b = new ImmutableArrayBuilder();
b.add(...);
...
ImmutableArray ia = b.build();

// throw away b
== END SNIPPET ==

A few observations about the above inevitable code snippet:
1) ImmutableArrayBuilder would have an API that's almost the same as
MutableArray, so why make it a separate class?
2) The builder pattern typically allows multiple objects to be built from
the same builder, but it's easy to imagine that typical uses won't actually
want to reuse builder instances, thus we're paying for twice the number of
object allocations (1 builder + 1 product) for the common case.

Why solve it with freeze()? This design makes MutableArray into a builder of
ImmutableArrays that is extremely efficient (since it will be implemented as
"return this" and will use JSO cross-casting), thus avoiding the wasteful
builder allocation problem. Secondly, the "freeze()" semantics don't open up
the notion that a single MutableArray could be used as a reusable factory --
unlike build(), freeze() makes it obvious that you can't mess with the
builder anymore.

Hope that makes sense. As Freeland said, this design is based on the idea of
maximum performance, minimum size, and a set of types that allows
applications to avoid expensive allocations and copying. We need a rich
enough set of types that, whatever the circumstances, you're never more than
cheap (hopefully O(1)-time) operation away from having an object that
satisfies the need. For example, we want to encourage handing out aliases to
private fields (making it safe to do so by providing a read-only handle in
the form of the root type).

On Mon, Mar 22, 2010 at 2:06 PM, Ray Ryan  wrote:

> Can you outline a use case? I don't get it. My argument isn't with
> isFrozen, it's with the freezing feature per se. I can't see a reasonable
> use for it.
>
>
> On Mon, Mar 22, 2010 at 11:03 AM, Rodrigo Chandia wrote:
>
>> isFrozen allows assertions on the status of a mutable collection. During
>> normal use (assertions disabled), there should be no need to call isFrozen.
>> Moreover, using isFrozen outside of an assertion, or while assertions are
>> disabled, is not guaranteed to work at all. The intention is to avoid having
>> to pay a runtime penalty and discourage defensive programming.
>>
>> Related to the review, it was not my intention to introduce isFrozen just
>> yet (but it slipped through, sorry). isFrozen is a construct that only makes
>> sense when when Immutable classes are introduced, along with assertions and
>> tests relevant to immutability. At this point I wanted to concentrate on the
>> Mutable and the parent Read-only classes.
>>
>> Is isFrozen still a bad idea when used for assertions only?
>>
>>
>> 2010/3/22 
>>
>> Can someone explain why isFrozen is a good idea? It sounds really,
>>> really bad to me.
>>>
>>>
>>> http://gwt-code-reviews.appspot.com/232801/show
>>>
>>
>>
>

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Array implementation for Lightweight Collections. Pure Java implementation only.

[Bruce Johnson]

@John: I was thinking about actually not even designating the package as
"shared" -- instead just make it a regular-looking Java package. As an
experiment.

On Fri, Mar 19, 2010 at 4:23 PM, John Tamplin  wrote:

> On Fri, Mar 19, 2010 at 4:21 PM, Rodrigo Chandia wrote:
>
>> I guess we could use a supersource trick to swap in the JS-optimized ones
>>
>
> Correct, see RegExp for an example of how this is done.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Array implementation for Lightweight Collections. Pure Java implementation only.

[Bruce Johnson]

re: package...consider skipping the "client" convention because it's
meant to be used on the server too. that new form of target-less
naming is part of the design experiment I hope this work can include.

On Friday, March 19, 2010, Rodrigo Chandia  wrote:
> Sure!
>
> 2010/3/19 Ray Ryan 
>
>
> I think bikeshed/{src,test}/com/google/gwt/collections/client/ is just right.
> Be warned, btw, that we have no ant test target in the build.xml there yet. 
> Patches welcome ;-)
>
>
>
> On Fri, Mar 19, 2010 at 12:15 PM, Rodrigo Chandia  wrote:
>
>
>
> You just told me right in time (talking to myself: how was incantation to 
> revert the last git commit?)
> Just to make sure. The classes should go into:
> bikeshed/src/com/google/gwt/collections/client/
>
>
>
>
> bikeshed/test/com/google/gwt/collections/client/
> Or would it be better to do a new project under bikeshed/collections?
> 2010/3/19 Ray Ryan 
>
>
>
> Great. When you move them to trunk/bikeshed, please don't put them under the 
> com.google.gwt.bikeshed package. We've concluded that was a mistake and will 
> be rejiggering it slightly. Your stuff should stay in its real packages.
>
>
>
>
>
>
> On Fri, Mar 19, 2010 at 9:57 AM, Rodrigo Chandia  wrote:
>
>
>
>
>
>
> Yes. I like your idea. I'll move the development to bikeshed so nobody thinks 
> this is ready for general consumption. Once the classes are in a "good 
> enough" state we will migrate (move) things into GWT proper.
>
>
>
>
>
>
>
>
> Afterwards, integration of these classes into GWT (aka "using them for 
> interesting things") will be done using a branch as some changes might be 
> somewhat intrusive.
> --
>
>
>
>
>
>
>
> Rodrigo
>
> El 19 de marzo de 2010 11:51, Miguel Méndez  escribió:
>
>
>
>
>
>
>
>
> I'm not advocating that you save up for one large patch at the end.  You 
> should have the code reviewed in increments as you are planning on doing.  
> All I'm suggesting is that the code not land in trunk/user/... until is 
> ready.  A real branch or bikeshed would be a better place.
>
>
>
>
>
>
>
>
>
> On Thu, Mar 18, 2010 at 4:44 PM, Rodrigo Chandia  wrote:
>
> Sure, discussion and comments are welcome.
>
> I am developing all this in a branch. The idea is to keep reviewing the 
> changes until we are all satisfied with it. I just thought it made more sense 
> to publish small changes rather than posting a huge patch for review at the 
> end. I can do either or something in between, but I tend to lean towards the 
> incremental approach.
>
>
>
>
>
>
>
>
>
>
>
>
> El 18 de marzo de 2010 14:40, Miguel Méndez  escribió:
>
>
>
>
>
>
>
>
>
>
>
> Not sure if this has been discussed already, but you should consider 
> developing these in a branch until the landing plan for the changes is clear.
>
> On Thu, Mar 18, 2010 at 9:50 AM,   wrote:
>

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] [google-web-toolkit] r7690 committed - Gflow framework with some local CFG-based optimizations....

[Bruce Johnson]

very exciting! nice work.

On Tue, Mar 9, 2010 at 7:20 PM, Scott Blum  wrote:

> w00t!  That's a lot of work that just landed!
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler

[Bruce Johnson]

Thanks for the explanation. Would be really useful to add to the design doc
with enough formatting to make it easy to understand. It just seems like a
very powerful feature that could interact in very hard-to-understand ways
with various build systems, IDEs, etc. So it would need a lot of vetting.

On Tue, Mar 9, 2010 at 3:48 PM, John Tamplin  wrote:

> On Tue, Mar 9, 2010 at 3:31 PM, BobV  wrote:
>
>>  - The runtimeLocale property is defined and collapsed by a
>> ModuleDefMutator which also defines additional rebind rules based on
>> the defined locale values.
>>- One or more ModuleDefMutators are installed by a > class="Foo" /> which are called before ModuleDef.normalize()
>>  - The SelectionProperty interface gains a getCollapsedValues() which
>> gives the values that are equivalent to the value returned by
>> getCurrentValue().
>>- This allows the runtime performance of the Generators to be
>> optimized.
>>  - The locale generators are simplified, removing the runtime locale
>> factory and instead relying on the soft rebind rules created by the
>> ModuleDefMutator.
>>
>
> To clarify the need for ModuleDefMutator -- the way runtime locales work
> currently is that you just define the locales you want to be compile-time
> properties, say "en", "es", and "es_419" (Latin American Spanish) and
> inherit CldrLocales.  The runtime locales will automatically pickup every
> locale that inherits from the current compile-time locale, for example
> picking up es_AR, es_CO, es_MX, etc for the es_419 permutations.  If I later
> added an es_AR locale value (which I might do if I needed a separate
> translation for Argentina), then nothing else has to be be changed -- es_AR
> will no longer be picked up via the es_419 permutation.  Having to specify
> the set of locales and inheritance/aliases between them (which may change
> with each CLDR release) seems like a real pain for a developer, so the idea
> is to allow code to generate the proper collapse-property entries given the
> set of locale values and the inheritance hierarchy among locales.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] RFC : Soft permutations for the GWT compiler

[Bruce Johnson]

Since  amounts to an API change (and sounds pretty weird
from a distance), please update the (nice) design doc and get unanimous
consent from the SDK team (after getting contributor feedback from the group
here).

On Tue, Mar 9, 2010 at 3:31 PM, BobV  wrote:

> Here's what John and I worked out over IM to get the existing runtime
> locales support migrated to soft permutations:
>
>  - The existing locale property continues to work as it currently does.
>  - The runtime.locales configuration property is eliminated in favor
> of a runtimeLocale deferred-binding property.
>  - The runtimeLocale property is defined and collapsed by a
> ModuleDefMutator which also defines additional rebind rules based on
> the defined locale values.
>- One or more ModuleDefMutators are installed by a  class="Foo" /> which are called before ModuleDef.normalize()
>  - The SelectionProperty interface gains a getCollapsedValues() which
> gives the values that are equivalent to the value returned by
> getCurrentValue().
>- This allows the runtime performance of the Generators to be optimized.
>  - The locale generators are simplified, removing the runtime locale
> factory and instead relying on the soft rebind rules created by the
> ModuleDefMutator.
>
> This will increase the size of the permutation-selection matrix, but
> this could be mitigated by using property-value extensions.  In the
> same way that "es_AR extends es", we might have "chrome extends
> safari", "iphone extends safari".  The value extension work is
> separate and orthogonal, but plays nicely with the two techniques in
>
> http://code.google.com/p/google-web-toolkit/wiki/ControllingPermutationExplosion
> .
>
> Thoughts?
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: supporting java.io.InputStream/Reader in GWT's JRE

[Bruce Johnson]

On Tue, Mar 9, 2010 at 11:29 AM, Andi Mullaraj wrote:

> > Also, my coworkers and I are wondering if GWT is single.?
>
> I am not an English native (so I might have read smth you didn't mean :)),
> but this is very funny. I love her too.
>

ha ha -- i'm totally stealing that joke.

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

Re: [gwt-contrib] Re: when-linker-added

[Bruce Johnson]

Is there some sort of lightweight design doc for this? I'm pretty sure I
remember it being discussed somewhere, but we need a short writeup on the
project wiki to capture the context.

On Wed, Mar 3, 2010 at 12:17 PM,  wrote:

>
> http://gwt-code-reviews.appspot.com/150801/diff/1/5
> File dev/core/src/com/google/gwt/dev/cfg/Condition.java (right):
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/5#newcode44
> Line 44: public final boolean isTrue(TreeLogger logger, PropertyOracle
> propertyOracle,
> With pleasure.  Maybe "DeferredBindingQuery" ?
>
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/14
> File dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java (right):
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/14#newcode913
> Line 913: protected Schema __when_linker_added_begin(String linkerName)
> {
> Ah, I missed that class.
>
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/15
> File dev/core/src/com/google/gwt/dev/cfg/Properties.java (right):
>
> http://gwt-code-reviews.appspot.com/150801/diff/1/15#newcode83
> Line 83: public int numPermutations(Set activeLinkerNames) {
> Will do.
>
>
> http://gwt-code-reviews.appspot.com/150801
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: CSS Selector Engine

[Bruce Johnson]

And if we can get GwtQuery to the point where a lot of people really like
it, I think we'd seriously consider rolling it into GWT proper.

On Tue, Feb 9, 2010 at 11:34 PM, Ray Cromwell  wrote:

> GwtQuery was developed before Gwt 2.0 and it's been a while since it's
> been updated, but I believe it always was the intent for it to be a
> 'proving ground' for bringing CSS selectors and jQuery like
> functionality into GWT core. Besides GWT 2.0 and/or IE8, let me know
> any issues that are most important to you. Perhaps I can grant those
> interested in helping comitter access.
>
> -Ray
>
> On Tue, Feb 9, 2010 at 8:12 PM, jarrod  wrote:
> > Yes, I am quite familiar with the project and have tried using it
> > several times. Unfortunately, it does not work very well with GWT 2.0,
> > does not support IE8, and appears to be dead as far as code
> > maintenance. I certainly wish that weren't the case, but given the
> > outstanding issues and lack of any code commits... what can you do?
> >
> >
> http://code.google.com/p/gwtquery/issues/list?can=1&q=&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=tiles
> >
> >
> >
> > On Feb 9, 10:26 pm, John Tamplin  wrote:
> >> On Tue, Feb 9, 2010 at 9:51 PM, jarrod 
> wrote:
> >> > I have to believe this topic has been broached before, but why does
> >> > GWT not contain any kind of CSS selector engine?
> >>
> >> > More and more I am using GWT to build JavaScript API tools for this
> >> > that or the other, and often this means integration with non-GWT code
> >> > (read: hand-written HTML, CSS and JavaScript).
> >>
> >> > Tool kits like JQuery and Dojo provide great helper methods for
> >> > manipulating the DOM via CSS selectors - a feature that is distinctly
> >> > absent from GWT. And yet, because of the vast differences in browser
> >> > support for various CSS selector methods (and CSS support itself), it
> >> > seems like a perfect fit for GWT, given the deferred binding
> >> > capabilities the compiler offers.
> >>
> >> > I do not believe GWT needs to support all the fancy helper "shortcut"
> >> > methods that other toolkits provide. Most of the extra features like
> >> > animation already have reasonable equivalents in GWT, and JQuery's
> >> > method chaining is just a hard-to-read way of minifying your code -
> >> > something GWT also already does. :-)
> >>
> >> > Probably my favorite CSS engine right now is Sizzle JS (http://
> >> > sizzlejs.com/) and I can't imagine it would be hard to write GWT
> >> > bindings for this library (it has three public methods in the API!).
> >> > In fact, if I can't find them with a quick Google search, maybe I'll
> >> > start a new project to do so.
> >>
> >> > The bindings would be a good start, but this is definitely a feature
> >> > I'd like to see get first-class support in GWT.
> >>
> >> Have you seenhttp://code.google.com/p/gwtquery/wiki/GettingStarted?
> >>
> >> --
> >> John A. Tamplin
> >> Software Engineer (GWT), Google
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Questions on JsArray*

[Bruce Johnson]

@John T: Are you saying we wouldn't want those methods on JsArray classes,
though? Seems like that's an appropriate place to put them. People don't
usually subclass containers like that (do they?).

On Tue, Feb 2, 2010 at 2:50 PM, Tom Schindl  wrote:

> On Tue, Feb 2, 2010 at 8:19 PM, John Tamplin  wrote:
> > On Tue, Feb 2, 2010 at 2:16 PM, Tom  wrote:
> >>
> >> I have some questions and proposals around the JsArray-classes because
> >> they are handy when working with JSNI but I believe they could be
> >> improved a bit.
> >>
> >> a) Why are not all native methods provided through the wrapper.
> >
> > One problem is that given how JSOs work, using a name on a parent class
> > means no subclass can have a method of that name.  Thus, you want to be
> very
> > careful about adding methods to a JSO class that is intended to be
> > subclassed.
> > A reasonable option would be to add a final subclass which does have
> those
> > methods, and you can freely cast any JSO to that class when you need to
> use
> > those methods.
>
> Thanks for your response. You are right. I didn't thought about the
> fact that someone could have already subclassed this base
> implementation and would be broken with such a changes.
>
> Anyways I'd volunteer to implement the needed classes if you decide
> that this is a good idea.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Interest in Wave for design docs?

[Bruce Johnson]

Hi folks,

There has been some discussion about having design discussions in Wave, but
maybe not everybody has access yet.

Disclaimer: I can't promise the rate at which everyone will get invites, but
as GWT contributors, I'll happily argue that you should be early in the
queue.

Reply to this thread if you'd like to get an invitation.

-- Bruce

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

Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)

[Bruce Johnson]

On Tue, Feb 2, 2010 at 11:43 AM, Paul Robinson  wrote:

> [...] I, and maybe quite a few others here, don't have access to Wave.
>

We can probably do something about that. I'll start another thread where
people who don't have Wave access yet can indicate interest in signing up.

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

Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)

[Bruce Johnson]

On Mon, Feb 1, 2010 at 4:05 PM, Sami Jaber  wrote:

> I'm agree with Thomas. RegExp integration should have been discussed in the
> list. It is landing into the trunk from nowhere for us...
>

I mentioned a couple of weeks ago that we were switching to a different
version control system -- and this is the first example of the sorts of
hiccups we thought could happen. A Googler, a GWT user but who is not on the
GWT team proper, has been working on this as a potential contribution, and
submitted this patch for a code review. We accidentally approved it for
commit rather than just giving some positive feedback on the code review.
Thus, a work in progress got dumped on svn.

We're still working out what sort of approval process makes sense for these
sorts of contributions, but for a large change like this involving new API
surface area, we definitely do want and need open, public discussion.


> Since the 2.0 release, I feel that there is less interaction with the
> contrib list (btw what have been decided for the roadmap ?) and what we are
> supposed to see in the coming releases.
>

I think more than anything, you're seeing the effects of a lot of us being
tired from the GWT 2.0 push. An updated roadmap is still forthcoming, but I
can summarize a lot of the ad hoc design discussions starting to take place
like this: we need to fill a lot of gaps in the libraries, especially
widgets and "app framewpork" sorts of library code. GWT is powerful at
present, but it doesn't make it especially easy to create traditional
business apps quickly. We'd like to change that.


> We can understand that you prefer to use internal waves/lists but please
> let's not forget the "openess" nature of GWT that contribute to make this
> framework so popular
>

It's true that Wave is fantastic for design docs, and it's hard not to want
to use that instead of email. Maybe the right answer is to get everyone on
this list to move to Wave :-)

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

Re: [gwt-contrib] GWT Incubator Status Update and Schedule

[Bruce Johnson]

Nightly or perhaps less frequent "stable snapshot" builds is something
we'd like to do for sure. Not sure about exactly when, but it's good
to know there would be an audience to justify looking into it a bit.

On Thursday, January 21, 2010, Arthur Kalmenson  wrote:
> Hmm, a nightly build sounds like a cool idea, I wouldn't mind seeing that as 
> well.
> --
> Arthur Kalmenson
>
>
> On Thu, Jan 21, 2010 at 3:28 AM, David  wrote:
>
>
> Hi,
>
> It would be nice that the GWT team would release some development
> builds once in a while. That would be very usefull at the point where
> new things are added to the trunk. This way you can get a lot more
> input from the community, since it makes it much easier to use a more
> experimental version of GWT. Compiling from the sources means that we
> need direct access to the internet, but not all companies allow that.
>
> As long as we have some indication of what is mostly stable and what
> not, we can choose at what point we whish to start using a development
> build.
>
> David
>
> On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy  wrote:
>> Thank you John for your explanation. Now I understand the reason why
>> you are shutting down the incubator. What I am suggesting is that
>> developers should have a place where they can see what new features
>> (libraries,...) are being developed and not to stumble upon this new
>> features by chance (like I stumbled upon the doc for
>> DataBackedWidgetsDesign for example). You mentioned that you send
>> emails when you start a new project. What do I need to do to receive
>> such an email?
>> I think you guys at Google develop great libraries that are perhaps
>> underused because they are hard to find. Let's take Gin for example
>> (http://code.google.com/p/google-gin/). I think that more people would
>> use it if you had a link to Gin from the GWT Tools and Libraries page.
>>
>> Regards.
>>
>> On Jan 20, 5:29 pm, John LaBanca  wrote:
>>> Libraries and widgets that we want to incubate will be moved into separate
>>> projects.  Instead of downloading one incubator jar, you'll be able to (have
>>> to) download each project individually.  Like Ray said, we're going to
>>> commit most new features directly to trunk, but we may still want to
>>> incubate some features if they are highly experimental.  We often setup a
>>> design doc and send out an email when we start a new project, such as the
>>> data backed widgets, so the community can be involved.  I'm sure we'll keep
>>> doing that.
>>>
>>> The advantage of separate projects is that each project can move along at
>>> its own pace.  The incubator currently has some very stable features, some
>>> highly experimental ones, and some deprecated code, and it isn't obvious
>>> which is which (well, except the deprecated stuff).  With individual
>>> projects, it should be more obvious what the state of the project is.
>>>
>>> Thanks,
>>> John LaBanca
>>> jlaba...@google.com
>>>
>>> On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy 
>>> wrote:
>>>
>>> > Then, how about a list of new features in the trunk since the last
>>> > release. That way developers would know if they should become involved
>>> > in the nontrivial (but not too hard) task of compiling GWT from
>>> > source. I take the last comment back if such a list exists. I could
>>> > not find it.
>>>
>>> > Regards.
>>>
>>> > On Jan 20, 4:26 pm, Ray Ryan  wrote:
>>> > > On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy >> > >wrote:
>>>
>>> > > > Hello John.
>>>
>>> > > > I'm glad to see that PagingScrollTable will make it to the GWT trunk.
>>> > > > Even now it is a useful widget but I can't wait to see the final
>>> > > > version. I would like to ask a few questions. I am sorry to hear that
>>> > > > the incubator will be shut down. I w
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Mirrored version control

[Bruce Johnson]

Hi GWT contributors,

This is a quick note to let you know about an internal process change that
the GWT team is making to maintain our sanity during GWT's continued growth
in adoption.

The number of GWT applications built by Google itself -- both outward-facing
apps like Google Wave and AdWords 3 as well as Google's own inward-facing
apps we use to the run the business -- has grown quite a bit over the last
couple of years. This growth brings with it new support challenges, and one
of the biggest is that these projects reside in a different version control
system. Keeping things in sync has created a lot of overhead and, as you can
imagine, headaches.

In the next week or so, we're planning to start committing GWT changes to
the internal version control system first, which will then be mirrored out
to the public svn repository within a few minutes by an automatic sync
process. We have gone to a lot of trouble to make sure that this extra level
of indirection will be so transparent that you won't even notice the change.
Things like commit log comments and author names will continue to appear as
they always have. Design and code reviews will continue to take place on
this public list as always. Contributed patches work the same way as always,
except that they'll be committed indirectly through the mirrored route.

So, again, if all goes as planned, you'll see nothing different. The only
reason we're announcing it at all, is...

1) to apologize in advance if there are some bumps as we get the syncing
thing working properly -- we've tested it a lot, but there's always a chance
of turbulence

2) to let you know to yell if anything looks messed up in the repo, so we
can find and fix those bumps faster :-)

-- Bruce, on behalf of the GWT team
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Removing the deprecated XxxListeners

[Bruce Johnson]

Happy belated birthday!

On Monday, January 4, 2010, Thomas Broyer  wrote:
> On Mon, Jan 4, 2010 at 7:45 PM, Joel Webber  wrote:
>> A hearty +1 from me. We've been needing to do this for a while, but have
>> been so heads-down on new features that it's fallen by the wayside. On that
>> note, we also need to deprecate the DOM class and fix all the widgets to not
>> use it (all its functionality was subsumed by Document/Element a long time
>> ago). We're working on our 2010 roadmap right now, and this will definitely
>> be a part of it.
>
> That's Really. Good. News!
>
> (thanks for this birthday gift ;-) )
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ 
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re:

[Bruce Johnson]

Let's take this to a separate thread or a wave, just to keep things
organized.

2009/12/22 John Tamplin 

> On Tue, Dec 22, 2009 at 10:09 PM, Bruce Johnson  wrote:
>
>> Related future discussion: I'm not really a fan of
>>  and would love to see it go away since in
>> principle it unifies with  (doesn't it?) All this stuff it
>> getting too fragmented and confusing.
>>
>
> The fundamental difference is that a config property may:
>
>- have values which are not valid Java identifiers
>- have values not known ahead of time, such as a filename
>- have multiple values
>- do not impact the set of permutations compiled
>
> What did you have in mind to unify that with deferred binding properties?
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

Re: [gwt-contrib] Re:

[Bruce Johnson]

Lex/Bob: To clarify one thing, did you mean



vs.



in the example of adding a linker conditionally? I think the latter is what
we'd want, right?

I agree it sounds like a nice, unifying change. In the process of cleaning
all this up (e.g. deprecation, errors for invalid combos) we really need to
bite the bullet and actually specify what the real API-level deferred
binding properties are -- the ones people should mention in books and
articles -- versus the ones we just use for intermediate values in an ad hoc
manner with the expectation of changing them at will.

Related future discussion: I'm not really a fan of
 and would love to see it go away since in
principle it unifies with  (doesn't it?) All this stuff it
getting too fragmented and confusing.

On Tue, Dec 22, 2009 at 4:17 PM, BobV  wrote:

> > Do you see a need for more deprecation?  If that's all it is, then it
> > seems reasonable to hard code the specific deprecations in the
> > compiler rather than adding a general deprecation system for module
> > components.
>
> It would be a nice-to-have.  RayC's impending change to enable
> stack-stripping effectively deprecates the "compiler.emulatedStack"
> property.  Similarly, there are some ClientBundle properties which are
> still defined, but that are unused.  The change should be pretty much
> confined to BodySchema and ModuleDef.normalize().
>
> Otherwise, the two items from your previous email SGTM.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>

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

Re: [gwt-contrib] uibinder and bnudled CSS

[Bruce Johnson]

Definitely do need to escape, as you said.

On Thursday, December 17, 2009, John Huss  wrote:
> I think you have to escape the css attributes that start with a dash
> like this:
>
> \-moz-box-shadow: 2px 2px 5px #000;
>
> You should be getting a warning about it in dev mode if you are not -
> making sure you having logging on at a good level.
>
> John
>
> On Dec 17, 6:03 am, "nicolas.deloof"  wrote:
>> Hi
>>
>> I'm migrating some nice HTML-fragment to GWT. Thanks to UiBinder this
>> is really easy and I get a nice result in few hours.
>>
>> I notice the uiBinder seems to rewrite the CSS rules according to
>> browser support (I may be wrong) : my CSS uses CSS3 box-shadow :
>>
>>         box-shadow: 2px 2px 5px #000;
>>         -moz-box-shadow: 2px 2px 5px #000;
>>         -webkit-box-shadow: 2px 2px 5px #000;
>>
>> This works fine on my Chrome browser, but when I use the uibinder
>> version I dont' have shadows anymore. The CSS rule filter should not
>> remove any -webkit* rule when targeting a webkit based browser,
>> sould'it ? Also the box-shadow is supported by recent webkit browsers
>> (it is on chrome 4, but this is in the dev channel)
>>
>> 2nd question : If my CSS uses background-image: url(...), can I
>> include those images in my ClientBundle and still make references to
>> them in my CSS fragement ?
>>
>> Cheers,
>> Nicolas
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] now.. afetr GWT 2.0?

[Bruce Johnson]

Working on a draft one.

What do folks here think is important?

On Wed, Dec 16, 2009 at 7:42 AM, tfreitas  wrote:

> What about roadmap?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: add option to generate overflow checks

[Bruce Johnson]

This needs to be its own thread, but heads up: flags that affect compiler
output (other than -draftCompile) need to become deferred binding properties
so that we can have per-perm flags. Then, we can produce standard sets of
module flags such as "Release" and "Debug" that would make easy to activate
groups of such properties at once.

This seems like it fits squarely into the category of "flags you'd want to
be per-perm"

On Tue, Dec 15, 2009 at 9:45 AM, John Tamplin  wrote:

> On Tue, Dec 15, 2009 at 4:00 AM,  wrote:
>
>>
>> http://gwt-code-reviews.appspot.com/126801/diff/1/5
>> File
>>
>> dev/core/src/com/google/gwt/dev/jjs/impl/OverflowDetectionNormalizer.java
>> (right):
>>
>> http://gwt-code-reviews.appspot.com/126801/diff/1/5#newcode55
>> Line 55:
>> Should we care about JSOs returning values which are already overflowed?
>> e.g. byte foo = someJSO.getLargeValue()? (Scott, is a cast auto-inserted
>> for this?) A JDeclarationStatement will be missed by this visitor.
>
>
> We already catch those in dev mode, but we don't catch overflow because
> running the code in the bytecode means there won't be any overflow.  It
> could be done as bytecode rewriting, but that is actually far more
> complicated since you can't look at the result but have to look at the
> operands before the operation and do a different check per operation.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: webAppCreator and RpcServerTemplate.javasrc

[Bruce Johnson]

What John said :-)

On Saturday, December 5, 2009, John Tamplin  wrote:
> On Sat, Dec 5, 2009 at 4:36 AM, Sami Jaber  wrote:
>
>
> I know that post RC 2 rules disallow to get last minute modification into the 
> 2.0 release. However, this modification would be slightly minor and won't 
> imply any side-effect issues.
> webAppCreator is used in the GPE Plugin and in command line mode, this tool 
> is very important. We all agree that deRPC is aimed at replacing RPC 1.0. So 
> why not generating the Greeting sample with RpcService and RpcServlet classes 
> ?
>
>
> GPE understands very well the deRPC new interfaces and synchronize the async 
> interface as before (with RemoteService) ..
> deRPC doesn't have the mileage on it to make it the default, and also has 
> some negatives (such as payload size) that don't make it appropriate 
> everywhere.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

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

Re: [gwt-contrib] Re: Proposals for mechanisms to "strip stack information" from compiled output

[Bruce Johnson]

@Bob: You rock.
@Ray: I like.

On Fri, Nov 27, 2009 at 1:13 AM, Ray Cromwell  wrote:

>
> Bob,
>   I love your proposal, if Bruce like's it, I'll go ahead and implement it
> (perhaps without the A/B testing part? We can leave that as a Wiki entry?)
>
> -Ray
>
> On Wed, Nov 25, 2009 at 7:23 AM, BobV  wrote:
>
>> On Wed, Nov 25, 2009 at 9:58 AM, Bruce Johnson  wrote:
>> > A) I want stack traces everywhere that it isn't costly.
>>
>> 
>> 
>> 
>> 
>>  
>>
>>
>>  
>> 
>>
>> 
>> 
>>  
>> 
>>
>> > B) I want stack traces on every browser possible, and for browsers in
>> which
>> > it is costly, I want to only burden a random 2% of those users.
>>
>> 
>> 
>>  // Do something with cookies, recalculating value every week
>> 
>>
>> 
>>  
>>  
>> 
>>
>> 
>>  
>>  
>> 
>>
>> > C) I want maximum fidelity stack traces everywhere, even paying for
>> > emulation on browsers that have native stack traces, if that's better.
>>
>> 
>>
>> > D) I want the smallest possible script size by default, but I'm willing
>> to
>> > burdon a random 2% of users to capture stack traces.
>>
>> 
>> 
>> 
>>  
>>  
>> 
>> 
>>  
>>  
>> 
>>
>>
>> --
>> Bob Vawter
>> Google Web Toolkit Team
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: Proposals for mechanisms to "strip stack information" from compiled output

[Bruce Johnson]

We need to call out some use cases that show how these settings would be
used in practice, for posterity if nothing else.

Could you describe how we would handle each of these high-level intents that
a developer might have?

A) I want stack traces everywhere that it isn't costly.

B) I want stack traces on every browser possible, and for browsers in which
it is costly, I want to only burden a random 2% of those users.

C) I want maximum fidelity stack traces everywhere, even paying for
emulation on browsers that have native stack traces, if that's better.

D) I want the smallest possible script size by default, but I'm willing to
burdon a random 2% of users to capture stack traces.

If we could write clear rules for each of these scenarios, then it's
probably sound and easy enough to understand.

On Wed, Nov 25, 2009 at 9:33 AM, BobV  wrote:

> Since emulatedStack and stripStack are mutually-exclusive, I'd say to
> switch to option number three and use the conditional property setters
> to support the old value.  Something like:
>
>  />
> 
> 
>  
> 
>
> Also, we should probably get around to adding a way to deprecate old
> deferred-binding properties.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Remove TODOs from hosted.html

[bruce]

LGTM

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

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

Re: [gwt-contrib] TypeOracle allTypes including types not in a path

[Bruce Johnson]

let's remember to talk about this more for the release after 2.0

On Mon, Nov 23, 2009 at 2:26 PM, Isaac Truett  wrote:

> +1 deprecate and warn.
>
> On Mon, Nov 23, 2009 at 2:24 PM, Ray Ryan  wrote:
> > FWIW, this confusion is exactly why webAppCreator no longer generates
> > projects that use the implicit include. I wonder if we shouldn't flat out
> > deprecate it--in which case a warning would be the right thing.
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] TypeOracle allTypes including types not in a path

[Bruce Johnson]

Maybe not a warning, but maybe an INFO-level log entry, or perhaps a
TRACE-level one. I think the default introduction of source path="client" is
net confusing. Forcing people to specify it would have helped (forced?)
people to understand what is going on.

On Mon, Nov 23, 2009 at 1:40 PM, John Tamplin  wrote:

> On Mon, Nov 23, 2009 at 1:33 PM, Matt Mastracci wrote:
>
>> I'll work around the implicit source path issue for now by using fake
>> source paths in modules that don't have any additional source
>> imports.  If possible, it would be useful if there were a log warning
>> explaining that the source path is defaulting to "client".
>>
>
> I don't think that warning there would be good, as that is a pretty common
> default - basically if you are using the recommended package setup and you
> don't have server-shared code, the common case is not needing any 
> tag in your module.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] adding new names to the blackout list

[Bruce Johnson]

+1 Freeland. You may then also like the planned "private goto", which
goes somewhere but it doesn't tell you where it's gone.

On Tuesday, November 17, 2009, Freeland Abbott  wrote:
> Personally, I'm holding out for "transient goto"... imagine being able to 
> leap to another chunk of code, and then back again when it finishes!
>
> On Tue, Nov 17, 2009 at 5:27 PM, Bruce Johnson  wrote:
> I'm especially excited about "goto"! Think of how powerful and flexible that 
> will be!
>
>
> On Tue, Nov 17, 2009 at 3:13 PM, Daniel Rice (דניאל רייס)  
> wrote:
>> // "future reserved words"
>> "abstract", "int", "short", "boolean", "interface", "static", "byte",
>> "long", "char", "final", "native", "synchronized", "float", "package",
>> "throws", "goto", "private", "transient", "implements", "protected",
>> "volatile", "double", "public",
>
>   What a future it will be...
>
> Dan
>
> On Tue, Nov 17, 2009 at 3:11 PM, Freeland Abbott  wrote:
>> I don't promise this is exhaustive, but it catches up to the mozilla and IE
>> references, plus uneval from issue 3965.  (Which wasn't on the mozilla
>> pages, despite being reserved there, so I'm in fact almost sure this
>> isn't exhaustive...)
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>
> --
>
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

[gwt-contrib] Re: Reduce log levels, remove stderr launch URL message

[bruce]

LGTM

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

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

[gwt-contrib] Re: RR : GWT 2.0 Polish : Set application title, dock image on OS X

[bruce]

Two other things:
- Can we do something about the icon?
- Where on earth is that About dialog box coming from? It has a
completely random version string.


http://gwt-code-reviews.appspot.com/103804/diff/1/2
File dev/core/src/com/google/gwt/dev/BootStrapPlatform.java (right):

http://gwt-code-reviews.appspot.com/103804/diff/1/2#newcode42
Line 42: "GWT DevMode");
On 2009/11/17 21:59:57, jat wrote:
> I think we have been spelling it out.  For example, the Swing UI is
titled "GWT
> Development Mode".

The ideal is for the menu item to read "Development Mode" (not prefixed
with GWT) and for the About menu text to read "About Google Web Toolkit
Development Mode"

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

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

Re: [gwt-contrib] adding new names to the blackout list

[Bruce Johnson]

I'm especially excited about "goto"! Think of how powerful and flexible that
will be!

On Tue, Nov 17, 2009 at 3:13 PM, Daniel Rice (דניאל רייס)
wrote:

> > // "future reserved words"
> > "abstract", "int", "short", "boolean", "interface", "static", "byte",
> > "long", "char", "final", "native", "synchronized", "float", "package",
> > "throws", "goto", "private", "transient", "implements", "protected",
> > "volatile", "double", "public",
>
>  What a future it will be...
>
> Dan
>
> On Tue, Nov 17, 2009 at 3:11 PM, Freeland Abbott 
> wrote:
> > I don't promise this is exhaustive, but it catches up to the mozilla and
> IE
> > references, plus uneval from issue 3965.  (Which wasn't on the mozilla
> > pages, despite being reserved there, so I'm in fact almost sure this
> > isn't exhaustive...)
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Using @if in CSS to provide 1-bit-alpha images on IE6 in the Mail sample.

[bruce]

LGTM

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

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

[gwt-contrib] Google Web Toolkit 2.0 RC1 Now Available

[Bruce Johnson]

Hi folks!

GWT 2.0 RC1 is now ready for you to try. The full documentation is still
very much a work in progress, but you can at least start trying out the GWT
SDK distribution and the Google Plugin for Eclipse using the following
instructions:

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

GWT 2.0 is going to be a big release, so don't be surprised if there are a
few bumps and surprises as we continue to finalize everything. Similarly, we
would caution you against using GWT 2.0 RC1 in production.

We are eager to get your feedback, both good and bad, in the Google Web
Toolkit Developer Forum:

http://groups.google.com/group/google-web-toolkit

If you find specific bugs to report, please do so in the GWT Issue Tracker:

http://code.google.com/p/google-web-toolkit/issues

See you online. Happy coding :-)

-- Bruce, on behalf of the GWT team

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

Re: [gwt-contrib] Re: Cannot install gwt-dev-plugin.exe from gwt-dev-missing-plugin.appspot.com

[Bruce Johnson]

And, by the way, a lot of this stuff is still in flux. If you're grabbing
bits and pieces as they appear, you mileage is bound to vary widely :-)

On Tue, Nov 17, 2009 at 12:20 PM, Mark Renouf  wrote:

> Oh, sorry... I *just* saw r6956. That worked. Thanks!
>
> On Nov 17, 12:05 pm, John Tamplin  wrote:
> > Yes, we are aware of it and fixing it right now.
> >
> > In the meantime, you can use this outrageously long URL:
> >
> > https://dl-ssl.google.com/tag/s/appguid%3D%7B9a5e649a-ec63-4c7d-99bf-...
> >
> > On 11/17/09, Mark  Renouf  wrote:
> >
> > > All I get is a dialog box "Google Installer" / "Unknown Installer
> > > Error"
> >
> > > Windows XP SP3, IE7, VMware
> >
> > > Screenshot:
> > >http://google-web-toolkit-contributors.googlegroups.com/web/Screensho.
> ..
> >
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
> > --
> > John A. Tamplin
> > Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Code Review Request: Made missing plugin iframe prettier

[Bruce Johnson]

Committed to tr...@6891 and merged to 2...@6892.

On Fri, Nov 13, 2009 at 12:06 PM, John Tamplin  wrote:

> On Fri, Nov 13, 2009 at 12:03 PM,  wrote:
>
>> Thanks for the review. Reply below.
>>
>>
>>
>> http://gwt-code-reviews.appspot.com/102815/diff/1002/3
>> File hosted.html (right):
>>
>> http://gwt-code-reviews.appspot.com/102815/diff/1002/3#newcode35
>> Line 35: var iframeDiv = topDoc.createElement("div");
>> On 2009/11/13 16:55:51, jat wrote:
>>
>>> Why topDoc instead of $doc?  Do you really want it stepping outside of
>>>
>> this
>>
>>> iframe?
>>>
>>
>> This is the incantation that seemed to work most reliably on IE6 to get
>> rid  of the yucky iframe border. I didn't really investigate too much
>> why or if there could be a better way. Either way, I think it's fine
>> because the iframe contents do completely cover up everything on the
>> page (intentionally - I thought hard about the pros/cons).
>>
>
> Ok, LGTM
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

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

[gwt-contrib] Code Review Request: Updated hosted.html to be pretty

[Bruce Johnson]

Hi John (and "Hi, contrib group!"),

I've been fighting to find just the right incantation to make the missing
plugin flow go smoothly. I think it's pretty  close now.

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

-- Bruce

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

[gwt-contrib] MissingPlugins updates for platforms, formatting

[bruce]

LGTM

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

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

[gwt-contrib] Re: Trace that auto detects the calling class/method.

[Bruce Johnson]

On Tue, Nov 10, 2009 at 11:12 AM, David  wrote:

> Do I read this correctly that stacktraces in exceptions will just be
> available (also on IE if the emulated mode is enabled at compile time)
> ? That would make my current implementation of finding the source of a
> Trace statement just work without changes. Great stuff.
>

Yep!

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

[gwt-contrib] Re: RR : GWT 2.0 : Make GenerateCssAst respect mtime

[bruce]

LGTM

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

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

[gwt-contrib] Re: RR : GWT 2.0 : Make GenerateCssAst respect mtime

[bruce]

Refresh seems to work as expected now. Note the one impl comment, tho.


http://gwt-code-reviews.appspot.com/96801/diff/1002/4
File user/src/com/google/gwt/resources/css/GenerateCssAst.java (right):

http://gwt-code-reviews.appspot.com/96801/diff/1002/4#newcode716
Line 716: logger.log(TreeLogger.DEBUG, "Invalidating cached
stylesheet");
Wouldn't it make sense to explicitly remove the known-invalid stylesheet
from the map at this point, to avoid having them accumulate?

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

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

[gwt-contrib] Re: Fixes NPE in DockLayoutPanelParser when children have no NS

[Bruce Johnson]

I just committed to trunk but haven't merged to 2.0. Feel free to roll
mine back and do something better.

On Wednesday, November 4, 2009, Ray Ryan  wrote:
> Thanks for the patch, Bruce. It's is a bit more complicated than it needs to 
> be, though (if parent doesn't have a prefix it will never get parsed), and 
> still doesn't fix the confusing error message. How does the attached look?
>
>
> rjrjr
>
> On Wed, Nov 4, 2009 at 7:05 AM,   wrote:
>
>
> On 2009/11/04 03:01:41, bruce wrote:
>
>
> LGTM. I think that to really get this right in general, with better
> error messages, we're going to have to normalize the way we handle
> custom parsers around some shared abstractions. But that's for another
> day...
> Might be able to do something about that today. I've got field references 
> done, and I'm thinking that before I start hunting escaping bugs that bit 5% 
> of users I should go stomping NPEs and code gen problems that stomp nearly 
> everybody.
>
>
>
> http://gwt-code-reviews.appspot.com/91813
>
>
>

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

[gwt-contrib] Fixes NPE in DockLayoutPanelParser when children have no NS

[bruce]

Reviewers: jgw,

Description:
Forgetting a namespace prefix on a child elem of DockLayoutPanel causes
an NPE, for example:


   foo
   


Unfortunately, even after the patch the error message is confusing. It
says:
"In , child must be one of {north, south,
east, west, center}"

The problem is that when you look at the XML, it seems like you've done
exactly what's being asked for. The error message ought to someone
account for the NS mismatch in how it explains the error.

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

Affected files:
   user/src/com/google/gwt/uibinder/parsers/DockLayoutPanelParser.java


Index: user/src/com/google/gwt/uibinder/parsers/DockLayoutPanelParser.java
===
--- user/src/com/google/gwt/uibinder/parsers/DockLayoutPanelParser.java  
(revision 6630)
+++ user/src/com/google/gwt/uibinder/parsers/DockLayoutPanelParser.java  
(working copy)
@@ -98,8 +98,22 @@
}

private boolean isValidChildElement(XMLElement parent, XMLElement child)  
{
-return child.getNamespaceUri().equals(parent.getNamespaceUri())
-&& DOCK_NAMES.containsKey(child.getLocalName());
+String childNsUri = child.getNamespaceUri();
+String parentNsUri = parent.getNamespaceUri();
+if (childNsUri == null && parentNsUri != null) {
+return false;
+}
+if (childNsUri != null && parentNsUri == null) {
+return false;
+}
+if (!childNsUri.equals(parentNsUri)) {
+  return false;
+}
+if (!DOCK_NAMES.containsKey(child.getLocalName())) {
+  return false;
+}
+// Made it through the gauntlet.
+return true;
}

private boolean requiresSize(XMLElement elem) {



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

[gwt-contrib] Re: Compiler Optimization Thought: Class merging

[Bruce Johnson]

This topic usually centers on all the little types needed for various event
handlers. Happily, @UiHandler in UiBinder removes the whole issue. The
UiBinder code generator can do whatever nastiness it needs to in order to
create the most efficient event handler/dispatch code. IOW, it's not only
more convenient to write your code using @UiHandler, it's almost certainly
more efficient than what you'd create by hand even if you were willing to do
the Hard Thing in your own handwritten code.

On Tue, Nov 3, 2009 at 12:23 PM, Scott Blum  wrote:

> Hi Nathan,
>
> We've talked about doing something like this, under various names,
> including "inner class elision".  It seems worthwhile in the abstract, to
> reduce client-side object counts.  What I'm not sure of is how hard it
> really would be to get right.  In the past we've had discussions about the
> attributes of the classes to be merged.  They'd need to be singletons within
> their containing class, final, initialized up front.. and references
> wouldn't be allowed to "escape" into the wild.  And that last one is the
> real sticking point for what you want... allowing references to escape gets
> very problematic, but not allowing them to escape makes it very hard to
> actually get it to kick in for the exact case you're trying to solve.
>
> Scott
>
> On Tue, Nov 3, 2009 at 11:43 AM, Nathan Wells  wrote:
>
>>
>> As I was developing this morning, I came across a trade-off that I
>> wasn't happy with. Namely, as I create handlers and other interface
>> implementations in a given class, the implementations create new
>> classes, which adds additional, unnecessary code into the compiled
>> output.
>>
>> One way around this is to sacrifice my code readability and simply
>> have the containing class implement those interfaces. For example,
>>
>> class Foo {
>>  static class BarHandler implements ClickHandler, KeyDownHandler {
>>...
>>  }
>>
>>  static class FooCommand implements Command {
>>...
>>  }
>>
>>  ... class body that doesn't implement and onClick, onKeyDown or
>> execute method...
>>
>> }
>>
>> could compile to something like
>>
>> class Foo implements ClickHandler, KeyDownHandler, Command {
>>  ... merged implementations ...
>> }
>>
>> Of course, I'm operating under a few assumptions (based on my watching
>> this group and the developer group, and my lack of knowledge about how
>> the compiler actually works ;)
>>
>> 1. This isn't already done,
>> 2. Adding more classes actually significantly increases the bulk of
>> compiled output.
>> 3. The amount of time to add this optimization would be less than the
>> pain of the trade-off I'm dealing with.
>>
>> Let me know what you think,
>> Nathan
>>
>>
>
> >
>

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

[gwt-contrib] Re: Random Thought: Compiler transformation Sync -> Async

[Bruce Johnson]

At a quick glance, something like this seems way better than a wholesale
sync->async rewriter.

It's actually important not to hide genuine asyncrony from the developer,
because it represents an actual app state the developer should account for
(e.g. what UI should be disabled while an async operation is pending? do you
show a "please wait" or not?). What we'd want is a framework that makes it
easier to produce and reason about necessarily async patterns.

On Mon, Nov 2, 2009 at 12:42 PM, Matt Mastracci wrote:

>
> The API is just a skeleton to experiment with all the strong-typing
> that would go along with porting Oni to Java, so there's not much
> there. It helped prove that the concept was sound if I had a chance to
> take a go at it and gave me some code to look at while planning it
> out. There's still a some porting work to take the Oni code and Java-
> fy it.
>
> I think this is the right first step - once you have a solid async
> library like this, there are some interesting things you can build on
> it (as Stratified JavaScript builds on Oni:
> http://www.croczilla.com/blog/17)
> .
>
> On 2-Nov-09, at 6:17 AM, Bart Guijt wrote:
>
> > Just checked out Oni - interseting indeed, could have used something
> > like that in several recent GWT projects I did.
> >
> > You mentioned you roughed out an equivalent GWT API - is it publicly
> > accessible?
>
>
>
>
> >
>

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

[gwt-contrib] Re: propagate log colors up the message tree

[bruce]

LGTM. This might be enough without auto-expanding the nodes in error. We
can wait on that.

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

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

[gwt-contrib] Re: Inline Polymorphic Function Declarations

[Bruce Johnson]

yep, and all of them should be per-perm

On Saturday, October 31, 2009, Ray Cromwell  wrote:
> Maybe it would make sense to move properties which the compiler relies on 
> into a special CompilerFlags.gwt.xml module, then if you want to change class 
> meta data, class cast checking, aggressive optimization, or stack info, 
> there'd be one centralized place to look at and document all the flags.?
>
> -Ray
>
> On Fri, Oct 30, 2009 at 9:31 PM, Bruce Johnson  wrote:
>
>
> I wish we could wrap that all up in a simpler-to-understand package.
> But a good article would make it at least bearable.
>
> On Saturday, October 31, 2009, Ray Cromwell  wrote:
>>
>>
>> On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson  wrote:
>>
>>
>> In terms of design, I think this would actually be best as a 
>> permutation-specific conditional deferred binding property that the compiler 
>> is sensitive to (that was a mouthful), so that it would be possible to let 
>> app developers control how many stack trace-enabled users there are, in the 
>> same way they can control how many users get the expensive emulated stack 
>> traces on IE. I would guess something like <= 10% would need stack traces 
>> enabled to still get good stats.
>>
>> Perhaps we can think of it as a tri-state variable: strip stack info, 
>> browser supplied stack info, emulated stack info. Choose per permutation.
>> -Ray
>>
>>
>>
>>
>>
>>
>>
>>
>> >
>>
>
>
>
>
> >
>

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

[gwt-contrib] Re: Inline Polymorphic Function Declarations

[Bruce Johnson]

I wish we could wrap that all up in a simpler-to-understand package.
But a good article would make it at least bearable.

On Saturday, October 31, 2009, Ray Cromwell  wrote:
>
>
> On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson  wrote:
>
>
> In terms of design, I think this would actually be best as a 
> permutation-specific conditional deferred binding property that the compiler 
> is sensitive to (that was a mouthful), so that it would be possible to let 
> app developers control how many stack trace-enabled users there are, in the 
> same way they can control how many users get the expensive emulated stack 
> traces on IE. I would guess something like <= 10% would need stack traces 
> enabled to still get good stats.
>
> Perhaps we can think of it as a tri-state variable: strip stack info, browser 
> supplied stack info, emulated stack info. Choose per permutation.
> -Ray
>
>
>
>
>
>
>
>
> >
>

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

[gwt-contrib] Re: Inline Polymorphic Function Declarations

[Bruce Johnson]

Very cool find.

On Fri, Oct 30, 2009 at 8:00 PM,  wrote:

> Note, that if you don't desire correct stack traces, you can use the
> following construct:
>
> _.foo = function() { ... }
>
> This results in a 6% post-gzip size reduction on Showcase. It might be
> useful to introduce a permutation parameter like
> "stripStackInformation", like -XdisableClassMetadata to enable this
> feature.
>

Please add an issue to go back and actually add this ability. 6% on Showcase
is too good to turn down; likely it would be even bigger on real-world apps
with lots more patterns that induce runtime polymorphism.

In terms of design, I think this would actually be best as a
permutation-specific conditional deferred binding property that the compiler
is sensitive to (that was a mouthful), so that it would be possible to let
app developers control how many stack trace-enabled users there are, in the
same way they can control how many users get the expensive emulated stack
traces on IE. I would guess something like <= 10% would need stack traces
enabled to still get good stats.

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

[gwt-contrib] Re: Fix a daylight saving bug

[Bruce Johnson]

If you're confident in the fix, Dan, instead of adding a test right now,
please just add an issue instead to remind us to review in the future what
kind of testing mechanism we would have needed to make a unit test easy to
create for this case. I want to make sure we revisit this at some point to
round out our testing story, even for hard things to test.

On Fri, Oct 30, 2009 at 1:23 PM, Daniel Rice (דניאל רייס)
wrote:

>   I'm not sure how to so this -- my testing involved manually setting the
> machine's time zone.  Ultimately the bug is in the fact that the native
> Javascript Date functions deal with the missing hour differently that Java's
> Date class, and I don't know that I can coerce the Javascript functions into
> doing this specific behavior except by altering the OS environment.
>
>   Also, this particular bug should only manifest when moving the clock
> ahead.  When going in the other direction, there is no missing hour, instead
> there is a duplicated hour.  While that may lead to other problems, it won't
> cause a wrong date to be inferred.
>
>   There's a theoretical possibility that some location could advance their
> clock by something other than one hour.  I'm not sure what to do about that,
> but I don't think there is anywhere in the world that does this at the
> moment.
>
> Dan
>
> On Fri, Oct 30, 2009 at 12:41 PM,  wrote:
>
>> We should have unit tests for all of these cases, testing DST going in
>> both directions (spring and fall).
>>
>> LGTM pending unit tests
>>
>>
>> http://gwt-code-reviews.appspot.com/90802
>>
>
>
> >
>

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

[gwt-contrib] Re: TBR requested

[Bruce Johnson]

both lgtmd kthxbye

On Thu, Oct 29, 2009 at 7:28 PM, Ray Ryan  wrote:

> Hey, Bruce. I TBR'd you on these:
>
> http://code.google.com/p/google-web-toolkit/source/detail?r=6550
> http://code.google.com/p/google-web-toolkit/source/detail?r=6552
>

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

[gwt-contrib] Re: Very fast code review: Adding UiBinder to javadoc

[Bruce Johnson]

SGTM

On Wed, Oct 28, 2009 at 7:12 PM, Ray Ryan  wrote:

> If you don't feel strongly about it, I'd like to leave it where it is.
> It's a pretty integral part of binder itself.
>

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

[gwt-contrib] Re: Very fast code review: Adding UiBinder to javadoc

[Bruce Johnson]

On Wed, Oct 28, 2009 at 6:38 PM, Ray Ryan  wrote:

> We usually use gwt-code-reviews.appspot.com, but LGTM'd anyway.
>

Oh yeah -- thanks. Duh.


> Testing is on its way out of user/src and into user/testing, review
> pending.
>

'k.


>
> sample isn't really a sample, it's become a test app. It should
> probably move to user/testing as well.
>

If it's a genuine test (as in a test case), then under user/test makes
sense.


> resources is unique to UiBinder as far as I know. It's the master copy
> of the file that we serve out of
> http://google-web-toolkit.googlecode.com/files/xhtml.ent, and has to
> be available to UiBinderGenerator as a resource at code gen time. Any
> suggestion where to put it instead?
>

Maybe in distro-source? That's where the DTD is, and it feels like a sibling
of that maybe. No strong opinion.

http://code.google.com/p/google-web-toolkit/source/browse/#svn/trunk/distro-source/core/src

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

[gwt-contrib] Very fast code review: Adding UiBinder to javadoc

[Bruce Johnson]

Hi Ray,

http://codereview.appspot.com/144046

The only thing controversial is that I'm including only the .client package
for now. It wasn't clear what else should go in there.

-- Bruce

P.S. What's up with these guys: .sample, .testing, and .resources? Seems
like there are already established patterns that differ from what you've
done here.

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

[gwt-contrib] Re: Server side I18N

[Bruce Johnson]

Thoka, I hope previous replies didn't come across as a debate as to whether
the use cases you describe are valuable or not; clearly they are.
The point is just that we want to identify exactly what the pros/cons of
each world view are to decide, among other things, if there is "one right
answer" versus just acknolwedging that there should be multiple libraries,
each with different tradeoffs. In this case, it seems quite likely to be the
latter.

So, as Ray suggests, if you'd be willing to make your library available, you
could start evangelizing it to other GWT users and if over time a consensus
emerges in favor of that approach, it would be much easier to justify trying
to roll that functionality into GWT proper.


On Wed, Oct 21, 2009 at 2:37 PM, Thoka  wrote:

>
> No, the code does not involve changes to the standard library. The
> only thing you have to do is to replace the localization module to
> another in the gwt.xml file. It is very simple and contains about 5
> simple classes. The only thing you have to do manually is to link
> "lang.js" to a servlet in web.xml.
>
> We started creating this module for about 3 month ago, and we still
> need to test it more thorough, which is why I posted this here to get
> more people involved for comments, features and optimizations. We've
> deployed an application live containing this server side I18N, and it
> is working like a charm:
>
> http://www.facebook.com/video/video.php?v=1174821983024&ref=mf
>
> If you are interested in trying it out your selves, I'll be happy to
> supply you with information and source code.
>
> On Oct 21, 11:22 pm, Ray Ryan  wrote:
> > Thoka, does your code involve changes to GWT proper? If not (or if so,
> for
> > that matter), would you be willing to create a new Google Code site for
> it?
> > It doesn't have to be part of GWT proper to be useful. And there's no
> reason
> > it couldn't reach GWT proper via that route--probably more likely for a
> > larger feature like this one.
> > rjrjr
> >
>

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

[gwt-contrib] Re: Server side I18N

[Bruce Johnson]

@Thobias: I want to make sure I'm understanding the root motivation. Is the
problem that compiles are taking too long when you create permutations per
locale? Perhaps the more fundamental question I should ask is: would you
describe exactly what's unserviceable about the current static approach that
John just mentioned?

On Mon, Oct 19, 2009 at 7:57 PM, John Tamplin  wrote:

> On Mon, Oct 19, 2009 at 5:23 PM, Thoka  wrote:
>
>> We've been building GWT application for about 3 years now, and we've
>> reached the point where compiling the internationalization strings
>> into the WAR file is no longer servicable. Today the GWT I18N support
>> is primarly based on Constants and Messages which is solely built on
>> Java property files.
>>
>> How ever, we've solved this issue by putting the internationalization
>> settings on the server side and by fetching these strings remotely via
>> JavaScript documents. This works perfect, as we now are able to (even
>> in live environment) change internationalization files without re-
>> compiling the entire project and without even restarting the tomcat
>> service.
>>
>
> Realize the big cost you are paying:
>
> @DefaultMessage("You have {0,number,#,##0}
> items totaling {0,number,currency}")
> @PluralText({"one", "You have 1 item costing {0,number,currency}"})
> String getCartTotal(@PluralCount int items, double total);
>
> Gets converted into essentially the following:
>
> String getCartTotal(int items, double total) {
>   switch (DefaultRule.select(items)) {
>  case 1: return "You have 1 item totaling "
> + NumberFormat.getCurrencyFormat().format(total);
>  default:  return "You have " +
> NumberFormat.getFormat("#,##0").format(items)
> + " items totalling " +
> NumberFormat.getCurrencyFormat().format(total);
>}
> }
>
> And things get inlined/optimized from there.  If you were to fetch the
> format strings from the server at runtime, you would have to include code to
> parse the format string in the runtime as well.  That code gets large --
> which is why String.format isn't currently included in GWT's JRE emulation.
>  If you wanted to allow the server strings to have plural support, then you
> even have to add extra work in the client and download multiple format
> strings for each message.
>
> Having to deploy a new compiled application when you make changes to
> translations doesn't seem a large cost compared to the huge savings by doing
> more work at compile time rather than at runtime.
>
> Much of the work on GWT is to be able to do more things at compile time
> rather than runtime and this is a good example.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> >
>

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

[gwt-contrib] Re: will deRPC ship with GWT 2.0 ?

[Bruce Johnson]

Love the enthusiasm!
Anyone else?

On Mon, Oct 19, 2009 at 4:26 PM, Sami Jaber  wrote:

> IMHO, It would be a mistake not to make it happen for GWT 2
>
> deRPC is a huge step forward in terms of performance, extensibility,
> command sinking, serialization extensibility, security and so forth
> Everybody know that GWT 2 will introduce new API and many new
> functionalities, why deRPC would not be part of the show?
> Because it has not been intensively tested ? There's probably a lack of
> tests cases, sure, but it is not specific to deRPC. When I see the last
> commit streams, deRPC seems to me more reliable than other APIs. And
> regarding the migration path and the different use case scenarios, this is
> sweet. If you want to stay in legacy land, just use the straight
> RemoteServiceServlet class. If you want to support the two modes, just
> inherits from HybridServiceServlet (as JUnitHostImpl does in the trunk right
> now). If you are a newcomer, forget all the old non-extensible interfaces
> and use RpcServlet and RpcService.
>
> Releasing deRPC does not mean that you won't be able to patch if later.
> Earlier it will be released, earlier you will get feedback. Please think
> about it.
>
> My 2 french euros,
>
> Sami
>
>
>
> On Mon, Oct 19, 2009 at 9:49 PM, Bruce Johnson  wrote:
>
>> So, here's the deal on deRPC. It doesn't yet have the miles on it that
>> we'd like, so we're pretty much on the fence as to whether to really ship it
>> in GWT 2.0 or not.
>> It has been included in MS1 and will be in MS2, but we may still make a
>> "no go" decision before the GWT 2.0 RC comes out.
>>
>> If you (as in, anyone reading this email) have tried the new RPC stuff and
>> have feedback, now would be the right time to give it a thumbs up or thumbs
>> down. At the moment, we're leaning thumbs down -- mainly to be conservative.
>>
>> -- Bruce
>>
>> On Mon, Oct 19, 2009 at 3:45 PM, Sami Jaber  wrote:
>>
>>> Following a question I asked privately to Bruce and Amit.
>>> Thanks for your response gwitters
>>>
>>> Sami
>>>
>>> On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson  wrote:
>>>
>>>> Sami, would you mind asking this question directly on the Contributors
>>>> list? We can answer it so that everyone has a chance to comment.
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>>> On Sat, Oct 17, 2009 at 1:46 AM, Sami Jaber wrote:
>>>>>>
>>>>>>> Bruce,
>>>>>>>
>>>>>>> What is the status of deRPC API in GWT 2. The code is in the trunk,
>>>>>>> it seems to be work very well (at least with my test cases) but nothing 
>>>>>>> in
>>>>>>> GWT MS1 Amit announce and very few gwtc posts regarding the API/issue.
>>>>>>> Are you planning to ship deRPC with GWT 2 (I would love to regarding
>>>>>>> all the JDO/AppEngine integration) ? Similarly, are you planning to 
>>>>>>> update
>>>>>>> GPE to conform to the new interfaces, RpcService, RpcServlet, etc ... (
>>>>>>> http://code.google.com/eclipse/docs/gwt_rpc.html) ?
>>>>>>>
>>>>>>> Thanks for you response,
>>>>>>>
>>>>>>> Sami
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>

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

[gwt-contrib] Re: will deRPC ship with GWT 2.0 ?

[Bruce Johnson]

So, here's the deal on deRPC. It doesn't yet have the miles on it that we'd
like, so we're pretty much on the fence as to whether to really ship it in
GWT 2.0 or not.
It has been included in MS1 and will be in MS2, but we may still make a "no
go" decision before the GWT 2.0 RC comes out.

If you (as in, anyone reading this email) have tried the new RPC stuff and
have feedback, now would be the right time to give it a thumbs up or thumbs
down. At the moment, we're leaning thumbs down -- mainly to be conservative.

-- Bruce

On Mon, Oct 19, 2009 at 3:45 PM, Sami Jaber  wrote:

> Following a question I asked privately to Bruce and Amit.
> Thanks for your response gwitters
>
> Sami
>
> On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson  wrote:
>
>> Sami, would you mind asking this question directly on the Contributors
>> list? We can answer it so that everyone has a chance to comment.
>> Thanks.
>>
>>
>>
>>>> On Sat, Oct 17, 2009 at 1:46 AM, Sami Jaber wrote:
>>>>
>>>>> Bruce,
>>>>>
>>>>> What is the status of deRPC API in GWT 2. The code is in the trunk, it
>>>>> seems to be work very well (at least with my test cases) but nothing in 
>>>>> GWT
>>>>> MS1 Amit announce and very few gwtc posts regarding the API/issue.
>>>>> Are you planning to ship deRPC with GWT 2 (I would love to regarding
>>>>> all the JDO/AppEngine integration) ? Similarly, are you planning to update
>>>>> GPE to conform to the new interfaces, RpcService, RpcServlet, etc ... (
>>>>> http://code.google.com/eclipse/docs/gwt_rpc.html) ?
>>>>>
>>>>> Thanks for you response,
>>>>>
>>>>> Sami
>>>>>
>>>>>
>>>>
>>
>

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

[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases

[Bruce Johnson]

@John L: You taking this one?

On Wed, Oct 14, 2009 at 12:08 PM, Pascal Muetschard
wrote:

> I've uploaded another patch set, which merges in the latest changes from
> the trunk.
>
>
> On Mon, Oct 12, 2009 at 2:34 AM, John Tamplin  wrote:
>
>> On Mon, Oct 12, 2009 at 12:03 AM, John LaBanca wrote:
>>
>>> @jat -
>>> When do you think we'll merge the htmlunit branch into trunk so we can
>>> check in this patch?
>>>
>>
>> We are supposed to ship MS2 on Wednesday, so it has to be real soon.
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>
>
>

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

[gwt-contrib] Re: RR : Add lightweight Scheduler API

[bruce]

Assuming you've tested the RESCUE SSW behavior and that Joel likes it,
this LGTM.

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

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

[gwt-contrib] Re: RR : Make StyleInjector use Scheduler.scheduleFinally() API

[bruce]

LGTM with a typo fix. An idea for an incredibly trivial improvement if
you just want to change something more for the heck of it.


http://gwt-code-reviews.appspot.com/78816/diff/1/2
File user/src/com/google/gwt/dom/client/StyleInjector.java (right):

http://gwt-code-reviews.appspot.com/78816/diff/1/2#newcode341
Line 341: * The with parameter is used to support the
deprecated API.
with => which

http://gwt-code-reviews.appspot.com/78816/diff/1/4
File user/test/com/google/gwt/dom/client/StyleInjectorTest.java (right):

http://gwt-code-reviews.appspot.com/78816/diff/1/4#newcode136
Line 136: delayTestFinish(500);
(Ignore if you please) The '500' here seems like it wants to be a
symbolic constants, along with the other bare '500's elsewhere in the
file.

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

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

[gwt-contrib] Re: RR : Add lightweight Scheduler API

[bruce]

Overall, very nice. The key, though ultimately superficial, design
question is whether to make the main methods non-static. See the comment
in Scheduler.java for details.

There are a couple of other minor points.

N.B. I didn't really scrutinize it for logical correctness, although the
basic implementation approach makes sense. Nice use of overlays.

Needs some tests soon after commit if not before.


http://gwt-code-reviews.appspot.com/77820/diff/1004/1005
File user/src/com/google/gwt/core/client/Scheduler.java (right):

http://gwt-code-reviews.appspot.com/77820/diff/1004/1005#newcode23
Line 23: public class Scheduler {
Let's get Ray Ryan's opinion on this, but isn't The Right Thing To Do
here to make the methods non-static and instead provide Scheduler.get().
That would leave the option open to make it injectible and mockable,
which I could imagine being potentially useful in some testing
situations.

http://gwt-code-reviews.appspot.com/77820/diff/1004/1005#newcode123
Line 123: public static void schedulePause() {
I'm inclined to leave this out. It's such a nice, clean API right now,
and the value of this isn't proven. I know I argued that it had a reason
to exist -- and it doesn in principle -- but why not let's rip it out
for v1 and add it in the future if there is ever demand. The main reason
I feel squirely about it is that it isn't clear which queue is getting
the "pause". Sure, it's clear if you already grok the system, but it's a
little hard to reason about otherwise.

http://gwt-code-reviews.appspot.com/77820/diff/1004/1007
File user/src/com/google/gwt/core/client/impl/SchedulerImpl.java
(right):

http://gwt-code-reviews.appspot.com/77820/diff/1004/1007#newcode110
Line 110: * This is a sentinel object used to reschedule any following
DeferredCommands
DeferredCommands => deferred commands

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

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

[gwt-contrib] Re: RR : GWT 2.0: Initial thoughts on $entry

[Bruce Johnson]

LGTM

On 10/12/09, b...@google.com  wrote:
> Hi Scott and Bruce,
>
> @Bruce, can I get feedback on the "API" that $entry() provides.
>
> @Scott, this changset just has the changes to the compiler and hosted
> mode, can you review them?
>
> http://gwt-code-reviews.appspot.com/77810
>

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

[gwt-contrib] Re: -soyc runs the dashboard, too

[Bruce Johnson]

On Mon, Sep 28, 2009 at 1:39 PM,  wrote:
>
> I'll rename everything to "compile report".  The command-line option
> would also be good to update, but I don't have any ideas about what to
> change it to at the moment.
>

Maybe -soyc => -compileReport or maybe just -report?

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

[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases

[Bruce Johnson]

I dig @WithProperties to the max.

On Fri, Sep 25, 2009 at 2:16 PM, Pascal Muetschard
wrote:

> How about @WithProperties or @WithModuleProperty? Since the module XML
> files use , , ,
> and .
>
> On Fri, Sep 25, 2009 at 11:01 AM, John LaBanca wrote:
>
>> @WithClientProperties is fine with me.  I thought we used the term binding
>> somewhere, but creating a DeferredBinding doesn't actual require the use of
>> the term binding.  The gwt.xml files just refer to these as properties.
>>
>> Thanks,
>> John LaBanca
>> jlaba...@google.com
>>
>>
>> On Fri, Sep 25, 2009 at 1:57 PM, Bruce Johnson  wrote:
>>
>>> On Fri, Sep 25, 2009 at 1:51 PM, John LaBanca wrote:
>>>
>>>> I vote for @WithBindingProperties for the annotation name.
>>>
>>>
>>> Is that a vote that we should start using the term "binding properties"
>>> in general?
>>>
>>> I think that's not quite the right term (perhaps this should be a
>>> separate thread) because increasingly, those properties will affect things
>>> like compiler optimization behavior, code splitting, etc. That is, they
>>> don't only affect how GWT.create() calls get bound.
>>>
>>> How about the term "client property"? It is a property that affects what
>>> the client receives and is in every case somehow a function of the client
>>> that is requesting the script.
>>>
>>> -- Bruce
>>>
>>> >>>
>>>
>

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

[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases

[Bruce Johnson]

On Fri, Sep 25, 2009 at 1:51 PM, John LaBanca  wrote:

> I vote for @WithBindingProperties for the annotation name.


Is that a vote that we should start using the term "binding properties" in
general?

I think that's not quite the right term (perhaps this should be a separate
thread) because increasingly, those properties will affect things like
compiler optimization behavior, code splitting, etc. That is, they don't
only affect how GWT.create() calls get bound.

How about the term "client property"? It is a property that affects what the
client receives and is in every case somehow a function of the client that
is requesting the script.

-- Bruce

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

[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases

[Bruce Johnson]

On Fri, Sep 25, 2009 at 1:19 PM, Pascal Muetschard
wrote:

> 1) What happens if the module returned by getModuleName() already specifies
> a fix value for a given property? More generally, how should one think about
> how these annotations dovetail with the settings in the module config?
>
> The annotation will override what is defined in the module. I think that's
> what is expected and "it just works".
>

Makes sense. Normally, when you  you can specify multiple
values (which often generates multiple permutations, though not always).
Seems like the annotation should support that if it doesn't.

2) The terminology is different than we've used in the past. Granted, we
>> haven't been very consistent with the term for "deferred binding properties"
>> (e.g. we've also called them "client properties"), but we've never called
>> them "module parameters". I know that doesn't make for a nice annotation
>> name, but I do want to avoid introducing yet another name for the same
>> concept.
>>
>
> Good point. I will do the rename and publish another patch.
>

Sadly, I'm not positive what the right name should be. Perhaps
@WithClientProperties?

I'd like to hear from others as to the best term.
@WithDeferredBindingProperties seems too weighty.


>  3) Would these annotations apply to the benchmarking subsystem? Should
> they? Could they?
>
> Yes it could. The simplest way would be to change the benchmark
> JUnitShell.Strategy to extend the new strategy. I don't know the benchmark
> system well, so I didn't want to change it. If somebody that does know the
> benchmark system well could look at this, I'd be more than happy to help...
>

I'd really like to look into this at the same time. It's always so much
harder to find time to go back and retrofit these kinds of enhancements than
to just add them uniformly when they first go in.

@John L: Thoughts? Could you point Pascal in the right direction w.r.t.
benchmarking?

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

[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases

[Bruce Johnson]

Looks convenient, but I have a few questions/comments.

1) What happens if the module returned by getModuleName() already specifies
a fix value for a given property? More generally, how should one think about
how these annotations dovetail with the settings in the module config?

2) The terminology is different than we've used in the past. Granted, we
haven't been very consistent with the term for "deferred binding properties"
(e.g. we've also called them "client properties"), but we've never called
them "module parameters". I know that doesn't make for a nice annotation
name, but I do want to avoid introducing yet another name for the same
concept.

3) Would these annotations apply to the benchmarking subsystem? Should they?
Could they?

On Fri, Sep 25, 2009 at 12:09 PM, John LaBanca  wrote:

> Patch courtesy of pmuetschard.
>
> We propose adding the annotation @WithModuleParameters to specify  deferred
> binding properties on specific test methods, as per this patch:
> http://gwt-code-reviews.appspot.com/71801/show
>
> For a specific example, see the test file in the patch:
> http://gwt-code-reviews.appspot.com/71801/patch/45/49
>
> This patch is pretty cool, but there are a couple of important items to
> consider:
> 1. Using these annotations increases the number of compilations.  In the
> example above, the single test class would require two compilations (one for
> each test case).  If the test case had a third, non-annotated method, the
> number of compilations would be three.  This is a natural side effect that
> would be true even if the user creates a separate test case with a separate
> test module for each parameter combination.
>
> 2. As the patch stands now, @WithModuleParameters is NOT inherited, so if a
> subclass overrides a test method, the annotations will not apply.   I
> suggest we add t...@inherited tag to the definition so that overriding
> subclasses do inherit the annotation.
>
> Thanks,
> John LaBanca
> jlaba...@google.com
>
> >
>

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

[gwt-contrib] Re: Testing new GWT RPC implementation (aka deRPC)

[Bruce Johnson]

Bob went off and got married, so he won't be back until next week (I think).

On Thu, Sep 17, 2009 at 8:21 AM, futzi  wrote:

>
> Hi Bob,
>
> during my RPCServlet - tests I found another issuer with the
> serialization and dezerialization of certain objects. When trying to
> send the attached object to the client, the rpc-mechanism leads to
> some kind of endless loop and ends with the following exception.
>
>  [java] java.lang.reflect.InvocationTargetException
> [java] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown
> Source)
> [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (Unknown Source)
> [java] at java.lang.reflect.Method.invoke(Unknown Source)
> [java] at
>
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.serializeWithCustomSerializer
> (CommandServerSerializationStreamWriter.java:213)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:146)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:179)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:179)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
>
> com.google.gwt.rpc.client.impl.CommandSerializationStreamWriterBase.writeObject
> (CommandSerializationStreamWriterBase.java:64)
> [java] at
>
> com.google.gwt.user.client.rpc.core.java.util.Collection_CustomFieldSerializerBase.serialize
> (Collection_CustomFieldSerializerBase.java:44)
> [java] at
>
> com.google.gwt.user.client.rpc.core.java.util.ArrayList_CustomFieldSerializer.serialize
> (ArrayList_CustomFieldSerializer.java:36)
> [java] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown
> Source)
> [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (Unknown Source)
> [java] at java.lang.reflect.Method.invoke(Unknown Source)
> [java] at
>
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.serializeWithCustomSerializer
> (CommandServerSerializationStreamWriter.java:213)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:146)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:179)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:179)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
>
> com.google.gwt.rpc.client.impl.CommandSerializationStreamWriterBase.writeObject
> (CommandSerializationStreamWriterBase.java:64)
> [java] at
>
> com.google.gwt.user.client.rpc.core.java.util.Collection_CustomFieldSerializerBase.serialize
> (Collection_CustomFieldSerializerBase.java:44)
> [java] at
>
> com.google.gwt.user.client.rpc.core.java.util.ArrayList_CustomFieldSerializer.serialize
> (ArrayList_CustomFieldSerializer.java:36)
> [java] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown
> Source)
> [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (Unknown Source)
> [java] at java.lang.reflect.Method.invoke(Unknown Source)
> [java] at
>
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.serializeWithCustomSerializer
> (CommandServerSerializationStreamWriter.java:213)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:146)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializationStreamWriter.java:92)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeObject
> (CommandServerSerializationStreamWriter.java:179)
> [java] at
> com.google.gwt.rpc.server.CommandServerSerializationStreamWriter.makeValue
> (CommandServerSerializat

[gwt-contrib] Re: GWT Incubator compatibility policy

[Bruce Johnson]

Brett's analysis nails it. And I agree with you Fred, that it's a "good
fail."

It really boils down to finding an arrangement that fits naturally with the
team's and community's work habits. It's too easy for the core GWT team to
ignore "that other project" when we work on GWT trunk every day, yet the
existence of the incubator might actively discourage autonomous community
projects from springing up as separate Google Code projects (because
would-be project founders feel they ought to instead work in the context of
the incubator).

Anyway, nothing drastic comes of any of this. And we still badly need a
paging data grid (that is really fast, small, and scalable) to land in
trunk!

On Wed, Sep 16, 2009 at 1:03 AM, Fred Sauer  wrote:

>
>
> On Tue, Sep 15, 2009 at 6:23 AM, brett.wooldridge <
> brett.wooldri...@gmail.com> wrote:
>
>>
>> I'll throw in my 2￥.  I see two things as untenable:
>>
>> 1. One incubator project with a bunch of widgets.  I know it's
>> convenient to have one project to build to get all the cool bits, but
>> the reality is that each of those bits has a different maintainer with
>> different levels of commitment (and time) to getting it current with
>> the trunk.
>>
>>
> I think this has be the reality of the current incubator.
>
> Overall I'm quite happy with the incubator. It was a great experiment which
> had some great code come of it. Even if we declare this experiment 'failed'
> I still consider it a success in that it's helped us to an even better path.
>
> Thanks
> Fred
>
>
>
>
>
>> 2. Committing to support plural versions of GWT with a non-branched
>> incubator.  If the incubator branches with the gwt trunk, users can
>> have some assurances that everything will work for a given version of
>> GWT -- save defects in said projects.
>>
>> I'm actually for giving the whack-a-mole process a go, with projects
>> living (independently) until they are merged or die a natural death.
>> Once merged, the project should be deleted or otherwise marked as
>> stopped.  Truly abandoned projects will either be adopted by someone
>> who cares, or will suffer bitrot.  Either way, there would be no
>> commitment to keep them current.
>>
>> Maybe with the lessened guarantees, fewer people will choose to employ
>> such projects, but my gut says that when you need a PagingScrollTable
>> you'll take one where you can get it.
>>
>> -Brett
>>
>> On Sep 15, 11:26 am, Isaac Truett  wrote:
>> > Bruce,
>> >
>> > I pondered this topic over the weekend. I don't think I have enough
>> > information right now to arrive at a better solution. I honestly
>> > thought until Wednesday that the incubator was working well. I
>> > understand that things look different from the inside.
>> >
>> > Ray said last week that the new direction was going to be developing
>> > widgets in GWT trunk or in separate projects. I assume that means
>> > there will be throw-away projects for new widgets or groups of widgets
>> > that will last until the code is incorporated into GWT trunk. On the
>> > pro side, that would mean you're not bound to long term backwards
>> > compatibility or supporting the dead-ends that hang around in the
>> > incubator but are still used by a few people. But if the pace of new
>> > development is fast enough, I could see it turning into a game of
>> > whack-a-mole with new projects popping up and disappearing rapidly. I
>> > think one of the advantages of having a single incubator project is
>> > that users can build one project and get access to all of those
>> > experimental widgets at once.
>> >
>> > On a side note, a couple of other people have discovered the
>> > StyleInjector change:
>> >
>> >
>> http://code.google.com/p/google-web-toolkit-incubator/issues/detail?i...http://code.google.com/p/google-web-toolkit-incubator/wiki/MakingIncu.
>> ..
>> >
>> > I'm not sure what to tell them at this point. I think at the very
>> > least the wiki needs to be clarified.
>> >
>> > - Isaac
>> >
>> >
>> >
>> > On Fri, Sep 11, 2009 at 5:28 PM, Bruce Johnson 
>> wrote:
>> > > We've been a little ambivalent about how well the incubator is working
>> --
>> > > it's taken a lot longer to things to move into trunk than we ever
>> guessed it
>> > > would, usually for pretty good reasons. So, we need to find a
>> differe

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[Bruce Johnson]

And those class names get obfuscated, too, right?

On Fri, Sep 11, 2009 at 6:24 PM, Ray Ryan  wrote:

> Want to see the best part? Css namespaces for free, courtesy of
> CssResource.
> 
>   
> .pretty {
>   color: red;
> }
>   
>   
> .pretty {
>   color: green;
> }
>   
>
>   
> I am red.
> I am green.
>   
> 
>
>
> On Fri, Sep 11, 2009 at 2:23 PM, Bruce Johnson  wrote:
>
>> Another w00t!
>> This is brilliant.
>>
>>
>> On Thu, Sep 10, 2009 at 7:00 PM, Joel Webber  wrote:
>>
>>> W00t, thanks. Looking forward to using this.Thanks for doing this
>>> review, Lex.
>>>
>>>
>>> On Thu, Sep 10, 2009 at 4:36 PM,  wrote:
>>>
>>>>
>>>> On 2009/09/10 19:54:05, Ray Ryan wrote:
>>>>
>>>>
>>>> Committed r6114
>>>>
>>>> http://gwt-code-reviews.appspot.com/64812
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: GWT Incubator compatibility policy

[Bruce Johnson]

We've been a little ambivalent about how well the incubator is working --
it's taken a lot longer to things to move into trunk than we ever guessed it
would, usually for pretty good reasons. So, we need to find a different way
of building up a pipeline, and that's a somewhat unsolved problem as yet. If
anyone has ideas, let 'em rip.

On Thu, Sep 10, 2009 at 2:21 PM, Ray Ryan  wrote:

> If you're after guarantees I guess that would be 1686, the one that the
> 1.7 jar was cut from (gwt-incubator-july-14-2009.jar). Looking at the svn
> history, nothing has actually changed in the code from that one to the
> removal of StyleInjector. It's all wiki edits and such since then.
>
>
> On Thu, Sep 10, 2009 at 8:46 AM, jay  wrote:
>
>>
>> So...as of right now, what is the *last* version of gwt-incubator that
>> is guaranteed to work with GWT 1.7? Is it safe to assume that it is
>> the version immediately prior to the removal of StyleInjector?
>>
>> thanks,
>>
>> jay
>>
>> On Sep 10, 8:28 am, Isaac Truett  wrote:
>> > [oops - +gwtc]
>> >
>> > Hi, Ray,
>> >
>> > I appreciate the drive to move forward and I applaud jumping on
>> > opportunities to remove redundant code.
>> >
>> > The reason this policy was important, to me at least, is that it
>> > provided a baseline to work against. The code in the incubator can be
>> > very useful (I use PagingScrollTable extensively and used DatePicker
>> > from incubator before it graduated) but it's also risky because the
>> > code is still experimental and subject to change. The assurance that
>> > those changes would be compatible with a packaged and released GWT
>> > build (even just a milestone) meant that I could build incubator from
>> > trunk and pick up the latest features and bugfixes as long as my
>> > project tracked the latest GWT build. Because of the GWT policies on
>> > deprecation and backwards compatibility, this has been fairly easy in
>> > practice. As it stands now, incubator will not compile except against
>> > GWT trunk, which is also notoriously unstable (it wasn't building as
>> > recently as last night, which I see was corrected this morning). This
>> > presents a much higher risk for those of us using incubator code.
>> >
>> > It also becomes harder to work on the incubator itself when it has to
>> > compile against GWT trunk. I wanted to look into issue #267 last night
>> > and I was stymied by GWT trunk not being in a buildable state. Not an
>> > insurmountable obstacle, but one that seems unnecessary to me.
>> >
>> > - Isaac
>> >
>> >
>> >
>> > On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan  wrote:
>> > > Hey, Isaac.
>> > > That policy has proven very difficult to live with. (And to tell you
>> the
>> > > truth I forgot about it.)
>> > > The reasoning here was that we have released incubator jars that work
>> with
>> > > 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it
>> prove
>> > > necessary to go back and do so we can go back and branch.
>> > > In the meantime, we were faced bugs due to FastTree in particular
>> being tied
>> > > to the old StyleInjector while new development was moving to the
>> version in
>> > > GWT.  We saw the opportunity to delete redundant code and took it.
>> > > Is this going to cause problems for anyone?
>> > > rjrjr
>> >
>> > > On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett 
>> wrote:
>> >
>> > >> Last year, Emily stated that it would compile against the "latest
>> > >> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that
>> > >> I've seen, so under the policy from last year StyleInjector should
>> not
>> > >> have been removed in revisions 1712-1715.
>> >
>> > >> So, what's the current policy for incubator trunk compatibility?
>>
>>
>
> >
>

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

[gwt-contrib] Re: Introduces inline styles to ui.xml files

[Bruce Johnson]

Another w00t!
This is brilliant.

On Thu, Sep 10, 2009 at 7:00 PM, Joel Webber  wrote:

> W00t, thanks. Looking forward to using this.Thanks for doing this review,
> Lex.
>
>
> On Thu, Sep 10, 2009 at 4:36 PM,  wrote:
>
>>
>> On 2009/09/10 19:54:05, Ray Ryan wrote:
>>
>>
>> Committed r6114
>>
>> http://gwt-code-reviews.appspot.com/64812
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: Initial implementations of Stack and Split layout panels, along with a few checkstyle tweaks.

[Bruce Johnson]

yay

On Thu, Sep 10, 2009 at 8:48 AM,  wrote:

>
> On 2009/09/04 22:37:44, Ray Ryan wrote:
> > LGTM
>
> Committed @r6110.
>
> http://gwt-code-reviews.appspot.com/65804
>
> >
>

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

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

[Bruce Johnson]

I'm definitely not a Java pedant, so maybe there's something
wrong/underinformed with my perspective here, but here's my take...
1) Why Runnable isn't quite right
- Has close associations with threads
- Isn't spec'd to throw Throwable, which means what could be simple callbaks
have to always have try/catch that then invoke exactly the same code path
that the uncaught exception handler would've called anyway.

2) Callable is closer, but it has a close association with the Executor
family, which itself has lots of connotations, most of which we can't honor.

3) I see the spritual similarity to ExecutorService/Future, but I don't see
that there's any proper subset we could implement that would cover the same
use cases. Even if we could, the standard Java for that subset could be
misleading relative to the semantics we are trying to guarantee -- that is,
we'd like to say stuff like "runs at the next opporuntity after the event
loop has been processed at least once" in the GWT javadoc, otherwise it
comes across as way too abstract.

Perhaps an approach would be to try to perfect the API without trying to
reconcile it, then see if we can map it onto the existing JRE without losing
anything vital.


On Thu, Sep 3, 2009 at 11:21 PM, Ray Cromwell  wrote:

>
> Is there a reason why we just don't add Runnable and Callable to the JRE
> emul and use those instead of Command? This design seems to parallel some of
> the patterns in ExecutorService. I could see some of those patterns being
> useful (like completion queues, which would be useful for staged
> animations).
> -Ray
>
>
> On Thu, Sep 3, 2009 at 7:08 PM, Bruce Johnson  wrote:
>
>> Okay, here's a strawman for a new-and-improved proposal. All these would
>> be in core.
>> // "Deferred command" = on the other side of the event loop
>> interface DeferredCommands {
>>   public static DeferredCommands get();
>>
>>   public void add(Command cmd);
>>   public void add(Command cmd, boolean asap);  // asap = faster than
>> setTimeout(0)
>>   public void addPause();
>> }
>>
>> // "Finally command" = before you end the current stack trace
>> interface FinallyCommands {
>>   public static FinallyCommands get();
>>
>>   public void add(Command cmd);
>> }
>>
>> // "Incremental command" = call repeatedly quickly to avoid SSWs
>> interface IncrementalCommands {
>>   public static IncrementalCommands get();
>>
>>   public void add(Command cmd);
>>   public void add(Command cmd, boolean asap);
>> }
>>
>> // "Timed command" = call based clock time (aka regular old timers)
>> interface TimedCommands {
>>   public static TimedCommand get();
>>
>>   public TimerController scheduleOnce(Command cmd, int millis);
>>   public TimerController scheduleRecurring(Command cmd, int millis);
>> }
>>
>> // Allows optional control over a timer after it's created.
>> // If the return values in scheduleOnce, etc. aren't used, extra code can
>> maybe optimize away.
>> interface TimerController {
>>   public void pause();
>>   public void resume();
>>   public void cancel();
>> }
>>
>> I think that maybe consolidating timers into this mix might be a bit much,
>> but, then again, if we're graduating "Command" to core, then it seems like
>> it would be nice to make it the uniform callback interface.
>>
>> -- Bruce
>>
>> On Thu, Sep 3, 2009 at 9:28 PM, Bruce Johnson  wrote:
>>
>>> I like it a lot Ray. (To be completely honest, I knew you were going to
>>> say all that, so I decided to sandbag and let you do the typing :-)
>>>
>>> I question if it's really appropriate to explicitly say "PreEventLoop"
>>> and "PostEventLoop" considering that...sometimes...the event loop can
>>> actually run re-entrantly. Those names sound like a very strong guarantee
>>> that I don't think we can reliably guarantee. It's more like
>>> "PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
>>>
>>> Actually, to take a step back (which is my very favorite thing to do),
>>> there are several kinds of things that could be consolidated:
>>>
>>> 1) Single-shot timers
>>> 2) Recurring timers
>>> 3) Incremental commands that run as soon as possible after the event loop
>>> (faster than setTimeout(0))
>>> 4) Incremental commands that run after the event loop via setTimeout(0)
>>> 5) Deferred commands that run as soon as possible after 

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

[Bruce Johnson]

Okay, here's a strawman for a new-and-improved proposal. All these would be
in core.
// "Deferred command" = on the other side of the event loop
interface DeferredCommands {
  public static DeferredCommands get();

  public void add(Command cmd);
  public void add(Command cmd, boolean asap);  // asap = faster than
setTimeout(0)
  public void addPause();
}

// "Finally command" = before you end the current stack trace
interface FinallyCommands {
  public static FinallyCommands get();

  public void add(Command cmd);
}

// "Incremental command" = call repeatedly quickly to avoid SSWs
interface IncrementalCommands {
  public static IncrementalCommands get();

  public void add(Command cmd);
  public void add(Command cmd, boolean asap);
}

// "Timed command" = call based clock time (aka regular old timers)
interface TimedCommands {
  public static TimedCommand get();

  public TimerController scheduleOnce(Command cmd, int millis);
  public TimerController scheduleRecurring(Command cmd, int millis);
}

// Allows optional control over a timer after it's created.
// If the return values in scheduleOnce, etc. aren't used, extra code can
maybe optimize away.
interface TimerController {
  public void pause();
  public void resume();
  public void cancel();
}

I think that maybe consolidating timers into this mix might be a bit much,
but, then again, if we're graduating "Command" to core, then it seems like
it would be nice to make it the uniform callback interface.

-- Bruce

On Thu, Sep 3, 2009 at 9:28 PM, Bruce Johnson  wrote:

> I like it a lot Ray. (To be completely honest, I knew you were going to say
> all that, so I decided to sandbag and let you do the typing :-)
>
> I question if it's really appropriate to explicitly say "PreEventLoop" and
> "PostEventLoop" considering that...sometimes...the event loop can actually
> run re-entrantly. Those names sound like a very strong guarantee that I
> don't think we can reliably guarantee. It's more like
> "PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
>
> Actually, to take a step back (which is my very favorite thing to do),
> there are several kinds of things that could be consolidated:
>
> 1) Single-shot timers
> 2) Recurring timers
> 3) Incremental commands that run as soon as possible after the event loop
> (faster than setTimeout(0))
> 4) Incremental commands that run after the event loop via setTimeout(0)
> 5) Deferred commands that run as soon as possible after the event loop
> (faster than setTimeout(0))
> 6) Deferred commands that run after the event loop via setTimeout(0)
> 7) Execute-this-before-you-unwind-the-JS-stack-in-which-it-was-enqueued
> (aka BatchedCommand)
> 8) Arguably, runAsync (although it's purpose is so functionally different
> it would probalby be a mistake to munge it in)
>
> #3 and #5 might look funny, but it is generally possible to run code
> *after* the event loop but *much* sooner than setTimeout(0), which is
> usually clamped to some pretty long duration such as 10ms. The reason you
> wouldn't want to do #3 and #5 as the default for deferred commands is that
> it would keep the CPU overly busy if you did it a bunch in a row. It would
> very likely drain mobile batteries quickly, even.
>
> @Ray (or anyone): Can you think of an awesome way to reconcile those behind
> a consistent API?
>
>
>
>
>
>
>
> On Thu, Sep 3, 2009 at 4:52 PM, Joel Webber  wrote:
>
>> ++(++Ray)
>> Anything we can do to sensibly get this crap out of .user and into .core
>> (or some other common location) would be very, very good.
>> If, as a side-effect, we could get DeferredCommand to *not* use
>> IncrementalCommand (the latter brings in fairly significant dependencies
>> that are enough to matter for small apps), that would be even better.
>>
>>
>> On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum  wrote:
>>
>>> ++Ray.
>>>
>>>
>>> On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan  wrote:
>>>
>>>>   The mechanism is just brilliant. I have reservations about the api.
>>>>
>>>> 
>>>> "it seemed kinda nice to have one less type"
>>>>
>>>> Except that we have one more type, BatchedCommand, which looks exactly
>>>> like Command, except with a different name, and you have to subclass it
>>>> rather than implement it...
>>>>
>>>> A simple thing we could do is:
>>>>
>>>>- create com.google.gwt.core.client,
>>>>- change com.google.gwt.user.client.Command to extend the new one
>>>>- deprecate com.google.gwt.user.clien

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

[Bruce Johnson]

le Widgets performing updates? e.g. a current approach to avoid the
>>>> overhead, of say, installing a dozen widgets, is to concatenate all the 
>>>> HTML
>>>> together, slam it into innerHTML, and then wrap the widgets around the 
>>>> HTML.
>>>> But this rather breaks the nice OO design people are used to with widgets.
>>>> Templating is an alternative, but I'm wondering, why can't we make all of
>>>> the attachment stuff happen via a batch queue. A special optimizer on the
>>>> queue could even recognize instances of when DOM updates can be coalesced
>>>> and leverage documentFragment or innerHTML.
>>>> e.g.
>>>>
>>>> VerticalPanel vp = ...
>>>> vp.add(new Label())
>>>> vp.add(new Label())
>>>>
>>>> The objects are constructed, but the HTML mutations are deferred/queued.
>>>> When adding a DOM mutation to the queue, you could check if existing queue
>>>> data isOrHasChild the new DOM mutation element, and if so, just modify the
>>>> queue element (coalesce) rather than appending another queue item. Then,
>>>> when processing the queue, you only need to add the roots to the DOM,
>>>> attaching/modifying enmasse.
>>>>
>>>> This would preserve the OO-ness of constructing widget hierarchies
>>>> without requiring 'foreign' string-based templating.
>>>>
>>>> -Ray
>>>>
>>>>
>>>>  On Wed, Sep 2, 2009 at 5:13 PM, Bruce Johnson wrote:
>>>>
>>>>>  On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum  wrote:
>>>>>
>>>>>> I do agree with John that we should really discuss how this can be
>>>>>> implemented.
>>>>>
>>>>>
>>>>> It's already implemented!
>>>>>
>>>>>
>>>>>>  Is there some magic trick to make the browser execute a piece of code
>>>>>> at the time you want, or do we need to go and modify all our event code
>>>>>> (like with the global uncaught exception handler)?
>>>>>
>>>>>
>>>>> No trick, it's as bad as you'd hope it wasn't. On the positive side,
>>>>> it's already been done -- I'm just augmenting the tests for the various
>>>>> subsystems such as RequestBuilder and event dispatching to make sure we
>>>>> tighten the correctness noose as much as possible.
>>>>>
>>>>> Longer term, Bob and I both would really like to find a general
>>>>> mechanism for making this pattern easy to do from any path into a GWT 
>>>>> module
>>>>> from "the outside", exactly along the lines of what Matt was talking 
>>>>> about.
>>>>> I think rolling this functionality into gwt-exporter (and then rolling 
>>>>> that
>>>>> sort of functionality directly into GWT proper) will get us pretty far 
>>>>> down
>>>>> the road.
>>>>>
>>>>> Code review request forthcoming, possibly tomorrow.
>>>>>
>>>>> -- Bruce
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

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

[Bruce Johnson]

On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum  wrote:

> I do agree with John that we should really discuss how this can be
> implemented.


It's already implemented!


>  Is there some magic trick to make the browser execute a piece of code at
> the time you want, or do we need to go and modify all our event code (like
> with the global uncaught exception handler)?


No trick, it's as bad as you'd hope it wasn't. On the positive side, it's
already been done -- I'm just augmenting the tests for the various
subsystems such as RequestBuilder and event dispatching to make sure we
tighten the correctness noose as much as possible.

Longer term, Bob and I both would really like to find a general mechanism
for making this pattern easy to do from any path into a GWT module from "the
outside", exactly along the lines of what Matt was talking about. I think
rolling this functionality into gwt-exporter (and then rolling that sort of
functionality directly into GWT proper) will get us pretty far down the
road.

Code review request forthcoming, possibly tomorrow.

-- Bruce

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

[gwt-contrib] New API proposal: BatchedCommand

[Bruce Johnson]

As is our team custom, I'd like unanimous signoff (or FHMP) from the GWT
team on this new API, as well as any and all feedback from the larger
community.
=== Proposal ===
Add a new API called BatchedCommand that enqueues callbacks that should be
called "later", much like a DeferredCommand, but definitely prior to the
next dispatch of the native event loop.

=== Key use case: Style injection ===
Injecting CSS styles programmatically (e.g. StyleInjector) causes the
browser to do a lot of work (e.g. selector matching, assimilating the new
CSS with the existing CSS) and this work happens synchronously during the
"inject" call. Therefore, a sequence of such injections across independent
calls in GWT code tends to induce a huge amount of overhead in the browser
(that is, because the browser does so much recalculation for each call). It
is much faster to concatenate each small chunk of CSS across calls to
"inject" into one large CSS chunk so that the overhead need only occur once
when all the CSS text has been concatenated (vs. doing the work once per
"inject" call site). Measurements have show 8-10x difference in speed
between the two approaches on Chrome and other browsers. (I'm not being
especially precise in the timings because the savings is large enough that
there's simply no question that it's beneficial).

The above describes exactly the sort of thing that DeferredCommands are
perfect for, except for one thing: DeferredCommands are guaranteed to run
*after* the JavaScript causing them to be enqueued has finished and the
native event loop has executed at least once. In the case of
programmatically injected styles, we definitely do not want this behavior,
because it would mean that DOM structures created could be rendered (because
the event loop might dispatch paint handlers) before their associated CSS
has been injected. The net results would be the user seeing ugly unstyled
DOM structures for at least a short amount of time, which is unacceptable.

Thus, we need a BatchedCommand that is guaranteed to execute callbacks
*before* the JavaScript call stack in which they are enqueued has fully
unwound. A prototype version of StyleInjector has been created that uses the
new technique, and it works nicely.

=== The Actual API ===
It is small enough that I can include the code directly:

package com.google.gwt.core.client;

/**
 * A BatchedCommand is a command that will be executed by the
GWT
 * libraries before the JavaScript stack unwinds (before the browser's
 * native event queue is pumped whenever feasible).
 */
public abstract class BatchedCommand {

  /**
   * Enqueues a BatchedCommand to be executed before the JavaScript stack
   * unwinds (typically before the browser's native event queue is pumped).
   *
   * @param cmd the command to be fired. Must not be null.
   */
  public static void add(BatchedCommand cmd);

  /**
   * Causes the BatchedCommand to execute its encapsulated
   * behavior.
   */
  public abstract void execute();
}


As you can see above, it is in the "core.client" package. It is necessary to
put it here (vs. alongside or integrated with DeferredCommand) because we
have to guard every known entrypoint into Java code, which includes things
like runAsync callbacks, which are themselves in core. In other words,
putting BatchedCommand in gwt-user would have meant that core code would
have to depend on gwt-user, which would be a bad idea.


The last note is that the API pattern differs from DeferredCommand/Command
and IncrementalCommand in that it doesn't have a separate callback
interface. BatchedComand#add() doesn't take a "Command" callback; it takes a
BatchCommand which has overridden the execute() method. This isn't a vitally
important design divergence from DeferredCommand/Command, but it seemed
kinda nice to have one less type.


Okay, that's my story. Thoughts?


-- Bruce



P.S. Bob V has already signed off on this; we pair-programmed the prototype
code for it.

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

[gwt-contrib] Re: update logging to provide performance metrics

[Bruce Johnson]

I think I'd rather look at any such work as orthogonal perf metrics data
gathering since it is really is, functionally, an independent question of
the log level. For example, we might want to see the effect of logging
itself on the speed of hosted mode refresh.
I think some sort of separate global collector mechanism would be a better
design.

On Wed, Sep 2, 2009 at 9:48 AM, John Tamplin  wrote:

> On Wed, Sep 2, 2009 at 8:58 AM, Freeland Abbott wrote:
>
>> Is the TIMING log level a good idea, though, and sorted correctly?  I
>> waffled a bit on whether to make it be a new log level or an orthogonal
>> flag
>
>
> I'm not sure it makes sense as a log level -- I think perhaps a separate
> flag to trigger timing information is useful, though it isn't clear how that
> will wind up different than the existing PerfLogger usage.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

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

[gwt-contrib] Re: UiBinder first impressions

[Bruce Johnson]

No plans to do drag-n-drop or anything wysiwyg. We'll probably
continue to focus on the basics.

On Tuesday, August 25, 2009, Miroslav Pokorny
 wrote:
> Extras...
> Are there any plans to build a ui tool (maybe in swing) so designers can drag 
> n drop available widgets and have the view instantly updated?
> Other kool features might include save the file etc.Some of the extra 
> features in interface builder.
> Thoughts...?
> On 26/08/2009, at 2:14 AM, Bruce Johnson  wrote:
>
> Hi Sony,
> I just wanted to clarify that UiBinder is based on XHTML not merely to make 
> coding more succinct vs. Java code. I agree that we could in theory provide 
> fluent APIs that could make Java imperative UI code much more succinct than 
> it is now. But there are three other big motivations for UiBinder that 
> wouldn't be address by fluent APIs that I wanted to share.
>
> First, specifying layouts in XHTML encouages developers (by making it easier) 
> to use HTML rather than widgets/panels where the two are effectively 
> equivalent anyway. For example, it's just as easy to use "" instead of 
> "" when you're already working in XHTML, yet  is much, much 
> better. Browsers can parse and render HTML string fragments much faster than 
> they can executing JavaScript that builds DOM structures programmatically. 
> So, really, UiBinder is a trojan horse to get people to write apps that are 
> smaller and run faster :-)
>
> Secondly, many teams we've worked with at Google really like that UiBinder 
> creates a firm wall between the aesthetics of the UI vs. its programatic 
> behavior, which supports well the MVP pattern that is becoming increasingly 
> recognizes as The Right Way to architect internet-based client/server apps. 
> It's also a good way to divide work in teams that have designers and 
> developers; designers can mess with the XHTML, developers can mess with the 
> code and if they ever diverge, you'll get a compile-time error. This seems to 
> really facilitate the kind of workflow in which a lot of people have 
> expressed interest since GWT 1.0. We're excited to finally be getting there.
>
> Finally, GWT is all about finding coding patterns with which tools (IDEs in 
> particular) are useful. UiBinder's XHTML syntax makes it easier to write good 
> tools because it isn't as expressive as full-blown code: more restrictive 
> language means more ability to analyze it statically, which is what tools are 
> all about. Fluent APIs that would encourage people to write UIs with Java 
> code are less amenable to creating good tools for them. For example, the 
> Google Plugin is already working on tools to make editing UiBinder templates 
> easy breezy, and we hope other IDEs will do the same.
>
> -- Bruce
> On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew  wrote:
>
>
> One point I have tried injecting into the GWT community is the
> importance of fluent APIs.  GWT's Java API is currently quite
> cumbersome for layouts and it seems folks immediately jumped to the
> conclusion that Java doesn't work and have gone the route of using XML
> for layouts.  I am not against folks that want XML layouts but there
> are many that feel fluent APIs in Java for layouts will be even more
> productive  Even if you layout your initial UI in XML you are still
> going to need to modify it dynamically in Java based on various events
> - so you end up having a eye sore mix.
>
> I put out an example of a fluent API called AxisPanel (search for it)
> - its not a great implementation - but it pretty much let me layout
> everything pretty quickly and changed the pace of my GWT development
> drastically - especially when it came to modifying layouts with new
> requirements.  Speaking for myself - I would like to see more such
> APIs (and better implementations than my AxisPanel) that folks can
> rely on as part of the Core GWT.
>
> I don't think developers starting a new GWT project would adopt XML
> layouts if they could fluently layout in Java right alongside the rest
> of their coding (at-least thats my theory)..
>
> Sony
>
> On Aug 10, 8:59 am, Arthur Kalmenson  wrote:
>> Hello everyone,
>>
>> We've been playing with UiBinder and I thought it'd be a good idea to
>> share what we've seen so far (and ask some questions).
>>
>> Some of the apps we write are used by more then one hospital and this
>> requires a tailored UI depending on the user's preferences and to
>> store additional information that a particular hospital needs to keep
>> track of. At the moment, writing UI in a swing style, we program to
>> interfaces and use GIN t
>

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

[gwt-contrib] Re: Nullness tracking

[Bruce Johnson]

Any numbers, by the way, on the before/after effects?

On Tue, Aug 25, 2009 at 2:54 PM,  wrote:

>
> Reviewers: scottb,
>
> Description:
> Tracks nullness within the compiler by adding a JNonNull type.
>
> See http://code.google.com/p/google-web-toolkit/issues/detail?id=1819 .
>
>
> Please review this at http://gwt-code-reviews.appspot.com/62805
>
> Affected files:
>   dev/core/src/com/google/gwt/core/ext/soyc/impl/SizeMapRecorder.java
>   dev/core/src/com/google/gwt/dev/jjs/CorrelationFactory.java
>   dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JArrayRef.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JBinaryOperation.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JCastOperation.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JConditional.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JGwtCreate.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JNewArray.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JNewInstance.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JNonNullType.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JNullType.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JReboundEntryPoint.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JReferenceType.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JStringLiteral.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JThisRef.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/JVariable.java
>   dev/core/src/com/google/gwt/dev/jjs/ast/js/JsniFieldRef.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/ArrayNormalizer.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/CastNormalizer.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/CloneExpressionVisitor.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.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/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/JavaToJavaScriptMap.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/ResolveRebinds.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/SourceGenerationVisitor.java
>   dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
>
>
> dev/core/src/com/google/gwt/dev/js/JsSourceGenerationVisitorWithSizeBreakdown.java
>   dev/core/test/com/google/gwt/dev/jjs/JjsTypeTest.java
>
>
>
> >
>

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

[gwt-contrib] Re: UiBinder first impressions

[Bruce Johnson]

Hi Sony,
I just wanted to clarify that UiBinder is based on XHTML not merely to make
coding more succinct vs. Java code. I agree that we could in theory provide
fluent APIs that could make Java imperative UI code much more succinct than
it is now. But there are three other big motivations for UiBinder that
wouldn't be address by fluent APIs that I wanted to share.

First, specifying layouts in XHTML encouages developers (by making it
easier) to use HTML rather than widgets/panels where the two are effectively
equivalent anyway. For example, it's just as easy to use "" instead of
"" when you're already working in XHTML, yet  is much, much
better. Browsers can parse and render HTML string fragments much faster than
they can executing JavaScript that builds DOM structures programmatically.
So, really, UiBinder is a trojan horse to get people to write apps that are
smaller and run faster :-)

Secondly, many teams we've worked with at Google really like that UiBinder
creates a firm wall between the aesthetics of the UI vs. its programatic
behavior, which supports well the MVP pattern that is becoming increasingly
recognizes as The Right Way to architect internet-based client/server apps.
It's also a good way to divide work in teams that have designers and
developers; designers can mess with the XHTML, developers can mess with the
code and if they ever diverge, you'll get a compile-time error. This seems
to really facilitate the kind of workflow in which a lot of people have
expressed interest since GWT 1.0. We're excited to finally be getting there.

Finally, GWT is all about finding coding patterns with which tools (IDEs in
particular) are useful. UiBinder's XHTML syntax makes it easier to write
good tools because it isn't as expressive as full-blown code: more
restrictive language means more ability to analyze it statically, which is
what tools are all about. Fluent APIs that would encourage people to write
UIs with Java code are less amenable to creating good tools for them. For
example, the Google Plugin is already working on tools to make editing
UiBinder templates easy breezy, and we hope other IDEs will do the same.

-- Bruce

On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew  wrote:

>
> One point I have tried injecting into the GWT community is the
> importance of fluent APIs.  GWT's Java API is currently quite
> cumbersome for layouts and it seems folks immediately jumped to the
> conclusion that Java doesn't work and have gone the route of using XML
> for layouts.  I am not against folks that want XML layouts but there
> are many that feel fluent APIs in Java for layouts will be even more
> productive  Even if you layout your initial UI in XML you are still
> going to need to modify it dynamically in Java based on various events
> - so you end up having a eye sore mix.
>
> I put out an example of a fluent API called AxisPanel (search for it)
> - its not a great implementation - but it pretty much let me layout
> everything pretty quickly and changed the pace of my GWT development
> drastically - especially when it came to modifying layouts with new
> requirements.  Speaking for myself - I would like to see more such
> APIs (and better implementations than my AxisPanel) that folks can
> rely on as part of the Core GWT.
>
> I don't think developers starting a new GWT project would adopt XML
> layouts if they could fluently layout in Java right alongside the rest
> of their coding (at-least thats my theory)..
>
> Sony
>
> On Aug 10, 8:59 am, Arthur Kalmenson  wrote:
> > Hello everyone,
> >
> > We've been playing with UiBinder and I thought it'd be a good idea to
> > share what we've seen so far (and ask some questions).
> >
> > Some of the apps we write are used by more then one hospital and this
> > requires a tailored UI depending on the user's preferences and to
> > store additional information that a particular hospital needs to keep
> > track of. At the moment, writing UI in a swing style, we program to
> > interfaces and use GIN to bind everything together. Using different
> > AbstractGinModules and Ginjectors, we can tie the application together
> > in different ways using different UI implementations. What would be
> > the way to do this with UiBinder? From what we could tell, one would
> > use UiTemplate, but there doesn't seem to be a way to configure the
> > String in UiTemplate easily through a GIN module. Are there
> > alternatives?
> >
> > Following the programming to interfaces theme, we've been doing that
> > with UiBinder, but have run into an issue when trying to build a
> > larger UI page out of smaller ui.xml classes. It seems that referring
> > to interfaces in ui.xml doesn

[gwt-contrib] Re: Implement conditional set-property and extend-property declarations

[bruce]

LGTM if you implement all the suggestions.


http://gwt-code-reviews.appspot.com/57802/diff/1001/54
File dev/core/src/com/google/gwt/dev/cfg/BindingProperty.java (right):

http://gwt-code-reviews.appspot.com/57802/diff/1001/54#newcode73
Line 73: return conditionalValues;
Better to make it unmodifiable to prevent future errors from creeping in

http://gwt-code-reviews.appspot.com/57802/diff/1001/65
File dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java (right):

http://gwt-code-reviews.appspot.com/57802/diff/1001/65#newcode323
Line 323: protected Schema __extend_property_begin(BindingProperty
property,
Let's remove the ability to use conditionals on  for
now, as we discussed on the phone.

http://gwt-code-reviews.appspot.com/57802/diff/1001/68
File dev/core/src/com/google/gwt/dev/cfg/PropertyPermutations.java
(right):

http://gwt-code-reviews.appspot.com/57802/diff/1001/68#newcode88
Line 88: + bindingProps.toString());
BindingProperty.toString() isn't implement; need to make it pretty for
this error message to make sense

http://gwt-code-reviews.appspot.com/57802/diff/1001/70
File
dev/core/src/com/google/gwt/dev/shell/ModuleSpacePropertyOracle.java
(right):

http://gwt-code-reviews.appspot.com/57802/diff/1001/70#newcode196
Line 196: values = prop.getAllowedValues(winner);
can you assign at declaration in 195

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

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

[gwt-contrib] Re: Stop trying to launch firefox, terminology changes

[bruce]

LGTM, but would be nice to tweak the instructional message.


http://gwt-code-reviews.appspot.com/56817/diff/1/2
File dev/oophm/src/com/google/gwt/dev/OophmHostedModeBase.java (right):

http://gwt-code-reviews.appspot.com/56817/diff/1/2#newcode321
Line 321: "Please connect a browser with the GWT Plugin to the URL");
The phrasing sounds a bit like you are telling them to connect a browser
*to* the GWT plugin.  I'd suggest, "Using a browser with the GWT
Development Plugin, please browse to the following URL:"

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

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

[gwt-contrib] Clean up GWTCompiler output

[Bruce Johnson]

End this email below is what it looks like when I run the compiler on a
modified Hello sample using the default compiler log level. How is the
signal-to-noise ratio? I think it's not great.


A few areas for improvement:

- Lower the log level for "Creating Split Point Map file for SOYC"; seems
like this should be TRACE, since they don't actually have info that is
really context-relevant; it's more telling you what code path the compiler
itself is following; it might seem more useful if it listed the file name.

- Maybe get rid of ""Done"; the presence of subsequent outdented logs should
make it clear enough that the preceding step has finished

- Lower the log level of permutation timings to INFO

- Decide how to make the permutation counting look like it makes sense; in
particular, specifying " of ", you expect the indices to range 1..N
rather than 0..(N-1). Every time I see that last mesage "8 of 9" I keep
feeling disappointed that I never see "9 of 9" :-)

- Lower the log level of the "Linking" subtree, and specify what "war"
directory is being linked into, such as "Linking into war at
/usr/local/myproject/war"


Also, on another note, when you run the compiler with -treeLogger, we still
get some console noise that looks like this:

Permutation took 516 ms

Permutation took 284 ms

Permutation took 187 ms

Permutation took 147 ms

Permutation took 196 ms

Permutation took 131 ms

Permutation took 177 ms

Permutation took 140 ms

Permutation took 134 ms


I think we have a stray System.out?


In the end, it seems like the default log level ought to produce treelogger
output that looks like this:


Compiling module com.google.gwt.sample.hello.Hello

Compilation succeeded -- 6.889s

Arguably, it should even be silent unless there's a problem.

Thoughts? Anyone eager to write a patch for changes along these lines?

-- Bruce

=== Actual log below ===


Compiling module com.google.gwt.sample.hello.Hello

   Compiling 9 permutations

   Worker permutation 0 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 294 ms

   Worker permutation 1 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 291 ms

   Worker permutation 2 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 197 ms

   Worker permutation 3 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 154 ms

   Worker permutation 4 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 198 ms

   Worker permutation 5 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 194 ms

   Worker permutation 6 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 184 ms

   Worker permutation 7 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 145 ms

   Worker permutation 8 of 9

  Creating Split Point Map file for SOYC

 Done

Permutation took 131 ms

  Permutation compile succeeded

Linking into war

   Link succeeded

   Compilation succeeded -- 6.889s

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

[gwt-contrib] Re: Rework emulated stack trace with conditional properties

[bruce]

LGTM, pending an LGTM on the other conditional property patch


http://gwt-code-reviews.appspot.com/56816/diff/1/6
File user/src/com/google/gwt/junit/JUnit.gwt.xml (right):

http://gwt-code-reviews.appspot.com/56816/diff/1/6#newcode34
Line 34: 
Probably want to remove this now?

http://gwt-code-reviews.appspot.com/56816/diff/1/6#newcode44
Line 44: 
To double-check, you're leaving these off because you  know that they
can already generate their own stack traces without emulation?

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

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

[gwt-contrib] Re: Rework emulated stack trace with conditional properties

[Bruce Johnson]

On Thu, Aug 13, 2009 at 12:55 PM,  wrote:

> @Bruce, does the following work for you?
>
>
>  
>
>
>  
>
>
>{
>  return location.search.indexOf('emulatedStack') != -1 ? 'true' :
> 'false';
>}
>


When you say, does it work for me, do you mean do I like it, or does it
literally run? I didn't run it (but can, if that's helpful), but I do like
the looks of it. It seems like exactly when I'd expect to see.

Reviewing the updated code now.

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

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

[Bruce Johnson]

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

> On Wed, Aug 12, 2009 at 6:39 PM, Bruce Johnson  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: Prettier GWT version names for upcoming 2.0 releases

[Bruce Johnson]

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