2025-08-04
[12:02:49.0378] <jmdyck>
So no editors call right now?

[12:04:58.0186] <shu>
i'm in the room but nobody else

[12:05:09.0133] <shu>
do people have the link?

[12:05:24.0235] <shu>
Michael Ficarra: bakkot ^

[12:05:38.0500] <bakkot>
sorry, we are on holiday

[12:06:27.0767] <shu>
oh okay

[12:06:32.0440] <shu>
time to eat lunch

[12:06:49.0277] <shu>
oh you said as much last week, i just didn't read

[12:06:50.0068] <shu>
apologies

[12:07:24.0995] <jmdyck>
but there is one a week from now?

[12:12:12.0893] <shu>
AFAIK


2025-08-07
[13:15:46.0744] <Michael Ficarra>
what are we doing?!

[13:19:05.0639] <bakkot>
... Forbidding null and undefined?

[14:17:26.0895] <Michael Ficarra>
no, I mean using aliases `str`, `string`, and `S` all within two steps

[14:54:29.0607] <bakkot>
oh, lol

[14:54:33.0560] <bakkot>
yeah.....


2025-08-11
[09:19:46.0840] <Michael Ficarra>
@ljharb:matrix.org a couple PRs ready to merge: https://github.com/tc39/ecma262/issues?q=label%3A%22ready%20to%20merge%22%20%20is%3Aopen


2025-08-12
[17:39:00.0906] <jmdyck>
Dang, I completely forgot about the meeting today.

[18:02:16.0818] <bakkot>
Don't worry I did too


2025-08-13
[18:43:24.0461] <Michael Ficarra>
hmm somehow the editor call is on the calendar again for tomorrow? I thought we got that sorted out


2025-08-14
[12:42:31.0336] <bakkot>
stamped https://github.com/tc39/ecma262/pull/2952

[12:59:58.0824] <jmdyck>
oo


2025-08-15
[17:04:23.0650] <jmdyck>
PR #3666 un-defined 4 table-* ids, BTW.

[17:52:09.0590] <Michael Ficarra>
hmm, I guess we should add them back as oldids on their respective AOs


2025-08-18
[12:12:43.0410] <bakkot>
jmdyck ping for meeting in case you wanted to attend

[13:12:02.0780] <jmdyck>
Thanks for the ping. Once again, completely forgot about it.

[13:13:07.0725] <jmdyck>
This time slot is not working out for me.


2025-08-19
[10:34:11.0679] <Michael Ficarra>
@ljharb:matrix.org I'm still seeing the editor call at our old Wednesday timeslot on the calendar

[10:34:27.0234] <Michael Ficarra>
if it's not just me, can you move it to our new timeslot of noon Pacific on Mondays?

[15:02:55.0183] <ljharb>
whoops, sorry about that. sure

[15:15:09.0379] <ljharb>
should be done


2025-08-20
[17:42:10.0372] <Michael Ficarra>
thanks

[15:35:06.0287] <jmdyck>
In 3655, "a boolean" should be "a Boolean". (Don't have time to submit a comment.)

[16:14:22.0633] <Michael Ficarra>
added a comment for you


2025-08-25
[13:29:54.0598] <Michael Ficarra>
hmm I'm not sure our decision on #2942 works

[13:30:23.0135] <Michael Ficarra>
if all async built-in function objects are built-in function objects, then wouldn't this line permit creating an async built-in function object? https://github.com/tc39/ecma262/pull/2942/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR13965

[13:43:33.0302] <Michael Ficarra>
okay, new Lists section in editorial conventions, as discussed:


2025-08-26
[18:47:09.0008] <bakkot>
removed the version number from https://github.com/tc39/ecma262/pull/3623, should be good to go

[18:47:13.0955] <bakkot>
Michael Ficarra did you want to review/stamp?

[18:48:16.0946] <bakkot>
Yes I assumed the plan was to remove the changes to CreateBuiltinFunction because they are no longer going to be a MOP-level different kind of object

[18:48:38.0761] <Michael Ficarra>
ooh good thing we caught that before landing

[18:49:26.0956] <Michael Ficarra>
> <@bakkot:matrix.org> Yes I assumed the plan was to remove the changes to CreateBuiltinFunction because they are no longer going to be a MOP-level different kind of object

ah okay I'll try again tomorrow


2025-08-27
[14:38:26.0696] <Michael Ficarra>
at the TG5 call this morning, some EPFL researchers presented their work mechanising the RegExp section of the spec: https://github.com/epfl-systemf/Warblre

[14:39:22.0966] <Michael Ficarra>
they did this to show equivalence to their linear matching algorithm

[14:40:17.0616] <Michael Ficarra>
and at the same time proved that our spec doesn't have any assertion failures or out-of-bound accesses in that section (🎉)

[14:41:15.0759] <Michael Ficarra>
I was thinking we should invite them to an editor call to see if we could use the mechanisation to help us make refactorings, proving that they are semantics-preserving

[14:41:43.0229] <Michael Ficarra>
but first we should probably think what kind of refactoring we'd *like* to make to that section

[14:42:30.0748] <Michael Ficarra>
I know we're unhappy with it (especially @bakkot:matrix.org), but I don't know if there's any concrete plans for what we'd want

[14:43:38.0000] <Michael Ficarra>
another idea is that we could take the linear matching algorithm and derive the spec factoring from that (given we know it's semantically identical)

[14:45:41.0088] <bakkot>
my current unhappiness with the section is about the observable complexity, not the editorial specification

[14:45:48.0756] <bakkot>
we dealt with most of the glaring editorial issues

[14:46:19.0198] <Michael Ficarra>
it's still definitely weird

[14:46:57.0241] <Michael Ficarra>
like these are weird https://tc39.es/ecma262/multipage/text-processing.html#sec-countleftcapturingparenswithin

[14:48:13.0894] <Michael Ficarra>
also, they skipped Annex B and based their work on ES2024, but I don't think either of those is significant for this work


2025-08-28
[18:15:53.0997] <jmdyck>
Are you thinking that we could refactor away the weirdness of CountLeftCapturingParensWithin?

[18:18:49.0730] <jmdyck>
Or do you just mean it's weird that we don't have a recursive op to calculate the number?

[18:27:45.0468] <jmdyck>
"based their work on ES2024": looks like 2023.

[06:37:28.0409] <jmdyck>
TC39 Events Calendar says editors call on Monday, but presumably not

[06:40:06.0683] <Michael Ficarra>
yeah next week is cancelled

[06:40:34.0041] <Michael Ficarra>
I'm going to have to get access to edit the calendar at some point

[08:31:34.0074] <ljharb>
removed the event