2025-04-01
[08:44:45.0785] <Michael Ficarra>
lol

[08:48:52.0095] <Michael Ficarra>
I'm assuming the terrible thing they're referring to is that they don't have papyrus installed on their computer

[10:09:26.0733] <shu>
how is it possible someone doesn't have papyrus

[10:09:28.0298] <shu>
isn't it defualt

[10:09:32.0838] <shu>
* isn't it default

[10:14:53.0005] <Michael Ficarra>
probably Linux

[10:15:32.0042] <shu>
this is why the year of linux on the desktop will never come

[10:15:54.0810] <shu>
papyrus has been around for 5000 years

[13:53:56.0499] <Richard Gibson>
how would y'all feel about introduction of a Mapping specification type (*analogous to the language values produced by `new Map()`, but no need for key/value/entry enumeration AFAICT*) for replacing ECMA-402 _record_.[[\<_var_>]] abuse of the Record type?
https://github.com/tc39/ecma402/pull/984#discussion_r2021261469

[14:03:32.0275] <bakkot>
positively

[14:09:55.0960] <Richard Gibson>
and followup: preferences for such a type being defined in ECMA-262 vs. ECMA-402?

[15:35:06.0525] <bakkot>
I would leave it in 402 until such time as there's use for it in 262

[15:36:25.0000] <bakkot>
Temporal is using the same thing so we could pull it in to 262 as part of landing Temporal

[15:36:37.0979] <bakkot>
generally we don't like to have stuff in 262 that isn't being used within the document itself


2025-04-02
[10:23:07.0472] <bakkot>
syg: quick one from a while ago: https://github.com/tc39/ecma262/pull/3402

[10:52:03.0514] <shu>
lgtm


2025-04-10
[17:07:23.0305] <jmdyck>
totally forgot about the meeting today

[17:27:08.0936] <bakkot>
nothing especially interesting discussed, mostly just prep for plenary

[17:27:23.0879] <jmdyck>
tx


2025-04-13
[16:15:19.0423] <Chris de Almeida>
KG is down for 5m 262 report tomorrow.  lmk if delta


2025-04-14
[18:02:12.0114] <shu>
"if delta"?

[18:04:59.0637] <bakkot>
i.e. if we expect a different amount of time

[18:05:00.0718] <bakkot>
but we do not

[20:16:01.0233] <Chris de Almeida>
or a different presenter

[07:50:02.0495] <Michael Ficarra>
I would really love to see another editor review of https://github.com/tc39/ecma262/pull/2952.

[07:50:30.0011] <Michael Ficarra>
I don't want any other Annex B things to land without following those conventions.


2025-04-23
[14:55:40.0167] <bakkot>
ljharb https://github.com/tc39/ecma262/pull/3559 and https://github.com/tc39/ecma262/pull/3566 should both get backported to es2025

[14:55:46.0807] <bakkot>
I can do it but I assume you have a process

[15:01:46.0545] <ljharb>
yup

[15:02:35.0937] <ljharb>
is it ok to pull in the meta and editorial changes that have landed since the cut as well?

[15:04:24.0061] <ljharb>
* is it ok to pull in the meta and editorial changes that have landed since the cut as well? (normally i pull in everything except unnecessary normative changes, when updating a candidate)

[16:15:40.0429] <Michael Ficarra>
@ljharb:matrix.org we'd rather not, just those 2 please

[16:26:50.0726] <ljharb>
alrighty. why not?

[16:53:33.0454] <Michael Ficarra>
there's plenty of things we *could* pull in, but we shouldn't make changes after the opt-out period starts unless they're really vital

[16:53:57.0430] <Michael Ficarra>
in theory, we should probably be notifying committee about every cherry-picked commits at plenary

[16:54:05.0995] <Michael Ficarra>
* in theory, we should probably be notifying committee about every cherry-picked commit at plenary

[16:54:26.0602] <ljharb>
the attitude for all the editors in the past was that only normative ones fell into that category, editorial was just a nice to have and within the editors' purview

[16:54:32.0536] <Michael Ficarra>
@bakkot:matrix.org @shuyuguo:matrix.org 402 issue tracking `<emu-normative-optional>`: https://github.com/tc39/ecma402/issues/998

[16:55:40.0054] <Michael Ficarra>
I'm not personally against that policy, though I don't feel particularly compelled to pull in the editorial changes either

[16:56:13.0190] <ljharb>
¯\_(ツ)_/¯ up to yall, this'll just be the first time we didn't eagerly pull all non-normatives in

[16:56:16.0218] <ljharb>
* ¯\\\_(ツ)\_/¯ up to yall, this'll just be the first time we didn't eagerly pull all non-normatives in


2025-04-24
[10:09:35.0739] <Michael Ficarra>
does anyone know where we last discussed this convention? https://github.com/tc39/ecma262/pull/3571/files#r2058891137

[10:09:50.0230] <Michael Ficarra>
also, nobody objects to me adding it to the editorial conventions doc, right?

[10:10:44.0985] <Michael Ficarra>
I'll just add it for now and we can remove it if someone objects

[10:45:43.0517] <jmdyck>
I don't think there's a precedent, and I don't recall it being discussed. PR #2711 had a commit that went in the opposite direction (insertion of "value"): https://github.com/tc39/ecma262/pull/2711/commits/3c4c2f5005cb62dceb1931f553d412d47fac362d , suggesting that any precedent or discussion (of deletion of "value") happened after that.

[10:48:06.0603] <Michael Ficarra>
yeah, pretty sure it was more recent than that

[10:55:49.0510] <jmdyck>
If the subject had come up (in my presence), I think I would have looked at my pseudocode grammar to see what would need changing, and I'm fairly confident that I've never done that till just now.

[11:01:09.0513] <jmdyck>
E.g., there are over 100 occurrences of "the String value".

[11:16:08.0669] <Michael Ficarra>
okay I still can't find it, so maybe I've imagined it

[11:17:05.0625] <Michael Ficarra>
or maybe I've somehow confused it with our editorial convention of avoiding "the value of" or the notation we use to describe types, I dunno

[11:17:48.0887] <Michael Ficarra>
anyway, I still like the rule so let me know if anyone has a problem with it

[11:19:00.0435] <bakkot>
I also recall talking about this in passing

[11:20:09.0486] <bakkot>
we did make "is a String" link, not "is a String value"

[11:26:48.0642] <Michael Ficarra>
we also have this related convention:
> don't unnecessarily qualify object types with the word "object"; _x_ is an Array, not _x_ is an Array object

[11:27:05.0206] <Michael Ficarra>
generally everything is moving in that direction


2025-04-26
[18:05:10.0549] <bakkot>
https://github.com/tc39/ecma262/pull/3575

[18:05:20.0868] <bakkot>
not sure this is strictly an editor concern but I think it basically is

[18:53:16.0924] <Michael Ficarra>
I think it should get chair approval since it's speaking on behalf of committee

[19:54:51.0254] <jmdyck>
@bakkot: in your msg 33min ago, the "CONTRIBUTING.md" isn't a proper link

[19:59:03.0322] <jmdyck>
(Just like isn't a proper link here.)

[19:59:09.0947] <jmdyck>
* (Just like it isn't a proper link here.)

[19:59:25.0164] <jmdyck>
* (Just like it isn't a proper link here ^.)

[19:59:32.0826] <bakkot>
it's not a link at all, matrix is just dumb

[19:59:35.0207] <bakkot>
I will try to escape it

[19:59:58.0148] <bakkot>
can't do backslash before the dot but code block works

[23:21:40.0934] <ljharb>
i think it's a good uncontroversial change, but people don't read so it won't help any


2025-04-27
[17:41:23.0123] <shu>
haha yeah reading's for nerds


2025-04-29
[19:21:55.0774] <jmdyck>
Is it no longer possible to see the rendered preview of a PR?

[20:36:04.0102] <bakkot>
currently no, not without building locally

[20:36:05.0527] <bakkot>
github broke the thing we were using and the replacement did not immediately fix it https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

[22:11:41.0604] <ljharb>
anyone's welcome to try to help fix it; otherwise it is on my sadly very long list

[10:20:07.0601] <Michael Ficarra>
I am *super* happy about this QoL improvement: https://github.com/tc39/ecmarkup/pull/645

[10:20:20.0687] <Michael Ficarra>
I do this ALL THE TIME


2025-04-30
[12:57:20.0503] <Michael Ficarra>
@shuyuguo:matrix.org we should bring back Mistral for spec drafts 😍

[13:35:59.0472] <shu>
lgtm