If I understand this right, essentially the problem is that an exception
could occur when some of the involved code is not alive on the stack
(because the generator(s) are suspended), and without the ability to
capture this information, the end user has no actual knowledge of why the
exception occu
a stable sort
> all the time.
>
> On Thu, Jun 13, 2013 at 3:10 PM, Sean Silva wrote:
> > On Thu, Jun 13, 2013 at 12:16 PM, Kevin Gadd
> wrote:
> >>
> >> I don't understand why you would intentionally sidetrack a discussion
> >> about a simple p
velopers probably use jQuery and/or Underscore already to make up for the
small number of useful primitives in the JS standard library, and that's
fine.
-kg
On Thu, Jun 13, 2013 at 9:50 AM, David Bruant wrote:
> Le 13/06/2013 17:56, Kevin Gadd a écrit :
>
> I don't really care a
hreshold at which
V8 switches between stable/unstable could change at any time if they
decided the performance gains justified potentially breaking a few
applications, and then suddenly more developers would be vulnerable to this.
-kg
On Thu, Jun 13, 2013 at 9:09 AM, Andreas Rossberg wrote:
> On 13
r wrote:
> On Thu, Jun 13, 2013 at 7:01 AM, Kevin Gadd wrote:
>
>> Even if stable sorts don't get required, it would make sense to require
>> that a given implementation is either always stable or always not stable.
>>
>
> How would such a requirement differ
Even if stable sorts don't get required, it would make sense to require
that a given implementation is either always stable or always not stable.
The current situation with V8 seems likely to result in subtly broken
software shipping to the web, where it works in testing environments with
small amo
Looking back through the archives, it seems like the discussion of future
disposal/cancellation trailed off without reaching a resolution. Was this
addressed in one of the face-to-face spec meetings and I missed it in the
minutes?
-kg
___
es-discuss mail
do something similar with promises, you’d return a
> disposable handle alongside your promise (i.e. `return { promise, diposable
> }` or simply `{ promise, dispose }`). You can also layer that on top of the
> promise (i.e. `promise.dispose = () => { .. }; return promise;`).
>
&g
To be honest, I haven't yet seen an explanation of why 'I no longer have
any need for the contents of this future' is not tied to the underlying
semantics of a future. Where else would it go? I agree with you that
complicating a primitive in order to support a small subset of use cases is
undesirab
> function and has a chain of 100 then()s?
>
> I certainly understand the value of cancellations in deferred computing,
> but it doesn't fit the promise model any more than the Maybe monad should
> be Nothing or Just(a) or Cancelled.
>
> Maybe that was coherent. Let me kno
Strongly agreed; however future cancellation should not be inferred to mean
that a task is cancelled. Rather, it means that the value the future
represents is no longer needed, which may implicitly result in the
cancellation of an actual operation.
To provide a simple example (from an actual appli
Even if a consequence of cancellation is rejection (I'm not sure this is
necessarily true), cancellation is different in that rejection comes from
the source of the value, which is why it's on the resolver, while
cancellation goes in the other direction - the recipient(s) of a value are
telling the
i use
for-of or similar on the generator. This is the intent, I hope?
On Tue, Apr 30, 2013 at 1:49 AM, Andy Wingo wrote:
> On Tue 30 Apr 2013 10:23, Kevin Gadd writes:
>
> > Is the reason why you wouldn't want to run finally blocks in generators
> > described elsewhere on
Is the reason why you wouldn't want to run finally blocks in generators
described elsewhere on the list? Choosing not to run a generator's finally
block is, to me at least, a very significant behavioral compromise,
especially for use cases where generators are used to approximate
coroutines (think
Something that wasn't clear to me personally until reading the last few
posts: I suspect that some of the negative reaction to unwrapping/wrapping,
and the suggestion that Future> is a meaningful construct, comes
from the mindset of static typing - not in the sense that static types
themselves are
Aren't sandboxed natives a JS technique that actually relies on cross-realm
prototype chains?
http://msdn.microsoft.com/en-us/magazine/gg278167.aspx
My understanding is that they create a separate origin in order to get
their own copies of the natives so that they can fiddle with those natives'
p
My information may be incomplete (I haven't used await since the beta of
the release that introduced it), but 'await' is part of the function's
return type/signature in C#; that is, a function that may await has a
different signature than a function that may not.
Calling a function that may await
callables...
On Sun, Apr 21, 2013 at 3:42 PM, Sam Tobin-Hochstadt wrote:
> On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd wrote:
> > if I called Object.freeze or Object.seal on a JS object would it
> actually be
> > safe to pass it to another thread and let both threads use i
For some subset of use cases I imagine shared-memory multithreading being
limited to immutable objects could do the trick. Of course, I don't know if
real immutability is actually possible in ES as currently specified - if I
called Object.freeze or Object.seal on a JS object would it actually be
sa
/ES7 seem very focused on
using object capability as a security model, you don't want passing a
Future across a boundary to give some third party the ability to fake the
result of a network request or something like that.
On Fri, Apr 19, 2013 at 3:50 PM, Tab Atkins Jr. wrote:
> On Fr
My solution for cancellation has been to allow cancellation notifications
to be bidirectional - that is, when you subscribe to completion
notifications on a Future, you can also subscribe to cancellation
notifications. Then it's possible to cancel a given future without breaking
any other listeners
I'm not sure this is a perfect match, but:
The futures library and task scheduler I've been using in my applications
for around ~5 years does unhandled error detection and delayed error
handling.
For the former, the model is that the future has an internal callback that
is fired when a consumer c
hts here that this really doesn't
seem like a 'Stream' API. It does not match the semantics of any Stream
primitive/concept I have ever encountered in an API.
On Mon, Apr 15, 2013 at 5:14 PM, Tab Atkins Jr. wrote:
> On Mon, Apr 15, 2013 at 5:06 PM, Kevin Gadd wrote:
> > I
If this is really about multiple-consumer streams, the semantics of this
proposed API are incredibly murky to me. What happens if each consumer
calls next()? Do they all get the same value out of their Future when it's
completed? Do they each randomly get one of the values pushed into the
stream? I
'new Number' and 'new String' are also functionally useful to a degree -
I've had reason to use both in my compiler's runtime library, either to
allow returning a value from a constructor or to assign properties to a
number.
It sounds like 'new Symbol' will never be functionally useful because it
One simple-ish real world example of a use case that can benefit from a
parallel sort:
It's common in games and other realtime rendering scenarios to want to sort
your queue of rendering operations by various attributes, in order to
minimize the number of hardware state changes and allow you to ba
Fancy behavior for out of range indices on Typed Arrays seems like it could
be more trouble than it's worth. Ideally, you want something that can be
cheaply implemented on native targets like x86, if not implemented for free
because it's something the runtime has to do anyway. Returning undefined
s
I previously had a discussion with someone about Typed Array sizes in
particular - at present it seems like no existing implementation of Typed
Arrays will allow you to allocate one larger than 2GB, regardless of the
actual numeric types being used. But when I did a quick scan of the Safari,
Chrome
An important distinction here - and one I think Bill and Brendan and others
have gotten at some, and I've been trying to get at - is that weak
references (and similar concepts, like weak maps and weak event listeners)
unfortunately encompass a set of different problems and end up being used
to solv
Is there a reason why DataView wasn't specified as static methods that take
an ArrayBuffer in the first place? That would solve the problem of figuring
out when/how often to create DataView instances, and eliminate the garbage
created by using DataViews.
On Tue, Apr 2, 2013 at 3:23 PM, Kenneth Ru
In that case it would be alive unless you destroyed the local variable 'x',
but in some environments the compiler is free to treat it as dead. I
believe in .NET the variable 'x' is only alive up until its last reference,
so the variable would become dead immediately after the construction of the
we
One could also argue that people using typed arrays to alias and munge
individual values should be using DataView instead. If it performs poorly,
that can hopefully be addressed in the JS runtimes (the way it's specified
doesn't seem to prevent it from being efficient).
-kg
On Sun, Mar 31, 2013 a
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
Most use cases I've personally seen for weak events would be satisfied by a
WeakMap of weak event target -> event handler. Having the event handler
itself be weak instead of the event target seems strange to me; it
introduces a bunch of nondeterministic behavior that isn't desirable -
sometimes you
Would using (...args) incur a performance penalty and impair
optimization since the argument list has to be an array now? Or is
that still better than using 'arguments.length'? Enforcing arity is a
common enough (and important, IMO) pattern that I'd be wary of doing
it using a pattern that is going
Another option for scenarios like open() where it is not cheap to
create multiple distinct iterators (each starting from the beginning),
or for scenarios where it's impossible (like a network stream) would
be to only expose an iterator in those instances, not an iterable.
Exposing an iterator would
I really don't understand why the debugger thing is being trotted out
again. It was addressed at the beginning of the thread: There are lots
of real world applications that use debugger-style introspection (in
particular, stack walking) for purposes that are not debugging.
Now, to be fair, that ma
in real applications, some of which can't be easily
implemented without it.
-kg
On Fri, Mar 8, 2013 at 2:28 PM, Kevin Reid wrote:
> On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd wrote:
>>
>> The Error.stack strawman is a great start at making Error.stack's
>> con
nting a dead snapshot of a stack, there's
> <http://wiki.ecmascript.org/doku.php?id=strawman:error_stack>, which is a
> good start. As that page notes, we should still be concerned about the
> information leak, but we can handle that well by hiding the access in a
> WeakMap.
The way caller is a single attribute of the function object arguably makes it
useless for authoring reusable code: it breaks in the presence of reentrance,
and requires you to keep an accessible reference to every function that might
want to know its caller, exposing you to leaks and making clos
Maybe I'm overlooking some past discussion on this, but if you want to
be able to generally terminate iteration in constructs like
Array.forEach (this seems like a pretty real world use-case), why not
introduce an additional argument to the forEach/etc callbacks, for an
'iteration token'?
I.e. if
I don't understand how the requestAnimationFrame approach (to
registering periodic callbacks) applies to scenarios where you want
Weak References (for lifetime management) or to observe an object (for
notifications in response to actions by other arbitrary code that has
a reference to an object). T
that do not want to be
>> extended, would like to be as fast as possible, and are loaded once and
>> never again.
>>
>> Thanks for all thoughts and info already provided, also agreed on some
>> bench.
>> I usually do that on jsPerf 'cause I don't know h
This is definitely the case. Recent performance guidance from V8
developers strongly discouraged the use of 'delete' so I've gone to
some lengths to avoid using it in my own code, mostly through design
(trying to avoid scenarios that require the deletion of attributes).
If this guidance isn't accur
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically slower
they are never faster.
The last time I asked on the mozilla and v8 bug trackers I was
informed that there is no plan to optimize for these features and that
the
On Sun, Feb 3, 2013 at 2:58 AM, David Bruant wrote:
> Let's see how the example would be with weakrefs:
>
> function Storage(){
> var storage = []
> return {
> push(e){storage.push(makeWeakRef(e))},
> last(){
> var last = storage[storage.
> I'd like to repeat something I wrote in another message: "...a very
> important point that most developers ignore or forget. GC is an undecidable
> problem, meaning that there will always be cases where a human being needs
> to figure out when in the object lifecycle it is not longer needed and
>
On Fri, Feb 1, 2013 at 2:06 AM, David Bruant wrote:
> I don't understand the connection between the lack of weak references and
> emulating a heap in a typed array.
For an algorithm that needs weak references to be correct, the only
way to implement that algorithm in JavaScript is to stop using t
leak and just have
> Caja etc blacklist use of WeakRefs but this is a discussion that we
> decided to postpone for now.
>
>
> On Thu, Jan 31, 2013 at 1:55 PM, Tab Atkins Jr. wrote:
>> On Thu, Jan 31, 2013 at 1:48 PM, Kevin Gadd wrote:
>>> A search shows some old disc
A search shows some old discussions of the topic mentioning that they
might be going in to future versions of the language, etc. But on the
other hand I've been told in response to this question before that
TC39 has a general policy against features that allow garbage
collection to be visible to ap
50 matches
Mail list logo
