2021-09-01 [11:43:33.0373] cancel the editor meeting today, i presume? [11:46:45.0519] y 2021-09-02 2021-09-03 2021-09-04 2021-09-05 2021-09-06 2021-09-07 2021-09-08 [13:55:46.0240] i shouldn't have taken a break from looking at ecmarkup and ecmarkdown, now i gotta page everything back in 2021-09-09 2021-09-10 [11:51:07.0467] bakkot: i'm doing something kind of cursed with the reals. opinions on the following? i'm fixing a bug in the resizable buffers proposal for %TypedArray%.prototype.slice in a way i want to increment a TA index by 1/element size inside a loop that does bytewise copy [11:51:13.0492] that TA index is an MV [11:51:17.0845] so... this is fine, but it seems cursed [16:12:16.0275] oof [16:12:33.0364] I am fine with it as a mathematician but that's scary as a thing-to-ask-machines-to-implement [16:13:14.0501] I guess it's not so bad when element size is a power of 2, which it presumably is here? [16:13:35.0516] but still, is there a way to rephrase it to increment by 1 instead, and count when have incremented enough times, or something to that effect? [16:14:05.0754] I am much happier with having the loop counter be integral if possible, even if it entails doing a division in the body of the loop [16:18:35.0787] i feel the same way [16:18:43.0541] so in the end i refactored to get around it [16:18:52.0519] it wasn't one of those observable loops [16:18:54.0198] but still 2021-09-11 2021-09-12 2021-09-13 [16:59:30.0825] bakkot i assume i should land https://github.com/tc39/ecma262/pull/2504 as separate commits? 2021-09-14 [17:37:09.0682] I have no preference; whichever you'd prefer / is easier is fine by me [17:59:02.0342] doesn't make a difference; i'll keep them separate [17:59:21.0717] bakkot: altho actually there's a rebase conflict, so if you could rebase it first that'd be great :-) [17:59:33.0156] * bakkot: altho actually there's a merge conflict, so if you could rebase it first that'd be great :-) [18:41:16.0135] ljharb: done [18:41:23.0096] thanks [09:11:14.0289] handy link for finding PRs awaiting your review: https://github.com/tc39/ecma262/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+-reviewed-by%3A%40me+review%3Aapproved+-label%3A%22editor+call%22+draft%3Afalse+-label%3A%22ready+to+merge%22 [09:39:52.0990] let's use assignment or something for PR review pings and save editor call for stuff we legitimately want to discuss during the call [09:40:24.0402] right now, I see issues that I would review if not for the editor call label because I assume there's some nuance to be discussed [09:43:06.0386] is assignment going to be noticed more than being in the "reviewers" list? [09:43:58.0025] we might not even need review pings if people reflexively looked at the "awaiting review by you" list: https://github.com/tc39/ecma262/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+-label%3A%22editor+call%22+draft%3Afalse+-label%3A%22ready+to+merge%22+review-requested%3A%40me [09:43:58.0317] I think it sends me a notification whenever I get assigned, so I assume so [09:44:31.0304] it sends you one when you're requested to review as well, but that doesn't seem to get things on people's queue consistently [09:48:27.0231] i'm going to make a meta commit to change "twelfth" to "thirteenth" for #2516; ok to push directly, or would you prefer a PR? [09:53:40.0696] * i'm going to make a meta commit to change "twelfth" to "thirteenth" for #2516; ok to push directly, or would yall prefer a PR? [09:59:58.0632] I think both should be PRs [10:10:37.0873] sounds good [10:11:11.0885] on the latter point, I don't think we need to go into so much detail about UTF-8 [10:11:21.0465] https://github.com/tc39/ecma262/pull/2517 [10:11:26.0273] I added editor call label to discuss dropping most of that comment [10:11:29.0751] *note [10:11:46.0724] removing the detail seems fine to me, i'm only concerned that like unicode, an external group might have introduced normative changes without us realizing [10:33:19.0432] name bikeshedding: for the options object AOs in 402 that'll end up being in 262 now with Temporal [10:34:16.0551] what should we call those? do we just call those "options objects" without qualification? 262's options bags don't behave like that and behave differently from function to function (like Error constructor checking presence of `cause` with `Has`) [10:35:02.0868] shu: link to such an AO? [10:37:03.0387] https://tc39.es/ecma402/#sec-getoptionsobject and the AOs below it [10:37:11.0991] Temporal uses them as well [10:40:48.0471] "options object" seems fine, and `cause` is a special case (but would happen again whenever `undefined` is a valid value in an options bag) [10:44:59.0185] what about the options i'm adding with resizable buffers? [10:45:20.0342] i... guess they could use those, actually? i need to look closer [10:45:50.0805] anyway i guess the bigger normative question is when this gets pulled in via temporal, are we on board with using this style of options objects by default [10:46:17.0094] what is meant by "this style" [10:51:19.0441] the one in 402 [11:27:08.0646] meaning, undefined is equivalent to empty object bag w/ null proto, non-object is type-error? that seems like a reasonable choice [11:27:13.0609] * meaning, undefined is equivalent to empty object bag w/ null proto, non-object is TypeError? that seems like a reasonable choice [11:32:32.0323] also no Has checks [11:32:38.0948] (also reasonable) [11:42:37.0160] yup, seems good [11:42:44.0378] IIRC that's what resizable arraybuffer ended up with? [12:10:03.0735] i think so [12:27:11.0944] i think `Has` checks should only ever be the way it's done when `undefined` is a meaningful option value [12:27:28.0597] * i think `Has` checks should only ever be the way it's done when `undefined` is a meaningful option value, which will be very rare [12:43:21.0282] agreed 2021-09-15 2021-09-16 [17:39:49.0737] bakkot: https://github.com/tc39/ecmarkup/pull/362 up, i guess there are test expectations i didn't update [17:39:53.0827] how do i run those? [17:54:02.0400] `npm run update-baselines` [18:00:20.0665] hm i think i screwed up the rebase somehow, some of these updated baselines are not expected [18:05:44.0981] ah there we go 2021-09-17 2021-09-18 2021-09-19 2021-09-20 2021-09-21 2021-09-22 [12:03:24.0173] bakkot: Michael Ficarra i can't make today's meeting for a very stupid reason [12:03:47.0538] i got mosquito bites on my eyelid of all places and i cannot open my eyes comfortably [12:51:34.0514] that sounds awful [12:51:39.0709] hope you enjoy your audiobooks or whatever [13:10:30.0289] ouch 2021-09-23 [16:45:01.0097] bakkot: did you get a chance to look at the ecmarkup PR yet? [16:45:49.0654] shu: started reviewing, haven't gotten back to it [16:46:02.0602] it's at the top my stack now though [16:49:50.0524] no hurry, was just wondering if you had discussed it yesterday when i couldn't open my eyes [16:50:27.0470] we did a bit [16:51:00.0184] Michael Ficarra was of the opinion that we'll probably always have a fixed number of effects and so it would make more sense to have each be its own attribute, rather than having a comma-separated list [16:51:20.0499] also I was wondering about whether the is-invocation attribute should be preserved at runtime - leaning towards no [16:56:09.0329] agreed that it shouldn't be preserved at runtime, was just oversight on my part for not removing [16:57:00.0353] i initially started with a separate attribute, but found it unwieldy to type to have an empty `
` [16:57:45.0779] independently i think it's nice to have the effect names propagate as-is so adding new ones don't require ecmarkup changes [16:57:54.0501] that may be overly optimistic, though, if they need special propagation rules [16:59:59.0755] Michael Ficarra: what's the reason for preferring separate attributes? 2021-09-24 2021-09-25 2021-09-26 2021-09-27 [09:07:00.0261] shu: for the reason bakkot stated: we don't have a need to support ad-hoc effects [09:07:06.0828] we will always know all the effects we support [09:07:49.0224] something like that is more appropriate as separate attributes than crammed into a comma-separated string together [09:08:05.0806] what do you want to be in the `dd`? [09:08:09.0012] just empty? [09:08:49.0998] i mean it could also be a known list of effects in `
effects
` [09:09:20.0601] they're 2-state, right? so true/false? [09:09:35.0291] well, and absence [09:09:53.0470] i don't see a lot of gains for separate attributes other than more typing [09:10:06.0290] but i see the argument about not having it be arbitrary [09:51:18.0941] yeah, I guess I would lean towards having it be a single attribute, for the sake of ease of reading/writing [09:51:49.0022] if we want to limit the allowable values we can enforce that with the linter [10:00:14.0146] separate attributes is easier for scripting [10:00:32.0058] otherwise every scripting operation needs to do the field parsing too [10:00:54.0136] that seems like it should be a very low priority [10:01:15.0587] speaking as the person who does most of the maintenance of the scripting here [10:27:26.0955] the scripting is `.split(',')`? [11:19:25.0143] i saw you ran an autoformatter, what should i be running? [11:19:30.0322] bakkot: [11:21:31.0786] `npm run format` [11:21:50.0869] also re: "static sdo", it's not enough to just update 262; ecmarkup knows about a specific list of types [11:22:05.0745] which does not include "static SDO" [11:23:08.0183] * which does not include "static sdo" [12:04:46.0602] i saw that there was special handling for some [12:05:28.0528] what additional things does ecmarkup need to be taught about static sdos, if the only thing that needs static sdo handling is the effect propagation? [12:11:15.0283] I think you can just grep for `'sdo'` in header-parser.ts, but like I said I think it would be better to track that as a separate bit rather than putting it into "type" [13:44:17.0677] fair enough [14:03:50.0060] also I think you can get away without changes to 262 - you can just rely on the "Static Semantics" prefix, no? [14:38:27.0441] for step 10 of https://tc39.es/ecma262/#sec-string.prototype.lastindexof - is there any interest in me restating that prose in the form of an explicit loop? (like how it's done in https://tc39.es/ecma262/#sec-stringindexof) [15:10:14.0094] bakkot: yes, good point, "Static Semantics" prefix suffices [16:38:00.0124] ljharb: yes, that sounds great [16:38:20.0900] the proposal copied what was in StringIndexOf before https://github.com/tc39/ecma262/pull/2258 landed, I suppose [16:38:44.0389] wish I'd noticed that during review [16:39:16.0227] or, wait [16:39:21.0058] I'm thinking of find-from-last [16:39:25.0516] lastIndexOf is old [16:40:04.0873] anyway, yes, such a PR sounds great; I would have done it in 2258 if I'd noticed [16:43:55.0035] Great - do you prefer an inline alg, a separate AO, or a two-way StringIndexOf? [16:55:48.0928] * Great! do you prefer an inline algorithm, a separate AO, or making StringIndexOf two-way via an arg? 2021-09-28 [17:00:00.0151] Just inline, I think [17:01:05.0540] on it [17:03:10.0653] is this even correct [17:05:38.0319] apparently it just works different from `Array.prototype.lastIndexOf` [17:05:39.0194] TIL [17:05:51.0659] (specifically wrt treatment of a negative second argument) [18:30:19.0172] i discovered this prose because i was implementing a polyfill, so i'm sure it matches web reality at least 2021-09-29 2021-09-30 [11:24:25.0819] i guess this is the first time i've done modern JS development, for ecmarkup [11:24:29.0191] i am not a fan of these eslint rules [11:30:33.0043] bakkot Michael Ficarra https://github.com/tc39/ecmarkup/pull/362 should have all the fixes and changes we discussed on the call, minus docs [11:30:53.0817] i didn't see a structured header doc section in the existing docs, and i didn't feel like writing one :P [11:35:51.0509] also the `` tag now _does_ go over the entire invocation [11:36:12.0368] e.g. `AO()` [11:36:58.0038] the xref is just checking for `parentElement`. additionally, putting it around just the AO name actually doesn't work correctly, because then the autolinker can't tell it's an invocation [11:37:10.0274] since the check for that is just the real naive "is the next character a '('" [12:11:27.0296] `npm run lint -- --fix` will fix a majority of the things the linter complains about [12:11:54.0979] which is a lot less painful than fixing them yourself [12:12:28.0912] re: docs, that's fine, I'll add docs for structure headers and effects at some point [13:02:05.0847] ah, good tip, didn't know about `--fix` [15:21:44.0258] you can also configure your editor to automatically run eslint autofix on save [15:22:34.0105] my .emacs is an ossified relic [15:22:52.0050] if i ever have to be productive in a language other than C++ i am screwed [15:23:46.0306] i'm sure you can configure your operating system to do it too :-p [15:29:21.0885] > <@ljharb:matrix.org> you can also configure your editor to automatically run eslint autofix on save I've never understood how anyone can stand this - saving shouldn't _change_ the file; I'm saving precisely because I am at a point where I do not want it to change! [15:29:59.0999] ¯\_(ツ)_/¯ for me it's that that's the point where i don't want the semantics to change, autofixes don't change the AST [15:30:05.0683] * ¯_(ツ)_/¯ for me it's that that's the point where i don't want the semantics to change, autofixes don't change the semantics [15:30:13.0360] * ¯\\\_(ツ)\_/¯ for me it's that that's the point where i don't want the semantics to change, autofixes don't change the semantics [15:30:26.0775] but you could ofc run it on the command line manually if you want, nbd