2022-08-02 [07:05:53.0460] ljharb: why am I a reviewer on https://github.com/tc39/ecma262/pull/2841? [07:06:02.0708] you shouldn't need editor approval to land meta PRs [08:54:46.0107] this particular approval we don't need to land at all 2022-08-03 [12:06:13.0272] i was under the impression it was needed for everything; noted for the future [12:06:18.0389] is https://github.com/tc39/ecma262/pull/2806 editorial or normative? [12:36:26.0458] ljharb: I say editorial, but let's confirm at editor call today 2022-08-04 [22:09:46.0027] Michael Ficarra: I pushed a bunch of (small) commits to https://github.com/tc39/ecma262/pull/2842 if you want to re-review 2022-08-12 [08:52:06.0731] interesting: https://es.discourse.group/t/is-support-for-subnormal-denormalized-numbers-required/1421 2022-08-13 [19:12:42.0142] does anyone have access to OED? [19:13:00.0947] it might be a problem if we use OED spelling but none of the editors can read the OED [19:13:49.0860] (trying to confirm the correct spelling of "zeros") [19:16:58.0730] My understanding is that the OED lists every spelling they're aware of, so "OED spelling" is not very restrictive. [19:21:04.0063] well apparently they have an opinion on -ize vs -ise so I assume they have further opinions [19:29:01.0601] Looks like the 1st edition of the OED only lists "zeroes", but that was almost 100 years ago. 2022-08-14 [17:12:36.0927] I took a look at the ES2022 PDF, found some rendering bugs. [20:31:43.0094] Allen made this one, so i think itโ€™d need to be emailed in to ecma 2022-08-17 [09:22:43.0487] FYI I won't be at editor call today [09:25:51.0723] for https://github.com/tc39/ecma262/issues/404, I wanted to make a call on [what we entity encode](https://github.com/tc39/ecma262/pull/2854#discussion_r947196770) to advise 402 editors [09:26:25.0994] other than that, I just wanted to ping syg for review on https://github.com/tc39/ecma262/pull/2817, https://github.com/tc39/ecma262/pull/2842, and https://github.com/tc39/ecma262/pull/2854 [13:20:51.0651] never mind, I will be there now [15:52:15.0961] it is great that we have a `/` in an AO name [15:52:36.0549] ecma262 bows to no tokenizer 2022-08-18 [19:00:39.0123] FYI in GetPrototypeFromConstructor we say "Set _proto_ to _realm_'s intrinsic object named _intrinsicDefaultProto_." which I didn't like because "named" isn't totally clear. I tried changing it to "Set _proto_ to the intrinsic object in _realm_ whose Intrinsic Name in Table 6 is _intrinsicDefaultProto_" but that doesn't work because we sometimes use the dotted notation as well, as in "%AsyncGeneratorFunction.prototype.prototype%". Thoughts on how to improve this step? Maybe just swap "named" with "referenced by"? [08:01:58.0920] Even though "referenced by" might be more in line with the pre-table-6 prose, I think it might confuse readers more than "named". (If you casually think of aliases as references, then you might read "the thing referenced by `_foo_`" as just a roundabout way of saying "`_foo_`".) [08:02:10.0420] * Even though "referenced by" might be more in line with the pre-table-6 prose, I think it might confuse readers more than "named". (If you casually think of aliases as references, then you might read "the thing referenced by `_foo_`" as just a roundabout way of saying "`_foo_`".) 2022-08-19 [11:57:46.0599] do yall agree that https://github.com/tc39/ecma262/pull/2863 is a normative spec bug? [11:58:21.0295] no, definitely editorial [11:58:50.0474] previous text was incoherent and the intent was unambiguously supposed to be the thing this PR changes it to [12:04:49.0349] aha k [12:26:24.0957] `leftShit` ๐Ÿ’€ [13:19:09.0179] the IPR check is still not working properly; as kevin predicted i'm switching from the compare API to the commits listing API. there's apparently more missing authors, so once the check will pass, i'll put up a PR for it [13:20:09.0647] bakkot: also the ecmarkup linter failed on main https://github.com/tc39/ecma262/runs/7924437508?check_suite_focus=true maybe just the minus sign messing it up? [13:29:29.0320] yeah it's just the minus sign [13:29:45.0085] let me see if I can patch that real quick [14:11:53.0601] ljharb: https://github.com/tc39/ecma262/pull/2864 2022-08-25 [22:23:02.0345] https://github.com/tc39/ecma262/pull/2872 is the fixed IPR script 2022-08-26 [14:41:51.0161] should have a harder stance and just say we don't want to define thenable 2022-08-29 [13:44:58.0478] `CreateNonEnumerableDataPropertyOrThrow`... doesn't throw https://tc39.es/ecma262/#sec-createnonenumerabledatapropertyorthrow [13:45:12.0569] should we rename it? [13:48:46.0114] hmm why is step 3 `!` there [13:49:01.0299] i would've expected `?` and the callers of `CreateNonEnumerableDataPropertyOrThrow` to be the ones adding `!` [13:49:38.0634] i originally requested that naming for symmetry with the other `CreateDataPropertyOrThrow` AO, to be used in the same way [13:59:01.0509] I would rename it [14:04:52.0470] haven't you brought this up before? [14:04:57.0186] because there are no throwing users currently? [14:05:02.0000] it was indeed named that for consistency with CreateDataPropertyOrThrow [14:05:21.0666] like it seems like a generic helper AO to me [14:05:27.0126] i see no reason to specialize it for all its current users [14:05:29.0520] re the steps, the assertion in step 1 is why step 3 can use `!` [14:05:55.0512] we could remove the assertion and change the `!` to `?`, i suspect, and then the naming would match [14:05:58.0605] i think the two consistent options are [14:06:08.0197] do what ljharb just said, or rename it [14:06:10.0751] the current state is kinda weird [14:07:10.0805] could've sworn we had an issue for this [14:07:42.0959] can't find it though [14:07:44.0749] > <@ljharb:matrix.org> we could remove the assertion and change the `!` to `?`, i suspect, and then the naming would match my preference would be this [14:08:06.0110] ah: https://github.com/tc39/ecma262/pull/2528 [14:08:27.0000] also https://github.com/tc39/ecma262/pull/2759 [16:49:04.0516] shu: if you have time to do some reviews, we're getting a pretty long list of PRs waiting on your review: https://github.com/tc39/ecma262/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+-reviewed-by%3Asyg+review%3Aapproved+-label%3A%22editor+call%22+draft%3Afalse+-label%3A%22ready+to+merge%22+-label%3A%22pending+stage+4%22+ [16:51:32.0091] thanks for the ping, will try to make some time [16:51:40.0647] been swamped for like 2 quarters now 2022-08-31 [15:22:35.0196] shu: I'm going to apply the "ready to merge" label to some of the more trivial ones that have 2 reviews (or are opened by me/Kevin and have 1 review) [15:22:52.0675] chime in if there's any that you really felt needed your review [15:31:17.0137] sgtm