2021-05-01 2021-05-02 2021-05-03 2021-05-04 2021-05-05 2021-05-06 2021-05-07 2021-05-08 2021-05-09 2021-05-10 2021-05-11 2021-05-12 2021-05-13 2021-05-14 2021-05-15 2021-05-16 2021-05-17 2021-05-18 2021-05-19 [01:58:51.0068] check this out, folks: https://t2bot.io/spacebot/ [01:58:57.0417] cc mpcsh [02:01:03.0813] oh actually jasew is the admin [02:01:24.0045] then I guess only you can kick if off, Jason, but it seems pretty straightforward šŸ˜€ [02:03:05.0182] You may have to walk me through that hah [02:03:28.0849] Why does @ not work on element? [02:03:46.0398] `@ryzokuken` doesn't work? [02:03:49.0040] it works for me... [02:04:08.0190] okay, just start a DM with @spacebot:t2bot.io [02:04:28.0111] you can do it by clicking on that name or `/query @spacebot:t2bot.io` [02:05:11.0886] then you can `!convert +tc39-official:matrix.org` [02:05:41.0632] now I'm not sure if you have access to spaces on whichever client you're on, since it is a beta feature [02:06:03.0713] Thereā€™s no autocomplete on it, @ does nothing for me [02:06:12.0415] but if you are on a browser, it shouldn't be hard. Let me find a nightly/beta element for you so you could actually see what is happening [02:06:26.0532] > <@jasew:matrix.org> Thereā€™s no autocomplete on it, @ does nothing for me that's weird, it should not be happening. [02:06:40.0154] oh wait, you type a little bit after @ [02:06:48.0141] try `@r`? [02:10:02.0000] actually, thinking about it, maybe I'm jumping the gun a little bit because I love the new feature... maybe we should wait until it lands on stable? [02:10:32.0013] @r does nothing [02:14:53.0909] huh, weird [02:15:14.0139] This is on the mobile app [02:15:26.0402] aaah I see my bad [02:15:38.0189] But still element [02:15:58.0484] @ should work in the Element android app, I just checked it [02:16:04.0908] are you on android? [02:16:13.0501] Ios [02:16:25.0025] What is the new feature btw? [02:17:24.0085] Spaces, completely overhaul of communities [02:17:50.0479] basically communities were a much weaker version of, say, whatever slack and discord have right? [02:18:01.0806] but spaces are better, more extensible, cooler, everything [02:18:23.0355] actually since they're still in beta, let's just pass this around for now: https://element.io/blog/spaces-the-next-frontier/ [02:18:41.0978] read it whenever you have a bit of free time! [02:19:38.0955] > Spaces rethink groups in Element and Matrix, and today weā€™re launching public beta testing on Element Web, Desktop and Android (with iOS coming soon!). [02:26:46.0719] Thanks šŸ‘ [08:33:20.0605] Do u know the freenode incident? [08:33:40.0022] https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 [08:45:01.0182] Hey Jack Works a few of us do yeah [08:45:26.0106] So are we going to move to matrix? [08:46:07.0522] My only opinion on potentially switching is we already have a matrix server set up here with many TC39 delegates in it. For me it makes sense to bring people across but I donā€™t think thereā€™s any official decision on that and probably wonā€™t be for a while. [08:47:06.0602] That incident was too sudden šŸ˜Ø [08:51:53.0999] * My only opinion on potentially switching is we already have a matrix server set up here with many TC39 delegates in it. For me it makes sense to bring people across but I donā€™t think thereā€™s any official decision on that and probably wonā€™t be for a while. [10:02:08.0160] It was in the works for a bit, but they slapped everyone with gag orders so it didn't break until it finally did and everything came flooding out... [10:03:05.0794] I personally feel that our best option is to switch to matrix (and worst is to stay on freenode IRC) but that's a call that the chair group will make. [15:34:30.0783] I'm not really sure how to use the channel links here: https://github.com/tc39/Reflector/issues/351#issue-790836237 [15:34:55.0325] they ultimately use the element:// protocol so I just copied the contents into an app.element.io URL and it worked [15:35:12.0640] but it felt like it should have not required my manual intervention [15:42:01.0116] rkirsling: Hmm, I think it didn't require the element:// protocol if you clicked the "continue in browser" links [15:42:28.0505] it's weird; that doesn't appear at first, but then if I hit Back it does [15:42:35.0865] I'll screencap [15:43:47.0289] argh never mind, it just works now [15:47:13.0985] yay (?) [15:47:24.0076] :P [15:47:53.0698] it's fine for me anyway; I was mainly just concerned about others to follow 2021-05-20 [21:35:33.0029] šŸ‘‹ rkirsling [21:36:01.0011] And yeah, matrix.to landing pages are great, they allow you to pop open the native client or use element in the browser [21:36:15.0325] also works well with custom 3rd party clients... [11:05:32.0554] What do you think about this? It's probably worth creating a space for the TC39. https://element.io/blog/spaces-the-next-frontier/ [11:06:15.0939] Oops, I missed the above conversation! [11:08:59.0912] > <@smorimoto:matrix.org> What do you think about this? It's probably worth creating a space for the TC39. > https://element.io/blog/spaces-the-next-frontier/ Yeah, will do it as soon as things get a bit more stable šŸ˜ [11:15:57.0778] Sounds good :) [11:56:39.0829] Iā€™ll take a look at it and I can go through it with ryzokuken when he thinks itā€™s ready. Happy to set it up, I just need to carve out some time to do it 2021-05-21 2021-05-22 2021-05-23 2021-05-24 2021-05-25 [06:33:26.0790] is anyone else super confused that realms are on the agenda for stage 3 [06:35:16.0001] ...because it's been years since they were Stage 2? [06:39:38.0725] no cuz it doesn't appear that they solved the issue brought up last time it was presented [06:47:45.0220] devsnek: What do you see as the important unresolved issues? [06:47:51.0710] I think the slide deck proposes resolutions to everything [06:48:10.0914] call boundary [06:48:17.0655] we frequently have a pattern in TC39 where people raise directly contradictory points and the resolution is, "choose one over the other" [06:48:27.0934] i don't think this proposal solves the criteria set out for it with the call boundary [06:48:39.0706] which criteria are unsolved by the current spec text? [06:49:00.0504] basically all of this https://gc.gy/89655536.png [06:49:42.0270] all of the examples in your explainer break of any of the functions return an object lol [06:50:08.0423] I don't think it's very polite to lol at proposals [06:50:20.0560] these examples can work through the use of membranes or other indirect techniques [06:50:54.0559] i might expect the proposal to include membranes or other indirect techniques in that case [06:51:31.0838] well, membranes are excluded because membranes are more of a pattern that can be taken in many different directions, rather than something which only has one implementation [06:51:43.0915] the champions have provided a membrane library that can be used with the proposal [06:52:07.0724] if objects make the api throw, there needs to be a built-in way to deal with that, is what i mean [06:52:33.0038] if recursive proxy magic is the answer, i'd want an api to create recursive proxy magic [06:56:00.0116] littledan: i think `new Realm({ unsafeSandboxWillBeBrokenAllowObjects: true })` would be fine too [06:56:34.0659] * littledan: i think `new Realm({ unsafeSandboxWillBeBrokenAllowObjects: true })` would be fine too [07:01:49.0667] OK, it's true that this point was raised last time, and I just disagree with it [07:02:15.0305] you can make internal slots work by always using an object with the internal slots that was allocated from the outside [07:03:18.0775] i'm just not sure how i would use this proposal for anything in its current state [07:05:04.0429] and the importValue api seems like a footgun considering it might give you an object or a function which returns an object [07:13:07.0746] littledan: do you have a link to the membrane library that can be used with this proposal? i can't find it from the repo [07:17:06.0957] I really don't understand this concept of a footgun. It feels like everything under the sun gets accused of being a footgun [07:17:29.0616] i would always use evaluate instead of importValue [07:17:31.0226] * i would always use evaluate instead of importValue [07:17:49.0023] cuz with evaluate you can wrap the function to catch its return value [07:19:04.0080] also proxies can't get through the call boundary [07:19:19.0681] do i have to pass lists of object keys as comma separated string values [07:21:16.0564] i'm just trying to imagine how i'd port my cloudflare worker test thing from node vm to this [07:29:20.0921] well, evaluate and importValue both do the exact same function wrapping [07:29:32.0273] it's just that they differ in terms of sync/async and CSP [07:29:42.0009] no i mean i would do `function wrap(f) { return (...args) => { f(...args); } }` [07:29:51.0748] no return value at all [07:30:03.0704] OK, sure [07:30:09.0940] I mean, depends on what you're trying to do [07:30:20.0293] you can also do ,0 of course [07:30:35.0781] i'm not trying to sandbox bad code [07:30:47.0255] i'm just trying to virtualize [07:31:03.0789] well, this Realm proposal is simply less expressive than the Node vm module [07:31:41.0589] it doesn't aim to do everything; it aims to meet the goal of providing some kind of boundary with a little bit of integrity and separation (though not Spectre-level) [07:32:08.0153] sure but in that process i'm not sure how you do anything with it [07:32:21.0726] like one of the the examples in the explainer adds two numbers together [07:32:41.0942] very cool but now what if that function does something more complex [07:33:03.0101] well, I'll find the membrane example for you [07:33:37.0916] also how do membranes work with importValue [07:33:39.0734] as far as i can tell there's no hook point there [07:34:00.0246] no, but there's no hook point with evaluate either... [07:34:16.0878] with evaluate you insert `makeMembrane(v)` or something right? [07:35:15.0079] you can also replace importValue with something which does the I/O and transpiles the module system (this is how all module system virtualization works today anyway) [07:35:25.0590] or, if you're in Node, sure, you can hook it [07:36:03.0032] I think it's quite important that we have a version of evaluating code in Realms which doesn't violate strict CSP policies [07:36:22.0303] i'm just thinking like, import `handleRequest` from a module, pass a complex request object to it, and use the complex return value [07:36:52.0364] curious to see how much abstraction i need for that [07:37:07.0803] I don't understand what you mean or what you're trying to do [07:37:38.0179] mocking a cloudflare worker environment [07:38:16.0875] get an http request from node's http stack, turn it into something the cf worker understands, pass it into the worker code which is inside the realm, get the return value out, turn it into a response node understands [07:39:06.0398] seems like a fairly standard use case for virtualization [07:41:00.0615] with realms api, you could even make a version that runs in the browser [07:41:03.0544] I am a bit lost, can you sketch out how you think this would work in realms? I thought it was pretty straight forward how you get the result out of a realm [07:41:05.0472] * with realms api, you could even make a version that runs in the browser [07:41:27.0907] yeah, basically with the callable boundary realms proposal, you have to serialize all of these operations in terms of primitives [07:42:15.0976] yulia: a cloudflare worker is a module which exports some functions. in the old realm proposal i think it would've looked something like `const { handleRequest } = await realm.import('./cf-worker-cide')` and then `const r = fromFetchResponse(handleRequest(toFetchRequest(node request)))` [07:42:27.0817] * yulia: a cloudflare worker is a module which exports some functions. in the old realm proposal i think it would've looked something like `const { handleRequest } = await realm.import('./cf-worker-cide')` and then `const r = fromFetchResponse(handleRequest(toFetchRequest(node request)))` [07:43:19.0920] right, you can't just share objects synchronously with this callable boundary realm proposal, but you can build a membrane out of it, see https://github.com/caridy/irealm [07:43:35.0614] (and it turns out that this doesn't need symbol as weakmap key) [07:44:23.0443] so i can import irealm and get something more like the old proposal? [07:44:33.0905] with this support library, yes [07:44:38.0970] i wonder what the perf overhead is šŸ˜° [07:45:40.0979] well, that seems like something we can examine during Stage 3? [07:45:51.0821] also there may be room for improvement in Proxy performance [07:45:59.0957] sure... [07:46:05.0375] i would probably just keep using node vm [07:47:00.0475] i'm just not sure why this is better than adding an "allow objects" option [07:47:19.0677] it's fine with me if you keep using node vm [07:47:46.0190] well, the presentation explains the motivation for the callable boundaries approach [07:47:51.0067] or for that matter moving GetWrappedValue to userland [07:47:57.0715] since afaict it doesn't do anything js can't do? [07:48:46.0271] OK, I believe this has already been explained in several threads and presentations that you've read [07:48:54.0991] so I'm not sure what I could say beyond repeating that content [07:49:02.0090] * so I'm not sure what I could say beyond repeating that content [07:49:09.0516] aight [07:49:50.0613] my point is just, if this is unfulfilling to the point of a case like mine not using it, it doesn't seem to match the problem the committee wanted to solve [07:50:40.0393] well, I explained how it can fulfill your use case [07:50:56.0323] sure, but that's a gamble on my part [07:51:14.0619] if the perf can't be solved, i'm stuck being the asshole who blocks stage 4 [07:51:22.0273] because of performance? [07:51:37.0937] I guess I'd be OK with optimizability being a Stage 4 blocker, personally [07:52:17.0247] much of the motivation for this proposal is that it *is* more optimizable than creating whole iframes [07:53:35.0096] rereading some stuff, i didn't see anything explicitly explaining why an option on the constructor is unacceptable [07:53:37.0945] could've missed it [07:55:20.0051] well, the argument against that option would be the same as the argument for callable boundaries in the first place [07:55:29.0743] namely that it's a sort of integrity/boundary footgun [07:56:22.0892] i mean if the alternative is pushing people to use iframes or node vm [07:56:36.0634] lol [07:58:29.0961] well, yeah, I think we will push people to iframes or node vm if we can't agree on callable boundary, since it will make it hard for the proposal to move forward at all [07:58:57.0549] like as one of the maintainers of node vm, i was really hoping to be able to deprecate it [07:59:04.0529] because it is awful [07:59:27.0689] * like as one of the maintainers of node vm, i was really hoping to be able to deprecate it [08:00:15.0512] Node vm is really much more expressive than even the non-callable-boundaries Realm proposal [08:00:28.0144] so it's not clear to me what it would mean to deprecate it [08:01:34.0996] well compartments are supposed to provide host hooks right? [08:01:47.0275] with those two things we could kill it [08:02:51.0891] yes, that is possible. Similarly, sharing objects directly as a Realm constructor flag could also be a follow-on proposal [08:03:40.0043] i mean it sounds like you'd be against that [08:04:00.0335] I'm not personally against it, but I understand the arguments against it [08:04:14.0576] I don't know if we'll ever get consensus on either compartments or shared-object Realms [08:04:31.0815] to go to Stage 3 on this, we have to be OK with the potential future where they never happen [08:22:29.0135] littledan: one more question i guess... what about irealm prevents it from being something we provide in stdlib [08:22:34.0538] is there some weird opinionated choice it makes? [08:24:26.0802] well, maybe it could eventually be in the stdlib; I wouldn't be opposed to that, but I also don't see why we should block on it. [08:25:16.0482] it seems like a reasonable alternative to `throw a TypeError` but šŸ¤·ā€ā™‚ļø [08:35:05.0020] it adds a lot of complexity. I'm OK with starting with something simpler [10:17:20.0243] (i can't post in the delegates channel btw) [10:17:34.0852] why is matrix hijacking the Mac OS's default command-` keyboard shortcut to switch windows? can i turn that off? [10:17:34.0977] Same [10:17:52.0669] * why is matrix hijacking the Mac OS's default command-` keyboard shortcut to switch windows? can i turn that off? [10:18:44.0405] > <@ljharb:matrix.org> why is matrix hijacking the Mac OS's default command-` keyboard shortcut to switch windows? can i turn that off? cmd + tab? [10:18:58.0544] no, that's to switch apps. command-tilde switches *windows* within the same app [10:19:16.0784] ah, I see. Let me see why it's doing that. [10:19:26.0776] how do I join a space? [10:19:33.0223] or spaces or whatever it's called [10:19:44.0821] > <@bitandbang:matrix.org> how do I join a space? https://matrix.to/#/!hmsRHUEXriRovkvcin:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org [10:19:57.0650] spaces are just rooms with special flags set [10:19:57.0984] is there no threading, it's just quoting replies? [10:20:17.0126] yeah, no threading yet, no [10:29:07.0799] can someone give me permission to send messages in the delegates channel [10:30:32.0380] cc @ryz [10:30:38.0628] tab [10:30:40.0317] šŸ˜› [10:30:40.0510] why didn't that autocomplete [10:30:48.0999] you need to hit tab manually [10:30:57.0083] sadly, I don't have access. [10:30:58.0966] cc littledan [10:33:52.0356] > <@shuyuguo:matrix.org> can someone give me permission to send messages in the delegates channel me as well. please and thank you :) [10:46:43.0671] ljharb: we can't hear you [10:46:59.0223] hm, ok thanks [10:47:32.0744] brb [10:49:59.0720] Issue and answer ljharb https://github.com/bocoup/test262-report-issue-tracker/issues/27#issuecomment-840203670 [10:51:42.0785] does anyone know how to make the interface on element.io less noisy, or am I going to download a desktop client? I would like to be able to see more than like five lines of the chat at a time [10:52:18.0991] zoom out? [10:52:21.0148] bakkot: do you mean, the spacing? [10:52:28.0901] ooh, i enabled "irc style layout" and it's much nicer and more compact (@bakkot) [10:52:35.0831] * ooh, i enabled "irc style layout" and it's much nicer and more compact (@bakkot) [10:52:49.0347] ljharb: nice! where's that? [10:53:01.0943] in "advanced" appearance settings [10:53:05.0998] settings > appearance [10:53:10.0893] yulia: yeah, I mean the the whitespace to actual content ratio [10:53:18.0004] @bak [10:53:24.0294] bakkot: the settings [10:53:30.0712] * settings > apprearance [10:54:04.0419] go to this thing [10:54:09.0694] click "show advanced" [10:54:22.0461] sweet, thanks [10:54:24.0580] ^ that [10:54:30.0867] I actually had not managed to find the settings yet [10:54:40.0767] they were under my username, which is not where I was expecting to find them [10:54:45.0235] * settings > appearance [10:55:16.0011] > <@ljharb:matrix.org> ooh, i enabled "irc style layout" and it's much nicer and more compact (@bakkot) Oh wow this is great, thanks for the pointer [11:28:53.0557] shu: i think we are still waiting on editor signoff is that right? [11:32:52.0497] yulia: for TLA spec? [11:33:01.0199] yeah [11:34:10.0030] yes, still needs editor sign off before mergeable [11:34:24.0722] i need to work through your example still [11:34:38.0145] in general the TLA spec is just very difficult to understand :( [11:37:55.0065] yeah :( i am happy to pair on it if it helps [11:38:17.0828] i would like to refactor the module loading spec from loops to recursive calls? i think that would help? [11:38:47.0615] like, eventually, as an editorial change [11:39:36.0925] i'm tempted to not change that stuff because we'd need to review the recursive versions again [11:39:47.0720] i'm also not excited about chasing down all the outdated spec comments in the implementation [11:42:06.0483] fair [11:42:07.0570] same [14:03:46.0045] can someone grant me permission to post in Delegates? [14:04:26.0865] Aki: Robin Ricard Rob Palmer ^ [14:05:14.0126] someone should remove me admin rights [14:05:26.0083] or can I do it to myself? [14:06:08.0953] I removed my own admin rights [15:08:30.0458] > <@rricard:mozilla.org> someone should remove me admin rights this is also how i aspire to live. please, unburden me of responsibility [15:47:48.0323] > <@shuyuguo:matrix.org> this is also how i aspire to live. please, unburden me of responsibility i take POLA as far as I can in every aspect of my life. everyone was shocked i took my new job after i spent _months_ adamantly refusing the promotion [16:52:25.0569] don't get me wrong, i'm not touting my moral character here [16:52:32.0653] i'd take authority without responsibility [16:52:49.0582] * don't get me wrong, i'm not touting my moral character here 2021-05-26 2021-05-27 [17:31:25.0667] https://twitter.com/assortedhackery/status/1397389032519307266 [19:43:58.0998] Is there any particular reason why `function * f () { 0 + yield 1; }` causes `yield` to be interpreted as an identifier? [19:44:27.0255] ā€¦Oh, right, because `+` has tighter precedence. [20:02:34.0038] Wait, but then how is it possible that `function * f () { x = yield 1; }` is valid? `=` is tighter than `yield`. [20:04:03.0227] Ah, I see, thereā€™s an AssignmentExpression : YieldExpression production specifically for this caseā€¦ [21:24:56.0463] jschoi: I think "`=` is tighter than `yield`" is false; they're both produced by `AssignmentExpression` [21:25:08.0972] that is, I would say they have the same precedence, and bind left-to-right [22:18:04.0858] > <@bakkot:matrix.org> jschoi: I think "`=` is tighter than `yield`" is false; they're both produced by `AssignmentExpression` Ah, looking at the actual spec, youā€™re right. I was going off the table in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence#table ā€¦which someone ought to edit and fix, I guess. [23:30:17.0962] that table also lists `??` and `||` as different precedence, which is also wrong [23:58:55.0749] > <@bakkot:matrix.org> that table also lists `??` and `||` as different precedence, which is also wrong Also true. I left this; they might fix it later. https://github.com/mdn/content/issues/5365 [04:38:27.0801] PSA: thereā€™s now a #whatwg:matrix.org room on Matrix (thanks all yā€™all for leading the way and setting a good precedent by having set up here) [05:01:47.0822] > <@sideshowbarker:mozilla.org> PSA: thereā€™s now a #whatwg:matrix.org room on Matrix (thanks all yā€™all for leading the way and setting a good precedent by having set up here) That is so awesome! [05:04:51.0224] > <@usharma:igalia.com> That is so awesome! You can thank jgraham for having taken the initiative on setting it up [05:14:19.0166] sideshowbarker: we had set up a "how to set up a new room" guide earlier but I suppose it's not too discoverable, and just now set up a "new user" guide. Perhaps it would be nice to have a canonical "matrix for standards bodies/committees" guide that we could reference? [05:16:31.0213] > <@usharma:igalia.com> sideshowbarker: we had set up a "how to set up a new room" guide earlier but I suppose it's not too discoverable, and just now set up a "new user" guide. Perhaps it would be nice to have a canonical "matrix for standards bodies/committees" guide that we could reference? Yeah, thatā€™d be nice to have [05:19:03.0618] First things first, I'd move the "setting up a new room" guide to the how-we-work repo we have, and then we can consolidate the documentation with whatever other folks have šŸ˜€ [12:42:14.0435] I'm looking for the bit of static semantics that prevents `while (true) function fn() {}`, I see various early errors for restrictions on labelled statements as the `Statement` of a `WhileStatement` but none for a non-labelled function [12:42:17.0620] any ideas? [12:45:06.0378] rubber duck strategy, I think I found it: https://tc39.es/ecma262/#prod-ExpressionStatement [14:02:05.0787] rickbutton: there's no static semantics which prevents it because it's not allowed by the grammar in the first place [14:02:36.0615] `function fn() {}` is a Declaration, and the RHS of a `while` is a Statement [14:03:40.0389] there's a special annex-B exception which allows FunctionDeclaration as the RHS of an `if`: https://tc39.es/ecma262/#prod-annexB-IfStatement [14:03:44.0369] but it's only for `if`, not `while` [14:06:15.0753] `function fn() {}` could also be a FunctionExpression, which the grammar disallows in a different way, which is I think the way that rickbutton found. [14:36:07.0267] ah I see, thanks bakkot [14:42:40.0764] ljharb: bakkot I find the "irc style layout" a lot more readable after hacking the CSS to do this: ```css .mx_EventTile { margin-top: 10px; } .mx_IRCLayout .mx_EventTile > .mx_SenderProfile { margin-right: 8px; } ``` [14:44:14.0073] I use the Stylish browser extension to make it do that [14:45:39.0564] It just adds some more vertical line height between messages, and some more space after the nicks. But without that, it all looks a bit too cramped for my taste at least. [16:16:39.0411] > Maybe that's what I'm not understanding: What's AssertionError? Justin Ridgewell: it is probably best described in my half-baked (unpresented & unofficial) proposal for it https://github.com/DerekNonGeneric/proposal-assertion-error [16:22:27.0128] Ohhhhhhh [16:22:45.0484] You're talking about things like `assert.equal(actual, expected)` [16:23:03.0594] That's very different than AMP's `ExpectedError` [16:23:36.0646] We're not doing comparisons, "expected" for us is errors that we know will happen in practice and cannot be fixed. [16:23:56.0441] They're not programmer errors, essentially, they're environment errors [16:24:17.0746] We have `ExpectedError` so that we can keep track of them in metrics [16:24:39.0647] If we see an `ExpectedError` spiking in graphs, we know something in the environment has changed [16:24:56.0136] dang, sounds like that could be a separate proposal then šŸ˜… [16:26:05.0399] looking at a bunch of other languages, almost all of them have an `AssertionError` [16:26:49.0768] so, i was under the impression that one would be able to use it for run-time feature detection errors, but it seems like that would be an `ExpectedError` in reality [16:28:04.0557] Yah, that sounds like an `ExpectedError` [16:31:06.0385] cool, good to know -- i am going to see if i find time to polish off the rough edges of that proposal and might ping you later on to have a look if you don't mind [16:31:27.0054] * cool, good to know -- i am going to see if i find time to polish off the rough edges of that proposal and might ping you later on to have a look if you don't mind [16:32:18.0435] there are so many things to consider about it and rn the explainer text is still not up to snuff w/ what i would like it to be 2021-05-28 [18:57:29.0676] I made a thing: https://github.com/shapesecurity/shift-shrink-js [18:57:35.0505] it's a test case reducer for JavaScript programs [18:58:00.0635] (that is, where the test cases themselves are javascript programs) [18:58:24.0937] I imagine some people here might get use out of it [18:58:39.0001] pairs well with the fuzzer: https://github.com/shapesecurity/shift-fuzzer-js [13:53:30.0455] ooh, nice. I have a dream of a Hypothesis-style library in which drawing and shrinking are related and tracked by internal state that is fundamentally an initially-random decision sequence 2021-05-29 [07:22:06.0131] `proposal-error-stacks` is the weirdest proposal ever... i don't understand why it is even still there... it is trying to standardize SystemJS and there is misinformation on the explainer text https://github.com/tc39/proposal-error-stacks [07:26:41.0655] like.. if there is no reference implementation, it should probably not say that there is (right?) [08:19:30.0228] i know this org is only like ~5yrs old, so curating all these oldies and moving them elsewhere probably is not something that has come up (or perhaps it has, but something _should_ be done) [08:19:50.0305] * i know this org only like ~5yrs old, so curating all these oldies and moving elsewhere probably is not something that has come up (or perhaps it has) [08:21:03.0063] * i know this org is only like ~5yrs old, so curating all these oldies and moving them elsewhere probably is not something that has come up (or perhaps it has, but something _should_ be done) [09:43:33.0707] bakkot: is there a process for removing unviable proposals? [09:44:52.0704] ljharb: see the above, maybe you can help demystify [10:11:38.0128] not sure how to interpret the silence, but if someone is able to make sense of this, please do get back to me. Jordan mentioned that the proposal needs to be split up; he also mentioned that it needs accessors (getters) for the `stack` property to function properly.. are we going to collaborate on this? how do we move this forwards? [10:19:34.0485] re silence: Well, it *is* Saturday. Moreover, in the USA, it's a long weekend. [11:48:40.0552] DerekNonGeneric: proposals are removed only if withdrawn by their champion, which this proposal has not been. [14:15:34.0329] good to know, thanks 2021-05-30 2021-05-31 [13:34:45.0871] I am trying to figure out how to resolve https://github.com/mdn/content/issues/5509 [13:36:04.0437] given https://github.com/tc39/ecma262/pull/2125, would it be appropriate for me to remove the big red **Deprecated** warning from the MDN article at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto ? [13:45:59.0090] this is what was referred to as "icky" when we discussed it in plenary in September: https://github.com/tc39/ecma262/pull/2125#issuecomment-695881423 [13:46:25.0001] ptomato: OK, yeah, I read the parts about ā€œickyā€ in that issue discussion [13:46:39.0557] the "Deprecated" warning says "may only be kept for compatibility purposes", that seems accurate to the situation? [13:46:55.0326] (just my opinion, not an official stance) [13:48:14.0933] OK thanks ā€” yeah if `Object.prototype.__proto__` is considered icky, then it seems appropriate for MDN to keep the **Deprecated** warning [13:48:43.0955] (it had just not been clear to me that `Object.prototype.__proto__` was in fact in the icky classification [13:49:32.0727] oh, wait, I'm not sure of the difference between "proto syntax" and "proto accessor", let me check the notes for the plenary [13:49:53.0177] OK [13:52:00.0826] here's the discussion. https://github.com/tc39/notes/blob/master/meetings/2020-09/sept-21.md#move-proto-out-of-annex-b [13:52:26.0710] I'm still not sure after reading it whether that MDN page describes the "icky" item or the "non-icky" item. someone else closer to the discussion should weigh in šŸ˜ƒ [14:31:49.0214] The `__proto__` *accessor* is still "icky". The syntax in object literals is not. [15:00:07.0184] OK thanks ā€” thee MDN article documents the accessor, so Iā€™ll close the MDN issue out with comment that the warning will remain in the article [15:03:35.0314] hmm, I wanted to cite the logs, but looking at https://view.matrix.org/room/%21wbACpffbfxANskIFZq:matrix.org/ now it seems there are no IDs/anchors in the logsā€¦ [15:09:00.0838] sideshowbarker: I am actively working on getting better logs going, so if you wait a day I should have something more linkable for you [15:09:55.0397] ok, thanks, Iā€˜ll wait