On Wed, Jun 13, 2012 at 3:15 PM, Alan Leung acle...@google.com wrote:
On Mon, Jun 11, 2012 at 5:23 PM, skybr...@google.com wrote:
I don't understand this code, but I wonder if there is any way to write
a smoke test for soyc?
I left a TODO for now.
Without challenging Alan's decision here
The workaround is to inject a server dependency on :gwt-dev, aka
gwt-dev.jar, which supplies that class.
It's a side effect of a refector we did recently, but I haven't reviewed
for what made it become necessary where it wasn't before.
On Tue May 29 16:43:48 GMT-400 2012, Jimo
Roughly speaking, the GWT serialization code---specifically, the part of
the generated server stub that serializes your response to send to the
client---is getting a type of object (PersistentBag) that it knows the
client code won't be able to decode, and is stopping as a result.
In this case,
, leading to code bloat *
*
*
Does this have any run-time slow-ness is it just a compile-time slowness ?
Also, does it increase the ultimate size of the generated javascript?
On Wednesday, May 2, 2012 7:35:36 AM UTC-7, Freeland Abbott wrote:
Roughly speaking, the GWT serialization code
Depending on which targets are failing, we also run with FF3, which Thomas
most likely doesn't
On Mon Apr 30 11:10:32 GMT-400 2012, Rajeev Dayal rda...@google.com
wrote:
Thanks, Thomas. I'll take a look and see what's going on in our
environment. I wonder if it's an order-of-execution
:
Ah, thanks - though it's interesting that there'd be a browser-specific
failure in response to this type of change. Thanks for pointing out the
difference though; I'll double-check.
On Mon Apr 30 13:22:34 GMT-400 2012, Freeland Abbott fabb...@google.com
wrote:
Depending on which targets
LGTM
On Mon, Apr 11, 2011 at 11:44 AM, t.bro...@gmail.com wrote:
http://gwt-code-reviews.appspot.com/1355805/diff/6003/user/src/com/google/gwt/user/client/ui/DeckPanel.java
File user/src/com/google/gwt/user/client/ui/DeckPanel.java (right):
Good point. On the wrong machine just now, but I'll do that.
On Sat, Mar 19, 2011 at 11:07 AM, Scott Blum sco...@google.com wrote:
I was thinking you'd want to remove junit.jar from the non-test build path
for gwt-dev.
On Fri, Mar 18, 2011 at 1:52 PM, Freeland Abbott fabb...@google.comwrote
Turns out that ant is already covered: user/build.xml has, in part:
!--
Classpaths added for test cases
--
path id=test.extraclasspath
pathelement location=${gwt.build}/out/dev/bin-test /
etc.
so dev/bin-test is already available. I guess source code wouldn't be, but
Pre-existing non-conforming, but yes, they should all use our jar.
On Mon, Mar 7, 2011 at 4:24 PM, j...@google.com wrote:
LGTM
Why do some of our .classpath entries reference the JUnit jar directly,
and others reference the Eclipse library JUNIT_CONTAINER?
It seems likely that you need to
That timeout means that GWT has launched a browser pointed at itself, to run
the test, but the browser didn't actually connect to us within 60 seconds.
The constant isn't directly configurable, no, but it's not about the size
of your test, just getting that first useful access from the browser
On Fri, Oct 1, 2010 at 12:32 PM, Ed post2edb...@gmail.com wrote:
Thanks for the detailed explanation, that sure helps.
I have seen the timeout message happen due to a compile error in the GWT
code, but you'd see those errors in the log also.
Could it have something to do with issue 4700 ?:
Yep, I'm looking (and apologies!). I'm planning to force-correct svn first,
then troll over the logs to see what went wrong.
I did recently update the script (to support merge metadata for branch
integrations), but that... shouldn't... have affected the textual content of
any given mirror,
r8893 should have the errors corrected. Still no diagnosis.
On Wed, Sep 29, 2010 at 10:43 AM, Miguel Méndez mmen...@google.com wrote:
Thanks for looking into this Freeland.
On Wed, Sep 29, 2010 at 10:41 AM, Freeland Abbott fabb...@google.comwrote:
Yep, I'm looking (and apologies!). I'm
I suppose anyone using dumpSignatures (and I agree, I think it's vanishingly
unlikely, really) would necessarily be developer-qualified to mutate the new
entry point, yes... I'll buy that.
On the checkstyle, I'd thought I knew my alphabet for sorting... _why_
doesn't checkstyle complain? (In
Unfortunately, I think that fixed one build break but moved on to the
next... javax.validation isn't found, 'cause it's not embedded (which I
like) but also isn't on the sample-building classpaths. 'Nother patch
coming...
On Fri, Aug 27, 2010 at 11:09 AM, fabb...@google.com wrote:
LGTM.
I think I fixed this at r8644... building GWT (with ant) will no longer
compile the expenses sample; however, the code for it, including the maven
pom.xml, is incorporated into the distro zip where folks can build it
themselves, with maven, auto-fetching the various dependencies.
I love having
LGTM
On Mon, Jul 12, 2010 at 4:58 PM, Scott Blum sco...@google.com wrote:
On Mon, Jul 12, 2010 at 4:54 PM, fabb...@google.com wrote:
http://gwt-code-reviews.appspot.com/685801/diff/1/2#newcode594
dev/core/src/com/google/gwt/core/ext/typeinfo/TypeOracle.java:594:
return result;
Cool, but is
, 2010 at 11:50 AM, Freeland Abbott fabb...@google.comwrote:
The last sentence was the only thing I was going to add here (except you
included it): I know my first cut is compilation-valid, which I think means
it has to be runtime-valid.
Actually, in my personal app I ran into runtime failures
.
On Mon, Jun 28, 2010 at 4:10 PM, John Tamplin j...@google.com wrote:
On Mon, Jun 28, 2010 at 3:57 PM, Freeland Abbott fabb...@google.comwrote:
So, this becomes a very breaking change if we say we want to go all the
way right: we would have to repackage
The last sentence was the only thing I was going to add here (except you
included it): I know my first cut is compilation-valid, which I think means
it has to be runtime-valid.
I guess we have violent agreement that gwt-servlet should eventually become
just **/shared/** and **/server/**. I can
On Fri, Jun 25, 2010 at 1:23 PM, Amit Manjhi amitman...@google.com wrote:
Thanks for the feedback. Since I already submitted the patch, I will create
follow-up patches for the issues below.
1. The javax validation is just used in the RequestFactory servlet. It is
currently not used by
Right now, if you pore through servlet/build.xml, we build gwt-servlet.jar
by first building the classes for gwt-user, then filtering out a set of
blacklisted packages from it. As we've added things, of course, the secret
blacklist has grown stale, and that explains why some
Well, yes; I'd be happy to go all the way. Consider the proposal a
proposed quick first step...
On Jun 24, 2010 4:19 PM, John Tamplin j...@google.com wrote:
On Thu, Jun 24, 2010 at 4:09 PM, Freeland Abbott fabb...@google.com
wrote:
Right now, if you pore through servlet/build.xml, we build
LGTM from me---I remember we turned it off when htmlunit was all hangy, and
at the time I was lobbying that iwe should at least have a warning saying
hey, nothing to do unless some of the remote properties was set. The
(probably correct) counter that nobody would notice the warning if they
didn't
I'd been tracking down this error, which was initially convolved with some
code I'd added to Hello for an unrelated issue I was tracking with
Kathryn... but I don't have a good explanation why I'm now seeing zero-based
values. But it seems, AFAICT, legit
On Mon, May 3, 2010 at 1:43 PM,
, 10:49 pm, Marko Vuksanovic markovuksano...@gmail.com
wrote:
Ok, I'll just save you some time... :) but will first check if everything
is
ok once the dependencies are replaced...
On Fri, Apr 16, 2010 at 10:46 PM, Freeland Abbott fabb...@google.com
wrote:
I think that's correct
I think that's correct, but we historically have been pretty lazy about
updating our dependencies...
On Fri, Apr 16, 2010 at 4:39 PM, Marko Vuksanovic markovuksano...@gmail.com
wrote:
One more question - why aren't JUnit 4 libraries used? I think junit4
supports junit3 test style? Am I right?
I wanted to ask the list a question, since we've looped back to an old
discussion at
http://code.google.com/p/google-web-toolkit/wiki/ResourceOracle about how to
treat overlapping source modules.
The question is what to do if a GWT App inherits two (or more) modules that
have selective source
On Mon, Apr 12, 2010 at 12:10 PM, John Tamplin j...@google.com wrote:
How would you handle the following:
A: include foo*.java, exclude b*.java
B: include bar*.java, exclude foobaz.java
I am assuming your union would be the following:
- all foo*.java
- all bar*.java
Is that
/)* doesn't do
that.
On Mon, Apr 12, 2010 at 1:53 PM, Freeland Abbott fabb...@google.com wrote:
On Mon, Apr 12, 2010 at 12:10 PM, John Tamplin j...@google.com wrote:
How would you handle the following:
A: include foo*.java, exclude b*.java
B: include bar*.java, exclude foobaz.java
I am
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?)
The solution to that could indeed be a more clever builder: at create()
time, we return the
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
, 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
I was considering making an @Translate annotation for localization, more or
less the flip side of the existing @Generate, to facilitate getting
translation text from systems other than property files.
Basically, @Generate is useful to generate message catalogs as part of your
GWT compile---a
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...)
--
,
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
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
Kathrin, can you review this trivia?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
samplefix.patch
Description: Binary data
pathelement location=src/
On Tue, Nov 10, 2009 at 12:54 PM, Katharina Probst kpro...@google.comwrote:
LGTM
kathrin
On Tue, Nov 10, 2009 at 12:52 PM, Freeland Abbott fabb...@google.comwrote:
Kathrin, can you review this trivia
Certainly having done the work I wouldn't suggest you go back, no.
I think command-line flags are only marginally self-documenting, though,
without an actual command line... now, if we got the Eclipse plugin to have
a nice UI on it
On Wed, Nov 4, 2009 at 1:01 PM, rj...@google.com wrote:
On Tue, Oct 27, 2009 at 11:54 PM, j...@google.com wrote:
http://gwt-code-reviews.appspot.com/86809/diff/1/2#newcode119
Line 119: echo message= or -Dgwt.selenium.hosts, but that's all./
On 2009/10/28 03:00:56, zundel wrote:
I know this is just temporary, but its too bad the top level test
Sorry for the double-file; I got a 500 server error so retried, but it
apparently did the right thing.
On Thu, Oct 29, 2009 at 1:38 AM, fabb...@google.com wrote:
Reviewers: ,
Description:
Two issues here, both arguably ant bugs. Although the scripts have
correct perms, and zip creates a
Grr. You're right, but it's supposed to work with *either* the trunk *or* the
most current, so I'll have to revisit that patch...
On Fri, Oct 23, 2009 at 2:39 PM, j...@google.com wrote:
I thought incubator policy was it needed to operate with the most recent
official release, which is
-C, and updated
the Incubator wiki accordingly. This is okay.
On Fri, Oct 23, 2009 at 11:43 AM, Freeland Abbott fabb...@google.comwrote:
Grr. You're right, but it's supposed to work with *either* the trunk *or
* the most current, so I'll have to revisit that patch...
On Fri, Oct 23, 2009
Trying to let my test-parallelization work have a shorter long pole to gate
timing. But this, although the longest test suite, seems not to make as
drastic a difference as I'd expected---I have to work how to reduce the
infrastructure overhead more.
(@GWTC, even if successful, this is unlikely to
Point, although CPU quotas is only the first of several reasons why
AppEngine would actually be hard to use in practice for this.
Maybe next quarter. (N.B.: that's a joke, neither a commitment nor a
forever-refusal.)
On Tue, Oct 13, 2009 at 4:11 PM, Isaac Truett itru...@gmail.com wrote:
. Still, I've been a dumber idiot than
that on occasion
I was using the ant that came with Eclipse; I tried using the
official, stand-alone one from apache and got the same result. On Oct 5,
12:29 am, Freeland Abbott fabb...@google.com wrote:
Going back to some of your original questions
also shows it:
f_DockLayoutPanel1.addNorth(topPanel, 5,00);
f_SplitLayoutPanel2.addWest(shortcuts, 192,00);
f_SplitLayoutPanel2.addNorth(mailList, 200,00);
On 6 Oct, 18:32, Freeland Abbott fabb...@google.com wrote:
On Tue, Oct 6, 2009 at 2:35 AM, tfga thiago
Going back to some of your original questions:
1. The default behavior is to build cross-platform. If you only care
about the platform you're on, there's a *-one family of targets, and to
leave things like samples and tools behind, a *-dev family. Try ant
dist-dev to make a
At risk of stating the obvious, note that svn/tools (which is commonly in a
sibling directory to your trunk checkout) is not the same as svn/trunk/tools
(which is a child directory of your trunk checkout). Both need to be
up-to-date.
But if Papick got the non-sample code to build, I would have
Ah, sorry. Depending on exactly when you need it, you want the classpath
element of the compile.tests task around line 75, the defined
path test.extraclasspaths around line 35; you might also consider compile
task, circa line 45, though I think you shouldn't need that. Generally,
searching for
Also, is there a reason we can't discard junit.headless from common.ant.xml,
rather than hardcoding it true?
On Thu, Sep 24, 2009 at 3:53 PM, j...@google.com wrote:
LGTM
Reitveld is again acting up -- I couldn't actually view any of the files
but the first and last, but I could get a diff of
Going forward, I think Ray said incubator bits will either migrate into GWT
proper (and be maintained and branched for releases there) or will
languish, so I imagine the advice will gradually become don't use
incubator. I take languish as meaning we'd probably remain stable
against existing
Thanks; submit @r6015
On Wed, Sep 9, 2009 at 3:15 PM, j...@google.com wrote:
LGTM
http://gwt-code-reviews.appspot.com/59804
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Looks like we want a different solution for test.web.htmlunit, but here's
the haltonfailure flag for gwt.junit
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
That's a drag... I hadn't noticed any instances where the main log and child
were interleaved (do we bother to differentiate which parallel child logs
are being used, in such a case?? OOPHM clearly has multiple loggers going,
but it had seemed that within each we had fairly clean separation).
Looks fine... the only comments are pretty cosmetic: changing
checkTypeInstantiable() (and checkArrayInstantiable() also) to return
non-boolean should probably also change its name; something like
computeInstantiability() may be a better name. It also may warrant more
explicit javadoc. It just
Trusting you on those two, LGTM.
2009/8/18 Lex Spoon sp...@google.com
2009/8/18 Freeland Abbott fabb...@google.com:
Looks fine... the only comments are pretty cosmetic: changing
checkTypeInstantiable() (and checkArrayInstantiable() also) to return
non-boolean should probably also change
I think it'd be reasonable. Patches welcome, particularly as you have the
reproduction case. ;-)
On Fri, Jul 24, 2009 at 10:33 AM, mescali...@gmail.com mescali...@gmail.com
wrote:
ok
sorry for all this bugspam
I finally solved this issue.
it turns out that Gentoo has many ant tasks
gwt-dev-*.jar are things that ant should build for you, fairly early (but
after the build-tools directory).
Is there a reason you're setting the classpath and all those -lib flags to
ant? It should just find them, using $GWT_TOOLS.
I suspect (but am not certain) the -lib's explain all of your
So, today we build user, and then make gwt-servlet.jar from a fairly random
subset of the compiled class files from user.
I say fairly random because we exclude things that are required by other
classes we include, e.g. resources/rg needs StringSourceWriter which is
excluded by a **/rebind/**
As people use dist-dev, they're more likely to have samples unbuilt (i.e. no
build/out/samples/...).As checkstyle is now fatal, and becoming part of
top-level tests, checkstyle will tend to run in unbuilt samples.
Today, this is Bad. But with this fix, it may become Happy. Or it may
Explode.
Revised for the slightly larger goal of allow 'ant clean presubmit' to
work, not merely checkstyle... apicheck requires that tools be built, and
the more minimalist targets buildonly and dist-dev do not do that.
On Fri, Jul 10, 2009 at 3:25 PM, Freeland Abbott fabb...@google.com wrote
Thanks for comments, all... Ben's seems most directly focused: yes, that
probably is better!
Amit, I'm embarrassed to admit I hadn't remembered that Scott added a test
case, so it's un-patched. Patch rejected for that reason, as well as Ben's
correction.
On Wed, Jul 8, 2009 at 10:49 AM, Amit
Yes, and this sort of thing makes me nervous. If we assume line separation
and no-space URL presentation, we can get the URL root and branch bits by
looking for URLs without watching for any tags, and assigning the one ending
in /svn to root. I don't see a way to do the revision, though.
Which
. For that matter, RTL languages would probably mess with the URL
matches for those, too. :-/
Is it worth trying to catch those cases?
On Tue, Jul 7, 2009 at 9:58 PM, Freeland Abbott fabb...@google.com wrote:
Yes, and this sort of thing makes me nervous. If we assume line separation
and no-space
On Sat, Jul 4, 2009 at 12:36 PM, BobV b...@google.com wrote:
Thanks for taking a look. I've updated my client.
I think the dev/ comments have been subsumed by the latest version of
the patch at:
http://gwt-code-reviews.appspot.com/46801/show
Yeah, I think so too.
All other comments
- generally, there's several line-wrap changes; did you mean them? Some
seem to be desirably shortening very long lines, but a few length lines
(E.g. javadoc in JDeclaredType l104:106). Minor, though.
- unqualified TODO at GenerateJavaAST:2980, what are you
promising/offering to
Yep. It'll be looking for English-language regexp matching. Rather than
commenting out the lines, you may be able to win by defining gwt.svnrev and
gwt.svnrev.file in a local.ant.properties file at the top level... although
it looks like that might not work, we can easily modify the svninfo task
On Wed, Jun 24, 2009 at 7:34 AM, Surya master...@gmail.com wrote:
Hi ,
I am fairly new to GWT and my requirement needs a glasspanel to be
used. But due to the heavy size of incubator.jar file i would like to
Heavy size in what sense? You're aware that only the classes you touch
will be in
My +1 in general. On Katharina's point, is it practical to just add a note
to the HTML output, rather than looking for a code change, to the effect of
some small methods may have been inlined away, perhaps citing an option
(-XsoycExtra, I see in the patch? Or maybe an option to -soyc, like
FWIW, Dan Rice has also been working on this, if you hadn't seen his review
thread from Friday.
On Mon, Jun 29, 2009 at 6:14 AM, bruno bruno.marches...@gmail.com wrote:
Hi Lex,
The main problem comes from enhancement added fields, so user can add
@GwtTransient annotation on it.
Yes,
ant test should do it. What platform and JVM are you using? Do even the
dev directory's tests fail? (cd dev; ant test will check that, so long
as you've built things like build-tools already.)
The memory limits for GWTTestCase tests (i.e. for user) are set in
trunk/common.ant.xml, currently at
John's second point is perhaps most important: the size of your compile-time
classpath is irrelevent to your deployment. Once compiled, GWT spits out a
collection of javascript files and other resources (from your modules'
public resources, generated resource bundles, RPC serialization policy
Previously, it failed in the checkstyle rule, and didn't even reach the
helpfully explanatory echo. This changes the echo to a fail, and
delays failure a bit, so that we only get the output if there is an error,
but we do get it.
--~--~-~--~~~---~--~~
derived provider for this same
property.
-- Bruce
On Mon, Jun 15, 2009 at 11:03 PM, Freeland Abbott fabb...@google.comwrote:
Revision to the concept, for design review: See
http://code.google.com/p/google-web-toolkit/wiki/DefaultLocaleBinding,
but the short-and-sweet
, but output is uppercase) and some
comments from Eric regarding the presubmit target (which are actually
orthogonal, but since I'm here)
On Tue, Jun 23, 2009 at 11:32 AM, Freeland Abbott fabb...@google.com
wrote:
Previously, it failed in the checkstyle rule, and didn't even
JUnitShell should be getting getCompilerOptions by inheritance from
com.google.gwt.dev.GWTShell, which means also from gwt-dev-${os}.jar rather
than gwt-user.jar.
If your GWT eclipse Plugin 1.0.1 is the Google Plugin for Eclipse, which
the version number suggests, be aware that it also installs a
Eric, this trivial patch should ensure that Ant's junit crud can't be
fouled up by our parallel testing. Can you review, please?
Index: common.ant.xml
===
--- common.ant.xml (revision 5572)
+++ common.ant.xml (working
FYI, Sujeesh seems to be sending the same question to a lot of us
privately. I've already responded in that vein, including pointing him to
google-web-tool...@googlegroups.com.
On Wed, Jun 17, 2009 at 2:32 PM, John LaBanca jlaba...@google.com wrote:
Some of the other team members might know
to
another directory in the build/out/test tree.
On Wed, Jun 17, 2009 at 5:48 PM, Scott Blumsco...@google.com wrote:
Will this keep those stupid junit.properties files out of our pristine
source tree? That would be awesome if so.
On Wed, Jun 17, 2009 at 11:15 AM, Freeland Abbott fabb
I failed to elaborate on the cleanup suggestions...
- At a minimum, we can make macros for the distinct types, and enforce a
depends= ban that way. I don't know a pretty way to enforce correlation to
content, though (i.e. to say no gwt.ant in this macro body).
- We don't actually
I was talking to Scott about the same optimization, recognizing chains of
methods returning this and inlining them as a block. I haven't looked into
what's involved, though, and promise not to until Thursday at least
On Mon, Jun 15, 2009 at 9:11 PM, Brian Stoler bsto...@google.com wrote:
As I said, I hadn't looked at all into how feasible this was... but I was
hoping to do it by jiggering the Java AST, really, and not the JS one. That
is, I was looking to rewrite the Java from a chained
builder.setA().setB().setC() to multi-statement
builder.setA();builder.setB();builder.setC(),
ourselves to use dist-dev at least
once, to get the distro set, even if you then use buildonly after that to
refresh sources?
On Mon, Jun 15, 2009 at 11:10 AM, Freeland Abbott fabb...@google.comwrote:
Thanks, I'll revisit.
On Mon, Jun 15, 2009 at 10:43 AM, BobV b...@google.com wrote
Bob, John, can you review? This doesn't address the buildonly or dist-dev
as precursor to user/test question, but I think addresses Thomas' and Bob's
other issue.
On Mon, Jun 15, 2009 at 11:47 AM, Freeland Abbott fabb...@google.comwrote:
+GWTC
With regard to the Mac looking for gwt-dev
Bob notes that dist-dev doesn't need (and thus shouldn't have) its
dependency on tools. I take that as tacit agreement that dist-dev can be
the minimally build everything for test execution name.
On Mon, Jun 15, 2009 at 11:53 AM, Freeland Abbott fabb...@google.comwrote:
Bob, John, can you
-*/
with the fallback string, whether empty or otherwise.
- For my default locale use case, our I18N.gwt.xml sets the locale
fallback to default, and user code sets it to something real if the user
doesn't like that.
On Wed, Jun 10, 2009 at 11:49 AM, Freeland Abbott fabb
+1 from me; I did a similar thing in STOB with regard to non-serializable
types.
I also think---though I don't have data to prove---that we often get spam
from classes that happen to be on the classpath, but could be provably
*not* reachable
(even by things like RPC polymorphism), for example from
Ping. Bob, I think you had special interest in this one. ;-)
On Mon, Jun 15, 2009 at 1:27 PM, Freeland Abbott fabb...@google.com wrote:
Bob notes that dist-dev doesn't need (and thus shouldn't have) its
dependency on tools. I take that as tacit agreement that dist-dev can be
the minimally
at 5:47 PM, Freeland Abbott fabb...@google.comwrote:
As of r5537, my no-change ant build takes 1:55 instead of 19:43, and
there's still some easy work to do, albeit with obviously diminishing
returns
Most of that difference is due to a rather annoying timestamp
consideration with directory
Thanks... I think.
On Thu, Jun 11, 2009 at 11:53 AM, Rajeev Dayal rda...@google.com wrote:
Nice job Freeland! You're an ant-master!
On Thu, Jun 11, 2009 at 10:40 AM, Freeland Abbott fabb...@google.comwrote:
Well, if I've saved serious time by 10:30am, I'm happy indeed.
I've got another
Yes, he and I already discussed it. I was initially trying to avoid needing
a new XML tag when the existing one was such a near fit, but the legacy
linker support issues convinced me we needed it.
On Tue, Jun 9, 2009 at 5:37 PM, Bruce Johnson br...@google.com wrote:
I like what jat said.
As of r5537, my no-change ant build takes 1:55 instead of 19:43, and
there's still some easy work to do, albeit with obviously diminishing
returns
Most of that difference is due to a rather annoying timestamp consideration
with directory entries in jars; my patch introduces a new Ant task,
Okay, return !!(node node.specified) works for me...
On Tue, Jun 9, 2009 at 3:06 PM, jlaba...@google.com wrote:
http://gwt-code-reviews.appspot.com/34833/diff/1/2
File user/src/com/google/gwt/dom/client/DOMImplIE6.java (right):
http://gwt-code-reviews.appspot.com/34833/diff/1/2#newcode48
Since we later use outFile.setLastModified(artifact.getLastModified()), thus
ensuring equality, yeah, that = is wrong
On Fri, Jun 5, 2009 at 9:45 AM, Joel Webber j...@google.com wrote:
Agreed, this comparison looks wrong, though it's not immediately obvious to
me how this affects
Well, I did try to use filesonly first. ;-)
Taking the worst-case example of the com/ directory entry from a
hypothetical amalgam of user/build.xml and dev/common.xml's jars, we might
have up five instances of the com/ directory being added to a jar (that
is, sources from src and super, built
with
newer/missing files from each source directory?
On Wed, Jun 3, 2009 at 2:13 PM, Freeland Abbott fabb...@google.com
wrote:
Well, I did try to use filesonly first. ;-)
Taking the worst-case example of the com/ directory entry from a
hypothetical amalgam of user/build.xml and dev
first. Then if we really care, we could update a
custom ant task later that uses timestamp to choose between identicals.
Would that be better or worse than the track we're on now?
On Wed, Jun 3, 2009 at 2:13 PM, Freeland Abbott fabb...@google.comwrote:
Well, I did try to use filesonly first
1 - 100 of 203 matches
Mail list logo
