Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

2015-09-27 Thread Mark S. Miller
On Sun, Sep 27, 2015 at 9:57 AM, Filip Pizlo wrote: > Hi Mark, > > It seems that most of the benefit for fail-faster behavior for VM errors > is security. > > To what extent do you think the security problem could be addressed by VMs > simply randomizing the point at which

Re: Weak References

2015-09-27 Thread Herby Vojčík
A naive question: don't you get working weakref by using a WeakMap and getting and setting using the same key? A naive point of view suggests that. What am I not seeing here? Herby Isiah Meadows wrote: I'm resurrecting this [1] because I have found a use case where I needed a weak reference.

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

2015-09-27 Thread Filip Pizlo
Hi Mark, It seems that most of the benefit for fail-faster behavior for VM errors is security. To what extent do you think the security problem could be addressed by VMs simply randomizing the point at which stack overflow or OOM happens? I think this would be more desirable, since it

Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

2015-09-27 Thread Mark S. Miller
[-whatwg, +es-discuss] Reposting to es-discuss, as Anne's more general question is best seen as a JS issue rather than a browser specific one On Sun, Sep 27, 2015 at 8:30 AM, Mark S. Miller wrote: > On Sat, Sep 26, 2015 at 7:34 AM, Anne van Kesteren >

Re: Weak References

2015-09-27 Thread Jordan Harband
`WeakMap` holds the *key* weakly, not the value - it holds the value strongly. If you have the key such that you can use it to get at the value, you'll always have the value. `WeakRef` is a container around a weakly held *value*, which I don't believe is possible to fully polyfill, even with

Re: Exponentiation operator precedence

2015-09-27 Thread Kevin Reid
On Thu, Sep 24, 2015 at 8:14 AM, Mark S. Miller wrote: > I like #4. Normally in a situation like this I would still argue for #1. > #4 is a complicated special case that breaks the normal pattern of operator > precedence elsewhere in the language. The need for ** is not great

Re: Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

2015-09-27 Thread Ron Waldon
Android has an older onLowMemory() callback and a newer onTrimMemory() callback: - http://developer.android.com/reference/android/content/ComponentCallbacks.html#onLowMemory () - http://developer.android.com/reference/android/content/ComponentCallbacks2.html#onTrimMemory(int ) iOS has something