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
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:
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
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 -
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
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
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
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
___
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
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
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]]
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
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
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:
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
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] =
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
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
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
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
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,
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
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
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
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:
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
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
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
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
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
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
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
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
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
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:
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
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
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
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:
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
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
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
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
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
44 matches
Mail list logo
