2023-10-04
[15:00:42.0600] <jmdyck>
no eds meeting, or was that tuesday again?

[15:24:47.0410] <jmdyck>
Hm, editors call doesn't appear on "TC39 Public Calendar"


2023-10-05
[17:31:58.0485] <ljharb>
i see it there for the 4th and the 11th on the regular wednesday times

[17:33:53.0870] <jmdyck>
not showing for me. either different calendar or different viewing permissions.

[17:34:46.0448] <jmdyck>
I'm looking at a Google calendar

[18:40:40.0109] <ljharb>
hm, it’s the same google cal as always, and you’re still on it as an attendee

[18:40:58.0171] <jmdyck>
link?

[18:42:52.0625] <ljharb>
will DM

[18:44:39.0930] <jmdyck>
Thanks, that works for me (different calendar: "TC39 Events Calendar" vs "TC39 Public Calendar")

[18:45:17.0955] <jmdyck>
So is the Events cal not Public?

[18:47:52.0123] <jmdyck>
There was supposed to be a Public and a Private, and I thought editors call would be on the Public, but maybe not.

[02:48:07.0645] <ljharb>
no, it's not public

[02:48:14.0660] <ljharb>
editors call isn't on the public one.


2023-10-10
[09:21:20.0502] <Michael Ficarra>
editor call should appear on the public calendar

[09:21:21.0654] <Michael Ficarra>
see https://github.com/tc39/Reflector/issues/487

[09:22:00.0350] <Michael Ficarra>
also I won't be there tomorrow since my flight home from Japan has been delayed (30 hours! 😭)

[09:41:13.0816] <shu>
oh man, 30 hours

[09:41:14.0330] <shu>
sorry

[09:41:23.0900] <shu>
is it because of the HK typhoon?

[09:41:31.0715] <shu>
but that's not the route... idk

[13:33:54.0744] <ljharb>
> <@michaelficarra:matrix.org> editor call should appear on the public calendar

i didn't realize yall had made a decision on that yet

[13:34:03.0341] <ljharb>
> <@michaelficarra:matrix.org> editor call should appear on the public calendar

 * i didn't realize yall had made a decision on that yet; it's not in the issue

[16:44:35.0045] <Michael Ficarra>
shu: no, we had a medical emergency on the plane and turned around 3 hours in

[16:47:47.0197] <Michael Ficarra>
ljharb: we talked about it on an editor call but I don't think we knew how we were expected to reply to the issue at the time

[16:48:22.0777] <ljharb>
i think just comment and say whether the editors want it on the public cal, and also, whether it's ok that the email addresses on it are public or not


2023-10-11
[14:32:04.0140] <bakkot>
shu: we doing editor call today?

[14:32:17.0222] <shu>
oops lost track of time, omw


2023-10-12
[17:50:19.0926] <bakkot>
Michael Ficarra: https://github.com/tc39/ecma262/pull/3116 is ready except your stamp

[14:25:48.0399] <shu>
i just noticed the % in IBM Plex is also wtf

[14:25:56.0365] <shu>
the / is split into 2

[14:27:08.0085] <shu>
that's not how a slash works

[14:27:36.0298] <shu>
it divides others! it itself must not be divided!

[14:31:47.0105] <justingrant>
Well, maybe they needed an excuse for why to make that character much wider than it needs to be, for consistency with other characters that are also unnecessarily wide? 

[16:19:11.0019] <Michael Ficarra>
I can kinda understand the split / in %

[16:19:23.0987] <Michael Ficarra>
it's only for italic monospace variants

[16:19:50.0993] <Michael Ficarra>
making % italic is probably really awkward, especially in monospace

[16:27:09.0547] <ljharb>
italic % and ÷ might get overlappy


2023-10-18
[15:50:14.0663] <bakkot>
shu: https://github.com/tc39/ecma262/pull/3200 lgtm but I had a suggestion for further clarity, which if you approve of you could either fold in to this PR or I am happy to send a PR myself

[15:50:39.0736] <bakkot>
if you don't want to put that change in this PR you can stamp it as ready to merge

[15:53:31.0772] <shu>
thanks. both suggestions sgtm, i'll fold them into this PR

[16:05:15.0987] <Michael Ficarra>
ljharb: we've got some PRs ready to merge when you get a chance: https://github.com/tc39/ecma262/issues?q=is%3Aopen+label%3A%22ready+to+merge%22+sort%3Aupdated-desc+status%3Asuccess

[16:17:49.0862] <ljharb>
Yep, just flew home and will land them tonight or tomorrow

[16:36:43.0324] <Michael Ficarra>
from Japan?


2023-10-19
[21:12:04.0572] <ljharb>
nope, from north carolina; i was there for a conf this week


2023-10-24
[14:49:58.0776] <ljharb>
https://github.com/tc39/ecma262/pull/3194 still fails the esmeta check, what do we want to do about that?

[14:54:21.0545] <jmdyck>
https://github.com/es-meta/esmeta/issues/197 got some attention 16 hours ago.

[14:58:04.0353] <bakkot>
I'd wait a bit longer to see if they fix it

[14:58:09.0157] <bakkot>
they've generally been pretty responsive

[14:58:16.0913] <bakkot>
and this isn't blocking anything

[16:46:51.0097] <ljharb>
sounds good


2023-10-25
[14:32:02.0893] <shu>
be there in 2


2023-10-27
[08:41:49.0554] <Michael Ficarra>
do we always use "this NonterminalName" when referring to the LHS of a production in SDO steps, or only when the same nonterminal appears on the RHS?

[08:41:54.0672] <Michael Ficarra>
if we don't, I think we should

[08:44:56.0552] <Michael Ficarra>
and early errors, I guess

[08:45:13.0498] <Michael Ficarra>
I wonder if it would be helpful to model early errors as an SDO... 🤔

[09:25:26.0579] <bakkot>
helpful to whom

[09:25:28.0430] <bakkot>
readers? no

[10:04:55.0410] <jmdyck>
Michael Ficarra: we don't always. I'm prepping a PR where this stuff gets consistified

[10:15:31.0182] <jmdyck>
re modelling early errors as an SDO: I've thought about it. I agree w bakkot that it wouldn't be particularly helpful to readers, as most early error rules are about as clear as they need to be for most people's purposes. On the other hand, there are some dark corners of early error processing, and the exercise might shine some light on them.