| 02:15 | <ljharb> | mmarchini: would "cause" interact with stack traces at all? |
| 02:18 | <devsnek> | this sounds like an application of AggregateError |
| 02:19 | <devsnek> | robpalme: ^ |
| 02:40 | <mmarchini> | devsnek oh that might be a good idea to explore |
| 02:42 | <mmarchini> | ljharb: on how they are displayed maybe (not the content of .stack, but what is printed by the gmail/runtime), I don’t think it will directly affect the stack trace structure |
| 02:43 | <ljharb> | mmarchini: what is printed is the stack itself? Or do you mean it’d affect the toString |
| 02:48 | <mmarchini> | I wouldn’t expect any of the error properties to be affected, but: 1) the runtime will have the option to print all the error chain when something is uncaught 2) user land will be able to transverse the chain to handle as it sees fit |
| 02:49 | <mmarchini> | How is aggregatorerror printed today? What’s the result of .toString on an aggregatorerror? |
| 03:58 | <ljharb> | mmarchini: impl-defined, but expectation is that it’s something like a combo of the toStrings of all the errors |
| 16:16 | <bradleymeck> | do we have a shared survey service (survey monkey, Google/MS forms, etc) we use to ask questions about proposals? We had the research call today and I realized I didn't know if we did. |
| 16:39 | <keith_miller> | ljharb: I believe JSC's stack is the stack where we created the error. Not a combo of the different errors. Is the combo preferred? |
| 16:44 | <ljharb> | keith_miller: for the .stack, that's what i'd expect, but for the .toString, i'd expect something creative :-) |
| 16:44 | <devsnek> | toString is specified |
| 16:44 | <ljharb> | keith_miller: but there's no requirement or anything, it's just that i'd want, when debugging, an aggregate error to show me in my logs some of the info about the .errors |
| 16:45 | <devsnek> | it is .stack where you'd have per-engine creativity |
| 16:45 | <ljharb> | devsnek: oof, you're right |
| 16:45 | <keith_miller> | Oh, I think the console has all the errors in an expandable thing. |
| 16:45 | <ljharb> | i forgot we got rid of AggregateError.prototype.toString |
| 16:45 | <ljharb> | nvm then |
| 16:45 | <devsnek> | we need to support AggregateError in node's inspect |
| 17:47 | <drousso> | isn't `stack` customizable? |
| 17:51 | <devsnek> | stack isn't part of the spec |
| 18:12 | <ljharb> | drousso: it's not customizable by users tho |
| 18:12 | <drousso> | it is in Safari |
| 18:13 | <drousso> | and it's respected by Web Inspector |
| 18:13 | <ljharb> | oof |
| 18:13 | <ljharb> | how? |
| 18:13 | <ljharb> | i know safari has `.displayName`, which is sad for the stacks proposal (unless yall are willing to remove it) |
| 18:14 | <drousso> | wdym "how"? |
| 18:14 | <ljharb> | like how do i customize it |
| 18:14 | <ljharb> | or do you mean i can just stick any `.stack` string on it |
| 18:15 | <drousso> | yes |
| 18:15 | <drousso> | it's just a string |
| 18:15 | <drousso> | and Web Inspector will parse it to generate a trace UI |
| 18:15 | <ljharb> | ah ok |
| 18:16 | <ljharb> | that's just an inspector thing then, not something the stacks proposal has to worry about |
| 19:37 | <keith_miller> | ljharb: Is there a reason not to respect the .displayName for the stacks proposal? |
| 19:37 | <keith_miller> | at least in the inspector? |
| 19:37 | <ljharb> | keith_miller: because no other browser does it and it complicates the spec :-) |
| 19:38 | <ljharb> | keith_miller: iow, if safari won't remove it then we'll definitely have to figure out how to specify it, but the easiest solution is to remove this thing that's in no other browser |
| 19:38 | <ljharb> | (easiest for me, at least :-p ) |
| 19:38 | <keith_miller> | ljharb: To be fair, I don't think we can remove it. We probably have too many internal clients relying on it |
| 19:38 | <ljharb> | keith_miller: things that can't change to setting the `name` instead? |
| 19:39 | <ljharb> | i presume displayName predates configurable function names |
| 19:39 | <keith_miller> | ljharb: I mean, we *maybe* could get first party apps to fix themselves but I doubt third party apps will do that. |
| 19:40 | <keith_miller> | Also does the stacks proposal only look at the .name when .stack is accessed? |
| 19:40 | <keith_miller> | If not, that's gonna be a no-go |
| 19:40 | <ljharb> | keith_miller: right but third party apps all presumably work on other browsers, no? |
| 19:40 | <keith_miller> | not on iOS |
| 19:40 | <ljharb> | ah k |
| 19:40 | <ljharb> | the entire stack contents are generated at error creation time |
| 19:40 | <keith_miller> | oh, yeah, that's not gonna fly |
| 19:41 | <ljharb> | um, why not? |
| 19:41 | <keith_miller> | that's a huge perf it |
| 19:41 | <keith_miller> | hit* |
| 19:41 | <ljharb> | you don't actually have to generate them obv |
| 19:41 | <keith_miller> | even accessing the .name property would probably be a big perf hit |
| 19:41 | <ljharb> | perf hit in a thrown exception case? |
| 19:41 | <ljharb> | hm |
| 19:41 | <keith_miller> | most exceptions don't look at the stack |
| 19:41 | <keith_miller> | especially in things like Speedometer |
| 19:42 | <ljharb> | right but i mean, why is there perf sensitivity in error cases |
| 19:42 | <devsnek> | there's perf sensitivity in everything |
| 19:42 | <keith_miller> | sites throw a *lot* of exceptions |
| 19:42 | <ljharb> | what do other browsers do here? |
| 19:43 | <keith_miller> | not sure |
| 19:43 | <ljharb> | like, if i make an error inside a function, and then change the function's name in a setTimeout to the timestamp, can i figure out roughly when .stack was first accessed? |
| 19:43 | <devsnek> | in which case specifically |
| 19:43 | <keith_miller> | IIRC, v8 is lazy dunno about SM though |
| 19:43 | <ljharb> | v8 has the "prepareStackTrace" thing but iirc there's an open issue to make it eager, per the proposal |
| 19:44 | <keith_miller> | ljharb: Yeah, you can tell, I think |
| 19:44 | <ljharb> | eesh, ok |
| 19:44 | <ljharb> | i *really* wish we'd been able to specify the structure and not the contents as an interim step :-/ |
| 19:44 | <keith_miller> | ljharb: even worse, I think there are cases where we know you're likely to look at the stack and generate it eager |
| 19:44 | <devsnek> | generating the structure would take time too |
| 19:45 | <keith_miller> | We also generate it when a function is going to get GCed |
| 19:45 | <keith_miller> | So you can tell if a GC happened on your function in the trace |
| 19:45 | <devsnek> | O.o |
| 19:46 | <ljharb> | devsnek: by specify the structure i mean the format, meaning "how many frames" or "what's in them" would be left implementation-defined for now |
| 19:46 | <ljharb> | but 1 or 2 delegates blocked and insisted that any proposal 100% standardize the existing .stack |
| 19:46 | <devsnek> | what's the difference between the format and the contents |
| 19:47 | <ljharb> | specifying the format means you can reliably parse it |
| 19:47 | <keith_miller> | To be fair, IIRC, we only do the GC thing if the .name isn't a getter. So it's not like we are running code. |
| 19:47 | <ljharb> | specifying the contents talks about things like the function name, GC'd functions, wording, etc |
| 19:47 | <devsnek> | i don't understand how those are different |
| 19:47 | <keith_miller> | Although, that doesn't change the observability of it |
| 19:48 | <ljharb> | devsnek: the format of a regular expression is in the spec, the contents of regular expressions aren't |
| 19:48 | <devsnek> | ya but like |
| 19:48 | <devsnek> | if you say |
| 19:48 | <ljharb> | devsnek: the format of a JS program is in the spec, the contents aren't, etc |
| 19:49 | <devsnek> | do you mean like you would start by saying |
| 19:49 | <devsnek> | `at (IdentifierName)` and then later say `at ({function.name})` |
| 19:49 | <ljharb> | no |
| 19:49 | <ljharb> | the current spec says the format is https://tc39.es/proposal-error-stacks/#sec-getstackstring |
| 19:50 | <devsnek> | that looks like contents to me |
| 19:50 | <ljharb> | it's not |
| 19:50 | <ljharb> | it doesn't care if it's an identifier name or not |
| 19:50 | <ljharb> | it just says "at something" |
| 19:50 | <ljharb> | the structure is all the slots; the contents is what's in those slots. |
| 19:50 | <devsnek> | it says it has to be frame.[[Name]] |
| 19:50 | <ljharb> | which can be any string |
| 19:51 | <ljharb> | specifying the contents would be saying "it's a function name" or something |
| 19:51 | <devsnek> | i see |
| 19:51 | <devsnek> | that's not really parsable then lol |
| 19:51 | <devsnek> | assuming an adversarial frame.[[Name]] anyway |
| 19:51 | <ljharb> | well sure, it's an interim step |
| 19:52 | <ljharb> | it means you'd be able to parse "what engines actually do" |
| 19:52 | <ljharb> | it just also means an engine would be free to deviate if they were malicious |
| 19:52 | <devsnek> | yeah i see what you mean now |
| 19:58 | <ryzokuken> | stupid question, but is it okay for any delegate to merge things into tc39/notes? |
| 19:58 | <ryzokuken> | I saw a really "nice" PR by rkirsling here: https://github.com/tc39/notes/pull/69 |
| 19:58 | <ryzokuken> | so I approved it, but didn't know if I should just go ahead and merge. |
| 19:59 | <ryzokuken> | (or leave for the chair group to actually do the honors) |
| 23:23 | <ljharb> | MylesBorins: https://github.com/tc39/process-document/pull/29#issuecomment-682240037 seems like a github bug, any chance you could help it get to the right person? :-D |