This is really cool, Bob! It adds a history to each AST node showing
where it came from. Thus, you can track an individual node backwards
through a long series of
Right now, the histories just hold a parent node and a string
description of what changed. Given how it's laid out, though, it
Hey, Scott,
Can I get an LGTM on removing this reference to GWT.java-hosted in
GWT.java? I got a scare when I ran across it this morning. The
capital letters shined right through the fog of morning. -Lex
Index:
On Mon, Oct 6, 2008 at 4:20 PM, Scott Blum [EMAIL PROTECTED] wrote:
How do you clean up dead refs in the entry method, which isn't part of any
class?
Good catch. It sounds like there is a more fundamental problem.
The runAsync entry methods actually are included in a class. Thus, in
some
On Mon, Oct 13, 2008 at 11:40 AM, John Tamplin [EMAIL PROTECTED] wrote:
Lex, do you know what we would need to do to get these exceptions
seirialized properly to the client?
I *think* what needs to happen is that the exception is wrapped in a
declared exception. I haven't checked, but the
Kathrin and I reviewed this together.
In general, this solves an important use case, so let's move forward
on it aside from minor issues.
The following use cases are the ones we could think of:
- Seeing what amount of output code (and in fact the actual code if you
want) corresponds to what
On Wed, Oct 15, 2008 at 2:47 AM, Katharina Probst [EMAIL PROTECTED]wrote:
I would say yes to the equals and compareTo, but I wouldn't consider the
hashCode a blocking issue (although it's the simplest fix...).
The equals and compareTo have the potential to create information loss (for
Cool! LGTU.
-Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Kathrin and I pair reviewed it. LGTU.
The particular choice of which class literal to pass in is probably
not good to get into. They all look fine, and we can iterate over
them based on how the reports look. So that you know,
though, in a few classes there is a kind of
inconsistent choice
On Fri, Oct 17, 2008 at 3:46 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
This is of great concern to me. Is there some fundamental reason why
linkers won't work with multiple fragments, or it is just that there
was an API change and some of the implementations need to be fixed?
For example, I
On Sat, Oct 18, 2008 at 12:33 AM, Ray Cromwell [EMAIL PROTECTED] wrote:
Lex,
I skimmed the CFA code, and I had perhaps a stupid question. I see
that method calls have their targets rescued, but what about
exceptions, either runtime, or explicitly thrown? Is it possible that
a non-local flow
I looked today at making the code splitter work with the cross-site
linker. I got it working, but I had to undo one aspect of the current
implementation, and I'm not sure what the correct change would be.
Specifically, the cross-site linker wraps all of the JavaScript code
into a function and
On Fri, Oct 17, 2008 at 5:40 PM, Lex Spoon [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 3:46 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
BTW, the code that loads the async fragments must be proxy-aware for
this to work. The GadgetLinker
generateScriptInjector/generateStylesheetInjector
On Wed, Oct 29, 2008 at 4:26 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
Lex, I can just hack it for now. Long term, I would prefer a solution
that addresses in a general purpose fashion, the needs of GWT to be
aware of the container it is in, such as the ability to fetch external
resources, or
On Thu, Oct 30, 2008 at 11:28 AM, BobV [EMAIL PROTECTED] wrote:
The cast to (T) is JsVisitor.accept() is necessary for javac 1.5.0_13
as shipped on OS X to compile the code.
Otherwise, LGTM.
Excellent. I put back the (T), with a comment, and committed at revision 3901.
What are your
The version of runAsync that just went into trunk includes a basic
code-splitting strategy from a few weeks ago. This patch adds a
better strategy. Instead of lumping all non-exclusive code atoms into
the initial download, the initial download only includes the initially
needed code.
usingRunAsyncCallback directly. You want the
compiler to know that, within MyModule.runAsync, the call to
cb.onSuccess() will only call the callbacks related to MyModule, not
to any other callback in the system.
Lex Spoon
--~--~-~--~~~---~--~~
http://groups.google.com
On Thu, Nov 6, 2008 at 4:47 AM, Cameron Braid [EMAIL PROTECTED] wrote:
I presume that the __gwtStartLoadingFragment needs to load the fragment into
the same document as the function resides, therefore the $doc.createElement
should probably be changed to document.createElement
That sounds
On Sat, Nov 8, 2008 at 10:41 AM, Toby Reyelts [EMAIL PROTECTED] wrote:
Are there not larger issues here that need to also be resolved? For
example, don't generators need to be able to generate server code? I'm also
confused as to what really separates generators and linkers in terms of
being
On Mon, Nov 10, 2008 at 2:33 PM, Kelly Norton [EMAIL PROTECTED] wrote:
For iframe loading, Cameron's change is correct. We should be loading
code into the document corresponding to our code context and not the
host page context.
Can I consider that an LGTM?
However, I am wondering how this
On Tue, Nov 11, 2008 at 10:50 AM, John LaBanca [EMAIL PROTECTED] wrote:
Do I remember correctly that you have looked at script-loading gymnastics
in the HTML host pages before?
No, I looked into style sheet loading gymnastics while working on the
Showcase so we could load style sheets
On Tue, Nov 11, 2008 at 11:34 AM, BobV [EMAIL PROTECTED] wrote:
Here's a strawman proposal for handling different types of
EmittedArtifacts in the Linker API and how that would interact with a
WAR output format.
Cool.
First, it's great to have a list of the categories of output. There
seem
Thanks, Bob.
List, Bob and I looked at this together. In general it looks great.
Things I want to do:
1. Ponder the overall strategy for starting up worker threads and
communicating with them. It looks odd to me to use the interrupted
thread state to communicate whether workers should shut
On Thu, Nov 20, 2008 at 2:44 PM, Lex Spoon [EMAIL PROTECTED] wrote:
Things for you to do, Bob, by my notes:
Also:
4. Call accept() within the worker thread, not in the main thread that
creates all the workers. That should speed things up a little,
allowing the first JVM that starts to go
I checked about java.home, and as far as I can tell the patch is doing
the right things.
I messed around with the threading logic, and did manage to come up
with something I think is a little easier to reason about. It's not a
huge advantage, but I get paranoid about concurrency bugs, so every
Hey, Bob, I hope your trip back was pleasant. Can you review this patch for me?
What it does is do a better job with static fields. This was spurred
by a bug that occurs for static fields initialized to strings.
While fixing that, it was just as easy to improve static fields
in general. Static
On Thu, Nov 20, 2008 at 1:43 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
Darn it, I hate when inconvenient facts get in the way of a nice theory! As
I did the benchmark and you are right, there is no advantage of | over
||.
For branch prediction in particular, note that a true interpreter
On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum [EMAIL PROTECTED] wrote:
- We ended up going with Lex's ThreadPoolExecutor stuff. Mainly because he
was physically here, and I think both of the TPE-based implementations suck.
Well, we eliminated TPE itself. However, we went with message-passing
Thank you! It's in at revision 4209.
On Wed, Nov 26, 2008 at 5:22 PM, Katharina Probst [EMAIL PROTECTED] wrote:
Two comments:
- in FragmentExtractor, you might want to update the method name of
containsInternedLiterals, because this now works for all kinds of literals,
not just interned
On Mon, Dec 1, 2008 at 3:23 PM, Ray Ryan [EMAIL PROTECTED] wrote:
Lex, given that we're not at all likely to benchmark this obscure method,
did you just suggest that we should stick with | (and document why we're
doing so)?
To summarize, | looks like a good default in cases where the rhs is
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 is the
strong name of the startup script?
A40BE3F0/
A40BE3F0-001.cache.js
A40BE3F0-002.cache.js
A40BE3F0-003.cache.js
Okay, that's two
On Thu, Dec 4, 2008 at 6:14 PM, Bruce Johnson [EMAIL PROTECTED] wrote:
What about:
A40BE3F0/
001.cache.js
002.cache.js
003.cache.js
That's what I was thinking you really meant. -Lex
--~--~-~--~~~---~--~~
Here is an updated version that puts the deferred JS files for each
permutation into a separate subdirectory of deferredjs. That is,
where there used to be a '-', there is now a '/'.
-Lex
--~--~-~--~~~---~--~~
This kind of data is very valuable for sure.
I not sure how much it makes sense to record on a regular basis,
though. It's already pretty easy to modify the compiler to get these
statistics whenever a developer needs them, and I've done so for
several of them in the past. It only takes a few
On Fri, Dec 5, 2008 at 11:02 PM, Bruce Johnson [EMAIL PROTECTED] wrote:
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
Kelly,
Can you review the patch I attached to issue 3121?
http://code.google.com/p/google-web-toolkit/issues/detail?id=3121
In particular, does it eliminate the cruft in the trivial app you
initially tried with, and still leave the app working?
Lex
On Fri, Dec 5, 2008 at 12:28 PM, BobV [EMAIL PROTECTED] wrote:
- Several classes in user/test/.../server/rpc do not compile against
Jetty given the difference in the servlet API in Jetty versus Tomcat.
This is problematic when using an Eclipse project structure that isn't
hamstrung by linked
Hi, this patch records some information that makes the final report
much easier to read. The internal fragment numbers are really
obscure, so the less they show up in the reports, the better.
It looks generally good but I think there should be a few small modifications.
First, it looks like it
On Mon, Dec 15, 2008 at 11:11 AM, Bruce Johnson br...@google.com wrote:
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
On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst kpro...@google.com wrote:
Hi Lex,
I've made all the changes you requested except the first, which we
have decided not to do for now (reason: SourceInfo does not contain a
pointer to the node, so instead we would have to keep JMethod around
In answer to your question, yes, runAsync works, but no, there's no
test case. It would be great if there were, but I don't know how to
fit it into the JUnit infrastructure. It requires testing that an
async event eventually happens.
Can we talk some about the more general design of this
On Mon, Dec 15, 2008 at 4:09 AM, BobV b...@google.com wrote:
I was trying to demonstrate the practical difference that runAsync
would make when compared to a monolithic deployment to someone today,
and there was no simple way to turn off runAsync that wasn't the
On Tue, Dec 16, 2008 at 11:15 AM, Lex Spoon sp...@google.com wrote:
My concern is that there were high hopes that the vast majority of
method calls in a program could actually be known-synchronous. The
problem is that for any operation that might happen asynchronously,
the developer needs
Hey, Kathrin,
When you have recovered enough from your cold, can you review the
attached patch for me? It fixes a problem with runAsync where a field
was only considered live when it is read. Writes didn't count, which
meant it was possible to write to a field before it was loaded! This
On Thu, Dec 18, 2008 at 3:33 PM, Katharina Probst kpro...@google.com wrote:
Hi Lex,
LGTM, with the caveat that you may want to add more tests in the
future (e.g., for load order dependencies).
Thank you! This is committed at revision 4358.
I agree about the more tests
-Lex
,
not on the class itself. But it's a start...)
On Thu, Nov 13, 2008 at 11:30 AM, Lex Spoon sp...@google.com wrote:
Bob, can you review the small attached patch? I can ask others if you
are slammed, but it's small and affects code you are familiar with, so
I thought I'd ask you first
The gwt-dev-*.jar files include a lot of code that GWT depends on but
that should not be directly used by clients of GWT. This can cause
issues for any application that both tries to run the GWT compiler and
also has its own copy of one of these dependencies.
One way to help is to use jarjar to
On Tue, Jan 6, 2009 at 4:30 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Patch(es) not attached, so this is fairly high-level. ;-)
Doh! Attached for real now, with updates.
So long as your patch puts jarjar into tools, and you're just not including
the binary file 'cause patch
Thanks, Freeland!
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/tonicsystems/README.google. And I hate the filename. Suggestions:
Why not just README (or README.txt)?
If
Thanks, all. It's committed at revisions 4414 (tools) and 4419
(trunk) along with the changes that came from Freeland's review.
-Lex
On Thu, Jan 8, 2009 at 3:01 PM, Freeland Abbott
gwt.team.fabb...@gmail.com wrote:
Not explicit in Lex's message, I LGTM'ed his changes based on IM
This is a really great step forward! I'll list my favorite next steps
at the end of the email, but let me say that getting this dependency
information is really great for helping people (a) shrink their code,
and (b) if they are using runAsync, shrink their initial download.
The overall
I'd like to revive this thread from last month and argue for a different spec:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/99a70af45e06ed3d?pli=1
The question there was what a GWT Timer should do with a timeout of 0,
which is currently prohibited. The
On Mon, Jan 12, 2009 at 2:13 PM, Kelly Norton knor...@google.com wrote:
We actually have it, it's called DeferredCommand. Unfortunately, we let its
implementation get too gangled up with another feature called
IncrementalCommand and use of DeferredCommand now generates way too much
code. Many
I have reviewed the JJS parts and the JSORestrictionsChecker part.
That leaves hosted mode (dev/shell).
I like the new rules that allow Java implementations to also exist,
albeit at a performance penalty.
I have one question about the new checking rules: is the check at
JSORestrictionsChecker
Thanks. This LGTM.
Minor things that don't need a re(re)review if you do them:
ControlFlowAnalyzer.recordDependencies is no longer needed; it's
equivalent to dr != null.
The DependencyRecorder interface could be made a static member of
ControlFlowAnalyzer.
Lex
On Fri, Jan 16, 2009 at 11:28 AM, Lex Spoon sp...@google.com wrote:
I'll go download ExtGwt now and try to figure out what's going on. It
really should find an implementing method, but the precise way it
checks must be messed up.
My initial attempt to repro didn't work.
Cameron, what
reproduce it now. I've created an issue to track its progress:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3304
-Lex
Regards
Cameron.
On Sat, Jan 17, 2009 at 9:00 AM, Lex Spoon sp...@google.com wrote:
On Fri, Jan 16, 2009 at 11:28 AM, Lex Spoon sp...@google.com wrote
I'd like runAsync to use XHR for the iframe linker, so that GWT
applications can get timely notification if an async code download
fails for any reason.
I've outlined all the code changes, but there is a remaining question
about how the runAsync support should access XHR. Ten minutes of
reading
On Thu, Jan 22, 2009 at 12:33 PM, Ian Petersen ispet...@gmail.com wrote:
The general plan seems fine to me, although I doubt I'm qualified to comment.
I do have a question regarding the implementation, though. Given that
you first check
if ($wnd.XMLHttpRequest)
and then have the cascading
On Fri, Jan 23, 2009 at 11:09 AM, Lex Spoon sp...@google.com wrote:
Here's the latest patch. Note that it includes an implicit test of
the default impl via StringBufferDefaultImplTest, due to the way the
patch modifies EmulSuiteUnknownAgent.gwt.xml.
Okay, I showed it to Kelly in person
On Fri, Jan 16, 2009 at 4:09 PM, Bruce Johnson br...@google.com wrote:
Can we add a separate suite of automated test invocations for -draftCompile
mode? It would be a nightmare if we had unrecognized breakages in
-draftCompile mode.
I've been thinking about this a few days, and I thought of
to getting XHR and its transitive dependencies available in Core
On specific notes for the patch so far:
On Fri, Jan 23, 2009 at 1:23 PM, John Tamplin j...@google.com wrote:
On Fri, Jan 23, 2009 at 11:09 AM, Lex Spoon sp...@google.com wrote:
Here's the latest patch. Note that it includes
On Tue, Jan 27, 2009 at 1:56 PM, Lex Spoon sp...@google.com wrote:
Thanks, John!
Unfortunately, I just realized that there are more problems getting
XHR available in Core. First, even though HTTPRequest is in package
com.google.gwt.http, HTTPRequestImpl is over in gwt.user.client
Thanks! I have committed it at revision 4539 to
changes/spoon/pending. This will get merged to trunk before too long.
On Sat, Jan 24, 2009 at 1:06 PM, Katharina Probst kpro...@google.com wrote:
The only thing I would change is the name of the current callback when
you traverse the list,
On Wed, Jan 28, 2009 at 3:03 AM, Ray Cromwell cromwell...@gmail.com wrote:
Recently, I've been trying to think about how to (ab)use the runAsync
facility as an efficient means to support third party plugins to be
dynamically linked into a running app, when I ran into the idea of
using
Okay, I have looked through all the tests that -draftCompile affects.
I'll write a full report, but there is one case where opinions would
really help.
The difficult case is that two test cases test that null+null
evaluates to nullnull. With optimization on, this translation is
done within the
On Wed, Jan 28, 2009 at 4:46 PM, Scott Blum sco...@google.com wrote:
That seems bad is it only null literals that evaluate to a number?
Code like this:
String x = staticallyUnevalableNull();
String y = staticallyUnevalableNull();
Window.alert(x + y);
Should produce:
nullnull
Not a
On Sat, Jan 24, 2009 at 7:04 PM, Sami Jaber sami.ja...@gmail.com wrote:
ok, I get it to work, I had to update the webdefault.xml config file located
in jetty.jar in the package org\mortbay\jetty\webapp\
here the diff :
servlet
servlet-namedefault/servlet-name
On Thu, Jan 29, 2009 at 3:41 PM, Ray Cromwell cromwell...@gmail.com wrote:
I just looked at doing this. The first target seems to be in GenerateJavaAST:
I see two general strategies that would get the info on casts:
1. Modify CastNormalizer to simply removes all casts, and see what the
size
On Fri, Jan 30, 2009 at 5:35 PM, Ray Cromwell cromwell...@gmail.com wrote:
On Fri, Jan 30, 2009 at 2:07 PM, Lex Spoon sp...@google.com wrote:
1. Modify CastNormalizer to simply removes all casts, and see what the
size difference is. This behavior would ultimately be settable by a
flag
Scott or Bob, could you thumb wrestle and have the loser review the
patch on this page?
http://code.google.com/p/google-web-toolkit/issues/detail?id=3304
It's a fix to unbreak Ext GWT, which I broke with my addBridgeMethods
patch (issue 3064, r4477). The new patch is less clever and simply
On Wed, Feb 4, 2009 at 12:43 PM, Scott Blum sco...@google.com wrote:
Is this for 1.6 or trunk?
Trunk. It's a fix to revision 4477 from trunk. -Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Mon, Feb 9, 2009 at 1:51 PM, Lex Spoon sp...@google.com wrote:
Jaime, can you review a patch for me? I broke the lightweight metric
reporting for runAsync months ago, and want to fix that. The patch is
attached to issue 3277:
http://code.google.com/p/google-web-toolkit/issues/detail?id
On Mon, Feb 9, 2009 at 3:06 PM, Jaime Yap jaime...@google.com wrote:
I don't think there is.
We could have some simple test setup that inserts a collector function
before the startup script, and makes some loose assertions as to the whether
or not an event was fired, and the rough ordering of
I would like to do a brief case study or two on how code splitting is
working in practice. Studying Showcase has already been helpful, but
Showcase might or might not be a typical application.
Is anyone trying code splitting on an open-source project that would
be willing to have your app's
At long last, I have started a wiki page on how to use GWT.runAsync.
It covers the basics, how to use SOYC to iterate to something better,
and a couple of recommended coding patterns.
http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
Thoughts welcome. Or, gee, it's a wiki. Just
+1 to the whole idea.
Also, for the reasons already given, I agree that ::method looks
better than this::method, which looks better than self::method.
I am not sure it's worth the spec weight to have a lot of variants in
the syntax. The most important thing is to allow * in place of an
entire
On Thu, Feb 12, 2009 at 2:04 PM, John Tamplin j...@google.com wrote:
It would be good to get the initial download size as well, if we are going
to be getting them from the log rather than the output directory.
That's a good idea. I'll also add the permutation's strong name to
the log message,
On Fri, Feb 13, 2009 at 6:04 AM, John Tamplin j...@google.com wrote:
Also, I have been using the largest permutation rather than an average -- I
know it compliations the computation a bit, but would it be reasonable to
give the largest maximum download for all split points?
I just read this
On Mon, Feb 16, 2009 at 12:43 PM, Lex Spoon sp...@google.com wrote:
Which ones should we report? Would anyone object to it only reporting
the max? Keep in mind that ultimately someone who wants something
very specialized is going to have to do their own calculation, anyway.
Okay
On Sun, Feb 15, 2009 at 7:45 AM, codesite-nore...@google.com wrote:
Author: br...@google.com
Date: Sat Feb 14 12:44:48 2009
New Revision: 4734
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/javac/JsniChecker.java
Log:
Fixes broken build introduced in last commit by adding a
The change looks obvious, but I can't trivially test them. Can anyone
who uses the Eclipse project files test this patch and verify that
they work for at least one platform?
A good test would be that, in trunk, the cast in LongFromJSNIChecker
at line 196 is necessary:
// It's just a
On Wed, Feb 18, 2009 at 2:42 PM, Scott Blum sco...@google.com wrote:
Sorry, didn't see this thread, I just put in a change to 1.6 to update those
files.
Excellent, that's even better. -Lex
--~--~-~--~~~---~--~~
On Wed, Feb 18, 2009 at 2:41 PM, Scott Blum sco...@google.com wrote:
That is indeed the problem. But there's no reason to not update the Eclipse
projects.. they should always reflect the state of the ant build files, and
ideally would be updated together in a single commit. I committed a fix
On Tue, Mar 3, 2009 at 11:40 AM, koollx alex.kalinov...@gmail.com wrote:
I would like to start contributing to the project to remove little and
big annoyances and to make it better overall. First little annoyance
on the list - lots of final and private methods in
RemoteServiceServlet, which
For possible amusement, I spent half a day yesterday spelunking into
the world of various ways to install code in a web browser. Details
are here:
http://lexspoon.blogspot.com/2009/03/many-scopes-of-javascripts-eval.html
My initial idea to use window.eval turns out to be terribly
On Thu, Mar 5, 2009 at 5:10 PM, Matt Mastracci matt...@mastracci.com wrote:
function x() {
var a = 3;
return new Function(alert(a); a = 4;);
}
I hadn't thought of that! Unfortunately, the code in question has
definitions like function foo() { ... } that are intended to end
up defined at
Bob, could you look at the updated version of this patch you reviewed
earlier? It addresses some browser quirks as described in the
description
Joel, or anyone, what do you think about the small change to
XMLHttpRequest? It seems that xhr.send(), while standards-mandated,
is not available in
On Mon, Mar 9, 2009 at 2:02 PM, Lex Spoon sp...@google.com wrote:
http://gwt-code-reviews.appspot.com/10803
My bad, I uploaded the previous patch instead of the new one. Here's
the new one:
http://gwt-code-reviews.appspot.com/9807
-Lex
Thanks, John! Comments inline.
On Mon, Mar 23, 2009 at 2:32 PM, John Tamplin j...@google.com wrote:
Checkstyle doesn't require sorted order of fields, since you can have
initialization dependencies, and so our style guide does not require them
being ordered (though for new code I would order
On Tue, Mar 24, 2009 at 6:57 PM, John Tamplin j...@google.com wrote:
On Tue, Mar 24, 2009 at 6:34 PM, Lex Spoon sp...@google.com wrote:
I left it at DEBUG, only for the following reason: the intention is
that people can pick this script size out of their continuous builds.
They'll need
Thanks, John! It's in at r5094 and r5095. Comments inline:
On Thu, Mar 26, 2009 at 4:31 PM, John Tamplin j...@google.com wrote:
Passing the parameter all the way down this way is ugly, but I don't know of
any better ways to do it.
Agreed.
I would prefer the new ArgHandler to be a
Bob, can you review this patch for me?
Currently SOYC can run into some really long file names when
generating output for large packages. The attached patch shortens the
package names to reduce the frequency this happens.
It's likely worth doing such shortening more consistently, but package
I guess I should actually include the patch. Here it is:
http://gwt-code-reviews.appspot.com/16802/show
-Lex
On Fri, Apr 3, 2009 at 6:30 PM, Lex Spoon sp...@google.com wrote:
Bob, can you review this patch for me?
--~--~-~--~~~---~--~~
http
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 warnings, then we can talk about how to put them back
in.
The main thing is that
On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott fabb...@google.com wrote:
The main thing is that many problems are still logged via TreeLogger
and not stored in the ProblemReport. Shouldn't we jump over
consistently to the new system rather than have a mix? Are there any
Probably; I was
5176: All this does is tweak the debug output of the Java AST. JSNI methods
have proper indentation in an AST dump now (I was using AST dumps to verify
incremental correctness.)
LGTM.
5177: Fairly self-explanatory; added the state to JReferenceType, but kept
it in JTypeOracle at first to
Scott, when you get back, can you review this tiny patch, or propose a
different way to solve the problem?
The problem is that when precompiles are sharded, it's not actually
sound to discard all early compilation state in the middle of
precompile(). If this is done, then the next precompile
On Wed, Apr 8, 2009 at 2:51 AM, Freeland Abbott fabb...@google.com wrote:
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
On Wed, Apr 8, 2009 at 11:17 AM, John Tamplin j...@google.com wrote:
On Wed, Apr 8, 2009 at 11:00 AM, Lex Spoon sp...@google.com wrote:
Scott, when you get back, can you review this tiny patch, or propose a
different way to solve the problem?
The problem is that when precompiles are sharded
On Thu, Apr 9, 2009 at 11:27 AM, Scott Blum sco...@google.com wrote:
Oh, a concrete reason occurred to me this morning why we'd rather have the
logic in Precompile.run() that binds using OptionCompilationStateRetained
with OptionMaxPermsPerCompile:
You'd actually like to turn off
1 - 100 of 220 matches
Mail list logo
