In the process of testing it, I found
http://code.google.com/p/chromium/issues/detail?id=109785 :)
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/01/08 01:20:54, jat wrote:
I'm eagerly waiting for it ;-)
Done - http://gwt-code-reviews.appspot.com/1626803/
OK, so it looks exactly like what I was thinking of, and describing
above. Same as Wave's collections except using a static factory +
super-source, rather than an abstract
I thought again about shared code using typed arrays.
We'll have the following:
- an interface shared.TypedArray
- an implementation client.TypedArray extends JSO implements
shared.TypedArray
- the client.TypedArray implements the methods defined in
shared.TypedArray using JSNI
Now let's think
On 2012/01/07 17:13:19, Steffen Schäfer wrote:
I thought again about shared code using typed arrays.
We'll have the following:
- an interface shared.TypedArray
- an implementation client.TypedArray extends JSO implements
shared.TypedArray
- the client.TypedArray implements the methods
On Sat, Jan 7, 2012 at 3:03 PM, t.bro...@gmail.com wrote:
That's it. I'd probably call the client class JsoTypedArray so it's
harder to mix it up with shared.TypedArray (particularly when you use
facilities provided by your IDE to automatically insert the 'import'
clauses). Also, giving the
Le 7 janv. 2012 22:30, John Tamplin j...@google.com a écrit :
On Sat, Jan 7, 2012 at 3:03 PM, t.bro...@gmail.com wrote:
That's it. I'd probably call the client class JsoTypedArray so it's
harder to mix it up with shared.TypedArray (particularly when you use
facilities provided by your IDE to
I'm eagerly waiting for it ;-)
Done - http://gwt-code-reviews.appspot.com/1626803/
http://gwt-code-reviews.appspot.com/1621803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
One general note:
The Uint stuff is one thing of this API I hate very much in the context
of GWT. There are two solutions:
1. use emulated longs, and somehow convert them to real primitive JS
numbers (either using a string, as we did in some places or using
doubles behind the scene)
2. use
On 2012/01/04 19:52:29, jat wrote:
I have only glanced over the files, but I have a general comment. If
possible,
it would be nice if shared code could operate on typed arrays. That
would mean
defining most things in interfaces in shared, and then in the places
that need
it using
On Fri, Jan 6, 2012 at 3:18 PM, steffen.scha...@googlemail.com wrote:
I think extracting interfaces and place them in shared won't be the
problem. I'll do that for the next patch set.
I have some questions about that:
- Where is the best place to implement the factory methods? In a nested
Re. long vs. double, my opinion is: do not deal with long at all in the
API.
I doubt there could ever be a better performing long[]-JsArrayNumber
conversion than iterating through the array and doing a long-double
conversion for each value; so I wouldn't even provide utility methods
(as that
http://gwt-code-reviews.appspot.com/1621803/diff/1/user/src/com/google/gwt/typedarrays/client/DataView.java
File user/src/com/google/gwt/typedarrays/client/DataView.java (right):
I think it is appropriate to keep the correct type on things, as using
it on the server people will be unhappy using double for purely integral
values. So, I think using long for uint32 is correct, but there should
be docs explaining that it is slow and should be avoided in the client,
and also
Note: I read files in random order.
http://gwt-code-reviews.appspot.com/1621803/diff/1/user/src/com/google/gwt/typedarrays/client/ArrayBuffer.java
File user/src/com/google/gwt/typedarrays/client/ArrayBuffer.java
(right):
14 matches
Mail list logo
