@Sami: Glad to hear it. If you (or anyone else reading this) have a moment
to do so, we'd love for you to take a look at the warning message that
occurs and let us know if you think it will make sense to the overall GWT
user base. Not everybody using GWT even understands war-style apps, so the
[+John Tamplin, lead dev on OOPHM]
@John: Would you have any time to write a short wiki article about how to do
this? It does seem like a good way to help people in the community get
started trying it out.
On Fri, Mar 6, 2009 at 11:13 AM, beelzabub vlov...@gmail.com wrote:
Hi all,
I was
LGTM
On Wed, Feb 25, 2009 at 7:36 PM, rj...@google.com wrote:
Reviewers: bruce,
Description:
GWT issue 434
Please review this at http://gwt-code-reviews.appspot.com/7803
Affected files:
user/src/com/google/gwt/user/client/ui/MenuItem.java
Index: user/src/com/google/gwt/user/client
This needs to be post-1.6 M2.
On Tue, Feb 24, 2009 at 12:34 PM, Scott Blum sco...@google.com wrote:
LGTM, but I'm punting this over to Bruce as far as timing for getting this
in.
2009/2/24 Alex Rudnick a...@google.com
Hey Scott :)
I'd like to add a doctype to our generated web.xml files
I was trying to send request from my machine to a server to get the
infromation provided by the server API. However, I get something like
this when I run the method builder.sendRequest(null, new
RequestCallback() {}
Can any one tell me how can I fix the problem. I have spent the whole
day on
Mind? Heck no! That would be great!
On Wed, Feb 18, 2009 at 5:21 PM, Arthur Kalmenson arthur.k...@gmail.comwrote:
Hello everyone,
I have a fairly complex class that is almost entirely non-GWT specific
aside from a single line that uses GWT's URL.decodeComponent method.
While I rediscovered
This is a very welcome metric. I'd love to see this land (assuming the
algorithm is correct, which I didn't actually check :-)
On Thu, Feb 12, 2009 at 12:21 PM, Lex Spoon sp...@google.com wrote:
Code splitting adds a small challenge for anyone monitoring their
overall code size: overall code
I agree that a handful of metrics like that would be ideal. Two more:
- Min/Max/Avg startup fragment
- Min/Max/Avg of the per-permutation sum of fragments
On Thu, Feb 12, 2009 at 2:04 PM, John Tamplin j...@google.com wrote:
On Thu, Feb 12, 2009 at 1:55 PM, Bruce Johnson br...@google.com wrote
+1 to the concept; need more time to think through the specifics, but it's
needed
On Thu, Feb 12, 2009 at 3:00 PM, Matthew Mastracci matt...@mastracci.comwrote:
Hey all,
I'd like to propose a feature for a future GWT release: JSNI signature
shortcuts.
==
JSNI
In terms of the GWT 1.5 code line, we're very unlikely to actually release a
1.5.4...GWT 1.6 is just around the corner.
On Wed, Jan 21, 2009 at 6:55 PM, Scott Blum sco...@google.com wrote:
Isaac, I would put money on our updating to a newer version of JDT. I'd
find where Lex committed this
This is too much of a one-off thing to consider. Any framework that's
intended to be portable between GWT and Android would have to have a higher
level of abstraction, in which this (and hundreds of other) impedance
mismatches would be necessarily wrapped in adapter code anyway.
On Fri, Jan 16,
DeferredCommand really is, and always has been, meant to be exactly the same
thing as invokeLater(). I do agree with Kelly that the implementation
became heavyweight by being intertwined with IncrementalCommand, and that we
should undo it. (It seemed like a good idea at the time...)
@Lex: Do you
actually produces polymorphic single
impls, allowing you to weed them out.
Does anyone buy that reasoning? An important related question is whether
these things are actually compiler flags or whether they are module
settings. I think they are actually more appropriate as the latter.
-- Bruce
On Wed
On Wed, Jan 7, 2009 at 11:17 AM, John Tamplin j...@google.com wrote:
On Wed, Jan 7, 2009 at 10:48 AM, Bruce Johnson br...@google.com wrote:
Does anyone buy that reasoning? An important related question is whether
these things are actually compiler flags or whether they are module
settings. I
One thing we need to reconcile before it gets away from us: for things like
this (and anticipated additional settings), should these be command-line
compiler flags or module settings?
I am more in favor of using module settings (specifically, deferred binding
properties that the compiler is
Ray, great timing. Bob was just talking about having started a patch to
allow this.
@Bob: care to comment?
On Fri, Dec 12, 2008 at 6:01 PM, Ray Cromwell cromwell...@gmail.com wrote:
So, I've got these JSON formats that I use both in my Android code and
my GWT code. I originally implemented
@Scott: Blame me. I asked Freeland to take this approach because we are
still urgently trying to stabilize the trunk. We'll knowingly suffer the
cost of a yuckier merge, but we definitely can't take any chance of
additional breakages.
On Thu, Dec 11, 2008 at 11:42 AM, Scott Blum sco...@google.com
The way describes is summarizes my perspective, too.
On Mon, Dec 8, 2008 at 2:15 PM, Toby Reyelts [EMAIL PROTECTED] wrote:
There are a lot of ways that you can tweak JProfiler to make it run faster,
depending upon the statistics that you're trying to collect. This is
particularly true for CPU
On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
I've always assumed that 0 wasn't portable and use 10 by convention.
Ideally, you'd want 0 to function like yield(), but I had a nagging
suspicious that some browsers might treat 0 as a NOP (that is, run the
code
Possible dumb point, but do you prefix-pad the fragments with '0'
where necessary? For some reason it's so aesthetically yucky to see
things mis-sorted on the command-line like this:
1.nocache.js
10.nocache.js
2.nocache.js
instead of nicer, like this:
01.nocache.js
02.nocache.js
of
the SOYC data.
I'd like to consider doing this relatively quickly, since there are
some *really* big projects that are having painfully slow compiles
that require lots (and I mean lots) of memory. Improving on this
requires that we see what's going on first.
-- Bruce
Would it make sense to group fragment files under a subdir whose name is the
strong name of the startup script?
A40BE3F0/
A40BE3F0-001.cache.js
A40BE3F0-002.cache.js
A40BE3F0-003.cache.js
On Thu, Dec 4, 2008 at 4:26 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at
What about:
A40BE3F0/
001.cache.js
002.cache.js
003.cache.js
On Thu, Dec 4, 2008 at 6:03 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 5:02 PM, Bruce Johnson [EMAIL PROTECTED] wrote:
Would it make sense to group fragment files under a subdir whose name
On Wed, Dec 3, 2008 at 7:50 AM, [EMAIL PROTECTED] wrote:
To be honest, I wish we would start creating larger .gwt.xml files and
make each one that exists inheritable.
I agree. It was a rookie decision we made early on to over-emphasize
fine-grained module reuse, and, like C header files,
Hey, that's a nice visualization! Using a nice view like that, we can
probably iterate in early 2009 to clean up a lot of this.
(Spoiler alert: I'm going to start advocating hard in 2009 to get rid of
module XML altogether and use package and class annotations instead.)
On Wed, Dec 3, 2008 at
That's great news guys.
On 11/27/08, nicolas.deloof [EMAIL PROTECTED] wrote:
You just precede me to announce this more officially ;)
Charlie Collins join the Mojo.codehaus.org community to merge gwt-
maven plugin with the Mojo one.
Yet some work required to merge the goals / parameters
Minor nit regarding the terminology, probably mostly just aesthetic on my
part. GwtTransient doesn't sound that cool to me.
Could we name it now to align with a more comprehensive effort later related
to more developer control of RPC? For example, what if we called the
annotation @NotSerializable.
That's a great find, Ray.
In terms of ideal product direction, I'd rather consider a flag like that
(at least, one that's documented) as the last resort. Extra options tend to
lead to option-shock, and we don't want people to have to think about things
like that too much.
Instead, I think we
On Tue, Nov 11, 2008 at 10:38 AM, Isaac Truett [EMAIL PROTECTED] wrote:
We've been kicking around the idea of an unsafe but fast compile for
exactly this reason.
I always thought the compile was unsafe already.
Only for things that are truly unaffordable, like null checks on every
object
elimination where it can. :)
-Ray
On Tue, Nov 11, 2008 at 7:54 AM, Bruce Johnson [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 10:51 AM, Isaac Truett [EMAIL PROTECTED]
wrote:
I'm curious what things you're referring to here. Generally, I think
we're
pretty open to more checks
Is this really part of the handler update? If this can wait, let's wait. We
need to wrap up the changes to handlers ASAP.
On Tue, Nov 11, 2008 at 9:37 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
I've managed to convince myself that it would be a trivial amount of work
to introduce a
+1 to Kelly's sentiment
@Ray C: Since you're probably doing more of this highly cross-compilable
code than anyone else, we're keen to get your participation in helping
formalize a set of design rules related to the portability/testability
issue. We definitely don't want to break the rockin' cool
perhaps the solution to the security concern is just to somehow be
more clear what your actual endpoints are as a function of the modules
you've inherited. maybe some sort of click-through acknowledgment? the
compiler could even dump out the list when you compile.
On 10/30/08, Scott Blum [EMAIL
On Sun, Oct 19, 2008 at 1:30 PM, Lex Spoon [EMAIL PROTECTED] wrote:
Ideally hosted mode would use a deferred
command instead of running the callback directly, but deferred
commands are not available in Core, but runAsync *is* available in
Core. I haven't run across a simple solution to this
sorry for the useless spammy reply, but I can help it: this is super
exciting
On Fri, Oct 17, 2008 at 12:24 PM, Lex Spoon [EMAIL PROTECTED] wrote:
Hi, Bob,
Can you be the main reviewer for the merge of the runAsync branch to
the trunk? The attached patch is the outstanding difference
Let's just make this patch available on the issue and not include this in
1.5.3.
On Tue, Oct 14, 2008 at 8:06 PM, Amit Manjhi [EMAIL PROTECTED] wrote:
Hi all,
I have attached a patch for TreeMap Serialization. The patch has been
reviewed by John Tamplin. Most of the code is similar to the
Let's not do this in 1.5.3.
On Wed, Oct 15, 2008 at 12:11 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
If we rename it FastStringMapImpl at the same time that would work. The
rename is useful because people using class-lookup to find gwt utility
classes cannot fail to realize it is an impl
Scott.
Bruce, should I commit it to 1.5.3 or not?
On Wed, Oct 15, 2008 at 12:58 PM, Scott Blum [EMAIL PROTECTED] wrote:
Amit, this patch looks great. I saw a tiny bit of whitespace cheese in 1
or 2 files, but it's fine.
On Wed, Oct 15, 2008 at 12:23 PM, Bruce Johnson [EMAIL PROTECTED] wrote
on are already using -noserver to have full
control over their server config.
Thanks,
Bruce
--~--~-~--~~~---~--~~
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
On Thu, Oct 9, 2008 at 4:01 PM, David G [EMAIL PROTECTED] wrote:
For a while now I've been trying to find an elegant solution to
dynamically load widgets/code into a running GWT application, and
finally I've stumbled across RunAsynch(), which is in the GWT SVN
repository, but has no
) Use bytecode on the server
Just a guess, though. Only the numbers can tell us how to proceed.
-- Bruce
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Thu, Sep 11, 2008 at 6:52 PM, BobV [EMAIL PROTECTED] wrote:
Is it the case that value=a and values=a are equivalent in their
behaviors?
Yes. (At least, I can't think of any reason it shouldn't work that way.)
--~--~-~--~~~---~--~~
Let me play devil's advocate, though in advance I'll admit I'm not sure I
have a good point. But I think I do.
Why shouldn't these simply be normal deferred binding properties? Consider
compiler optimization flags we may want to add in the future. It is quite
possible that you'd want to compile
AFAIK, no one is proposing that set-property changes the set of possible
values. I would certainly argue against that.
The upshot of all this is:
set-property gets another attribute called values that is mutually
exclusive with value:
set-property name=foo value=a/ // set property
you *don't* want to separate them, but
I'd like actually hear them.)
On Thu, Sep 11, 2008 at 6:28 PM, BobV [EMAIL PROTECTED] wrote:
On Thu, Sep 11, 2008 at 10:00 AM, Bruce Johnson [EMAIL PROTECTED] wrote:
Could we list some examples, so that we can refer to this thread in the
future
Sorry, typo. See correction below.
On Wed, Sep 10, 2008 at 10:24 AM, Bruce Johnson [EMAIL PROTECTED] wrote:
I propose instead of allow set-property to have a values attribute as a
mutually-exclusive alternative to the value attribute:
I propose instead to allow set-property to have a values
Hi everyone,
The GWT team is proud to announce that GWT 1.5 is now officially released!
GWT Home:
http://code.google.com/webtoolkit/
Download:
http://code.google.com/webtoolkit/download.html
Announcement:
http://googlewebtoolkit.blogspot.com/2008/08/gwt-15-now-available.html
201 - 247 of 247 matches
Mail list logo
