| 05:09 | <ljharb> | node uses Symbol.for symbols for custom inspection protocols, for custom promisification protocols, and all the browser polyfills for those use them as well |
| 05:09 | <ljharb> | but certainly that's not an API that takes a symbol directly |
| 16:41 | <shu> | yulia: ping |
| 16:42 | <yulia> | hi! |
| 16:42 | <yulia> | am i late? |
| 16:42 | <shu> | yulia: fully embodying the stereotype of "not understanding your own code", apparently the current spec text for SharedArrayBuffer.grow already prohibits spurious failures |
| 16:42 | <shu> | yulia: so no spec text change is needed, but i'll reword notes |
| 16:42 | <shu> | i'll also follow up with waldemar |
| 16:43 | <shu> | no, not late for anything, just saying my presentation was wrong yesterday and the spec is actually right |
| 16:43 | <yulia> | oh hhhh noooo |
| 16:43 | <yulia> | ill have to heck what we implement |
| 16:43 | <yulia> | ok |
| 16:43 | <yulia> | cool |
| 16:43 | <shu> | implementation is: loop your compare_exchange_weak, or use compare_exchange_strong |
| 16:44 | <shu> | (v8 loops a compare_exchange_weak, but probably should use a compare_exchange_strong?) |
| 16:47 | <yulia> | arright, good to know -- ill loop back with jan and the others |
| 17:05 | <ljharb> | i like "SheeTCQ" but "alternaQ" is pretty good too |
| 17:06 | <Michael Ficarra> | do we add replies by inserting a row below the topic? |
| 17:06 | <Aki> | yes |
| 17:06 | <Michael Ficarra> | okay |
| 17:07 | <Rob Palmer> | replies should be offset, immediately under the topic - like an HTML details element |
| 17:09 | <Rob Palmer> | 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. |
| 17:10 | <Justin Ridgewell> | Is Peter presenting, or just talking? |
| 17:10 | <Justin Ridgewell> | I only see his initials. |
| 17:10 | <Aki> | talking |
| 17:10 | <Aki> | there are no slides this hour |
| 17:10 | <shu> | Rob Palmer: i'd like to add a 5 min item clarifying something with resizable buffers |
| 17:11 | <Rob Palmer> | ok |
| 17:30 | <bakkot> | bot seems like it's reasonable on top of things today, which is nice |
| 17:32 | <Aki> | Robin Ricard: is your hand raised on purpose |
| 17:32 | <Robin Ricard> | nope |
| 17:33 | <Robin Ricard> | my ui was not showing as raised |
| 17:33 | <Aki> | gone now! |
| 17:33 | <Robin Ricard> | something similar happened yesterday |
| 17:33 | <Robin Ricard> | please disregard any hand raising from me |
| 17:33 | <Robin Ricard> | will use the queue if I need to speak |
| 17:33 | <Aki> | haha k |
| 17:34 | <Robin Ricard> | yea I clicked on it twice |
| 17:38 | <littledan> | A lightweight open discussion topic could be explicit support for consensus: https://github.com/tc39/Reflector/issues/360 . |
| 17:39 | <littledan> | what do people think? I would briefly present |
| 17:40 | <bakkot> | if we have a little extra time this meeting, can we get an official ruling on where the new IRC-channel-like-thing is? |
| 17:40 | <bakkot> | unless we've officially announced matrix |
| 17:40 | <littledan> | if we have a little extra time this meeting, can we get an official ruling on where the new IRC-channel-like-thing is? |
| 17:40 | <bakkot> | freenode now seems decidedly dead, with the staff taking over channels for mentioning other networks |
| 17:40 | <ryzokuken> | talk of a nail in the coffin... |
| 17:40 | <shu> | lol is that really happening |
| 17:41 | <shu> | that is cartoon villainy |
| 17:41 | <Aki> | also changing their policy on hate speech to only go so far as UK law requires |
| 17:41 | <bakkot> | yeah: https://twitter.com/GrapheneOS/status/1397401277072646145 |
| 17:41 | <ryzokuken> | over 700 channels, btw |
| 17:42 | <littledan> | huh, why do they bother rather than just shutting it down? |
| 17:42 | <Aki> | … … … profit… somehow…? |
| 17:43 | <ryzokuken> | how delusional could you be... |
| 17:43 | <ljharb> | 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 |
| 17:43 | <ljharb> | but either way, preventing legit redirects is super hostile on its own |
| 17:47 | <Aki> | sadly IRC has a reputation |
| 17:49 | <ljharb> | i hear "what is IRC" far more than i hear any other reaction to it, tbh |
| 17:49 | <littledan> | bridges to IRC just don't work reliably at all. This is why we recommend against it. |
| 17:51 | <yulia> | here is the matrix dl script: https://github.com/rubo77/matrix-dl from the chat |
| 17:58 | <Michael Ficarra> | Justin Ridgewell: same, this allows me to uninstall my IRC client |
| 18:00 | <littledan> | FWIW there's a total of one non-voiced person in this room |
| 18:00 | <ljharb> | how do you see that? |
| 18:01 | <littledan> | well, you can click on each one and look at their permission level (10 or more is delegate) |
| 18:01 | <littledan> | 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 |
| 18:01 | <ljharb> | ah, didn't think of a manual approach |
| 18:02 | <littledan> | it's all very scriptable too |
| 18:07 | <littledan> | Maybe we should be ##tc39 on Libera, to make it clear that it's a community channel rather than an official committee one? |
| 18:08 | <ryzokuken> | I don't think libera does the # vs ## thing |
| 18:09 | <ljharb> | they don't |
| 18:09 | <ljharb> | libera's trying to shed the ## thing when possible |
| 18:10 | <littledan> | oh, I see. They have ## but encourage communities to use # https://libera.chat/policies#channels |
| 18:10 | <Rob Palmer> | shu: would you like to do incubation chartering next? |
| 18:12 | <Justin Ridgewell> | @yulia Agree |
| 18:12 | <bakkot> | just to confirm, for the notes, we had consensus to move to matrix? |
| 18:13 | <ryzokuken> | I think so? |
| 18:13 | <ljharb> | yes, but let's please explicitly note that we'll be very subtle about announcing that on freenode |
| 18:13 | <Rob Palmer> | yes |
| 18:14 | <littledan> | A lightweight open discussion topic could be explicit support for consensus: https://github.com/tc39/Reflector/issues/360 . |
| 18:19 | <tabatkins> | When's the next meeting? June, right? |
| 18:19 | <tabatkins> | Or July? |
| 18:19 | <Michael Ficarra> | shorter days do not help me at all |
| 18:19 | <Michael Ficarra> | I would rather longer days, longer meetings, and less frequent meetings |
| 18:19 | <yulia> | july |
| 18:20 | <yulia> | same, shorter days are not going to help |
| 18:20 | <Michael Ficarra> | tabatkins: 2021-07-13 to 2021-07-16, tokyo |
| 18:20 | <littledan> | would fewer days help you? |
| 18:20 | <littledan> | like a 1/3 pattern, at the current frequency, for example |
| 18:21 | <yulia> | it is really about the agenda to be honest |
| 18:21 | <littledan> | well, does the shorter agenda help at all? |
| 18:21 | <tabatkins> | 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. |
| 18:21 | <yulia> | i would say: if we had something like "single proposal" meetings, where we meet for one hour, that would reduce preperation time |
| 18:21 | <tabatkins> | Yup. |
| 18:22 | <yulia> | yep, its more about the prep time |
| 18:22 | <Rob Palmer> | in 2020 we did 6 per year. in 2021 we have 8 per year. should we switch to 7 per year? |
| 18:22 | <yulia> | so, if we could have large proposals have a dedicated day, that might be interesting |
| 18:22 | <littledan> | i would say: if we had something like "single proposal" meetings, where we meet for one hour, that would reduce preperation time |
| 18:22 | <yulia> | yeah that would be great |
| 18:22 | <yulia> | then i only prep one proposal |
| 18:23 | <yulia> | we could have that as a pre-determined cadence and people could sign up with larger proposals |
| 18:25 | <littledan> | if we make sure that the agendas are available well in advance, then this could help people know when to be present to block |
| 18:25 | <tabatkins> | 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. |
| 18:26 | <davethegr8> | 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? |
| 18:26 | <littledan> | doesn't csswg have weekly calls? |
| 18:26 | <Michael Ficarra> | davethegr8: that sounds like a promising direction |
| 18:26 | <shu> | yes, i like single proposal slots |
| 18:27 | <shu> | it's worked well for incubator calls fwiw |
| 18:27 | <shu> | incubator calls started trying to have more than a single slot, and that just didn't work at all |
| 18:27 | <Michael Ficarra> | also note that weeks with plenary are weeks where we skip editor call and various other side meetings |
| 18:28 | <tabatkins> | 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 |
| 18:28 | <tabatkins> | (We got thru six of the items this time, that's not unusual.) |
| 18:29 | <tabatkins> | And then we have 3-4 longer meetings per year (which includes the big cross-W3C TPAC meeting) |
| 18:30 | <bakkot> | single proposal slots would be a nightmare for me, fwiw |
| 18:31 | <bakkot> | means i would have to be thinking about tc39 scheduling constantly, instead of just every few weeks |
| 18:31 | <littledan> | I think we'd need to have weekly meetings if we wanted to give big gaps like this |
| 18:32 | <littledan> | tabatkins: Maybe you could share some experience with how vacations work for csswg? |
| 18:32 | <tabatkins> | 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. |
| 18:32 | <bakkot> | that queue item was me |
| 18:33 | <bakkot> | couldn't find my mic, sorry |
| 18:33 | <bakkot> | don't know what happened to my name... |
| 18:33 | <tabatkins> | 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. |
| 18:33 | <littledan> | I wonder why this doesn't work for bakkot and waldemarh |
| 18:33 | <littledan> | +100 to ptomato 's comment |
| 18:35 | <bakkot> | 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 |
| 18:36 | <bakkot> | 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 |
| 18:36 | <littledan> | 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. |
| 18:36 | <yulia> | 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 |
| 18:37 | <bakkot> | Again, I am not talking about blocking, just about ensuring that I have the chance to review carefully before advancement can happen |
| 18:37 | <yulia> | because ditto to what bakkot said |
| 18:37 | <littledan> | maybe we can just cancel our remaining 2-day meetings this year and see what happens? |
| 18:38 | <littledan> | and encourage more use of incubator calls to make up for it |
| 18:39 | <littledan> | anyway I agree with bakkot |
| 18:39 | <ljharb> | 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" |
| 18:40 | <Sergey Rubanov> | Shorter days could help people from inconvenient time zones unload their day and participate more |
| 18:41 | <littledan> | 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. |
| 18:44 | <bakkot> | shu: I mean the point of my company joining is so we can check every single proposal |
| 18:44 | <bakkot> | it's not necessarily that I personally need to do it, but someone from my company does |
| 18:44 | <Bradford Smith> | 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. |
| 18:46 | <yulia> | waldemarh: i saw you had a response to my topic, shall we discuss here? |
| 18:48 | <rbuckton> | Where is this issue? |
| 18:48 | <waldemarh> | My concern was inclusiveness, where we seem to be dismissive of attendees' desire to attend all plenary meetings. |
| 18:48 | <rbuckton> | I found it |
| 18:49 | <bakkot> | Where is this issue? |
| 18:49 | <yulia> | 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? |
| 18:49 | <rbuckton> | IIRC, myself, danielrosenwasser and tabatkins volunteered as champions for pipeline? |
| 18:50 | <tabatkins> | 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. |
| 18:50 | <tabatkins> | Yes. |
| 18:50 | <waldemarh> | Maybe some of the technical issues can be addressed via such means, but it's still an inclusiveness problem. |
| 18:50 | <tabatkins> | 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. |
| 18:50 | <ljharb> | tabatkins: usually a year at a time; check the current agenda at the bottom (every agenda has the upcoming meetings at the bottom) |
| 18:50 | <yulia> | 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 |
| 18:51 | <yulia> | but, maybe we could handle the extra pressure with incubator calls |
| 18:51 | <yulia> | I think the majority of proposals that try to advance and fail due to design issues, are usually early stage proposals |
| 18:51 | <rbuckton> | I added myself and danielrosenwasser to the list for pipeline |
| 18:51 | <yulia> | (haven't checked, thats just my feeling) |
| 18:51 | <tabatkins> | ljharb: Ah thanks, I might submit a PR to add them to the main page with filled in info |
| 18:52 | <ljharb> | ljharb: Ah thanks, I might submit a PR to add them to the main page with filled in info |
| 18:53 | <tabatkins> | sounds good |
| 18:53 | <shu> | bakkot: that's fine! that's why your company doesn't employ just a single person |
| 18:53 | <littledan> | would people be open to discussing this item? |
| 18:53 | <shu> | 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 |
| 18:53 | <littledan> | but if people don't want to discuss it, that's OK |
| 18:53 | <shu> | bakkot: i was calling out specific delegates feeling that pressure personally |
| 18:53 | <ljharb> | bakkot: that's fine! that's why your company doesn't employ just a single person |
| 18:54 | <shu> | 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 |
| 18:54 | <Michael Ficarra> | ljharb: it can also be hard to find qualified individuals |
| 18:55 | <ljharb> | shu: that's not really an argument that's inclusive to companies without massive revenue/budgets/workforce |
| 18:55 | <shu> | then take that up with ecma about asking for dues and making members companies? |
| 18:55 | <shu> | like the standards body is not a design focus group, i keep saying this |
| 18:56 | <shu> | it is to get interoperability on features everyone can live with |
| 18:56 | <ljharb> | i'm not sure what you mean. ecma's dues are scaled by revenue |
| 18:56 | <ljharb> | right, but "everyone" includes "companies who can't afford to pay for multiple people to do standards work" |
| 18:56 | <ljharb> | the importance of someone's input doesn't lessen because there's a smaller budget behind them. |
| 18:57 | <shu> | i don't see us having a productive discussion about this, so i'm going to lunch, sorry |
| 19:17 | <Aki> | 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 |
| 19:27 | <littledan> | 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. |
| 19:38 | <Richard Gibson> | in before Mark: https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 |
| 19:41 | <Richard Gibson> | 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/ |
| 19:42 | <littledan> | yeah, look at how DNS has clearly fallen off the complexity cliff. Nobody uses it anymore. |
| 19:46 | <Richard Gibson> | the argument is that approximately nobody gets it right, because new features interact with old ones |
| 19:46 | <littledan> | I think we have a stronger testing story which avoids that particular problem |
| 19:47 | <littledan> | 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. |
| 19:58 | <davethegr8> | Did we formally drop IRC? I seem to have been removed from the delegates channel and can't rejoin |
| 20:04 | <ljharb> | 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. |
| 20:06 | <bakkot> | ljharb: fwiw I am almost certain that we could just mention it without issue as long as it doesn't go in the title |
| 20:06 | <bakkot> | and I think we should do that, at least once our docs are updated |
| 20:07 | <ryzokuken> | yeah, we can mention it, just not include it in the topic |
| 20:07 | <ljharb> | probably so |
| 20:07 | <ljharb> | there's so few non-delegates tho that i'll probably just PM them |
| 20:08 | <Michael Ficarra> | waldemarh: https://w3c.github.io/webappsec-csp/ |
| 20:12 | <waldemarh> | Michael Ficarra: Thank you |
| 20:15 | <littledan> | Personally, I'm not persuaded that either of these two constraints posited by Domenic about the module map makes sense |
| 20:15 | <yulia> | i don't understand this one... what was the rationale? |
| 20:16 | <shu> | yulia: i can try to explain later |
| 20:16 | <shu> | yulia: when we're discussing |
| 20:17 | <yulia> | ok, thanks |
| 20:18 | <littledan> | That will be great, since I don't understand the rationale either. |
| 20:18 | <Aki> | what the heck. |
| 20:19 | <waldemar> | <test post> |
| 20:19 | <Hemanth H.M> | Thanks Aki it worked. |
| 20:23 | <Justin Ridgewell> | Was there pushback from TAG? |
| 20:24 | <littledan> | https://github.com/caridy/irealm |
| 20:25 | <shu> | 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 |
| 20:25 | <shu> | i didn't read the TAG review as "the TAG pushed back" |
| 20:26 | <Michael Ficarra> | I agree that the ergonomics in this proposal are quite bad, and it seems tailored to a very very narrow usage |
| 20:27 | <littledan> | i didn't read the TAG review as "the TAG pushed back" |
| 20:31 | <bakkot> | question: are SABs and atomics actually seeing much use? |
| 20:31 | <bakkot> | even via libraries? |
| 20:31 | <shu> | unfortunately no, spectre had a lot to do with it |
| 20:31 | <shu> | but the feedback i hear is that it's just too hard |
| 20:31 | <shu> | futexes be hard |
| 20:32 | <shu> | thus what i'm trying to do with concurrent js with higher level abstraction |
| 20:32 | <littledan> | 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/ |
| 20:33 | <bakkot> | that's a relatively recent development, if I understand right; they shipped for a while first |
| 20:33 | <bakkot> | 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 |
| 20:34 | <ljharb> | it doesn't, which is why it's totally reasonable for the defaults to be "whatever's in the env" |
| 20:34 | <ljharb> | but that's not an argument to prohibit some opt in way to get a subset |
| 20:35 | <bakkot> | I don't understand the argument for being able to opt in to that; say more? |
| 20:35 | <bakkot> | like if you just aren't using the extra things, seems fine? |
| 20:35 | <littledan> | Looks like SAB is running at about .5% of Chrome page loads https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructed |
| 20:35 | <bakkot> | 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 |
| 20:35 | <ljharb> | bakkot: i want to run code, that uses transitive deps i don't author, and ensure that it works in all my target envs |
| 20:36 | <bakkot> | littledan: sweet, thanks |
| 20:36 | <bakkot> | ljharb: I don't understand how this helps with that goal |
| 20:36 | <Justin Ridgewell> | Can someone throw my name on the queue to respond |
| 20:36 | <littledan> | btw I guess Shu is on the globals topic, and hasn't yet started his queue item about module loading yet, right? |
| 20:36 | <Justin Ridgewell> | (Computer less) |
| 20:36 | <ljharb> | 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 |
| 20:36 | <shu> | correct |
| 20:37 | <Michael Ficarra> | Justin Ridgewell: added |
| 20:37 | <littledan> | bakkot: SAB is at the sweet spot of "too commonly used to unship, not used enough to actually be considered fully successful" |
| 20:38 | <bakkot> | ljharb: I don't understand how opting in to the subset helps with your goal |
| 20:38 | <bakkot> | unless you mean just for running tests? |
| 20:38 | <bakkot> | and if it's just for running tests, manually deleting seems like the way to go for sure |
| 20:38 | <ljharb> | that, but also for running it in a realm in prod, assuming that's performant enough |
| 20:39 | <ljharb> | 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 |
| 20:39 | <bakkot> | for doing it in prod, I do yet not understand how opting in to the subset helps |
| 20:39 | <Michael Ficarra> | we don't seem to be sticking to the queue very well though |
| 20:39 | <ljharb> | 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 |
| 20:40 | <bakkot> | hmm. |
| 20:40 | <bakkot> | ok, I understand that motivation but it really does not seem to me sufficiently important to warrant language support, I guess. |
| 20:41 | <littledan> | I hope we have time to discuss the module system issues today. |
| 20:44 | <yulia> | I mentioned [Exposed=*] before |
| 20:44 | <yulia> | that would be reviewing webidl for exposed tags such as https://w3c.github.io/FileAPI/#dfn-Blob |
| 20:44 | <yulia> | ill raise this in a moment |
| 20:48 | <yulia> | so, the work that would need to happen is we would need to review this for truly universal apis |
| 20:48 | <Michael Ficarra> | how can anything be "not a stage 3 blocker"? |
| 20:49 | <bakkot> | Michael Ficarra: if you're asking for an additional feature, you can push it through in a subsequent proposal |
| 20:49 | <waldemar> | Can we advance the queue? |
| 20:49 | <waldemar> | We've had the same few people speak for a while |
| 20:49 | <waldemar> | There are nine entries queued |
| 20:49 | <yulia> | ^ Rob Palmer |
| 20:54 | <littledan> | What Mark is describing is not the current version of this proposal. I thought we agreed that what Leo presented was acceptable. |
| 20:54 | <shu> | yeah i'm not sure what we're being asked |
| 20:54 | <shu> | what mark is saying is kind of radical |
| 20:54 | <littledan> | 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 |
| 20:54 | <shu> | for ecma262 to "version pin" other upstream specs |
| 20:54 | <littledan> | yeah, I disagree with Mark's proposal |
| 20:55 | <littledan> | I would like to talk about modules, though |
| 20:55 | <shu> | same, i regret responding to jordan |
| 20:55 | <yulia> | [exposed=*] would be a stretch goal, it would be a lot of work. we can also just use the existing piping |
| 20:56 | <littledan> | I imagine it being more like [Exposed=Window,Worker,Realm] |
| 20:56 | <Jack Works> | 🤔Actually I found it's hard to track those Web IDL tags |
| 20:56 | <yulia> | yeah, that would be fine |
| 20:56 | <littledan> | I don't see a strong need for * at this point; being explicit isn't bad |
| 20:56 | <yulia> | agreed |
| 20:57 | <littledan> | 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) |
| 20:57 | <Jack Works> | E.g. I don't know how to get the full list of [Serializable] (for structured cloning) from Web spec |
| 20:59 | <yulia> | ah i understand the concern.. hm |
| 20:59 | <yulia> | Jack Works: i've just been searching, ill ask anne if he has tips |
| 20:59 | <yulia> | i need to think more about the module map |
| 21:00 | <Jack Works> | so should we have a new API for loading but not executing the module map to resolve the module map concerns? |
| 21:00 | <Jack Works> | e.g. import.cache(specifier) |
| 21:00 | <yulia> | yeah that is true what is being said now |
| 21:01 | <Jack Works> | cool |
| 21:02 | <yulia> | oh sorry Jack Works i was responding to the conversation not your question |
| 21:02 | <yulia> | I don't know the answer there |
| 21:02 | <yulia> | though, exposing how the module loader is working is something I have been thinking |
| 21:02 | <yulia> | unrelated from realms though, for another thing |
| 21:03 | <Jack Works> | lol |
| 21:03 | <Jack Works> | that's a thing in the compartment API. we should give developers more controls about how modules loaded in that proposal IMO |
| 21:04 | <bakkot> | 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" |
| 21:04 | <bakkot> | I think the fact that modules are cached is basically irrelevant to that consideration |
| 21:04 | <bakkot> | unless you have the restriction that you can only load things previously cached by the outer realm |
| 21:04 | <shu> | that's one such proposed path forward |
| 21:05 | <Justin Ridgewell> | If Realms exist in process, there's already a timing vulnerability with Spectre |
| 21:06 | <bakkot> | Justin Ridgewell: right, but that's not relevant unless they can exfiltrate data |
| 21:06 | <Justin Ridgewell> | I don't see why we need to prevent module loading (which is significant) to prevent another timing vuln |
| 21:07 | <Jack Works> | 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. |
| 21:07 | <Jack Works> | how do you think about that, or it's my misunderstanding on the compartment |
| 21:07 | <littledan> | maybe "cached by the outer realm or explicitly passed as the argument to importValue"? |
| 21:08 | <yulia> | i think switching static imports does change the behavior if you modify global state? |
| 21:08 | <yulia> | though it is less unintuitive than this |
| 21:08 | <littledan> | 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. |
| 21:09 | <shu> | it is important is to acknowledge that this IS a timing channel but it is somehow okay |
| 21:09 | <ljharb> | isn't this timing issue something that wasn't an issue for TLA? |
| 21:09 | <shu> | not that timing is an implementation's problem |
| 21:09 | <ljharb> | 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 |
| 21:09 | <shu> | ljharb: TLA doesn't entice people to try to run untrusted code |
| 21:10 | <ljharb> | right but why does it matter if the untrusted code can see that the cache was populated first, versus not? |
| 21:11 | <ljharb> | is the concern that untrusted code could learn something about what things are imported by the trusted code that ran before it? |
| 21:12 | <ljharb> | (and also, isn't anything imported from another domain "untrusted", which was the entire motivation around json modules and import assertions?) |
| 21:15 | <shu> | ljharb: the cache matters as much as you care about timing? |
| 21:16 | <shu> | 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 |
| 21:16 | <shu> | i guess to me, that's at an earlier stage in the pipeline |
| 21:16 | <shu> | "untrusted code" in the sense that you want to execute it, you just don't trust it to do 100% safe things |
| 21:17 | <shu> | the json module thing was "let's not execute it at all" |
| 21:17 | <ljharb> | alrighty, i hear the distinction |
| 21:18 | <littledan> | 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 |
| 21:21 | <Jack Works> | https://github.com/tc39/proposal-realms/issues/22 |
| 21:21 | <Jack Works> | stage 3 question, how to handle annex b |
| 21:30 | <Michael Ficarra> | we should've always required escaping - in character classes |
| 21:30 | <Michael Ficarra> | or at least when we introduced the u flag |
| 21:43 | <tabatkins> | There is in fact only 26^2 flags |
| 21:43 | <tabatkins> | Well, the "flag + zwnj + (regionalchars+)" version that lets you do subregion indicators is theoretically infinite |
| 21:44 | <tabatkins> | sorry, zwj |
| 21:45 | <Michael Ficarra> | there's other flags that are not country/region flags |
| 21:45 | <Michael Ficarra> | chequered flag |
| 21:45 | <Michael Ficarra> | white flag, pirate flag |
| 21:45 | <tabatkins> | sure but they're in the same "infinite" category as any other combination emoji |
| 21:45 | <tabatkins> | the flagness isn't relevant |
| 21:48 | <bakkot> | it definitely might mask a bug but it's not something the language should stop you from doing |
| 21:49 | <shu> | it might mask a bug in the sense that any operation can mask a bug? |
| 21:49 | <Michael Ficarra> | also compilers generate these kinds of things and they want them to behave like sets |
| 21:50 | <bakkot> | yeah |
| 21:50 | <bakkot> | also maybe you are just being careful, who knows |
| 21:50 | <bakkot> | that is a thing for linters to deal with |
| 21:51 | <shu> | just doesn't seem legit to me to lint |
| 21:51 | <bakkot> | people lint for no-unnecessary-escapes, it's the same sort of thing |
| 21:51 | <bakkot> | also, I kind of like waldemar's idea about, if you say v you have to also say u |
| 21:53 | <Michael Ficarra> | 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 |
| 21:53 | <ljharb> | 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 |
| 21:53 | <Michael Ficarra> | I'm leaning toward the former |
| 21:54 | <bakkot> | 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 |
| 21:54 | <bakkot> | as far as I understood, anyway |
| 21:55 | <ljharb> | 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 |
| 21:56 | <Michael Ficarra> | ljharb: again, these are not just constructed in user programs, they are also constructed by compilers outputting JavaScript |
| 21:56 | <Michael Ficarra> | which may not have access to these data sets |
| 21:56 | <ljharb> | such validation would presumably be trivial with /^\p{RGI_EMOJI}*$/.test(input) as well |
| 21:56 | <ljharb> | while that's fair, i'm also not convinced that's something that's reasonable to optimize for |
| 21:57 | <Michael Ficarra> | we consider the compile-to-JS use case all the time, since at least I started attending committee |
| 21:57 | <ljharb> | consider, sure |
| 21:59 | <bakkot> |
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. |
| 22:01 | <Michael Ficarra> | I think this V => U question can be resolved during stage 2 |
| 22:01 | <shu> | yeah it's not a blocking concern |
| 22:07 | <Hemanth H.M> | https://dev.to/hemanth/updates-from-83rd-meeting-of-tc39-1d67 :) |
| 22:10 | <tabatkins> | Just to be clear, it's "virtual" tokyo, right? |
| 22:10 | <Aki> | it is indeed |
| 22:10 | <tabatkins> | all right, combination phew+damb |
| 22:10 | <tabatkins> | goddamit, "damb" has sunk into my fingers now, it's happening automatically |
| 22:11 | <Aki> | https://snaps.akiro.se/mia9w.jpg |
| 22:12 | <Michael Ficarra> | yeah, I would not want to be trying to book a flight to Tokyo for mid-July right now |
| 22:14 | <tabatkins> | oh yeah the olympics exists |
