Re: Observability of NaN distinctions — is this a concern?
On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt oli...@apple.com wrote: On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote: Right, thanks for the reminder. It all comes back now, including the how to write correct ending-independent typed array code bit. Ok, so looping back to my earlier observation. It sounds like endian-ness can be observed by writing into an Float64Array element and then reading back from a Uint8Array that is backed by the same buffer. If there is agreement that this doesn't represent a significant interoperability hazard can we also agree that not doing NaN cannonicalization on writes to FloatXArray is an even less significant hazard and need not be mandated? The reason I have pushed for NaN canonicalization is because it means that it allows (and in essence requires) that typedArray[n] = typedArray[n] can modify the bit value of typedArray[n]. An implementation _may_ be able to optimize the checks away in some cases, but most engines must perform checks on read unless they can prove that they were the original source of the value being read. Forcing canonicalization simply means that you are guaranteed that a certain behavior will occur, and so won't be bitten by some tests changing behavior that you may have seen during testing. I know Ken hates these sorts of things, but seriously in the absence of a real benchmark, that shows catastrophic performance degradation due to this, simply saying this is extra work that will burn cpu cycles without evidence is a waste of time. I also disagree with you. Also there is absolutely no case in which abstract performance concerns should ever outweigh absolute security and correctness bugs. Could you elaborate on the security part? I doubt NaN distinctions can really be of any significant use for fingerprinting, etc. So far I've yet to come across any unexpected bugs caused by this, maybe you have examples? NaN is usually a non-desired value so if you write a NaN you probably had a bug in the first place. And about correctness, by definition NaN is a category, not a value; by definition a NaN value is not the same as another NaN value. If you want to canonicalize NaN, my suggestion is IEEE, not ES-discuss. ;) We need to stop raising this causes performance problems type issues without a concrete example of that problem. I remember having to work very hard to stop WebGL from being a gaping security hole in the first place and it's disappointing to see these same issues being re-raised in a different forum to try and get them bypassed here. Before saying security hole, please elaborate. Also, when it comes to standards, I think change should be justified with data, rather than the other way around. Cheers, Jussi --Oliver Allen /be On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote: On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was there ever a resolution as to whether or not TypedArray [[Set]] operations need to use a cannonical endian-ness? Search for byte order at https://www.khronos.org/registry/typedarray/specs/latest/. I had already search for endian with similar results. It says that the default for DataViews gets/sets that do not specify a byte order is big-endean. It doesn't say anything (that I can find) about such accesses on TypedArray gets/sets. Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE to match dominant architectures, while DataViews are BE to match packed serialization use-cases. Ken, did something get edited out? No. The typed array views (everything except DataView) have used the host machine's endianness from day one by design -- although the typed array spec does not state this explicitly. If desired, text can be added to the specification to this effect. Any change in this behavior will destroy the performance of APIs like WebGL and Web Audio on big-endian architectures. Correctly written code works identically on big-endian and little-endian architectures. See http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a detailed description of the usage of the APIs. DataView, which is designed for input/output, operates on data with a specified endianness. -Ken ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing
Re: Observability of NaN distinctions — is this a concern?
On Tue, Mar 26, 2013 at 6:40 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt oli...@apple.com wrote:
On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
Right, thanks for the reminder. It all comes back now, including the
how to write correct ending-independent typed array code bit.
Ok, so looping back to my earlier observation. It sounds like
endian-ness can be observed by writing into an Float64Array element and
then reading back from a Uint8Array that is backed by the same buffer. If
there is agreement that this doesn't represent a significant
interoperability hazard can we also agree that not doing NaN
cannonicalization on writes to FloatXArray is an even less significant
hazard and need not be mandated?
The reason I have pushed for NaN canonicalization is because it means
that it allows (and in essence requires) that typedArray[n] = typedArray[n]
can modify the bit value of typedArray[n].
An implementation _may_ be able to optimize the checks away in some
cases, but most engines must perform checks on read unless they can prove
that they were the original source of the value being read.
Forcing canonicalization simply means that you are guaranteed that a
certain behavior will occur, and so won't be bitten by some tests changing
behavior that you may have seen during testing. I know Ken hates these
sorts of things, but seriously in the absence of a real benchmark, that
shows catastrophic performance degradation due to this, simply saying this
is extra work that will burn cpu cycles without evidence is a waste of
time.
I also disagree with you.
Also there is absolutely no case in which abstract performance concerns
should ever outweigh absolute security and correctness bugs.
Could you elaborate on the security part? I doubt NaN distinctions can
really be of any significant use for fingerprinting, etc.
In SES, Alice says:
var bob = confinedEval(bobSrc);
var carol = confinedEval(carolSrc);
// At this point, bob and carol should be unable to communicate with
// each other, and are in fact completely isolated from each other
// except that Alice holds a reference to both.
// See http://www.youtube.com/watch?v=w9hHHvhZ_HY start
// at about 44 minutes in.
var shouldBeImmutable = Object.freeze(Object.create(null, {foo: {value:
NaN}}));
bob(shouldBeImmutable);
carol(shouldBeImmutable);
// Alice, by sharing this object with bob and carol, should still be
able
// to assume that they are isolated from each other
Bob says:
var FunnyNaN = // expression creating NaN with non-canonical internal
rep
// on this platform, perhaps created by doing funny typed array tricks
if (wantToCommunicate1bitToCarol) {
Object.defineProperty(shouldBeImmutable, 'foo', {value: FunnyNaN});
// The [[DefineProperty]] algorithm is allowed to overwrite
shouldBeImmutable.foo
// with FunnyNaN, since it passes the SameValue check.
Carol says:
if (isNaNFunny(shouldBeImmutable.foo)) {
// where isNaNFunny uses typed array tricks to detect whether its
argument has
// a non-canonical rep on this this platform
So far I've yet to come across any unexpected bugs caused by this, maybe
you have examples? NaN is usually a non-desired value so if you write a NaN
you probably had a bug in the first place.
And about correctness, by definition NaN is a category, not a value; by
definition a NaN value is not the same as another NaN value. If you want to
canonicalize NaN, my suggestion is IEEE, not ES-discuss. ;)
You're confusing IEEE NaN with ES NaN. In ES, NaN is a value, not a bit
pattern. In IEEE, NaN is a family of bit patterns. Type arrays make us face
the issue of what IEEE NaN bit pattern an ES NaN value converts to.
We need to stop raising this causes performance problems type issues
without a concrete example of that problem. I remember having to work very
hard to stop WebGL from being a gaping security hole in the first place and
it's disappointing to see these same issues being re-raised in a different
forum to try and get them bypassed here.
Before saying security hole, please elaborate. Also, when it comes to
standards, I think change should be justified with data, rather than the
other way around.
Done.
Cheers,
Jussi
--Oliver
Allen
/be
On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote:
On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com
wrote:
Allen Wirfs-Brock wrote:
On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
BTW, isn't cannonicalization of endian-ness for both integers and
floats
a bigger interop issue than NaN cannonicalization? I know this
was
discussed in the past, but it doesn't seem to be covered in the
Re: Observability of NaN distinctions — is this a concern?
On Tue, Mar 26, 2013 at 9:54 AM, Mark S. Miller erig...@google.com wrote:
On Tue, Mar 26, 2013 at 6:40 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt oli...@apple.com wrote:
On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
Right, thanks for the reminder. It all comes back now, including the
how to write correct ending-independent typed array code bit.
Ok, so looping back to my earlier observation. It sounds like
endian-ness can be observed by writing into an Float64Array element and
then reading back from a Uint8Array that is backed by the same buffer. If
there is agreement that this doesn't represent a significant
interoperability hazard can we also agree that not doing NaN
cannonicalization on writes to FloatXArray is an even less significant
hazard and need not be mandated?
The reason I have pushed for NaN canonicalization is because it means
that it allows (and in essence requires) that typedArray[n] = typedArray[n]
can modify the bit value of typedArray[n].
An implementation _may_ be able to optimize the checks away in some
cases, but most engines must perform checks on read unless they can prove
that they were the original source of the value being read.
Forcing canonicalization simply means that you are guaranteed that a
certain behavior will occur, and so won't be bitten by some tests changing
behavior that you may have seen during testing. I know Ken hates these
sorts of things, but seriously in the absence of a real benchmark, that
shows catastrophic performance degradation due to this, simply saying this
is extra work that will burn cpu cycles without evidence is a waste of
time.
I also disagree with you.
Also there is absolutely no case in which abstract performance concerns
should ever outweigh absolute security and correctness bugs.
Could you elaborate on the security part? I doubt NaN distinctions can
really be of any significant use for fingerprinting, etc.
In SES, Alice says:
var bob = confinedEval(bobSrc);
var carol = confinedEval(carolSrc);
// At this point, bob and carol should be unable to communicate with
// each other, and are in fact completely isolated from each other
// except that Alice holds a reference to both.
// See http://www.youtube.com/watch?v=w9hHHvhZ_HY start
// at about 44 minutes in.
var shouldBeImmutable = Object.freeze(Object.create(null, {foo:
{value: NaN}}));
bob(shouldBeImmutable);
carol(shouldBeImmutable);
// Alice, by sharing this object with bob and carol, should still be
able
// to assume that they are isolated from each other
Bob says:
var FunnyNaN = // expression creating NaN with non-canonical internal
rep
// on this platform, perhaps created by doing funny typed array tricks
if (wantToCommunicate1bitToCarol) {
Object.defineProperty(shouldBeImmutable, 'foo', {value: FunnyNaN});
// The [[DefineProperty]] algorithm is allowed to overwrite
shouldBeImmutable.foo
// with FunnyNaN, since it passes the SameValue check.
Carol says:
if (isNaNFunny(shouldBeImmutable.foo)) {
// where isNaNFunny uses typed array tricks to detect whether its
argument has
// a non-canonical rep on this this platform
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value, so
that example is invalid.
So far I've yet to come across any unexpected bugs caused by this, maybe
you have examples? NaN is usually a non-desired value so if you write a NaN
you probably had a bug in the first place.
And about correctness, by definition NaN is a category, not a value; by
definition a NaN value is not the same as another NaN value. If you want to
canonicalize NaN, my suggestion is IEEE, not ES-discuss. ;)
You're confusing IEEE NaN with ES NaN. In ES, NaN is a value, not a bit
pattern. In IEEE, NaN is a family of bit patterns. Type arrays make us face
the issue of what IEEE NaN bit pattern an ES NaN value converts to.
That's just because ES has had no notion of bits for floating points
before. Other than that, ES NaN works like IEEE NaN, e.g.
0/0 === NaN // false
isNaN(0/0) // true
We need to stop raising this causes performance problems type issues
without a concrete example of that problem. I remember having to work very
hard to stop WebGL from being a gaping security hole in the first place and
it's disappointing to see these same issues being re-raised in a different
forum to try and get them bypassed here.
Before saying security hole, please elaborate. Also, when it comes to
standards, I think change should be justified with data, rather than the
other way around.
Done.
You'll have to do better than that. ;)
Cheers,
Jussi
Cheers,
Jussi
Re: Observability of NaN distinctions — is this a concern?
On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: That's just because ES has had no notion of bits for floating points before. Other than that, ES NaN works like IEEE NaN, e.g. 0/0 === NaN // false isNaN(0/0) // true That's true in any language - comparing to NaN is almost always defined explicitly as producing false. You're not looking at bit patterns, here so conflating NaN compares with bit values is kind of pointless. We need to stop raising this causes performance problems type issues without a concrete example of that problem. I remember having to work very hard to stop WebGL from being a gaping security hole in the first place and it's disappointing to see these same issues being re-raised in a different forum to try and get them bypassed here. Before saying security hole, please elaborate. Also, when it comes to standards, I think change should be justified with data, rather than the other way around. Done. You'll have to do better than that. ;) Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the can't be remotely pwned sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver Cheers, Jussi Cheers, Jussi --Oliver Allen /be On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote: On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was there ever a resolution as to whether or not TypedArray [[Set]] operations need to use a cannonical endian-ness? Search for byte order at https://www.khronos.org/registry/typedarray/specs/latest/. I had already search for endian with similar results. It says that the default for DataViews gets/sets that do not specify a byte order is big-endean. It doesn't say anything (that I can find) about such accesses on TypedArray gets/sets. Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE to match dominant architectures, while DataViews are BE to match packed serialization use-cases. Ken, did something get edited out? No. The typed array views (everything except DataView) have used the host machine's endianness from day one by design -- although the typed array spec does not state this explicitly. If desired, text can be added to the specification to this effect. Any change in this behavior will destroy the performance of APIs like WebGL and Web Audio on big-endian architectures. Correctly written code works identically on big-endian and little-endian architectures. See http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a detailed description of the usage of the APIs. DataView, which is designed for input/output, operates on data with a specified endianness. -Ken ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list
Re: Modules feedback from March 2013 meeting
On 25 March 2013 18:31, James Burke jrbu...@gmail.com wrote:
### Single Anonymous Export ###
The latest update was more about semantics, but some thoughts on how
single anonymous export might work:
Just use `export` for the single anonymous export:
module m {
export function calculate() {}
}
where calculate is just the local name for use internally by the
module, but `calculate` is not visible to outside modules, they just
import that single anonymous export.
For exporting a named property:
module n {
export calculate: function () {}
}
This would still result in a local `calculate`, let-equivalent local
name, but then also allows for other modules to import `calculate`
from this module.
And how about const declarations, class declarations, module
declarations, and any other declaration form that might enter the
language at some point? I can't see how your suggestion scales to
that.
Also, optimising the entire syntax for one special use case while
uglifying all regular ones will be a hard sell.
start extremely speculative section:
This next part is very speculative, and the most likely of this
feedback to be a waste of your time:
crypto is a bit more interesting. It would be neat to allow:
let { encrypt } from crypto;
which is shorthand for:
import temp from crypto;
let { encrypt } = temp;
You are trying very hard to avoid using ES6 modules the way they are
meant to be used. Just define your crypto module as
module crypto {
export function encrypt() {}
export function decrypt() {}
}
and the existing import destructuring will work like a charm, while
having made your module both prettier and more concise. ;)
With that capability, it may be possible to go without `import` at
all, at least at this stage of ES (macros later may require it).
As I have explained earlier on this list, destructuring import and
destructuring let are not the same. The former introduces aliases, not
new stateful bindings. This is relevant if you want to be able to
export mutable entities. So no, we cannot drop import.
Going even further: then the `export publicName: value` syntax may not
be needed either.
Only when you're willing to throw all static checking (not just of
imports but any module access M.x) out the window.
### Nested modules ###
This was explicitly stated as a non-goal, but it is something that
shows up in the AMD module world (library builds with almond wrapped
with a UMD style boilerplate for use by the outside world):
module publicThing {
module j {}
module k {}
export …. //something visible outside publicThing
}
The idea being that internally publicThing uses some modules, but
they are only for its internal use, not for use outside of
publicThing.
It would be nice to allow a chain of ID lookup tables, favoring a
local lookup table/closer tables and working up the chain to find a
match. If no match, a module is fetched/loaded and placed in the top
level table.
I agree with your goal, and that is why I still maintain my point of
view that modules should be denoted by regular lexically scoped
identifiers, like any good language citizen. Then we'd get the right
rules for free, in a clean, declarative manner, and wouldn't need to
reinvent the wheel continuously, through more and more operational
hacks.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
I'm with Dave and Oliver. Worrying about the performance cost of NaN normalisation has a strong smell of premature micro optimisation. The one branch per float store, whose cost should be amortised by branch prediction when frequent, seems very unlikely to be measurable compared to everything else going on when executing JavaScript. As for the this is not a common problem argument, use cases should only trump principles if the cost is unbearable. /Andreas On 26 March 2013 09:29, Oliver Hunt oli...@apple.com wrote: On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: That's just because ES has had no notion of bits for floating points before. Other than that, ES NaN works like IEEE NaN, e.g. 0/0 === NaN // false isNaN(0/0) // true That's true in any language - comparing to NaN is almost always defined explicitly as producing false. You're not looking at bit patterns, here so conflating NaN compares with bit values is kind of pointless. We need to stop raising this causes performance problems type issues without a concrete example of that problem. I remember having to work very hard to stop WebGL from being a gaping security hole in the first place and it's disappointing to see these same issues being re-raised in a different forum to try and get them bypassed here. Before saying security hole, please elaborate. Also, when it comes to standards, I think change should be justified with data, rather than the other way around. Done. You'll have to do better than that. ;) Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the can't be remotely pwned sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver Cheers, Jussi Cheers, Jussi --Oliver Allen /be On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote: On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was there ever a resolution as to whether or not TypedArray [[Set]] operations need to use a cannonical endian-ness? Search for byte order at https://www.khronos.org/registry/typedarray/specs/latest/. I had already search for endian with similar results. It says that the default for DataViews gets/sets that do not specify a byte order is big-endean. It doesn't say anything (that I can find) about such accesses on TypedArray gets/sets. Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE to match dominant architectures, while DataViews are BE to match packed serialization use-cases. Ken, did something get edited out? No. The typed array views (everything except DataView) have used the host machine's endianness from day one by design -- although the typed array spec does not state this explicitly. If desired, text can be added to the specification to this effect. Any change in this behavior will destroy the performance of APIs like WebGL and Web Audio on big-endian architectures. Correctly written code works identically on big-endian and little-endian architectures. See http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a detailed description of the usage of the APIs. DataView, which is designed for input/output, operates on data with a specified endianness. -Ken ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
So to summarize: - This would be very useful in large MVC applications with many independent components. - Even with WeakMaps there is no way to implement weak event listeners, since WeakMaps cannot be iterated. A weak reference implementation would solve this. - The main problem with weak event listeners is that they are not deterministic; even if you remove all references to an object there is no way to ensure that the object is garbage collected immediately, and so events would still be dispatched to it for an indeterminable period of time after the last strong reference is severed. I'm not sure of how big of a problem this would be; it might be an annoyance or it might break the application completely. Marius Gundersen On Tue, Mar 26, 2013 at 4:24 AM, Benoit Marchant march...@mac.com wrote: Very true, I'm wondering if based on usage today it could make sense to have this as default behavior on current API? Benoit On Mar 25, 2013, at 19:51, Peter Michaux petermich...@gmail.com wrote: On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote: One thing which is impossible to make in JavaScript today is a weakly referenced event listener system. In such a system an event listener is not strongly referenced by the event system, so events are only dispatched to it as long as another object holds a reference to it. Being able to make an observable subject that keeps a weak list of observers would be very useful to ease memory management within an application and avoid accidental memory leaks at the application level. Sometimes the application programmer may forgot to remove a observer from an observable subject, for example. With regard to the MVC architecture, this could be the best addition to the language to make application development easier. A view might mistakenly not unsubscribe from its associate model when the view is destroyed, for example. That or the view's destroy method is never even called because the application programmer forgot to call it. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
2013/3/25 Erik Arvidsson erik.arvids...@gmail.com WeakMap would not work in this specific case since a WeakMap cannot be iteratered. I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or just dropped? Thanks, Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
2013/3/26 Juan Ignacio Dopazo dopazo.j...@gmail.com 2013/3/25 Erik Arvidsson erik.arvids...@gmail.com WeakMap would not work in this specific case since a WeakMap cannot be iteratered. I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or just dropped? I doubt there was ever an *iterable* WeakSet proposal, since iteration would make GC of the weakly held values observable. This is exactly the same reason why WeakMap isn't iterable. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Observability of NaN distinctions — is this a concern?
jussi.kallioko...@gmail.com wrote: That's just because ES has had no notion of bits for floating points before. Other than that, ES NaN works like IEEE NaN, e.g. Some background about the latest GLS spec and IEEE NaNs from http://www.opengl.org/registry/doc/GLSLangSpec.4.20.11.clean.pdf Section 4.1.4 states As an input value to one of the processing units, a single-precision or double-precision floating-point variable is expected to match the corresponding IEEE 754 floating-point definition for precision and dynamic range. Floating-point variables within a shader are also encoded according to the IEEE 754 specification for single-precision floating-point values (logically, not necessarily physically). Section 4.7.1 goes on to provide a detailed list of reduced (from IEEE 754) precision requirements for single precision floats and then states the following: The precision of double-precision operations is at least that of single precision. 4.7.1 also sets up the requirements of operations to produce NaNs as follows: NaNs are not required to be generated. Support for signaling NaNs is not required and exceptions are never raised. Operations and built-in functions that operate on a NaN are not required to return a NaN as the result. So any statement that the GLS spec follows IEEE 754 treatment of double precision is only a statement about input values. - Rick -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andreas Rossberg Sent: Tuesday, March 26, 2013 6:40 AM To: Oliver Hunt Cc: Mark S. Miller; Brendan Eich; es-discuss Subject: Re: Observability of NaN distinctions — is this a concern? I'm with Dave and Oliver. Worrying about the performance cost of NaN normalisation has a strong smell of premature micro optimisation. The one branch per float store, whose cost should be amortised by branch prediction when frequent, seems very unlikely to be measurable compared to everything else going on when executing JavaScript. As for the this is not a common problem argument, use cases should only trump principles if the cost is unbearable. /Andreas On 26 March 2013 09:29, Oliver Hunt oli...@apple.com wrote: On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: That's just because ES has had no notion of bits for floating points before. Other than that, ES NaN works like IEEE NaN, e.g. 0/0 === NaN // false isNaN(0/0) // true That's true in any language - comparing to NaN is almost always defined explicitly as producing false. You're not looking at bit patterns, here so conflating NaN compares with bit values is kind of pointless. We need to stop raising this causes performance problems type issues without a concrete example of that problem. I remember having to work very hard to stop WebGL from being a gaping security hole in the first place and it's disappointing to see these same issues being re-raised in a different forum to try and get them bypassed here. Before saying security hole, please elaborate. Also, when it comes to standards, I think change should be justified with data, rather than the other way around. Done. You'll have to do better than that. ;) Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the can't be remotely pwned sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver Cheers, Jussi Cheers, Jussi --Oliver Allen /be On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote: On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was
Re: Observability of NaN distinctions — is this a concern?
On Tue, Mar 26, 2013 at 3:54 AM, Mark S. Miller erig...@google.com wrote: // The [[DefineProperty]] algorithm is allowed to overwrite shouldBeImmutable.foo While I agree with you on the larger point (and this issue reoccurs with proxies), the actual problem here is that [[DefineProperty]] should just do nothing on immutable data. The idea of mutating immutable data as long as its the same value is crazy. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 9:46 AM, Tom Van Cutsem tomvc...@gmail.com wrote: 2013/3/26 Juan Ignacio Dopazo dopazo.j...@gmail.com 2013/3/25 Erik Arvidsson erik.arvids...@gmail.com WeakMap would not work in this specific case since a WeakMap cannot be iteratered. I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or just dropped? I doubt there was ever an *iterable* WeakSet proposal, since iteration would make GC of the weakly held values observable. This is exactly the same reason why WeakMap isn't iterable. Cheers, Tom TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Mark Miller proposed semantics for WeakRefs to satisfy security concerns: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html Both of these should be discussed at the next meeting. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Weak event listener
From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. Mark Miller proposed semantics for WeakRefs to satisfy security concerns: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html I assume this is ES7 timeframe, even if it'll be discussed at the next meeting? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Mark Miller proposed semantics for WeakRefs to satisfy security concerns: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html I assume this is ES7 timeframe, even if it'll be discussed at the next meeting? I don't know the answer to this question, sorry. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Note that this requirement is conditional on a particular approach (which I still favor) to the interaction between proxies and private names, and so since that's still up in the air, the WeakSet requirement for ES6 may go away. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote: The NaN distinction is only observable in the byte array, not if you extract the value, because at that point it becomes an ES NaN value, so that example is invalid. It becomes observable on the read end by doing: float64array[0] = shouldBeImmutable.foo; new Uint32Array(float64array.buffer)[0]; // or [1] depending on endianness ...unless you canonicalize the NaN on either on the read or the write. This is pretty damning. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
On 3/26/2013 10:03 AM, Brandon Benvie wrote:
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value,
so that example is invalid.
It becomes observable on the read end by doing:
float64array[0] = shouldBeImmutable.foo;
new Uint32Array(float64array.buffer)[0]; // or [1] depending on
endianness
...unless you canonicalize the NaN on either on the read or the write.
This is pretty damning.
It does appear that in practice (at least in V8 and SpiderMonkey), the
attempt to write a different NaN does not succeed. It still is possible
to use a packed NaN to deliver information as a kind of secret
communication channel. Demonstration:
var buff = new ArrayBuffer(8);
var f64 = new Float64Array(buff);
var ui32 = new Uint32Array(buff);
ui32[1] = 0xfff8; // may need to be 1 depending on endianness
function packNaN(value){
ui32[1] = value;
return f64[1]; // may need to be 0 depending on endianness
}
function unpackNaN(nan){
f64[0] = nan;
return ui32[0]; // may need to be 1 depending on endianness
}
var shouldBeImmutable = Object.freeze({ foo: packNaN(1500) });
console.log(unpackNaN(shouldBeImmutable.foo)); // 1500
// the following silently fails in V8 and throws in SpiderMonkey
Object.defineProperty(shouldBeImmutable, 'foo', { value:
packNaN(2000) });
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
On 3/26/2013 10:39 AM, Brandon Benvie wrote:
On 3/26/2013 10:03 AM, Brandon Benvie wrote:
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value,
so that example is invalid.
It becomes observable on the read end by doing:
float64array[0] = shouldBeImmutable.foo;
new Uint32Array(float64array.buffer)[0]; // or [1] depending on
endianness
...unless you canonicalize the NaN on either on the read or the
write. This is pretty damning.
It does appear that in practice (at least in V8 and SpiderMonkey), the
attempt to write a different NaN does not succeed. It still is
possible to use a packed NaN to deliver information as a kind of
secret communication channel. Demonstration:
... snip code ...
Sorry, I screwed this up here trying to figure out why NaN packing is
not working in Spidermonkey but is in V8. Curiously different results.
var buff = new ArrayBuffer(8);
var f64 = new Float64Array(buff);
var ui32 = new Uint32Array(buff);
ui32[1] = 0xfff8; // may need to be 0 depending on endianness
function packNaN(value){
ui32[0] = value; // may need to be 1 depending on endianness
return f64[0];
}
function unpackNaN(nan){
f64[0] = nan;
return ui32[0]; // may need to be 1 depending on endianness
}
var shouldBeImmutable = Object.freeze({ foo: packNaN(1500) });
console.log(shouldBeImmutable.foo) // NaN
console.log(unpackNaN(shouldBeImmutable.foo)); // 1500 in V8, 0 in SM
Object.defineProperty(shouldBeImmutable, 'foo', { value:
packNaN(2000) });
console.log(unpackNaN(shouldBeImmutable.foo)); // 1500 in V8, 0 in SM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
No mystery here: SpiderMonkey canonicalizes all NaN bit patterns to
0x7FF8LL.
/be
Brandon Benvie wrote:
On 3/26/2013 10:39 AM, Brandon Benvie wrote:
On 3/26/2013 10:03 AM, Brandon Benvie wrote:
On 3/26/2013 1:12 AM, Jussi Kalliokoski wrote:
The NaN distinction is only observable in the byte array, not if
you extract the value, because at that point it becomes an ES NaN
value, so that example is invalid.
It becomes observable on the read end by doing:
float64array[0] = shouldBeImmutable.foo;
new Uint32Array(float64array.buffer)[0]; // or [1] depending on
endianness
...unless you canonicalize the NaN on either on the read or the
write. This is pretty damning.
It does appear that in practice (at least in V8 and SpiderMonkey),
the attempt to write a different NaN does not succeed. It still is
possible to use a packed NaN to deliver information as a kind of
secret communication channel. Demonstration:
... snip code ...
Sorry, I screwed this up here trying to figure out why NaN packing is
not working in Spidermonkey but is in V8. Curiously different results.
var buff = new ArrayBuffer(8);
var f64 = new Float64Array(buff);
var ui32 = new Uint32Array(buff);
ui32[1] = 0xfff8; // may need to be 0 depending on endianness
function packNaN(value){
ui32[0] = value; // may need to be 1 depending on endianness
return f64[0];
}
function unpackNaN(nan){
f64[0] = nan;
return ui32[0]; // may need to be 1 depending on endianness
}
var shouldBeImmutable = Object.freeze({ foo: packNaN(1500) });
console.log(shouldBeImmutable.foo) // NaN
console.log(unpackNaN(shouldBeImmutable.foo)); // 1500 in V8, 0 in SM
Object.defineProperty(shouldBeImmutable, 'foo', { value:
packNaN(2000) });
console.log(unpackNaN(shouldBeImmutable.foo)); // 1500 in V8, 0 in SM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
Oliver Hunt wrote: Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. This is where Kenneth parts company, arguing for safety (no pwnage, no ability to forge a NaN in engines that nanbox) but against interoperability on this edge case. The two are separable concerns: safety and interop. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
On Mar 26, 2013, at 1:29 AM, Oliver Hunt wrote: Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the can't be remotely pwned sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver Oliver, Let's look at actual ES6 spec. language and see if there is actually anything you would like to see changed. The encoding of NaNs is only discussed in three places: Section 8.1.5, first paragraph says: The Number type has exactly 18437736874454810627 (that is, 264253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 2532) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value. (Note that the NaN value is produced by the program expression NaN.) In some implementations, external code might be able to detect a difference between various Not-a-Number values, but such behaviour is implementation-dependent; to ECMAScript code, all NaN values are indistinguishable from each other. This is very old text, most of which dates to ES1. It is defining the ES Number type, which is an abstraction, not an actual bit-level encoding. To me it say these things: 1) Unlike the the IEEE 64-bit floating point type. The ES Number type has only a single NaN value. 2) An implementations are free to internally encode the Number type any why it desires (as long is it observably conforms to all the requirements of section 8.1.5). 3) In particular, an implementation might have multiple internal bit patterns all of which correspond to the single NaN element of the Number type. 4) A corollary of 3) is that implementation are not required to internally canonicalize NaNs, that is an implementation level design decision. 5) Implementations are not required to canonicalize NaNs when they are passed or otherwise made visible to non-ES code. Hence such code may be able to observe details of the NaN encoding, including whether or not a canonical NaN value is used internally by the ES implementation. Is there anything you think should change in the above specification text? Section 15.13.5.1.3 defines the GetValueFromBuffer abstraction operation which is currently the only place in the ES6 spec. where a ES Number value is retrieved from an ArrayBuffer. Step 8 of the specification algorithm is: 8 If type is “Float64” , then rawValue is interpreted, taking into accont the value of isBigEndian, as a bit string encoding of an IEEE 754-208 binary64 value. If rawValue is any an IEEE 754-208 binary64 NaN value, return the NaN Number value. Return the Number value that is encoded by rawValue. Step 7 is similar but deals with Float32 values. To me it say these things: 1) In all cases, an ES Number value (as defined in 8.1.5) is returned. 2) All IEEE NaN values are logically canonicalized as the single ES NaN value. 3) No additional requirements for ES Numbers, beyond those in 8.1.5 are introduced. Actual representation remains up to implementation. Should anything change? If 8.1.5 continues to not mandate any particular or single encoding representation of a NaN, I don't see why this should either. Section 15.13.5.1.4 defines the SetValueInBuffer abstraction operation which is currently the only place in the ES6 spec. where a ES Number value is stored into a ArrayBuffer. Step 8 of the specification algorithm is: 8. Else, if type is “Float64” , then Set rawValue to the 8 bytes that are the IEEE-868-2005 binary64 format encoding of value. If isBigEndian is true, the bytes are arranged in big endian order. Otherwise, the bytes are arranged in little endian order. If value is NaN, rawValue is may be set to any implementation choosen non-signaling NaN encoding. Step 7 is similar but deals with Float32 values. To me it say these things: 1) When storing into an ArrayBuffer,
Re: Observability of NaN distinctions — is this a concern?
I would like to add some perf numbers to this discussion, if I may. I have implemented a quick patch for V8 that implements NaN normalization on Float64Array store. V8 does not use NaN boxing, so from implementation perspective NaN normalization is not required by V8. In my test, the perf penalty for Float64Array store is 25% (on ia32 architecture in optimized regime, using sse2 instructions). I am attaching the test and my patch for your perusal (the patch should easily apply to v8's bleeding_edge). It feels like the performance hit is a very considerable factor here, especially given that typed arrays are all about fast math. Results on my machine: Normalized stores: $ ./out/ia32.release/d8 float-array.js Start 14033 msec Start 14059 msec Start 13983 msec Start 13979 msec Non-normalized stores: $ ./out.baseline/ia32.release/d8 float-array.js Start 11197 msec Start 11207 msec Start 11207 msec Start 11253 msec Dmitry On Tue, Mar 26, 2013 at 7:55 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Mar 26, 2013, at 1:29 AM, Oliver Hunt wrote: Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the can't be remotely pwned sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver Oliver, Let's look at actual ES6 spec. language and see if there is actually anything you would like to see changed. The encoding of NaNs is only discussed in three places: Section 8.1.5, first paragraph says: The Number type has exactly 18437736874454810627 (that is, 264253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 2532) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special * NaN* value. (Note that the *NaN* value is produced by the program expression *NaN*.) In some implementations, external code might be able to detect a difference between various Not-a-Number values, but such behaviour is implementation-dependent; to ECMAScript code, all NaN values are indistinguishable from each other. This is very old text, most of which dates to ES1. It is defining the ES Number type, which is an abstraction, not an actual bit-level encoding. To me it say these things: 1) Unlike the the IEEE 64-bit floating point type. The ES Number type has only a single NaN value. 2) An implementations are free to internally encode the Number type any why it desires (as long is it observably conforms to all the requirements of section 8.1.5). 3) In particular, an implementation might have multiple internal bit patterns all of which correspond to the single NaN element of the Number type. 4) A corollary of 3) is that implementation are not required to internally canonicalize NaNs, that is an implementation level design decision. 5) Implementations are not required to canonicalize NaNs when they are passed or otherwise made visible to non-ES code. Hence such code may be able to observe details of the NaN encoding, including whether or not a canonical NaN value is used internally by the ES implementation. Is there anything you think should change in the above specification text? Section 15.13.5.1.3 defines the GetValueFromBuffer abstraction operation which is currently the only place in the ES6 spec. where a ES Number value is retrieved from an ArrayBuffer. Step 8 of the specification algorithm is: - 8 If *type* is “Float64” , then 1. * rawValue* is interpreted, taking into accont the value of * isBigEndian*, as a bit string encoding of an IEEE 754-208 binary64 value. 2. If *rawValue* is any an IEEE 754-208 binary64 NaN value, return the *NaN* Number value. 3. Return the Number value that is encoded by *rawValue*. Step 7 is similar but deals with Float32 values. To me it say these things: 1) In all cases, an ES Number value (as defined in 8.1.5) is returned. 2) All IEEE NaN values are
Re: Weak event listener
WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. WeakRef will definitely not happen earlier than ES7. I do hope it will happen in ES7, but this discussion has yet to happen. On Tue, Mar 26, 2013 at 4:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Note that this requirement is conditional on a particular approach (which I still favor) to the interaction between proxies and private names, and so since that's still up in the air, the WeakSet requirement for ES6 may go away. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: WeakMap would not work in this specific case since a WeakMap cannot be iteratered. What would work here is determinism: https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. The main justification I’ve heard for WeakRef is that sometimes it’s hard to unhook observers at the point where you find you don't want them anymore. That’s plausible. I'd really appreciate some better examples of how this comes up and (especially) how WeakRef helps in practice. The References section of the strawman is just a collection of links to reactive libraries like Tangle[1], without elaboration. But if Tangle actually used weak observer semantics, even the most basic Tangle use cases would break! [2] I don't mean to pick on WeakRef. Across the board, I would love to see better motivating use cases for all proposals: less contrived, and actually illustrating the benefit of the proposal. I don’t think it’s too much to ask. The modules proposal has suddenly gone from one of the worst-motivated proposals in ES6 to perhaps the best, with scads of excellent use cases. More of that, please! -j [1]http://worrydream.com/Tangle/ [2]http://worrydream.com/Tangle/Examples/CookieExample.js Note that after the observer is hooked up, it immediately becomes unreachable (except via Tangle itself) as soon as that function returns. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Hi Jason, agree on your request for non-contrived use-cases. I wrote about the general observer pub/sub problem here: http://www.mail-archive.com/es-discuss@mozilla.org/msg21480.html Hope it helps. One specific thought below. Jason Orendorff wrote: What would work here is determinism: https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. It seems to me you want some kind of deterministic finalization or scoped destructor. That's not in the cards for JS. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Which is why it isn't the in the spec. yet. It was introduced in support of Proxy private Symbol white list, but it is still unclear whether we will have them and even if we do, it's not clear that the actual internal whitelist needs to be exposed as a WeakSet. WeakRef will definitely not happen earlier than ES7. I do hope it will happen in ES7, but this discussion has yet to happen. On Tue, Mar 26, 2013 at 4:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Note that this requirement is conditional on a particular approach (which I still favor) to the interaction between proxies and private names, and so since that's still up in the air, the WeakSet requirement for ES6 may go away. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules feedback from March 2013 meeting
On Tue, Mar 26, 2013 at 3:23 AM, Andreas Rossberg rossb...@google.com wrote:
On 25 March 2013 18:31, James Burke jrbu...@gmail.com wrote:
### Single Anonymous Export ###
Also, optimising the entire syntax for one special use case while
uglifying all regular ones will be a hard sell.
I believe this is one of the points of disconnect, at least with
people in the node and AMD communities. Single exports is regular
form, multiple export are seen as the special case.
But my main point with this section was: I was hoping that by turning
the syntax around (export for single anonymous, some other export with
label for multiple export) maybe that opened up some syntax options.
But syntax is hard, and I do not envy TC39's job to sort it all out.
Sorry if this was just noise.
As I have explained earlier on this list, destructuring import and
destructuring let are not the same. The former introduces aliases, not
new stateful bindings. This is relevant if you want to be able to
export mutable entities. So no, we cannot drop import.
Right, thank you for the reminder of the previous thread. I can see
mutable entities helping cycle cases. I am curious to know what else
it helps. But cycle cases are important, so that alone is nice.
I was hoping that with single export, since a mutable entity was a
special, new thing, it had more freedom to write the rules around it.
However, it seems different enough that it cannot not fit in with
`let` or `var`.
I wonder if this implies later assignment to the import name is not allowed:
import { decrypt } from 'crypto';
//This would be an error?
decrypt = function () {};
If so, that really drives home that it is a new special kind of thing.
In any case, thanks for your response. With that information, this is
the kind of summary I would give to node and AMD users:
* import exists because it creates something new in the language, a
reference to a mutable slot. This is really important for cycle
resolution. let and var cannot handle this type of mutable slot.
* multiple exports exists because it allows for better static
checking, and due to how import/export works with mutable slots,
allows cycles with those exports. While your community may not prefer
a multiple export style, there are others that do. Also, in some cases
there are roll up modules that aggregate an interface to multiple
module exports, and the multiple exports allows that to work even with
cycles.
* single anonymous export will be supported, so you can code all your
modules in that style and it all works out, and you even get better
cycle support when non-function exports are involved. (I have seen
cycles in node rely on function hoisting and strategically placed
require/module.exports assignment to work -- non-function exports are
harder to support with that pattern)
* node's imperative require is not deterministic enough for a general
loading solution, particularly for the web and network fetching. The
ES spec solves this by using string literals for dependencies that are
language-enforced to be top level, with System.load() for anything
that is computed dependency. The mutable slots provided by import give
robust cycle support.
* there are enough hooks in the Module Loader spec to allow node to
internally maintain its synchronous require, so it does not have to
force all modules to upgrade to a new syntax, and a good level of
interop with ES6 modules is possible.
* AMD's dependency resolution has the right amount of determinism, but
suffers from weak cycle support. It also less clear semantically since
require('StringLiteral') can be used in control structures like
if/else, but operates more like System.get('StringLiteral') --- it
just returns the cached module value, it does not trigger conditional
code loading. All require('StringLiteral') calls are effectively
hoisted to the top level for module loading purposes, which can be
surprising to the end user, particularly when coming from node.
* since the ES6 Module Loader can load scripts with the same browser
security rules as script tags (load cross domain without CORS, avoids
problems with eval, like CSP restrictions) then the need in AMD for a
function wrapper in single module per file source form goes away, and
you recover a level of indent.
* there are enough hooks in the Module Loader spec that a hybrid
AMD/ES6 loader can be made, so no need to force upgrade all your AMD
modules, it can be done over time. Since AMD's execution model aligns
pretty well with the ES6 model, it will be easy to write conversion
scripts.
### Nested modules ###
I agree with your goal, and that is why I still maintain my point of
view that modules should be denoted by regular lexically scoped
identifiers, like any good language citizen. Then we'd get the right
rules for free, in a clean, declarative manner, and wouldn't need to
reinvent the wheel continuously, through more and more operational
hacks.
Some dependencies are referenced via strings, `from
Re: Weak event listener
On 3/26/2013 1:03 PM, David Bruant wrote: I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? This is a question I had as well. An iterable WeakMap is nearly the same as a Map full of WeakRefs, is it not? Just a different API that is less usable for single references and more usable for collections. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 26/03/2013 21:26, Brandon Benvie a écrit : On 3/26/2013 1:03 PM, David Bruant wrote: I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? This is a question I had as well. An iterable WeakMap is nearly the same as a Map full of WeakRefs, is it not? Just a different API that is less usable for single references and more usable for collections. Interestingly, publish-subscribe would probably make a better use of an iterable weakset (set of observers) I think: When a publication happens, what needs to be done is tell all the (remaning) subscribers. I don't think anyone really needs the weakrefs themselves. Iterating over remaining observers seems to be enough. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit : On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Set is also shimmable on top of Map. If Set is in, there are as many reason to have WeakSets in. If WeakSets are considered as second class, so should Set. I feel Set and WeakSet fate should be bound. Which is why it isn't the in the spec. yet. It was introduced in support of Proxy private Symbol white list, but it is still unclear whether we will have them and even if we do, it's not clear that the actual internal whitelist needs to be exposed as a WeakSet. I don't understand the reluctance towards having WeakSets in spec. They have as much use as WeakMaps. Domenic wrote a couple of messages ago I have run into a few use cases for [WeakSet] (...), and was hoping it was on-track. I've had a case too and even left a comment about it [1]. We can argue whether, that's a use case more for private symbols than WeakSet, but still, weaksets sounds like an appriopriate tool for appropriate situations. David [1] https://github.com/DavidBruant/HarmonyProxyLab/blob/413a153c01b34bfc281b901b399ac09f3ca8c0d7/ES3AndProxy/ES5ObjectModelEmul.js#L57 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 26/03/2013 22:56, Mark S. Miller a écrit : Because the weak-map-maker constructor grants no privilege and can be generally accessible, whereas the weak-ref-maker grants the privilege of being able to observe the non-determinism of GC, and so should not be made accessible to code that shouldn't have such powers. It is the same reason why Maps and Sets, which are enumerable, enumerate their elements in a deterministic order. In short, separation of concerns as well as separation of privileges. If WeakMaps were granted the privilege of observing GC non-determinism via iteration, I assume it would be through a default WeakMap.prototype.@@iterator (that's how it works for Map). Removing this authority can be done by providing another WeakMap constructor with 'null' as WeakMap.prototype.@@iterator which is pretty much as much work as removing access to the weak-ref-maker. Thanks to the iterator protocol (and especially the @@iterator symbol), privileges can be kept separate, so I don't think it's a sufficient enough reason to not allow iteration over WeakMaps if WeakRefs are in. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 10:14 PM, David Bruant bruan...@gmail.com wrote: Le 26/03/2013 22:56, Mark S. Miller a écrit : Because the weak-map-maker constructor grants no privilege and can be generally accessible, whereas the weak-ref-maker grants the privilege of being able to observe the non-determinism of GC, and so should not be made accessible to code that shouldn't have such powers. It is the same reason why Maps and Sets, which are enumerable, enumerate their elements in a deterministic order. In short, separation of concerns as well as separation of privileges. If WeakMaps were granted the privilege of observing GC non-determinism via iteration, I assume it would be through a default WeakMap.prototype.@@iterator (that's how it works for Map). Removing this authority can be done by providing another WeakMap constructor with 'null' as WeakMap.prototype.@@iterator which is pretty much as much work as removing access to the weak-ref-maker. Thanks to the iterator protocol (and especially the @@iterator symbol), privileges can be kept separate, so I don't think it's a sufficient enough reason to not allow iteration over WeakMaps if WeakRefs are in. WeakRefs are *not* in ES6, because getting these privilege separation issues right is hard, and is best done after real experience using the new module system. David __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mar 26, 2013, at 2:57 PM, David Bruant wrote: Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit : On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Set is also shimmable on top of Map. If Set is in, there are as many reason to have WeakSets in. If WeakSets are considered as second class, so should Set. I feel Set and WeakSet fate should be bound. It's really a consensus based judgement call based upon perceived breadth of utility. Both Map and WeakMap provide unique primitive functionality that is useful for creating other derived abstractions. Set can be implemented in terms of Map, but is expected to be used frequently enough that a consensus emerged for providing it as a built-in. WeakMap is used much less frequently than Map but is needed because of its primitive GC behavior. If WeakSet will have even a smaller frequency of use than WeakMap and is easily expressed using WeakMap, then maybe it doesn't carry its own weight. A few usage cases may not be enough. Convince us that it's wide utility justifies, the specification, implementation, and testing overhead it adds. Which is why it isn't the in the spec. yet. It was introduced in support of Proxy private Symbol white list, but it is still unclear whether we will have them and even if we do, it's not clear that the actual internal whitelist needs to be exposed as a WeakSet. I don't understand the reluctance towards having WeakSets in spec. They have as much use as WeakMaps. Domenic wrote a couple of messages ago I have run into a few use cases for [WeakSet] (...), and was hoping it was on-track. I've had a case too and even left a comment about it [1]. We can argue whether, that's a use case more for private symbols than WeakSet, but still, weaksets sounds like an appriopriate tool for appropriate situations. David [1] https://github.com/DavidBruant/HarmonyProxyLab/blob/413a153c01b34bfc281b901b399ac09f3ca8c0d7/ES3AndProxy/ES5ObjectModelEmul.js#L57 I'm not sure why you didn't just define yourself a WeakSet shim based upon a WeakMap ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. What process needs to be followed before people will believe that Weak References are a real primitive that solves real problems? Do you need a set of broken, non-functional 'real world' applications written in JS that work in a customized version of V8/SpiderMonkey that has WRs? Do you need more verbose descriptions of use cases than previously provided? I can try to provide more justification than I did previously if this is necessary; I wasn't aware that it was. I totally understand that security concerns and the limited number of hours in the day have caused WRs to be postponed until ES7 or later (though this makes me annoyed for obvious reasons), but if WRs as a useful feature are somehow in such question that people are suggesting they are unnecessary, I want to know how they got into this position and how to fix it. The question of whether the non-determinism is justified is a hard one, of course. Right now applications that need WRs aren't JS applications, so WRs only pull their weight if it is worthwhile to have those applications brought into the browser (instead of remaining in native execution environments like NaCL or being emulated by a custom garbage collector implementation inside of emscripten with typed arrays acting as a virtual heap). I can't answer the question of whether iterable WeakMaps are equivalent to weak references. I do believe that with iterable WeakMaps you could determine whether a given object has been collected, but I am having a hard time imagining how one could performantly implement a Weak Reference via an iterable WeakMap. The most obvious implementation would be to create a single-key WeakMap for every Weak Reference, and treating the reference as dead when the map contains 0 items. This would certainly 'work', but seems like a rather roundabout way of solving the problem. With an iterable WeakSet you'd at least be reducing the overhead, so that might be alright. If this roundabout solution could get into ES6, then I suppose I would probably prefer it to real WRs in ESsome larger digit, because I prefer solving customers' problems now to solving the problems of future customers later. Thanks, -kg On Tue, Mar 26, 2013 at 1:03 PM, David Bruant bruan...@gmail.com wrote: Le 26/03/2013 20:25, Jason Orendorff a écrit : On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: WeakMap would not work in this specific case since a WeakMap cannot be iteratered. What would work here is determinism: https://gist.github.com/**jorendorff/5245857https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. I'm not entirely sure I understand your code snippet. Is withListener some equivalent of Node's once [1][2]? If so, then I agree, but, we're back to a debate earlier this month starting at [3] (implicitly forked). From the previous discussions, my understanding of the problem that weakrefs are expected to solve is automated cascading of GC, that is, a full subgraph gets collected as a result of releasing one reference assuming the convention that everyone with access to the weakref plays nice by always accessing the object via .get, and I guess via releasing the weakref (which is itself an object?) when useless. I'm still not entirely convinced whether the problem being solved is worth the non-determinism it brings along. I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? The References section of the strawman is just a collection of links to reactive libraries like Tangle[1], without elaboration. But if Tangle actually used weak observer semantics, even the most basic Tangle use cases would break! [2] The precedent of other languages was used as a justification of doing the same in JS and I guess this example is a good case of why this might not be a good argument. In JS, listeners are functions which are their own objects and keeping one hard reference imposes a different constraint than in other languages. David [1] http://nodejs.org/api/events.**html#events_emitter_once_** event_listenerhttp://nodejs.org/api/events.html#events_emitter_once_event_listener [2] https://github.com/joyent/**node/blob/**2eb847849fc133e39d64798bee0125
Re: endianness (was: Observability of NaN distinctions — is this a concern?)
On Tue, Mar 26, 2013 at 4:35 PM, David Herman dher...@mozilla.com 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/es-discuss/2012-May/022834.html The de facto reality is that there are essentially no big-endian browsers for developers to test on. Web content is being invited to introduce byte-order dependencies. DataView is usually held up as the counter-argument, as if the *existence* of a safe alternative API means no one will ever misuse the unsafe one. Even if we don't take into account human nature, Murphy's Law, and the fact that the web is the world's largest fuzz tester, a wholly rational developer may often prefer not to use DataView because it's still easier to read out bytes using [ ] notation instead of DataView methods. I myself -- possibly the one person in the world who cares most about this issue! -- accidentally created a buggy app that wouldn't work on a big-endian system, because I had no way of testing it: https://github.com/dherman/float.js/commit/deb5bf2f5696ce29d9a6c1a6bf7c479a3784fd7b In summary: we already agreed on TC39 to close this loophole, it's the right thing to do, and concern about potential performance issues on non-existent browsers of non-existent systems should not trump portability and correctly executing existing web content. I am disappointed that this decision was made without input from both of the editors of the typed array spec and disagree with the statement that it is the right thing to do. -Ken Dave This was not the plan of record on TC39. The plan was to fix the semantics as little-endian. On Mar 25, 2013, at 6:00 PM, Brendan Eich bren...@mozilla.com wrote: Right, thanks for the reminder. It all comes back now, including the how to write correct ending-independent typed array code bit. /be On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote: On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was there ever a resolution as to whether or not TypedArray [[Set]] operations need to use a cannonical endian-ness? Search for byte order at https://www.khronos.org/registry/typedarray/specs/latest/. I had already search for endian with similar results. It says that the default for DataViews gets/sets that do not specify a byte order is big-endean. It doesn't say anything (that I can find) about such accesses on TypedArray gets/sets. Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE to match dominant architectures, while DataViews are BE to match packed serialization use-cases. Ken, did something get edited out? No. The typed array views (everything except DataView) have used the host machine's endianness from day one by design -- although the typed array spec does not state this explicitly. If desired, text can be added to the specification to this effect. Any change in this behavior will destroy the performance of APIs like WebGL and Web Audio on big-endian architectures. Correctly written code works identically on big-endian and little-endian architectures. See http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a detailed description of the usage of the APIs. DataView, which is designed for input/output, operates on data with a specified endianness. -Ken ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
Kenneth Russell wrote: On Tue, Mar 26, 2013 at 4:35 PM, David Hermandher...@mozilla.com 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/es-discuss/2012-May/022834.html The de facto reality is that there are essentially no big-endian browsers for developers to test on. Web content is being invited to introduce byte-order dependencies. DataView is usually held up as the counter-argument, as if the *existence* of a safe alternative API means no one will ever misuse the unsafe one. Even if we don't take into account human nature, Murphy's Law, and the fact that the web is the world's largest fuzz tester, a wholly rational developer may often prefer not to use DataView because it's still easier to read out bytes using [ ] notation instead of DataView methods. I myself -- possibly the one person in the world who cares most about this issue! -- accidentally created a buggy app that wouldn't work on a big-endian system, because I had no way of testing it: https://github.com/dherman/float.js/commit/deb5bf2f5696ce29d9a6c1a6bf7c479a3784fd7b In summary: we already agreed on TC39 to close this loophole, it's the right thing to do, and concern about potential performance issues on non-existent browsers of non-existent systems should not trump portability and correctly executing existing web content. I am disappointed that this decision was made without input from both of the editors of the typed array spec and disagree with the statement that it is the right thing to do. First, my apologies to Dave for forgetting the May decision. I was looking in the wrong place for a record of that decision! Second, I understand Ken's point of view (old SGI hacker here) but have to question it on the grounds Dave raises: no one is testing, so there are very likely to be latent little-endian dependencies in deployed code today. So why not codify this? Because it might penalize big-endian systems? The IP protocols use big-endian byte order (owing to the pre-Intel big-endian architectures of IMPs and early Internet machines) and so penalize Intel machines, and we take the hit (and it's small on modern super-scalar CPUs). Ken, a couple of questions: 1. Do you know of any big-endian systems with market share that host JS implementations? It would be great to have a list. 2. Independent of the answer to (1), today's web browsers run on little-endian systems and that has very likely created a de-facto standard. If we codify it, we make the small to empty set of big-endian systems pay a price. Why is this the wrong thing for typed arrays but the right thing (in reverse! majority-architectures penalized) for the IP protocol suite? /be -Ken Dave This was not the plan of record on TC39. The plan was to fix the semantics as little-endian. On Mar 25, 2013, at 6:00 PM, Brendan Eichbren...@mozilla.com wrote: Right, thanks for the reminder. It all comes back now, including the how to write correct ending-independent typed array code bit. /be On Mar 25, 2013, at 4:33 PM, Kenneth Russellk...@google.com wrote: On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eichbren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: BTW, isn't cannonicalization of endian-ness for both integers and floats a bigger interop issue than NaN cannonicalization? I know this was discussed in the past, but it doesn't seem to be covered in the latest Khronos spec. Was there ever a resolution as to whether or not TypedArray [[Set]] operations need to use a cannonical endian-ness? Search for byte order at https://www.khronos.org/registry/typedarray/specs/latest/. I had already search for endian with similar results. It says that the default for DataViews gets/sets that do not specify a byte order is big-endean. It doesn't say anything (that I can find) about such accesses on TypedArray gets/sets. Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE to match dominant architectures, while DataViews are BE to match packed serialization use-cases. Ken, did something get edited out? No. The typed array views (everything except DataView) have used the host machine's endianness from day one by design -- although the typed array spec does not state this explicitly. If desired, text can be added to the specification to this effect. Any change in this behavior will destroy the performance of APIs like WebGL and Web Audio on big-endian architectures. Correctly written code works identically on big-endian and little-endian architectures. See http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a detailed description of the usage of the APIs. DataView, which is designed for input/output, operates on data with a
Re: Weak event listener
On Tue, Mar 26, 2013 at 11:22 PM, Kevin Gadd kevin.g...@gmail.com wrote: OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. What process needs to be followed before people will believe that Weak References are a real primitive that solves real problems? Do you need a set of broken, non-functional 'real world' applications written in JS that work in a customized version of V8/SpiderMonkey that has WRs? Do you need more verbose descriptions of use cases than previously provided? I can try to provide more justification than I did previously if this is necessary; I wasn't aware that it was. I totally understand that security concerns and the limited number of hours in the day have caused WRs to be postponed until ES7 or later (though this makes me annoyed for obvious reasons), but if WRs as a useful feature are somehow in such question that people are suggesting they are unnecessary, I want to know how they got into this position and how to fix it. The question of whether the non-determinism is justified is a hard one, of course. Right now applications that need WRs aren't JS applications, so WRs only pull their weight if it is worthwhile to have those applications brought into the browser (instead of remaining in native execution environments like NaCL or being emulated by a custom garbage collector implementation inside of emscripten with typed arrays acting as a virtual heap). I can't answer the question of whether iterable WeakMaps are equivalent to weak references. I do believe that with iterable WeakMaps you could determine whether a given object has been collected, but I am having a hard time imagining how one could performantly implement a Weak Reference via an iterable WeakMap. The most obvious implementation would be to create a single-key WeakMap for every Weak Reference, and treating the reference as dead when the map contains 0 items. This would certainly 'work', but seems like a rather roundabout way of solving the problem. With an iterable WeakSet you'd at least be reducing the overhead, so that might be alright. If this roundabout solution could get into ES6, It can't, because it raises all the hard issues raised by weak-refs. We are not going to add issues this deep to ES6 at this date. We've already postponed easier issues to ES7. then I suppose I would probably prefer it to real WRs in ESsome larger digit, because I prefer solving customers' problems now to solving the problems of future customers later. Thanks, -kg On Tue, Mar 26, 2013 at 1:03 PM, David Bruant bruan...@gmail.com wrote: Le 26/03/2013 20:25, Jason Orendorff a écrit : On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: WeakMap would not work in this specific case since a WeakMap cannot be iteratered. What would work here is determinism: https://gist.github.com/**jorendorff/5245857https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. I'm not entirely sure I understand your code snippet. Is withListener some equivalent of Node's once [1][2]? If so, then I agree, but, we're back to a debate earlier this month starting at [3] (implicitly forked). From the previous discussions, my understanding of the problem that weakrefs are expected to solve is automated cascading of GC, that is, a full subgraph gets collected as a result of releasing one reference assuming the convention that everyone with access to the weakref plays nice by always accessing the object via .get, and I guess via releasing the weakref (which is itself an object?) when useless. I'm still not entirely convinced whether the problem being solved is worth the non-determinism it brings along. I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? The References section of the strawman is just a collection of links to reactive libraries like Tangle[1], without elaboration. But if Tangle actually used weak observer semantics, even the most basic Tangle use cases would break! [2] The precedent of other languages was used as a justification of doing the same in JS and I guess this example is a good case of why this might not be a good argument. In JS, listeners are functions which are their own objects and keeping one hard reference imposes a different constraint than in other languages. David [1]
memory safety and weak references
Patrick Walton send me this link to a fascinating approach to exploiting weak references in engines using conservative stack scanning to discover the address of objects: https://github.com/justdionysus/gcwoah I don't fully grok all the details, but IIUC the attacker sprays the heap with objects that it holds weak references to, synthesizes a fake reference as an integer, triggers a conservative GC, and then uses the state of the weak references to figure out which object lived at that address. As a concrete example of how this can be used to do bad things: in conjunction with an exploit that allows jumping to an arbitrary memory location, this would effectively enable arbitrary code execution. One immediate takeaway: Mark deserves serious kudos, because Dionysus was not able to figure out how to use this attack on WeakMaps. He explicitly mentions the work on WeakMaps and credits them for having been well designed for security. Well done! But we need to take this into account as we consider what to do about weak references in ES7. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: memory safety and weak references
Interestingly, I wonder if the idea of only collecting weak references between turns is immune to such attacks, since it's not possible to have a bogus reference on the stack between turns, where there is no stack. Dave On Mar 26, 2013, at 5:55 PM, David Herman dher...@mozilla.com wrote: Patrick Walton send me this link to a fascinating approach to exploiting weak references in engines using conservative stack scanning to discover the address of objects: https://github.com/justdionysus/gcwoah I don't fully grok all the details, but IIUC the attacker sprays the heap with objects that it holds weak references to, synthesizes a fake reference as an integer, triggers a conservative GC, and then uses the state of the weak references to figure out which object lived at that address. As a concrete example of how this can be used to do bad things: in conjunction with an exploit that allows jumping to an arbitrary memory location, this would effectively enable arbitrary code execution. One immediate takeaway: Mark deserves serious kudos, because Dionysus was not able to figure out how to use this attack on WeakMaps. He explicitly mentions the work on WeakMaps and credits them for having been well designed for security. Well done! But we need to take this into account as we consider what to do about weak references in ES7. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: memory safety and weak references
David Herman wrote: Patrick Walton send me this link to a fascinating approach to exploiting weak references in engines using conservative stack scanning to discover the address of objects: https://github.com/justdionysus/gcwoah I don't fully grok all the details, but IIUC the attacker sprays the heap with objects that it holds weak references to, synthesizes a fake reference as an integer, triggers a conservative GC, and then uses the state of the weak references to figure out which object lived at that address. As a concrete example of how this can be used to do bad things: in conjunction with an exploit that allows jumping to an arbitrary memory location, this would effectively enable arbitrary code execution. Dion did the JITSpray paper at BlackHat 2010: One immediate takeaway: Mark deserves serious kudos, because Dionysus was not able to figure out how to use this attack on WeakMaps. He explicitly mentions the work on WeakMaps and credits them for having been well designed for security. Well done! Yes, and somehow Andreas Gal and Andrew McCreight's impl in SpiderMonkey / Firefox resisted Dion's hashtable-growth timing channel attack. Double kudos, even if luck! (This needs more investigation, though.) But we need to take this into account as we consider what to do about weak references in ES7. Definitely. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: memory safety and weak references
Brendan Eich wrote: Dion did the JITSpray paper at BlackHat 2010: This paper is very hard to find now! I downloaded a copy, but I'm not sure about protocol. Breadcrumbs that time out for me are at http://www.woodmann.com/forum/archive/index.php/t-13412.html /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
Dmitry, thank you for prototyping and benchmarking this. There should be no question that a slowdown of 25% is too high a cost to pay. Allen's analysis earlier in the thread indicates that no spec changes are necessary in order to allow multiple bit patterns to be used when storing NaNs into Float32Array and Float64Array. Can this topic be laid to rest? -Ken On Tue, Mar 26, 2013 at 12:14 PM, Dmitry Lomov dslo...@google.com wrote: I would like to add some perf numbers to this discussion, if I may. I have implemented a quick patch for V8 that implements NaN normalization on Float64Array store. V8 does not use NaN boxing, so from implementation perspective NaN normalization is not required by V8. In my test, the perf penalty for Float64Array store is 25% (on ia32 architecture in optimized regime, using sse2 instructions). I am attaching the test and my patch for your perusal (the patch should easily apply to v8's bleeding_edge). It feels like the performance hit is a very considerable factor here, especially given that typed arrays are all about fast math. Results on my machine: Normalized stores: $ ./out/ia32.release/d8 float-array.js Start 14033 msec Start 14059 msec Start 13983 msec Start 13979 msec Non-normalized stores: $ ./out.baseline/ia32.release/d8 float-array.js Start 11197 msec Start 11207 msec Start 11207 msec Start 11253 msec Dmitry On Tue, Mar 26, 2013 at 7:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 26, 2013, at 1:29 AM, Oliver Hunt wrote: Ok, I'll try to go over this again, because for whatever reason it doesn't appear to stick: If you have a double-typed array, and access a member: typedArray[0] Then in ES it is a double that can be one of these values: +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec. There are no signaling NaNs, nor is there any exposure of what the underlying bit pattern of the NaN is. So the runtime loads this double, and then stores it somewhere, anywhere, it doesn't matter where, eg. var tmp = typedArray[0]; Now you store it: typedArray[whatever] = tmp; The specification must allow a bitwise comparison of typedArray[whatever] to typedArray[0] to return false, as it is not possible for any NaN-boxing engine to maintain the bit equality that you would otherwise desire, as that would be trivially exploitable. When I say security and correctness i mean it in the can't be remotely pwned sense. Given that we can't guarantee that the bit pattern will remain unchanged the spec should mandate normalizing to the non-signalling NaN. --Oliver Oliver, Let's look at actual ES6 spec. language and see if there is actually anything you would like to see changed. The encoding of NaNs is only discussed in three places: Section 8.1.5, first paragraph says: The Number type has exactly 18437736874454810627 (that is, 264253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 2532) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value. (Note that the NaN value is produced by the program expression NaN.) In some implementations, external code might be able to detect a difference between various Not-a-Number values, but such behaviour is implementation-dependent; to ECMAScript code, all NaN values are indistinguishable from each other. This is very old text, most of which dates to ES1. It is defining the ES Number type, which is an abstraction, not an actual bit-level encoding. To me it say these things: 1) Unlike the the IEEE 64-bit floating point type. The ES Number type has only a single NaN value. 2) An implementations are free to internally encode the Number type any why it desires (as long is it observably conforms to all the requirements of section 8.1.5). 3) In particular, an implementation might have multiple internal bit patterns all of which correspond to the single NaN element of the Number type. 4) A corollary of 3) is that implementation are not required to internally canonicalize NaNs, that is an implementation level design decision. 5) Implementations are not required to canonicalize NaNs when they are passed or otherwise made visible to non-ES code. Hence such code may be able to observe details of the NaN encoding, including whether or not a canonical NaN value is used internally by the ES implementation. Is there anything you think should change in the above specification text? Section 15.13.5.1.3 defines the GetValueFromBuffer abstraction operation which is currently the only place in the ES6 spec. where a ES Number value is retrieved from an ArrayBuffer. Step 8 of the specification algorithm is: 8 If type is “Float64” , then rawValue is interpreted, taking into accont the value of
Re: giving up on NaN, with one patch
On Tue, Mar 26, 2013 at 10:15 PM, David Herman dher...@mozilla.com wrote: ## Fix 2: Patch the semantics of writing non-writable properties I agree with Sam that writing to a non-writable property is silly. We can fix the semantics so that it doesn't actually modify the value if SameValue holds. The only observable difference should be this NaN issue, which is what we wanted to fix in the first place. I'm fine with either fix, but note that if we go with Fix 2, there's a finer distinction in the language than SameValue. Jeff Walden pointed out that the semantics don't actually have this bug -- see the ValidateAndApplyPropertyDescriptor algorithm, which doesn't update in the SameValue case. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: giving up on NaN, with one patch
On 3/26/2013 7:19 PM, Sam Tobin-Hochstadt wrote: On Tue, Mar 26, 2013 at 10:15 PM, David Herman dher...@mozilla.com wrote: ## Fix 2: Patch the semantics of writing non-writable properties I agree with Sam that writing to a non-writable property is silly. We can fix the semantics so that it doesn't actually modify the value if SameValue holds. The only observable difference should be this NaN issue, which is what we wanted to fix in the first place. I'm fine with either fix, but note that if we go with Fix 2, there's a finer distinction in the language than SameValue. Jeff Walden pointed out that the semantics don't actually have this bug -- see the ValidateAndApplyPropertyDescriptor algorithm, which doesn't update in the SameValue case. Indeed, and my earlier test showed that V8, in fact, does not change the value of an immutable property given two different NaNs (silently ignores the attempt to change). As I said, in V8 it IS possible to hide values in NaNs, but this doesn't violate any invariants. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
