2024-11-06 [08:06:17.0611] I'm not going to be able to make editor call today. We got snowed in and I'm single-parenting this week, so I have to watch the baby all day. [08:10:43.0181] and next week I'll be travelling home from wasmcon during editor call, so I'll also miss that one [14:28:49.0297] Michael Ficarra: https://tc39.es/ecma262/#sec-asynciterator-interface, under Table 80, the Note refers to "AsyncIterators". Should 3459 have changed that to "async iterators" ? [14:30:29.0763] yes, it looks like we missed that one [14:30:31.0258] PRs welcome [14:31:42.0776] I could add a commit to 3454 [14:50:53.0398] https://www.felixcloutier.com/x86/movd:movq [15:26:49.0078] @jmdyck:matrix.org 3454 has already been approved by @bakkot:matrix.org and myself, I'd rather it be separate [15:27:05.0321] speaking of, @shuyuguo:matrix.org you should also approve https://github.com/tc39/ecma262/pull/3454 2024-11-07 [16:38:23.0214] ok [16:41:39.0049] stamped [12:22:49.0791] @shuyuguo:matrix.org @bakkot:matrix.org thoughts on making Call's argument list parameter mandatory? https://github.com/tc39/proposal-upsert/pull/65 [12:27:30.0957] even though we do omit the arguments list a decent amount in 262, I think it's a bit of a footgun [12:29:10.0158] and an explicit empty list makes it a little harder for a reader to make the analogous mistake [12:39:45.0759] I am OK with it as long as you're volunteering to find and update every downstream spec again [12:54:27.0231] I think we should audit the AOs that have optional arguments at the moment and do all the ones we want to do in one go [12:54:52.0817] I don't want to do this for Call and then next month do it again for another one [13:14:33.0405] i don't think the implicit argument list is the cause of that footgun in upsert PR [13:14:45.0777] i'd prefer to not have to write empty lists personally [13:15:19.0423] like, in that PR, the footgun is that the author forgot the 2nd argument is the receiver, not the argument [13:48:12.0649] yeah but if it was mandatory, ecmarkup should be able to warn the author about it [13:48:21.0259] when it's optional, ecmarkup just lets it happen [13:51:18.0775] oh i see, okay [13:51:32.0973] then i am ok with it as well given what kevin said 2024-11-08 [21:16:33.0426] shu: do you want to review https://github.com/tc39/ecma262/pull/3394 or is it good to go 2024-11-11 [10:30:21.0950] stamped, i had just missed this 2024-11-13 [11:29:29.0184] reminder: I won't be able to make editor call today [12:08:28.0987] I'm down with a cold; syg let's just cancel today's 2024-11-14 [14:00:11.0516] so I added `content-visibility: auto` to the spec in hopes to make it load faster: https://michaelficarra.github.io/ecma262-content-visibility-auto/ [14:00:35.0665] and while the initial load is a bit faster, it is horribly laggy and jumps around all over the place when following in-page links [14:01:24.0827] @shuyuguo:matrix.org maybe ecma262 is a case study worth sharing with your colleagues https://web.dev/blog/css-content-visibility-baseline [14:02:19.0788] we already did in https://github.com/tc39/ecmarkup/pull/263 [14:02:32.0095] CSS diff is here: https://github.com/tc39/ecmarkup/compare/content-visibility-auto [14:20:10.0894] we tried that and last time it was really bad [14:20:24.0063] i don't know if chrome's or any other browser's implementation of the feature was at fault or what [14:20:30.0010] but it was like unusably bad [14:20:31.0636] it did load fast [14:23:57.0184] yeah it's so bad [14:24:06.0464] I'll try other browsers and see if it's better [14:25:33.0065] okay it's really slow in Safari, but at least in-document links work properly [15:03:50.0368] and Firefox is the worst of them all, it seems [15:18:24.0085] It works fine in Firefox for me [15:25:20.0690] > <@jmdyck:matrix.org> It works fine in Firefox for me in-document links go to the right place? 2024-11-15 [19:02:38.0675] more or less. Sometimes the target is at top-of-screen, sometimes a little down from there. [10:14:10.0566] i think i fixed the ipr check for realsies this time https://github.com/tc39/ecma262/pull/3480 2024-11-20 [06:45:36.0218] shu: https://github.com/tc39/ecma262/pull/2924 could also use review [06:45:45.0362] I updated it to do a different thing than it says in the description 2024-11-21 [16:35:01.0433] @bakkot:matrix.org explain this: https://github.com/tc39/ecmarkup/blob/main/src/Spec.ts#L1878-L1887 [16:36:18.0703] lol [16:36:30.0533] I mean, that one is necessary because ecmarkup outputs utf8 [16:37:01.0556] significantly predates me https://github.com/tc39/ecmarkup/commit/ce5fcdd77cda052fdadc93b0f6bf12f69ecf2f98 [09:28:35.0790] before i merge the pending things, could perhaps https://github.com/tc39/ecma262/pull/3480 land so i don't have to manually check the IPR pre-merge anymore? [09:30:17.0971] I'm not interested in reviewing it, so if @bakkot:matrix.org says it's good, it's fine by me [09:30:36.0157] yeah ship it [09:36:54.0997] @bakkot:matrix.org wanna stamp https://github.com/tc39/ecma262/pull/3487 if you approve of that plan? [09:55:51.0027] wfm [10:11:13.0492] ljharb: https://github.com/tc39/ecma262/pull/2924 should land as one commit [10:11:27.0992] ah ok, will fix [10:11:50.0593] as is the second one is basically reverting the first; no reason to have both [11:19:49.0375] shu: https://github.com/tc39/ecma262/issues/3117 we can just pull the `1. Let type be TypedArrayElementType(typedArray).` into the abstract closure, yeah? that way it won't happen until after the validation. and it's pure so that's allowed even inside of a read-modify-write modification function [11:20:20.0967] alternative is that we do the validation eagerly there and then allow it to be re-done in the `AtomicReadModifyWrite` call [11:20:54.0295] I guess I'm fine with either [11:52:53.0648] bakkot: yeah i'd just put it into the AC [11:53:44.0997] both the type and the little endian thing don't need to be closed over, actually [11:56:01.0371] depends a little on what you are allowed to do inside of a "mathematical function", which the read-modify-write functions are supposed to be [11:56:05.0437] but I'm fine with it [11:58:58.0138] spec-wise the requirements are: They perform all their algorithm steps atomically. Their individual algorithm steps are not observable. [11:59:29.0881] both getting the type and getting the endianess satisfy both counts. implementations should understand the as-if nature that getting the type can be lifted out [11:59:45.0732] (and since obviously no RMW operations are implemented like this with a higher order function) 2024-11-25 [10:21:24.0858] we're cancelling this week's meeting, yeah? [10:38:27.0298] yep, I think I was the only one who was gonna be around 2024-11-27 [21:23:49.0810] I recall an issue having to do with `\11` escapes in regexes not being correctly specified in the case that there are fewer groups than the number evaluates to, but I can't find it now. does this ring a bell for anyone else? [21:25:13.0993] also Michael Ficarra is https://github.com/tc39/ecma262/issues/2486 done now that https://github.com/tc39/ecma262/pull/3459 landed? [00:31:56.0511] > <@bakkot:matrix.org> I recall an issue having to do with `\11` escapes in regexes not being correctly specified in the case that there are fewer groups than the number evaluates to, but I can't find it now. does this ring a bell for anyone else? i believe richard fixed that in https://github.com/tc39/ecma262/pull/2468 and related PRs? [07:02:15.0454] > <@bakkot:matrix.org> also Michael Ficarra is https://github.com/tc39/ecma262/issues/2486 done now that https://github.com/tc39/ecma262/pull/3459 landed? yes, but also https://github.com/tc39/ecma262/pull/3501 [09:17:56.0436] > <@bakkot:matrix.org> I recall an issue having to do with `\11` escapes in regexes not being correctly specified in the case that there are fewer groups than the number evaluates to, but I can't find it now. does this ring a bell for anyone else? they've been well-specified since at least ES5.1 AFAICT (it's an early error, with content in Annex B since 2015 that instead downgrades it to an octal escape or identity escape in the absence of a "u" flag) what _did_ change is `$nn` references in String.prototype.replace, for which https://github.com/tc39/ecma262/pull/3157 brought the spec into alignment with implementation reality (_$nn patterns fall back to $n when there aren't at least nn captures_) [09:18:28.0486] aha, that must be what I'm thinking of [09:18:35.0894] thanks for the reference