2021-07-01 2021-07-02 2021-07-03 2021-07-04 2021-07-05 2021-07-06 2021-07-07 2021-07-08 2021-07-09 [07:49:56.0017] added a sentence to https://github.com/tc39/ecma262/pull/2451/files [07:50:00.0311] I'm pretty happy with that [07:50:08.0063] let me know if it covers what you wanted [13:38:49.0727] i still feel like i wanna read the phrase "template raw value" somewhere 2021-07-10 2021-07-11 2021-07-12 2021-07-13 [17:42:57.0795] lol, just saw https://github.com/tc39/ecma262/issues/2454 [18:03:19.0475] was pretty good 2021-07-14 [16:10:17.0875] https://github.com/tc39/ecma262/pull/545 is updated including the ` : ` -> `: ` change we asked for [16:10:29.0552] I think it's good to go [16:10:51.0002] should get a review from at least one of shu or Michael Ficarra , though [16:11:12.0553] also it'll conflict with many open PRs, but I am happy to take care of the rebases 2021-07-15 [17:41:08.0477] will review next week or later this week if i decide to work [18:12:34.0637] I've reviewed it in the past, and I really don't expect to find anything new [18:13:00.0998] I can do a really quick once-over to make sure there's nothing stray included if you like [18:27:28.0654] Just skim for the syntax and read my description of the diff, basically [18:27:34.0253] * Just skim for the syntax/formatting and read my description of the diff, basically [18:31:52.0787] actually yeah, I see your diff of the rendering, that should be fine [18:32:08.0645] as long as we've not missed any recently-introduced AOs [18:32:25.0901] does ecmarkup ensure we don't define an AO without metadata? [18:32:52.0130] I see my RoundMVResult AO is there [18:35:07.0523] Nope, intentionally so that existing PRs still build [18:35:19.0531] we'll check manually for a while [18:35:28.0341] I'll turn on enforcement at some future point [18:37:43.0948] k yeah it's not the end of the world if we've missed some [18:37:52.0674] I'm gonna just stamp it [18:38:14.0826] ... set a reminder to enable enforcement? [18:38:23.0421] maybe best to just have a tracking issue [18:39:00.0622] I'll put it in the linting tracking issue [19:06:08.0751] ljharb: did that do anything? [19:07:26.0594] I don't have any clue what these numbers mean [19:11:48.0208] now i can post [19:11:54.0655] lol just needed to add more 9s [19:12:03.0644] ship it [19:13:17.0151] ok so i'll land 545 first, and rebase everything else on top [21:05:15.0042] ljharb: is 2442 a nontrivial rebase? [21:05:22.0536] yes [21:05:30.0009] strange [21:05:33.0782] i could probably figure it out but it took more judgement than i wanted [21:05:50.0926] it's like, 2442 changes adjacent to 545 changes, and git not being good at detecting that [22:03:47.0271] does https://github.com/tc39/ecma262/pull/2125 need a post-545 adjustment as well? [22:09:02.0757] probably not, but it needs further review [22:09:42.0849] yeah I don't see any new AOs, so it should be ready to go assuming we get approvals 2021-07-16 [12:13:10.0693] Michael Ficarra: bakkot: i wanna do a temperature check among us for moving structured clone into tc39 and owning it (+ the structured clone algorithms for 262 objects) [12:16:49.0078] I would be happy with that if HTML is on board [12:23:17.0873] indeed, domenic is the one who reached out to me to do it [12:23:32.0217] i'm thinking of an initial proposal to not expose it programmatically, just to do the refactoring across specs [12:23:53.0404] we'll then split the maintenance responsibilities as 262 owning the cloning algorithms for 262+402 objects, and HTML owns the others, instead of HTML owning everything [12:24:11.0055] the possibly contentious normative thing to hash out is what to throw for errors [12:37:25.0290] I'm OK with just deferring to hosts for that personally [12:38:18.0028] obviously I'd prefer to throw the appropriate 262 error, but if that's going to be contentious I wouldn't want to fight about it [12:39:10.0386] and just saying "throw a host-defined non-exotic value which has Error.prototype somewhere in its prototype chain" works for me [12:39:11.0668] or similar [12:42:16.0282] (with my user hat on, the precise type of an error basically never matters to me) [12:45:10.0266] beyond being contentious we can't really change it for HTML anyway [12:45:34.0381] > (with my user hat on, the precise type of an error basically never matters to me) yes, that's my hunch. it seems riskier than error timing, but still not risky in the scheme of things 2021-07-17 2021-07-18 2021-07-19 [19:02:29.0251] shu: I just reviewed TLA. Mostly looks good. If you still have stuff paged in at all, can you take a look at https://github.com/tc39/ecma262/pull/2408#discussion_r671922954, https://github.com/tc39/ecma262/pull/2408#discussion_r671923292, and https://github.com/tc39/ecma262/pull/2408#discussion_r671931375 ? Those are my only nontrivial comments. [10:43:40.0300] thanks for ping, looking now 2021-07-20 [12:23:40.0641] it might be good to land the proto one before TLA, but obv yall can pick the order [12:55:57.0271] they don't conflict in any way, do they? [13:01:59.0845] i wouldn't expect so. just speaking in terms of "order in which consensus was given" 2021-07-21 [10:40:46.0026] bakkot: nice, structured headers landed. rebasing https://github.com/tc39/ecma262/pull/2442 right now and got a question [10:41:15.0053] the HostEnqueueFinalizationRegistryCleanupJob is structured a little oddly [10:41:58.0008] that's what it looks like on a local build [10:42:49.0081] the odness is that the "Let cleanupJob be ..." section needs to come _before_ the description that "[It] is an implementation-defined abstract operation that schedules [...]" [10:42:54.0929] * the oddness is that the "Let cleanupJob be ..." section needs to come _before_ the description that "[It] is an implementation-defined abstract operation that schedules [...]" [10:43:38.0387] this looks weird currently with an initial sentence "The abstract operation HostEnqueueFinalizationRegistryCleanupJob", then a bunch of stuff, then another sentence of "[It] is an impl-defined abstract operation" [10:43:56.0341] any thoughts on formatting this? [10:44:56.0067] my first thought was to rephrase the "is an implementation-defined abstraction operation that schedules [...]" sentence into a conformance requirement, but it's not really a conformance requirement [10:50:53.0013] hm, i think i will rephrase that sentence to "An implementation of HostEnqueueFinalizationRegistryCleanupJob schedules _cleanupJob_ to be performed at some future time, if possible. It must also conform to the requirements in " [14:17:10.0599] I like the phrasing it ended up as 2021-07-22 [19:58:52.0883] Michael Ficarra: is 2125 ready to land? [20:35:57.0634] ljharb: no, give me a chance to review [20:36:03.0004] I'll get to it tonight and then put the label on [20:36:57.0805] Perfect, thanks [07:36:04.0824] so i've never developed a TS project before, how do i actually build ecmarkup? it's complaining that it can't find ecmarkdown [08:10:42.0397] oh i see, i guess i needed to `npm install`, but then how do i use a local copy of ecmarkdown? [09:54:41.0403] the official way is to do `npm link` in your local ecmarkdown directory and then `npm link ecmarkdown` in your ecmarkup directory [12:38:16.0308] cool, thanks [16:10:38.0497] i have a WIP of the annotation that works off of reachability of 'Call' [16:10:57.0086] the naive version is producing funny results [16:12:58.0424] it is marking static semantics as calling user code because we use ToString liberally [16:31:30.0775] bakkot: did we make it so that all `emu-clause`s have a `type` attribute? 2021-07-23 [17:20:12.0109] nope [17:20:20.0906] all AOs do, though, of any stripe [17:20:24.0172] (I believe) [17:20:48.0460] * all AOs do, though, including SDOs and host-defined AOs and so on [17:22:43.0936] what about all static semantics that also have aoids? [17:23:14.0439] i classified all the the `type="sdo"` into `type="static sdo"` vs `type="dynamic sdo"`, since i need that info to stop propagating the can-call-user-code annotation [17:23:29.0787] but that only works if we already exhaustively marked the SDOs [20:03:40.0814] I believe we have exhaustively marked the SDOs, yes [20:04:07.0098] SDOs have AOIDs still only because they do not yet have structured headers, since we just wanted to get that PR landed [20:07:46.0859] jmdyck: you should be able to speak here now if you're so inclined [21:00:06.0120] cool, thanks [21:06:23.0270] There are a few AOs that aren't the 'subject' of the emu-clause they appear in, so don't get a type attribute. E.g. thisBooleanValue [21:06:57.0444] As for SDOs, there are a few we don't mark with type="sdo": Evaluation, regex-evaluation, MV, TV and TRV. Also, the two clauses that define HasCallInTailPosition, although their parent does. Plus there are a few emu-annex'es that extend SDOs that don't get type="sdo" [21:08:23.0551] (So the rule appears to be: an emu-clause gets`type="sdo"` iff it contains the complete definition of exactly one SDO.) [21:09:00.0199] ("complete" ignoring the existence of Annex B) [21:09:57.0017] The static/dynamic (or Static/Runtime) dichotomy applies to more than just SDOs, so you might want to express it in the dl.header, unless you also want e.g. type="static abstract operation" and type="dynamic abstract operation". [21:11:35.0082] Also, classifying ToString as static or dynamic is problematic, as shu has seen. You might consider duplicating the part of it that's needed for static processing, which I think would be just NumericToString. (So then you could classify NumericToString as static and ToString as dynamic.) [08:05:58.0481] jmdyck: i don't think AOs themselves need to be classified as static or dynamic, just the SDOs (for the purposes of this can-call-user-code annotation anyway) [09:51:46.0966] Hm. So if you're classifying SDOs as to whether or not they can call user-code, why do you *also* need to classify them as static or dynamic? [09:53:38.0632] jmdyck: i'm doing a simple reachability analysis so AOs don't need to be manually classified. the idea is to mark a few leaves as "can call user code", and then propagate that up all AOs that can transitively call them [09:53:51.0583] i'd like this propagation to stop at static SDO boundaries [10:47:01.0468] but why stop there? why not just continue the analysis down? [10:57:11.0822] how do you mean, by classifying all AOs? [10:58:27.0274] ?? I thought the reachability analysis was already classifying all AOs. [10:58:43.0657] i'm confused [10:58:47.0353] me too [10:59:30.0974] it is classifying all AOs, and i said i want the propagation to stop at at static SDOs, and you said "why not continue the analysis down" [10:59:40.0350] i'm not sure what you mean by "why not continue the analysis down" [10:59:58.0280] use the same analysis to classify the SDOs [11:01:18.0522] ah i see, i suppose we could, but i wasn't planning to since there are far more static leaf nodes that we need to manually classify than "can call user code" ones [11:03:08.0903] that wasn't well expressed [11:03:27.0750] (I was about to ask for clarification!) [11:03:44.0677] i mean something more like, manually classifying it seems to be 95% of the work, i'm not sure what the reachability analysis here would get us [11:04:03.0624] but it's not that much code to write, so that seems like a fine thing to do [11:05:04.0522] re "manually classifying it seems to be 95% of the work": I'm not sure exactly what you mean by "it" there, or why you think the manual part is 95% of the work. [11:05:34.0104] let me start over [11:06:18.0826] the problem with "can call user code" is that there are relatively few chokepoints that can end up calling user code, like `Call()`, and the various internal methods e.g. `[[Get]]` when Proxy traps are involved. annotating only those and relying on a reachability analysis seems to be a good way forward. [11:06:56.0890] for "static or dynamic", are there also relatively few chokepoints? my inclination is there's just a bunch of static SDOs [11:13:22.0729] If "can call user code" is what you're interested in, then it seems to me that *that's* the question you should be asking of SDOs, not "static or dynamic". [11:15:23.0380] And I think you can use the same set of 'chokepoints' for SDOs as for AOs. [11:34:55.0704] On second thought, it needs to be larger, maybe for both. [11:36:13.0269] Or maybe not, hm. 2021-07-24 2021-07-25 2021-07-26 2021-07-27 2021-07-28 2021-07-29 2021-07-30 2021-07-31