Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-04-03 Thread Andreas Rossberg
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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-04-03 Thread Andreas Rossberg
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

Re: endianness

2013-04-03 Thread Aymeric Vitte
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'

Re: endianness

2013-04-02 Thread Kenneth Russell
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

Re: endianness

2013-04-02 Thread Kevin Gadd
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

Re: endianness

2013-04-02 Thread Kenneth Russell
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 --

Re: endianness

2013-04-02 Thread Aymeric Vitte
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

Re: endianness

2013-04-02 Thread Vladimir Vukicevic
'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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-04-01 Thread Kenneth Russell
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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-31 Thread Kevin Gadd
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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-31 Thread Vladimir Vukicevic
(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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-28 Thread David Herman
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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-28 Thread Mark S. Miller
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/

Re: endianness

2013-03-27 Thread Aymeric Vitte
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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-27 Thread Andreas Rossberg
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:

Re: endianness

2013-03-26 Thread Brendan Eich
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

Re: endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-26 Thread Kenneth Russell
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: &

endianness (was: Observability of NaN distinctions — is this a concern?)

2013-03-26 Thread David Herman
[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

Re: Typed Arrays and Endianness

2010-05-24 Thread Kenneth Russell
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

Typed Arrays and Endianness

2010-05-20 Thread Waldemar Horwat
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