x27;s if we *don't* mandate
> little-endian that code breaks.
No. WebGL expects native endianness today, and existing JS typed array
code produces native endianness today. This is true on both little and
big endian platforms. So existing code will typically run on both
classes of plat
On 28 March 2013 21:42, Mark S. Miller wrote:
> "prohibitively" depends on your tolerance. Modern machines can usually do
> register-to-register byte order reversal rather speedily. Which big endian
> machines do you have in mind?
For WebGL, which expects native endianness
So, my suspicion was correct, I am using DataView methods like this
(https://github.com/Ayms/abstract-tls/blob/master/lib/abstract-tls.js#l280-332
here and on other projects) for historical reasons, because I started
from node.js's buffers methods and then switched to ArrayBuffers with
node.js'
Yes: API consistency. An ArrayBuffer is opaque; to work with the data
it contains, instantiate a view.
On Tue, Apr 2, 2013 at 3:36 PM, Kevin Gadd wrote:
> Is there a reason why DataView wasn't specified as static methods that take
> an ArrayBuffer in the first place? That would solve the proble
Is there a reason why DataView wasn't specified as static methods that take
an ArrayBuffer in the first place? That would solve the problem of figuring
out when/how often to create DataView instances, and eliminate the garbage
created by using DataViews.
On Tue, Apr 2, 2013 at 3:23 PM, Kenneth Ru
On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte wrote:
>
> Le 02/04/2013 04:24, Kenneth Russell a écrit :
>>
>> Agreed. DataView's methods are all simple and should be easy to
>> optimize. Because they include a conditional byte swap, they can't run
>> quite as fast as the typed arrays' accessors --
Le 02/04/2013 04:24, Kenneth Russell a écrit :
Agreed. DataView's methods are all simple and should be easy to
optimize. Because they include a conditional byte swap, they can't run
quite as fast as the typed arrays' accessors -- but they shouldn't
need to. DataView was designed to support file
't
need to.
Side note: in theory they could run extremely fast, as long as the
endianness parameter was a constant. Since you generally know the
format of the data coming over the network, it should be except in rare
cases. The implementation knows the native endianness and can just
choos
On Sun, Mar 31, 2013 at 1:42 PM, Kevin Gadd wrote:
> One could also argue that people using typed arrays to alias and munge
> individual values should be using DataView instead. If it performs poorly,
> that can hopefully be addressed in the JS runtimes (the way it's specified
> doesn't seem to pr
One could also argue that people using typed arrays to alias and munge
individual values should be using DataView instead. If it performs poorly,
that can hopefully be addressed in the JS runtimes (the way it's specified
doesn't seem to prevent it from being efficient).
-kg
On Sun, Mar 31, 2013 a
(Apologies for breaking threading -- subscribed too late to have
original message to reply to.)
David Herman wrote:
On Mar 27, 2013, at 6:51 AM, Andreas Rossberg https://mail.mozilla.org/listinfo/es-discuss>> wrote:
>/ There actually are (third-party) projects
/>/ with ports of V8 and/or Chr
On Mar 27, 2013, at 6:51 AM, Andreas Rossberg wrote:
> There actually are (third-party) projects
> with ports of V8 and/or Chromium to big endian architectures.
It would be helpful to have more information about what these platforms and
projects are.
> WebGL
> code should not break or become p
Herman wrote:
> > [breaking out a new thread since this is orthogonal to the NaN issue]
> >
> > While the Khronos spec never specified an endianness, TC39 agreed in May
> 2012 to make the byte order explicitly little-endian in ES6:
> >
> > https://mail.mozilla.org/pipermail/
g endian order, I did not read everything about the subject and
why this decision was made but the basic reflex would be to add an
endianness option to typed arrays.
Regards,
[1] https://github.com/Ayms/node-Tor
[2] https://github.com/Ayms/iAnonym
[3] https://github.com/Ayms/abstract-tls and
ht
On 27 March 2013 00:35, David Herman wrote:
> [breaking out a new thread since this is orthogonal to the NaN issue]
>
> While the Khronos spec never specified an endianness, TC39 agreed in May 2012
> to make the byte order explicitly little-endian in ES6:
>
> https:
Kenneth Russell wrote:
On Tue, Mar 26, 2013 at 4:35 PM, David Herman wrote:
[breaking out a new thread since this is orthogonal to the NaN issue]
While the Khronos spec never specified an endianness, TC39 agreed in May 2012
to make the byte order explicitly little-endian in ES6:
https
On Tue, Mar 26, 2013 at 4:35 PM, David Herman wrote:
> [breaking out a new thread since this is orthogonal to the NaN issue]
>
> While the Khronos spec never specified an endianness, TC39 agreed in May 2012
> to make the byte order explicitly little-endian in ES6:
&
[breaking out a new thread since this is orthogonal to the NaN issue]
While the Khronos spec never specified an endianness, TC39 agreed in May 2012
to make the byte order explicitly little-endian in ES6:
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022834.html
The de facto
On Thu, May 20, 2010 at 4:50 PM, Waldemar Horwat wrote:
> Having unspecified endianness in the specification of TypedArrays seems like
> a show-stopper to me. There are two alternatives here:
>
> - If you do any I/O, you want the endianness to be specified. Sending data
> from
Having unspecified endianness in the specification of TypedArrays seems like a
show-stopper to me. There are two alternatives here:
- If you do any I/O, you want the endianness to be specified. Sending data
from one process to another with a different endianness would get you into
trouble
20 matches
Mail list logo