Agreed
On Wed, Jun 29, 2011 at 4:01 AM, wrote:
>
> LGTM. You're right, you can't do it statically because the array type
> can be from a cast.
>
>
>
> http://gwt-code-reviews.appspot.com/1470801/diff/1003/dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Array.java
> File
> dev
> he gets ASEs?
>
>
> On Tue, Jun 28, 2011 at 11:31 AM, Jason Rosenberg
> wrote:
>> What about the case for a DualSimple (e.g. an interface that has both
>> java and jso implementations). In this case, my fix doesn't allow the
>> jso to be assigned to a
What about the case for a DualSimple (e.g. an interface that has both
java and jso implementations). In this case, my fix doesn't allow the
jso to be assigned to an array of DualSimple[]. Is that expected (I'm
guessing not).
Jason
On Tue, Jun 28, 2011 at 2:05 PM, wrote:
>
> http://gwt-code-re
The EnumOrdinalizer has the ability to report for each
non-ordinalizable enum, the source location that caused it to be
black-listed. I noticed that for the case of JNewArray's constructed
in a method call with varargs, the source info was showing up as
"Unknown: Line 0". This change allows the s
LGTM
On Mon, May 16, 2011 at 9:47 PM, wrote:
> There's no expected net change in behavior, it's just code cleanup.
>
>
> http://gwt-code-reviews.appspot.com/1436801/diff/2001/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
> File dev/core/src/com/google/gwt/dev/jjs/impl/Gener
+zundel
Adding in Eric also...
Jason
On Fri, Apr 1, 2011 at 11:11 AM, BobV wrote:
> [+scottb, jbrosenberg]
>
> Jason or Scott, can you take a look at this? You have been working in
> this area more recently than I.
>
>> Please review this at http://gwt-code-reviews.appspot.com/1357804/
>
> --
LGTM
(and I eagerly await the fruits of this as applicable to checking type
hashes from generator code)
On Thu, Feb 17, 2011 at 11:00 AM, wrote:
> I did a performance test on this hash on a small sample GWT app and got
> an average of .1 to .12 ms per CompliledClass instance (2548 types were
> p
Ray,
Good question, but yeah, that case will be handled too. Leaf types
don't get visited for arrays at all (thus the root cause of this
problem). I have added another test case with the Enum[][]
reference, I'll commit that and add to the patch shortly.
Jason
On Mon, Nov 22, 2010 at 3:15 PM,
Appears I spoke too soon, getting a submit-queue test failure
On Fri, Aug 13, 2010 at 12:06 PM, wrote:
> Ok, I've addressed Bob's minor "nits" there (thanks Bob for catching)...
>
> I shall proceed to submit this puppy.
>
> Thanks for the great review guys
>
> Jason
>
>
> http://gwt-code
So, I've added some minor clarification in the comments describing the
castableTypeMap 'Object' (and removed some whitespace), but have not
attempted to narrow the typing on that Object (e.g. as a sub-classed
JavaScriptObject (as suggested by BobV), or as an int[] array (as
suggested by Scott/RayC)
Scott,
I'm working on getting rid of it now (I'll create a different bug
issue). My quick and dirty attempt to get rid of it had a few issues,
so I decided to release the main typeIdArray change first. Yes, I
agree, it should be able to be gotten rid of, since it's main purpose
was indeed to be
11 matches
Mail list logo
