2023-02-02 [19:33:56.0579] here is a build of the spec where `[[FieldNames]]` are clickable to highlight like variable names: https://bakkot.github.io/ecma262-previews/highlight-brackets/ [19:34:19.0495] it's mostly intended for Temporal and 402, which have a lot more algorithms with a lot of different field names [19:34:27.0674] but it seems like it is not harmful for 262? [19:34:37.0682] anyway requesting feedback before I commit to this in ecmarkup [20:55:07.0724] where’s the diff for 262? [21:02:41.0473] I don't understand the question [21:58:06.0465] like what's different in 262 from that change [22:18:02.0017] if you click `[[FieldNames]]` they highlight like variables do [08:15:25.0407] oh interesting, but they highlight across the entire spec, not just one algorithm [08:15:56.0312] that seems useful but also sort of implies that field names should be unique for a given purpose? [08:16:16.0376] ljharb: there's no way to tell two fields apart if they have the same name though [08:16:23.0525] since it's a dynamic concept [08:16:38.0813] right, hence implying they should be unique :-) [08:16:55.0557] PRs welcome [08:16:56.0449] like AB and SAB should share a name but like `[[Value]]` shouldn't be used for more than just completion records, or something [08:17:29.0819] I think it will be hard to make the field names globally unique while also not making them super verbose [08:17:52.0967] fair [08:19:37.0089] ljharb: though now that I check it out, I only see it highlighting a field in a single algorithm at any given time [08:19:55.0342] that makes this much less of a problem [08:20:28.0586] hm, if that's true then ok, but i grepped for the first `[[` and clicked on it and it went across more than one algo [08:20:36.0682] it was a `[[Value]]` in the returnabrupt macro iirc [08:21:46.0687] well highlights inside an AO seem to be bounded to the AO [08:21:57.0155] * well highlights inside an AO seem to be bounded to the AO [08:22:45.0837] ljharb: that behavior is shared with spec-alias variables such as _argument_ in the same section [08:23:02.0376] ah ok [08:23:05.0415] here's a good section for testing it out: https://bakkot.github.io/ecma262-previews/highlight-brackets/#sec-property-descriptor-specification-type [08:24:00.0120] ah ok makes sense [08:25:48.0851] I believe it stems from `findContainer` looking for ancestor emu-{clause,intro,annex} elements via `toggleFindLocalReferences` at https://github.com/tc39/ecmarkup/blob/4e43574fb6f8efab80aa74d79d58f7bfee97b6a5/js/menu.js#L573 [08:26:41.0202] * I believe it stems from `findContainer` looking for ancestor emu-{clause,intro,annex} elements via `toggleFindLocalReferences` at https://github.com/tc39/ecmarkup/blob/4e43574fb6f8efab80aa74d79d58f7bfee97b6a5/js/menu.js#L573 [08:27:18.0312] note that this also applies to the MOP methods, since they look exactly the same as fields [08:27:20.0545] but again, not harmful [08:37:11.0441] so anything that uses the \[\[Foo\]\] notation (but not \[\[%Foo%\]\]): a field of a record, an internal slot/method of an object, an attribute of a property, the \[\[Description\]\] of a Symbol. [08:37:28.0642] * so anything that uses the \[\[Foo\]\] notation (but not \[\[%Foo%\]\]): a field of a record, an internal slot/method of an object, an attribute of a property, the \[\[Description\]\] of a Symbol. 2023-02-08 [12:15:06.0618] i have a possible conflict today. should be fine but don't wait for me to start 2023-02-13 [08:37:46.0809] https://github.com/tc39/ecma262/pull/2947 ready for a stamp? [10:29:51.0545] ljharb: yeah I don't see why it's not marked as ready [10:30:29.0603] * https://github.com/tc39/ecma262/pull/2947 ready for a label? [10:34:15.0936] stamped [10:34:19.0465] * stamped [10:53:55.0724] thanks [11:13:40.0311] any more to do on https://github.com/tc39/ecma262/pull/2917 as well? [12:11:05.0495] that one just needs review from me and/or shu I think [13:49:03.0482] it's past the deadline rob set for editor group feedback, and looking at the form (which you all have access to), there were only 2 responses [13:49:09.0592] and one constructive piece of feedback which is good [14:35:35.0428] i don't think i have access to it, anything you can share? [14:48:45.0718] the feedback was that they'd prefer we didn't hold up PRs from contributors on consistency concerns [14:49:04.0227] and settle them afterwards [14:49:28.0099] i feel like that's reasonable for some normative stuff, especially if something is already not consistent 2023-02-14 [18:09:44.0323] we should set aside a few minutes at the beginning of the next editor call to discuss the feedback 2023-02-16 [16:11:26.0258] i had to revert 3006; the biblio task failed on it because it was trying to publish a sha that had already been published previously. that should probably be a silent success condition? [16:17:16.0050] uhhh the task uses the commit number, not the sha [16:17:45.0236] and the only way for the commit number to be reused is if you force-push to main, I think? reverts count as commits for the purposes of `rev-list --count` [16:18:07.0594] if you didn't force-push, I don't know what's going on there [16:33:56.0110] ah ok then that's what did it, i did force push, to remove my first attempt to fix it [16:34:03.0500] won't be doing that again :-) [18:19:06.0270] pulling in the new merges, finding some bugs. [18:19:16.0535] * pulling in the new merges, finding some bugs. [19:57:29.0627] actually only one bug. [20:12:57.0863] and one new inconsistency [20:31:15.0242] https://github.com/tc39/ecma262/pull/3017 [21:41:18.0352] jmdyck: if there's any chance of making a github action to detect these things on PRs - even if it remained optional - i think it'd be very helpful [06:12:29.0850] If it's optional, is there anything to prod the PR-owner to check the results? [06:20:50.0369] Is there a way to set things up so that the results go to me, and then I can decide if a reported error is due to a problem in my code or a problem in the PR? [08:11:30.0814] they’ll still see the failures - and certainly part of the action could be to notify you [10:47:46.0011] So they'd still get a red-X failure, but instead of "Required" in an oval, it'd say "Optional"? [12:46:02.0714] it's just say nothing, since only things with "required" are required, but yep 2023-02-28 [13:25:22.0197] okay I finally got some time to sit down with the stage 4 proposals and got something I'm happy with for symbols as weakmap keys: https://github.com/acutmore/ecma262/pull/3 [13:25:41.0975] shu: please review so we can discuss at tomorrow's editor call [13:38:41.0765] okay [14:31:28.0357] commented