2021-06-01 [18:19:23.0164] sideshowbarker: https://bakkot.github.io/matrix-logs/ [19:25:54.0924] > <@bakkot:matrix.org> sideshowbarker: https://bakkot.github.io/matrix-logs/ Beautiful [01:29:48.0147] bakkot: [01:30:11.0227] your logs look good - for some reason Chrome offers to translate from Albanian [02:39:57.0546] adding a `lang` attribute to the `html` would probably make Chrome not do that ```html ``` [02:40:13.0202] * adding a `lang` attribute to the `html` element would probably make Chrome not do that ```html ``` [07:08:01.0333] 👋 [07:08:14.0006] Hi ryzokuken !!! [07:08:50.0442] Rob Palmer Aki trying to close out that question about the video I sent ya'll in email/dm [07:09:12.0696] ping me when you log on? [07:16:59.0845] hey hey jory [07:33:40.0983] Hi yulia !!!! [08:24:45.0904] > <@sideshowbarker:mozilla.org> adding a `lang` attribute to the `html` element would probably make Chrome not do that > ```html > > ``` I'm hesitant to do this because the bot does not know what languages the channels it's scraping are in. it happens to be the case that the current set is english, but that's not a guarantee [08:26:17.0241] > <@bakkot:matrix.org> I'm hesitant to do this because the bot does not know what languages the channels it's scraping are in. it happens to be the case that the current set is english, but that's not a guarantee Ah yeah that makes sense [08:26:30.0090] I suppose Google's auto-detection would work better once there's more content... [08:30:40.0574] yeah in general language guessers aren’t reliable when there’s only a small amount of content [08:32:18.0188] in the W3C HTML checker I have a language-guessing library integrated in, to try to catch cases where a document has the wrong `lang` value [08:33:15.0442] and the error message that guesser emits includes a link to the bug tracker, for people to report cases where it’s misidentified the language of document [08:33:19.0728] https://github.com/validator/validator/search?q=language+misidentified+is%3Aissue&type=issues [08:34:02.0259] most of the reports are for documents with very little text content — things like online product catalogues [08:35:40.0536] anyway, the reason that guesser was added to the HTML checker is that we know there are a significant number of documents with `lang=en` attributes that aren’t in English [08:37:18.0044] …because of a cargo-cult copy/pasting that goes on — some developers don’t know what`lang=en` is, but they see it in another document, so so they just copy it as-is into their document, even if it’s not in English [08:38:06.0492] perhaps also has something to do with poorly made templates and such? [08:38:19.0655] the biggest problem that causes in practice is for non-English screen-reader users [08:38:35.0354] > <@usharma:igalia.com> perhaps also has something to do with poorly made templates and such? yeah stuff like that too [08:38:45.0523] "my wordpress theme comes with `lang=en` set" [08:38:52.0421] bingo [08:38:57.0247] * "my free wordpress theme comes with `lang=en` set" [08:39:32.0257] so anyway, a document having no `lang` at all is better for screen-reader users than a document have the wrong `lang` value [08:39:43.0293] * so anyway, a document having no `lang` at all is better for screen-reader users than a document having the wrong `lang` value 2021-06-02 [21:24:53.0072] Was the pipeline operator proposal integrated into the ES spec itself already? [21:25:55.0880] nevermind, of course not — I see it’s only at stage 1 still [21:39:16.0144] OK yeah, FYI we’re dropping all info about the pipeline operator from MDN and from [BCD](https://github.com/mdn/browser-compat- data) [21:41:32.0674] * OK yeah, FYI we’re dropping all info about the pipeline operator from MDN and from [BCD](https://github.com/mdn/browser-compat-data) [21:42:17.0390] for details, see https://github.com/mdn/content/pull/5394 [21:42:57.0229] * OK yeah, FYI we’re dropping all info about the pipeline operator from MDN and from [BCD](https://github.com/mdn/browser-compat-data) [21:43:49.0532] and see also https://github.com/mdn/browser-compat-data/pull/6957#pullrequestreview-509954390 [23:03:14.0923] Merged, thanks sideshowbarker :) [23:47:52.0146] > <@sideshowbarker:mozilla.org> OK yeah, FYI we’re dropping all info about the pipeline operator from MDN and from [BCD](https://github.com/mdn/browser-compat-data) Removing pipe operator’s documentation until it’s settled seems appropriate, given its high flux, but did something happen regarding the pipe operator at the May TC39 meeting? [23:51:42.0265] > <@jschoi:matrix.org> Removing pipe operator’s documentation until it’s settled seems appropriate, given its high flux, but did something happen regarding the pipe operator at the May TC39 meeting? Nothing I know of. But as far as implementations, Firefox backed out what it had implemented for it [23:54:43.0623] Oh yeah; also seems like a good idea. [00:04:51.0248] > ddbeck: The pipeline operator (|>) appears to be going backwards in terms of acceptance. This PR redirects the page to the parent operators page, then removes the content. Not sure what they mean by this. 🤔 [00:05:03.0131] * > ddbeck: The pipeline operator (|>) appears to be going backwards in terms of acceptance. This PR redirects the page to the parent operators page, then removes the content. Not sure what they mean by this. 🤔 [00:07:21.0958] * https://github.com/mdn/content/pull/5394#issue-655147724 > ddbeck: The pipeline operator (|>) appears to be going backwards in terms of acceptance. This PR redirects the page to the parent operators page, then removes the content. Not sure what they mean by this. 🤔 [00:09:40.0869] * https://github.com/mdn/content/pull/5394#issue-655147724 > ddbeck: The pipeline operator (|>) appears to be going backwards in terms of acceptance. Not sure what they mean by this. 🤔 [00:10:58.0498] * https://github.com/mdn/content/pull/5394#issue-655147724 > ddbeck: The pipeline operator (`|>`) appears to be going backwards in terms of acceptance. Not sure what they mean by this. 🤔 [09:10:17.0318] How would I go about teaching the TC39 Delegates channel that I'm a delegate? [09:11:05.0044] pinging one of the admins to add you [09:11:40.0965] lol [09:47:29.0639] hober: do you need/want access to the TC39 Delegates channel or extended access to the Reflector repo in the TC39's GH org? For the TC39 Delegates channel, I'd ping Aki Rob Palmer yulia, for the extended access you'd need a point of contact from your org to register a new delegate in the TC39's Admin-and-Business repo. I believe that's probably done at this point? [09:48:16.0758] I tried but I can't invite hober [09:52:49.0159] hober: you are now privileged [09:53:07.0165] I think I already have access to things on GitHub. [09:53:10.0186] Thanks! [14:55:13.0374] jmdyck: I'd like to get back to #545 now that fields have landed; but it needs a rebase, do you think you'll get a chance sometime? [15:16:20.0947] DerekNonGeneric: the stacks proposal is perfectly viable and in no way withdrawn [15:16:49.0405] DerekNonGeneric: in general, it's not necessarily appropriate for a reference implementation to exist for any pre-stage-3 proposal. [15:19:42.0294] DerekNonGeneric: also "SystemJS" has nothing to do with it - that the namespace is called "System" is the reason SystemJS named itself that, but the System namespace predates both SystemJS and the stacks proposal [15:20:26.0521] DerekNonGeneric: happy to chat more about it but the matrix interface is weird for me; i'd prefer irc :-) [15:25:10.0345] crystal clear now, thanks ljharb [15:50:48.0577] bakkot: 545 needs a few things more than a rebase; I should be able to get back to it soon. 2021-06-03 [01:00:24.0710] oooh, looks like someone mentioned this channel somewhere [01:00:35.0962] the voyager bot is here... [08:03:58.0178] is there a way to auto-accept DM requests? [08:04:56.0452] in practice, the DM request thing isn't much of a bother for me, since people can send messages before the DM request is accepted, and also because you end up having an open DM with many of the people you want to talk to [08:05:04.0548] (I don't know how to auto-accept) [08:05:57.0505] well, i'm trying to accept one someone sent me yesterday, and it says "The person who invited you already left the room." so i can't view what the message was [10:49:27.0252] i just want to disable that gate entirely; i don't want to have to approve DMs [11:07:46.0404] oh, I guess people should learn that they shouldn't leave the room like that, I dunno [11:08:02.0058] maybe someone else knows how to remove the gate, but I think once you know how to use it, it's really OK [11:12:27.0227] I expect it's intended as a mitigation for harassment until a mod can step in; if someone is sending you abusive DMs from multiple accounts, then you can block them without having to read the messages [12:53:43.0502] is it possible to consolidate matrix accounts somehow? [12:53:53.0141] i forgot i already had a mozilla.org one [12:54:31.0945] shu: there's currently no official consolidation or migration mechanism, but there's a tool at https://ems.element.io/tools/matrix-migration that kinda emulates it by inviting your new user into all the old user's rooms and such [12:54:47.0266] i see [12:54:47.0739] presumably(tm) it also works for consolidation* [12:54:52.0743] * I am not liable for any problems :D [12:54:56.0773] * \* I am not liable for any problems :D [12:55:05.0765] (of course you can just do this manually, by sort of orphaning one of your accounts) [12:55:19.0772] for permissions porting, we'll just do this manually, whether or not you use that tool [12:56:00.0382] > <@ljharb:matrix.org> i just want to disable that gate entirely; i don't want to have to approve DMs there's currently a small protocol niggle getting in the way of that; the inability to reliably tell whether a room is a DM or not [12:56:09.0502] presumably that'll get fixed with the "canonical DM" spec changes [12:56:14.0571] i guess i should just use the mozilla.org one, let me invite myself... [12:58:10.0182] oh i can't invite in all rooms [12:58:20.0884] okay, that's enough obstacles for one day, will try this later [12:59:19.0149] shu: you can join the rooms via links, but the way the rooms are set up currently, you cannot use the invite button to do it... [12:59:36.0836] maybe someone can change the permissions on all the rooms to make sure everyone can invite new people? [13:07:03.0342] ryzokuken: thaaaaaat seems like a bug [13:07:24.0945] the protocol, or at least the server, should not allow being in the state "anyone can join, but not anyone can invite" [13:07:30.0494] no, it's just permissions set badly. [13:08:07.0522] if the protocol allows permissions to be in an inconsistent state that's a bug in the protocol, not a problem with the permissions [13:08:07.0718] in the room settings, we changed it to "anyone with the link can join" but "who can invite" is set the just the admins or sth [13:08:35.0942] hm, that's a fair criticism actually. [13:08:53.0678] I could make an issue, but for now we can just fix the permissions [13:09:53.0089] same boat here: would like to consolidate (unsure whether i was mozilla.org or matrix.org) [13:10:14.0221] * same boat here: would like to consolidate (unsure whether i want mozilla.org or matrix.org) [13:12:10.0573] for sure want to get rid of the parenthesis after my name tho [13:12:56.0014] that would be a problem if both accounts have the same nick [13:13:18.0568] the `_` at the end solution works, but you don't even necessarily have to globally do that [13:13:44.0809] if there is a subset of rooms where you want both accounts to be present, just change the nicks of the secondary account for those rooms [13:14:10.0886] `/myroomnick ` in a room but change your nick in just one room [13:17:42.0842] i don't need both accounts to be present, but maybe if i globally update the nick of the secondary, i will not have the parens [13:17:52.0532] > <@bakkot:matrix.org> the protocol, or at least the server, should not allow being in the state "anyone can join, but not anyone can invite" I believe this is because invites can override things like bans [13:18:18.0800] though I'm not sure whether that is also the case when someone doesn't have unban perms 2021-06-04 [00:42:55.0901] so I’m working resolving https://github.com/mdn/content/issues/5647 [00:43:25.0459] …and I am reading https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#strict_mode [00:44:08.0171] …and there I read: > The body of a class is executed in strict mode [00:44:34.0825] …but I am trying to find the part of the ES spec which states that requirement [00:45:05.0692] at https://tc39.es/ecma262/multipage/ecmascript-language-source-code.html#sec-strict-mode-code find this: > All parts of a ClassDeclaration or a ClassExpression are strict mode code. [00:45:22.0627] * at https://tc39.es/ecma262/multipage/ecmascript-language-source-code.html#sec-strict-mode-code, I find this: > All parts of a ClassDeclaration or a ClassExpression are strict mode code. [00:45:33.0521] * at https://tc39.es/ecma262/multipage/ecmascript-language-source-code.html#sec-strict-mode-code, I find: > All parts of a ClassDeclaration or a ClassExpression are strict mode code. [00:46:41.0438] …which I realize is a non-normative re-statement of that actual requirements — but anyway, that does not explicitly say anything similar about the body of a class [00:52:05.0912] aha nevermind I think I found it myself: https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#prod-ClassExpression [00:52:28.0393] …which of course is all obvious in hindsight [05:18:42.0268] i.e., the fact that "the body of a class" is included in "All parts of a ClassDeclaration or a ClassExpression" ? [07:22:59.0236] jmdyck: yes, that 2021-06-05 [18:15:28.0645] settled on mozilla.org account bc impossible to put your account into an unrecoverable state (if you get locked out of matrix.org accounts, there is no recourse) [19:22:56.0652] it has occurred to me that i can champion my own proposals seeing as how i am in two orgs that are ecma members [19:36:07.0358] it would be nice if someone can clarify exactly what deliverables are necessary for a proposal [19:36:41.0963] specifically, do i need a keynote presentation as well as a repo w/ explainer text? [19:38:11.0147] DerekNonGeneric: https://tc39.es/process-document/ [19:39:13.0890] not mentioned here, but stage advancement (past 0) requires consensus, which can only be achieved at plenary, so you will also need to make a presentation at a meeting sufficient [19:39:34.0836] strictly speaking no slideshow is required for this, and for very simple proposals going for stage 1 people don't always bother, but it's a good idea [19:40:04.0153] * not mentioned here, but stage advancement (past 0) requires consensus, which can only be achieved at plenary, so you will also need to make a presentation at a meeting sufficient to convince people it's worth pursuing [19:40:54.0384] for advancement, you'll also need to add your proposal along with the supporting materials to the agenda for a meeting at least ten days before the start of that meeting [19:41:17.0027] (each agenda lists the deadline for that meeting) [19:48:32.0946] interesting, guess stage 1 is what i would be requesting seeing as how i have not learned any ecmamarkup [19:49:31.0285] thanks for the tips bakkot [19:56:19.0571] you'd be requesting stage 1 anyway, proposals have to go through the stages in order [20:00:03.0939] that's news to me (the accessible Object.hasOwn proposal skipped stages) [20:09:57.0867] it is possible to advance multiple stages in a single meeting, yes [20:10:30.0072] only ever happens for very small proposals, though, and it's pretty unusual [20:12:11.0836] basically the thing that happens is you go for stage 1, but have satisfied the requirements for stage 2, and after you present if people are sufficiently enthusiastic about advancement, and there's no major questions about semantics remaining, you say "ok, then can we have consensus for stage 2 also" [20:12:54.0717] I wouldn't recommend that as the goal, though; usually there will be major questions about the semantics. there are almost always such questions, for early-stage proposals. [20:15:43.0597] incidentally if you want to attend you will need to get one of your organizations' current delegates to open a PR to the admin-and-business repo with your details (which is private to delegates) [20:24:33.0856] ok, i will need to wait for business hours tomorrow (thanks again for the info bakkot) [20:25:35.0583] ooh it's Friday [20:26:21.0667] next meeting isn't until the middle of July anyway, so don't feel too rushed [20:36:19.0892] DerekNonGeneric: oh, also, I should have pointed you to the actual docs for how to champion a proposal, i.e. https://github.com/tc39/how-we-work/blob/master/champion.md [20:45:08.0923] super useful, thanks (had not seen this yet) [10:22:11.0599] Justin Ridgewell: any plans to bring `groupBy` to plenary sometime soon? (I ask because I needed it today.) [10:27:10.0359] hmm, I just realized there's actually a possible design question with `groupBy`, namely, do you return a Map or an object [10:27:24.0075] Map is more useful but more awkward [13:24:18.0703] Let's generalize objects to permit any JS value as a property key to address this issue [13:41:49.0379] 😐️ [13:43:44.0101] We can use obj{prop} to avoid the legacy ToPropertyKey algorithm [13:44:05.0259] Obviously with [no LineTerminator here] [13:46:02.0775] We would of course have to add `Object.getOwnPropertyNamesNoForReal`, to avoid breaking existing consumers of `getOwnPropertyNames` and `getOwnPropertySymbols` [13:46:37.0688] `Object.getOwnPropertyNamesFinalFinalVersion2` [13:48:01.0200] Property “names” probably would no longer be an apt name; more like `getOwnPropertyKeys`. Though how prototypes would work is another issue… [13:48:47.0956] * Property “names” probably would no longer be apt terminology; more like `getOwnPropertyKeys`. Though how prototypes would work is another issue… [16:22:11.0520] bakkot: Thanks for the prompt. https://docs.google.com/presentation/d/1fY_jsD8bVZ8P95Mr7cEr3WdCbhMLdEQ7OS5hhLCbfJ4/edit [16:33:59.0547] Justin Ridgewell: re slide 7: it's not just Lodash, it's every language with a `partition` method: of the top of my head, at last haskell, scala, ruby, kotlin, rust [16:36:23.0355] (It is of course still confusing even though there's strong precedent for one choice. Just wanted to call out that the precedent isn't just Lodash.) [16:38:36.0013] I’ll update [16:39:04.0907] (I’ve never used a functional language, was’t aware of the wider precedent) 2021-06-06 [18:38:48.0517] * Property “names” probably would no longer be apt terminology; it could be more like `Object.getOwnPropertyKeys`. [18:44:27.0511] * Property “names” probably would no longer be apt terminology for non-string values; the method name could be like `Object.getOwnPropertyKeys`. [18:44:45.0446] * Property “names” probably would no longer be apt terminology for non-string keys; the method name could be like `Object.getOwnPropertyKeys`. [21:33:36.0541] Anyone know what's going on here? Are we all misunderstanding? https://stackoverflow.com/questions/67855714/eval-declaration-instantiation-when-calling-context-is-evaluating-formal-param [22:42:33.0855] loganfsmyth: that note became stale as of https://github.com/tc39/ecma262/pull/1046 [22:43:25.0564] I suppose I'll open a PR [22:44:57.0707] excellent, that makes sense [22:48:11.0618] https://github.com/tc39/ecma262/pull/2428 [22:48:42.0996] loganfsmyth: You want to answer the stackoverflow question or shall I try to dig up my old account? [22:50:01.0509] I posted an answer, thanks! [11:39:06.0092] jmdyck: re https://github.com/tc39/ecma262/issues/2400, you suggest replacing "Set the code evaluation state of contextA such that when evaluation is resumed with a Completion v [...]." with "Resume contextB passing B-VALUE. Let v be the value returned by the resumed computation." [11:39:17.0501] problem: it is not generally the case that contextB is the thing which resumes the thing just suspended. [11:40:22.0294] e.g., in Await, it's not contextB which does the resumption, but rather some future Await Fulfilled Function (or Await Rejected Function, of course) [11:40:46.0978] I'm trying to think of an alternative phrasing which avoids this, but haven't come up with anything I like yet [11:43:00.0616] "the thing which resumes" present tense? I say that contextB is the execution context that most recently *resumed* the evaluation of contextA. [11:43:29.0448] I'm focusing specifically on the step > Resume contextB passing B-VALUE. Let v be the value returned by the resumed computation. [11:43:52.0369] to me, that step implies that contextB is going to be the thing which provides _v_. [11:44:18.0768] and, by extension, is going to be the thing which _subsequently_ resumes contextA. [11:46:44.0315] Ah,okay. Well, it doesn't actually *say* that contextB will be returning v and resuming contextA, though that's what I would have thought. [11:47:55.0984] I still don't grok Await machinery [11:49:54.0350] It's not just Await; the same issue arises for plain generators. contextB is the _previous_ caller of `Generator.prototype.next`, whereas _v_ is going to be provided by the _next_ caller of `Generator.prototype.next`. [11:51:29.0174] Maybe something like > 1. Resume contextB passing B-VALUE. > 1. Assert: when control reaches here, contextA is once again the running execution context. > 1. Let _v_ be the value with which contextA was resumed. [11:51:32.0447] and those can be 'in' different contexts (w plain generators)? [11:52:05.0563] they are necessarily going to be in different contexts, since each call to `.next` (as with all function calls) creates and pushes a new context [11:53:01.0898] I guess I ought to have said "contextB is the execution context of the previous call of Generator.prototype.next", not "is the caller of" [11:53:07.0974] sorry, i need to page this in [11:53:22.0639] haven't thought about it for a while [11:58:02.0893] Not to worry, lots to page in [11:58:19.0303] I'll have a PR up in a bit [12:02:48.0102] okay, i think i'm more or less up to speed [12:03:46.0179] And yeah, the wording could be improved, but I'm not sure about your suggestion. [12:09:58.0518] I think it needs to be clearer that the thread of control that performs the 'Resume' step has to then (suspend and) wait until *it* is Resumed (if ever), at which time a value (v) will be supplied. [12:10:44.0587] Maybe it would suffice if just defined 'Resume' somewhere. [12:10:51.0551] * Maybe it would suffice if we just defined 'Resume' somewhere. [12:12:42.0840] There's always an explicit suspension before the Resume, which maybe makes it clearer? [12:13:08.0697] Usually, but not quite always, immediately before the Resume [12:15:29.0763] Actually that's maybe false? [12:16:10.0773] Note that GeneratorResume, GeneratorResumeAbrupt , and AsyncGeneratorResumeNext use the "Resume ... Let" step format, although those are all going "the other way", right? [12:16:13.0600] There's always an explicit "remove the current context from the stack", though [12:16:51.0899] Yeah. For those it makes sense because it really is the execution which is Resumed which is providing the value. [12:19:37.0784] Having the "Resume" and "Let" in the same step helps (to some extent) convey that the 'lifetime' of the step includes a resume-to-suspend chunk of execution of another thread of control. [12:20:56.0621] now have a draft at https://github.com/tc39/ecma262/pull/2429 [12:21:22.0113] I can see the case for having it be a single step, yeah. Hmm. [12:34:31.0291] I have notes about suggesting an AO to have one place to clarify the semantics of transferring flow of control (suspend and resume). [12:36:09.0447] Rather than having to convey it "inline" at each point where it occurs. [12:37:49.0523] But I didn't want to pull that into 2400. [12:43:47.0492] To the original point you raised, I could change "Let v be the value returned by the resumed computation." to something like "If _contextA_ is ever resumed again, let _v_ be the value supplied by the context that resumes it." [12:45:58.0829] or maybe "... the value supplied at the time of resumption" [12:47:22.0099] I am pretty indifferent between that and the wording I used in the PR, which is "the value with which it was resumed" [12:47:39.0419] that's fine too. [12:47:43.0392] I also changed all the places which do such a resumption to "Resume ... with _v_" [12:50:50.0953] PrepareForTail call is going to just remain incoherent, I guess [12:51:26.0408] * PrepareForTailCall is going to just remain incoherent, I guess [12:53:35.0146] I've updated that comment in 2400. [13:10:01.0841] I forget, where do you discuss PrepareForTailCall? [13:14:05.0401] I don't [13:14:19.0995] I've been ignoring it because it's obnoxious, basically [13:18:47.0324] what it _wants_ to say is, replace the current execution context with that of the new function, such that when you ultimately reach the Return algorithm step which would take you back to the `Let result be Call(...). Return result.` steps following this PrepareForTailCall, instead move control back to the most recent `Let result be OrdinaryCallEvaluateBody(...)` step, which is where the aforementioned `Return result.` step would have returned to [13:19:44.0326] but the problem is that "that of the new function" isn't really coherent, and in fact not all function invocations push a new context as their first step - revoked proxies, in particular, do not [13:22:16.0958] so, what PrepareForTailCall does instead is just pops the current execution context _without_ transferring control back to the underlying context, and continues execution into Call. When Call returns, you are supposed to understand that this transfers control back to the step which did OrdinaryCallEvaluateBody. [13:22:55.0394] "the new function" = the function passed to `Call` immediately after the invocation of PFTC? [13:23:28.0071] right [13:47:21.0655] This involves EvaluateCall's Assert "... the above call will not return here ..." [13:50:09.0511] * This involves EvaluateCall's Assert "... the above call will not return here ..."? [13:52:51.0778] So it's similar to what I complain about in 2400, where manipulating the context stack is supposed to change where an operation will return to. [14:07:14.0314] Is tail-call optimization observable in the spec? [14:10:51.0721] (I.e., did the addition of TailCall stuff to the spec change the behavior required of implementations?) [14:34:34.0636] Theoretically, yes, although more as a matter of social consensus than as a question of what's actually clear from the written specification: the TailCall stuff is supposed to require that implementations implement proper tail calls. [14:35:21.0312] i.e., to allow you to write code which depends on very deep recursion as long as each recursive call is in tail position [14:36:11.0596] but since the spec as currently written does not have a notion of "running out of stack space", and since execution contexts are strictly a spec fiction, it's not entirely clear to me how the PrepareForTailCall stuff is supposed to require this [14:38:22.0471] however, as a stupid and I think unintentional side effect, it also has an effect on the realm used for the TypeError produced when invoking a revoked proxy [14:38:59.0491] when invoking such a proxy in tail position, that is [14:39:22.0057] previously it had a similar effect on the realm of the TypeError produced when invoking a class as a function, but that changed with the merge of https://github.com/tc39/ecma262/pull/2216. [14:39:55.0924] (there's still incorrect test262 tests about this which I haven't been able to work up the willpower to fix, given how inane this corner of the spec is: https://github.com/tc39/test262/issues/2978 ) [14:45:55.0975] > the spec as currently written does not have a notion of "running out of stack space", and ... execution contexts are strictly a spec fiction [14:46:09.0104] * > the spec as currently written does not have a notion of "running out of stack space", and ... execution contexts are strictly a spec fiction [14:47:26.0721] * > the spec as currently written does not have a notion of "running out of stack space", and ... execution contexts are strictly a spec fiction So the observable behavior exhibited by the spec model will be the same with or without the TailCall stuff, right? [14:47:45.0099] * > the spec as currently written does not have a notion of "running out of stack space", and ... execution contexts are strictly a spec fiction So the observable behavior exhibited by the spec model will be the same with or without the TailCall stuff, right? [14:48:43.0068] Other than the bit about the realm for the TypeError when invoking a revoked proxy, yes. [14:49:02.0801] right, sorry, that. [14:51:47.0607] The idea is that, although we mostly pretend the spec is describing an abstract (and hence unbounded) machine, you are supposed to remember when looking at this part that in fact you are going to be running it on a real (and hence bounded) device, which means that execution contexts will correspond to some finite resource, and hence the requirement in PrepareForTailCall that you discard the old execution context before doing the tail call is supposed to be understood as a requirement that you do not consume more of said finite resource [14:52:03.0515] But again this is a "social consensus" thing, not something which is actually present in the spec-as-written [14:56:11.0107] It seems like it should have been possible to express the idea/requirement without making the spec incoherent. [14:57:40.0747] I think it's possible that it's coherent if you have the right mental model of how execution contexts and "Return" work, I just don't know what that model is, and the spec does not lay it out [14:59:01.0622] yeah, I tried to grasp something of that mental model in 2400. [14:59:57.0550] But I suspect there are parts of the spec that have a conflicting mental model. 2021-06-07 [07:12:16.0277] I suspect that, if we want to make the mental model of the spec clearer, we should make the text higher level (explaining intentions more) rather than lower level (having very detailed mechanics that imply the right thing) [07:15:10.0096] I think we'd want both: high level in the prose and low-level in the algorithms. [07:15:17.0126] * I think we'd want both: high-level in the prose and low-level in the algorithms. [07:17:45.0802] I guess it depends what you mean by low-level. I don't think we should go much lower level than today. [07:18:15.0710] If edits are being made, I would recommend focusing on the prose as the higher priority, since the audience of the spec is humans. [07:48:00.0414] Do you view what bakkot and I are doing/discussing as "going lower level than today"? [07:49:44.0415] (Just trying to get a better sense of what you're advising against/about.) 2021-06-08 [21:28:33.0878] bakkot: (re tail calls) you said "instead move control back to the most recent `Let result be OrdinaryCallEvaluateBody(...)` step". I assume you mean the most recent "pending" OrdinaryCallEvaluateBody step. But I don't think that would work, because the first thing after that call is "Remove calleeContext from the execution context stack", which you don't want to do, because PrepareForTailCall already removed that context from the stack. [21:29:17.0964] * bakkot: (re tail calls) you said "instead move control back to the most recent `Let result be OrdinaryCallEvaluateBody(...)` step". I assume you mean the most recent "pending" OrdinaryCallEvaluateBody step. But I don't think that would work, because the first thing after that step is "Remove calleeContext from the execution context stack", which you don't want to do, because PrepareForTailCall already removed that context from the stack. [21:39:14.0252] jmdyck: ah, yes, good point. I'm not sure exactly where it's mean to return to, then [21:39:29.0642] possibly something like "return to that step, but don't do the following one because calleeContext has already been removed"? [21:41:03.0766] in the case that the tailcall occurs in function being invoked via `[[Call]]` you could return from that `[[Call]]`, but that doesn't work if the tailcall occurs while doing `[[Construct]]` [21:42:27.0658] My current guess is that, if fn A calls fn B in tail position, then `Call(B)` returns to where `Call(A)` would have returned to: step 7 in EvaluateCall, but it's an outer execution of EvaluateCall. [21:44:37.0646] That works if you're just doing calls, but doesn't work if fn A was invoked with `Construct(A)` rather than `Call(A)` [21:45:05.0070] it's possible that's just an oversight [21:45:58.0508] Hmm [21:47:42.0147] I wonder what engine262 does here [21:53:02.0015] It's an oversight for me. I don't think you can call it an oversight for the spec, because the spec says almost nothing about where control returns to. [21:53:28.0184] * It's an oversight for me. I don't think you can call it an oversight for the spec, because the spec says almost nothing about where control returns to in tail calls. [21:54:27.0536] I'm going to add a comment about tail calls to 2400. [22:02:21.0526] (tomorrow) [22:07:32.0902] or maybe i should make it a new issue, since the solution will probably be different from the solution for the stuff that's currently in 2400. [22:08:36.0858] either way [22:09:26.0991] also tailcalls are a huge political mess which sucks huge amounts of time and energy whenever we get into it, so everyone tries to avoid the topic [22:15:53.0820] I wonder if I could just email Allen and get him to explain what he was thinking when he wrote all this [22:16:00.0517] might be worth a shot [22:16:47.0516] oh that's cheating! :) [22:32:24.0483] I suppose he's probably busy with hopl at the moment anyway [22:36:08.0799] I thought hopl was last year, but i see it was postponed. [22:37:06.0537] indeed [22:37:19.0795] he finished the paper last year, I believe, but I don't know what the status of the accompanying talk is [22:37:30.0479] if it were me I'd've been putting off writing the talk until about now [07:24:23.0118] http://test262.report appears to be down. [07:24:54.0365] jmdyck: yes, for a while now [07:25:05.0974] this is the issue: https://github.com/bocoup/test262-report-issue-tracker/issues/27 [07:26:24.0459] i took a snapshot a few days ago when it was up (it is intermittent): http://web.archive.org/web/20210603160512/https://test262.report/ [07:28:05.0690] Yeah, I found the archive.org snapshot, but I think it's incomplete (or the navigation is off). [07:29:27.0569] hmm maybe the crawler didn't grab everything... what is it missing? [07:29:37.0414] ill make sure i catch it the next time i go to take a snapshot [07:30:13.0685] oh i see [07:30:16.0537] darn [07:31:18.0296] E.g., if you click on "Language Syntax", I get "The Wayback Machine has not archived that URL." [07:31:27.0852] * E.g., if I click on "Language Syntax", I get "The Wayback Machine has not archived that URL." [07:34:52.0754] And yet, if you check http://web.archive.org/web/*/https://test262.report/browse/language/* , archive.org *has* archived lots of pages under /language/, so I'm not sure what's going on. [07:35:46.0965] * And yet, if you check `http://web.archive.org/web/*/https://test262.report/browse/language/*` , archive.org _has_ archived lots of pages under /language/, so I'm not sure what's going on. [14:38:00.0670] bakkot: the issue turned into a PR: https://github.com/tc39/ecma262/pull/2430 [14:38:08.0512] * @bakkot: the issue turned into a PR: https://github.com/tc39/ecma262/pull/2430 [14:38:14.0468] * bakkot: the issue turned into a PR: https://github.com/tc39/ecma262/pull/2430 [15:06:52.0686] sweet 2021-06-09 2021-06-10 [19:37:20.0873] Any input any of might y’all might have on https://github.com/mdn/content/issues/309 would be welcome [19:38:12.0726] The OP asserts *“Static class fields should not yet be documented without a disclaimer.”* [19:42:22.0766] …and suggests that to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static we add the same warning text that the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields article has — which is: > This page describes experimental features. > > Both Public and private field declarations are an experimental feature (stage 3) proposed at TC39, the JavaScript standards committee. > > Support in browsers is limited, but the feature can be used through a build step with systems like Babel. See the compat information below. [19:43:04.0338] adding that sounds reasonable to me [19:43:19.0178] is there any reason I shouldn’t? [19:45:06.0592] I see that https://tc39.es/proposal-class-fields/#prod-FieldDefinition is still at Stage 3, so that assertion is accurate at least [19:46:31.0225] further though, the OP says: > Yes, `static` *methods* are standardised just fine, but https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static unfortunately describes all kinds of static members, both methods and "properties" (it doesn't even use the term "public field"). It doesn't even link the pages about method definitions or public class fields. That's why we need a banner on this page as well (of course, only for static fields). Students are already confused because they read MDN but then their ES2020 tooling won't accept the syntax they've seen. [19:48:26.0108] The proposal text is out of date: it's stage 4, and landed in the specification [19:48:36.0893] aha [19:48:56.0418] OK, I had vaguely remembered that it landed in the spec [19:49:10.0170] https://github.com/tc39/ecma262/pull/1668 is the PR [19:49:18.0389] thanks much [19:50:33.0579] well then, incidentally, there remains this general problem it’s hard for me and others like me to know when a proposal has finally been merged into the spec [19:51:03.0291] the canonical way is to check https://github.com/tc39/proposals [19:51:34.0262] in particular, see https://github.com/tc39/proposals/blob/master/finished-proposals.md [19:51:52.0462] OK [19:52:05.0088] yeah but even though I actually knew that, for some reason I consistently fail to check it [19:52:10.0124] I keep re-learning this [19:52:17.0996] maybe it’ll eventually stick [19:53:26.0547] OK, well I will update both the MDN warning text and also https://github.com/mdn/browser-compat-data (which is what the Specification section is now generated from) [19:55:22.0637] sideshowbarker: navigating the proposals in the various stages is probably easiest by using the footer of the tc39 site (https://tc39.es/) [19:55:28.0386] as far the content of the article itself, I guess it would be worthwhile to refine that content to use the correct terms — e.g., _public field_ — and to put one separate section for static methods, and another for fields (and add the suggested links) [19:56:16.0553] yeah, so there's a matrix of stuff: [static, instance] x [public, private] x [field, method, accessor] [19:56:43.0843] prior to #1668 landing, the only part which was filled out was [static, instance] x [public] x [method/accessor] [19:56:53.0360] now it's completely filled out [19:57:10.0643] OK [19:57:29.0252] I'm not sure what the best way to present that matrix is, though [19:57:51.0978] (s/matrix/cartesian product/) [19:58:21.0936] yeah I guess it’s just relatively complicated and kind of an information-design challenge — as far as documenting it in MDN [19:59:16.0083] anyway, if anybody is interested in putting together a PR for resolving the more-substantive part of https://github.com/mdn/content/issues/309, that would be very welcome [19:59:51.0601] otherwise I guess I will circle back around to it myself at some point later [20:28:10.0841] oh hey bakkot I just noticed one thing other worth mentioning to you and here —  all the Specification links to the ES spec in MDN now reference the multipage spec e.g., at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static#specifications [20:32:58.0261] nice! [01:47:41.0693] crazy idea for y’all to consider: after has gone through all the stages and gets merged into the spec, change the `body` start tag in the HTML source of the proposal to this: ```html ``` [01:48:52.0113] …alternatively, to the full spec: ```html ``` [01:49:34.0855] …in other words, make the proposal document redirect to the corresponding fragment in the ES spec [01:50:21.0688] * crazy idea for y’all to consider: after a proposal has gone through all the stages and gets merged into the spec, change the `body` start tag in the HTML source of the proposal to this: ```html ``` [02:05:13.0231] > <@dereknongeneric:mozilla.org> sideshowbarker: navigating the proposals in the various stages is probably easiest by using the footer of the tc39 site (https://tc39.es/) I see now — thanks! [02:08:03.0294] but it might help some of that footer also included all the merged proposals too I realize that’s a longer list — but it could all be put into collapse `details` element [13:43:44.0098] > <@sideshowbarker:mozilla.org> well then, incidentally, there remains this general problem it’s hard for me and others like me to know when a proposal has finally been merged into the spec sideshowbarker: i know we had a similar confusion come up when the footer had just landed, so perhaps some disambiguation could be of some use here https://github.com/tc39/tc39.github.io/issues/217 [13:46:59.0460] created an issue at https://github.com/tc39/proposals/issues/360 for my proposal-redirect idea [13:49:32.0748] oh, hmm interestingg [14:55:21.0799] looking at https://github.com/mdn/content/issues/5875 [14:56:02.0279] per-spec, `new Uint8Array("nope")` should not throw, right? [15:00:16.0234] correct [15:01:47.0616] when called with a non-object it coerces the argument to an integer, which defaults to `0` for anything which would be NaN [15:02:33.0700] OK, thanks [15:02:46.0832] I wonder if that page was written back when it was a Khronos spec [15:03:02.0207] ah yeah that would make sense [15:03:16.0696] I had forgotten the genesis for TypedArray [15:03:37.0656] but incidentally, what does the requirement in https://tc39.es/ecma262/multipage/indexed-collections.html#sec-%typedarray% actually apply to? [15:04:13.0832] invoking rather than constructing with `new` [15:04:33.0489] aha, yeah — thanks again [15:04:38.0338] or, wait [15:04:39.0101] sorry [15:05:05.0262] this one is for calling the actual TypedArray object [15:05:12.0884] which is `Uint8Array.prototype` [15:05:18.0522] so this is what happens if you `new Uint8Array.prototype` or whatever [15:05:25.0727] /me looks again [15:05:36.0924] ah OK [15:05:54.0289] er, sorry, `Uint8Array.prototype.__proto__` [15:05:56.0648] or something like that [15:05:59.0162] I have to page this in [15:06:17.0811] `Uint8Array.prototype.__proto__.constructor` [15:06:19.0228] there we go [15:06:41.0898] so that error is for `Uint8Array.prototype.__proto__.constructor()` and `new Uint8Array.prototype.__proto__.constructor()` [15:07:52.0645] /me prepares a PR for removing the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Typed_array_invalid_arguments article [15:21:55.0583] sideshowbarker: btw, my matrix logger will let you link to ranges, same as with github [15:22:00.0276] just shift-click the end of the range [15:27:01.0021] > <@bakkot:matrix.org> sideshowbarker: btw, my matrix logger will let you link to ranges, same as with github beautiful — thanks for the heads-up 2021-06-11 [11:54:54.0519] bakkot: Currently, some preambles give a parameter-'type' as "a List of Foo" (mostly "a List of ECMAScript language values"). But what about if the 'element type' isn't a single type? E.g., in #1713, MakeIndicesArray's _indices_ param is a List where each element is either a Match Record or *undefined*. Should the preamble just say "a List" (as it does currently), or should there be a (standard) way to convey the type of elements? [11:57:00.0264] hmm [11:57:16.0848] would be good to get a standard wording, but everything unambiguous I can think of ends up pretty long [11:57:53.0949] "a List whose elements are each either undefined or a Math Record" is about the best I can do [12:06:44.0302] and if there were 3 possibilities, that'd still be ambiguous: "a List whose... either (A or B or C)" vs "(a List whose ... either (A or B)) or C" (Though the latter probably doesn't occur, and if it did you could rewrite as "C or a List whose ... either A or B" to avoid the ambiguity) 2021-06-12 2021-06-13 [12:47:39.0588] devsnek: Thanks! I logged into Element and now I'm in! [12:47:57.0854] 👍 [12:48:47.0196] element is so dumb sometimes lol 2021-06-14 [00:33:42.0113] some discussion from whatwg about exposing structured clone: https://github.com/whatwg/html/pull/3414#issuecomment-853998618 [01:11:58.0684] funny, i was just reading the C++ impl in SM https://searchfox.org/mozilla-central/source/js/src/vm/StructuredClone.cpp [01:23:47.0577] unclear if the ask is simply to expose `structuredClone(value, options)` or what else that might entail, but seems like it would be really handy for it to be available somehow https://whatpr.org/html/3414/structured-data.html#structured-cloning [08:25:26.0785] does anyone have recollection of a synchronous Promise introspection API? e.g. something that gives back stuff like `{ state: "fulfilled", value: ... }`? [08:30:12.0574] something like promise.isFulfilled or like getting the value back, or just introspection? [08:30:21.0095] i was talking earlier about a similar api with somemone [08:30:33.0650] * i was talking earlier about a similar api with someone as an alternative for the deferred eval thing [09:06:33.0356] yulia: I think we tend to view this as violating some kind of fundamental principle [09:09:47.0518] maybe as part of https://w3ctag.github.io/promises-guide/ but I'm not sure which part [09:15:22.0048] I vaguely recall something to this effect but can't find a proposal. Closest I can find is https://github.com/tc39/proposal-async-await/issues/16 and some discussion in https://github.com/tc39/notes/blob/master/meetings/2015-07/july-30.md#64-advance-async-functions-to-stage-2 [09:27:15.0342] this was also discussed in the context of cancellable promises [09:39:53.0383] i'm thinking of getting both state and value back [09:40:16.0491] the specific context is application-level optimization opportunities to skip microtask ticks [09:41:03.0704] my initial take was along the lines of what littledan said with violating some kind of anti-Zalgo principle [09:42:23.0406] bakkot: thanks for that thread, the reason that killed that transformation idea is exactly the motivation for wanting it [09:43:13.0385] though in this case, there's no problem in that the buck is passed to the application. it's up to the app to write stuff like `let x = promise.tryGet().state == "fulfilled" ? promise[inspectSymbol].value : await promise;` [09:43:16.0048] err [09:43:25.0269] * though in this case, there's no problem in that the buck is passed to the application. it's up to the app to write stuff like `let x = promise[inspectSymbol].state == "fulfilled" ? promise[inspectSymbol].value : await promise;` [09:45:36.0006] yeah this was my reaction as well, but this is what the write up was from that alternative: https://github.com/tc39/proposal-defer-import-eval/blob/main/alternatives.md#delegating-work-to-blocking-workers [09:46:27.0514] i forgot exactly what that looked like, but its a blocking api. I don't think it is realistic but it keeps coming up [09:47:51.0638] blocking seems different to me than this, which is fine with async waiting, but want to know when it would be wasteful [09:48:02.0509] * blocking seems different to me than this, which is fine with async waiting, but wants to know when it would be wasteful [11:39:16.0812] there was also https://github.com/tc39/proposal-atomics-wait-async/pull/30 [11:39:46.0852] I think for the vast majority of promises the single microtask tick is going to be irrelevant next to the time it takes for the promise to settle in the first place [11:48:24.0452] Does having the state of the promise available synchronously have a huge benefit over checking it in one-tick: https://gist.github.com/jamiebuilds/44f469bece4d2c5b45daa3031e48232d [12:35:27.0372] bakkot: i agree with that intuition, that for the majority of cases it doesn't matter [12:35:49.0179] bakkot: i've gotten feedback from internal product teams that it very much does matter, to the extent that they're not using native Promises directly because of it [12:37:30.0801] and as you know, i have a soft spot for performance-driven features for minority power user apps :P [14:30:53.0923] shu: unrelated, I'm thinking about proposing `ArrayBuffer.fromBase64` and `ArrayBuffer.prototype.toBase64`. thoughts? [14:32:43.0992] * shu: unrelated, I'm thinking about proposing `ArrayBuffer.fromBase64` and `ArrayBuffer.prototype.toBase64`. thoughts? [14:34:08.0205] bakkot: common, onerous enough to write in userland, not really any room for "innovation" or different ways to design it. ticks all the boxes for me for standardizing, i'm positive on it [14:34:38.0479] it's too bad we'll have competing conventions with TextEncoder/Decoder, but what you gonna do [14:35:22.0994] those don't do base64 though [14:35:24.0345] afaik [14:35:30.0030] and aren't going to because base64 isn't text [14:35:49.0959] i know, i meant more like those are standalone classes, not methods [14:35:52.0619] API surface convention [16:03:14.0894] ah, sure [16:03:20.0574] those are a weird convention though 2021-06-15 [19:33:52.0175] travis-ci.org is shutting down tomorrow? [20:09:20.0219] cc ljharb ^ [20:09:26.0732] that'll be fun for everyone [20:09:58.0896] migrating to github actions will hopefully not be hard, just gotta move the secrets [06:07:17.0249] https://discourse.gnome.org/t/irc-matrix-and-thanks-for-all-the-kicks/6482 GNOME is moving too, eventually... Fun times. [09:22:12.0823] .org is, but .com won’t be 2021-06-16 [20:15:32.0230] looking at https://github.com/mdn/content/pull/6031#pullrequestreview-684402976 [20:17:02.0966] in reviewing MDN patches, I’ve run into cases where MDN article need to describe what happens with calling methods from `Date` objects that aren’t really dates [20:18:55.0899] https://github.com/mdn/content/pull/5983/files#diff-d108cc0257f7f555256331b7caef09755d17dab85df3a402943865e7338b5b26R138 is another case [20:22:35.0431] in the latest review I suggested wording it as *“if the Date object doesn’t represent a valid date”* [20:23:42.0792] but I’m wondering if there’s some better way to describe it — I mean, without resorting to talking about internal slots of the object [21:38:05.0157] congrats to Jamie Kyle on becoming delegate [21:40:29.0862] > <@sideshowbarker:mozilla.org> in the latest review I suggested wording it as *“if the Date object doesn’t represent a valid date”* That's exactly how I'd say it... [21:40:56.0298] Maybe even say "if the Date object doesn't point to a valid instant of time" or something like that... [14:55:26.0473] DerekNonGeneric: Thanks! [15:13:10.0601] knew that rome (tools) recently joining ecma + the sus power bump could only mean one thing; 😉 honestly really excited to see how all next-gen tooling pieces will end up fitting together 😄 [15:26:30.0501] the sus power bump was my dopey mistake and it's like impossible to undo [15:28:58.0479] Thanks! It's been really great lately with the Object.hasOwn() proposal. I'm really impressed by how friendly everything/everyone is today [15:32:54.0594] it's a good proposal! [15:34:05.0299] not that we’re mean with a bad proposal tho, hopefully [15:34:19.0444] Thanks :) I'm hoping to get it to stage 4 soon, it's most of the way there besides getting it unflagged in browsers. Gonna have an update at the next meeting: https://docs.google.com/presentation/d/1UbbNOjNB6XpMGo1GGwl0b8lVsNoCPPPLBByPYc7i5IY/edit?usp=sharing [15:34:42.0447] There's a lot for us to improve about the environment in TC39, but I'm very glad that your experience here has been good. [15:34:49.0662] * not that we’re mean with a bad proposal tho, hopefully :-p [15:35:03.0682] Speaking of which, is there anyone at apple who could tell me what the internal status of the feature is? rdar://problem/78782545 2021-06-17 [21:59:53.0350] Do we have bots in here? [22:12:57.0601] > <@hemanth.hm:matrix.org> Do we have bots in here? Hemanth H.M: yes, there are 3 that i am aware of: - bakkot-logbot - Matrix Traveler (bot) - Server Stats Discoverer (traveler bot) [22:15:44.0777] Hemanth H.M: the latter 2 showed up invited (never heard of them, but ryzokuken might have more info) [22:16:04.0640] * Hemanth H.M: the latter 2 showed up out of the blue (never heard of them, but ryzokuken might have more info) [22:18:25.0957] yeah, the traveler bots are trying to map the entire matrixverse as much as possible [22:19:35.0116] check out https://voyager.t2bot.io/ [09:05:17.0224] FYI: pipeline incubator call is happening now if you'd like to join: https://github.com/tc39/Reflector/issues/378 2021-06-18 2021-06-19 2021-06-20 [14:35:04.0714] I forget: does it still make sense for AddRestrictedFunctionProperties to exist (as opposed to using more conventional means to declare the properties in question)? [15:21:22.0029] AddRestrictedFunctionProperties looks pretty conventional to me? [15:21:57.0261] but it [15:22:42.0154] * it's syntactically conventional, but it's not how properties of intrinsics are usually 'declared' [15:23:20.0310] ah, for built-ins, you mean? [15:23:29.0122] (I've re-found #877 and #1148.) [15:23:46.0198] yeah, built-ins. [15:23:50.0070] seems fine to keep it separate, I think, since those properties are conceptually unlike other properties [15:24:14.0364] what's the conceptual diff? [15:25:15.0810] most other properties exist to be accessed; these exist specifically because they're not supposed to be accessed [15:25:52.0291] ah ok [15:27:13.0416] (#877 and #1148 are about actually normatively removing the properties themselves, afaict, despite the misleading names) [16:05:34.0776] The `emu-note` notes are really helpful and I wish the spec had even more of them [16:06:35.0040] especially the longer ones like the one at https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.reduce [16:07:18.0098] …which I was reading today in the context of trying to resolve the MDN issue at https://github.com/mdn/content/issues/6156 [16:08:26.0809] the wording of that`emu-note` in the spec is more clear than what we have in MDN [16:10:59.0827] among the things that help make it more clear is, using _previousValue_ to refer to the first argument of the _callbackfn_ for `reduce()` (rather than calling it `accumulator`, as MDN currently does 2021-06-21 [04:50:21.0053] https://github.com/mdn/content/pull/6172 could use some review from a domain expert [04:50:51.0405] see my comment at https://github.com/mdn/content/pull/6172 [04:59:07.0389] Why await is a new reserved keyword in module? Is that prepared for TLA or committee though they may add async function in the future so reserved it? [05:20:16.0690] > <@jackworks:matrix.org> Why await is a new reserved keyword in module? Is that prepared for TLA or committee though they may add async function in the future so reserved it? yep. await was reserved to keep the option open to add TLA. Reference: Myles said this in https://tc39er.us/posts/episode-3-myles-borins/ at 40:20 [06:27:52.0985] Thanks [07:06:47.0134] can somebody take a minute to review he (one-line) patch in https://github.com/mdn/content/pull/6191 and confirm whether it’s fully accurate or not? [07:06:59.0620] * can somebody take a minute to review the (one-line) patch in https://github.com/mdn/content/pull/6191 and confirm whether it’s fully accurate or not? [07:11:09.0237] B.3.4 only applies when parsing non-strict code, so it's a Syntax Error in strict code, so "This is no longer the case" is wrong, I think. [07:11:54.0202] But I might be missing something. [07:16:49.0677] Hm, the example is `if (a < b) { function f() {} }`, which isn't B.3.4 syntax (because of the braces) [07:28:33.0927] So I'm thinking that that particular example is syntactically ok in strict mode and non-strict. [07:45:53.0482] * Hm, the example is `if (a < b) { function f() {} }`, which isn't B.3.4 syntax (because of the braces) [07:46:06.0993] * Hm, the example is `if (a < b) { function f() {} }`, which isn't B.3.4 syntax (because of the outer braces) [08:15:08.0472] jmdyck: OK thanks yeah I suspected there was more subtlety to it than what that change captured [08:16:10.0397] don't take my word for it though. 2021-06-22 [00:27:40.0355] the IRC logbot we used has shut down (see https://freenode.logbot.info/_shutdown) and the announcement doesn't make it clear if the operator intends to keep the website up, so I've imported our historical IRC logs as archived by logbot to my matrix logger just in case: https://matrixlogs.bakkot.com/irc-tc39-delegates/2020-02-05#L0 [00:29:42.0982] > <@bakkot:matrix.org> the IRC logbot we used has shut down (see https://freenode.logbot.info/_shutdown) and the announcement doesn't make it clear if the operator intends to keep the website up, so I've imported our historical IRC logs as archived by logbot to my matrix logger just in case: https://matrixlogs.bakkot.com/irc-tc39-delegates/2020-02-05#L0 In need a "you're the real MVP" reaction emote but: you're the real MVP! [00:29:44.0974] > <@bakkot:matrix.org> the IRC logbot we used has shut down (see https://freenode.logbot.info/_shutdown) and the announcement doesn't make it clear if the operator intends to keep the website up, so I've imported our historical IRC logs as archived by logbot to my matrix logger just in case: https://matrixlogs.bakkot.com/irc-tc39-delegates/2020-02-05#L0 * In need a "you're the real MVP" reaction emote but: you're the real MVP! 😀 [00:52:43.0762] bakkot: not the end of the world, but a few debates that took place in #tc39 (general on freenode) a couple of months (or so) ago would be useful for me to review if possible [08:41:31.0900] DerekNonGeneric: #tc39 is up on https://matrixlogs.bakkot.com/irc-tc39/, though you may find the actual logbot easier: https://freenode.logbot.info/tc39 2021-06-23 2021-06-24 [15:02:19.0889] not sure what logs i was reading, but learned of something called tcq (https://tcq.app/), found some docs @ https://github.com/tc39/how-we-work/blob/HEAD/how-to-participate-in-meetings.md and also found the repo (https://github.com/bterlson/tcq), but not too sure how anyone was able to get this thing to build... it uses a really old version of node and all the deps are deprecated? [15:29:34.0550] oh, looks like it was brought up a little while ago in #tc39-delegates:matrix.org -- that project looks to be in pretty bad shape -- almost every api and dependency it uses is currently deprecated... from the `documentdb` store it uses to all the webpack plugins it uses (yikes) [15:36:01.0829] lololol [15:36:03.0502] look [15:36:19.0642] or has a job to do, and with one tiny exception, it does it [15:36:28.0740] * it has a job to do, and with one tiny exception, it does it [15:37:03.0941] i *love* tcq and will defend it to my dying day [15:49:11.0710] well, feeling bad for whoever gets stuck w/ getting that thing in working order (it doesn't seem to be a trivial web app either) [15:49:47.0176] it is not trivial. it's a side project. [15:50:40.0500] on a semi-related note i just learned today that a person I was speaking to assumed the chairs get paid for our work and keeping my laughter in was a real accomplishment [15:50:53.0321] (cuz I wasn't laughing at them, i was laughing at the idea of Ecma paying us) [15:52:07.0582] > <@akirose:matrix.org> it is not trivial. it's a side project. sorry this sounded more brusque than i intended. i just really love tcq. [15:53:26.0598] lol, i feel that about the $$ thing -- going to see what it would take to at least not depend on a version of node that is EOL [15:55:54.0129] ... this is just for personal edification (still haven't even figured out what it does lol) [15:58:48.0883] here, have some screenshots from my intro slides last September [16:03:46.0656] nice, looks kinda like business meeting software [16:18:32.0277] Fwiw it is running on node 14. Needs node 8 to build. [16:19:36.0204] welcome back, boo [16:19:48.0920] wait you're not back yet [16:22:05.0845] No, I'm modding some cabinets but I felt like someone was talking about tcq so I stopped by 😀 [16:28:28.0689] Also fwiw tcq2 built on fluid framework should be out q1 2022 [16:34:59.0959] what about the sheets back-end tho? sheetcq seemed like an interesting idea [16:38:48.0959] ... otherwise looking like `documentdb` (deprecated) -> `@azure/cosmos` (?) https://www.npmjs.com/package/@azure/cosmos [16:48:32.0418] having an unfortunate case of "haven't heart of it here" syndrome (ditto fluid framework >< ) [16:49:23.0502] * having an unfortunate case of "haven't heard of it here" syndrome (ditto fluid framework 😆) 2021-06-25 [17:09:38.0698] double-checked and i might be living under a rock wrt cosmos https://db-engines.com/en/ranking_trend/system/Microsoft+Azure+Cosmos+DB%3BMongoDB [17:11:49.0652] I also happen to think fluid will be massive (biased) but it's still very new [17:43:12.0224] for giving W3C working groups some incentive to migrate away from IRC, it’s clear to need to have replacements for the Zakim IRC bot that we use for managing agendas and speaker queues for meetings [17:43:31.0150] tcq looks pretty great [17:44:15.0900] we’re looking to migrate to Matrix, so I wonder if tcq has some Matrix integration? [17:47:36.0529] W3C groups are accustomed to using an IRC channel for meeting discussions, and so we have another IRC bot, RRSAgent, that we use to capture the IRC log for a meeting, and re-format it in HTML and auto-publish it to the w3.org site [17:51:27.0039] so for giving W3C groups some more incentive to migrate away from IRC, we’re looking to have Matrix channels for each working group, and making it possible for groups to use the Matrix channels for meetings in the same way they use IRC now — so, with some automated RRSAgent-equivalent tool that captures the log from the Matrix room and auto-publishes it to the w3.org site. And then also integration in the Matrix room with some Zakim equivalent for managing the meeting agenda and speaker queue [17:52:47.0383] tcq looks perfect for managing the agenda and queue — so it would be great to have a way to get it integrated with a Matrix room [17:54:21.0338] * for giving W3C working groups some incentive to migrate away from IRC, it’s clear we need to have replacements for the Zakim IRC bot that we use for managing agendas and speaker queues for meetings [00:03:06.0278] There's no matrix integration AFAIK, just the web interface. Do you think that workflow is a problem? [00:32:47.0926] TCQ and Matrix both have no integration with our Notes system today. I like the idea of more integration if it assists automatic capture, or even just threading of the Matrix conversations that relates to a specific agenda item [00:38:37.0882] Integrating matrix, tcq and notes sounds like a great idea either way, we should certainly investigate [00:39:02.0966] sideshowbarker: can you tell us more about the kind of integration w3c gas with IRC? [01:26:28.0735] See https://www.w3.org/2001/12/zakim-irc-bot and https://www.w3.org/2002/03/RRSAgent [01:30:44.0550] > <@annevk:mozilla.org> See https://www.w3.org/2001/12/zakim-irc-bot and https://www.w3.org/2002/03/RRSAgent really cool! we use web interfaces over textual ones, but a bot that puts you on the TCQ queue for example, would be nice. [01:31:03.0801] Not sure how useful people would find it over the website... [01:35:17.0244] it's rather nice to just have IRC open all the time and do things like "q+ to comment on host integration issues" and at the same time see the minutes being taken and be able to correct them using s/.../, though I'm not sure how many W3C groups still operate that way [01:37:11.0046] I think the former can be done by using a bot that integrates directly with TCQ, not sure if the latter could be done that easily... maybe using some sort of Google Docs API? [02:11:15.0364] Yeah, I can see the case for such a TCQ/notes bot to make W3C people comfortable, but it hasn't been a request from TC39 [02:11:42.0521] Maybe because we use real-time chat in a very different way [02:12:14.0400] * Yeah, I can see the case for such a TCQ/notes bot to make W3C people comfortable, but it hasn't been a request from TC39 [02:12:14.0448] I mostly see folks using Google Docs or equivalent for minute taking these days and it's probably better for collaboration as well [02:12:37.0471] The Privacy CG also uses it to manage the queue, but that's kinda bad [02:13:04.0509] They use Google docs for the queue? [02:13:14.0308] Yeah... [02:13:24.0349] Well, we used Google Sheets for that last time, since TCQ was down [02:13:33.0270] we used google docs for the queue when tcq was down. It made me appreciate TCQ even more. [02:13:56.0432] I wonder if hackmd might be slightly better for notes than Google Docs [02:14:21.0895] But the notes bot is worth it as is, more than that delta [02:16:20.0280] google docs has good traceability on history tracking [03:06:19.0588] > <@dehrenberg:igalia.com> I wonder if hackmd might be slightly better for notes than Google Docs I love hedgedoc/hackmd a lot too! [03:38:14.0329] > <@robpalme:matrix.org> google docs has good traceability on history tracking hackmd has something for this too but I can't speak to its quality [06:52:56.0026] people who like/use the IRC layout would love this: https://github.com/matrix-org/matrix-react-sdk/pull/6193 [06:53:26.0922] * people who like/use the IRC layout would like this: https://github.com/matrix-org/matrix-react-sdk/pull/6193 [08:10:34.0947] If hackmd has an API I can make the notes bot output to it, probably [08:13:13.0518] though, while I haven't used hackmd for multiplayer editing, my experience with other web based editors is that they mostly struggle more than gdocs does [08:43:57.0851] OK, I am happy to just take your anecdote and drop this for a while [15:20:32.0947] ``` var bar = {get 10 (){ return 42; }, 10 : 1, 11: 3} print(bar[10]) ``` we have this small test case in which V8 and chakra print 42, but JSC and SM print 1 - we don't see any reason '10' should be different than a string literal as the property name (say, 'foo'), but changing all the keys to non-integer strings makes all the engines agree. Is there a rule exception in the spec for integer keys here, or are we right to believe that printing 1 is the correct behavior? 2021-06-26 [18:07:53.0983] pretty sure 1 is correct; properties are added in source order and later properties clobber earlier ones. there's nothing special about any particular way of writing a key. [22:22:17.0103] shu: as promised: https://github.com/bakkot/proposal-arraybuffer-base64 2021-06-27 [18:08:29.0422] is built-ins/TypedArrayConstructors/internals/DefineOwnProperty/tonumber-value-detached-buffer.js correct? [18:09:15.0956] the spec steps listed in it do not match the spec [18:13:45.0291] oh nvm i see the change is actually in IsValidIntegerIndex [18:15:08.0003] but now a bunch of other tests fail [18:18:04.0983] oh nvm there was a typo [00:46:15.0089] Where does the spec define that a number literal can have a sign? [00:46:33.0866] context is https://github.com/mdn/content/pull/6379 [02:49:07.0723] looking at https://github.com/mdn/content/issues/6382 [02:50:13.0835] > The concat method does not alter this or any of the arrays provided as arguments but instead **returns a shallow copy** that contains copies of the same elements combined from the original arrays. [02:50:25.0199] * > The concat method does not alter this or any of the arrays > provided as arguments but instead **returns a shallow copy** that contains copies of the > same elements combined from the original arrays. [02:50:48.0651] * > The `concat` method does not alter `this` or any of the arrays > provided as arguments but instead **returns a shallow copy** that contains copies of the > same elements combined from the original arrays. [02:51:05.0764] * > The `concat` method does not alter `this` or any of the arrays provided as arguments but instead **returns a shallow copy** that contains copies of the same elements combined from the original arrays. [02:51:39.0144] **returns a shallow copy** is not true, right? [02:51:54.0896] * _returns a shallow copy_ is not true, right? [02:56:45.0289] "returns a shallow copy" is correct [02:56:58.0031] ah OK [02:57:30.0392] so then I am just not understanding what I’m seeing when I try it [02:58:11.0441] if I try the OP’s test case in that issue, it seems like I’m in fact getting a deep copy rather than a shallow one [02:59:23.0737] that is, simply this: ```js k = [1234, 553, 989, 000, [1,4,5]]; z = k.concat() ``` [03:00:13.0593] if I examine `z`, it does seem to have kept that `[1,4,5]` array as a member [03:02:52.0085] ``` z === k // false z[4] === k[4] // true ``` [03:05:36.0919] it hasn't copied `[1,4,5]`, but kept the original 'instance' [03:15:21.0818] OK, I see [03:20:00.0976] > <@sideshowbarker:mozilla.org> Where does the spec define that a number literal can have a sign? NumericLiterals don't have signs: https://262.ecma-international.org/12.0/#sec-literals-numeric-literals + and - are separate unary operations. This can also be seen here: https://astexplorer.net/#/gist/9e46bdbeb90384aa6fae4381538f29da/a8def7d99cb5a1e8f9e848c698cb03b23042cffa [03:20:25.0795] > <@sideshowbarker:mozilla.org> Where does the spec define that a number literal can have a sign? * NumericLiterals don't have signs: https://262.ecma-international.org/12.0/#sec-literals-numeric-literals `+` and `-` are separate unary operations. This can also be seen here: https://astexplorer.net/#/gist/9e46bdbeb90384aa6fae4381538f29da/a8def7d99cb5a1e8f9e848c698cb03b23042cffa [03:22:29.0854] /me looks [03:26:11.0082] Ashley Claymore: so what we have in the examples in MDN at http://localhost:5000/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#numeric_literals is strictly wrong? [03:26:49.0316] oofs make that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#numeric_literals [03:27:53.0111] > Some examples of numeric literals are: > ```js > 0, 117, -345, 123456789123456789n (decimal, base 10) > ``` [03:29:33.0375] And so I should remove that `-345` but add a statement saying something like, *“A number literal can be preceded by a `-` or `+` sign to give it a sign.”* [03:30:29.0724] or *“to assign it a sign”*? [03:32:29.0776] Yep, `-345` is not a technically correct example of a numeric literal [03:33:32.0291] OK — thanks [07:58:45.0287] Hm. I just tried to push a branch of ecma262 to my personal github repo, and got "! [remote rejected] ... (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/build.yml` without `workflow` scope)" [08:00:56.0761] I'm guessing this is related to the merge of #2260 on Friday aft. [08:03:08.0289] ljharb: ? [08:15:01.0237] I was able to push my branch by deleting everything in .github/workflows, but that seems like a bad solution. 2021-06-28 [22:48:56.0764] jmdyck: is your personal repo's master branch up to date? [06:43:06.0781] ljharb: Attempting to push an up-to-date master branch to my personal repo fails similarly. [06:45:39.0651] but updating master *on github* seems to work. [06:46:40.0947] And that seems to allow pushing other branches. [06:55:41.0683] And I've now backed out the workflow deletions from 2445. [06:55:44.0160] Thanks! [08:03:35.0196] hey folks, pattern matching incubator call happening right now in case folks forgot [08:10:49.0292] second update: cancelling, folks didn't show, might've not seen the finalized time since i finalized it kinda late last week. also didn't get a satisfying answer yet to mark's question of who outside the champion group would like to participate [08:10:53.0072] will update the reflector thread [08:26:28.0506] So now I'm getting GitHub workflow email, for both jmdyck/ecma262 and tc39/ecma262. [08:45:14.0023] i think that’s expected; GitHub actions is a bit email-happy [08:45:33.0596] I can mostly see what it's about, but I'm puzzled by one set [08:46:16.0829] where the subject is "[tc39/ecma262] PR run failed: Upload Preview - merchant-center-1546635176041 (80efe41)" [08:46:30.0002] what the heck is "merchant-center-1546635176041" ? [08:47:13.0091] I don't have a branch or PR with that name. [08:51:42.0021] hm - does anyone? [08:52:07.0572] the upload preview task runs on tc39/ecma262 when any pull request finishes the “build preview” step [08:52:22.0330] since you have write access, you might receive an email like that for every PR [08:53:34.0739] Shouldn't the email tell me which PR or branch it's trying to do the upload preview for? [08:54:12.0668] I’d think so, but the way workflow_run tasks work is that that info is all buried in an event payload [08:58:23.0793] Apparently the Upload Preview job is failing because scripts/publish-preview throws "ReferenceError: Missing env var PULL_REQUEST" [09:06:17.0669] But workflows/preview.yml does appear to be setting the PULL_REQUEST env var for the run of publish-preview. [09:06:34.0899] So is the problem that `${{ github.event.workflow_run.pull_requests['0'].number }}` isn't defined? [09:15:34.0436] yes, that's the issue i'm working through right now with it [09:15:51.0068] it was defined when i was testing on my fork, but it seems not to be now, so i need to find another way to convey it [12:31:00.0190] someone wanna update this citation (which currently points to a 404) to something else? https://en.wikipedia.org/wiki/ECMAScript#cite_note-ES2021-9 does ES2021 have a permalink on Ecma's site? should it link to https://www.ecma-international.org/news/ecma-international-approves-new-standards-4/ ? [12:34:32.0210] I'd say the permalink is https://262.ecma-international.org/12.0/ [12:37:45.0891] Seems like the url that's there (http://www.ecma-international.org/ecma-262/12.0/) *should* work, but Ecma hasn't set up the redirect. [12:47:40.0781] I'll do some fixing. [13:11:29.0726] bakkot: did you see https://github.com/lucacasonato/proposal-binary-encoding? [14:02:27.0597] i am getting increasingly dissatisfied with reviewing spec stuff on GH [14:02:40.0576] it really is quite bad for large documents like ours [16:06:36.0300] shu: yeah, https://github.com/bakkot/proposal-arraybuffer-base64/issues/4 [16:13:50.0872] good to see quick engagement 2021-06-29 2021-06-30 [19:24:54.0351] > <@shuyuguo:matrix.org> i am getting increasingly dissatisfied with reviewing spec stuff on GH i keep saying we should use multiple files :P [20:47:54.0493] devsnek: shu free advice: now that y’all have multipage *output* at least, one thing that might help is, setting up a “PR preview” mechanism that has a list of links to the rendered output of each multipage file affected by the change, along with a link that shows HTML diff of the output [20:48:30.0452] that’s what we do for the HTML spec — the source for which is one giant (now 6.0MB) file [20:48:58.0770] sounds difficult [20:49:00.0800] see for example the list in https://github.com/whatwg/html/pull/6812 [20:49:26.0452] devsnek: I think the tooling we used could be ported to use with the ES spec as well [20:49:40.0387] 🤷 [20:49:40.0447] * devsnek: I think the tooling we use could be ported to use with the ES spec as well [20:51:22.0842] https://github.com/tobie/pr-preview is the tool