+1
I think this would be very useful. Indeed it would allow me to simplify my
.gwt.xml files in gwt-log a great deal.
Thanks
Fred Sauer
[EMAIL PROTECTED]
On Tue, Sep 9, 2008 at 5:33 PM, BobV <[EMAIL PROTECTED]> wrote:
> This patch against trunk allows multiple define-property tags for the
> sam
This patch against trunk allows multiple define-property tags for the
same deferred binding property. The second and subsequent definitions
of a property will override the allowable values and undo the effects
of any previous set-value tags. No change will be made to the
existing property-provide
Good thoughts, Ray. The only way to guarantee order is to have a generator
emit a GWT.create() call.
Your other thought about post-pass generation is something Bob's done a lot
of thinking about. Have you read Bob's new proposals on RPC? They include
reference to apis for computing reachability.
This is certainly a welcome improvement, I detailed a similar issue
last year
(http://groups.google.com/group/Google-Web-Toolkit-Contributors/msg/0422bc6f44e950a9)
in which I needed to run accumulate data (in this instance, a bunch of
mappings), and then generate another class that uses this info
I just remembered one trick I think you might get by with until we resolve
this question. There's something involving caching a reference to the
TypeOracle and doing an identity check on it to determine that you're part
of the same compilation. Um, you'd have to check if this is brittle in
post-F
Working on CssResource has shown a limitation in the Generator model
in that there are no provisions to accumulate state between
invocations of a Generator while rebinding a module. The general
problem with assuming stateful Generators is that the lifecycle and
invocation order of Generators ar
One nit. Per the discussion on this thread, it would be best if
StringBufferTest.testStringBuilder() had a call to each of the new
methods.
Otherwise , LGTM.
-Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~-
Hi Miguel,
I would like for you to review this addition of package level javadoc
summary files for Gears.
A gears/src/com/google/gwt/gears/offline/client/package.html
A gears/src/com/google/gwt/gears/client/localserver/package.html
A gears/src/com/google/gwt/gears/client/workerpool
:)
On Tue, Sep 9, 2008 at 4:34 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Edits welcome!
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Edits welcome!
On Tue, Sep 9, 2008 at 4:33 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Probably. Maybe I'm just thinking a slight word tweak would make it
> clearer, like:
> "Although Java arrays cannot be used directly in JavaScript, the helper
> classes"
>
>
> On Tue, Sep 9, 2008 at 4:31 P
Author: [EMAIL PROTECTED]
Date: Tue Sep 9 13:33:36 2008
New Revision: 3641
Modified:
changes/spoon/runAsync/samples/showcase/src/com/google/gwt/sample/showcase/client/content/widgets/CwCheckBox.java
Log:
Load the check box demo synchronously, because it is the first demo used by
default
Probably. Maybe I'm just thinking a slight word tweak would make it
clearer, like:
"Although Java arrays cannot be used directly in JavaScript, the helper
classes"
On Tue, Sep 9, 2008 at 4:31 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> This is an addition. There is a note about Java arrays
This is an addition. There is a note about Java arrays being opaque objects
above in the main part of the doc - do you think that's sufficient?
On Tue, Sep 9, 2008 at 4:17 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Eric, was this an addition, or was there text there before? I think we
> should
Eric, was this an addition, or was there text there before? I think we
should be clear that passing a Java array into JavaScript is not supported,
then we can turn around and suggest the JsArray* classes as an alternative.
On Tue, Sep 9, 2008 at 10:11 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
>
Hello Miguel,
I've combined the conversion of several classes into one patch because of
the overlap.
- PolylineOptions
- PolygonOptions
- Fixed constructor name in PolyStyleOptions.java
- Fixed references to above.
- Changed some references to PolylineOptions to EncodedPolyline... that was
w
Author: [EMAIL PROTECTED]
Date: Tue Sep 9 13:03:15 2008
New Revision: 3640
Modified:
branches/oophm/branch-info.txt
Log:
Fix typo showing incorrect trunk revision.
Modified: branches/oophm/branch-info.txt
==
--- b
Author: [EMAIL PROTECTED]
Date: Tue Sep 9 12:47:45 2008
New Revision: 3639
Added:
branches/oophm/
- copied from r3638, /branches/oophm-tmp-3634/
Removed:
branches/oophm-tmp-3634/
Log:
Update OOPHM branch with newer trunk merge.
--~--~-~--~~~---~--~--
Author: [EMAIL PROTECTED]
Date: Tue Sep 9 12:47:16 2008
New Revision: 3638
Removed:
branches/oophm/
Log:
Remove old oophm branch, will replace with newer trunk merge.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~---
Author: [EMAIL PROTECTED]
Date: Tue Sep 9 12:45:56 2008
New Revision: 3637
Added:
branches/oophm-tmp-3634/branch-info.txt (contents, props changed)
Log:
Add branch-info.txt for updated OOPHM branch.
Added: branches/oophm-tmp-3634/branch-info.txt
=
LGTM!
On Tue, Sep 9, 2008 at 2:37 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Alex,
>
> Could you review this code which adds "clearing " support to date
> box?
>
> Cheers,
>
> Emily
>
>
> --
> "There are only 10 types of people in the world: Those who understand
> binar
Thanks! Committed at 957.
On Tue, Sep 9, 2008 at 2:37 PM, Freeland Abbott
<[EMAIL PROTECTED]>wrote:
> Optional, it might be helpful to have a check that, if both files are
> available, warns you that there're two sources and could be in conflict.
> But it's a cherry; I'm not sure it's worth any r
Alex,
Could you review this code which adds "clearing " support to date
box?
Cheers,
Emily
--
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"
--~--~-~--~~~---~--~~
http://groups.google.co
Optional, it might be helpful to have a check that, if both files are
available, warns you that there're two sources and could be in conflict.
But it's a cherry; I'm not sure it's worth any real effort, so I'm back to
my opening "LGTM".
On Tue, Sep 9, 2008 at 2:10 PM, Emily Crutcher <[EMAIL PROTE
Yep, that was actually deliberate, as it should be the case that any
properties defined locally will trump the default ones, which is as it
should be.
On Tue, Sep 9, 2008 at 2:05 PM, Freeland Abbott
<[EMAIL PROTECTED]>wrote:
> LGTM, but as written if users have both property files the in-project-
LGTM, but as written if users have both property files the in-project-dir
one will "win" on any overlaps, because ant properties are immutable. That
may not be a problem, but I wanted to call it out.
On Mon, Sep 8, 2008 at 11:30 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Adds a check for a
On Tue, Sep 9, 2008 at 1:28 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> I don't understand. If a plugin was found but failed to connect, and we
> call the module load error function, why would we continue iterating through
> the list? Once you've found a plugin that loads, that's the right plugi
On Tue, Sep 9, 2008 at 1:24 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 1:11 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
>
>> What was misplaced about this?
>>
>
> The break needs to happen if a plugin was successfully found rather than if
> an error occurred trying to initi
Author: [EMAIL PROTECTED]
Date: Tue Sep 9 10:24:53 2008
New Revision: 3635
Added:
branches/oophm-tmp-3634/
- copied from r3634, /trunk/
Log:
Create a copy of [EMAIL PROTECTED] to update new OOPHM branch.
--~--~-~--~~~---~--~~
http://groups.google.com
On Tue, Sep 9, 2008 at 1:11 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> What was misplaced about this?
>
The break needs to happen if a plugin was successfully found rather than if
an error occurred trying to initialize it.
> By the way, we're at a point now where changes to the OOPHM branch ne
On Tue, Sep 9, 2008 at 1:12 PM, BobV <[EMAIL PROTECTED]> wrote:
>
> On Tue, Sep 9, 2008 at 10:11 AM, Scott Blum <[EMAIL PROTECTED]> wrote:
> > What was misplaced about this?
> > By the way, we're at a point now where changes to the OOPHM branch need
> to
> > be reviewed.
>
> @John, are getting thi
On Tue, Sep 9, 2008 at 1:09 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> When passing arrays between JavaScript and Java, the helper classes
> JsArray, JsArrayBoolean, JsArrayInteger, JsArrayNumber, and JsArrayStringcan
> be used. These classes are wrappers around a native JavaScript array.
>
LGT
On Tue, Sep 9, 2008 at 10:11 AM, Scott Blum <[EMAIL PROTECTED]> wrote:
> What was misplaced about this?
> By the way, we're at a point now where changes to the OOPHM branch need to
> be reviewed.
@John, are getting this working in your branch with the intent to
merge it into /branches/oophm later
What was misplaced about this?
By the way, we're at a point now where changes to the OOPHM branch need to
be reviewed.
On Mon, Sep 8, 2008 at 7:56 PM, <[EMAIL PROTECTED]> wrote:
>
> Author: [EMAIL PROTECTED]
> Date: Mon Sep 8 16:56:02 2008
> New Revision: 3633
>
> Modified:
>
>
> changes/jat/oop
On Tue, Sep 9, 2008 at 11:53 AM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 10:11 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
>
>> Would you please review the following change I made to the Developer's
>> Guide?
>>
>> Updated the page:
>>
>>
>> http://code.google.com/p/google-w
On Tue, Sep 9, 2008 at 10:11 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Would you please review the following change I made to the Developer's
> Guide?
>
> Updated the page:
>
>
> http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/DevGuideMarshaling?updated=DevGuideMarshaling&ts=1220969310
On Tue, Sep 9, 2008 at 11:38 AM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> Correction -- that's method testStringBuilder(), within StringBufferTest.
> -Lex
>
Ok, I missed that test method -- I was looking for another standlone test
class.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~
On Tue, Sep 9, 2008 at 11:30 AM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 5:53 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
>> Finally, it looks like we are not testing StringBuilder at all -- since
>> StringBuffer no longer delegates to StringBuilder, I think it needs to be
>>
Hey, John, I'll review the patch.
On Mon, Sep 8, 2008 at 5:53 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
> Finally, it looks like we are not testing StringBuilder at all -- since
> StringBuffer no longer delegates to StringBuilder, I think it needs to be
> tested as well to make sure no cut-and
On Tue, Sep 9, 2008 at 9:56 AM, Miguel Méndez <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 9:52 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Sep 9, 2008 at 9:36 AM, Miguel Méndez <[EMAIL PROTECTED]> wrote:
>> > LGTM. Couple of nits:
>> > 103 this could be a switch statement
>>
>
John,
Would you please review the following change I made to the Developer's
Guide?
Updated the page:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/DevGuideMarshaling?updated=DevGuideMarshaling&ts=1220969310
with the following text near the bottom:
"When passing arrays between JavaS
On Tue, Sep 9, 2008 at 9:52 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 9:36 AM, Miguel Méndez <[EMAIL PROTECTED]> wrote:
> > LGTM. Couple of nits:
> > 103 this could be a switch statement
>
> Two of the members turn out to have the same value. Won't that kill
> the switch
On Tue, Sep 9, 2008 at 9:36 AM, Miguel Méndez <[EMAIL PROTECTED]> wrote:
> LGTM. Couple of nits:
> 103 this could be a switch statement
Two of the members turn out to have the same value. Won't that kill
the switch statement?
MISSING_QUERY and UNKNOWN_ADDRESS bothmap to the numeric value 601.
LGTM. Couple of nits:103 this could be a switch statement
34-84 - if you are going to have public static ints, do you still need the
public accessor methods? Should those be private?
On Mon, Sep 8, 2008 at 2:20 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Attached the patch file...
>
> On Mon, S
LGTM
On Mon, Sep 8, 2008 at 3:02 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> This patch was submitted to fix another build break, this time in the
> HelloMaps sample.
>
> -Eric.
>
>
> -- Forwarded message --
> From: <[EMAIL PROTECTED]>
> Date: Mon, Sep 8, 2008 at 3:01 PM
> Subject
44 matches
Mail list logo
