On Tue, Mar 26, 2013 at 10:29 AM, Oliver Hunt 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 // f
On Mar 27, 2013, at 1:56 PM, David Herman wrote:
> 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.
If you could induce an
Old SGI-hacker-me is on board with spec'ing as-is. Thanks,
/be
On Mar 26, 2013, at 7:02 PM, Kenneth Russell wrote:
> 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 thre
On Mar 26, 2013, at 7:19 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Mar 26, 2013 at 10:15 PM, David Herman 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 i
On 3/26/2013 7:19 PM, Sam Tobin-Hochstadt wrote:
On Tue, Mar 26, 2013 at 10:15 PM, David Herman 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 modif
On Tue, Mar 26, 2013 at 10:15 PM, David Herman 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
I'm ready to surrender on the NaN issue, so long as we fix the loophole Mark
described.
While SpiderMonkey has demonstrated that it's possible to do
read-canonicalization efficiently, the lack of write-canonicalization is still
detectable. Apparently different Math operations use internal opera
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 Float
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
_
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 s
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 wrote:
> Patrick Walton send me
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
ob
On 03/26/2013 08:48 AM, Sam Tobin-Hochstadt wrote:
> 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 val
On Tue, Mar 26, 2013 at 11:22 PM, Kevin Gadd 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 si
Kenneth Russell wrote:
On Tue, Mar 26, 2013 at 4:35 PM, David Herman wrote:
[breaking out a new thread since this is orthogonal to the NaN issue]
While the Khronos spec never specified an endianness, TC39 agreed in May 2012
to make the byte order explicitly little-endian in ES6:
https:/
On Tue, Mar 26, 2013 at 4:35 PM, David Herman wrote:
> [breaking out a new thread since this is orthogonal to the NaN issue]
>
> While the Khronos spec never specified an endianness, TC39 agreed in May 2012
> to make the byte order explicitly little-endian in ES6:
>
> https://mail.mozilla.org
[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
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 wea
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 t
On Tue, Mar 26, 2013 at 10:14 PM, David Bruant 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
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
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 WeakS
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 Map
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
sa
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
On Tue, Mar 26, 2013 at 3:23 AM, Andreas Rossberg wrote:
> On 25 March 2013 18:31, James Burke 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 di
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
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:
ht
Le 26/03/2013 20:25, Jason Orendorff a écrit :
On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson
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 deterministi
On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson
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
impleme
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 wrote:
> On
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
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: +Infiniti
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
interope
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
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
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 en
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] = shouldBeImm
On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron wrote:
>
>
>
> On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola
> 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
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
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
heari
On Tue, Mar 26, 2013 at 9:46 AM, Tom Van Cutsem wrote:
> 2013/3/26 Juan Ignacio Dopazo
>
>> 2013/3/25 Erik Arvidsson
>>
>>> 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
>
On Tue, Mar 26, 2013 at 3:54 AM, Mark S. Miller 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 no
>
> 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
"A
2013/3/26 Juan Ignacio Dopazo
> 2013/3/25 Erik Arvidsson
>
>> 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 p
2013/3/25 Erik Arvidsson
> 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-dis
>
> 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.
I agree with this. I don't think that the concatenation scenario provides
a good reason to hold off on lexical
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 l
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
On 25 March 2013 18:31, James Burke 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() {}
>
On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski
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 alwa
On Tue, Mar 26, 2013 at 9:54 AM, Mark S. Miller 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 wrote:
>>
>>>
>>> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock
>>> 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 wrote:
>
>>
>> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock
>> wrote:
>>
>> >
>> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
>> >
>> >> Right, thanks
53 matches
Mail list logo
