2024-08-05
[19:45:13.0012] <bakkot>
neat https://es.discourse.group/t/chinese-translation-of-ecma-262-standard-completed/2100

[08:05:37.0744] <Michael Ficarra>
I have mixed feelings about community translations

[08:05:54.0709] <Michael Ficarra>
on one hand, it's great that it makes it easier and more accessible for some people

[08:06:12.0358] <Michael Ficarra>
but on the other hand, it's bound to quickly become out of date

[08:06:56.0493] <Michael Ficarra>
and we can't officially endorse it if we can't verify the translation is correct and intent-preserving (among other reasons)

[08:07:42.0223] <Michael Ficarra>
also I'm not sure if they're technically legal?

[08:07:52.0343] <Michael Ficarra>
I don't know how copyright works for this sorta thing

[08:42:35.0654] <jmdyck>
Ecma's copyright notice allows derivative works without restriction, other than reproducing the copyright notice.

[09:20:21.0352] <shu>
yes i think it is technically legal


2024-08-06
[19:02:16.0785] <Michael Ficarra>
needs approval: https://github.com/tc39/ecma262/pull/3345

[19:03:05.0570] <Michael Ficarra>
also https://github.com/tc39/how-we-work/pull/152 needs sign-off from @shuyuguo:matrix.org

[19:07:30.0710] <bakkot>
strictly speaking I don't think we own how-we-work

[19:07:52.0423] <bakkot>
though I guess it is reasonable to have editors gate wording of normative conventions

[22:13:04.0656] <ljharb>
i think it's bizarre that it's on "ecma262.com" tho

[22:13:41.0820] <ljharb>
the translation is legal but i'm not sure a deceptively official domain name is

[05:35:51.0869] <Michael Ficarra>
bakkot during plenary we decided shu would gate merging it because he requested the additional examples

[10:37:04.0088] <shu>
sorry for delay, on the queue


2024-08-08
[17:02:32.0534] <bakkot>
https://github.com/tc39/ecma262/pull/3335 landed with changes to IDs, what gives? I thought we weren't going to do that?

[17:02:50.0492] <bakkot>
(`#callCover` etc)

[17:04:12.0614] <bakkot>
 * (`#callCover` and `#parenCover`)

[17:12:18.0487] <shu>
Michael Ficarra did say he was removing them, guess some got left in?

[17:48:09.0290] <Michael Ficarra>
sorry, I only fixed the ones in html id attributes

[18:56:07.0551] <ljharb>
guess we'll need a followup?

[10:37:33.0287] <Michael Ficarra>
done: https://github.com/tc39/ecma262/pull/3384


2024-08-09
[09:44:44.0941] <Michael Ficarra>
I won't be able to make editor call next week

[09:45:20.0356] <Michael Ficarra>
@shuyuguo:matrix.org we can reschedule it (1 hour earlier or 2 hours later) or just cancel

[09:47:31.0193] <shu>
1 hour earlier wfm but always happy with fewer meetings

[09:47:45.0538] <shu>
if nothing urgent, leaning towards cancel

[10:10:27.0401] <Michael Ficarra>
if you can take a look at https://github.com/tc39/ecma262/pull/3383 before then, I'm fine with cancelling

[10:19:18.0750] <bakkot>
Michael Ficarra that PR isn't ready per my comment

[10:19:25.0432] <bakkot>
(and yours)

[10:19:45.0483] <Michael Ficarra>
yeah I know, I wanted Shu's opinion on our preferred path forward

[10:19:52.0346] <Michael Ficarra>
it's trivial to update it

[10:19:52.0557] <bakkot>
oh, ok

[10:20:10.0420] <bakkot>
I assumed we were doing the "initialize to ~suspended-start~ earlier" thing

[10:21:10.0000] <Michael Ficarra>
@bakkot:matrix.org if you're looking for something to do: https://github.com/tc39/ecma262/pull/2924

[10:21:21.0507] <bakkot>
I am not


2024-08-14
[07:13:41.0907] <Michael Ficarra>
I could use an approval on this: https://github.com/tc39/ecma262/pull/3345

[07:13:45.0886] <Michael Ficarra>
it should be otherwise ready to go

[07:51:52.0015] <shu>
Michael Ficarra: are we cancelling today?

[07:52:04.0134] <Michael Ficarra>
yep


2024-08-20
[13:54:28.0971] <Michael Ficarra>
@bakkot:matrix.org do you have an opinion on this? https://github.com/tc39/ecma262/issues/3370

[14:40:25.0415] <bakkot>
lean negative. the prose becomes hard to read without knowing the types if we do that, I think

[14:44:14.0525] <shu>
wouldn't the return type of these expressions that have "is true" or "is false" elided always be Boolean?

[14:50:09.0355] <bakkot>
well, yes, but if you're reading an english sentence it's kind of weird to encounter something which would normally be a noun and instead it's being used as a condition

[14:55:38.0213] <shu>
not sure i follow

[14:56:04.0631] <shu>
the proposal is allow elisions where it reads naturally in english, not that "is true" and "is false" be systematically dropped everywhere

[15:00:48.0437] <jmdyck>
how would you systematically drop "is false"?

[15:01:08.0804] <jmdyck>
or un-systematically?

[15:02:13.0737] <jmdyck>
like, would you change `X is false` to `it is not the case that X` ?

[15:09:40.0681] <shu>
no, you just wouldn't change it

[15:10:21.0453] <jmdyck>
So ignore mentions of eliding "is false"?

[15:10:37.0224] <shu>
i want to type e.g. "If IsFoo(foo), then" instead of "If IsFoo(foo) is true, then"

[15:10:45.0471] <shu>
oh sorry, you were specifically talking about false

[15:10:49.0925] <jmdyck>
yes

[15:10:58.0969] <shu>
hmm that's a good point, i don't see a natural way to elide "is false" at the moment

[15:12:55.0841] <jmdyck>
I'm trying out eliding "is true", modifying my pseudocode grammar to handle the result, but I'm hitting some ambiguities.

[15:14:11.0418] <shu>
ooh fun, do tell

[15:17:25.0478] <jmdyck>
later; time for food

[15:20:22.0632] <bakkot>
> <@shuyuguo:matrix.org> the proposal is allow elisions where it reads naturally in english, not that "is true" and "is false" be systematically dropped everywhere

AOs return values, which are nouns

[15:20:49.0416] <bakkot>
conditions like "x is y" are not nouns

[15:21:30.0561] <bakkot>
so it cannot read naturally unless you stop seeing the AO invocation as an AO invocation and instead read it as words based on its name

[15:21:52.0615] <bakkot>
also michael did want to drop it everywhere it sounded like

[15:23:42.0762] <shu>
i also don't want to drop it everywhere i don't think

[16:39:30.0627] <Michael Ficarra>
yeah I don't see a reason not to drop it everywhere

[16:39:38.0765] <Michael Ficarra>
it can be easily explained

[16:44:11.0184] <jmdyck>
I made the ambiguities go away, but at the expense of misparsing at least one condition.

[16:47:12.0028] <jmdyck>
In `IsLessThan`, there's a step `If _nx_ or _ny_ is *NaN*, return *undefined*.`, which required me (long ago) to add a production to my pseudocode grammar `{CONDITION} : {var} or {var} is {LITERAL}`. If I leave that production in, I get tons of ambiguities. If I take it out, no ambigs, but `_nx_ or _ny_ is *NaN*` is now parsed like `(_nx_) or (_ny_ is *NaN*)`.

[16:51:01.0732] <jmdyck>
That one step has the only instance of that production in the whole spec, so if you rewrote the condition to `_nx_ is *NaN* or _ny_ is *NaN*`, I wouldn't need the production.


2024-08-21
[17:01:50.0100] <bakkot>
changing that would be consistent with https://github.com/tc39/ecma262/pull/3330 etc

[17:02:56.0460] <jmdyck>
So I *think* eliding all `is *true*` is possible without ambiguities. Mind you, some things don't read as well, so you'd probably want to do some renaming.

[17:02:57.0158] <bakkot>
anyway I definitely do not want to drop this everywhere

[17:03:21.0073] <bakkot>
I am maybe pursuadable that we can drop it for specifically `If AO(...)` where AO is a predicate

[17:03:29.0590] <bakkot>
but personally I would be inclined not to

[17:03:41.0552] <bakkot>
especially since there's not a good way to do the negated case

[17:04:19.0182] <shu>
i also definitely do not want to drop this everywhere

[17:04:32.0015] <shu>
i basically just want to drop it for `If IsFoo()`

[17:05:40.0716] <jmdyck>
Personally, I don't much like dropping it anywhere, but I think I can deal with it, so shrug.

[17:08:50.0485] <jmdyck>
Note that there are already 11 places in the spec where we elide `is *true*`. E.g. `It is a Syntax Error if the <sub>[Tagged]</sub> parameter was not set and |NoSubstitutionTemplate| Contains |NotEscapeSequence|.`

[17:18:20.0977] <jmdyck>
Oh, I should have said earlier, I use a dynamic parsing algorithm, so it's possible for the grammar to have formal ambiguities that I don't know about, simply because the current pseudocode doesn't encounter them.

[18:16:08.0144] <Michael Ficarra>
btw I will have to leave editor call tomorrow at 15:00

[18:17:03.0049] <Michael Ficarra>
@shuyuguo:matrix.org we can start a half hour earlier if you like and are free, otherwise we'll just have to do 30 minutes

[09:31:34.0166] <Michael Ficarra>
@shuyuguo:matrix.org all your comments on this thread are duplicated https://github.com/tc39/ecma262/pull/3396#pullrequestreview-2249195201

[09:31:40.0227] <Michael Ficarra>
what did you do to make this happen?

[10:00:00.0437] <shu>
oh wow, i have no idea

[10:00:06.0541] <shu>
> <@michaelficarra:matrix.org> @shuyuguo:matrix.org we can start a half hour earlier if you like and are free, otherwise we'll just have to do 30 minutes

unfortunately i am not

[10:09:56.0692] <Michael Ficarra>
this isn't the first time it's happened to you

[10:10:03.0083] <Michael Ficarra>
something about your review workflow causes this

[10:12:32.0934] <shu>
this happened before? i don't recall

[10:13:13.0599] <shu>
wait i'm looking at this issue more lcosely, what's duplicated?

[10:13:19.0884] <shu>
 * wait i'm looking at this issue more closely, what's duplicated?

[10:13:39.0677] <shu>
are you talking about how replies to a previous review comment show up both in that original review's thread, and in the new review?

[10:14:27.0334] <shu>
i feel like that's a GH issue, and i'm using the workflow as intended. if i reply to a previous review's comment thread in a new review, and submit that review, that's what happens

[10:19:30.0977] <ljharb>
yeah that's how github works

[10:19:46.0143] <ljharb>
 * yeah that's how github works - specifically, when you reply to a comment as part of a review instead of as an immediate comment

[10:21:16.0912] <Michael Ficarra>
that's gross

[10:21:32.0838] <Michael Ficarra>
why would I want to see the replies both inline and completely out of context with no indicator that they're even replies?

[10:22:03.0742] <Michael Ficarra>
like this is useless to me

[10:22:57.0904] <shu>
https://github.com/community/community

[10:24:01.0364] <ljharb>
> <@michaelficarra:matrix.org> sent an image.

click on the timestamp and it'll jump you up to the thread.

[10:26:00.0622] <shu>
i take it F5 doesn't use GH internally? what do you use?

[10:48:48.0883] <Michael Ficarra>
we used to but we use GitLab now

[10:49:05.0179] <Michael Ficarra>
also, I think the difference is I never use the "review" feature on PRs

[10:49:15.0497] <Michael Ficarra>
and I guess I don't really see other people use it either

[10:54:09.0018] <shu>
how do you review PRs? you leave single comments one at a time?

[10:54:55.0858] <shu>
i'm used to review workflows where you leave draft comments and submit the review

[10:55:25.0516] <jmdyck>
How do people submit multiple comments in one go if not via a review?

[11:31:40.0196] <bakkot>
michael is mistaken; he definitely used the review feature and encountered other people using it

[11:32:12.0895] <bakkot>
but you only notice this if you reply to existing comments as part of a review, which is much less common

[11:32:15.0179] <Michael Ficarra>
I just do one comment at a time, dude

[11:32:21.0173] <bakkot>
impossible if you're the first review

[11:32:41.0187] <shu>
🍿

[11:32:41.0824] <Michael Ficarra>
> <@bakkot:matrix.org> but you only notice this if you reply to existing comments as part of a review, which is much less common

this is probably it

[11:33:03.0611] <shu>
does michael lack a reflexive theory of mind to understand his own workflows??

[11:34:23.0964] <shu>
> <@bakkot:matrix.org> but you only notice this if you reply to existing comments as part of a review, which is much less common

i find this surprising (but can believe) coming from Google tools, where comment threads are very common, even if just to close them as resolved with an 'Ack' or 'Done'

[11:35:52.0068] <bakkot>
you don't get the button to add a comment-reply to a review unless you're already starting a review, I think

[11:36:11.0431] <bakkot>
so if you just go through responding to comments you won't even be offered the chance

[11:36:32.0011] <shu>
yeah, i always click the Start a Review button

[11:36:38.0566] <shu>
should i not?

[11:36:49.0670] <bakkot>
¯\_(ツ)_/¯

[11:36:56.0482] <bakkot>
I don't personally care

[11:37:02.0430] <bakkot>
it is a bit silly on github's part

[12:27:01.0696] <ljharb>
i only "start a review" when i'm going to be doing one asap; i send my reply as a comment otherwise so that the reply can be read in a timely fashion, instead of whenever i get around to finishing the review

[12:34:35.0987] <jmdyck>
I submit reviews because Domenic asked me to: https://github.com/tc39/ecma262/pull/1460#issuecomment-468960387

[12:35:48.0463] <jmdyck>
 * I submit reviews rather than individual comments because Domenic asked me to: https://github.com/tc39/ecma262/pull/1460#issuecomment-468960387

[14:04:04.0887] <Michael Ficarra>
this is a really quick one that could use a second stamp: https://github.com/tc39/ecma262/pull/3375

[14:05:08.0390] <jmdyck>
editor call in ~55min?

[14:05:53.0301] <Michael Ficarra>
@jmdyck:matrix.org yes

[14:06:06.0047] <Michael Ficarra>
I actually can't even find the start review button

[14:07:17.0619] <jmdyck>
I see it when I click on a line in the diff.

[14:20:35.0195] <Michael Ficarra>
oh wow okay

[14:29:52.0265] <Michael Ficarra>
> <@jmdyck:matrix.org> editor call in ~55min?

oh wait I was confused, it is starting now

[16:13:46.0081] <bakkot>
remind me what https://github.com/tc39/ecma262/pull/2721 is waiting on? been stage 4 since april


2024-08-22
[17:50:50.0424] <ljharb>
a rebase, reviews, and a label

[18:46:00.0482] <Michael Ficarra>
nobody likes reviewing regexp PRs

[19:02:03.0281] <bakkot>
this one is easy

[19:03:17.0934] <Michael Ficarra>
okay @shuyuguo:matrix.org please review https://github.com/tc39/ecma262/pull/3383/files

[19:05:10.0896] <bakkot>
Michael Ficarra you need to correct the existing initializations and also the types of the fields

[19:05:47.0372] <Michael Ficarra>
uh what?

[19:05:53.0131] <Michael Ficarra>
did you not refresh?

[19:28:45.0819] <bakkot>
I did refresh

[19:28:47.0763] <bakkot>
did you not push?

[19:30:02.0183] <bakkot>
specifically you need to fix the table in 27.5.2 to not list undefined and remove GeneratorStart step 7

[19:30:14.0228] <bakkot>
and the analogous thing for AsyncGeneratorStart and their table

[19:30:22.0441] <bakkot>
 * specifically you need to fix the table in 27.5.2 to not list undefined, and remove GeneratorStart step 7


2024-08-23
[17:39:21.0112] <bakkot>
does anyone care to review https://github.com/tc39/ecma262/pull/3390 or can I stamp it

[18:23:59.0715] <Michael Ficarra>
🚢 it

[10:11:30.0589] <shu>
what does npm audit do?

[10:12:05.0894] <shu>
oh i see

[10:12:15.0889] <shu>
how is this useful for CI...? that's crazy

[10:12:18.0868] <Michael Ficarra>
https://docs.npmjs.com/cli/v10/commands/npm-audit

[10:15:19.0576] <Michael Ficarra>
it could be useful as its own CI action (though I guess it would go from passing to failing on its own, which is undesirable), but it definitely shouldn't happen for other actions like build or test

[10:32:54.0998] <bakkot>
apparently it's intentional though https://github.com/npm/cli/issues/2703

[10:50:41.0835] <ljharb>
it's useful when a PR would add a NEW warning. it's hugely disruptive when a new warning suddenly appears on an existing dep.

[10:50:48.0168] <ljharb>
 * it's useful when a PR would add a NEW vuln. it's hugely disruptive when a new vuln suddenly appears on an existing dep.

[10:55:41.0495] <bakkot>
when it's just a warning in setup you'll never see it either way

[11:18:39.0694] <Michael Ficarra>
yeah if it's just a warning, you'll never see it, and if it's an error, it'll just randomly pop up and get in your way as new vulnerabilities get published

[15:32:50.0698] <Michael Ficarra>
> <@bakkot:matrix.org> specifically you need to fix the table in 27.5.2 to not list undefined, and remove GeneratorStart step 7

I don't know what you mean about GeneratorStart step 7

[15:33:27.0081] <Michael Ficarra>
updated the table though, I didn't know we had already explicitly listed `undefined`

[15:34:48.0197] <Michael Ficarra>
oh I get it, it's no longer necessary since it's already in that state

[15:36:17.0463] <Michael Ficarra>
okay please review https://github.com/tc39/ecma262/pull/3383 again


2024-08-26
[09:19:11.0578] <Michael Ficarra>
@ljharb:matrix.org hold off on https://github.com/tc39/ecma262/pull/3393, the guy updated the PR after being marked as ready to merge

[09:19:28.0108] <Michael Ficarra>
@nicolo-ribaudo:matrix.org wasn't aware that we decided in editor call to not link to the archive.org snapshot

[09:19:31.0768] <ljharb>
ok, he pointed the URL at archive.org per nicolo's comment

[09:19:32.0396] <ljharb>
ah ok

[09:19:34.0539] <ljharb>
sure, lmk

[09:44:26.0936] <Michael Ficarra>
@ljharb:matrix.org since it wasn't a force-push, can you just take the first commit and drop the new one?

[09:46:44.0227] <Michael Ficarra>
also, we should probably get this one in ASAP https://github.com/tc39/ecma262/pull/3404 @shuyuguo:matrix.org

[10:32:32.0304] <ljharb>
yeah i can just drop the new commit, nbd

[10:32:39.0622] <ljharb>
and sure, i'll prioritize that one


2024-08-29
[07:46:06.0396] <shu>
Michael Ficarra: oh btw i'm OOO next Wed flying back to CA from CO

[07:46:10.0539] <shu>
you wanna reschedule or skip?

[08:16:03.0035] <Michael Ficarra>
let's reschedule

[08:16:08.0048] <Michael Ficarra>
send me some times that work for you