2024-05-02
[09:35:21.0980] <bakkot>
https://github.com/tc39/ecma262/pull/2683 is rebased and just needs stamps now


2024-05-04
[20:52:57.0424] <bakkot>
syg: I made you an issue https://github.com/tc39/ecma262/issues/3320

[21:03:48.0911] <bakkot>
(I would do it myself but I can't actually figure out what the definitions of those terms is supposed to be)


2024-05-06
[08:37:47.0974] <shu>
got it, will take care of it


2024-05-07
[07:41:25.0421] <bakkot>
I am going to close https://github.com/tc39/ecma262/pull/3322 unless anyone particularly wants this change

[08:57:01.0826] <shu>
+1

[08:57:09.0238] <shu>
bakkot: i don't get the build failure on https://github.com/tc39/ecma262/actions/runs/8977191619/job/24655470100?pr=3321 locally, ideas?

[08:57:51.0886] <bakkot>
shu: that build failure is for the prior commit; addressing my comments fixed it

[08:58:37.0168] <shu>
ah doh

[08:58:40.0167] <shu>
i didn't reload the tab

[08:58:52.0699] <shu>
new commits show up with reload but i guess the checks don't get updated

[09:01:01.0118] <bakkot>
yup

[09:01:13.0522] <bakkot>
which is a bit silly but oh well

[13:19:56.0387] <jmdyck>
Given 3322, we should maybe have a sentence saying that function summaries are (in general) incomplete / imprecise / non-normative.

[16:30:10.0785] <Michael Ficarra>
they are normative and correct, just not complete, which I think most people would intuitively understand


2024-05-13
[14:16:39.0798] <ljharb>
i'm going to be migrating the tc39 CI stuff (deploy preview, primarily) to a different AWS setup (along with the Begin folks). at some point there'll be a few hours downtime, i'll try to ping here beforehand, but if you notice problems please do lmk.

[14:29:47.0821] <shu>
copy, thanks for heads up

[14:31:30.0120] <Chris de Almeida>
> <@ljharb:matrix.org> i'm going to be migrating the tc39 CI stuff (deploy preview, primarily) to a different AWS setup (along with the Begin folks). at some point there'll be a few hours downtime, i'll try to ping here beforehand, but if you notice problems please do lmk.

DNS impact?

[14:32:20.0608] <ljharb>
it’ll require a dns change to be coordinated with the migration yes, i meant to ping you to ask who’s making those changes now :-)


2024-05-18
[17:03:09.0474] <Michael Ficarra>
this PR needs another approval: https://github.com/tc39/ecma262/pull/3139

[17:05:34.0375] <Michael Ficarra>
it's holding up https://github.com/tc39/ecma262/pull/3274

[17:06:12.0614] <Michael Ficarra>
also, I'm gonna add a new "integration point" label for changes that affect our spec integration interface

[17:08:40.0380] <Michael Ficarra>
nvm, I see we already have a "layering" label

[17:08:44.0204] <Michael Ficarra>
there's so many labels!


2024-05-21
[10:58:16.0351] <bakkot>
ljharb: https://github.com/tc39/ecma262/actions/runs/9177009670/job/25233618298?pr=3332

[11:11:05.0282] <ljharb>
thanks, on it

[11:11:07.0146] <ljharb>
 * thanks, on it now

[11:13:35.0513] <ljharb>
(i switched to esbuild and it doesn't bundle by default; it's fixed now)

we can peg that action to the "v1" or "v2" branches if we want, that'll be safer than "main"

[16:17:32.0786] <bakkot>
shu: do you want to stamp esmeta bumps like https://github.com/tc39/ecma262/pull/3325

[16:17:36.0727] <bakkot>
or should we just mark as ready

[16:26:44.0084] <shu>
nope, happy to not stamp


2024-05-22
[13:42:54.0354] <bakkot>
I have a conflict 2:30-3 today, will join late if you are still there

[13:42:59.0569] <bakkot>
or we could move it to 3

[13:50:44.0251] <shu>
happy to move to 3

[13:50:56.0002] <shu>
Michael Ficarra?

[13:51:30.0707] <Michael Ficarra>
3:00-4:00 Pacific?

[13:51:33.0260] <Michael Ficarra>
I can do that

[14:04:16.0294] <shu>
i can't do 3-4, i can do 3-3:30

[14:13:21.0779] <Michael Ficarra>
okay well hopefully we can get through everything in that time, then


2024-05-23
[10:47:38.0266] <Michael Ficarra>
woah what is going on with the highlighting of aliases in `String.prototype.padStart`?

[10:48:05.0959] <Michael Ficarra>
clicking on `maxLength`/`fillString` in that built-in also highlights all following aliases with the same name?

[10:48:12.0172] <Michael Ficarra>
this isn't the behaviour elsewhere

[10:50:55.0757] <shu>
it must be because the AOs are nested under the same section

[10:51:13.0999] <shu>
PadStartImpl is 22.1.3.17.1, and the padStart method is 22.1.3.17

[10:51:19.0666] <shu>
that is pretty misleading though

[11:30:57.0374] <Michael Ficarra>
yeah that seems broken

[11:31:26.0937] <Michael Ficarra>
@bakkot:matrix.org can you look into it?

[11:35:48.0960] <bakkot>
it just highlights everything in the clause with that name: https://github.com/tc39/ecmarkup/blob/fd938c8a4da2dca309f8c54a72d8c8616f5da009/js/menu.js#L640-L653

[11:36:18.0187] <bakkot>
I guess it should avoid descending into subclauses?

[11:36:28.0342] <shu>
yeah i'd just un-nest them

[11:36:42.0271] <shu>
coming up with more complex rules seems more complicated

[12:00:45.0371] <jmdyck>
un-nesting the nested clauses would make AOs siblings of intrinsic functions, which we almost never do

[12:03:14.0609] <jmdyck>
The only exception I can find is in https://tc39.es/ecma262/#sec-uri-handling-functions, which contains 4 functions followed by 3 AOs.

[12:09:47.0547] <jmdyck>
(https://tc39.es/ecma262/#sec-properties-of-the-promise-constructor also contains 3 cases where an AO is followed by a sibling *anonymous* built-in function, but anon built-ins are weird)


2024-05-24
[13:31:02.0460] <Michael Ficarra>
I

[13:31:16.0348] <Michael Ficarra>
* I'm asking Ecma for an Oxford English Dictionary license

[13:31:53.0032] <Michael Ficarra>
sorry, licence lol

[13:47:58.0740] <shu>
michael ficarra, unmasked

[13:49:28.0263] <Michael Ficarra>
I usually use non-American spellings, but licence/defence/etc have never jived with me

[14:19:34.0067] <Michael Ficarra>
we have steps with IDs but no references to those IDs

[14:19:37.0564] <Michael Ficarra>
should we remove the IDs?


2024-05-25
[17:38:43.0791] <Michael Ficarra>
I sent a PR for ^


2024-05-28
[11:19:30.0163] <Michael Ficarra>
I've started working on documenting our editorial conventions: https://github.com/tc39/ecma262/wiki/Editorial-Conventions

[11:19:41.0127] <Michael Ficarra>
I'd like to reserve some time to talk about it at tomorrow's editor call

[11:59:12.0530] <bakkot>
Probably don't need to worry about documenting things ecmarkup enforces?

[12:02:15.0766] <Michael Ficarra>
I think it's a mix

[12:02:32.0650] <Michael Ficarra>
some things are still good to know because they get our editorial philosophy across better

[12:03:01.0843] <Michael Ficarra>
certainly some things are not worth occupying your brain until/unless you make that mistake and ecmarkup fixes it for you

[12:06:30.0889] <bakkot>
I'm thinking specifically "denote all characters literally, using HTML entities only as required by HTML syntax"

[12:06:50.0776] <bakkot>
and someday the list/record spacing though right now ecmarkup doesn't handle those as well as I'd like

[12:08:57.0526] <bakkot>
(specifically: spacing is handled by the formatter, whereas the more advanced parser capable of recognizing lists/records is only used for linting. the more advanced parser skips `<del>` and inlines `<ins>`, because that's how you want the linter to work, but that means it's unsuitable for formatting. I just need to update it to retain that information somewhere that the linter will ignore it.)

[13:08:27.0621] <Michael Ficarra>
I'm happy to draw the line a bit different, but I'm sure there are going to be things that are checked by ecmarkup that we'll still want to communicate


2024-05-29
[19:11:21.0729] <Michael Ficarra>
okay I've gone through all of the "establishes editorial conventions"-marked PRs and issues and filled out the page

[19:11:45.0551] <Michael Ficarra>
it's obviously going to be a WIP for a while, but at least it gives us a better place to start collecting and documenting our conventions


2024-05-30
[17:05:28.0193] <Michael Ficarra>
@jmdyck:matrix.org in case it wasn't clear, you are also welcome to contribute to the editorial conventions wiki page

[17:05:58.0468] <Michael Ficarra>
I'm sure there's a bunch of things you've normalised over the years that don't have a "establishes editorial conventions"-marked PR associated

[17:38:43.0458] <jmdyck>
It's a wiki, so I figured I was allowed, but it's good to be welcomed.

[17:44:06.0723] <jmdyck>
But, like I indicated in the meeting chat, I don't get the divisions there. Like, almost everything under "Phrasing Conventions" is stuff that would appears in algorithms (some *only* in algorithms).

[18:46:51.0135] <jmdyck>
 * But, like I indicated in the meeting chat, I don't get the divisions there. Like, almost everything under "Phrasing Conventions" is stuff that appears in algorithms (some _only_ in algorithms).

[03:26:02.0944] <Michael Ficarra>
don't worry too much about the taxonomy, it was just what worked for me so far

[12:48:24.0172] <bakkot>
implemented the canonicalize-collection-key change: https://github.com/tc39/ecma262/pull/3337/commits/7fee27138d5e261ba4f1cca4b88b8e7bea4440b6

[12:48:27.0542] <bakkot>
if that looks good this PR is ready

[13:19:25.0248] <Michael Ficarra>
marked


2024-05-31
[18:08:30.0248] <jmdyck>
re 3337 changing `SameValueZero(_p_.[[Key]], _key_) is *true*` to `_p_.[[Key]] is _key_`, I think that should be `SameValue(_p_.[[Key]], _key_) is *true*` according to editorial convention

[18:17:56.0562] <bakkot>
ah yeah I suppose so

[18:18:40.0756] <jmdyck>
i can submit a quick PR?

[18:43:25.0576] <bakkot>
if you are so inclined, go for it

[18:43:35.0590] <bakkot>
otherwise I will get to it eventually

[18:53:14.0710] <jmdyck>
done