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 |
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. |
03:48 | <Jack Works> |
|
03:52 | <snek> | thats cool |
05:11 | <Kris Kowal> | this reminded me of $_ in Perl |
06:59 | <snek> | thats cool |
12:55 | <annevk> |
Pointer? |
17:58 | <ljharb> |
|
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 |