Re: [gwt-contrib] About GWT opinion in thoughtworks technology radar july 2011
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 emilio@gmail.com 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)?
[+Scott and Kelly from Google]
On Thu, Sep 30, 2010 at 4:54 PM, Damon Lundin damon.lun...@gmail.comwrote:
We are trying to upgrade from 2.0.4 to 2.1.0.m3 because of some bugs
in 2.0.4 but in doing so our GWT test cases have begun failing and I
have determined it's because the next test is beginning before the
previous one is complete and they are messing each other up. I know
that delayTestFinish is meant to allow for tests to make use of async
calls and it's been working for us but now it's not.
We have a number of tests that roughly look like this:
public void test03 {
delayTestFinish(12);
rpcService.someServerCall(new AsyncCallback() {
public void onSuccess() {
// Do some stuff
DeferredCommand.addCommand(new Command() {
public void execute() {
// More stuff
finishTest();
}
}
}
}
}
public void test04 {
delayTestFinish(12);
...
}
Our code actually uses DeferredCommands in a long chain of calls but
in short, test04 begins executing before we call finishTest() in the
previous test and I don't think that's supposed to happen.
I could further debug this if someone could explain to me what
implemented in the translatable version of this class means and how
I would debug this translatable version. Any advice on how to
proceed?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: allow CheckBox to accept null?
Fwiw, I don't actually care. It just seemed like something that needed some devil's advocacy. On Thursday, August 26, 2010, Ray Ryan rj...@google.com 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 andrew.piet...@gmail.com 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 johan.rydb...@edgeware.tv 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?
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 rj...@google.com 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] RR: allow CheckBox to accept null?
Glad I looked at it funny, then. Micro-design reviews ftw. On Wed, Aug 25, 2010 at 12:16 PM, Ray Ryan rj...@google.com 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 br...@google.com 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 rj...@google.com 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] Re: Introducing the Abstractizer compiler optimization (issue 4893) (issue609801)
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 sp...@google.com 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
Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)
On 3/25/10, Daniel Rice (דניאל רייס) r...@google.com 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.
[gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)
On Thursday, March 25, 2010, Freeland Abbott fabb...@google.com 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 (דניאל רייס) r...@google.com 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 br...@google.com wrote: On 3/25/10, Daniel Rice (דניאל רייס) r...@google.com 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.
[gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)
What John said. JSO cross-casts allow this. On Thursday, March 25, 2010, John Tamplin j...@google.com wrote: On Thu, Mar 25, 2010 at 6:07 PM, Rodrigo Chandia rchan...@google.com 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 ImmutableArrayImplE(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)
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 rj...@google.com 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 rchan...@google.comwrote: 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 rj...@google.com 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] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)
@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 j...@google.com wrote: On Mon, Mar 22, 2010 at 2:19 PM, Freeland Abbott fabb...@google.comwrote: 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.
Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)
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(ImmutableArrayWidget 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(ListWidget 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 rchan...@google.comwrote:
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 rj...@google.com
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 j...@google.com 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 owner
Re: [gwt-contrib] Array implementation for Lightweight Collections. Pure Java implementation only.
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 rchan...@google.com wrote:
Sure!
2010/3/19 Ray Ryan rj...@google.com
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 rchan...@google.com 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 rj...@google.com
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 rchan...@google.com 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 mmen...@google.com 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 rchan...@google.com 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 mmen...@google.com 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, rchan...@google.com 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] Array implementation for Lightweight Collections. Pure Java implementation only.
@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 j...@google.com wrote: On Fri, Mar 19, 2010 at 4:21 PM, Rodrigo Chandia rchan...@google.comwrote: 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] Re: supporting java.io.InputStream/Reader in GWT's JRE
On Tue, Mar 9, 2010 at 11:29 AM, Andi Mullaraj andimulla...@gmail.comwrote: 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] RFC : Soft permutations for the GWT compiler
Since module-mutator 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 b...@google.com 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 module-mutator 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] RFC : Soft permutations for the GWT compiler
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 j...@google.com wrote: On Tue, Mar 9, 2010 at 3:31 PM, BobV b...@google.com 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 module-mutator 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] [google-web-toolkit] r7690 committed - Gflow framework with some local CFG-based optimizations....
very exciting! nice work. On Tue, Mar 9, 2010 at 7:20 PM, Scott Blum sco...@google.com 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] Re: CSS Selector Engine
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 cromwell...@gmail.com 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 jarrod.carl...@gmail.com 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=1q=colspec=ID+Type+Status+Priority+Milestone+Owner+Summarycells=tiles On Feb 9, 10:26 pm, John Tamplin j...@google.com wrote: On Tue, Feb 9, 2010 at 9:51 PM, jarrod jarrod.carl...@gmail.com 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] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)
On Tue, Feb 2, 2010 at 11:43 AM, Paul Robinson ukcue...@gmail.com 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
[gwt-contrib] Interest in Wave for design docs?
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] Questions on JsArray*
@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 tomson...@gmail.com wrote: On Tue, Feb 2, 2010 at 8:19 PM, John Tamplin j...@google.com wrote: On Tue, Feb 2, 2010 at 2:16 PM, Tom tomson...@gmail.com 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
Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)
On Mon, Feb 1, 2010 at 4:05 PM, Sami Jaber sami.ja...@gmail.com 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
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 arthur.k...@gmail.com 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 david.no...@gmail.com 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 dilbert.elbo...@gmail.com 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 jlaba...@google.com 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 dilbert.elbo...@gmail.comwrote: 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 rj...@google.com wrote: On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy dilbert.elbo...@gmail.com 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
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
Happy belated birthday! On Monday, January 4, 2010, Thomas Broyer t.bro...@gmail.com wrote: On Mon, Jan 4, 2010 at 7:45 PM, Joel Webber j...@google.com 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://xn--nna.ma.xn--bwa-xxb.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: when-linkers-include name='xs' /
Lex/Bob: To clarify one thing, did you mean set-configuration-property vs. set-property 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 set-configuration-property and would love to see it go away since in principle it unifies with set-property (doesn't it?) All this stuff it getting too fragmented and confusing. On Tue, Dec 22, 2009 at 4:17 PM, BobV b...@google.com 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] Re: when-linkers-include name='xs' /
Let's take this to a separate thread or a wave, just to keep things organized. 2009/12/22 John Tamplin j...@google.com On Tue, Dec 22, 2009 at 10:09 PM, Bruce Johnson br...@google.com wrote: Related future discussion: I'm not really a fan of set-configuration-property and would love to see it go away since in principle it unifies with set-property (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] uibinder and bnudled CSS
Definitely do need to escape, as you said. On Thursday, December 17, 2009, John Huss johnth...@gmail.com 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 nicolas.del...@gmail.com 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?
Working on a draft one. What do folks here think is important? On Wed, Dec 16, 2009 at 7:42 AM, tfreitas tfrei...@gmail.com 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
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 j...@google.com wrote: On Tue, Dec 15, 2009 at 4:00 AM, cromwell...@gmail.com 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
What John said :-) On Saturday, December 5, 2009, John Tamplin j...@google.com wrote: On Sat, Dec 5, 2009 at 4:36 AM, Sami Jaber sami.ja...@gmail.com 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
@Bob: You rock. @Ray: I like. On Fri, Nov 27, 2009 at 1:13 AM, Ray Cromwell cromwell...@gmail.com 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 b...@google.com wrote: On Wed, Nov 25, 2009 at 9:58 AM, Bruce Johnson br...@google.com wrote: A) I want stack traces everywhere that it isn't costly. !-- This is a derived property that doesn't need a property provider and indicates that getting a useful stack trace will be expensive -- define-property name=stackIsExpensive values=true,false / set-property name=stackIsExpensive value=false / set-property name=stackIsExpensive value=true any when-property-is name=user.agent value=ie6 / when-property-is name=user.agent value=ie8 / /any /set-property !-- Assuming native is the default value. Since the native stack isn't useful, optimize for code size -- set-property name=stack value=strip when-property-is name=stackIsExpensive value=true / /set-property 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. define-property name=inStackExperiment values=true,false / property-provider name=inStackExperiment // Do something with cookies, recalculating value every week /property-provider set-property name=stack value=emulated when-property-is name=inStackExperiment value=true / when-property-is name=stackIsExpensive value=true / /set-property set-property name=stack value=strip when-property-is name=inStackExperiment value=false / when-property-is name=stackIsExpensive value=true / /set-property C) I want maximum fidelity stack traces everywhere, even paying for emulation on browsers that have native stack traces, if that's better. set-property name=stack value=emulated / 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. set-property name=stack value=strip / !-- Assuming that native stack traces are good enough -- set-property name=stack vaue=native when-property-is name=inStackExperiment value=true / when-property-is name=stackIsExpensive value=false / /set-property set-property name=stack vaue=emulated when-property-is name=inStackExperiment value=true / when-property-is name=stackIsExpensive value=true / /set-property -- 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
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 b...@google.com 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: define-property name=compiler.stackMode values=strip, native, emulated / set-property name=compiler.stackMode value=native / set-property name=compiler.stackMode value=emulated when-property-is name=compiler.emulatedStack value=true / /set-property 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
Re: [gwt-contrib] TypeOracle allTypes including types not in a source path
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 j...@google.com wrote: On Mon, Nov 23, 2009 at 1:33 PM, Matt Mastracci matt...@mastracci.comwrote: 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 source 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] TypeOracle allTypes including types not in a source path
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 itru...@gmail.com wrote: +1 deprecate and warn. On Mon, Nov 23, 2009 at 2:24 PM, Ray Ryan rj...@google.com 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
Google Web Toolkit 2.0 RC1 Now Available
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 at 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 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=.
Re: [gwt-contrib] Re: Cannot install gwt-dev-plugin.exe from gwt-dev-missing-plugin.appspot.com
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 mark.ren...@gmail.com wrote: Oh, sorry... I *just* saw r6956. That worked. Thanks! On Nov 17, 12:05 pm, John Tamplin j...@google.com 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 mark.ren...@gmail.com 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] Google Web Toolkit 2.0 RC1 Now Available
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] adding new names to the blackout list
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 (דניאל רייס) r...@google.comwrote: // 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 fabb...@google.com 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
Re: [gwt-contrib] adding new names to the blackout list
+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 fabb...@google.com 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 br...@google.com 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 (דניאל רייס) r...@google.com 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 fabb...@google.com 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] Code Review Request: Updated hosted.html to be pretty
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] Re: Code Review Request: Made missing plugin iframe prettier
Committed to tr...@6891 and merged to 2...@6892. On Fri, Nov 13, 2009 at 12:06 PM, John Tamplin j...@google.com wrote: On Fri, Nov 13, 2009 at 12:03 PM, br...@google.com 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] Re: Trace that auto detects the calling class/method.
On Tue, Nov 10, 2009 at 11:12 AM, David david.no...@gmail.com 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: Fixes NPE in DockLayoutPanelParser when children have no NS
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 rj...@google.com 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, j...@google.com 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] Re: Compiler Optimization Thought: Class merging
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 sco...@google.com 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 nwwe...@gmail.com 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
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 matt...@mastracci.comwrote: 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: Fix a daylight saving bug
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 (דניאל רייס) r...@google.comwrote: 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, jlaba...@google.com 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: Inline Polymorphic Function Declarations
Very cool find.
On Fri, Oct 30, 2009 at 8:00 PM, cromwell...@gmail.com 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: Inline Polymorphic Function Declarations
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 cromwell...@gmail.com wrote: On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson br...@google.com 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
yep, and all of them should be per-perm On Saturday, October 31, 2009, Ray Cromwell cromwell...@gmail.com 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 br...@google.com 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 cromwell...@gmail.com wrote: On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson br...@google.com 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: Very fast code review: Adding UiBinder to javadoc
SGTM On Wed, Oct 28, 2009 at 7:12 PM, Ray Ryan rj...@google.com 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: TBR requested
both lgtmd kthxbye On Thu, Oct 29, 2009 at 7:28 PM, Ray Ryan rj...@google.com 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] Very fast code review: Adding UiBinder to javadoc
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: Very fast code review: Adding UiBinder to javadoc
On Wed, Oct 28, 2009 at 6:38 PM, Ray Ryan rj...@google.com 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] Re: Server side I18N
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 thobias.karls...@gmail.com 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=1174821983024ref=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 rj...@google.com 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: will deRPC ship with GWT 2.0 ?
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 sami.ja...@gmail.com 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 br...@google.com 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 sami.ja...@gmail.comwrote: 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 ?
Love the enthusiasm! Anyone else? On Mon, Oct 19, 2009 at 4:26 PM, Sami Jaber sami.ja...@gmail.com 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 br...@google.com 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 sami.ja...@gmail.com 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 br...@google.com 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 sami.ja...@gmail.comwrote: 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: Server side I18N
@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 j...@google.com wrote:
On Mon, Oct 19, 2009 at 5:23 PM, Thoka thobias.karls...@gmail.com 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: Proposed API Addition - @WithModuleParameters on test cases
@John L: You taking this one? On Wed, Oct 14, 2009 at 12:08 PM, Pascal Muetschard pmuetsch...@google.comwrote: 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 j...@google.com wrote: On Mon, Oct 12, 2009 at 12:03 AM, John LaBanca jlaba...@google.comwrote: @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 : GWT 2.0: Initial thoughts on $entry
LGTM On 10/12/09, b...@google.com 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: Proposed API Addition - @WithModuleParameters on test cases
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 jlaba...@google.com 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: Proposed API Addition - @WithModuleParameters on test cases
On Fri, Sep 25, 2009 at 1:19 PM, Pascal Muetschard pmuetsch...@google.comwrote: 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 set-property 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
On Fri, Sep 25, 2009 at 1:51 PM, John LaBanca jlaba...@google.com 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: Introduces inline styles to ui.xml files
Another w00t! This is brilliant. On Thu, Sep 10, 2009 at 7:00 PM, Joel Webber j...@google.com wrote: W00t, thanks. Looking forward to using this.Thanks for doing this review, Lex. On Thu, Sep 10, 2009 at 4:36 PM, rj...@google.com 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: Introduces inline styles to ui.xml files
And those class names get obfuscated, too, right?
On Fri, Sep 11, 2009 at 6:24 PM, Ray Ryan rj...@google.com wrote:
Want to see the best part? Css namespaces for free, courtesy of
CssResource.
ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
ui:style
.pretty {
color: red;
}
/ui:style
ui:style field='otherStyle'
.pretty {
color: green;
}
/ui:style
div
div class='{style.pretty}'I am red./div
div class='{otherStyle.pretty}'I am green./div
/div
/ui:UiBinder
On Fri, Sep 11, 2009 at 2:23 PM, Bruce Johnson br...@google.com wrote:
Another w00t!
This is brilliant.
On Thu, Sep 10, 2009 at 7:00 PM, Joel Webber j...@google.com wrote:
W00t, thanks. Looking forward to using this.Thanks for doing this
review, Lex.
On Thu, Sep 10, 2009 at 4:36 PM, rj...@google.com 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: New API proposal: BatchedCommand
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 cromwell...@gmail.com wrote:
Is there a reason why we just don't add Runnable and CallableV 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 br...@google.com 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 br...@google.com 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
[gwt-contrib] Re: New API proposal: BatchedCommand
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 br...@google.comwrote: On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum sco...@google.com 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
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 br...@google.com 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 j...@google.com 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 sco...@google.com wrote:
++Ray.
On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan rj...@google.com wrote:
The mechanism is just brilliant. I have reservations about the api.
bikeshed
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.client.Command
- And have BatchedCommand accept com.google.gwt.core.client
And the two names, DeferredComand and BatchedCommand, don't give
much clue as to which does what. And of course BatchedCommand doesn't
actually provide any batching service.
If we were doing all this from scratch, I suspect we would wind up with
something like this in core (presuming we're happy with IncrementalCommand
and addPause):
package com.google.gwt.core.dispatch
public interface Command {
void execute();
}
public interface IncrementalCommand {
boolean execute();
}
public class
[gwt-contrib] Re: update logging to provide performance metrics
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 j...@google.com wrote: On Wed, Sep 2, 2009 at 8:58 AM, Freeland Abbott fabb...@google.comwrote: 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: New API proposal: BatchedCommand
On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum sco...@google.com 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: UiBinder first impressions
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 div instead of FlowPanel when you're already working in XHTML, yet div 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 xsonymat...@gmail.com 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 arthur.k...@gmail.com 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't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having
[gwt-contrib] Re: Nullness tracking
Any numbers, by the way, on the before/after effects? On Tue, Aug 25, 2009 at 2:54 PM, sp...@google.com 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
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 miroslav.poko...@gmail.com 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 br...@google.com 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 div instead of FlowPanel when you're already working in XHTML, yet div 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 xsonymat...@gmail.com 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 arthur.k...@gmail.com 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: Rework emulated stack trace with conditional properties
On Thu, Aug 13, 2009 at 12:55 PM, b...@google.com wrote:
@Bruce, does the following work for you?
set-property name=compiler.emulatedStack value=true,false
any
when-property-is name=user.agent value=ie6 /
when-property-is name=user.agent value=ie8 /
/any
/set-property
property-provider name=compiler.emulatedStack
{
return location.search.indexOf('emulatedStack') != -1 ? 'true' :
'false';
}
/property-provider
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] Clean up GWTCompiler output
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 I of N, 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: Prettier GWT version names for upcoming 2.0 releases
Exactly :-) On Wednesday, August 12, 2009, Joel Webber j...@google.com wrote: Makes sense to me. So the first one will be gwt-2.0.0-m0, right? On Tue, Aug 11, 2009 at 11:40 PM, Bruce Johnson br...@google.com wrote: Mostly, this writeup is aimed at people who have been working on GWT's own build-related stuff, but if anyone else has objections, now would be a good time to raise them (though it seems unlikely anyone would). In the past, we've never had a good naming scheme for distros other than the general availability distro. For milestones, we used the convention 0.0.rev, which probably scares people off and isn't at all self-descriptive. For RCs and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing. Here's the new proposal: major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2)= This is an official, supported build. Every new minor (or bigger) release would start with a bugfix number of 0. major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2)= This is release candidate build n for the specified upcoming GWT release major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2)= This is milestone build n for the specified upcoming GWT release In other words, the stream of announced code drops for 2.0 will look like this (assuming 2 milestone and 1 rc): 1) gwt-2.0.0-m1.zip2) gwt-2.0.0-m2.zip3) gwt-2.0.0-rc1.zip4) gwt-2.0.0.zip Note that we would always include the RC number, even if there's just one (because you never know if another one is coming). I'm very happy to report that there seems to be no need to change even a single line of code, as best I can tell. (Thank you to whomever wrote the version string parsing code to ignore non-digit prefixes and suffixes.) Thus, by simply following this convention when we set GWT_VERSION in the continuous build, everything should work just fine. -- Bruce P.S. No, Joel, we can't start counting at 0, even though it makes more sense :-) I can read your mind. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases
Duh, Kelly. Everybody knows that you always start counting at 1 when there's a number immediately following a space or a non-digit and you start counting at 0 when there's a number that immediately follows a period. It's such a logical and obvious system that I thought the rules would be self-evident. On Wed, Aug 12, 2009 at 9:24 AM, Kelly Norton knor...@google.com wrote: No, no, Joel, we will start counting at 1 not 0. The first release will be gwt-2.1.1-m1. I think the naming scheme is good (even if sometimes starts with 0, other times with 1). /kel On Wed, Aug 12, 2009 at 9:12 AM, Joel Webber j...@google.com wrote: Makes sense to me. So the first one will be gwt-2.0.0-m0, right? On Tue, Aug 11, 2009 at 11:40 PM, Bruce Johnson br...@google.com wrote: Mostly, this writeup is aimed at people who have been working on GWT's own build-related stuff, but if anyone else has objections, now would be a good time to raise them (though it seems unlikely anyone would). In the past, we've never had a good naming scheme for distros other than the general availability distro. For milestones, we used the convention 0.0.rev, which probably scares people off and isn't at all self-descriptive. For RCs and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing. Here's the new proposal: major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2) = This is an official, supported build. Every new minor (or bigger) release would start with a bugfix number of 0. major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2) = This is release candidate build n for the specified upcoming GWT release major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2) = This is milestone build n for the specified upcoming GWT release In other words, the stream of announced code drops for 2.0 will look like this (assuming 2 milestone and 1 rc): 1) gwt-2.0.0-m1.zip 2) gwt-2.0.0-m2.zip 3) gwt-2.0.0-rc1.zip 4) gwt-2.0.0.zip Note that we would always include the RC number, even if there's just one (because you never know if another one is coming). I'm very happy to report that there seems to be no need to change even a single line of code, as best I can tell. (Thank you to whomever wrote the version string parsing code to ignore non-digit prefixes and suffixes.) Thus, by simply following this convention when we set GWT_VERSION in the continuous build, everything should work just fine. -- Bruce P.S. No, Joel, we can't start counting at 0, even though it makes more sense :-) I can read your mind. -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases
Senator Blum, Do you mean disturbing as in 1) revolting, 2) distressing, or 3) disordering? It seems that mathematics has successfully survived similar notational issues, such as the whole X vs. X' thing. Willing to give it a chance? On Wed, Aug 12, 2009 at 4:47 PM, Scott Blum sco...@google.com wrote: I find the fact that 2.0.0 is now ambiguous to be disturbing, admiral. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases
The version update notification thing is admittedly a problem, and so it's true we maybe would need to tweak that. Not changing code most certaily wasn't the justification for the naming scheme I proposed (slap me the day I let that be a reason to justify a lame approach). Alternate proposals, naysayers? On Wed, Aug 12, 2009 at 6:49 PM, John Tamplin j...@google.com wrote: On Wed, Aug 12, 2009 at 6:39 PM, Bruce Johnson br...@google.com wrote: Senator Blum, Do you mean disturbing as in 1) revolting, 2) distressing, or 3) disordering? It seems that mathematics has successfully survived similar notational issues, such as the whole X vs. X' thing. I dislike the fact that normal ordering rules do no apply here. For example, you promoted the fact that version checking code doesn't have to change, it does -- otherwise, you won't get prompted to upgrade from 2.0.0-rc1 to 2.0.0. I would also prefer 2.0.0-ms1 rather than -m1 for better clarity and symmetry with -rc1. Willing to give it a chance? I don't feel strongly enough to fight hard for something different, but I would prefer having a straightforward comparison do the right thing. We can certainly make the comparator understand the particular naming scheme, but that doesn't do well when/if we decide to change it (as it happens, that isn't a problem for older versions but it might be for future versions if we change the scheme). -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DTO compiler optimization
There's sometimes an important difference between the kind of object model
that is appropriate to send to the client and one you'd use on the server.
That's the reason we haven't historically tried to make it easier to do
no-brainer sharing of server-side object models to the client (i.e.
because it seems likely on average there would be way too much wasted data
transferred, which would lead to slowness). Clearly, you see that issue,
too, based on your suggestion.
How well would the transient keyword or the @GwtTransient annotation
satisfy the use case you gave?
On Mon, Aug 10, 2009 at 1:10 PM, Nathan Wells nwwe...@gmail.com wrote:
I have hesitated to bring this up, since I'm relatively new to GWT,
and I would hate to waste anyone's time with explaining what is
hopefully common knowledge to me.
Specifically, I thinking about the DTO problem. I think the general
opinion about DTOs is that they are a necessary evil when working with
GWT. And let me say, they are a very minor blemish on a life-saving
framework. But, It seems to me that the problem has a more elegant
solution. I would propose that all we need to do is increase the
granularity of GWT compiler control.
For clarification, I would like to be able to tell the compiler at the
class member level (either through annotations or *.gwt.xml) what
should be client-side and what should be server-side. As an example,
compiling the following class wouldn't be a problem:
class Foo implements Serializable {
@ServerOnly
static long serialVersionUID = 325490285;
//default, of course compiles to java byte-code and js.
String bar;
@ServerOnly
void setBar(String bar) {
//a method which might reference un-emulated JRE classes
}
String getBar() {
return bar;
}
}
I hope that makes sense... that way, our the same class could be used
on server and client side. Hurray for OO!
Again, I'm sure there are some unforeseen consequences of this design,
not the least of which is the possibility that it would require
basically rebuilding the GWT compiler. I'm just hoping that this
discussion might answer other n00b questions in the future :)
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Prettier GWT version names for upcoming 2.0 releases
Mostly, this writeup is aimed at people who have been working on GWT's own build-related stuff, but if anyone else has objections, now would be a good time to raise them (though it seems unlikely anyone would). In the past, we've never had a good naming scheme for distros other than the general availability distro. For milestones, we used the convention 0.0.rev, which probably scares people off and isn't at all self-descriptive. For RCs and GAs, we used major.minor.bugfix (e.g. 1.5.0 was 1.5 RC1, 1.5.1 was 1.5 RC2, and 1.5.2 was GA). This is all too ad hoc and confusing. Here's the new proposal: major.minor.bugfix (e.g. 2.1.0, 2.1.1, 2.1.2) = This is an official, supported build. Every new minor (or bigger) release would start with a bugfix number of 0. major.minor.bugfix-rcn (e.g. 2.0.0-rc1, 2.0.0-rc2) = This is release candidate build n for the specified upcoming GWT release major.minor.bugfix-mn (e.g. 2.0.0-m1, 2.0.0-m2) = This is milestone build n for the specified upcoming GWT release In other words, the stream of announced code drops for 2.0 will look like this (assuming 2 milestone and 1 rc): 1) gwt-2.0.0-m1.zip 2) gwt-2.0.0-m2.zip 3) gwt-2.0.0-rc1.zip 4) gwt-2.0.0.zip Note that we would always include the RC number, even if there's just one (because you never know if another one is coming). I'm very happy to report that there seems to be no need to change even a single line of code, as best I can tell. (Thank you to whomever wrote the version string parsing code to ignore non-digit prefixes and suffixes.) Thus, by simply following this convention when we set GWT_VERSION in the continuous build, everything should work just fine. -- Bruce P.S. No, Joel, we can't start counting at 0, even though it makes more sense :-) I can read your mind. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add GWT#getUserAgentProperty()
Let me play devil's advocate, at least against the idea of returning the string directly. I fear that making this value easily accessible will encourage people to write conditional tests all over the place, which is brittle (i.e. because we're very subtly locked into particular user.agent values) and less optimal (because it isn't clear that the resulting patterns will optimize well). I guarantee you people will create maps of (user agent string key) = (functor), which will thoroughly default compiler optimizations. Can you talk a bit more about the motivation, so we could consider alternatives? On Fri, Aug 7, 2009 at 10:50 AM, Ray Ryan rj...@google.com wrote: I say where's the unit test? On Fri, Aug 7, 2009 at 7:14 AM, j...@google.com wrote: On 2009/08/07 13:56:08, jlabanca wrote: So there's one problem here: The GWT class is in the Core module, which doesn't (and shouldn't) depend upon the UserAgent module. I think that to get this right, we'll need to do one of the following things: - Add this code to some class in User. Not my favorite option. - Add a new UserAgent module that lives in its own package, so that we can add UserAgent-related stuff to a class there. Perhaps com.google.gwt.ua.UserAgent? - I kind of like this option, because (a) it gets UserAgent out of the user packgage, where it never should have been in the first place, and (b) it gives me a place to put other UserAgent-related methods I need to add. What say you? http://gwt-code-reviews.appspot.com/57804 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Inlining nocache.js
2 requests is very impressive, Arthur! This is the sort of conscientiousness (i.e. for optimizing user experience) I hope all GWT developers would strive for. Nice work. And yes, we'd like to help you get that down to 1, too. On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson arthur.k...@gmail.comwrote: I'd love to see this in the trunk too. We have only 2 round trips on start up now, thanks to ClientBundle. Getting it down to one will be very slick! -- Arthur Kalmenson On Fri, Aug 7, 2009 at 8:41 AM, Cameron Braidcame...@braid.com.au wrote: I'd be keen to see this land in trunk ! Cam 2009/8/7 John Tamplin j...@google.com On Fri, Aug 7, 2009 at 3:51 AM, George Georgovassilis g.georgovassi...@gmail.com wrote: I'd like to save first time visitors that roundtrip to fetch nocache.js. Instead I've declared the module HTML page as non- cacheable (works nice thanks to E-Tag) and moved images and GWT- compiler output to a fully cacheable directory. After inlining nocache.js into the module HTML I had to change the paths to the XYZ.cache.html permutations, but couldn't get RPC to work reliably across all browsers. Is there a way to do this cleanly? There is a Google-internal linker that does this, and will be cleaned up and moved to GWT itself in the near future. I don't know an exact timeframe for this however. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Inlining nocache.js
The best you can do for a cold cache is 2 round-trips (including the host page) if you inline the selection script (.nocache.js) in the host page. You definitely do want the compiled script (.cache.html) *not* embedded in the host page, so that it can have cache forever semantics. Then, when users have a warm cache, it's literally exactly 1 round-trip for the module to start. BTW, once you do inline the selection script, it will be more important to get the HTTP semantics just right. Although it says nocache, the proper semantics are must-revalidate, so typically, the host page won't have changed on the server, and thus it becomes an If-Modified-Since (IMS) request with a Not-Modified (NM) response. In other words, the best case for a warm cache is this 1 round-trip: IMS = NM, which is very cheap because there's no response payload. Your code can start essentially instantly on a decent network. On Fri, Aug 7, 2009 at 11:39 AM, Arthur Kalmenson arthur.k...@gmail.comwrote: Are you counting fetching the host HTML page? With this approach, the selection script is done away with but you still have a fetch for the compiled script so that it can remain permanently cacheable. You could theoretically inline it into the host page, but since none of that is cacheable that would only make sense for very tiny compiled outputs. I don't think firebug counts the initial request to fetch the host page, so two requests. One for the nocache.js and another for the cachable HTML. With the inlining of the nocache.js file, you could get it down to 0 requests if the retrieved page is cached forever. Are you saying to inline the generated JS in the host page too? How could you do that? Don't you need the selector script to pick the correct compiled version? Maybe I'm just not understanding what you mean. 2 requests is very impressive, Arthur! This is the sort of conscientiousness (i.e. for optimizing user experience) I hope all GWT developers would strive for. Nice work. And yes, we'd like to help you get that down to 1, too. Thanks Bruce! But it's really all thanks to Bob's ClientBundle :) -- Arthur Kalmenson On Fri, Aug 7, 2009 at 9:57 AM, John Tamplinj...@google.com wrote: On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: I'd love to see this in the trunk too. We have only 2 round trips on start up now, thanks to ClientBundle. Getting it down to one will be very slick! Are you counting fetching the host HTML page? With this approach, the selection script is done away with but you still have a fetch for the compiled script so that it can remain permanently cacheable. You could theoretically inline it into the host page, but since none of that is cacheable that would only make sense for very tiny compiled outputs. Note that there is a cost, as your host HTML page now can't be cached (since the selection script essentially runs in the server). If your host page is complex, this may be a net loss. You could try leaving it cacheable but setting Vary headers for the pieces that you use to make the decision, but my understanding is that many caches do not handle this properly. Also, you cannot use any deferred binding properties that can't be determined by the HTTP fetch of your host page. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: lightweight events for runAsync in draft mode
On Fri, Aug 7, 2009 at 12:20 PM, Lex Spoon sp...@google.com wrote:
One place I would quibble about is compiler transforms that we
consider to be optimizations, because an optimization should preserve
behavior. Thus, a test case should not have any easy way to be
sensitive to the choice. Going back to the code splitting example, it
would be within spec for the code splitter *not* to generate a
download event for a particular split point, even though it's not that
clever right now. That flexibility makes it very hard to think up an
API for querying the code splitter's settings. Certainly on and
off isn't enough information, at least going forward.
The sorts of compiler optimizations tests I was referring to were
to-be-written tests of complex optimizations where the whole point of the
test is to ensure the compiler is doing exactly the transform we intend it
to. IOW, the sort of stuff Scott is working on testing infrastructure for.
I mostly see your point about the splitter, and in cases like that where you
aren't trying to test the exact decisions/implementation, then it seems
reasonable to have something that's a bit looser. OTOH, one could argue that
it's good to have tests that verify specific behavior that is intended for
the current implementation rather than adherence to the spec.
Would anyone see anything bad, for the narrow code splitting example,
with adding a LWM event saying split point requested, but code
already present? This approach would mean I can finish up the
runAsync LWM patch on Monday or Tuesday.
No objections here, especially if the code already present event is
meaningful for web
mode where indeed the needed code has already been downloaded. That
could be useful thing to know at runtime in production.
Looks good to me. For the short term, how does it strike you to also
have a way to query config and binding properties? While it might not
be what we want in the long run, it looks very practical right now.
For example, disable this test when user.agent=opera. Another
example would be, disable this test if class metadata is off. Given
the near-term state of module specifications, querying the property
looks more direct than needing to define a class that corresponds to
them.
I like the pragmatism, but I fear the repercussions of a intermediate
generalized solution that would encouraged the string literal names of
properties and flags all over client code. I'd rather we switched things
over to The Right Way (whatever we deem that to be) rather than have a
half-done waypoint. However, The Right Thing could be something very
different than what I proposed -- see the JUnit discussion below.
Also, while thinking about how to set up the annotations, or and
and would seem helpful in some cases. Run this test if the agent is
iphone *or* the agent is android. Run this test if the agent is
iphone *and* class metadata is on. So it would be good to include
them, or something equally powerful, in the supported annotations.
My idea here might be considered a hack. I was thinking that and could be
represented as pairs of (to, from) tuples, and that or could be
represented as separate test cases that simply delegate, such as
@RunWhen(Browser.class, Browser_IPhone.class)
public void testIPhone() {
doTestIPhoneOrAndroid();
}
@RunWhen(Browser.class, Browser_Android.class)
public void testAndroid() {
doTestIPhoneOrAndroid();
}
private void doTestIPhoneOrAndroid() {
...
}
Now that I look at it, it's kinda hacky, but then again it may not be very
common. Hopefully not, or we're not doing a good job of creating portable
APIs.
On the downside, using assumeThat() means that the test runner still
has to run the tests. With annotations, the test runner can know
ahead of time which tests are relevant on which platforms. Would our
test runners make good use of that information? Enough to merit the
implementation time and the larger GWT user manual?
I think assumeThat() might indeed be a good general solution, along the
lines of your examples. It subsumes the annotations I proposed, and it's
nice that it could be generalized easily to any sort of tests. Also, it
*might* be possible for the compiler to optimize it statically somewhat such
that if a test contained assumeThat(X) where X was statically know to be
false, the whole method could go away. (Of course, we'd need that behavior
to be generalized somehow -- I'm not proposing JUnit-specific compiler
behavior, which would be way too hacky).
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Questions and concerns with HandlerManager
Are there lots of folks on the list that have the same sorts of feedback on
HandlerManager? I ask because, as a fly on the wall here, this conversation
doesn't sound like it's converging, and I'd like to declare this thread dead
for now so that we can move onto other things. We have a lot of other things
to be giving attention to so that we can get GWT 2.0 out. If we need to
revisit these issues in the future, we certainly can.
-- Bruce
On Fri, Aug 7, 2009 at 4:43 PM, Ed post2edb...@hotmail.com wrote:
class HandlerManagerSource { ... }
Interesting how you put Generics in the HandlerManager
Of course this is a no go area as you explained.
Try my HandlerManager scenario like I described above; only the event
contains the actual source generics, and of course not he
HandlerManager...
Let me know if you want some code of this ? So I can grep something
together... I might need a bit of time for that... and let me know
where to send it to?
To be honest, I'm having a really hard time understanding the structure
you're describing. Maybe a bit of (heavily elided) code would help
clarify
it?
H... I could give some code, but I think in words the need for the
interceptor is clear:
The user selects something and the interceptor will indicate if the
selection is allowed to be committed (like a 2-phase db transaction)
or not..
Can you give me more details about what you not understand here
please?
I am afraid that the code only make it less understandable as it's
complex.. due to the asynchrone behavior.
If you could describe *precisely* what you think should be opened up in
HandlerManager, it would help me to make a reasonable judgment. As it
stands, it all seems very vague to me.
H... can't remember the *precise* details anymore... it was
already some time ago... :(
One thing I remember was that I wanted to change the source in the
HandlerManager, which wasn't possible as it can only be set through
the constructor..
On Aug 7, 10:07 pm, Joel Webber j...@google.com wrote:
On Fri, Aug 7, 2009 at 1:34 PM, Ed post2edb...@hotmail.com wrote:
It costs me a bit to go back in time as these issues are already from
some time back..
Let me try to give some input on these points.
2) I don't fully understand what the problem is here. Could you give
an example that shows that it breaks?
It's actually worse than I thought. If I add a type parameter to
HandlerManager, I get something like
class HandlerManagerSource { ... }
But I have no way to specify the source type when it's declared in
Widget:
class Widget {
HandlerManager??? handlerManager;
}
The Source type parameter would force me to declare a separate
HandlerManager field in each subclass of Widget. But then I can't
subclass a
widget and get the source type correct -- I'd need *another*
handlerManager
field.
3) Ok, let me give an example and hope I have some luck here... ;) I
remember we had this same discussion about primitive-simple Widget
interfaces, you asked me the same thing (together with Bruce), I gave
some concrete interfaces.. and never heard anyting :(...
My app is very simple in layout: a menu on the left and the content on
the right. You can navigate to another piece of content by clicking on
the next/prev button in the content screen part or by clicking in the
menu.
If the user navigates away from the current content screen (by
clicking next/previous... or the menu), and the current shown content
isn't valid, he will be asked for a confirmation. If yes, the action
(=going to the new content and saving the current shown content) will
be performed, if no, the action is canceled and he stays on the same
content screen.
I implement this through an interceptor (aynchrone in this case) that
will take care of the confirmation and some other side-actions. It
makes it clean and transparent.
What I do roughly: I inject the interceptor in the presenter. When the
select value in the model changes it will first inform the interceptor
with a callback. The call back contains different methods that are
called by the HandlerManager implementation to indicate success/
cancelation. In case of success (the user clicks Ok), it will inform
the callback about this such that the property change can be made
permanent. The handlermanager will then inform the listeners and after
that call the callback to indicate that they are all informed
If you need more details, let me know ?
To be honest, I'm having a really hard time understanding the structure
you're describing. Maybe a bit of (heavily elided) code would help
clarify
it?
After describing the above, you might understand that it's desirable
to open up the GWT Handlermanager to add these functionality directly
to it, instead of making a copy and changing it.. Probably this is
need in
[gwt-contrib] Re: Questions and concerns with HandlerManager
Dead! (for now)
On Fri, Aug 7, 2009 at 5:10 PM, Ed post2edb...@hotmail.com wrote:
Then I would declare it dead Bruce!
With all do respect: I do very complex things with GWT and do walk on
his boundaries...
And to my experience - I am a bit lonely out here... (yes I know
it sounds a bit arrogant...)
And yes, I agree that you guys have better things to do to make GWT
first more mature before they support these complex things...
Buttt... it would be nice if these things aren't forgotten and put on
the nice-to-have list... and not on the forget-list.
I think that adding (more) primitive (characteristic) widget/panel
interfaces, like we discussed before has an higher priority, so I hope
you guys add this to gwt 2.0. I am still suprised about the few people
complain about this. But I have pointed out concrete clear cases that
show the need for this...(like you asked before)
Just my thoughts...
BTW: Joe if you want some code about my HandlerManager to be able to
define the source through generics, let me know...
On Aug 7, 10:55 pm, Bruce Johnson br...@google.com wrote:
Are there lots of folks on the list that have the same sorts of feedback
on
HandlerManager? I ask because, as a fly on the wall here, this
conversation
doesn't sound like it's converging, and I'd like to declare this thread
dead
for now so that we can move onto other things. We have a lot of other
things
to be giving attention to so that we can get GWT 2.0 out. If we need to
revisit these issues in the future, we certainly can.
-- Bruce
On Fri, Aug 7, 2009 at 4:43 PM, Ed post2edb...@hotmail.com wrote:
class HandlerManagerSource { ... }
Interesting how you put Generics in the HandlerManager
Of course this is a no go area as you explained.
Try my HandlerManager scenario like I described above; only the event
contains the actual source generics, and of course not he
HandlerManager...
Let me know if you want some code of this ? So I can grep something
together... I might need a bit of time for that... and let me know
where to send it to?
To be honest, I'm having a really hard time understanding the
structure
you're describing. Maybe a bit of (heavily elided) code would help
clarify
it?
H... I could give some code, but I think in words the need for the
interceptor is clear:
The user selects something and the interceptor will indicate if the
selection is allowed to be committed (like a 2-phase db transaction)
or not..
Can you give me more details about what you not understand here
please?
I am afraid that the code only make it less understandable as it's
complex.. due to the asynchrone behavior.
If you could describe *precisely* what you think should be opened
up in
HandlerManager, it would help me to make a reasonable judgment. As it
stands, it all seems very vague to me.
H... can't remember the *precise* details anymore... it was
already some time ago... :(
One thing I remember was that I wanted to change the source in the
HandlerManager, which wasn't possible as it can only be set through
the constructor..
On Aug 7, 10:07 pm, Joel Webber j...@google.com wrote:
On Fri, Aug 7, 2009 at 1:34 PM, Ed post2edb...@hotmail.com wrote:
It costs me a bit to go back in time as these issues are already
from
some time back..
Let me try to give some input on these points.
2) I don't fully understand what the problem is here. Could you
give
an example that shows that it breaks?
It's actually worse than I thought. If I add a type parameter to
HandlerManager, I get something like
class HandlerManagerSource { ... }
But I have no way to specify the source type when it's declared in
Widget:
class Widget {
HandlerManager??? handlerManager;
}
The Source type parameter would force me to declare a separate
HandlerManager field in each subclass of Widget. But then I can't
subclass a
widget and get the source type correct -- I'd need *another*
handlerManager
field.
3) Ok, let me give an example and hope I have some luck here... ;) I
remember we had this same discussion about primitive-simple Widget
interfaces, you asked me the same thing (together with Bruce), I
gave
some concrete interfaces.. and never heard anyting :(...
My app is very simple in layout: a menu on the left and the content
on
the right. You can navigate to another piece of content by clicking
on
the next/prev button in the content screen part or by clicking in
the
menu.
If the user navigates away from the current content screen (by
clicking next/previous... or the menu), and the current shown
content
isn't valid, he will be asked for a confirmation. If yes, the
action
(=going to the new content and saving the current shown content
[gwt-contrib] Re: UIBinder
We're shooting for a milestone drop in a few weeks, and we're planning for an RC by the end of the quarter. But, you know how predicting dates goes... On 8/4/09, Claudemir Todo Bom claude...@gmail.com wrote: is there an ETA for 2.0? On Aug 4, 10:42 am, Ray Ryan rj...@google.com wrote: How does today strike you? It's headed into gwt trunk, and will be part of the 2.0 release. On Tuesday, August 4, 2009, brett.wooldridge brett.wooldri...@gmail.com wrote: Ping. This not this month any more, it's early next. Got a revised (rough) ETA for UIBinder in SVN? I would even love to hear definitely this month, but we don't know when. -Brett On Jul 15, 1:25 am, Ray Ryan rj...@google.com wrote: It's coming RSN. We're trying to get UiBinder into GWT 2.0. It will certainly be in SVN this month or early next. I know I've been saying that for a while, but now we're actually, like, working to make it happen. On Mon, Jul 13, 2009 at 11:05 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: I've read the docs for UIBinder in the wiki, and like everyone else who has read it, I am anxious to start using it. However, even though the doc and examples are in the wiki, I am unable to find the UIBinder code in svn. Is it available? Or can it be made available? Rough or not, documented or not, there are many developers who would like to start playing with it (and helping to fix issues). Thanks Brett --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Async interface black magic
Although it feels less convenient, the async nature of RPC is actually valuable for usability. It forces you to think about what to do in the application UI while a potentially long-running activity is taking place. When you consider that a network round-trip combined with time spent on the server could easily take multiple seconds on average, that's an awful long time to have the UI thread blocked doing nothing. If it were possible to write blocking (or even, seemingly blocking) calls, it would be too tempting to not think about the user experience -- in other words, in most apps the UI would simply hang -- and it's probably prescibing a horrible user experience. On Mon, Aug 3, 2009 at 6:57 AM, John Patterson jdpatter...@gmail.comwrote: On 3 Aug 2009, at 20:53, Miroslav Pokorny wrote: The Async interface is necessary because one does not want to use sync (blocking) rpc calls back to the server. When using blocking calls the entire browser freezes which is especially bad give responses arenot instantwous. I was suggesting the use of continuations to _mimic_ blocking calls but allow the thread to continue. Then from your Java code you would not need to worry about passing in a callback to every service method. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: faster size breakdown with non-fractional billing
Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag more like -style in that it has multiple values rather than having two separate flags? Or is there a rationale for this style that I'm missing. When Bob V's permutation control changes land, we want to make all of this sort of stuff fall into the category of deferred binding properties, so that you could, for example, create one permutaiton with style PRETTY, another with style DETAILED, etc. Having the -soyc flag follow a name/value pattern would make it more amenable to this change. On Mon, Aug 3, 2009 at 8:53 AM, kpro...@google.com wrote: On 2009/07/16 22:28:18, Lex wrote: I think this is a great step forward. This version of Soyc is much more intuitive, and will make it much easier to explain. There are a couple of things that occurred to me, but otherwise it LGTM: 1. Is the detailed output truly a more detailed version of the version that uses JavaToJavaScriptMaps? I think that because of inlining, etc., and the resulting partial billing, you will end up with different cumulative sizes for fragments. This is probably fine, but if I were using Soyc and wanted to get more detailed information, and got different numbers, I would think that there is a bug. How can we set expectations correctly? 2) I'm not the biggest fan of having two compiler flags, -soyc and -soycExtra, but if you are, then it's fine. A few small comments are in the code. http://gwt-code-reviews.appspot.com/51804 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: faster size breakdown with non-fractional billing
Based on what you said, I like a lot as is. Thanks for explaining it. On Mon, Aug 3, 2009 at 2:52 PM, Lex Spoon sp...@google.com wrote: On Mon, Aug 3, 2009 at 1:58 PM, Bruce Johnsonbr...@google.com wrote: Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag more like -style in that it has multiple values rather than having two separate flags? Or is there a rationale for this style that I'm missing. When Bob V's permutation control changes land, we want to make all of this sort of stuff fall into the category of deferred binding properties, so that you could, for example, create one permutaiton with style PRETTY, another with style DETAILED, etc. Having the -soyc flag follow a name/value pattern would make it more amenable to this change. There is no immediate use case for the detailed information. However, I hated to remove all that code when we might need it later. Thus, I left -soyc as the normal use case, and added -XsoycExtra for those use cases that might conceivably need it in the future. It's not a documented option, and it's not listed when you run the compiler with -help. How does that sound, Bruce and Kathrin (and anyone else interested)? It seems very helpful if -soyc is the only option users need to supply. There is even talk of having the -soyc option go ahead and run the dashboard generator, thus giving you final HTML output without needing to add the second step. On a related note, I agree with Kathrin that it's not precisely detailed or extra information that this flag gives you. It's different information, different enough that you can't compute one from the other. I named it extra in a hurry. Can anyone think of anything that would be less misleading? -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Web mode stack traces - propose stackElement.getFileName() return 'JavaScript' instead of 'Unknown'
I prefer Unknown because it's an indication you are looking at suboptimal stack trace output. JavaScript makes it sound like we actually intend for you to be looking at that output, when in fact, you really want to use symbol maps to reverse lookup the Java idents. On Fri, Jul 31, 2009 at 2:42 PM, Fred Sauer fre...@google.com wrote: Web mode stack traces are steadily improving. You can even get line numbers (by inheriting com.google.gwt.core.EmulateJsStack). Without the extra instrumentation you web mode stack traces might look something like this: at Unknown.$NullPointerException() at Unknown.onClick_6() at Unknown.dispatch() at Unknown.$fireEvent() at Unknown.$fireEvent_0() at Unknown.$fireEvent_1() at Unknown.fireNativeEvent() at Unknown.onBrowserEvent() at Unknown.dispatchEventImpl() at Unknown.dispatchEventAndCatch() at Unknown.anonymous() I was thinking it might make slightly more sense if we replaced 'Unknown' with 'JavaScript', e.g. at JavaScript.$NullPointerException() at JavaScript.onClick_6() at JavaScript.dispatch() at JavaScript.$fireEvent() at JavaScript.$fireEvent_0() at JavaScript.$fireEvent_1() at JavaScript.fireNativeEvent() at JavaScript.onBrowserEvent() at JavaScript.dispatchEventImpl() at JavaScript.dispatchEventAndCatch() at JavaScript.anonymous() Anyone have strong opinions wither way? -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Web mode stack traces - propose stackElement.getFileName() return 'JavaScript' instead of 'Unknown'
) On Fri, Jul 31, 2009 at 5:00 PM, Fred Sauer fre...@google.com wrote: I can't wait! On Fri, Jul 31, 2009 at 4:58 PM, Bruce Johnson br...@google.com wrote: 4 cheers for Bob! w00t, w00t, w00t and w00t. Also, note that this is phase 1 in a larger plan. For Bob's next feat of magic, he's going to provide better control over permutations, allowing you to, say, include the (expensive) stack traces below for only a small percentage of users -- as well as all sorts of other cool, unrelated things that involve carving up your permutation space more powerfully On Fri, Jul 31, 2009 at 4:36 PM, Ray Cromwell cromwell...@gmail.comwrote: On Fri, Jul 31, 2009 at 4:33 PM, Fred Sauer fre...@google.com wrote: You get the following, which notably can be pasted into Eclipse's Stack Trace Console view so that the filename:lineNumber pairs become clickable hyperlinks: That's just awesome beyond belief. -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: patch to enable web tests using HtmlUnit
Fantastic! On Thu, Jul 30, 2009 at 1:52 PM, Ray Ryan rj...@google.com wrote: WAHOO! On Thu, Jul 30, 2009 at 1:48 PM, Amit Manjhi amitman...@google.comwrote: Thanks Scott. Commited the changes at r5844 with a fix the first thing and a TODO for the second thing. On Thu, Jul 30, 2009 at 10:48 AM, sco...@google.com wrote: LGTM with nits. http://gwt-code-reviews.appspot.com/54809/diff/1096/1130 File user/src/com/google/gwt/junit/JUnitShell.java (right): http://gwt-code-reviews.appspot.com/54809/diff/1096/1130#newcode220 Line 220: + e.g. IE6,IE7,FF2,FF3...; Could the exact list be gotten from RunStyleHtmlUnit? Then you don't need to update this message if the set of browsers changes. http://gwt-code-reviews.appspot.com/54809/diff/1096/1129 File user/src/com/google/gwt/junit/RunStyleHtmlUnit.java (right): http://gwt-code-reviews.appspot.com/54809/diff/1096/1129#newcode149 Line 149: threads.add(hut); Is there any way to, say, pause here waiting for the other thread to get to an okay state that would could call a successful launch? Might be nice to detect report errors early. http://gwt-code-reviews.appspot.com/54809 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Force emulated stack traces when running JUnit tests?
Yes, I think we would want to. My point is that we also would want to run the non-instrumented code. I have to think there could be subtle downstream behavioral differences (e.g. compiler optimizations that do/don't happen) based on whether the stack trace code is generated. Thus, I'm saying we should test both. On Thu, Jul 23, 2009 at 1:09 PM, BobV b...@google.com wrote: Technically, wouldn't it just mean we should not pin down the value of the deferred binding property that controls it? It would double the number of permutations, tho. But wouldn't we actually want to run the instrumented code, to make sure that the instrumentation itself doesn't break something? -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
GWT 1.7 Now Available
Hi everyone, (Most people are probably already quite aware of the new GWT 1.7 release, but we wanted to send out an official announcement we could pin to the top of the message list.) GWT 1.7 is a minor update that adds better support for Internet Explorer 8, Firefox 3.5, and Safari 4. Each of these new browser versions introduced at least one change that negatively impacted compiled GWT modules, so we recommend that you do update to GWT 1.7 and recompile your existing applications to ensure that they work with the latest versions of browsers. No source code changes on your part should be required. Normally, a minor update such as this would have been named 1.6.5 (the previous latest version of GWT was 1.6.4), but we did add the value ie8 to the user.agent deferred binding property, which could impact projects using custom deferred binding rules that are sensitive to that property. Thus, we went withGWT 1.7 rather than GWT 1.6.5, to indicate that you may need to pay attention to that change. Details are in the release notes. In every other respect, this is just a bugfix release, so in the vast majority of cases, the update-recompile process should be nearly effortless. Download here: http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=GWT+1.7.0 Cheers, Bruce, on behalf of your friendly GWT Team --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
[gwt-contrib] Re: Generators and hosted mode refresh
@Scott: Hasn't there been a subtle shift in this regard? With GWT 1.5, didn't we conclude that loading classes at least for annotations would make the most sense? I think now that we have enhanced the CCL, for deRPC, to delegate to grey area classes that aren't strictly in the client space, maybe we actually could run generators in the CCL. On Wed, Jul 22, 2009 at 10:24 AM, Brian Stoler bsto...@google.com wrote: Hi Scott, Gin uses reflection because it reuses the heavy lifting from Guice, which is not GWT-aware. Seems like both issues could be resolved if generators were loaded in the client code ClassLoader. Is there a technical or philosophical problem with doing so? I can understand it might not be at the top of the priority list right now, but wanted to know if it would be a bad thing if someone were to propose a patch. -brian On Wed, Jul 22, 2009 at 7:20 AM, Scott Blum sco...@google.com wrote: Generally speaking, you do not want to use reflection inside a generator to try to view the client code. That's what TypeOracle is for, that's the supported way of viewing client code. As for the separate issue of modifying and recompiling a generator itself while running, you're right in that we don't explicitly support it. Using unit tests during generator development as you suggest sounds like a good strategy to me. In some cases, you might also get your IDE to do a hot-replace if you modify the code while debugging, but this can be flaky. On Wed, Jul 22, 2009 at 6:45 AM, Alen Vrecko alen_vre...@yahoo.comwrote: Hi, continuing from http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/c65457fa4df351c1 . Sorry for the added garbage could have known better to post it here in the first place. I see generators as en extension to client code therefore I expect them to behave a bit like client code namely refresh recompiles the generator and client class code changes are visible to the generator. As recompiling the generator feature goes maybe it is a bit like fairytale i.e. not really needed. Will just write the unit tests for generators in any case before running the hosted mode and not play with the generator on the fly with change code shutdown-start hosted mode repeat. But seeing the latest class files inside generator is needed for refresh to work in some cases. Sure you can do much with TypeOracle but you can't instantiate the JType. Afaik there is no bridge between a JType and Class type. What do you think? Cheers Alen --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Force emulated stack traces when running JUnit tests?
On Wed, Jul 22, 2009 at 4:57 PM, Scott Blum sco...@google.com wrote: On Wed, Jul 22, 2009 at 4:46 PM, BobV b...@google.com wrote: Should running a web-mode test case always turn on the emulated stack trace code? Would always on mean that it generates code even for browsers that have native stack traces (i.e. FF)? Generally, as much as I hate to say it, it seems we'd want variations of the tests both with and without stack trace code, so that we don't inadvertently break one mode or the other. It is much like -draftCompile in this respect. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWT 1.7 Now Available
Hi everyone, GWT 1.7 is a minor update that adds better support for Internet Explorer 8, Firefox 3.5, and Safari 4. Each of these new browser versions introduced at least one change that negatively impacted compiled GWT modules, so we recommend that you do update to GWT 1.7 and recompile your existing applications to ensure that they work with the latest versions of browsers. No source code changes on your part should be required. Normally, a minor update such as this would have been named 1.6.5 (the previous latest version of GWT was 1.6.4), but we did add the value ie8 to the user.agent deferred binding property, which could impact projects using custom deferred binding rules that are sensitive to that property. Thus, we went with GWT 1.7 rather than GWT 1.6.5, to indicate that you may need to pay attention to that change. Details are in the release notes. In every other respect, this is just a bugfix release, so in the vast majority of cases, the update-recompile process should be nearly effortless. Download here: http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=GWT+1.7.0 Cheers, Bruce, on behalf of your friendly GWT Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
