Re: Error stack strawman

[Mark S. Miller]

On Thu, Feb 25, 2016 at 6:45 PM, Gary Guo  wrote:

> Things became more complicated when considering async & generators. For
> async calls as mentioned before somewhere in the thread, only Firefox
> Nightly build includes histories of the frame, while all other browsers
> don't. It could be useful to include that in stack trace, but it will then
> be a special case to a general rule, so not all functions are treated as
> the same. Also, including this information can be costly. Similar reasoning
> about usefulness can be extended to generators & async functions. Shall we
> include a copy of history frames at the time the function is called? (If we
> use FF's SavedFrame format, then in this case both `parent` and
> `asyncParent` will be set) Again, this will be costly as well. In these two
> cases, it could be useful to developers if these information are available,
> but generally these will be costly to collect. Making these optional can be
> a choice, by simply not including unsupported fields in the returned
> object. I suppose `isTailCall` can be made optional as well.
>

All important issues. My current stance:

  * We should separate the issue of obtaining the shallow synchronous
within-a-turn stacks from the gathering of multiple of these together into
deep stacks or graphs of asynchronous causality.

  * The getStack and getStackString apis, and the corresponding normative
optional deletable Error.prototype.stack accessor, should only provide
shallow within-turn stacks.

In thinking about how Causeway stitches these separate shallow synchronous
stacks into an overall picture of asynchronous causality, including deep
stacks, I think the next steps are something like:

  * The stack object format should contain one additional thing -- a turn
identifier, identifying the turn that stack occurred in. To avoid leaking
unnecessary implementation details, say that this turn identifier is a
large random number.

  * There be some way to declare that a certain scope of activity (realm?)
is to be instrumented, i.e., that certain significant events generate
notifications to some kind of logging apparatus. This issue already arises
with onerror and unhandled rejection notifications.

  * When instrumented, an action in one turn that schedules something to
happen in another turn also emits a log-notification containing:

* the stack of the scheduling action within the scheduling turn,
including the turn identifier of the scheduling turn.
* the turn identifier of the scheduled turn.

When the scheduling turn and the scheduled turn both happen in the same
vat, then stitching the shallow stacks together into a deep stack creates
exactly the kinds of deep stack we see on FF. However, I purposely phrased
that last bullet so that it also applies to inter-vat causality. For
example, if instrumented worker A does a postMessage to instrumented worker
B, the postMessage event in worker A logs, in A,

  * the stack in A where A did the postMessage, including the identifier of
the A turn in which this happened.
  * the identifier of the turn in worker B where this message will be
processed.

There is much more to be said and explored, but I think that would be a
start. It naturally breaks up into two separable proposals -- the first two
bullets and the rest.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack strawman

[Gary Guo]

Things became more complicated when considering async & generators.

For async calls as mentioned before somewhere in the thread, only Firefox 
Nightly build includes histories of the frame, while all other browsers don't. 
It could be useful to include that in stack trace, but it will then be a 
special case to a general rule, so not all functions are treated as the same. 
Also, including this information can be costly.

Similar reasoning about usefulness can be extended to generators & async 
functions. Shall we include a copy of history frames at the time the function 
is called? (If we use FF's SavedFrame format, then in this case both `parent` 
and `asyncParent` will be set) Again, this will be costly as well.

In these two cases, it could be useful to developers if these information are 
available, but generally these will be costly to collect. Making these optional 
can be a choice, by simply not including unsupported fields in the returned 
object. I suppose `isTailCall` can be made optional as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Questions about Proxy.[[OwnPropertyKeys]] and the List type

[saam barati]

I’m currently implementing section 9.5.11 of the spec (
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys
).
Sections 17 and 19 perform the Remove operation on the List type. How is
the Remove
operation defined? Is it defined to just delete the first instance of
something in the List or all instances?
Is this defined somewhere? (If so, I couldn’t find it. Sorry if it’s
there.) If not, maybe it’s worth defining?

Also, it appears the the algorithm defined in 9.5.11 allows for duplicate
entries to be returned by
this trap under certain circumstances (dependent on how List::Remove is
defined). Is this intended?
I think this would be the only place where [[OwnPropertyKeys]] has
duplicate entries. Maybe we should
guarantee the items are unique?

Thanks,
Saam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: non-self referencial cyclical promises?

[Benjamin Gruenbaum]

Thanks​ Raul, I understand this case better now - fixed in master
https://github.com/petkaantonov/bluebird/commit/7094e1677d79de99ba5f268785f49e9d99508e2f
- wasn't particularly hard to fix this case, no one ever complained about
it or mentioned it before so it wasn't considered.

Bluebird will now raise an error about a cyclical reference here.

Native promises should have no issue fixing this without any weak maps too.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

non-self referencial cyclical promises?

[Raul-Sebastian Mihăilă]

@Benjamin: Your example is different than Bradley's. Should be:

```
var r1, p1 = new Promise(r => r1 = r);
var r2, p2 = new Promise(r => r2 = r);
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: non-self referencial cyclical promises?

[Benjamin Gruenbaum]

Sorry, the example fiddle was before the inclusion of bluebird - I got
confused by the UI. Here: https://jsfiddle.net/cm9kvLqv/
It appears like native chrome promises also detect it (although with a less
informative error and only for one of the promises)

On Thu, Feb 25, 2016 at 10:17 AM, Benjamin Gruenbaum 
wrote:

> For what it's worth, bluebird promises detect the error and reject with:
>
> ```
> TypeError: Chaining cycle detected for promise #
> ```
>
> So it's both possible and not a performance issue. For this case, a
> WeakMap is not needed for this case. https://jsfiddle.net/41ez2b6d/ .
>
>
> > We ran into code "in the wild"
>
> Yes, while I've never run into this I've talked to several people who have
> ran into this error - so it's definitely "a thing".
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: non-self referencial cyclical promises?

[Benjamin Gruenbaum]

For what it's worth, bluebird promises detect the error and reject with:

```
TypeError: Chaining cycle detected for promise #
```

So it's both possible and not a performance issue. For this case, a WeakMap
is not needed for this case. https://jsfiddle.net/41ez2b6d/ .


> We ran into code "in the wild"

Yes, while I've never run into this I've talked to several people who have
ran into this error - so it's definitely "a thing".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss