PROTECTED] wrote:
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
Submitted at r3646.
On Wed, Sep 10, 2008 at 11:14 PM, Freeland Abbott wrote:
I actually looked at the TODO to figure out a way to consolidate most of
that stuff, which would achieve much the same effect. But I decided I
didn't want to expand this patch...
(A subdir of ${project.build
-- Forwarded message --
Date: Thu, Sep 11, 2008 at 12:52 PM
Subject: Re: [gwt-contrib] Re: one-word review for trivial patch in
About.java
To: Google-Web-Toolkit-Contributors@googlegroups.com
Cc: Rajeev Dayal [EMAIL PROTECTED]
Ah, so no longer copying ${project.build} in its
-- Forwarded message --
Date: Fri, Sep 19, 2008 at 11:28 AM
Subject: Re: [gwt-contrib] Re: Proposed API Addition -
TabBar.setTabEnabled(int, boolean)
To: Google-Web-Toolkit-Contributors@googlegroups.com
I think I agree (where would we boot them too, if we had the job? The other
be helpful in some scenarios. Anyone have thoughts on this?
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Fri, Sep 19, 2008 at 11:36 AM, Freeland Abbott
[EMAIL PROTECTED] wrote:
-- Forwarded message --
Date: Fri, Sep 19, 2008 at 11:28 AM
Subject: Re: [gwt-contrib] Re: Proposed
The patch LGTM, and I agree with John that this is an easy fix to an active
problem, so I think that we should do it, even if we also go tweak the
compiler later.
If we assume the compiler fix arrives at some point---that is, that ( + x)
causes x.toString() to be rescued---is there any reason to
:
LGTM, although I only skimmed SvnInfo.java. I would have thought,
however, that Ant would have already had really good process launching
infrastructure. I'm surprised you had to reinvent the wheel with
runCommand().
On Thu, Sep 18, 2008 at 12:01 PM, Freeland Abbott
[EMAIL PROTECTED] wrote
Mostly LGTM. The only (marginally) substantive complaint is that it may
make sense to rework the property parsing around lines 285-293 so that it's
done once, statically, rather than re-parsing the String-int conversion for
every TypeSerializer we create, especially if (as I suggest as a nit) you
On Tue, Sep 30, 2008 at 4:27 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Tue, Sep 30, 2008 at 3:49 PM, Freeland Abbott
[EMAIL PROTECTED] wrote:
Mostly LGTM. The only (marginally) substantive complaint is that it may
make sense to rework the property parsing around lines 285-293 so
LGTM
On Tue, Sep 30, 2008 at 5:26 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Tue, Sep 30, 2008 at 4:51 PM, Freeland Abbott
[EMAIL PROTECTED] wrote:
But, again, it's a nit: my way saves at most ~10b of code size and could
gain or lose a few miliseconds in execution time depending
The format for gwt.svnrev is [EMAIL PROTECTED], and if a real answer can't
be determined it's set to [EMAIL PROTECTED], so I'd rather keep that pattern
consistent instead of the 0 here.
As a bigger change, though, I'd actually suggest pushing the test for .svn
into SvnInfo.java; that already
LGTM, with a minor tweak to the comment to be clearer why it's not a big
deal.
Submitted at r3717.
On Mon, Oct 6, 2008 at 1:46 PM, Mike Aizatsky [EMAIL PROTECTED]wrote:
Freeland,
How's this?
On Fri, Oct 3, 2008 at 6:43 PM, Freeland Abbott
[EMAIL PROTECTED] wrote:
The format
I recently tracked down a problem where a colleague got JUnit to hang
indefinitely with a bad GWTTestCase.
The attached patch aims at closing the front door problem; he had done:
TestSuite.addTest(new MyGwtTestCase())
instead of
TestSuite.addTestSuite(MyGwtTestCase.class);
and, while the
Scott, can you review-or-delegate both this and my earlier review request:
JUnit hang
I just sent a patch up to block sending a bad Test to the client (i.e. to
fail early if the test is unnamed), but that led me to thinking about the
more general how-not-to-hang-on-unspecified-error case.
We send
LGTM.
On Tue, Oct 21, 2008 at 4:31 PM, John Tamplin [EMAIL PROTECTED] wrote:
Please review the following patch, relative to trunk r3728, which fixes a
bug that slipped through when I cleaned up the methodMap sharding in
TypeSerializerCreator to commit to trunk.
--
John A. Tamplin
Thanks. I'm not particularly interested in trying to run a malformed Test
object correctly, so failing usefully is definitely the goal.
If you want to comment on the contentious one---which I'd left on Scott's
plate since I know he has opinions on it---you can dig up the other thread,
'review
:11 PM, Scott Blum [EMAIL PROTECTED] wrote:
Sorry for the delay. Shouldn't we fix the underlying problem, though?
On Fri, Oct 17, 2008 at 1:49 PM, Freeland Abbott
[EMAIL PROTECTED] wrote:
Scott, can you review-or-delegate both this and my earlier review
request: JUnit hang
I just sent
I don't suppose you could attach the fix, to save the next person those ten
minutes? ;-)
On Tue, Oct 28, 2008 at 10:19 AM, Thomas Broyer [EMAIL PROTECTED] wrote:
On 28 oct, 13:51, Isaac Truett [EMAIL PROTECTED] wrote:
Lastly, of course, possibly the best way to get an issue noticed is to
Thanks---I (obviously) hadn't checked the bug record, just this thread. I
didn't want work lost!
On Tue, Oct 28, 2008 at 1:16 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
On 28 oct, 15:44, Freeland Abbott [EMAIL PROTECTED]
wrote:
I don't suppose you could attach the fix, to save the next
I'm good with that.
On Tue, Oct 28, 2008 at 4:26 PM, Ray Ryan [EMAIL PROTECTED] wrote:
So I'd modify my proposal thus:
Parameterized type names should be one capital letter. However, if
readability demands longer names (particularly due to having multiple
parameters), the name should be
Not my hobby horse to ride, but I'm pretty sure the answer is because
interfaces aren't nearly as meta as generics.
If I have an interface, I know certain things about its API, and I know that
my IDE can take me to the definition of that type-contract. If I have a
generic type variable, I know
I find it problematic if there are two equally reasonable assumptions about
what people were trying to do; surely that suggests that making either
assumption will break about half the prior-user population?
(Which I gather is expected to be a very small number, but we aren't sure of
that.)
On
On Mon, Nov 17, 2008 at 1:15 AM, John Tamplin [EMAIL PROTECTED] wrote:
Shouldn't Link.java:157 refer to Link?
Yes; fixed, and thanks.
Won't this mean if you just run the precompile step it will automatically
create one if not specified? I think it should fail if you run the steps
the cleanup interacts poorly with
System.exit (which seems to really exit, right then, and so skip my finally
block)... thus the code duplication in GWTCompiler.main().
On Mon, Nov 17, 2008 at 11:24 AM, John Tamplin [EMAIL PROTECTED] wrote:
On Mon, Nov 17, 2008 at 11:15 AM, Freeland Abbott
[EMAIL
Joel's near-reemergence reminded me of a few low-priority patches I'd sent
his way just before he became more interested in his new daughter than in
us; mostly they're low-priority convenience (to let you add all tests in
this package rather than enumerating them individually), but it uncovered
Clever. I don't see any reason that'd be bad... anybody else?
On Fri, Nov 21, 2008 at 10:38 AM, dflorey [EMAIL PROTECTED] wrote:
So is it an option to let IsSerializable extend the Serializable
marker interface?
On 21 Nov., 16:16, John LaBanca [EMAIL PROTECTED] wrote:
That's a good
I think this was just a typo...
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
treeopen.r4264.patch
Description: Binary data
Since we generate compressed output, wouldn't it be nice to handle it as
input? (We don't seem to need any of the reports but report0.xml[.gz], so
it's just the one stream insertion.)
--~--~-~--~~~---~--~~
Another patch-review for you, sorry: I'm actually a bit surprised that the
prior built, which it did, but I just got a local build error complaining
about tarfileset occurring inside a zip for the windows build... dangers
of too much cut-n-paste.
Patch in-line, as it's so short:
Index:
Submitted; the ant dependency would explain why the builds succeeded
On Tue, Dec 9, 2008 at 4:27 PM, Amit Manjhi [EMAIL PROTECTED] wrote:
LGTM.
I had to make this change myself. (Apparently, this does not happen with
ant 1.7+)
On Tue, Dec 9, 2008 at 11:55 AM, Freeland Abbott
[EMAIL
Without having actually looked at HasValue much, I did get pinged by a
friend of mine who was annoyed that his overridden parameterized getValue()
was now colliding with our String getValue()... looking at CheckBox, perhaps
something like HasValueBoolean would be a better semantic. (It also might
This is going to make our next 1.6 - trunk merge mildly unpleasant, but we
need the 1.6 fixes at c4298 and c4299 'cause we're seeing them in the trunk,
but want minimal other changes until we're sure the current mess around the
confluence of event updates, hosted mode, war mode, AND oophm have
out?
On Thu, Dec 11, 2008 at 12:30 AM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
This is going to make our next 1.6 - trunk merge mildly unpleasant, but
we need the 1.6 fixes at c4298 and c4299 'cause we're seeing them in the
trunk, but want minimal other changes until we're sure
Two semantically-equivalent patches attached: I think we want the following
new packages in the user javadoc set, but they weren't there.
- com.google.gwt.event.dom.client
- com.google.gwt.event.logical.shared
- com.google.gwt.event.shared
- com.google.gwt.debug.client
-
.
On Mon, Jan 5, 2009 at 11:34 AM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Two semantically-equivalent patches attached: I think we want the
following new packages in the user javadoc set, but they weren't there.
- com.google.gwt.event.dom.client
1. Patch(es) not attached, so this is fairly high-level. ;-)
2. So long as your patch puts jarjar into tools, and you're just not
including the binary file 'cause patch can't deal and it's big anyway, that
SGTM. If you're proposing that folks can get jarjar themselves, that
sounds
?
- separately, do we want to put jarjar inside gwt.jar? That would
mean running on more things (soyc-vis, oophm, etc.), which might
actually be
good
On Wed, Jan 7, 2009 at 11:22 AM, Lex Spoon sp...@google.com wrote:
On Tue, Jan 6, 2009 at 4:30 PM, Freeland Abbott
gwt.team.fabb
But in this case we haven't changed it...
On Thu, Jan 8, 2009 at 2:37 PM, John Tamplin j...@google.com wrote:
On Thu, Jan 8, 2009 at 2:23 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Tools patch:
- nitpick (nonblocking): None of the other tools have an analog
to lib
Not explicit in Lex's message, I LGTM'ed his changes based on IM
discussions.
On Thu, Jan 8, 2009 at 2:56 PM, Lex Spoon sp...@google.com wrote:
Thanks, Freeland!
On Thu, Jan 8, 2009 at 2:23 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Tools patch:
nitpick (nonblocking): None
I've actually never had trouble getting a command-line client, but that's
beside the point.
We can make no svn and also not compatible messages be non-blocking
errors, though as I mentioned that raises the question of whether anything
should be blocking... and if not, whether we're getting
, 2009 at 11:00 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
I've actually never had trouble getting a command-line client, but that's
beside the point.
We can make no svn and also not compatible messages be non-blocking
errors, though as I mentioned that raises the question of whether
Actually, given Yann is pulling GWT source code up, and in impl classes at
that, I'm not sure he's in the wrong place... (Although it's true that if
Yann had gone all the way and written up your change into a patch, that'd be
more typical of this forum.)
However, I can't personally say whether
At a speculative guess, Android may be choosing short names to keep the
compiled class files smaller, since they're such a memory-restricted
environment (they also like filenames like R.java to contain what amounts to
a dictionary of resource
At a guess, this will be related to the new event stuff... although that was
supposed to provide (deprecated) compatibility implementations, I'd guess
this is tripping over one that is missing. Still, as Lex says, a compiler
bug also to end with an ICE. ;-)
On Fri, Jan 16, 2009 at 11:28 AM, Lex
-windows-0.0.0 directory as output. Would be nice
to have a revision number there instead.
On Jan 12, 11:00 pm, Freeland Abbott gwt.team.fabb...@gmail.com
wrote:
I've actually never had trouble getting a command-line client, but that's
beside the point.
We can make no svn and also
We've bumped into some problems where the pattern /tmp/gwt-tmp/*
something-unique* fails, because the intermediate gwt-tmp layer has bad
permissions from one user that later block a second user.
I think that was my original error, fwiw, but here's a patch that just cuts
the middle layer... less
For the XSLinker breakage... longer in the digging than the fixing. This is
against *trunk* r4499, although I imagine it's identical in 1.6... in 1.6, I
also wanted to downport the LinkerSuite tests, but I'm getting what I think
is an unrelated break in
@Scott,
Perhaps an exercise in barn door closing, but this patch pulls LinkerSuite
from trunk to 1.6.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Since 1.6 is currently red, I can't prove that it passes. Yet. I'll hold
it 'til I can...
On Tue, Jan 20, 2009 at 10:09 PM, Scott Blum sco...@google.com wrote:
No need to review if it passes and is a clean merge.
On Tue, Jan 20, 2009 at 9:59 PM, Freeland Abbott
gwt.team.fabb...@gmail.com
, is not something programs should have to mess with.
On Tue, Feb 3, 2009 at 11:59 AM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Looks good, but can we make heap and stack be parameters to gwt.junit?
For incubator it may not matter, but when you have a second suite you may
want
, the size is proportional to nothing user visible, just a matter
of how the gwt serialization happened to work, and the number does not
effect performance in any significant way.
On Tue, Feb 3, 2009 at 12:38 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
I'll LGTM either way, since
Plausibly, yes. I'll merge.
On Tue, Feb 3, 2009 at 1:08 PM, Scott Blum sco...@google.com wrote:
Shouldn't this have gone into 1.6?
On Tue, Feb 3, 2009 at 11:15 AM, codesite-nore...@google.com wrote:
Author: fabb...@google.com
Date: Tue Feb 3 08:14:45 2009
New Revision: 4603
Modified:
-- Forwarded message --
From: Freeland Abbott fabb...@google.com
Date: Wed, Mar 11, 2009 at 10:59 AM
Subject: Re: [gwt-contrib] Re: class conflicts during development due to
gwt-dev.jar
To: Google-Web-Toolkit-Contributors@googlegroups.com
As John notes, we did try using jarjar
Sorry for the lag...
1. Why'd you specify branch revision as transient? Not clearly wrong,
just seems unnecessary.
2. You're changing the branch output from my just the last term spec to
full branch path from repo root, right? That's surely more correctly
complete, but may make
, Mar 12, 2009 at 10:22 AM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Sorry for the lag...
1. Why'd you specify branch revision as transient? Not clearly
wrong, just seems unnecessary.
2. You're changing the branch output from my just the last term spec
to full branch path
LGTM. Clearly there could be more tests (e.g. of ...NoErr), but I'm not
going to hold back moving from none to some for that!
On Thu, Mar 12, 2009 at 7:01 PM, Scott Blum sco...@google.com wrote:
Freeland, I decided to stage this in two sequential patches (and commits)
to make it easier to
patch #1 from the previous
one I sent).
I'll go ahead and commit #1.
--Scott, powered by git
On Thu, Mar 12, 2009 at 7:56 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
LGTM. Clearly there could be more tests (e.g. of ...NoErr), but I'm not
going to hold back moving from none
Scott, we already talked about this, but here's the patch for public review.
The basic goal is to surface the native length, sort, push, and shift
operators for JsArrays... I know you mentioned that IE6's push may be slower
than indexed extension, and thus a candidate for deferred binding, but I
, Mar 27, 2009 at 1:28 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Scott, we already talked about this, but here's the patch for public
review.
The basic goal is to surface the native length, sort, push, and shift
operators for JsArrays... I know you mentioned that IE6's push may
As we'd discussed earlier, here's a cut at giving our Style class explicit
accessors for the various property attributes.
(Not that it matters, but the only thing I *really* hate about our
checkstyle alphabetization is that it splits clear/get/setFoo apart. C'est
la vie.)
The for (T x: array) ... use case is precisely what's motivating me, yes; I
don't have any intention of e.g. implementing Iterator.remove(). We allow
that syntax on real Java arrays, but not on JsArrays.
Does returning T[] actually avoid creating an Iterator object, or does it
just create an
Perhaps more directly, exactly what problems are you having?
As John mentioned, you also need to check out the tools directory from
.../svn/tools, typically to a sibling directory of your trunk checkout.
Don't be confused by the tools subdirectory inside your trunk checkout;
they're entirely
Hey Lex,
With regard to
http://code.google.com/p/google-web-toolkit/issues/detail?id=3461, I'd like
you to review the attached patch.
The basic idea is probably the obvious one: record any problems with good
detail, but into a ProblemReport object; we decide later (back at
STOB.build()) whether
Scott,
is this what you were suggesting, to lighten JavaScriptObject.toString() for
micro-apps?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index:
Thanks, Lex!
On Tue, Apr 7, 2009 at 8:01 AM, Lex Spoon sp...@google.com wrote:
This is a big improvement on the logging. I really like the
gist of it. I think it should have a second iteration, though.
I reluctantly agree about dropping most all warnings. Once we have a
way to suppress
Thus, then.
2009/4/6 Scott Blum sco...@google.com
On Mon, Apr 6, 2009 at 9:16 AM, Scott Blum sco...@google.com wrote:
return JavaScriptObject.class.desiredAssertionStatus() ?
toStringVerbose()? : toStringSimple();
(typo, obviously)
return JavaScriptObject.class.desiredAssertionStatus()
On Wed, Apr 8, 2009 at 2:38 AM, Lex Spoon sp...@google.com wrote:
On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott fabb...@google.com
wrote:
There's no special recursion I had to provoke; if you put logging in
instead
of my short circuit, I think DynaTable reconsiders java.lang.String
, but it tests for definition, and
I don't imagine anything else should want that method name). I can make an
in-project utility class to do sort, since Kelly was nervous about setting
an ill-considered trend for JSO functors.
-- Forwarded message --
From: Freeland Abbott fabb
Thanks, Kelly. Apologies for making you find a tree with wi-fi
available
On Wed, Apr 8, 2009 at 8:56 AM, Kelly Norton knor...@google.com wrote:
Internet is alive today in the boonies.LGTM.
/kel
On Wed, Apr 8, 2009 at 3:58 AM, Freeland Abbott fabb...@google.comwrote:
Bruce, with Kelly
Submit @r5200.
On Wed, Apr 8, 2009 at 8:09 PM, Freeland Abbott fabb...@google.com wrote:
Thanks, Kelly. Apologies for making you find a tree with wi-fi
available
On Wed, Apr 8, 2009 at 8:56 AM, Kelly Norton knor...@google.com wrote:
Internet is alive today in the boonies.LGTM.
/kel
It's not included in our distro, which is why we haven't HAD to fix it
since... um... r558. :-/ But it should still build if asked to.
(Amit, I picked you more or less at random, to be a value of !scottb.
Sorry... but it's tiny.)
--~--~-~--~~~---~--~~
Isn't that achieved by the auxiliary warnings? Or do you mean you want them
all listed in the one error message, or am I misunderstandinging the
scenario you describe?
On Thu, Apr 9, 2009 at 3:26 PM, Lex Spoon sp...@google.com wrote:
Thanks!
The overall report layout is a big improvement.
Right, and I also checked that in fact the errors ought to have been caught
anyway.
Validating the tests, will submit (as I think you okayed) when they're
proven still unchanged.
On Fri, Apr 17, 2009 at 2:50 PM, Lex Spoon sp...@google.com wrote:
On Thu, Apr 16, 2009 at 7:02 PM, Freeland
Lines 11-14, I would have just returned svndir.isDirectory() instead of the
if/else, but otherwise looks good to me.
On Mon, Apr 20, 2009 at 1:17 PM, Eric Ayers zun...@google.com wrote:
@Freeland, Scott,
I have an oddball case where I have been using GIT in my project, but not
GIT-SVN. In
Here's the promised follow-on to my earlier, fixing the subtype logging to
be a subtree logger.
I'm still bothered by the multiple entries for E extends java.lang.Object,
but I'm not sure which is the better way to fix it... I think I would like
to change JType constructors and/or .equals, to
Thanks. Typo fixed, submit at r5269.
On Tue, Apr 21, 2009 at 6:27 PM, Lex Spoon sp...@google.com wrote:
LGTM. There's a typo in ProblemReport: accessir.
-Lex
On 4/21/09, Freeland Abbott fabb...@google.com wrote:
Here's the promised follow-on to my earlier, fixing the subtype logging
, Apr 22, 2009 at 1:58 PM, Bruce Johnson br...@google.com wrote:
Would you be willing to drop a before and after example of the output
for those of watching from the stands?
On Wed, Apr 22, 2009 at 1:55 PM, Freeland Abbott fabb...@google.comwrote:
Thanks. Typo fixed, submit at r5269
[+gwtc]
LGTM, although I had to do some work to convince myself it was safe.
You might consider updating the comment; what I find more quickly
understandable and verifiable is something like:
If n32, a[HIGH]/shiftFact is guaranteed to be an integer already. For
n32, a[HIGH]/shiftFact will have
at 2:06 PM, Freeland Abbott fabb...@google.com wrote:
From this patch (the bigger impact is my earlier one, which already had at
least the after form thrashed on), the new, sublogger-using format is:
[java] Compiling module com.google.gwt.sample.broken.Broken
[java]Scanning
Well, that will run emma tests for everyone everywhere who does ant
test...
Does it require anything in particular to work, which people might not have
installed? And is the time significant?
We can easily enough tweak the continuous builder configuration to
explicitly run the emma tests, if
:
It just requires emma.jar which is pulled in from the tools dir. The time
is basically the same as running hosted mode user tests.
Amit
On Thu, Apr 23, 2009 at 10:41 AM, Freeland Abbott fabb...@google.comwrote:
Well, that will run emma tests for everyone everywhere who does ant
test...
Does
On that topic, I've been quietly lobbying to move the svn/tools directory
into svn/trunk/..., although there's already a tools directory (which adds
to the confusion; it's different), so it would have to be named something
else.
I think it'd be a lot simpler for this sort of confusion... but the
the bad test.out value of
default.hosted.emma.tests and also specifically excluding
EmmaClassLoadingTest.class from the long tests.
Amit
On Thu, Apr 23, 2009 at 12:58 PM, Freeland Abbott fabb...@google.comwrote:
Er. Can I take back my approval? It looks like test.hosted already and
also
JavaScriptObject
On Tue, Apr 7, 2009 at 8:13 PM, Freeland Abbott fabb...@google.comwrote:
Thus, then.
2009/4/6 Scott Blum sco...@google.com
On Mon, Apr 6, 2009 at 9:16 AM, Scott Blum sco...@google.com wrote:
return JavaScriptObject.class.desiredAssertionStatus() ?
toStringVerbose
Joel (and John),
Take a look at the attached patch... it's all visibility changes
(moveUp/Down become public, setSelectionStyle protected for test access from
client-code packages), except for a bugfix in selectFirstItemIfNoneSelected
to ensure that there actually is a a first item to select.
. A name like moveSelectionUp/Down() would be more
appropriate.
MenuItem - LGTM
Thanks,
John LaBanca
jlaba...@google.com
On Tue, Apr 28, 2009 at 11:40 PM, Freeland Abbott fabb...@google.comwrote:
Joel (and John),
Take a look at the attached patch... it's all visibility changes
(moveUp
Thanks, submit at 5308.
On Wed, Apr 29, 2009 at 4:08 PM, John LaBanca jlaba...@google.com wrote:
LGTM
Thanks,
John LaBanca
jlaba...@google.com
On Wed, Apr 29, 2009 at 3:55 PM, Freeland Abbott fabb...@google.comwrote:
How's this?
Note there's a small semantic shift: previously
Before I started working up a patch for this, I thought it was worth
floating the basic idea for comment:
I recently wanted an app with special interfaces for mobile browsers
(specificially, iphone and android). No problem; we redefined user.agent to
allow those values, and to provide a property
inheritance. No?
On Tue, May 5, 2009 at 10:16 AM, Freeland Abbott fabb...@google.com wrote:
Before I started working up a patch for this, I thought it was worth
floating the basic idea for comment:
I recently wanted an app with special interfaces for mobile browsers
(specificially, iphone
John,
I noticed that ant buildonly doesn't rebuild the tools directory (which I
care about for soyc, for example)... I think it should, yes?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
, Freeland Abbott fabb...@google.comwrote:
I noticed that ant buildonly doesn't rebuild the tools directory (which
I care about for soyc, for example)... I think it should, yes?
Well, the more things that are added the less useful it becomes for what I
used it for, which was quick builds of the jars
John---
Attached is a proposal---it's missing tests, so it's just a proposal
here---for that default locale issue we were looking at. It's slightly
sideways from your suggestion: instead of not using default at all, this
keeps it in play (figuring that various tools, including our own generators,
Why did I know you'd check in and respond before morning? ;-)
On Wed, May 13, 2009 at 12:34 AM, John Tamplin j...@google.com wrote:
On Tue, May 12, 2009 at 11:12 PM, Freeland Abbott fabb...@google.comwrote:
Attached is a proposal---it's missing tests, so it's just a proposal
here
It's not entirely clear yet that it's going to be implemented, at least
not in bounded time; it's on my personal wish-list to do, but time is short
and that list long.
There's no specific internal need driving it, either; I just got to help
out a project which had decided to make private patches
The issue complains that if you mess up and don't inherit from User,
hosted mode gives you an unexplained NPE:
java.lang.NullPointerException
at
com.google.gwt.core.ext.linker.impl.StandardLinkerContext.init(StandardLinkerContext.java:164)
at com.google.gwt.dev.HostedMode.link(HostedMode.java:452)
So, I'm looking at our ant files, and trying to unwind several problems...
but I figure I'll ask what other people have as pet peeves, to see if there
are other games I should play, too.
Here's what's on my mind right now:
- If you run ant clean build; ant build, the second build should be
widgets)
3. ant platform-jars (fast, incremental build)
Fred
On Wed, May 27, 2009 at 10:38 AM, Freeland Abbott fabb...@google.comwrote:
So, I'm looking at our ant files, and trying to unwind several problems...
but I figure I'll ask what other people have as pet peeves, to see if there
are other
platforms I don't need (at that
moment at least) also takes time that would be nice to avoid. Anyway,
I'll
try buildonly.
Thanks
Fred
On Wed, May 27, 2009 at 11:46 AM, Freeland Abbott fabb...@google.com
wrote:
I think that's about what I'm hoping to make ant build become
Right. Both are supposed to be supported, and therefore should be tested,
but I don't think mine is the only system that balks at $, so as to avoid
quirky shell evaluation behavior. Thus the suggestion to go with overlays.
We could, alternatively, strongly prefer _ instead of $, and either not
harder to
run say the RPC and I18N suites at once.
Rajeev
On Wed, May 27, 2009 at 1:38 PM, Freeland Abbott fabb...@google.comwrote:
So, I'm looking at our ant files, and trying to unwind several problems...
but I figure I'll ask what other people have as pet peeves, to see
1 - 100 of 202 matches
Mail list logo
