2021-10-01
[11:29:57.0134] <shu>
what i want is to use `let` even for bindings i don't re-assign!

[12:32:10.0584] <bakkot>
yeah, I also hate that rule

[12:32:26.0408] <bakkot>
I think it predates my maintainership

[12:40:14.0044] <bakkot>
oh, no, it's because of typescript

[12:40:31.0687] <bakkot>
typescript, for some reason, has better type inference when using `const`

[12:41:06.0418] <bakkot>
this seems silly to me, since a whole program analysis should be perfectly capable of noticing that a `let`-bound variable is never reassigned and then treating it exactly like `const`

[12:41:09.0238] <bakkot>
but that's the justification

[12:41:35.0027] <shu>
that is strange

[12:41:39.0879] <shu>
the TS inference thing, i mean


2021-10-02
[09:15:54.0847] <ljharb>
that rule is the best, let sucks, but I agree it’s ridiculous that if affects type inference whatsoever

[09:16:05.0811] <ljharb>
* that rule is the best, let sucks, but I agree it’s ridiculous that it affects type inference whatsoever


2021-10-04
[08:28:08.0042] <shu>
let does suck, but so does const!

[08:28:09.0670] <shu>
var forever

[10:54:37.0610] <ljharb>
should probably say that in comic sans tbh

[15:23:47.0803] <Michael Ficarra>
you use var? I just put everything on Object.prototype

[15:51:47.0137] <shu>
i use var because fast

[15:52:08.0813] <shu>
gonna propose to rename `var` to `vroom`

[16:47:02.0007] <bakkot>
shu: ecmarkup PR lgtm; do you want me to cut a release now, or do you want to wait until the ecma262 PR is up in case you discover changes you want to make during that process?

[16:50:31.0913] <shu>
nah let's just land it and iterate/bugfix as we work on adding the annotation in ecma262

[16:50:38.0520] <bakkot>
wfm

[16:50:45.0520] <shu>
just fingers crossed it doesn't require a new approach!

[16:52:31.0373] <shu>
bakkot: you applied your own suggestion, right?

[16:53:26.0976] <bakkot>
yup

[16:53:30.0804] <bakkot>
and pushed up the formatting

[16:53:57.0639] <shu>
great, thanks


2021-10-05
[17:04:11.0194] <bakkot>
published in v9.4.0

[13:14:33.0538] <bakkot>
I forgot to mention I'm out for a week starting tomorrow

[13:14:39.0494] <bakkot>
y'all will need to make a different meeting for the editor call

[13:42:59.0670] <shu>
thanks for the heads up i'll edit the meeting

[13:45:10.0833] <shu>
enjoy your vacation


2021-10-06
[14:13:52.0661] <ljharb>
shu: you're marked "no" on the event btw

[14:15:47.0304] <shu>
i see that

[14:15:52.0849] <shu>
i also cannot change it for some reason, but i can edit the event

[14:16:00.0716] <shu>
(i am planning on attending, and updated the Meet link)

[14:16:07.0724] <ljharb>
weird, and cool thanks

[14:16:58.0424] <shu>
i have the same event copied over to my personal calendar for the popup reminder

[14:17:10.0856] <shu>
i wonder if calendar is seeing there's a conflict and then auto-marking me as no

[14:17:44.0142] <ljharb>
oh yeah probably so

[14:17:58.0549] <ljharb>
i have that feature turned off

[14:18:46.0801] <shu>
no, that's not it

[14:18:50.0025] <shu>
i have no idea

[14:19:01.0787] <shu>
let me remove myself?

[14:19:57.0174] <ljharb>
now you're a maybe

[14:20:49.0658] <shu>
i think that worked

[14:21:02.0816] <ljharb>
LGTM

[14:21:10.0850] <ljharb>
now the important problems are solved

[16:21:16.0101] <ljharb>
thoughts on https://github.com/tc39/ecma262/pull/2144#issuecomment-676783183 versus https://github.com/tc39/ecma262/pull/2144#pullrequestreview-471015688 ?

[16:21:20.0745] <ljharb>
happy to update to whichever yall prefer


2021-10-07
[20:16:28.0279] <Michael Ficarra>
StringIndexOf should be good enough

[21:25:57.0033] <ljharb>
ok, meaning richard's comment

[21:54:36.0454] <ljharb>
k, updated the PR


2021-10-08
[13:30:33.0723] <shu>
another npm noob question: when i ran `npm install` in ecma262, it basically rewrote package-lock.json from version 1 to version 2

[13:30:47.0040] <shu>
i'm guessing i shouldn't actually commit that? am i supposed to run it with some flags? am i using the wrong version of npm?

[13:37:54.0573] <shu>
ljharb: ^

[13:47:16.0178] <bakkot>
shu: yeah, that means you are npm 7 rather than npm 6

[13:47:19.0117] <bakkot>
it doesn't much matter though

[13:47:22.0302] <ljharb>
that's fine, npm 8 is out now too

[14:33:43.0439] <shu>
thanks

[15:00:20.0899] <Michael Ficarra>
eww, check out https://tc39.es/ecma262/multipage/abstract-operations.html#sec-stringtobigint

[15:00:35.0912] <Michael Ficarra>
why did we ever think it was acceptable to specify things that way?

[15:02:42.0980] <jmdyck>
expediency, probably.

[15:02:47.0852] <Michael Ficarra>
also, it returns a BigInt or NaN, which is very weird

[15:03:11.0718] <Michael Ficarra>
jmdyck: it seems like they wanted to save space or something

[15:03:16.0989] <ljharb>
expediency and also bigint was a massive spec, so it probably didn't get a thorough enough review. that seems to be a pattern in large proposals - it's easy to miss issues

[15:03:23.0181] <ljharb>
 * expediency and also bigint was a massive spec, so it probably didn't get a thorough enugh review. that seems to be a pattern in large proposals

[15:03:27.0443] <ljharb>
 * expediency and also bigint was a massive spec, so it probably didn't get a thorough enough review. that seems to be a pattern in large proposals

[15:03:34.0188] <ljharb>
 * expediency and also bigint was a massive spec, so it probably didn't get a thorough enough review. that seems to be a pattern in large proposals - it's easy to miss issues

[15:03:55.0122] <Michael Ficarra>
agree ljharb, the bigger the review, the more weird stuff slips in

[15:04:33.0856] <Michael Ficarra>
in big reviews, it's easier to spot little local issues than big oddities

[15:06:59.0205] <bakkot>
it wouldn't even be that hard to factor out a "string to MV" AO and then use it in both places

[15:07:23.0336] <bakkot>
we already have such an AO but not over this grammar, I guess

[15:08:09.0894] <Michael Ficarra>
bakkot:  PRs welcome

[15:09:21.0621] <jmdyck>
In my notes, I've got some steps. I'd have to check them over.

[15:12:08.0444] <shu>
okay, a first draft of can-call-user-code at https://ci.tc39.es/preview/tc39/ecma262/sha/a5ba1ae3a48e8cffb1e6051bc97dceace591af20/

[15:12:08.0488] <jmdyck>
I'll probably have time this weekend.

[15:12:19.0197] <shu>
press 'u' to toggle the 'UC' annotation on AO links

[15:12:34.0468] <shu>
play around, it's probably way too conservative and we need a bunch of manual supprsesions

[15:13:25.0187] <shu>
somewhat expectedly and unfortunately, everything can call user code

[15:15:23.0018] <ljharb>
the "u" stuff is verryyyyyy slow to respond

[15:15:35.0545] <ljharb>
how are you changing the visibility?

[15:15:46.0565] <ljharb>
the way i'd assume is fastest is a single css class applied or removed to `html` or `body`, and have that class change something that doesn't case a reflow

[15:16:12.0387] <ljharb>
 * the way i'd assume is fastest is a single css class applied or removed to `html` or `body`, and have that class change something that doesn't case a reflow

[15:16:36.0663] <ljharb>
so, i don't see an annotation on https://ci.tc39.es/preview/tc39/ecma262/sha/a5ba1ae3a48e8cffb1e6051bc97dceace591af20/#sec-isregexp even tho it contains a step that has one - is that expected?

[15:16:54.0203] <ljharb>
it'd also be super useful to show the AO-level annotation in the TOC on the left pane, as well

[15:17:44.0570] <shu>
it is a terrible hack

[15:17:55.0234] <shu>
look at the "e-user-code" class

[15:18:04.0863] <shu>
it has a `::before` that has the 'UC'

[15:18:39.0026] <shu>
however, since i can't directly toggle `::before` visibility, i have a big of JS that injects a `<style>` tag with `.e-user-code::before { display: block !important }` when you press `u`

[15:18:47.0712] <shu>
we definitely should not ship with this

[15:18:48.0009] <ljharb>
why can't you?

[15:18:58.0503] <shu>
how... do you?

[15:19:12.0942] <shu>
i can't select for it

[15:19:35.0268] <ljharb>
if you have two `::before` blocks they don't control the same content?

[15:19:48.0945] <ljharb>
i haven't messed with native css in awhile

[15:19:49.0393] <shu>
yes, and that's what i do

[15:19:56.0043] <shu>
with that style injection hack

[15:20:09.0212] <shu>
but that's probably why it's so slow

[15:20:46.0604] <shu>
 * but that's probably why it's so slow

[15:21:29.0888] <ljharb>
gotcha

[15:21:52.0212] <ljharb>
i wonder if it'd be faster tho to have the styles be always there

[15:22:38.0611] <ljharb>
like
```
e-user-code::before {
  /* whatever */
  opacity: 0;
}
html.showUC e-user-code::before {
  opacity: 1;
}
```

[15:22:57.0511] <shu>
oh maybe, patches welcome?

[15:23:00.0273] <ljharb>
opacity as opposed to display, so that the document doesn't have to reflow, because the UC content will always be there

[15:23:06.0639] <shu>
anyway i don't think we should do any optimization work here until we hash out how we actually want to render these

[15:23:10.0948] <ljharb>
fair enough

[15:23:33.0138] <shu>
just needed _something_ to debug and see the false positives

[15:23:38.0468] <ljharb>
right

[15:23:44.0266] <shu>
most of the false positives i've seen so far are of the integer coercion flavor

[15:23:56.0163] <shu>
where we know something we're coercing is a number we constructed internally or something

[15:28:16.0961] <ljharb>
another is https://ci.tc39.es/preview/tc39/ecma262/sha/a5ba1ae3a48e8cffb1e6051bc97dceace591af20/#sec-createregexpstringiterator which is kind of the same case

[15:28:35.0372] <ljharb>
iow, technically if you called that AO with a user-provided regex, the annotations are correct; but it's only ever called with a spec-fiction-regex, so they're not

[15:28:49.0017] <ljharb>
there's probably a similar case with async iteration

[15:28:57.0143] <Michael Ficarra>
I was expecting a badge more like 

[15:29:40.0824] <shu>
ljharb: awesome, please note them down in a comment :)

[15:30:10.0143] <shu>
Michael Ficarra: that would reflow, right? would be slower for sure

[15:30:13.0692] <shu>
visually wfm

[15:30:14.0046] <Michael Ficarra>
oops, simplified should be small-caps

[15:30:26.0130] <Michael Ficarra>
it would reflow, but I'm not all that against reflow

[15:30:46.0873] <shu>
yeah, we can discuss rendering at the next call or after the next plenary

[15:31:02.0485] <shu>
i have very little opinion here other than that it be nice and clear

[15:31:11.0271] <shu>
i think my only bar is "no low contrast crap"

[15:34:20.0627] <Michael Ficarra>
yeah, well using a class on `<html>` as ljharb suggests should be faster than the current hack of inserting a new stylesheet

[15:34:28.0280] <Michael Ficarra>
I would start there

[15:36:30.0157] <shu>
i wonder if we can farm out the task of finding false positives out to committee delegates... 😈

[15:41:00.0536] <Michael Ficarra>
just merge it, and with enough time ...

[15:42:55.0578] <ljharb>
lol

[16:27:38.0545] <bakkot>
shu: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ruby

[16:36:42.0435] <Michael Ficarra>
bakkot: we talked about that at the editor call


2021-10-11
[10:15:57.0920] <shu>
furigana doesn't scale with multiple effects, but maybe we don't care?

[10:27:49.0531] <bakkot>
you can put linebreaks in

[10:31:56.0971] <shu>
oh really?

[10:34:13.0897] <bakkot>
data:text/html;charset=utf-8,%3Cruby%3E%0D%0Asome%20AO%20%3Crt%3Eeffect%3Cbr%3Eother-effect%3C%2Frt%3E%0D%0A%3C%2Fruby%3E

[10:34:24.0119] <bakkot>
bah, matrix doesn't recognize data:uris

[10:34:30.0661] <bakkot>
that should be a link

[10:34:32.0445] <bakkot>
anyway, yes

[10:35:49.0855] <shu>
a pretty good idea, will try


2021-10-12
[10:14:33.0014] <Michael Ficarra>
we don't dfn iterator record

[10:14:34.0485] <Michael Ficarra>
should we?

[10:14:47.0756] <Michael Ficarra>
we need it for some AO parameter types and return types

[10:26:17.0330] <bakkot>
Michael Ficarra: yes, see https://github.com/tc39/ecma262/issues/2486

[10:34:52.0033] <Michael Ficarra>
k I will just use the term in my WIP PR and the dfn will come in later


2021-10-15
[11:05:14.0415] <shu>
i have hit upon just the badge to use for user code: 🤡

[11:06:29.0461] <bakkot>
:D

[14:46:12.0755] <jmdyck>
My code is complaining about step 9.c in the new [String.prototype.split](https://tc39.es/ecma262/#sec-string.prototype.split): `_codeUnits_` appears to be a List in which each element is a code unit, but  CreateArrayFromList wants a List in which each element is an ECMAScript language value. Don't we need wording that makes a String value for each code unit?

[15:20:29.0934] <ljharb>
isn't a String just a sequence of code units?

[15:20:39.0151] <ljharb>
altho i guess there's at least one Note where it adds "converted to a String"

[15:21:55.0944] <ljharb>
the intro para in https://tc39.es/ecma262/#sec-ecmascript-language-types-string-type seems like it does define a String as a sequence of integers, where each integer is considered a code unit

[15:32:06.0672] <bakkot>
even then, strictly speaking a code unit is not a sequence of code units

[15:32:43.0217] <ljharb>
fair point

[15:34:07.0071] <ljharb>
so "Let _codeUnits_ be a List consisting of the sequence of code units that are the elements of _head_." → "Let _codeUnits_ be a List consisting of the sequence of code units that are the elements of _head_, each converted to a String."?

[15:34:42.0776] <bakkot>
"converted to a string" isn't really precise enough

[15:35:08.0393] <bakkot>
hm

[15:37:09.0100] <bakkot>
`Let _codeUnits_ be a List whose elements are the Strings given by considering each code unit of _head_, in order, to be a distinct length-one sequence of code units`, maybe

[15:37:13.0277] <bakkot>
 * `Let _codeUnits_ be a List whose elements are the Strings given by considering each code unit of _head_, in order, to be a distinct length-one sequence`, maybe

[15:38:06.0198] <bakkot>
 * `Let _codeUnits_ be a List whose elements are the Strings given by considering each code unit of _head_, in order, to be a distinct length-one sequence of code units`, maybe

[15:58:00.0100] <ljharb>
sgtm


2021-10-16
[18:15:57.0332] <jmdyck>
I think the spec would be more likely to express it as an explicit loop. Not that I'm against saying it as a one-liner, but I'd prefer if there were an established syntax for doing so.

[18:40:43.0451] <bakkot>
While I'm generally in favor of sticking to established conventions, I think the prose is clearer than a loop would be, and clarity is what I'd most prefer to optimize for.

[10:31:51.0770] <jmdyck>
I think which of those seems clearer would vary from reader to reader.

[10:37:23.0014] <bakkot>
Well, yes, that is always true, so what I mean is that I think the prose will be clearer to more readers.


2021-10-20
[16:36:56.0940] <shu>
bakkot: here's a confusing one for can call user code: GeneratorStart

[16:37:05.0787] <shu>
i guess it's technically no, it can't call user code

[16:37:12.0323] <shu>
but like, obviously it does


2021-10-21
[17:56:15.0852] <bakkot>
lol

[17:56:18.0232] <bakkot>
it doesn't though!

[17:56:35.0409] <bakkot>
though the ones which deal with execution context are all kind of suspicious

[17:57:13.0836] <bakkot>
but here it's definitely GeneratorResume which calls user code

[17:58:23.0742] <bakkot>
which, it occurs to me, your analysis probably misses, because the "resume" stuff isn't AO-like

[18:09:01.0243] <shu>
yeah

[18:09:11.0975] <shu>
we'll need to do another pass on execution context stuff for sure

[18:09:36.0657] <shu>
TIL we have a non-capitalized AO

[18:09:39.0045] <shu>
`thisTimeValue`

[18:09:45.0747] <shu>
 * `thisTimeValue`

[18:10:03.0860] <shu>
it doesn't even have a header: https://tc39.es/ecma262/#thistimevalue

[18:10:05.0116] <shu>
cursed

[18:14:51.0691] <shu>
the analysis also misses anything higher-ordered with abstract closures

[18:29:32.0286] <bakkot>
there's a few of those

[18:29:38.0832] <bakkot>
thisBooleanValue, etc

[18:29:58.0746] <bakkot>
even worse is "this Date object"

[18:30:17.0872] <bakkot>
> the phrase “this Date object” refers to the object that is the this value for the invocation of the function. If the Type of the this value is not Object, a TypeError exception is thrown

[18:30:21.0462] <bakkot>
 * > the phrase “this Date object” refers to the object that is the this value for the invocation of the function. If the Type of the this value is not Object, a TypeError exception is thrown

[18:30:35.0292] <bakkot>
I have on my queue to clean those up, but it's... pretty far down

[18:32:00.0574] <jmdyck>
I would have done those ages ago, except there isn't a great place for the resulting emu-clause

[23:28:58.0768] <ljharb>
`thisFooValue` are definitely a class of non-capitalized AOs - there's also things that are kind of macros/formulas like `min` and `abs` and `msFromTime` etc

[11:28:26.0840] <Michael Ficarra>
alternative idea for user code marker: ⚠️

[11:31:06.0934] <Michael Ficarra>
lol

[11:37:57.0042] <Michael Ficarra>
anyway, shu the PR is up: https://github.com/tc39/ecmarkup/pull/365

[13:41:37.0209] <shu>
🎉

[14:12:59.0877] <shu>
spacing seems pretty off on the ⚠️

[14:13:08.0008] <shu>
i quite like the red UC with the outline, actually

[14:13:10.0335] <shu>
much more than i was expecting


2021-10-22
[17:22:43.0356] <bakkot>
shu: Michael Ficarra either of you have opinions on the organization of the commits in https://github.com/tc39/ecma262/pull/2531 (other than that the fixup commits should be squashed, which they are on the branch; seems to be a github bug)

[17:22:54.0464] <bakkot>
I do not have an opinion and am happy to merge as-is

[20:17:47.0710] <shu>
i do not either

[20:41:33.0709] <bakkot>
:shipit:


2021-10-25
[02:35:04.0523] <bakkot>
wow, ecma actually taking some initiative on the whole PDF thing

[02:35:10.0136] <bakkot>
 * wow, ecma actually taking some initiative on the whole PDF thing

[02:36:16.0574] <shu>
yeah

[03:04:46.0222] <Michael Ficarra>
they're asking for software to do the job automatically though, which I don't think we're interested in

[09:05:41.0585] <ljharb>
i assume this week's call is skipped

[10:43:11.0821] <shu>
mos def


2021-10-27
[06:01:02.0110] <Michael Ficarra>
FYI https://matrix.to/#/!wbACpffbfxANskIFZq:matrix.org/$ZsUPg6tG98It34xrXz0AbiWh3m8SA4ihofMurC45vF8?via=matrix.org&via=mozilla.org&via=igalia.com

[07:07:55.0142] <ljharb>
i'll be putting up a PR later this week to resolve a privately reported security vulnerability in one of our github workflows; please try to review it quickly but once i'm confident it's working, i plan to land it so i can resolve the vuln. hopefully that's ok.

[07:09:09.0794] <Michael Ficarra>
just land it and we can do review in post

[07:10:27.0996] <bakkot>
ljharb: PM me about it? i want to see if it's something I have elsewhere

[07:11:22.0948] <ljharb>
sure

[08:36:49.0940] <ljharb>
https://github.com/tc39/ecma262/pull/2557

[09:14:54.0159] <ljharb>
ok to close https://github.com/tc39/ecma262/pull/2528? if not i'll rebase it


2021-10-28
[06:52:49.0026] <Michael Ficarra>
ljharb: nah, I think I still want to discuss it more

[06:52:59.0690] <ljharb>
ok

[06:53:01.0943] <Michael Ficarra>
I get that it conveys additional info, but maybe there's a better way to do that

[06:54:32.0356] <ljharb>
the spec was riddled with bugs around this before we switched everything to use OrThrow; if there's a better way great, but imo the better way is to get rid of the non-OrThrow one (altho the 2 remaining callsites of it aren't easy to do that on)


2021-10-29
[13:06:13.0156] <bakkot>
oh, we were gonna rename the default branch yesterday

[13:06:17.0651] <bakkot>
we should do it today maybe?

[13:19:33.0202] <shu>
let's do it


2021-10-30
[23:31:55.0181] <ljharb>
sure, want me to do it next chance i get? i can do it in 12-14 hours or so

[13:08:35.0595] <bakkot>
ljharb: sure, please do

[13:09:06.0969] <bakkot>
I'm also happy to take care of it as long as the process is literally just clicking the rename button on the branches page on github, but if you want to do more than that I will leave it to you

[13:21:55.0006] <ljharb>
oh hmm

[13:22:03.0419] <ljharb>
yeah there's a tiny bit of extra cleanup

[13:22:13.0612] <ljharb>
but "Will close 1 open pull request for this branch."

[13:22:26.0571] <ljharb>
iow, that means one PR is probably something that we can't update, so i guess that's fine if it's closed

[13:24:57.0831] <ljharb>
k, everything should be updated

[13:29:38.0071] <bakkot>
I just got a bunch of notifications about apparently nonexistent PRs being closed

[13:29:56.0162] <bakkot>
I wonder if those were spam PRs that github created a number for but hid?

[13:30:06.0530] <bakkot>
they all seem to be gibberish

[13:31:43.0445] <bakkot>
like, 1508 - afaik there just isn't an issue or PR with that number, so presumably github hid it?

[13:32:16.0870] <bakkot>
except for https://github.com/tc39/ecma262/pull/1986, that was a real PR which got closed, presumably by accident?