| 00:27 | <snek> | is it reasonable for implementations to throw an error for Array.prototype.sort.call({length: Infinity})? currently jsc and quickjs get stuck in an infinite loop, spidermonkey and xs raise an error, and v8 and engine262 hard crash. i assume the two that get stuck in an infinite loop will eventually throw or crash either way. |
| 00:28 | <bakkot> | we currently underspecify resource limits in general; in practice most resource limits eventually hit a RangeError or something similar |
| 00:28 | <bakkot> | or a panic, in some cases |
| 00:29 | <bakkot> | so, yes, it's reasonable although not strictly allowed by the specification |
| 05:02 | <Michael Ficarra> | it would be nice if we stopped pretending implementations have infinite resources some day |
| 05:57 | <Meghan Denny> | i think its less about pretending limits dont exist and more about letting those limits be implementation defined |
| 05:58 | <Meghan Denny> | or host/environment defined |
| 06:25 | <Meghan Denny> | saying more about what happens when those limits are reached could still be useful tho, if thats what u mean |
| 06:25 | <Meghan Denny> | read it back again |
| 08:41 | <littledan> | I think we do currently let them be implementation-defined, and the main questions are:
|
| 14:00 | <Richard Gibson> | related: https://github.com/tc39/ecma262/issues/2623 |
| 14:23 | <snek> |
|
| 14:24 | <annevk> | Should have made new ArrayBuffer(too-large) crash rather than throw. |
| 14:25 | <snek> | are we using crash with a different meaning than I'm used to |
| 14:26 | <Meghan Denny> | i take crash to mean in a way that stops all js execution but not the whole page; like html would still be interactable |
| 14:27 | <snek> | intentional and controlled vm halt sounds ok |
| 14:27 | <snek> | I'm referring to like v8 just std::abort()ing somewhere in the heap allocator, which is not great |
| 14:30 | <annevk> | That's not how people are thinking about it as far as I know. The complete website would crash. It's all rather intermingled so it's not even clear to me you could split it that way. |
| 14:33 | <Bradford Smith> | The links to the notes docs for the last meeting on https://github.com/tc39/Reflector/issues/527 all point to empty documents. What happened here? I need to check the notes for the 3rd day, because I didn't attend that one. |
| 14:42 | <Michael Ficarra> | @Bradford Smith The version history shows someone cleared them out on July 4th. We should probably revert back to the previous version. Ping the chairs about it on the Reflector thread. |
| 14:46 | <Bradford Smith> | @Bradford Smith The version history shows someone cleared them out on July 4th. We should probably revert back to the previous version. Ping the chairs about it on the Reflector thread. |
| 15:05 | <littledan> | no it has to kernel panic or it doesn't count |
| 15:05 | <littledan> | it invokes the HCF instruction |
| 15:05 | <Andreu Botella> | bah, that's nothing, it has to actively fry the hardware |
| 17:03 | <Ashley Claymore> | the google doc being cleared is usually a sign that the text has been moved to another doc, usually just before the notes PR |
| 17:03 | <Ashley Claymore> | to avoid people making edits that will get ignored as it's too late to edit |
| 19:56 | <Bradford Smith> | the google doc being cleared is usually a sign that the text has been moved to another doc, usually just before the notes PR |
| 19:59 | <Bradford Smith> | It's not a big deal, really. I'm scheduled to give a summary of the meeting to a group at work in a couple of hours. I'll just tell them about the parts I did attend. |
| 20:00 | <Bradford Smith> | At this point I don't have time to spend reading the notes even if they suddenly became available. |
| 20:24 | <Ashley Claymore> | Yeah. Unfortunate timing! |
| 20:43 | <Michael Ficarra> | it's not a perfect process, unfortunately 🫤 |
| 20:59 | <Chris de Almeida> | So, I guess it's just my bad luck that I need to read the notes in the time between the docs being wiped and the final notes being posted. Drat. |