00:29
<ljharb>
i wanted to specify just the format, and leave the contents for a follow-on, and i was blocked until i can specify the contents too
00:50
<snek>
i wanted to specify just the format, and leave the contents for a follow-on, and i was blocked until i can specify the contents too
the contents as in the stringification?
00:50
<snek>
isn't the point of the proposal to provide structured data so that stringification doesn't need to be relied on 🤔
01:08
<ljharb>
yes.
01:09
<ljharb>
as in the exact wording of the stack trace. Which i guess would have to be in English despite the spec not specifying prose messaging.
01:09
<ljharb>
it certainly felt unreasonable and demotivating :-) . if folks feel like i could still come back and specify structure only, then I’d be happy to do that.
02:04
<Jessidhia>
Use of _ I’ve encountered is not as a black hole (void) but as a readable reference to the last thing bound.
this reminded me of $_ in Perl
03:48
<Jack Works>

idea that popped into my head a few minutes ago while looking at some debugging tooling that someone made... what if you could attach metadata to stack traces to identify specific function invocations?
for example lets say you have something like an event emitter, you could do something like

class Emitter {
  emit(name, data) {
    System.setStackMetadata(name);
    // ...
  }
}

and then in a stack trace, it would be identified as emit (event name) instead of just emit

you may want to know console.createTask
03:52
<snek>
thats cool
05:11
<Kris Kowal>
this reminded me of $_ in Perl
My sincerest apologies.
06:59
<snek>
thats cool
seems to be limited to devtools though, doesn't modify the actual stack trace
12:55
<annevk>

I think web platform folks asked for the ocean to be boiled

Pointer?

17:58
<ljharb>

I think web platform folks asked for the ocean to be boiled

Pointer?

https://github.com/tc39/notes/blob/e338ef708f553b03cf5b74dfb5a585e532991100/meetings/2019-03/mar-28.md?plain=1#L136
18:09
<annevk>
ljharb: that doesn't seem like web platform folks asking for boiling an ocean?
18:10
<ljharb>
i was explicitly asked to specify the exact text content of all stack traces
18:11
<ljharb>
what the proposal already had at that point was 100% specifying the format/structure, without locking down the contents
18:11
<annevk>
Maybe we have a different definition of "web platform folks"
18:12
<littledan>
I guess the two people in that conversation were Mathias Bynens and Till Schneidereit, who were working in JS engines at the time (but neither has that role today, so it's worth checking in with the current people)
18:14
<littledan>
but I would have expected browsers to ask for flexibility in how the stack trace is presented (e.g., to enable async stack traces, as Mathias mentioned)
18:14
<ljharb>
maybe i linked the wrong notes; as i recall it was DD and folks from v8/chrome that had the primary block
18:15
<littledan>
oh I see, he was there
18:15
<ljharb>
but the history isn't quite as important; what i stated that was agreed with was 1) do the legwork to figure out what browsers do in terms of the contents of the stack. 2) explicitly enumerate the similarities and the differences. 3) to attempt to write a spec algorithm that can allow them all and mandate one of them. 4) potentially Create a brand new structure including a preferred output. 5) ask browsers and engines that would need to make changes, what changes they may need to make.
18:15
<ljharb>
and that list is definitely boiling an ocean
18:16
<ljharb>
whereas if i were able to standardize the structure, the way would be paved for someone more motivated than i to do that list
18:16
<littledan>
what would standardizing the structure mean?
18:17
<Chris de Almeida>
apologies if I mischaracterized or misattributed any positions re: ocean boiling
18:19
<annevk>
To be fair, those five points do make a lot of sense. There is often a desire to replace the old with the new, but as the old has to be maintained forever, understanding it fully is essential.
18:22
<ljharb>
oh sure
18:22
<ljharb>
i think that's the right path forward overall. i just think the best way to get there is iteratively, and instead i was told "all or nothing"
18:22
<ljharb>
i would vastly prefer to return to the iterative approach and unblock work on those 5 points