2025-02-05
[12:00:01.0824] <shu>
i'll be missing today's meeting, dentist

[12:00:14.0928] <shu>
swear to god if i need another crown

[12:46:53.0491] <ljharb>
i might miss it also (parent teacher confs) but i'm still working on the upload-artifact migration PR, which will unblock any pending merges. once i get the build preview fixed i'll merge it and then drain the queue.

if things become urgent, lmk and we can ignore the failing build preview and i'll drain the queue before fixing it.

[12:49:01.0254] <Michael Ficarra>
I don't think there's anything urgent atm


2025-02-06
[13:12:12.0347] <shu>
if kevin and i are both going to be at wasm cg next week, which is Wed Thu, maybe we should reschedule the editor call

[13:12:15.0732] <shu>
since we need to do slides etc

[15:53:04.0753] <Michael Ficarra>
oh that's right, yeah let's reschedule it for Mon or Fri

[15:55:12.0614] <bakkot>
I vote Monday


2025-02-07
[16:07:27.0193] <Michael Ficarra>
also I'll still be attending CG and research day, just virtually

[16:10:11.0656] <shu>
i can do 1pm-2pm mon

[17:31:06.0696] <bakkot>
wfm

[17:39:38.0132] <Michael Ficarra>
My Monday's a little tight. I can't do 09:00-09:30, 11:00-12:00, or 13:30-15:00.

[17:39:47.0166] <Michael Ficarra>
all times Pacific

[10:44:58.0246] <shu>
yeah my monday isn't great either, hm

[10:45:14.0701] <shu>
are you okay with 1230-1330 Michael Ficarra bakkot 

[10:47:23.0957] <Michael Ficarra>
yep

[10:48:45.0146] <bakkot>
sure

[10:50:19.0042] <shu>
moved the calendar item


2025-02-11
[17:28:30.0575] <Michael Ficarra>
when we say "for each X of Y", it means *sequentially in list order*, right?

[17:28:35.0191] <Michael Ficarra>
do we say that anywhere?

[17:29:19.0790] <bakkot>
we do say that in most places I think

[17:29:48.0206] <bakkot>
I guess we only do that for the integer ranges

[17:29:51.0754] <bakkot>
not for lists as often

[17:30:42.0460] <Michael Ficarra>
what I'm asking is: do we say anywhere that when we say "for each X of Y", it means more specifically "sequentially in list order", or is one supposed to just know that?

[17:30:57.0402] <Michael Ficarra>
because I don't think it's obvious, but there's also places that depend on that meaning

[17:32:24.0114] <Michael Ficarra>
RegExp.escape also depends on that meaning

[17:32:31.0712] <bakkot>
I feel like we talked about doing that but I can't find it

[17:32:58.0145] <Michael Ficarra>
maybe we have an issue?

[17:33:46.0209] <Michael Ficarra>
if I had the choice, I would probably prefer explicitly saying "sequentially, in list order" wherever we depend on that over just defining every for-each to have that meaning

[17:34:00.0798] <Michael Ficarra>
that way we can distinguish cases where it matters from those where it doesn't

[17:34:11.0289] <bakkot>
aha

[17:34:11.0740] <bakkot>
https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-list-and-record-specification-type

[17:34:15.0280] <bakkot>
When an algorithm iterates over the elements of a List without specifying an order, the order used is the order of the elements in the List.

[17:34:37.0705] <Michael Ficarra>
❤️ thank you

[17:35:01.0483] <bakkot>
https://github.com/tc39/ecma262/pull/2152

[17:38:23.0575] <Michael Ficarra>
okay well some day it might be nice to differentiate those that depend on order from those that don't, but the prose in 6.2.2 is good enough for me for now

[18:08:06.0333] <jmdyck>
In https://github.com/tc39/ecma262/pull/2152#issuecomment-679174888, I wondered if the spec was already doing that differentiation. But I suspect it wasn't.

[19:18:22.0421] <Michael Ficarra>
yeah @jmdyck:matrix.org I suspect the places where we used to explicitly state "in list order" were no different than other places, just authored by different people at different times


2025-02-13
[08:54:10.0276] <Michael Ficarra>
@shuyuguo:matrix.org @bakkot:matrix.org should we add JSON modules and import attributes to this slide? https://docs.google.com/presentation/d/1jgEaNaq6W7hZSKQILZ1F2sC1jTjRKwwnuqCGgi6iyQc/edit

[08:54:28.0277] <Michael Ficarra>
* @shuyuguo:matrix.org @bakkot:matrix.org should we add JSON modules and import attributes to this slide? https://docs.google.com/presentation/d/1jgEaNaq6W7hZSKQILZ1F2sC1jTjRKwwnuqCGgi6iyQc/edit#slide=id.g3338c5ce129_0_1

[08:55:12.0601] <bakkot>
yeah

[08:55:28.0598] <bakkot>
though ideally we just get them in before the meeting and put them on the normative updates slide

[09:25:01.0938] <ljharb>
if i can't get the build preview done soon, i'll just merge the queue through it, so anything in the queue will be merged before the meeting.

[10:07:22.0031] <jmdyck>
Is 3391 going to merge at about the same time as 3057, or will there be a gap?

[10:36:22.0053] <ljharb>
likely about at the same time. the gap would be rebase + CI time

[10:41:25.0232] <jmdyck>
ok thanks

[10:53:01.0415] <shu>
yeah agree


2025-02-14
[14:06:49.0489] <shu>
i'm looking at https://github.com/tc39/ecma262/pull/3391/files in the review view, and the comments don't really make sense where they are

[14:07:00.0599] <shu>
is it a GH bug because the line numbers moved around?

[14:21:51.0500] <jmdyck>
GH would need to be pretty smart to 'properly' place comments that were made on earlier versions of the file, wouldn't it?

[14:25:00.0907] <shu>
it shows "outdated"

[14:25:05.0191] <shu>
like, it could just not display those?

[14:42:21.0801] <ljharb>
then how would anyone read them?

[14:51:22.0768] <shu>
why would i want to read outdated comments at the wrong source location in the file view, when viewing a more recent version of the diff?


2025-02-15
[16:32:15.0044] <Chris de Almeida>
'outdated' refers to the code state now vs when the comment was made.  it doesn't mean the comment is outdated.  the code change that resulted in the comment being marked as 'outdated' may have addressed the comment, sufficiently or insufficiently, or it may not have been related to the comment at all


2025-02-17
[10:40:00.0293] <Chris de Almeida>
putting KG down for 5m editors' report tomorrow.  lmk if delta


2025-02-18
[08:32:02.0438] <bakkot>
shall I stamp https://github.com/tc39/ecma262/pull/3057 and https://github.com/tc39/ecma262/pull/3391 as ready to merge?

[09:21:16.0119] <shu>
i'd say so

[09:21:44.0996] <shu>
i don't know about those esmeta failures but review-wise they both have all of our reviews, and no outstanding comments

[09:21:53.0023] <shu>
though technically #3057 still needs your stamp bakkot 


2025-02-21
[15:17:42.0504] <bakkot>
Michael Ficarra do you want to review https://github.com/tc39/ecma262/pull/3353 ?


2025-02-22
[18:12:06.0379] <Michael Ficarra>
yes, I will get to it soon


2025-02-26
[14:33:29.0849] <bakkot>
ljharb: you gonna make the editor call this week? we got a bunch of stuff to get in

[14:37:21.0217] <ljharb>
I’m in a call rn but after that I’ll move through the queue - anything to discuss, or just stuff piling up from today?

[14:48:11.0743] <bakkot>
just stuff from today I think

[14:48:20.0330] <bakkot>
we do want to get it all finalized so we can cut the spec formally

[14:51:52.0395] <bakkot>
ljharb for https://github.com/tc39/ecma262/pull/3382 I stamped it as ready but there's an alias rename to do which we figured it would be easiest for you to just do when landing

[14:52:20.0741] <ljharb>
sounds good, thanks for the heads up

[15:33:27.0652] <bakkot>
once everything tagged lands, spec is ready to cut

[15:33:59.0514] <Michael Ficarra>
es2025 🎉


2025-02-27
[16:14:09.0134] <ljharb>
can yall confirm i rebased https://github.com/tc39/ecma262/pull/3226 correctly?

[16:17:34.0651] <shu>
looks right to me

[16:17:38.0840] <shu>
there was a conflict?

[16:18:09.0281] <ljharb>
yeah, i think from the PR that changed some concrete methods into AOs

[16:19:18.0984] <shu>
ah right, HasVarDeclaration had no other overrides and was just for globals

[09:57:16.0264] <Richard Gibson>
the build preview seems to be broken: https://github.com/tc39/ecma262/actions/runs/13572427688/job/37940538089

[09:57:24.0655] <Richard Gibson>
* build preview CI seems to be broken: https://github.com/tc39/ecma262/actions/runs/13572427688/job/37940538089

[11:46:19.0619] <ljharb>
yep, it's been broken for awhile, since github turned off its artifacts action pre-v4

[11:46:33.0126] <ljharb>
i'm going to fix it but we haven't been letting it block merges


2025-02-28
[16:26:56.0635] <Michael Ficarra>
@bakkot:matrix.org we really need to finish https://github.com/tc39/ecmarkup/pull/600

[16:57:53.0906] <bakkot>
Michael Ficarra whenever you want

[16:58:14.0653] <bakkot>
ljharb I think we are good to cut the spec now

[16:58:30.0935] <bakkot>
the things we marked ready yesterday were all the things we intended to get in

[16:58:46.0337] <Michael Ficarra>
> <@bakkot:matrix.org> Michael Ficarra whenever you want

are you going to be not sick on Monday? I can do Monday

[16:58:56.0591] <bakkot>
I mean, I live in hope

[16:59:03.0014] <bakkot>
but yes probably I will be better by then

[16:59:13.0969] <Michael Ficarra>
okay I'll block off the afternoon

[16:59:22.0658] <Michael Ficarra>
I hope you live until then

[17:01:30.0736] <Michael Ficarra>
> <@bakkot:matrix.org> I mean, I live in hope

definitely read this as "I'll live I hope" lol

[17:01:42.0946] <bakkot>
that too

[17:57:05.0437] <jmdyck>
In PR #3382, not all _c_ were changed to _cp_.

[18:27:24.0025] <jmdyck>
fixed by https://github.com/tc39/ecma262/pull/3546