2021-05-01 2021-05-02 2021-05-03 2021-05-04 2021-05-05 [12:56:46.0722] x-post from IRC, maybe this crowd knows: I have a question for anyone versed in the intricacies of Ecma bylaws. The ExecCom meeting is tuesday and I canโ€™t attend (in my capacity as TC39 chair). Are ordinary members allowed to attend? Can I send a proxy? 2021-05-06 [00:23:57.0655] Is it just me or is ecma-international.org (and all its subdomains) down? [00:25:16.0120] Such as, e.g., https://262.ecma-international.org/10.0/ [05:21:08.0629] > <@akirose:matrix.org> x-post from IRC, maybe this crowd knows: I have a question for anyone versed in the intricacies of Ecma bylaws. The ExecCom meeting is tuesday and I canโ€™t attend (in my capacity as TC39 chair). Are ordinary members allowed to attend? Can I send a proxy? You are invited to ExeCom as chair, but ordinary members are not [05:21:39.0013] Please send an email to Istvan and Patrick, cc'ing me and Joel, to figure out how to join [05:26:30.0335] > <@sffc:mozilla.org> Is it just me or is ecma-international.org (and all its subdomains) down? They're down, yes. Jordan filed an issue on the Reflector IIRC. [07:29:47.0002] sffc: https://github.com/tc39/Reflector/issues/372#issuecomment-833548595 2021-05-07 2021-05-08 2021-05-09 2021-05-10 2021-05-11 2021-05-12 2021-05-13 [19:36:54.0685] There's an incubator call tomorrow about module fragments. It'd be great to have you there. See more at https://github.com/tc39/Reflector/issues/371 2021-05-14 2021-05-15 2021-05-16 2021-05-17 2021-05-18 2021-05-19 [08:29:12.0648] I ... guess if we ultimately move to matrix it will be very timely: https://blog.bofh.it/debian/id_461 [08:30:05.0780] ah, already posted in irc [08:30:30.0053] * I ... guess if we ultimately move to matrisxit will be very timely: https://blog.bofh.it/debian/id_461 [08:30:35.0068] * I ... guess if we ultimately move to matrix it will be very timely: https://blog.bofh.it/debian/id_461 [15:50:01.0603] :wave: [15:50:12.0973] ๐Ÿ‘‹ [15:50:28.0415] hrmm this webapp doesn't work super fantastically in Safari [15:51:07.0862] really? What kind of issues does it have? [15:51:17.0879] only subtle ones, tbf [15:51:34.0491] well.... that might not be Safari's fault [15:51:41.0486] it was weird that :wave: was treated as plaintext because I didn't hit tab but not sure if that's browser-specific [15:51:57.0088] that's definitely a site feature, not a browser feature [15:52:02.0457] ah okay cool [15:52:19.0053] I'll get used to it :) [15:52:31.0964] I mean, for me, if I type :wave: and *pause*, it pops up a menu of emoji that I can select, but if I just keep going, it doesn't render them [15:52:39.0276] is that what happens for you? [15:53:28.0240] yeah, but after having manually typed the second colon, I felt unsure what button to press, and Enter was the wrong answer. haha [15:54:02.0193] well, I still had the option of choosing something in the menu after the second colon [15:54:16.0227] anyway you can blame Matrix here; I'm not saying you're wrong [15:55:32.0284] I'm mostly glad that my assumption about it being Safari-related was incorrect, hehe [15:57:45.0640] me too! I don't want a repeat of Igalia's old-Jitsi fiasco [15:57:57.0761] (new-Jitsi fixes the Safari issues) 2021-05-20 2021-05-21 2021-05-22 2021-05-23 2021-05-24 2021-05-25 [06:26:37.0218] Sora Morimoto, others: we kickstarted a space for TC39 stuff, join it at https://matrix.to/#/!hmsRHUEXriRovkvcin:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org. [08:44:28.0466] ryzokuken: Cool! [08:44:39.0592] Sora Morimoto: I sent you an invite already [08:48:26.0473] Great thanks [08:50:39.0081] I'm already joined! ๐Ÿ™ƒ [08:55:12.0127] It seems that the bridge channel between freenode can also be added to the space, so I don't think it's a bad idea to add it to the space's room list. [08:56:14.0050] But it also makes sense to list only Matrix stuff. [08:56:16.0020] I don't think we should encourage the use of bridges unless we're sure that they can work well technically. I would also prefer to avoid bridging to Freenode in particular right now, since we all just need to abandon Freenode. [08:56:51.0009] freenode bridge is glitchy at the best of times [08:58:31.0398] > <@dehrenberg:igalia.com> I don't think we should encourage the use of bridges unless we're sure that they can work well technically. I would also prefer to avoid bridging to Freenode in particular right now, since we all just need to abandon Freenode. Indeed, although bridge works well for me at least, it's certainly not that simple. Also, given the timing of the transition, it would be better not to list it! [08:58:51.0294] > <@devsnek:matrix.org> freenode bridge is glitchy at the best of times I love this ๐Ÿ˜ [09:00:25.0061] I will be speaking about Matrix/IRC today [09:20:04.0074] ๐Ÿ‘€ [09:25:49.0482] could I get a volunteer to try entering the call today please. link is in the reflector. [09:27:40.0798] I can do that, if you give me a couple of minutes [09:27:41.0083] all done - Richard Gibson confirmed the call is active [09:27:45.0488] ah ok [09:40:03.0953] Rob Palmer: Can you hear me in the room? [09:40:20.0007] i think rob stepped out for a sec [09:43:46.0123] ok [09:43:48.0239] no probs [09:52:57.0600] can we put https://github.com/tc39/Reflector/issues/367 in the topic [09:53:26.0205] I don't have admin access, rricard could you try that? [09:53:44.0635] I can try, do I have admin access? [09:54:50.0354] looks like I do [09:56:37.0407] oh, looks like I have admin access. Should the set of people with admin access be expanded (or restricted?) [09:56:59.0192] I feel that on this channel, only the chairs/dowagers/moderators should have admin access [09:57:08.0525] I do not need admin access tbh [09:57:11.0254] * I feel that on this channel, only the chairs/dowagers/moderators should have admin access [10:01:33.0656] Am I able to post now? [10:01:54.0940] yes [10:01:56.0969] Yes [10:02:10.0706] ๐ŸŽ‰ [10:18:06.0451] ๐Ÿ˜ƒ [10:18:18.0748] ty [10:19:36.0729] I only see four rooms though? [10:20:22.0375] i see at least 7 rooms with "tc39" in the name, plus TDZ [10:20:30.0645] * i see at least 7 rooms with "tc39" in the name, plus TDZ [10:20:46.0941] i clicked the "+", went to "explore public rooms", and typed "tc39" (i'm in the web client) [10:20:52.0687] * i clicked the "+", went to "explore public rooms", and typed "tc39" (i'm in the web client) [10:21:22.0372] > <@ljharb:matrix.org> i clicked the "+", went to "explore public rooms", and typed "tc39" (i'm in the web client) oh I see. it's really weird because View Community doesn't have them [10:21:54.0490] i think this should help https://matrix.to/#/!hmsRHUEXriRovkvcin:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org [10:22:06.0221] it should prompt you to enable "spaces" [10:22:15.0772] and then you'll see all our associated channels [10:22:44.0134] oh that worked [10:22:57.0194] that didn't prompt me to enable spaces [10:23:12.0002] thanks Rob Palmer! [10:23:14.0915] 10 [10:23:15.0874] @ptomato not directly; but there's another button that takes you to settings to enable it (in the web client, i guess) [10:23:18.0109] * thanks Rob Palmer! [10:23:26.0699] ptomato: that's because you're on igalia's older version ๐Ÿ˜… [10:23:32.0302] > <@pchimento:igalia.com> that didn't prompt me to enable spaces otherwise it's in Settings > Labs [10:23:35.0134] igalia's server does not support spaces yet [10:23:37.0236] * @ptomato not directly; but there's another button that takes you to settings to enable it (in the web client, i guess) [10:23:39.0246] oh i see [10:24:07.0947] oh dear [10:24:58.0774] all these js devs and no one could whip up a tcq clone website in an hour? [10:25:10.0653] (/s) [10:26:53.0664] how many js devs does it take to change a tcq? ๐Ÿ˜› [10:29:41.0950] hope the first in-person meeting we have again is in Tokyo [10:33:16.0277] so what are we using for this meeting, this or irc? [10:34:04.0760] my understanding is this [10:34:09.0537] Is SoftwareChris a delegate? [10:34:23.0471] littledan: yes [10:34:30.0850] and Granville Schmidt ? [10:34:39.0794] littledan: yes [10:34:49.0818] Tierney Cyren: hm, i don't think we have the critical mass yet here to use this [10:35:29.0316] @shu [10:35:32.0433] ack [10:35:38.0608] the autocomplete will kill me [10:35:47.0506] apologies in advance for the many mistakes I'll make [10:35:50.0730] shu: [10:35:53.0674] AAAAA [10:36:08.0011] you get used to it, eventually [10:36:12.0784] i seem to get highlighted either way *shrug* [10:36:16.0009] Is tkopp a registered invited expert? [10:36:19.0193] shu: there's 50 people in the meeting and 40 in this room [10:36:33.0518] wait really? when i expanded the list i saw like 10 [10:36:36.0402] am i pressing the wrong button [10:36:48.0420] yeah I think this is as much critical mass as IRC had [10:36:53.0198] not everyone joined IRC either [10:37:06.0630] I think more people would join this, though. [10:37:11.0544] when i click on "40 People", why do i only see a list of 13 people? [10:37:14.0314] I mean, that was the whole point though, wasn't it? [10:38:00.0123] shu: option at the bottom is like "and 10 others" [10:38:02.0691] and you can click on that [10:38:11.0564] i do not have such a button [10:38:31.0550] shu: Maybe if you can post a screenshot of where you got the 10 from we could help you interpret it? [10:38:36.0418] or we can just ignore this [10:39:16.0985] https://gc.gy/89669355.png [10:39:19.0504] that's scrolled all the way to the bottom in the list [10:39:33.0707] > <@devsnek:matrix.org> https://gc.gy/89669355.png you can send images directly now ๐Ÿ˜› [10:40:07.0330] shu: there's a different set of people on my list [10:40:11.0401] luv 2 decentralize [10:40:29.0321] but but you're all on the same homeserver ๐Ÿ˜ญ [10:40:47.0563] isn't element like 50000 homeservers [10:40:56.0196] glued together [10:41:14.0067] well fair [10:41:21.0297] scaling synapse is... hard [10:41:31.0905] * scaling synapse is... hard [10:42:16.0086] ryan phillipe figured it out easily enough [10:42:29.0611] perfect compression [10:45:30.0812] FYI: I tried using the Jitsi Electron app on MacOS, and the audio didn't work well. Was choppy and every 10 seconds I'd lose 5-ish seconds of audio. The browser Jitsi seems to be working OK. [10:47:39.0169] Aki: I believe rwaldron and jugglinmike are both working on Test262 but they are not present on the meeting. I've been catching just a PR here and there on Test262 and there isn't much to say about it from my very end. [10:50:41.0407] See the link to alternaqueue in https://github.com/tc39/Reflector/issues/367 [10:53:01.0450] shu: lgtm, thanks for the fix [10:53:37.0372] Rob Palmer: trying to open your message but either matrix or element is not cooperating [10:54:18.0953] rbuckton: i received your reponse - so all fixed now [11:01:02.0004] congrats! :tada: [11:01:08.0159] ๐ŸŽ‰ [11:01:17.0381] Congrats rbuckton [11:01:21.0200] pls no excessive animations [11:01:23.0493] this laptop cannot handle [11:01:43.0766] shu: you can disable the confetti/snow/etc animations. [11:01:51.0493] oh good, let me do that [11:01:55.0393] in the settings [11:01:56.0240] Such excite [11:02:37.0907] I see the slides [11:02:46.0440] congrats rbuckton ! Well-earned. [11:03:41.0989] I dunno, you'll have to .then it to find out *rimshot* [11:06:47.0330] who can add new rooms to the space? [11:06:54.0393] Have been busy with TypeScript, but hope to get `static {}` ready for Stage 4 this year too. [11:07:21.0234] rbuckton: test262's what's been blocking chrome from shipping for a month or two now [11:07:31.0288] which one do you want to be added? [11:07:36.0477] > <@shuyuguo:matrix.org> who can add new rooms to the space? ^ [11:07:36.0654] and that is currently blocked on the "await as identifier" issue [11:07:45.0746] ryzokuken: an editors' channel [11:07:48.0487] shu: I plan to look at it this week. [11:07:54.0197] rbuckton: thanks [11:08:51.0191] can you make the room? If I make it, it will be created on the igalia.com server and not matrix.org. I could add that room to the space, then. [11:13:17.0296] well that's what i'm asking [11:13:21.0304] i don't know how to make the room, or if i can :) [11:13:43.0081] i [11:13:45.0524] i'm on it [11:13:50.0695] awesome, thanks! [11:15:27.0041] shu: will this be a publicly listed room? [11:15:46.0541] justingrant: the deadline only applies to stage advancement. [11:19:31.0070] Aki: hm, i think public listed and readonly is fine, but we'd like only editors to be able to send messages [11:19:41.0277] bakkot: opinions on the editor's room? [11:20:25.0199] shu: depends on if we can get michael to join [11:20:30.0227] heh [11:20:33.0530] if not, I'd prefer to do it on libera [11:20:37.0689] okay [11:21:28.0032] Aki: sounds like let's hold off making the room then [11:22:35.0505] Michael Ficarra: poke [11:23:39.0459] Aki: yes? [11:24:49.0283] Michael Ficarra: if we had a room here for tc39 editors would you participate [11:25:06.0632] at least as much as I participated in the IRC room [11:25:15.0013] this is definitely easier for me [11:25:32.0163] oh good [11:25:46.0956] https://snaps.akibraun.com/eori1.gif [11:26:07.0708] good movie! [11:28:11.0338] lol @ "you can't rely on hasOwnProperty being there so let's add another writable property to a built-in 4Head" [11:29:21.0298] yes [11:29:50.0336] `v.constructor.hasOwn(v, p)` [11:30:12.0448] I guess s-urabeis not a delegate or IE, and I accidentally gave them power level 10, and need to reduce it. However, Matrix gives me an error message when I try to do this. Does anyone have ideas? [11:53:56.0834] Should we continue going down the queue? [11:54:08.0264] > <@dehrenberg:igalia.com> I guess s-urabeis not a delegate or IE, and I accidentally gave them power level 10, and need to reduce it. However, Matrix gives me an error message when I try to do this. Does anyone have ideas? you can't change the power level of anyone who has the same power level as you; someone with a higher power level has to do it, which it looks like Aki did [11:54:46.0461] Aki: it might be nice to move through the queue; there's a number of responses to waldemar's points [11:54:54.0699] > <@mpcsh_:matrix.org> you can't change the power level of anyone who has the same power level as you; someone with a higher power level has to do it, which it looks like Aki did I don't understand why that came up, since I'm an admin and s-urabe was 10. Maybe some other UI issue [11:55:35.0852] oh! weird. [11:55:47.0774] littledan: whenever that happens to me (a couple times now) i quit and relaunch [12:02:21.0454] i think TCQ in the future should always have a Sheets backend [12:02:39.0872] all applications should [12:02:44.0318] sheets is the ideal database [12:02:44.0510] yeah [12:03:07.0345] time to launch a new cloud computing company that scales excel better [12:03:13.0974] "cloud is someone else's spreadsheet" [12:03:24.0920] it's NoSQL! [12:03:35.0912] damn, time is a flat circle [12:03:57.0928] i would've just named the space vlookup [12:04:06.0951] isn't SQLite technically a SQL-compatible spreadsheet? [12:06:42.0402] how can i disable the behavior where i have to grant people permission to message me? [12:10:59.0932] Hm, I'm not sure you can do that, since that would mean that you'd automatically join every room you're invited to... [12:11:21.0685] Each DM is just a 1:1 room ๐Ÿ˜… [12:14:12.0680] They can send the first message immediately and you'll receive it once you accept [12:26:49.0413] > <@shuyuguo:matrix.org> time to launch a new cloud computing company that scales excel better Airtable's done this pretty well :P [12:27:07.0538] also Notion to some extent? I've not used it enough to actually know. [12:43:37.0986] oh cool, i've never used either [12:44:10.0350] for some reason i thought airtable was an email thing [13:09:23.0445] shu: do you have any schedule constraints around Resizable Array Buffer? [13:12:01.0889] no [13:13:15.0407] shu: would you be willing to step in at the end of today if we end up with 45 min? [13:13:20.0644] * shu: would you be willing to step in at the end of today if we end up with 45 min? [13:14:11.0079] sure [13:14:18.0568] cool [13:28:24.0053] it'd be nice if the sheeTCQ listed the current agenda item name [13:29:09.0673] bold should represent the ongoing item [13:31:02.0676] agreed [13:37:23.0005] that's the queue item. i mean the _agenda_ item [13:37:38.0811] oh, I look at hackmd [13:37:49.0428] that's what i did. but regular TCQ has that info up top also, so it'd be nice as a reference [13:37:53.0469] * that's what i did. but regular TCQ has that info up top also, so it'd be nice as a reference [13:37:54.0088] but yea agreed [13:38:45.0039] well it is a collaborative document, I think it can be added [13:38:59.0589] do ittttt [13:39:59.0751] it has been added [13:40:19.0546] how is :gavel: not an emoji [13:40:50.0584] ๐Ÿ”จ [13:51:12.0580] I'm not going to be able to make it to the ResizableArrayBuffer presentation, but I'm +1 on Stage 3 for the proposal [13:51:29.0548] great work finding a compromise way forward here [13:55:31.0350] has anyone proposed using a Set here [13:55:44.0451] that seems like the thing you actually want [13:56:34.0036] also I would like to hear from implementors about cost of arrays vs iterators, if possible [13:59:28.0324] not a fan of iterators [13:59:36.0670] purely from implementation perspective [14:00:01.0870] too many intermediate values, don't like thinking about edge cases with iterator close [14:00:09.0335] ljharb: just to be clear -- its not just tied to this proposal [14:00:20.0599] right, i get that it would impact everything [14:00:25.0891] we will require it for all proposals that implement similar behavior going forward [14:00:41.0202] but i mean, i don't think this or any proposal should be held back until that separate proposal advances [14:01:13.0288] hm, to word it differently: We would like to introduce this invariant [14:01:21.0625] ie, even if there's impls right now that ship partial datasets, i can already observe that without this proposal, so i don't think this proposal should be affected [14:01:37.0164] my understanding is that this proposal doesn't incur any addition in the CLDR data included [14:01:54.0590] right - i think that's a great invariant to introduce! but it doesn't seem reasonable to me to hold back a stage 2 proposal from stage 3 due to an invariant that doesn't exist yet [14:01:59.0375] right, from my reading of the spec that doesn't change [14:02:10.0936] (especially considering this proposal doesn't seem to in any way worsen the thing the invariant is designed to prevent) [14:02:32.0657] do we have anything like this already in the language? specifically about listing apis available in the browser in this specific way? [14:02:35.0927] If implementors don't want iterators, and the point of iterators was to make things easier for implementors, it sounds like we should not do iterators [14:03:04.0007] wait, it's not at all my understanding iterators was to make things _easier_ for implementers [14:03:11.0175] because from my understanding -- the privacy review found that while we are not concerned with this specific proposal, we are concerned with the tendency [14:03:15.0161] yulia: not that i know of; it'd be tricky i think to word it since 402 doesn't precisely mandate what's shipped [14:03:33.0825] yeah, that was my understanding as well [14:03:36.0452] but something like a consistency invariant seems like it has precedent [14:03:47.0472] ie, "if a locale is accepted anywhere, it must appear everywhere locales do" etc [14:04:06.0027] right [14:04:32.0105] I don't think we are disagreeing here, but it is a hard requirement for us going forward [14:08:35.0265] if by "going forward" you mean "all other proposals besides this one" then we agree :-D [14:08:44.0324] shu: it certainly sounded like it the point of iterators was to conserve memory or something [14:08:52.0771] not because of any design question [14:08:56.0443] waaat [14:09:02.0802] for this specific topic, I mean [14:09:07.0340] a protocol that produces a new object _every iteration_ [14:09:08.0188] ooooh [14:09:21.0533] i thought you were talking about why we introduced iterators to begin with [14:09:26.0448] oh, no, sorry [14:09:30.0883] for this specific proposal [14:09:39.0526] right, but that's not about ease, that's at the expense of ease [14:09:44.0561] yeah, in this case the idea was that we might not have the entire list on memory... [14:09:45.0603] the idea of using iterators instead of arrays, for this question, would be to save memory in implementations [14:09:49.0440] ljharb: this proposal isn't yet at stage 3, and this is a pre-implementation concern [14:10:25.0271] to be faiiir though i think this is not so complicated [14:10:29.0720] and i believe this was already agreed [14:10:51.0497] bakkot: i don't really have anything against that; iterators are a known quantity of complexity, and could arguably reduce peak memory use [14:12:42.0987] yulia: totally agree; but i think it would be unfortunate to block it based on an invariant we don't even have consensus on yet, when the "problem" the invariant is solving already exists [14:13:21.0954] The invariant is for future proposals [14:13:30.0472] this is a requirement for this one [14:13:59.0633] yulia: ok so that's the part we disagree on. i think it's unreasonable to make it a requirement for this one since this one doesn't worsen the fingerprintability of existing implementations. [14:14:30.0756] if i understood mozilla's review on fingerprinting, it depends on this -- that all users get the same dataset [14:15:06.0903] i'm pretty sure i could build a 100% compliant polyfill for the current proposal, it'd just be large and annoying to write, which means it's not providing any new capabilities (i'd be happy to do that as an exercise if it changes anything) [14:15:26.0812] * i'm pretty sure i could build a 100% compliant polyfill for the current proposal, it'd just be large and annoying to write, which means it's not providing any new capabilities (i'd be happy to do that as an exercise if it changes anything) [14:15:55.0815] im not sure what the goal there would be? [14:16:46.0292] to demonstrate that the proposal doesn't make "the problems the invariant is preventing" any worse, and thus, the invariant needn't block the proposal [14:17:23.0976] ok, let me order things a bit [14:17:37.0301] 1) we are not convinced by the proposals and this requires a list of usecases that make it clear that this is worthwhile [14:18:02.0924] 2) if committee chooses to go forward with this proposal, it is a requirement from mozilla that we do not ship enumeration apis that ship partial data sets [14:18:16.0984] this is non-negotiable, so i am not sure why we are having this discussion [14:18:26.0551] the first obv makes anything else moot; but i don't understand how the second is logically consistent [14:19:08.0308] if 1 is not satisfied, we do not have such an api in the language where this was a risk [14:19:14.0615] i'm not understanding how it being "an enumeration API" makes anything less safe/ideal than the current needed approach of "hardcoding a list and brute-forcing" [14:19:35.0455] we have that api already - i can make a hardcoded list of every possible Intl value, and brute-force a list of all the supported things. the only difference is that i have to keep up with *new* possible values over time; with an enumeration API i wouldn't. [14:19:54.0903] hard coding a list is shipping the full data set, or am i missing something? [14:19:56.0576] * we have that api already - i can make a hardcoded list of every possible Intl value, and brute-force a list of all the supported things. the only difference is that i have to keep up with *new* possible values over time; with an enumeration API i wouldn't. [14:20:03.0222] I don't think I understand "partial data sets" here. [14:20:04.0288] me, the user would ship it [14:20:14.0368] the concern as i understand it is about fingerprinting [14:20:32.0970] i can ship the full dataset in my JS, in order to fingerprint the partial data set some browser/engine is already shipping [14:21:21.0690] the enumeration api allows legit use cases (pickers, validation, etc) to be much easier and cheaper, without making fingerprinting use cases any more possible (just, also easier) [14:21:58.0140] does the enumeration api ship the same data set to all users? [14:22:15.0848] the enumeration API doesn't ship a data set - it exposes the data set that's already shipped, that all the other Intl APIs already use (and thus, already expose in a one-off fashion) [14:22:33.0513] * the enumeration API doesn't ship a data set - it exposes the data set that's already shipped, that all the other Intl APIs already use (and thus, already expose in a one-off fashion) [14:22:39.0289] ok, does it *expose* the same data set? [14:22:53.0255] yes [14:22:59.0553] ok. then what are we arguing about? [14:23:10.0376] hm [14:23:16.0295] aside from terminology [14:23:25.0337] ok so by "not a partial dataset" you mean, it has to correspond to the same data set all the other Intl apis use? [14:23:29.0337] * ok so by "not a partial dataset" you mean, it has to correspond to the same data set all the other Intl apis use? [14:23:30.0192] yes [14:23:40.0573] @ljha [14:23:42.0015] oh lol ok then sorry for the confusion, seems like we violently agree [14:23:49.0204] very good! [14:24:07.0232] better than disagreeing [14:24:23.0829] ljharb: I believe anti-fingerprinting techniques are easier to implement against a single test style API than an enumeration style API [14:24:29.0374] if the spec *allows* some locale data to be supported somewhere, but not show up in the enumeration - or vice versa - that sounds like a spec bug to me (and i'd be shocked if an implementation knowingly shipped that) [14:40:18.0469] does anyone has the saved queue? [14:44:54.0665] I am confused, I thought well-known symbols were pre-populated into the symbol.for registry [14:45:31.0167] maybe I am wrong [14:45:44.0889] I think the last bullet point is just poorly worded. Shouldn't dwell on it. [14:47:11.0842] Robin Ricard: it's a tab on the spreadsheet [14:47:24.0028] yep it was ported [14:47:28.0890] well-known symbols are not in the registry, but are the same across all realms [14:47:29.0542] apparently I am wrong, well-known symbols are not put into the global symbol registry [14:47:30.0992] thanks [14:48:33.0217] I don't understand, couldn't you register a symbol after putting it in the weak map/set? [14:48:54.0674] > <@michaelficarra:matrix.org> I don't understand, couldn't you register a symbol after putting it in the weak map/set? no [14:48:59.0813] i thought not, that'd be real bad [14:49:02.0452] you can't register a symbol, you get a symbol out of the registry by a string [14:49:19.0626] p sure a non-registry symbol can't ever === a registry symbol [14:49:35.0297] ljharb: agree [14:49:45.0849] that's an important distinction [14:49:47.0613] bakkot: uhh aren't they? Symbol.for('iterator') [14:50:02.0047] `Symbol.iterator !== Symbol.for('iterator')` [14:50:21.0074] oh wow I did not know that [14:50:26.0111] it's also not `Symbol.for(Symbol.iterator.description)` or `Symbol.for(Symbol.iterator.toString())` [14:53:07.0525] for some reason, I also thought that well-known symbols were already in the global symbol registry [14:54:10.0266] shu: `const wm = new WeakMap(); var o = {}; wm.add(o, () => o); o = null` makes `o` uncollectible also, until `wm` is, no? [14:54:28.0638] * shu: `const wm = new WeakMap(); var o = {}; wm.add(o, () => o); o = null` makes `o` uncollectible also, until `wm` is, no? [14:55:33.0129] the last time this was raised, Mark presented what was to me a novel mental model in which registered symbols are functionally a distinct type from other symbols, and leaned on that model in support of excluding them as WeakMap keys [14:55:54.0199] that sounds interesting but i don't think that's how any users think about symbols [14:55:59.0084] I agree [14:56:05.0739] > <@gibson042:matrix.org> the last time this was raised, Mark presented what was to me a novel mental model in which registered symbols are functionally a distinct type from other symbols, and leaned on that model in support of excluding them as WeakMap keys * that sounds interesting but i don't think that's how any users think about symbols [14:56:30.0932] and I share your original objection, but I think my position has since weakened more than yours [14:56:45.0655] but it still makes me uncomfortable to allow some symbols but not others [14:57:51.0381] Justin Ridgewell: also "is it a well-known symbol" which is much more complex logic [14:58:39.0827] * < [14:58:40.0973] * [14:58:43.0345] I'd just be willing to make that compromise, because well-known and registered symbols aren't the ones I really care about [14:58:57.0985] For reference, my code sample was `if (Symbol.keyFor(s)) { useMap(s) } else { useWeakMap(s) }` [14:59:12.0388] i absolutely care about keying on well-known symbols, but ofc i write polyfills [14:59:22.0288] Meaning that the fallback case will have the same uncollectable behavior, because I have to insert it into a Map [15:01:21.0061] I don't even know if there is a robust way to identify a value as a well-known symbol [15:02:21.0487] if you assume caching of all relevant methods/objects, the equivalent of `function isWKS(s) { return typeof s === 'symbol' && !Symbol.keyFor(s) && Reflect.ownKeys(Symbol).filter(x => typeof x === 'symbol').some(x => x === s); }`, which is onerous and gross [15:02:33.0893] * if you assume caching of all relevant methods/objects, the equivalent of `function isWKS(s) { return Reflect.ownKeys(Symbol).filter(x => typeof x === 'symbol').some(x => x === s); }`, which is onerous and gross [15:02:55.0967] * if you assume caching of all relevant methods/objects, the equivalent of `function isWKS(s) { return typeof s === 'symbol' && !Symbol.keyFor(s) && Reflect.ownKeys(Symbol).filter(x => typeof x === 'symbol').some(x => x === s); }`, which is onerous and gross [15:04:05.0191] ljharb: no, it shouldn't [15:04:24.0864] ljharb: weakmaps are ephemerons, so the closure that captures `o` would only be marked as live if its key, `o` is also marked as live. it's an implication [15:04:31.0535] ah ok, gotcha [15:04:42.0602] we could add a `isWellKnown` getter to symbols [15:04:57.0252] `.canGoInWeakStuff` [15:05:18.0252] `!Symbol.keyFor(s)` isn't right because `Symbol.keyFor(Symbol.for('')) === ''` [15:05:41.0562] have to check `== null` [15:05:44.0536] oh right, `typeof Symbol.keyFor(s) !== 'string'` or something [15:06:23.0278] I was concerned about Symbol properties corresponding to well-known symbols being configurable or writable, but that is thankfully not the case [15:07:22.0917] so at least first-run code _can_ reliably detect, the process just sucks [15:07:31.0668] ljharb: old IE used to have trouble cleaning up objects with mutual references like `var a = {}; var b = { a: a }; a.b = b;` [15:07:50.0257] did they not have a garbage collector o_O [15:08:33.0296] beats me, this was like IE6/7 days [15:09:26.0370] yulia: Rob Palmer We had a constraint for Daniel and Caio in the agenda, but I cleared it out with them already, they are now able to attend it at 1PM [15:09:43.0115] perfect - thank you [15:09:53.0327] Ok, that was part of the confusion, thanks for clarifying! [15:16:35.0354] Richard Gibson: you can always just check if `(new WeakSet).add(k)` throws. pretend we're python. [15:38:51.0911] that's actually what was on my mind, if this goes through then it _becomes_ the best way of detecting cross-realm symbols [15:43:01.0811] and i suspect it will become idiomatic for APIs to only accept a subset of the three kinds of symbols [16:12:01.0738] I'm not certain I've ever seen Symbol.for in the wild [16:12:20.0528] so that is probably not a huge loss [16:12:47.0487] though also I think I Have never seen an API which takes as an argument an arbitrary symbol, so [16:25:28.0353] likewise for me, and that's why I think I can live with the compromise even though I don't like the added spec and practitioner complexity of differentiating symbols that can be WM keys vs. those that can't [16:31:41.0843] but I do recognize that well-known symbols and registered symbols _are_ special in practice because they can enter an object graph even after becoming unreachable (having been revived by creation of a new realm) 2021-05-26 [22:09:10.0741] node uses Symbol.for symbols for custom inspection protocols, for custom promisification protocols, and all the browser polyfills for those use them as well [22:09:25.0223] but certainly that's not an API that takes a symbol directly [09:41:41.0325] yulia: ping [09:42:15.0609] hi! [09:42:18.0776] am i late? [09:42:48.0010] yulia: fully embodying the stereotype of "not understanding your own code", apparently the current spec text for SharedArrayBuffer.grow already prohibits spurious failures [09:42:55.0934] yulia: so no spec text change is needed, but i'll reword notes [09:42:59.0147] i'll also follow up with waldemar [09:43:16.0990] no, not late for anything, just saying my presentation was wrong yesterday and the spec is actually right [09:43:18.0275] oh hhhh noooo [09:43:27.0579] ill have to heck what we implement [09:43:33.0138] ok [09:43:34.0680] cool [09:43:58.0523] implementation is: loop your compare_exchange_weak, or use compare_exchange_strong [09:44:12.0529] (v8 loops a compare_exchange_weak, but probably should use a compare_exchange_strong?) [09:47:51.0781] arright, good to know -- ill loop back with jan and the others [10:05:45.0865] i like "SheeTCQ" but "alternaQ" is pretty good too [10:06:22.0622] do we add replies by inserting a row below the topic? [10:06:31.0905] yes [10:06:37.0175] okay [10:07:52.0386] replies should be offset, immediately under the topic - like an HTML details element [10:09:17.0643] also, we have a 60min slot of free time after Shu's item that is happening now. feel free to propose items to use the time. [10:10:14.0954] Is Peter presenting, or just talking? [10:10:21.0183] I only see his initials. [10:10:24.0627] talking [10:10:30.0575] there are no slides this hour [10:10:58.0591] Rob Palmer: i'd like to add a 5 min item clarifying something with resizable buffers [10:11:09.0062] ok [10:30:45.0195] bot seems like it's reasonable on top of things today, which is nice [10:32:20.0417] Robin Ricard: is your hand raised on purpose [10:32:45.0776] nope [10:33:01.0306] my ui was not showing as raised [10:33:20.0628] gone now! [10:33:22.0419] something similar happened yesterday [10:33:32.0414] please disregard any hand raising from me [10:33:43.0955] will use the queue if I need to speak [10:33:53.0787] haha k [10:34:02.0403] yea I clicked on it twice [10:38:59.0046] A lightweight open discussion topic could be explicit support for consensus: https://github.com/tc39/Reflector/issues/360 . [10:39:13.0006] what do people think? I would briefly present [10:40:05.0841] if we have a little extra time this meeting, can we get an official ruling on where the new IRC-channel-like-thing is? [10:40:13.0377] unless we've officially announced matrix [10:40:33.0855] > <@bakkot:matrix.org> if we have a little extra time this meeting, can we get an official ruling on where the new IRC-channel-like-thing is? Yes, this is probably the most important thing [10:40:37.0884] freenode now seems decidedly dead, with the staff taking over channels for mentioning other networks [10:40:55.0621] talk of a nail in the coffin... [10:40:56.0845] lol is that really happening [10:41:01.0118] that is cartoon villainy [10:41:07.0632] also changing their policy on hate speech to only go so far as UK law requires [10:41:10.0407] yeah: https://twitter.com/GrapheneOS/status/1397401277072646145 [10:41:11.0142] over 700 channels, btw [10:42:16.0357] huh, why do they bother rather than just shutting it down? [10:42:40.0296] โ€ฆ โ€ฆ โ€ฆ profitโ€ฆ somehowโ€ฆ? [10:43:09.0157] how delusional could you be... [10:43:16.0571] they claim an overeager regex, and that the actual policy is that channels that have "moved" and *also* prevented users from chatting are violating policy [10:43:29.0170] but either way, preventing legit redirects is super hostile on its own [10:47:20.0609] sadly IRC has a _reputation_ [10:49:46.0810] i hear "what is IRC" far more than i hear any other reaction to it, tbh [10:49:48.0167] bridges to IRC just don't work reliably at all. This is why we recommend against it. [10:51:34.0424] here is the matrix dl script: https://github.com/rubo77/matrix-dl from the chat [10:58:14.0904] Justin Ridgewell: same, this allows me to uninstall my IRC client [11:00:19.0431] FWIW there's a total of one non-voiced person in this room [11:00:46.0476] how do you see that? [11:01:31.0039] well, you can click on each one and look at their permission level (10 or more is delegate) [11:01:45.0969] I have read the whole list and did the exercise of voicing everyone who was left out, and so I just re-scanned it and recognize all the names [11:01:54.0833] ah, didn't think of a manual approach [11:02:06.0826] it's all very scriptable too [11:07:19.0002] Maybe we should be ##tc39 on Libera, to make it clear that it's a community channel rather than an official committee one? [11:08:56.0103] I don't think libera does the # vs ## thing [11:09:16.0065] they don't [11:09:30.0233] libera's trying to shed the ## thing when possible [11:10:05.0097] oh, I see. They have ## but encourage communities to use # https://libera.chat/policies#channels [11:10:39.0883] shu: would you like to do incubation chartering next? [11:12:23.0072] @yulia Agree [11:12:50.0463] just to confirm, for the notes, we had consensus to move to matrix? [11:13:04.0458] I think so? [11:13:50.0456] yes, but let's please explicitly note that we'll be very subtle about announcing that on freenode [11:13:51.0973] yes [11:14:26.0859] > <@dehrenberg:igalia.com> A lightweight open discussion topic could be explicit support for consensus: https://github.com/tc39/Reflector/issues/360 . would people be open to discussing this item? [11:19:21.0446] When's the next meeting? June, right? [11:19:34.0745] Or July? [11:19:43.0519] shorter days do not help me at all [11:19:53.0903] I would rather longer days, longer meetings, and less frequent meetings [11:19:58.0912] july [11:20:05.0912] same, shorter days are not going to help [11:20:20.0253] tabatkins: 2021-07-13 to 2021-07-16, tokyo [11:20:45.0941] would fewer days help you? [11:20:55.0539] like a 1/3 pattern, at the current frequency, for example [11:21:11.0787] it is really about the agenda to be honest [11:21:31.0829] well, does the shorter agenda help at all? [11:21:32.0309] If "short meetings" means "an hour", I'd be fine with that happening regularly. But 3+ hours essentially takes up my entire day, because I have to reschedule meetings anyway. [11:21:37.0104] i would say: if we had something like "single proposal" meetings, where we meet for one hour, that would reduce preperation time [11:21:43.0400] Yup. [11:22:00.0426] yep, its more about the prep time [11:22:12.0035] in 2020 we did 6 per year. in 2021 we have 8 per year. should we switch to 7 per year? [11:22:23.0179] so, if we could have large proposals have a dedicated day, that might be interesting [11:22:38.0855] > <@yulia:mozilla.org> i would say: if we had something like "single proposal" meetings, where we meet for one hour, that would reduce preperation time What if we had these, say, every week or two for an hour (cancelled when there is no agenda), in addition to the 4x per year longer meetings? [11:22:50.0485] yeah that would be great [11:22:57.0310] then i only prep one proposal [11:23:18.0256] we could have that as a pre-determined cadence and people could sign up with larger proposals [11:25:09.0631] if we make sure that the agendas are available well in advance, then this could help people know when to be present to block [11:25:14.0433] So my big issue is that after a decent meeting, I want to not think about these topics for a week or two. Then I need to have proposals ready almost two weeks before the next meeting. That gives me a ~1 week window between meetings that I can actually do work on a topic. [11:26:25.0314] a thought I had was about grouping stage advancements together, for example doing all stage 0->1 proposals in the same day. And doing the same for S1->2 etc. My guess is that it would make it easier to budget time & energy? [11:26:29.0696] doesn't csswg have weekly calls? [11:26:56.0822] davethegr8: that sounds like a promising direction [11:26:56.0964] yes, i like single proposal slots [11:27:02.0567] it's worked well for incubator calls fwiw [11:27:14.0029] incubator calls started trying to have more than a single slot, and that just didn't work at all [11:27:48.0840] also note that weeks with plenary are weeks where we skip editor call and various other side meetings [11:28:21.0604] littledan: Yes, we have a weekly telcon, 1hr each. This morning's meeting, for example, used this agenda https://lists.w3.org/Archives/Public/www-style/2021May/0014.html [11:28:31.0307] (We got thru six of the items this time, that's not unusual.) [11:29:30.0570] And then we have 3-4 longer meetings per year (which includes the big cross-W3C TPAC meeting) [11:30:49.0925] single proposal slots would be a nightmare for me, fwiw [11:31:06.0310] means i would have to be thinking about tc39 scheduling _constantly_, instead of just every few weeks [11:31:58.0867] I think we'd need to have weekly meetings if we wanted to give big gaps like this [11:32:16.0618] tabatkins: Maybe you could share some experience with how vacations work for csswg? [11:32:54.0408] We schedule our long meetings a year in advance, which lets people either feed their vacations into the time planning, or plan their vacations around it, pretty well. [11:32:56.0435] that queue item was me [11:33:00.0256] couldn't find my mic, sorry [11:33:05.0197] don't know what happened to my name... [11:33:11.0723] Our weekly calls are short and common, so if someone has to send regrets, we just bump their topic to the next week, it's fine. [11:33:31.0815] I wonder why this doesn't work for bakkot and waldemarh [11:33:42.0009] +100 to ptomato 's comment [11:35:35.0362] I disagree with Mark about blocking being the most important thing, but I do think that people who are interested in particular topics need to pay attention to every single proposal before it can advance, and that's hard to do when advancement can happen at any time instead of just every two months [11:36:26.0363] I like the incubator calls, because I can participate when I will be particularly useful but I don't need to be extremely vigilant about the topics I care about because I know that advancement won't happen in those meetings [11:36:36.0250] I just disagree that blocking is an effective way to make change; I haven't found it to be this way in the past. Working with champions really seems to be the main option. [11:36:57.0430] > <@bakkot:matrix.org> I like the incubator calls, because I can participate when I will be particularly useful but I don't need to be extremely vigilant about the topics I care about because I know that advancement won't happen in those meetings I would be ok with more incubator meetings and fewer plenary [11:37:08.0769] Again, I am not talking about blocking, just about ensuring that I have the chance to review carefully before advancement can happen [11:37:12.0503] because ditto to what bakkot said [11:37:31.0302] maybe we can just cancel our remaining 2-day meetings this year and see what happens? [11:37:37.0731] * maybe we can just cancel our remaining 2-day meetings this year and see what happens? [11:38:40.0202] and encourage more use of incubator calls to make up for it [11:39:36.0511] anyway I agree with bakkot [11:39:56.0172] i don't think "blocking" is the most important thing, but i do agree with mark that "preventing a mistake we likely have to live with forever" should be our highest priority, which ofc has to be balanced with "making the language better" [11:40:21.0733] * i don't think "blocking" is the most important thing, but i do agree with mark that "preventing a mistake we likely have to live with forever" should be our highest priority, which ofc has to be balanced with "making the language better" [11:40:32.0140] Shorter days could help people from inconvenient time zones unload their day and participate more [11:41:07.0942] Valuing advancing improvements vs avoiding mistakes is an example of different value judgements. In TC39, we work in an environment of different delegates disagreeing on priorities, and finding common ground. [11:44:37.0713] shu: I mean the point of my company joining is so we can check every single proposal [11:44:51.0226] it's not necessarily that I personally need to do it, but someone from my company does [11:44:53.0087] It's a good thing if some delegates are more focused on avoiding mistakes while others are more focused on advancing things. It helps give good overall balance. I think it would be more of a problem if we all agreed that one was more important than the other. [11:46:10.0048] waldemarh: i saw you had a response to my topic, shall we discuss here? [11:48:11.0266] Where is this issue? [11:48:23.0655] My concern was inclusiveness, where we seem to be dismissive of attendees' desire to attend all plenary meetings. [11:48:41.0084] I found it [11:49:18.0149] > <@rbuckton:matrix.org> Where is this issue? https://github.com/tc39/incubator-agendas/issues/17 I assume [11:49:31.0705] My thinking is primarily still related to the invariants proposal (and possibly broader) -- we have individuals protecting aspects of the language but we don't have those written down where arguably they should be -- either in the spec or elsewhere. Ideally we would have a strong enough transfer of knowledge that a given topic will be covered. It sounds like we probably don't disagree there and they are orthogonal concerns? [11:49:51.0351] IIRC, myself, danielrosenwasser and tabatkins volunteered as champions for pipeline? [11:50:04.0240] How far ahead are our meetings scheduled? The next meeting isn't in tc39/agendas, which is where I always check to see timing on upcoming meetings. [11:50:09.0533] Yes. [11:50:16.0341] Maybe some of the technical issues can be addressed via such means, but it's still an inclusiveness problem. [11:50:36.0986] And I apologize, I've been trying to write an intro email to restart conversation about pipeline and plan for a future meeting proposal, but have been having trouble summoning the psychic energy to complete it. [11:50:42.0506] tabatkins: usually a year at a time; check the current agenda at the bottom (every agenda has the upcoming meetings at the bottom) [11:50:51.0922] waldemarh: personally, I would like to move to quarterly meetings, the issue there is that we might hit a wall with the amount of topics that are proposed [11:50:53.0571] * tabatkins: usually a year at a time; check the current agenda at the bottom (every agenda has the upcoming meetings at the bottom) [11:51:00.0253] but, maybe we could handle the extra pressure with incubator calls [11:51:21.0755] I think the majority of proposals that try to advance and fail due to design issues, are usually early stage proposals [11:51:27.0908] I added myself and danielrosenwasser to the list for pipeline [11:51:33.0760] (haven't checked, thats just my feeling) [11:51:36.0610] ljharb: Ah thanks, I might submit a PR to add them to the main page with filled in info [11:51:39.0353] * (haven't checked, thats just my feeling) [11:52:01.0521] > <@tabatkins:matrix.org> ljharb: Ah thanks, I might submit a PR to add them to the main page with filled in info if we do that, let's update the agenda template to link to the main page section instead of duplicating the info :-) [11:53:06.0782] sounds good [11:53:07.0905] bakkot: that's fine! that's why your company doesn't employ just a single person [11:53:25.0320] > <@dehrenberg:igalia.com> would people be open to discussing this item? I think this item would fit in 7 minutes [11:53:32.0199] bakkot: to be clear i'm not saying member companies shouldn't feel the pressure to have a check on every proposal. the big members definitely have that expectation [11:53:34.0572] but if people don't want to discuss it, that's OK [11:53:53.0457] bakkot: i was calling out specific delegates feeling that pressure personally [11:53:56.0577] > <@shuyuguo:matrix.org> bakkot: that's fine! that's why your company doesn't employ just a single person in most companies, it's hard to convince them to budget time for more than a single person to do standards work [11:54:32.0037] ljharb: i interpret that as the company saying they don't want to spend the capital to care about every single thing that happens in committee [11:54:33.0895] ljharb: it can also be hard to find qualified individuals [11:55:20.0844] shu: that's not really an argument that's inclusive to companies without massive revenue/budgets/workforce [11:55:35.0499] then take that up with ecma about asking for dues and making members companies? [11:55:52.0621] like the standards body is not a design focus group, i keep saying this [11:56:04.0769] it is to get interoperability on features everyone can live with [11:56:08.0633] i'm not sure what you mean. ecma's dues are scaled by revenue [11:56:29.0175] right, but "everyone" includes "companies who can't afford to pay for multiple people to do standards work" [11:56:50.0152] the importance of someone's input doesn't lessen because there's a smaller budget behind them. [11:57:20.0193] i don't see us having a productive discussion about this, so i'm going to lunch, sorry [12:17:51.0545] PSA if you haven't already, you can join the TC39 beta "space" here https://matrix.to/#/!hmsRHUEXriRovkvcin:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org [12:27:13.0635] I think we should focus on openness to input/feedback/changes/contributions, including scaling this further to non-delegates. I'm not convinced we need to do more work to improve openness to blocking. [12:38:46.0068] in before Mark: https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 [12:41:11.0944] not that it is unique to ECMAScript or even to language design: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/ [12:42:00.0088] yeah, look at how DNS has clearly fallen off the complexity cliff. Nobody uses it anymore. [12:46:19.0010] the argument is that approximately nobody gets it _right_, because new features interact with old ones [12:46:46.0497] I think we have a stronger testing story which avoids that particular problem [12:47:11.0125] it's clearly harder to make a JS implementation now than in ES1 days. I don't think that means we should disband committee work. Everyone agrees that new features should have strong motivation to justify their complexity. [12:58:47.0331] Did we formally drop IRC? I seem to have been removed from the delegates channel and can't rejoin [13:04:13.0816] davethegr8: we set it to forward to the #tc39 irc channel. there won't be any formal announcement on freenode itself tho, due to the toxic conditions there. [13:04:33.0709] * davethegr8: we set it to forward to the #tc39 irc channel. there won't be any formal announcement on freenode itself tho, due to the toxic conditions there. [13:06:18.0784] ljharb: fwiw I am almost certain that we could just mention it without issue as long as it doesn't go in the title [13:06:26.0779] and I think we should do that, at least once our docs are updated [13:07:00.0821] yeah, we can mention it, just not include it in the topic [13:07:13.0598] probably so [13:07:31.0796] there's so few non-delegates tho that i'll probably just PM them [13:08:10.0304] waldemarh: https://w3c.github.io/webappsec-csp/ [13:12:48.0218] Michael Ficarra: Thank you [13:15:28.0361] Personally, I'm not persuaded that either of these two constraints posited by Domenic about the module map makes sense [13:15:59.0947] i don't understand this one... what was the rationale? [13:16:11.0437] * Personally, I'm not persuaded that either of these two constraints posited by Domenic about the module map makes sense [13:16:43.0832] yulia: i can try to explain later [13:16:46.0999] yulia: when we're discussing [13:17:01.0294] ok, thanks [13:18:08.0066] That will be great, since I don't understand the rationale either. [13:18:51.0617] what the heck. [13:19:05.0321] [13:19:25.0134] Thanks Aki it worked. [13:23:29.0878] Was there pushback from TAG? [13:24:43.0209] https://github.com/caridy/irealm [13:25:08.0055] Justin Ridgewell: yeah i was wondering about that, my reading of the TAG review is that one member of TAG (plinss) that one of his use cases might not be met [13:25:25.0387] i didn't read the TAG review as "the TAG pushed back" [13:26:14.0375] I agree that the ergonomics in this proposal are quite bad, and it seems tailored to a very very narrow usage [13:27:42.0089] > <@shuyuguo:matrix.org> i didn't read the TAG review as "the TAG pushed back" I didn't read that either, but it sounds like offline conversations led to this analysis [13:31:26.0518] question: are SABs and atomics actually seeing much use? [13:31:40.0567] even via libraries? [13:31:50.0920] unfortunately no, spectre had a lot to do with it [13:31:57.0469] but the feedback i hear is that it's just too hard [13:31:59.0384] futexes be hard [13:32:13.0644] thus what i'm trying to do with concurrent js with higher level abstraction [13:32:38.0017] their uptake was limited by COOP/COEP, so I'm not sure if current usage numbers are so meaningful. https://web.dev/cross-origin-isolation-guide/ [13:33:14.0339] that's a relatively recent development, if I understand right; they shipped for a while first [13:33:47.0691] ljharb: I don't understand the point you're making. it's true that some people need to know what's on the web and what's in all JS, but many people don't, and I don't see why limiting the amount of stuff in realms helps the first group of people [13:34:02.0810] * ljharb: I don't understand the point you're making. it's true that some people need to know what's on the web and what's in all JS, but many people don't, and I don't see why limiting the amount of stuff in realms helps the first group of people [13:34:17.0059] it doesn't, which is why it's totally reasonable for the defaults to be "whatever's in the env" [13:34:37.0157] but that's not an argument to prohibit some opt in way to get a subset [13:35:05.0053] I don't understand the argument for being able to opt in to that; say more? [13:35:15.0318] like if you just aren't using the extra things, seems fine? [13:35:40.0928] Looks like SAB is running at about .5% of Chrome page loads https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructed [13:35:43.0378] I have a hard time imagining having the extra things would break many people at all, and it seems ok for us to say that those people just have to manually delete all those items [13:35:56.0518] bakkot: i want to run code, that uses transitive deps i don't author, and ensure that it works in all my target envs [13:36:08.0242] littledan: sweet, thanks [13:36:19.0426] ljharb: I don't understand how this helps with that goal [13:36:23.0076] Can someone throw my name on the queue to respond [13:36:31.0258] btw I guess Shu is on the globals topic, and hasn't yet started his queue item about module loading yet, right? [13:36:36.0898] (Computer less) [13:36:37.0745] it's possible but highly impractical to try to mutate the current env's environment (or a Realm's env) so that it mimics the intersection i rely on [13:36:41.0863] correct [13:36:46.0996] * it's possible but highly impractical to try to mutate the current env's environment (or a Realm's env) so that it mimics the intersection i rely on [13:37:15.0083] Justin Ridgewell: added [13:37:50.0510] bakkot: SAB is at the sweet spot of "too commonly used to unship, not used enough to actually be considered fully successful" [13:38:04.0617] ljharb: I don't understand how opting in to the subset helps with your goal [13:38:07.0881] unless you mean just for running tests? [13:38:19.0316] and if it's just for running tests, manually deleting seems like the way to go for sure [13:38:32.0553] that, but also for running it in a realm in prod, assuming that's performant enough [13:39:00.0045] that way i don't have to rely on my tests hitting every code path, i can get a loud failure, even if something would normally work in one env, to tell me that it won't work in another [13:39:01.0205] for doing it in prod, I do yet not understand how opting in to the subset helps [13:39:41.0021] we don't seem to be sticking to the queue very well though [13:39:42.0890] it means that prod code that doesn't work in all envs i need, won't ever work, increasing the chance it gets caught and fixed [13:40:15.0607] hmm. [13:40:34.0105] ok, I understand that motivation but it really does not seem to me sufficiently important to warrant language support, I guess. [13:41:57.0128] I hope we have time to discuss the module system issues today. [13:44:13.0866] I mentioned [Exposed=*] before [13:44:25.0269] that would be reviewing webidl for exposed tags such as https://w3c.github.io/FileAPI/#dfn-Blob [13:44:31.0556] ill raise this in a moment [13:48:33.0928] so, the work that would need to happen is we would need to review this for truly universal apis [13:48:34.0464] how can anything be "not a stage 3 blocker"? [13:49:08.0675] Michael Ficarra: if you're asking for an additional feature, you can push it through in a subsequent proposal [13:49:12.0872] Can we advance the queue? [13:49:21.0807] We've had the same few people speak for a while [13:49:32.0881] There are nine entries queued [13:49:44.0035] ^ Rob Palmer [13:54:12.0138] What Mark is describing is not the current version of this proposal. I thought we agreed that what Leo presented was acceptable. [13:54:32.0963] yeah i'm not sure what we're being asked [13:54:39.0156] what mark is saying is kind of radical [13:54:47.0052] based on how [Exposed] works, the things exposed in Realms may or may not be available in other places. If we go with the [Exposed=*] spelling, then it would indeed be a subset [13:54:49.0838] for ecma262 to "version pin" other upstream specs [13:54:54.0004] yeah, I disagree with Mark's proposal [13:55:01.0650] I would like to talk about modules, though [13:55:16.0334] same, i regret responding to jordan [13:55:49.0308] [exposed=*] would be a stretch goal, it would be a lot of work. we can also just use the existing piping [13:56:11.0818] I imagine it being more like [Exposed=Window,Worker,Realm] [13:56:16.0477] ๐Ÿค”Actually I found it's hard to track those Web IDL tags [13:56:20.0409] yeah, that would be fine [13:56:23.0062] I don't see a strong need for * at this point; being explicit isn't bad [13:56:30.0204] agreed [13:57:02.0127] There is no way to intermingle these object graphs; this is what I don't understand about Shu's comment (EDIT: I guess he's talking about the callable boundaries motivation at all) [13:57:08.0614] E.g. I don't know how to get the full list of [Serializable] (for structured cloning) from Web spec [13:58:08.0191] * There is no way to intermingle these object graphs; this is what I don't understand about Shu's comment (EDIT: I guess he's talking about the callable boundaries motivation at all) [13:59:17.0097] ah i understand the concern.. hm [13:59:27.0314] Jack Works: i've just been searching, ill ask anne if he has tips [13:59:55.0953] i need to think more about the module map [14:00:03.0798] so should we have a new API for loading but not executing the module map to resolve the module map concerns? [14:00:25.0586] e.g. `import.cache(specifier)` [14:00:57.0345] yeah that is true what is being said now [14:01:11.0448] cool [14:02:05.0019] oh sorry Jack Works i was responding to the conversation not your question [14:02:12.0233] I don't know the answer there [14:02:45.0520] though, exposing how the module loader is working is something I have been thinking [14:02:49.0113] unrelated from realms though, for another thing [14:03:02.0023] lol [14:03:11.0329] * unrelated from realms though, for another thing [14:03:53.0152] that's a thing in the compartment API. we should give developers more controls about how modules loaded in that proposal IMO [14:04:09.0469] littledan: realms being able to do IO by default would be real bad, I think, since the thing people want is "can run untrusted code" [14:04:21.0990] I think the fact that modules are cached is basically irrelevant to that consideration [14:04:37.0766] unless you have the restriction that you can only load things previously cached by the outer realm [14:04:52.0729] that's one such proposed path forward [14:05:46.0497] If Realms exist in process, there's already a timing vulnerability with Spectre [14:06:00.0724] Justin Ridgewell: right, but that's not relevant unless they can exfiltrate data [14:06:12.0580] I don't see why we need to prevent module loading (which is significant) to prevent another timing vuln [14:07:24.0175] an irrelevant issue, in the compartment proposal it seems it is allowing to have a separate module map (that controlled by the developer) _within_ the same realm. [14:07:45.0893] how do you think about that, or it's my misunderstanding on the compartment [14:07:51.0007] maybe "cached by the outer realm or explicitly passed as the argument to `importValue`"? [14:08:00.0437] i think switching static imports does change the behavior if you modify global state? [14:08:30.0372] though it is less unintuitive than this [14:08:37.0628] I agree with Mark that we would have to accept this timing side channel if we allow Realms to import modules from the network. I just don't think it would be a problem. [14:09:24.0687] it is important is to acknowledge that this IS a timing channel but it is somehow okay [14:09:30.0493] isn't this timing issue something that wasn't an issue for TLA? [14:09:36.0388] not that timing is an implementation's problem [14:09:47.0665] like, in any module graph on the web, you already can't know for sure if previous graphs have populated the cache with the modules you're importing [14:09:53.0196] * like, in any module graph on the web, you already can't know for sure if previous graphs have populated the cache with the modules you're importing [14:09:56.0199] ljharb: TLA doesn't entice people to try to run untrusted code [14:10:45.0517] right but why does it matter if the untrusted code can see that the cache was populated first, versus not? [14:11:32.0807] is the concern that untrusted code could learn something about what things are imported by the trusted code that ran before it? [14:12:41.0616] (and also, isn't anything imported from another domain "untrusted", which was the entire motivation around json modules and import assertions?) [14:14:20.0637] * (and also, isn't anything imported from another domain "untrusted", which was the entire motivation around json modules and import assertions?) [14:15:51.0091] ljharb: the cache matters as much as you care about timing? [14:16:28.0518] ljharb: as for the entire motivation for the json modules and import assertions, that was about accidentally callign the wrong parser as well as executing stuff you don't think should execute [14:16:40.0262] i guess to me, that's at an earlier stage in the pipeline [14:16:55.0746] "untrusted code" in the sense that you want to execute it, you just don't trust it to do 100% safe things [14:17:01.0128] the json module thing was "let's not execute it at all" [14:17:36.0176] alrighty, i hear the distinction [14:18:07.0092] I don't think we need primitives which are ArrayBuffers; I think you ultimately want something more like transferring ownership or sharing the data blocks, as a separate feature [14:21:03.0984] https://github.com/tc39/proposal-realms/issues/22 [14:21:22.0704] stage 3 question, how to handle annex b [14:30:43.0691] we should've always required escaping - in character classes [14:30:50.0030] or at least when we introduced the u flag [14:43:09.0802] There is in fact only 26^2 flags [14:43:57.0584] Well, the "flag + zwnj + (regionalchars+)" version that lets you do subregion indicators is theoretically infinite [14:44:19.0864] sorry, zwj [14:45:17.0376] there's other flags that are not country/region flags [14:45:25.0623] chequered flag [14:45:29.0691] white flag, pirate flag [14:45:34.0842] sure but they're in the same "infinite" category as any other combination emoji [14:45:40.0544] the flagness isn't relevant [14:48:40.0323] it definitely might mask a bug but it's not something the language should stop you from doing [14:49:21.0594] it might mask a bug in the sense that any operation can mask a bug? [14:49:52.0579] also compilers generate these kinds of things and they want them to behave like sets [14:50:45.0616] yeah [14:50:52.0626] also maybe you are just being careful, who knows [14:50:58.0326] that is a thing for linters to deal with [14:51:19.0538] just doesn't seem legit to me to lint [14:51:49.0816] people lint for no-unnecessary-escapes, it's the same sort of thing [14:51:53.0466] also, I kind of like waldemar's idea about, if you say `v` you have to also say `u` [14:53:27.0212] on that note, I'm thinking about how the grammar flags are going to work, whether the v flag (in source text) should enable both v and u grammar flags or whether they should be kept separate [14:53:28.0570] i'm not particularly convinced by designing for "putting user input into a dynamic regex" given that we still haven't advanced escaping, but this may be reasonable for a "just lint against it" kind of thing [14:53:32.0993] I'm leaning toward the former [14:54:20.0330] * i'm not particularly convinced by designing for "putting user input into a dynamic regex" given that we still haven't advanced escaping, but this may be reasonable for a "just lint against it" kind of thing [14:54:34.0045] we haven't advanced escaping because we're fighting about how to do it, not because we think it's a bad thing to do [14:54:58.0125] as far as I understood, anyway [14:55:40.0454] i mean, somewhat. but if we're willing to let years go by with users having to escape in userland, then they could surely also validate against characters-not-in-the-set in userland too, if that's what we went with [14:56:18.0265] ljharb: again, these are not just constructed in user programs, they are also constructed by compilers outputting JavaScript [14:56:25.0293] which may not have access to these data sets [14:56:27.0583] such validation would presumably be trivial with `/^\p{RGI_EMOJI}*$/.test(input)` as well [14:56:45.0386] while that's fair, i'm also not convinced that's something that's reasonable to optimize for [14:57:04.0822] * while that's fair, i'm also not convinced that's something that's reasonable to optimize for [14:57:14.0137] we consider the compile-to-JS use case all the time, since at least I started attending committee [14:57:21.0492] consider, sure [14:59:33.0660] > if we're willing to let years go by with users having to escape in userland, then they could surely also validate against characters-not-in-the-set in userland too, if that's what we went with that's _way_ more work than escaping. more importantly, it's a different kind of work: escaping is a feature the language does not provide you which would be helpful for constructing regexes, whereas this would be that the language has an artificial limitation you're working around. [15:01:10.0385] I think this V => U question can be resolved during stage 2 [15:01:33.0750] yeah it's not a blocking concern [15:07:39.0038] https://dev.to/hemanth/updates-from-83rd-meeting-of-tc39-1d67 :) [15:10:00.0999] Just to be clear, it's "virtual" tokyo, right? [15:10:11.0440] it is indeed [15:10:22.0238] all right, combination phew+damb [15:10:51.0708] goddamit, "damb" has sunk into my fingers now, it's happening automatically [15:11:14.0550] https://snaps.akiro.se/mia9w.jpg [15:12:16.0249] yeah, I would not want to be trying to book a flight to Tokyo for mid-July right now [15:14:54.0163] oh yeah the olympics exists 2021-05-27 [07:47:25.0207] I suppose someone needs to keep the reflector link updated and stuff? 2021-05-28 2021-05-29 2021-05-30 2021-05-31