Very cool. Bob Vawter and I (and I think a couple more people) worked on
this a long time ago, and there's definitely a lot of room for improvement.
Nice to see someone tackle this!
On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:
Dear fellow GWT users,
I would like to
On Wed, Jul 6, 2011 at 12:07 PM, Eric Ayers zun...@google.com wrote:
So, the tests in the back-end issue are valid, but the GwtAstBuilder patch
is superceded. Could you roll the tests into issue 1470803?
Lemme clarify.
The tests in the back-end are valid tests, which fail both with
On Fri, Jun 24, 2011 at 8:35 AM, zun...@google.com wrote:
So, what you are saying is that we are getting lots of unrelated errors
for units that reference foo that are obscuring the real problem?
The unrelated units are actually causing a blow-up. When we try to
construct the type hierarchy
On Fri, Jun 24, 2011 at 10:02 PM, stephen.haber...@gmail.com wrote:
Sounds good; I was hoping for some kind of for good measure reason
like that. I've been translating GwtAstBuilder/ReferenceMapper to
jribble versions and had to skip over this part because jribble only has
textual ASTs, so
Now that's a good answer! So the real is is just to close the result of
sourceFile.openContents()?
I would update the doc on DiskCache.tranferTo/FromStream that they don't
close the stream, and then look at all the callers and make sure they do the
right thing.
On Fri, Jun 24, 2011 at 10:36 PM,
SGTM, I'll double-check my settings.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
What Eric said. I haven't nailed down all the error reporting yet (although
it's closer now), but the idea is that we really can avoid reporting errors
on unreachable types. And not reaching code means fewer deserialized types,
which is better for memory and takes less time. But there's an even
Don't worry about it, since I'm punting the review over to Jason and Eric.
:P
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LOL
On Sun, Jun 5, 2011 at 1:50 PM, zun...@google.com wrote:
srsly, we don't want this kind of thing to be happening:
http://www.wsbtv.com/news/**28127904/detail.htmlhttp://www.wsbtv.com/news/28127904/detail.html
Be sure to get the one in GwtAstBuilder too. But don't makeChild() there,
just use the existing reference.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
I cannot comment on your proposals because I don't know gwt internals
enough. I decided to add a method to TypeOracle that allows me to ask if
given type comes from Java or Jribble. If it's Jribble I
You wouldn't have to hack TypeOracle. You could just look for your
particular annotation to see what was a Jribble type.
On Sun, May 29, 2011 at 1:47 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
2011/5/29 Scott Blum sco...@google.com
On Sat, May 28, 2011 at 3:41 PM
What John said. Blame Java for the fact that with some lookup oracle, it's
impossible to distinguish the cases. We've always assumed that users would
not use '$' in class names in places where it matters.
That being said, let's assume that a user isn't allowed to have both A.B and
A$B like Toby
On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote:
I don't think that solves the problem -- let's say we store Foo/Bar$Baz
internally and convert it to a source name where needed. How do we know
whether the class name is Bar$Baz or Baz inside of Bar? The problem is
simply
that way. You would always to one-way
conversions from source-binary and never back.
On Fri, May 27, 2011 at 1:01 PM, John Tamplin j...@google.com wrote:
On Fri, May 27, 2011 at 12:53 PM, Scott Blum sco...@google.com wrote:
On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote:
I
I'm not sure what all that means, but shouldn't GPE be able to just turn the
code formatter on automatically?
On Tue, May 24, 2011 at 1:00 PM, Eric Ayers zun...@google.com wrote:
Alex added a new eclipse application to GPE. If you've got his latest
and greatest (not sure if its public yet)
Yeah, sorry. old = what is now committed and new = this patch.
On Fri, May 20, 2011 at 9:41 AM, zun...@google.com wrote:
I'm missing some contect here. I don't know what you mean by 'new' and
old implementations of runAsync. How new is new (this cl? something
already committed or a
something like that when I was doing the JSO CFA overhaul last time.
Also the checks in Pruner are simpler now.
On Fri, May 13, 2011 at 11:37 AM, Scott Blum sco...@google.com wrote:
On Fri, May 13, 2011 at 11:15 AM, Eric Ayers zun...@google.com wrote:
I've been reading the code and talking
On Sat, May 14, 2011 at 9:22 AM, zun...@google.com wrote:
I know I've asked this before, but if code isn't live in the runer, we
replace it with null.nullMethod(), null.nullField or the likes. Why do
we keep this around? Dead Code elimination usually gets rid of it (but
not always?) is it
On Fri, May 13, 2011 at 11:15 AM, Eric Ayers zun...@google.com wrote:
I've been reading the code and talking to Scott about it. The loop
being removed is the while() loop in execImpl(). The jitter is the
fact that the ControlFlowAnalyzer might return one result for liveness
before the
SGTM. At some point I'll have to deal with versioning for the embedded GWT
ASTs, but I can burn that bridge when I come to it.
On Thu, May 12, 2011 at 6:48 PM, zun...@google.com wrote:
I know the paint is still drying on the last patch I submitted for the
Persistent Unit Cache, but no real
On Wed, May 11, 2011 at 10:57 PM, zun...@google.com wrote:
this needs to return a copy. all other implementations of
asCachedCompilationUnit() already return a copy.
That would make CachedCompilationUnit.writeReplace() be weird tho, right?
--
I mean only super-sourced. Does Object come through as
'com/google/gwt/emul/java/lang/Object.java' or merely
'java/lang/Object.java'?
On Tue, May 3, 2011 at 2:56 PM, zun...@google.com wrote:
On 2011/05/03 18:45:15, scottb wrote:
LGTM. Like Toby said, this is much better.
Can you confirm
If the Java MethodInliner kept call counts, I would have special-cased it to
allow inlining the static into the instance when it's the only caller. But
since call counts aren't already computed, I decided it would be best to try
it out as is and see if it actually increases code size in practice.
On Wed, Apr 27, 2011 at 3:20 PM, jbrosenb...@google.com wrote:
If I understand correctly, part of staticification is that all
call-sites to myVar.foo(x) will be replaced by $foo(myVar, x), and thus
foo(x) will be unused, and thus pruned. So, the delegation issues goes
away, no?
Yes, as
It actually does fix the abstract getClass() problem, I was noticing in the
generated output. I'll mark my change as fixing this issue.
On Tue, Apr 26, 2011 at 4:03 AM, t.bro...@gmail.com wrote:
Hey, it looks like it would fix this issue, cool!
Based on your comments, I'm going to rework the patch. You're right, I was
totally confused about the difference between
ReplaceEnumTypesWithInteger ReplaceOrdinalFieldAndMethodRefsWithOrdinal.
I think the JField / JFieldRef replacements in the former are what threw
me. I'll rework the patch.
Yeah, they're in an impl package.
On Tue, Apr 19, 2011 at 11:12 AM, schm...@google.com wrote:
I think the idea here is that no one (outside the existing GWT tests)
should reference the *Resource classes directly - that's why we have the
new interface Source. This way, you should be able to
On Thu, Mar 31, 2011 at 7:38 PM, Eric Ayers zun...@google.com wrote:
It was kind of disruptive to pass the suppressErrors setting around
through method parameters. I assume that's what you're talking about.
Yeah.
The good thing about logging inside of CompilationStateBuilder is that
familiar with the intricacies of
JavaScript, it seems likely that I missed an opportunity to preserve the
nativeness of the array. I'd be happy to take a look at this after the 2.3
release.
On Mon, Mar 28, 2011 at 5:52 PM, Scott Blum sco...@google.com wrote:
Something smells fishy here. I'm
Something smells fishy here. I'm quite certain that this used to be
implemented strictly as a two-double array in web mode, a true array. At
some point it was modified to use 3 elements instead of 2, but I don't think
it should have lost its nativity.
On Mon, Mar 28, 2011 at 5:36 PM,
Thanks, it is really nice for Eclipse testing.
On Fri, Mar 25, 2011 at 9:56 PM, Eric Ayers zun...@google.com wrote:
LGTM
I didn't think maintaining this suite was a priority - the ant build
searches for *Test.java and ignores the suite. I guess if you are
manually testing from eclipse its
On Wed, Mar 23, 2011 at 9:57 AM, zun...@google.com wrote:
If we only write the cache to the same war dir subdirectory, then I
think my concerns with purging the cache are solved (the cache will be
in a well known place). I'm still going to make an exception so that
setting a system property
On Wed, Mar 23, 2011 at 1:02 PM, Eric Ayers zun...@google.com wrote:
FYI: I am adding a call to return the resource location to the
CompilationUnit to handle changing the key.
That's what CompilationUnitBuilder.getLocation() was used for and in
practice, CompilationUnit.getDisplayLocation()
On Mon, Mar 21, 2011 at 10:10 AM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
The problem I described above (broken polymorphic calls) was caused by
superClass field being equal to null for nodes representing
interfaces. That would lead to broken overrides calculations for an
/junitvmwatcher6602185781037387809.properties) missing,
location not writable, testcase not started or mixing ant versions?, which
seemed unlikely to be related to migration of UserTestTreeLogger, especially
with the others passing.
On Fri, Mar 18, 2011 at 1:40 PM, Scott Blum sco...@google.com wrote:
LGTM. Shouldn't
LGTM. Shouldn't some ant build rules want to change, though?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Mon, Mar 14, 2011 at 3:03 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
1. What's the difference between TypeMap and TypeOracle and why they
seem to have overlapping functionality?
In GWT, there are two major pieces of infrastructure that deal with
representing Java
On Mon, Mar 14, 2011 at 4:41 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
So, if my GWT app doesn't have any generators exact contents of
TypeOracle doesn't matter? I'm asking because I'm thinking of creating
some stub data structures for jribble units and just move on to
On Thu, Mar 3, 2011 at 10:04 AM, Eric Ayers zun...@google.com wrote:
After sleeping on the static rogue setter, I don't like it much either and
came up with some alternatives:
1) Would it be more palatable to turn setJavaScriptObjectClass() it into an
instance method? That way, we wouldn't
LGTM
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Thu, Mar 3, 2011 at 12:36 PM, zun...@google.com wrote:
http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
File
dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
(right):
On Thu, Mar 3, 2011 at 1:47 PM, zun...@google.com wrote:
http://gwt-code-reviews.appspot.com/1369805/diff/3001/dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
File
dev/core/test/com/google/gwt/dev/javac/TypeOracleMediatorTestBase.java
(right):
Yay! Submitted!
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Wed, Mar 2, 2011 at 7:21 PM, Eric Ayers zun...@google.com wrote:
@Scott: I was not planning to revert the diff cheese. This uses the
recently updated official gwt-format.xml autoformatting for Eclipse. I've
already volunteered to go through and run the autoformatter to bring
existing
Enums should be almost exactly the same, I think.
On Mon, Feb 28, 2011 at 5:00 PM, Eric Ayers zun...@google.com wrote:
I was trying to think of a way to use enum support (which serializes kind
of compactly), but I don't think it would be any more compact than this.
On Mon, Feb 28, 2011 at
Hi John,
If my question is stupid or makes incorrect assumptions, feel free to
completely ignore me. My question relates to render and how the
SafeHtmlBuilder is constructed:
@Override
public void render(Context context, SafeHtml data, SafeHtmlBuilder sb) {
I bet you could do something like this:
class FooGenerator extends Generator {
private static final Generator impl;
static {
try {
Class? jTypeClass =
Class.forName(com.google.gwt.core.ext.typeinfo.JType);
Class? generatorClass;
if (jTypeClass.isInterface()) {
On Wed, Feb 23, 2011 at 1:16 PM, Toby Reyelts to...@google.com wrote:
I'm concerned about how this might impact logging results. For example,
even if the results are written out on a separate thread (and assuming the
box has an entirely free processor to deal with it), you can still cause the
On Thu, Feb 17, 2011 at 12:22 AM, jbrosenb...@google.com wrote:
Scott makes sense, however, would it not also make sense to have a
signature that can also used by generators to determine whether a type
has changed (and prevent the need for an alternate signature being
maintained for that
On Thu, Feb 17, 2011 at 6:29 PM, Ray Cromwell cromwell...@google.comwrote:
That sounds better, but is there a reason why JavaScriptObjectNormalizer
was doing this pre-optimization in the first place?
I dunno Bob?
Anyway, in favor of keeping the 'null instanceof JSO' behavior is that
On Thu, Feb 17, 2011 at 6:43 PM, Ray Cromwell cromwell...@google.comwrote:
So your proposal is something like this:
setupVtable(castableTypeMap, someSuperCtor, ctor1, ctor2);
function setupVtable(ctm, supCtor) {
var newProto = {};
copyProtoFields(someSuperCtor.prototype,
To give some context, this signature is used for the purpose of deciding if
a class's API has changed... *as far as other Java source files are
concerned for the purposes of running javac*. It has no effect on
TypeOracle or the data presented there, it's not being used to cache old
TypeOracle
On Wed, Feb 9, 2011 at 3:36 PM, cromwell...@google.com wrote:
It is strange, then again, it is strange that a JSO that is null can
still be invoked. :) However, I think I've come back to sanity on
rethinking this. Since it is only used for a single use case in my Json
library (JsonNull), I
Yes, it directly affects SOYC output; it causes tons of useless clinit
dependencies on interfaces to get recorded, when in reality there is no
actual method in the output.
On Fri, Feb 4, 2011 at 2:18 PM, b...@google.com wrote:
Did you mean to include the clinit fixes in this patch?
Sure thing.
The original intent was that JsContext would get parameterized with the
compatible node type. So all JsExpression subclasses used a
JsContextJsExpression, which means, essentially, I can be replaced only
with other expressions. There was a tiny amount of usefulness in being
able to
SGTM.
Call it gwt.js.inlinerRatio maybe? There's wiki page somewhere that has
all the existing ones... there's probably a pattern that will emerge. (And
yours should be added.)
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I don't have anything great written up, but here's the gist of it:
Currently, when you do a web mode compile, JDT actually runs twice. First,
it runs from CompilationStateBuilder and compiles all the source code in
your project. The output of this is used to build TypeOracle, which is a
I plan to kill AbstractCompiler soon :D
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
No hard commitments, but I'm looking on the order of a month or thereabout.
On Wed, Jan 26, 2011 at 3:25 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
Thanks Scott for this. It's enough for me to understand motivation and (at
least some) implications of this change.
This is
Point taken; I killed the old one and made it reference the new one.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Is that SGTM or LGTM? I uploaded a patch.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
That seems good to me as a mid-term goal. Wouldn't this still be a useful
stop-gap moving in that direction but with the current servlet spec?
On Fri, Jan 7, 2011 at 1:41 PM, Toby Reyelts to...@google.com wrote:
It sounds to me as if we should be integrating with the facilities in
Servlet
On Wed, Jan 5, 2011 at 2:13 PM, zun...@google.com wrote:
On 2011/01/05 18:59:02, scottb wrote:
LGTM, I think.
What is that supposed to mean?!?
Sorry, it means I didn't scrutinize this to the Nth degree, just looked over
it at a high level.
I assume all the new units are being moved
On Thu, Dec 2, 2010 at 1:35 PM, Luis Solano luissolan...@gmail.com wrote:
I have checked out the trunk and configured my eclipse as said here:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt
.
I have set the checkstyle and the error/warning configuration
Like, LGTM++
On Wed, Dec 1, 2010 at 7:12 PM, zun...@google.com wrote:
On 2010/12/01 16:03:22, scottb wrote:
Perfect!
Is that perfect as in, Sounds great I'll look at it later! or LGTM?
http://gwt-code-reviews.appspot.com/1144801/show
--
Works for me.
On Mon, Nov 29, 2010 at 6:43 PM, Eric Ayers zun...@google.com wrote:
how about SerializationUtils.getRpcTypeName()
On Mon, Nov 29, 2010 at 4:53 PM, Scott Blum sco...@google.com wrote:
On Mon, Nov 29, 2010 at 2:50 PM, zun...@google.com wrote:
other references
-Restart the server, not just the WebAppContext, on refresh
Can you be more specific in the change description when you submit? Like:
- On server restart, restart the whole Jetty server, not just the
WebAppContext.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
and I get
exactly the same error.
Yves
On 9 nov, 07:47, Scott Blum sco...@google.com wrote:
Hmm can you increase your virtual memory?
On Mon, Nov 8, 2010 at 5:13 PM, yves yves.ko...@gmail.com wrote:
I can't, I only have 2GB RAM, I get this error as from -Xmx1024M
[java] Error
What if you turn the heap up to -Xmx2048M?
What log level are you using?
On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com wrote:
Hi,
I had a class named ResultNode and the project compiled fine.
In order to improve the code, I changed this class by adding generic
stuff like that :
[java] Could not create the Java virtual machine.
and the log level is INFO
Yves
On 8 nov, 22:53, Scott Blum sco...@google.com wrote:
What if you turn the heap up to -Xmx2048M?
What log level are you using?
On Mon, Nov 8, 2010 at 4:44 PM, yves yves.ko...@gmail.com wrote:
Hi
On Thu, Nov 4, 2010 at 4:57 PM, zun...@google.com wrote:
A second entry point for compile makes a lot of sense - and maybe for
CompilePerms too. Keep looking and tell me what you think.
I'm thinking of these names:
PrecompileOnePerm for the new precompile entry point.
CompileOnePerm for
LGTM
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
My JDK says:
*Throwable java.lang.reflect.InvocationTargetException.getTargetException()*
Get the thrown target exception.
This method predates the general-purpose exception chaining facility. The
Throwable.getCause() method is now the preferred means of obtaining this
information.
Returns:
Well, I had to pick something that wouldn't conflict with the names of the
established static methods. My names are pretty lame. Suggestions?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Hmm... not really sure how to recreate it. :/
On Mon, Oct 18, 2010 at 7:19 PM, con...@google.com wrote:
On 2010/10/18 22:52:22, scottb wrote:
perhaps we should add a test for this too?
http://gwt-code-reviews.appspot.com/1028801/show
--
On Wed, Oct 13, 2010 at 2:39 PM, Eric Ayers zun...@google.com wrote:
This is good, it confirms that the number of changes to the AST hasn't
changed (or haven't changed much). I was thinking of the speedtracer logs
which would show a change in the real-time performance of each pass the
.
On Wed, Oct 13, 2010 at 2:46 PM, Scott Blum sco...@google.com wrote:
On Wed, Oct 13, 2010 at 2:39 PM, Eric Ayers zun...@google.com wrote:
This is good, it confirms that the number of changes to the AST hasn't
changed (or haven't changed much). I was thinking of the speedtracer logs
which would
On Tue, Oct 12, 2010 at 4:07 PM, zun...@google.com wrote:
FYI, I like the refactoring of JModVisitor
Thanks!
I have no idea how you came up with these changes other than to pick up
a huge piece of code and start setting break points in the compiler and
iterating until you fixed them.
Is this in dev mode or prod mode? Do the tests succeed if you run them
individually?
On Thu, Sep 30, 2010 at 7:54 PM, Damon Lundin damon.lun...@gmail.comwrote:
We are trying to upgrade from 2.0.4 to 2.1.0.m3 because of some bugs
in 2.0.4 but in doing so our GWT test cases have begun failing
, 2010 at 11:13 AM, Damon Lundin damon.lun...@gmail.comwrote:
On Oct 1, 9:11 am, Scott Blum sco...@google.com wrote:
Is this in dev mode or prod mode? Do the tests succeed if you run them
individually?
This is in dev mode. If I disable all of the tests and run them
individually they all pass
It sounds like the problem really boils down to less-than-useful stack
traces when a native exception is thrown in Dev mode. Ironically, if you
ran this in Prod mode, you'd probably get a better stack trace, because we
emulate the stack over there.
We could probably implement the same sort of
It is the last reference to the (int) version. There are refs to the no-arg
version in my copy. I can definitely remove it.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I'm also not sure this is a bug. If it's set read-only, why would we try to
clobber it?
On Tue, Sep 28, 2010 at 11:18 AM, fabb...@google.com wrote:
Assuming we like the concept, I have two issues noted here.
At the larger level, people should be doing this today in e.g. build.xml
as a
This actually gives me pause. What kind of code can leave primitives on one
side but not the other?
I'm concerned because in Java, I think this should be true:
Integer.valueOf(1) == 1
Because the RHS gets autoboxed. If we're translating this as-is into JS
triple-equals without boxing it, the
What Bob said. You can write much, much faster unit tests using just
CompStateBuilder, since it's easy to build a very small world that only
contains just what you need. If you don't care about speed, it's probably
less work to go with ModuleDefLoader.
Some of the UiBinder tests are really
LGTM
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
High-level comments:
- CompilationState doesn't really need the extra API, because you can always
just iterate through the returned collection looking for errors. Arguably,
this would take a few extra cycles, but I've kinda been wanting to move the
error reporting out CompilationState anyway
LGTM
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Will our Eclipse formatter settings respect this? Or will it auto-format
such a construct into something else?
On Mon, Aug 30, 2010 at 1:53 PM, ncha...@google.com wrote:
On 2010/08/30 17:51:52, rjrjr wrote:
LGTM
Nice, thanks.
You're sure this works with the checkstyle 4.whatever
On Thu, Aug 26, 2010 at 9:40 PM, j...@google.com wrote:
Hmm, the code is fine, but the property files aren't. If you remove all
but AUD and USD from the CurrencyData_en_AU.properties file, you can see
the generated CurrencyList_en_AU.java contains only the modified values.
I'll work on
On Fri, Aug 27, 2010 at 11:21 AM, John Tamplin j...@google.com wrote:
Why do that every time you run the generator rather than once when you
import the CLDR data?
Oh, you know what, I kind of forgot that we're the only ones who actually
implement currency list.
Which actually brings up
On Fri, Aug 20, 2010 at 2:25 PM, b...@google.com wrote:
Change LGTM, but why is this a problem in practice? Isn't the generated
source transient?
It is, except when you use the -gen flag because you actually want to see
the generated output. What I was seeing is that, in some cases, the line
On Thu, Aug 19, 2010 at 11:41 AM, kplatf...@google.com wrote:
Why do we no longer visit annotation types?
We visit annotation types; what we don't visit is annotation elements on
other types. IE, we don't visit the @Override on a method. The reasoning
has to do with how the actual
Not exactly. I was trying to figure out *why* my patch broke the test, and
the non-deterministic error reporting made it very difficult to compare the
logs. I have a fix for the other issue (review coming soon), but this
seemed like a useful partial.
On Wed, Aug 18, 2010 at 4:16 PM,
On Thu, Aug 12, 2010 at 10:21 AM, b...@google.com wrote:
@Scott,
Do you have any further input on the implementation changes to the JS
runtime in the patch as it stands (modulo any future optimizations)?
No further comments, beyond what you said.
--
On Wed, Aug 11, 2010 at 12:56 PM, jbrosenb...@google.com wrote:
I think this makes sense, and would reduce the size of the generated
code, e.g. [12,35,123] vs. {12:1,35:1,123:1}. The Cast.canCast()
methods would have to iterate through the array explicitly to test for
existence though,
This should be jat.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
1 - 100 of 550 matches
Mail list logo
