2024-04-04 [07:14:40.0599] i hope Temporal will be able to support the moon https://www.reuters.com/science/white-house-directs-nasa-create-time-standard-moon-2024-04-02/ [07:17:02.0068] That is a clear use case for sub-microsecond precision [07:21:24.0968] we'll need a v2 of Temporal where we specify the astronomical "home base" object. CLDR will need to be extended with a new catalog of astronomical objects and new lunar time zones. Should be doable! [07:22:01.0255] make sure you never end up with a home base inside a black hole [07:25:47.0132] maybe this time we can get it right and agree to use timex time (100 second minutes, 100 minute hours) on the moon [07:30:17.0337] * we'll need a v2 of Temporal where we specify the astronomical "home base" object for all operations. CLDR will need to be extended with a new catalog of astronomical objects and new lunar time zones. Should be doable! [12:23:57.0519] what I learned from researching the moon standard time in the past couple of days, is that local gravity affects the rate at which atomic clocks tick. Earth's atomic time is the average of several dozen atomic clocks, all with gravitational corrections applied so that they are effectively ticking at mean sea level (even if the clock itself is physically far above sea level) [12:34:03.0904] Yup, that's relativity for you. Gravity affects the rate time passes. [12:34:36.0407] yeah it's not just that it affects the rate at which the clocks tick, it's that it affects the rate at which _everything_ ticks https://en.wikipedia.org/wiki/Gravitational_time_dilation [12:35:20.0711] looking forward to Temporal being updated to include a "strength of local gravity" parameter :D [12:38:07.0627] right, so I'm a bit skeptical about whether it makes any sense to stretch the definition of POSIX time to incorporate other astronomical bodies [13:56:02.0800] gentle reminder to please add any and all plenary schedule constraints as soon as possible [14:45:50.0407] > <@bakkot:matrix.org> looking forward to Temporal being updated to include a "strength of local gravity" parameter :D "velocity relative to timebase station", too [14:46:24.0570] if we're doing velocity we need acceleration and jerk and so on as well, so we can properly represent dates in the future [14:46:37.0262] really just a full PDE I figure [14:52:33.0535] the curvature of the entire universe too [14:57:37.0525] what the fuck 2024-04-05 [17:19:11.0869] The current time systems in common use are only really designed to work on the surface of the Earth. Astronomers and other space scientists use different time systems which account for relativistic effects such as https://en.wikipedia.org/wiki/Barycentric_Dynamical_Time [17:21:00.0409] One of my favorite papers is measuring the masses of various solar system bodies such as Saturn using nothing more than clocks, comparing earthbound clocks to clocks outside the solar system (in the form of distant pulsars): https://arxiv.org/abs/1008.3607 [17:24:04.0707] The approach of counting seconds won't work well after we expand into space because clocks tick at different rates in different places in the solar system. If you want everyone to stay synced to Earth time, you'll need to adjust the duration of the second depending on where you are. If you want to keep the SI definition of a second, clocks in various places will diverge over time. [17:25:16.0778] We already have that issue with spacecraft, but the scientists and engineers working them account for the differences. [15:18:54.0730] if you'll all allow a brief single off-topic post: i'm baaaaaack. 😘 [15:37:44.0040] requesting consensus for an eclipse break on Monday [15:39:42.0077] well. I guess that doesn't make much sense unless the break is like.. 2 hours long [15:39:44.0800] i wonder if people will be too distributed [15:39:46.0787] lol [15:39:50.0436] also that [15:40:40.0576] ah, actually for me the meeting will be over already [15:41:04.0653] yeah the farther east you are, i think 2024-04-06 [17:35:11.0123] I will be missing Monday for the eclipse, though I might try to dial in to observe the plenary for part of the day. [23:36:03.0603] https://github.com/tc39/Reflector/issues/522#issuecomment-2040991367 [23:38:46.0738] ☝️ draft schedule is available. all constraints have been accommodated 2024-04-08 [07:02:26.0932] is there a way to join the meeting without logging in [07:02:59.0511] I joined the call anonymously (no prior log in) [07:03:46.0202] you do not have to use the client [07:04:12.0479] oh i see, i can just enter any name/email, thanks [07:04:12.0879] if you click the "use on the web" it kind of implies you're signing in, but you just put your name and email and then join regardless of what you put in those boxes [07:04:22.0400] > <@shuyuguo:matrix.org> is there a way to join the meeting without logging in yes [07:04:37.0660] I just gave my name and email address, and then the "join as guest" button un-grayed [07:04:52.0415] (done on the native client) [07:07:19.0489] > <@bakkot:matrix.org> if you click the "use on the web" it kind of implies you're signing in, but you just put your name and email and then join regardless of what you put in those boxes thanks, that's what confused me [07:20:48.0227] Slides for this presentation at https://github.com/tc39/agendas/blob/littledan-patch-2/2024/tc39-2024-016.pdf (PR'd to the agenda also) [07:21:29.0352] ooohh we're bringing WinterCG into Ecma? [07:21:35.0040] yep! [07:21:40.0316] WinterTC [07:21:42.0628] I imagine it won't continue to be called WinterCG? [07:22:02.0902] More context: https://github.com/wintercg/admin/issues/58 [07:22:28.0541] The W3C CG will be the main place for technical development; WinterTC will be more for validation and formal standardization (this mirrors CycloneDX) [07:25:15.0098] Are temp checks an official vote? [07:25:21.0423] no [07:25:26.0632] It's weird that voting rules apply to temp checks [07:26:05.0675] yes, I agree. I think these Ecma rules only apply directly to official votes, which we do not have. That said, I'm not sure if IEs should be able to block. [07:26:09.0848] they're def not votes [07:26:35.0227] calling for consensus on advancement might be thought of as an implicit vote [07:26:39.0873] but temperature checks certainly aren't fotes [07:26:43.0137] * but temperature checks certainly aren't votes [07:26:44.0160] IEs definitely should not be voting/blocking [07:26:48.0579] IEs not being able to participate in consensus would be a radical change from the way tc39 has always operated, so that'd be something that needs discussion [07:27:02.0636] IEs should not be able to veto [07:27:08.0299] > <@ljharb:matrix.org> IEs not being able to participate in consensus would be a radical change from the way tc39 has always operated, so that'd be something that needs discussion OK, let's have this discussion now with Samina [07:27:13.0942] in the queue [07:27:55.0522] about temp checks sure. but ecma rules aren't really relevant; IEs participate in consensus here, and we'd need an agenda item to get consensus on changing that. [07:31:40.0124] shu: "being an IE" is at the discretion of chairs and ecma, so if that were ever abused it would be pretty easy to shut it down [07:32:48.0877] Does consensus for stage advancement count as a "vote" in ECMA terms? [07:33:08.0900] imo yes? [07:33:25.0901] I think so [07:33:26.0192] no [07:33:27.0989] like i don't see why there would be any bylaws if any TC can also just say "actually we don't do that"? [07:33:33.0498] it's consensus. not a ote. [07:33:34.0769] * it's consensus. not a vote. [07:33:43.0685] if it was a vote than we wouldn't ask individuals, we'd ask members. [07:33:50.0747] And we informally agree that the chairs only ask for the vote if there is would be full consensus [07:34:00.0218] i strongly disagree [07:34:04.0350] for example, google having 30 delegates would still only get 1 response to a call for consensus. that's not how we operate. [07:34:19.0368] there has long been disagreement within the committee about what the policy is. It's good for this to be on the table for discussion. [07:35:06.0618] * for example, google having 30 delegates would still only get 1 response to a call for consensus. that's not how we operate, or have literally ever operated. [07:35:28.0730] * And we informally agree that the champions only ask for the vote if there is would be full consensus [07:35:39.0534] * And we informally agree that the champions only "ask for the vote" if there is would be full consensus anyway, so no vote needed [07:35:45.0497] it's fine to discuss it, and if someone would like to, it'd be great to add an agenda item for it. but making a change here would be dramatic and unprecedented for tc39, and isn't a matter of simply "interpreting bylaws". [07:35:47.0564] It would be Really Good for execom to explicitly comment on our consensus practices. [07:36:13.0061] good reminder from @ljharb on GitHub teams, and thank you for your good work on setting up the GitHub teams. I do want to note that we have some inconsistencies between the GitHub and Ecma data (which member organizations have provided to Ecma and are published in the Ecma memento) and we will need to work through these. I believe neither one of these is perfectly up to date, and we will make a lot of progress by reconciling them. [07:36:30.0673] in general, laws serve the people, so if the bylaws conflict with what we actually do, the bylaws, not us, should change. [07:37:22.0954] > <@eemeli:mozilla.org> It would be Really Good for execom to explicitly comment on our consensus practices. In general, the ExeCom and Ecma management are very happy with TC39's "self-governance" and don't want to intervene too much. Ecma folks have previously said that they are happy with consensus-based processes like ours, but have found our way of dealing with vetos as absolute to be a bit much. [07:37:29.0948] * in general, laws serve the people, so if the bylaws conflict with what committees actually do, the bylaws, not us, should change. [07:39:42.0536] > <@ljharb:matrix.org> in general, laws serve the people, so if the bylaws conflict with what committees actually do, the bylaws, not us, should change. Yes, I very strongly agree with you that we should be thoughtful about any change to TC39's practices and not just blindly apply rules/bylaws, but consider whether they need to be changed if they don't fit, and submit such changes to the Ecma GA for a vote [in practice, consensus there too]. That said, the committee has long contained multiple opinions about whether IEs can block, so it's not clear what the change would/should be. Ecma rules are still set by the GA and not by TC39 precedent. [07:40:06.0634] I mean, this is why I got involved in Ecma stuff in the first place, to ensure that we had an IE policy in the first place and that we didn't accidentally kick Babel etc out [07:42:21.0294] littledan: Does "a bit much" mean that there's an expectation for us to change something at some point, or that the divergence from expectations is small enough to ignore? [07:43:36.0431] i mean sure, but opinions that differ from 100% of past history don't change what's actually happened [07:44:02.0808] it's fine to believe IEs shouldn't participate in consensus, for example, but that's only relevant in a discussion about whether to change the fact that they do :-) [07:45:10.0345] * it's fine to believe IEs shouldn't participate in consensus, for example, but that's only relevant in a discussion about whether to change the fact that they do :-) (which is also fine to have, ofc) [07:50:01.0990] > <@eemeli:mozilla.org> littledan: Does "a bit much" mean that there's an expectation for us to change something at some point, or that the divergence from expectations is small enough to ignore? No, there is no expectation that we change anything; they respect our self-management here and don't want to excessively intervene. [07:50:38.0182] > <@ljharb:matrix.org> i mean sure, but opinions that differ from 100% of past history don't change what's actually happened in past incidents of IEs blocking, IMO there is ambiguity as to whether the IE actually executed a block, or whether the IE expressed a strong negative opinion and the champion withdrew the request for advancement. [07:51:18.0335] there's no such thing as "block". there's either consensus for something, or not [07:51:19.0727] IEs are definitely here to participate actively in all technical discussions, and express strong negative opinions when there's a request for consensus, no doubt about that. If they make a good argument, they won't be the only blocker, so this is probably not a very impactful decision. [08:10:06.0150] 402 update slides: https://notes.igalia.com/p/fxx00_k5K#/ [08:14:39.0447] This transcriber wrote "camel cased" as CamelCased [08:14:47.0790] 💯 [08:19:43.0281] oh no, that's PascalCased tho [08:21:34.0343] ptomato: Could you please provide a link to the sovereign tech fund that is funding the test262 work? Or to your slides? [08:22:08.0509] it's Germany [08:22:14.0492] https://www.sovereigntechfund.de [08:22:27.0910] I was about to paste the content of the slide into the notes, will that work? [08:22:30.0491] they also gave nearly a million to the OpenJS Foundation last year [08:22:33.0853] otherwise yes what Jordan said [08:22:38.0930] they're doing what all governments should be doing :-) it's great [08:22:50.0560] Great, thank you :) [08:29:53.0178] Hypothetical question, would we take money from any sovereign tech fund, or would we consider things like human rights records, etc. before accepting funding? [08:29:55.0536] apparently there's also https://nlnet.nl/bluehatsprize/2024 currently seeking nominations [08:31:06.0719] > <@dminor:mozilla.org> Hypothetical question, would we take money from any sovereign tech fund, or would we consider things like human rights records, etc. before accepting funding? we = TC39? [08:33:33.0268] Well, in that case I guess it's Igalia's decision, but yes, I'm kind of wondering how we as a group would feel about this. [08:33:46.0813] There's also https://www.opentech.fund (from the US govt) [08:34:09.0282] > <@dminor:mozilla.org> Well, in that case I guess it's Igalia's decision, but yes, I'm kind of wondering how we as a group would feel about this. I guess this would be something at the Ecma level? In which case it'd definitely be a matter up for GA discussion [08:34:18.0521] i feel like TC39 itself isn't a legal entity to receive funds, so i imagine it's just up to Ecma [08:35:14.0197] * There's also https://www.opentech.fund (from the US govt) , specifically https://apply.opentech.fund/foss-sustainability-fund/ [08:35:30.0172] it'd be nice if the CoC update included what actions were taken (if any) instead of just saying "it's been resolved" [08:36:04.0448] the usual non-profit donation tricks abound, i imagine, with whether you can or cannot earmark donations for specific activities, especially if it's from a government [08:42:48.0319] > <@shuyuguo:matrix.org> the usual non-profit donation tricks abound, i imagine, with whether you can or cannot earmark donations for specific activities, especially if it's from a government FWIW Ecma is a Swiss "association", not a US 501(c)(3). I think this makes certain things more flexible. [08:42:49.0122] serious question: is there anyone who goes to the Firefox download page, says "300MB?! No thanks.", and leaves? [08:43:01.0054] I think by the time you're there, you're downloading Firefox, right? [08:43:11.0121] it's sort of a cumulative thing though, right? [08:43:19.0205] especially for mobile [08:43:21.0208] my intuition on almost all size concerns are about mobile, not desktop [08:43:25.0833] you mean Mozilla wants to save upload bandwidth? [08:43:33.0612] indeed i don't think people say that to the desktop downloader [08:43:37.0711] > <@michaelficarra:matrix.org> serious question: is there anyone who goes to the Firefox download page, says "300MB?! No thanks.", and leaves? When your phone is out of storage you have to start going through the list of big apps 🤷 [08:43:52.0500] And all phones already have a built-in browser [08:44:03.0169] > <@shuyuguo:matrix.org> the usual non-profit donation tricks abound, i imagine, with whether you can or cannot earmark donations for specific activities, especially if it's from a government * FWIW Ecma is a Swiss "association", not a US 501(c)(3). I think this makes certain things more flexible (IANAL!) [08:44:24.0422] also, markets with significantly cheaper hardware [08:44:35.0991] how small is the average phone in those markets these days? [08:44:52.0859] I think it's more about bandwidth [08:45:08.0499] > <@ljharb:matrix.org> how small is the average phone in those markets these days? Idk but my dad is always uninstalling apps to free up space because his phone is full [08:45:18.0199] * I think it's more about download bandwidth [08:48:05.0841] > <@ljharb:matrix.org> how small is the average phone in those markets these days? (nominally 64GB-128GB, usually) [08:48:18.0998] that's what i'd expect [08:48:47.0927] for me it's images/movies, not apps, that take up space [08:49:31.0939] > <@michaelficarra:matrix.org> serious question: is there anyone who goes to the Firefox download page, says "300MB?! No thanks.", and leaves? To be picky, Firefox desktop on MacOS is currently 134Mb, and on Android it's 88Mb. [08:49:44.0151] > <@michaelficarra:matrix.org> serious question: is there anyone who goes to the Firefox download page, says "300MB?! No thanks.", and leaves? * To be picky, Firefox desktop on MacOS is currently 134MB, and on Android it's 88MB. [08:49:57.0772] yeah I was too lazy to look up the actual number [08:50:25.0530] here, let me fix it for you: "134MB?! No thanks." [08:51:12.0437] > <@jesse:igalia.com> for me it's images/movies, not apps, that take up space spotify's cache grows nearly exponentially [08:53:42.0877] > <@michaelficarra:matrix.org> it'd be nice if the CoC update included what actions were taken (if any) instead of just saying "it's been resolved" per the Code of Conduct: > The Committee will never publicly discuss the issue; all public statements, if needed, will be made by the TC39 Chair and/or the Ecma Secretariat. [08:55:37.0682] telling us what actions were taken (like somebody being banned from a particular forum) is not discussing the issue IMO [08:58:53.0469] The CoC committee could refer more public statements to the chair or secretariat for disclosure. Overall I think we have enough experience that statements like, "there was a report, it was handled" don't really make all of TC39 feel more secure about the process. But maybe we should just trust the CoC committee, and even these notifications are unnecessary--confidentiality is really important to preserve. [08:59:21.0144] yeah i think if you want to be confidential just don't update [08:59:31.0979] 100% confidential, that is [09:00:38.0215] depending on the action taken, saying what that action was may have privacy risk [09:00:45.0184] there's no harm in evolving our CoC processes in order to better serve delegates and make everyone feel more secure about our working environment here [09:10:07.0761] it's up to TC39 what the CoC is and how the CoC committee reports back to TC39 and the ExeCom/GA. if folks want to change the CoC, that's fine. it needs to be raised and get consensus at plenary, and I think Ecma ExeCom also would need to support if I'm not mistaken [09:11:13.0487] * it's up to TC39 what the CoC is and how the CoC committee reports back to TC39 and the ExeCom/GA. if folks want to change the CoC, that's fine. it needs to be raised and get consensus at plenary [09:22:37.0997] Definitely needs an agenda item to draw a conclusion; this is just some earlier discussion/feedback, which is also valid (like our above discussion about Ecma rules despite this not being a GA meeting). The CoC committee could also be the ones to propose something to plenary, based on this kind of feedback. [09:33:14.0276] you're absolutely right. I want to be clear it's not a matter the CoC committee can unilaterally decide [09:40:03.0157] About blocks: IMO IEs should generally be able to operate equally to all other committee delegates, and the process focus should probably be more on, what can we do in response to someone (anyone) blocking, and whether the committee may still have general consensus (e.g., by establishing that general consensus at a follow-on meeting once we all have more time to consider things). [10:06:38.0293] I don't know that "I would prefer to work with arrays" is... really an answer to "what is the benefit"? [10:13:14.0896] yeah I think we kinda settled this with iterator helpers a while ago... I did try to give more space to the iterables vs iterators discussion with inviting Axel in, etc. [10:14:40.0695] i mean i also to prefer to work with arrays when cache locality matters [10:14:53.0769] but i don't know if i care about it for joint iteration in particular [10:15:14.0243] and "caring about cache locality" certainly argues for case-by-case for the operation, not a catch-all [10:15:26.0619] to be clear i'm not arguing for 100% symmetry [10:16:32.0099] FYI I consider take/drop to be the analogue to slice @nicolo-ribaudo:matrix.org @bakkot:matrix.org [10:16:45.0068] they're certainly similar, just not identical [10:20:36.0850] I would like us to explicitly have a policy that we don't use "this package has many downloads" as a reason to add a feature [10:20:59.0442] "this package has many dependents from different authors", sure [10:21:41.0686] (in this case, the package has a dependency of Jest) [10:21:45.0127] yeah i was more saying, this is empirical evidence that the original belief is false [10:21:54.0495] (that everybody would prefer an aiife) [10:22:13.0426] * (in this case, the package is a transitive dependency of Jest) [10:22:30.0550] > <@shuyuguo:matrix.org> but i don't know if i care about it for joint iteration in particular please add these comments to https://github.com/tc39/proposal-joint-iteration/issues/1 [10:23:32.0294] * (in this case, the package is a transitive dependency of Jest and yargs) [10:26:24.0038] ok [10:26:28.0184] tbc, the closest analogy is `new Promise(r => r(foo, ...args))`, not a try-catch [10:26:41.0794] * tbc, the closest analogy is `new Promise(r => r(foo(args)))`, not a try-catch [10:26:48.0086] We've heard a lot of skepticism on motivation. Maybe we should do a temperature check/ [10:26:52.0606] * We've heard a lot of skepticism on motivation. Maybe we should do a temperature check? [10:27:56.0365] My position is exactly the same [10:28:03.0225] "Not bad, but not convinced that it's useful" [10:29:54.0512] Promise.prototype.catch/finally are really different from Promise.try... [10:30:26.0888] we have spent more time talking about the check than just doing the check [10:31:17.0288] I like the hoisting of a sometimes promised function into a definite promise. It helps decluttering functional chaining. [10:31:59.0561] > <@shuyuguo:matrix.org> we have spent more time talking about the check than just doing the check we do that every time. but temperature checks are rare. if they were more common, I think we wouldn't have to talk about them so much [10:34:06.0303] > <@littledan:matrix.org> Promise.prototype.catch/finally are really different from Promise.try... could you say more about what the big differences are? [10:34:52.0945] Temp polls should have a symmetrical state, going from Strong Positive to Strong Negative [10:36:06.0616] I voted "indifferent" based on agreeing with what Nicolo said. The intended meaning is not "abstain" [10:37:12.0071] "very weak negative" is how I intended my "indifferent" [10:37:23.0817] I assumed "👀" was abstain [10:37:39.0733] Indifferent indicates that you had time to consider the issue and vote. [10:38:03.0075] Indifferent has no negative connotations to me. [10:38:28.0604] Without "indifferent" it would be hard to tell if people had a chance to vote. [10:38:33.0136] communication is all about relationships and context, and not only absolute meanings of words [10:39:14.0024] here, several people explicitly clarified that they specifically meant "very weak negative", so it doesn't really matter if "indifferent" generally has no negative connotations [10:39:22.0218] anyway it has Stage 2.7 so this is closed, I think [10:39:31.0287] I guess given that we would not advance a proposal unless at least some people were strongly positive, and that "very weak negative" is "I don't object to advancement", there's not much practical difference between the two [10:40:09.0667] in this case, yes [10:40:23.0112] more of an aside, but we regularly change the semantics of what the temp check options are because they don't always align well with the question [10:40:25.0642] I did want to elicit some more positive/strongly positive feedback, which we did get [10:42:13.0844] just a backslash wouldn't work anyway since we got rid of identity escapes [10:42:30.0766] so it'd be replacing the first character with an escape sequence for that character, like a hex escape [10:42:39.0129] if this is even needed, which I don't believe it is [10:44:33.0107] > <@nicolo-ribaudo:matrix.org> Temp polls should have a symmetrical state, going from Strong Positive to Strong Negative I think this choice was deliberate because it was trying to avoid negativity, but after a couple years of experience, it doesn't seem like that design worked. I like the idea of a basically 1-5 symmetrical scale; the other options don't seem to be very easy to interpret. [10:44:58.0284] and in particular, temperature checks were designed to avoid, well, this kind of vote as a use case, to be honest [10:44:58.0494] I opened https://github.com/bterlson/tcq/pull/67for now [10:45:12.0241] * I opened https://github.com/bterlson/tcq/pull/67 for now [10:46:35.0698] strictly more options?! [10:46:42.0933] please no, please get rid of some options at the same time [10:47:37.0849] Who should take the fall, "Strongly positive" or "Following" [10:47:59.0219] following [10:48:03.0667] following. has anyone ever voted following [10:48:31.0037] following for sure [10:49:18.0624] So "unconvinced" is weakly negative, and "negative" is strongly negative? Should we rename the options to be symmetrical? [10:49:24.0508] also confused because if you're confused, you should be asking for clarification, not voting! [10:49:44.0896] I guess in this case, "unconvinced" being the strongest negative option makes it scary to vote for [10:50:03.0976] no, confused is good, we should keep it--it's a big problem if people are confused and afraid to ask! [10:50:43.0771] I think calling it unconvinced is more expressive than "weakly negative" [10:51:04.0400] Or "This temperature check has been worded terribly I don't know what I'm voting" 😛 [10:51:07.0151] OK, I'm convinced :) [10:51:15.0439] * Or "This temperature check has been worded terribly I don't understand what the options mean in this case" 😛 [10:51:25.0428] the most important thing is to have something stronger than unconvinced, so that unconvinced becomes less harsh, I think [10:57:14.0993] Ughh I just noticed that I forgot to add slides to one of my topics on the agenda (a status update) [10:57:26.0116] this is enough change in the proposal that, even Wednesday, I don't think I'd be prepared to advance to 2.7 [10:57:26.0547] * Ughh I just noticed that I forgot to add slides to one of my topics on the agenda (a status update) -- I'm sorry [10:57:41.0666] 100% agreed [10:58:06.0556] maybe with just one of these changes, but with 2 or 3 i'd rather wait [10:58:50.0013] to be clear, I think they're all good improvements, but I'd want to review it as a whole again [11:00:31.0247] yep, i've unchecked all the signoffs so i know to re-ask [11:00:42.0656] btw for the steno, can we get them to stop double spacing after periods? [11:01:18.0285] they're also inserting newlines at the page width instead of letting it wrap 😭 [11:02:17.0713] "Can you please set your line width to 100_000_000?" [11:02:43.0350] both of those, yes please [11:03:15.0141] we've asked the stenographers to do this before. They should be doing it. I'll call them today. [11:03:27.0536] They've fixed this in the past, it's just that not all of them do it [11:25:27.0279] waldemar: On the topic of RegExp escapes, what escaping do you think we ought to use for null bytes? We have `\0`, but `\x00` is plenty readable, and `\0` has the complication that you can't use it if the next character is an ASCII digit. My inclination is to use `\x00`. [11:56:29.0626] should `microwait` be called `microWait`? [11:58:54.0669] should "kilogram" be spelled "kiloGram"? [12:00:52.0828] if it was a JS API? probably [12:01:03.0838] nooooo [12:01:14.0277] we use camel case when it's two words [12:01:21.0453] but "micro" is a prefix, not a new word [12:01:47.0696] `setTimeOut` [12:03:47.0535] Feedback about WebEx: much better than zoom [12:04:04.0285] i liked how it had a light mode [12:04:07.0488] down with dark mode!! [12:04:11.0315] much better than I expected, about the same as zoom [12:04:11.0484] please qualify better better. [12:04:11.0796] it is literally indistinguishable afacit [12:04:24.0283] In Zoom I always have audio issues [12:04:30.0244] It never works the first time [12:04:41.0866] is this a zoom problem or is this "year of linux on the desktop" problem [12:04:52.0340] video/screenshare entirely didn't work on firefox for me, so webex is a 👎️ from me [12:05:03.0336] > <@shuyuguo:matrix.org> is this a zoom problem or is this "year of linux on the desktop" problem A year of firefox problem 😛 [12:05:07.0476] it only allowed you to share "apps", not windows, so if I changed which Chrome window was focused, it would share that one instead [12:05:11.0874] IMO the web version was nicer than zoom and thus I had no reason to even attempt to use the native (apropos the parens thingie that was weird) and zoom's native version just takes years off my life [12:05:13.0098] > <@pchimento:igalia.com> video/screenshare entirely didn't work on firefox for me, so webex is a 👎️ from me Oh weird, I had zero problems with it [12:05:25.0322] > <@usharma:igalia.com> IMO the web version was nicer than zoom and thus I had no reason to even attempt to use the native (apropos the parens thingie that was weird) and zoom's native version just takes years off my life Oh yes, I use the web version for both [12:05:31.0690] Long live the web [12:06:16.0136] > <@usharma:igalia.com> IMO the web version was nicer than zoom and thus I had no reason to even attempt to use the native (apropos the parens thingie that was weird) and zoom's native version just takes years off my life but I'd clarify that calling zoom not working hard enough on their linux app a linux problem is unfair [12:06:35.0866] like other native video conferencing apps exist, many of them are electron based and still do a vastly better job [13:17:37.0105] > <@michaelficarra:matrix.org> it only allowed you to share "apps", not windows, so if I changed which Chrome window was focused, it would share that one instead mine, from chrome, let me choose which specific chrome tab i wanted to share [13:17:41.0839] > <@michaelficarra:matrix.org> it only allowed you to share "apps", not windows, so if I changed which Chrome window was focused, it would share that one instead * mine, from chrome, let me choose which specific chrome tab i wanted to share (zoom does also) [13:30:12.0215] I think that's a chrome/chromium-specific feature [16:10:10.0622] > <@bakkot:matrix.org> waldemar: On the topic of RegExp escapes, what escaping do you think we ought to use for null bytes? We have `\0`, but `\x00` is plenty readable, and `\0` has the complication that you can't use it if the next character is an ASCII digit. My inclination is to use `\x00`. I didn't ask that question, but I did notice that non-whitespace control characters weren't escaped. I thought that was deliberate, but escaping them would be a worthwhile change for readability. I agree with `\x00` for the reasons you state. 2024-04-09 [06:52:32.0959] good morning/evening/night everyone! [06:52:36.0888] meeting starts in ~7 [07:29:19.0744] I have trouble understanding the motivation for this null change, but also it doesn't seem harmful [07:29:55.0863] (or rather, I have trouble understanding the motivation for the null skipping in the first place) [07:30:39.0976] Random fact: Babel accidentally ignores `null`s while guaranteeing at least one `await` -- we have a PR open to match the behavior of the current (pre-this-change) proposal [07:35:07.0570] It seems this PR try to avoid nulls introducing extra awaits, am I understanding this correctly? [07:35:17.0535] Yes [07:37:51.0235] this is a small thing, but i'd be interested in people's thoughts on banning `using` inside base switch cases: https://github.com/tc39/proposal-explicit-resource-management/issues/215#issuecomment-2040486653 [07:39:23.0609] Babel's `using` support in `switch` is currently completely broken [07:39:42.0017] Because everything in `switch` is incredibly annoying to compile [07:39:57.0272] i wanna ban it but recognize that'll break symmetry with let/const [07:40:52.0756] Is it for implementation reasons? [07:41:54.0326] it's laid out in the comment -- saves some codegen complexity [07:42:36.0729] we can unroll the dispose loop in all cases except switch cases [07:44:25.0497] I'm trying to think of any usecase for `using` in switch, but I cannot think of any where I would want `using`'s scope to fall through multiple cases [07:46:00.0809] (Babel doesn't unroll the loop anymore, so for us it wouldn't actually be difficult to fix `using` in `switch`) [07:46:39.0248] we don't unroll currently, but would like to [07:50:26.0532] > <@nicolo-ribaudo:matrix.org> I'm trying to think of any usecase for `using` in switch, but I cannot think of any where I would want `using`'s scope to fall through multiple cases The most relevant case I can see would be something like manual loop unrolling, where you skip over the `using` for a chunk of operations when it isn't needed, such as if a lock was needed for a 16k chunk of data that isn't needed for a smaller chunk of data. The point of manual loop unrolling is to avoid a bunch of comparisons and branches based on a single condition such as input size, so a smaller chunk of data skips over the `using` (and avoids the extraneous `null`/`undefined` check), while a larger chunk of data enforces the `using` and holds the lock until the current iteration of the loop ends. [07:52:52.0530] Oh I see, like for transpiling generators [07:53:13.0016] (in a world where generators are transpiled and `using` is not I guess) [07:53:51.0282] ```js for (let start = 0; start < len; start += 8) { switch (start % 8) { case 0: // full chunk, perform lock using lck = new UniqueLock(mut); readByte(); case 1: readByte(); case 2: readByte(); case 3: readByte(); case 4: readByte(); case 5: readByte(); case 6: readByte(); case 7: readByte(); } // lock released if taken } ``` [07:56:40.0590] not for transpiling generators, no. that would be using a `switch` as a finite state machine, but an FSM would result in the `using` terminating early. Loop unrolling in this case is to handle chunks of data without continuously spinning and checking in the `for` to process one element at a time and cutting down the number of comparisons/branching from n to 1/n for a given chunk size of n. [07:58:31.0396] * not for transpiling generators, no. that would be using a `switch` as a finite state machine, but an FSM would result in the `using` terminating early. Loop unrolling in this case is to handle chunks of data without continuously spinning and checking in the `for` to process one element at a time and cut down the number of comparisons/branching from n to 1/n for a given chunk size of n. [08:25:18.0882] If we could get to Ashley's point, he can explain why TLA running eagerly is useful within Bloomberg [08:26:40.0529] tla already can break expectations... [08:29:10.0363] certainly a TLA being added anywhere in your graph is a breaking change [08:29:20.0562] The thing is: in practice, you really shouldn't use JSON or CSS modules either, due to the lack of built-in bundling. The limited utility of built-in modules is not at all limited to this feature [08:29:46.0958] this strongly suggests to me that we need a path to standardize bundler-only syntax [08:29:48.0867] until then, we'll be talking about features that are mostly useful for bundlers and non-web environments [08:29:55.0338] * certainly a TLA being added anywhere in your graph (that's not an entrpoint) is a breaking change [08:30:13.0856] > <@bakkot:matrix.org> this strongly suggests to me that we need a path to standardize bundler-only syntax I disagree; I think we should fix the issues to allow native modules to be usable in browsers [08:30:27.0596] i disagree with that disagree [08:30:32.0747] doesn't seem a good use of resources tbh [08:31:06.0008] > <@littledan:matrix.org> I disagree; I think we should fix the issues to allow native modules to be usable in browsers That is also good! And then, after that, standardizing things like this everywhere instead of bundler-only. But not before that. [08:31:13.0688] these are all arguments against ES6 modules in the first place [08:31:22.0335] *cough* [08:31:31.0248] I mean, yes. [08:31:36.0224] But that ship has sailed. [08:31:45.0035] you're soooo close [08:31:53.0368] bundler-related, but could `import defer` potentially avoid fetch and parse as well if we could serialize the import graph on the server side ahead of time? [08:32:03.0172] In Jack's "assert sync" proposal I suggest we can also add "use async" directive which might help to make TLA explicit. Maybe it also help this issue. [08:32:16.0253] well, yeah, so this would be good input to the module harmony group, if we don't like modules features anymore... [08:32:19.0410] I think standardizing ES6 modules as bundler-only syntax would have been better than the current world [08:32:33.0030] or is that not an option because fetch is async [08:33:28.0283] > <@littledan:matrix.org> well, yeah, so this would be good input to the module harmony group, if we don't like modules features anymore... `import source` is useful on the web! [08:33:45.0613] so it's not "module features" in general, just those specific ones which aren't useful on the web [08:34:11.0898] /me Taking over Chair responsibilities for a bit [08:34:12.0251] (possibly "[...] aren't useful on the web _yet_") [08:34:29.0614] I think the Matrix results show that it's useful on the web *in practice* [08:34:53.0125] It's a good thing that bundlers are aligned to TC39 and browsers in their syntax and semantics. It will be good for us to preserve that. [08:35:07.0286] > <@rbuckton:matrix.org> bundler-related, but could `import defer` potentially avoid fetch and parse as well if we could serialize the import graph on the server side ahead of time? yep. That's what we do at Bloomberg. We find the TLA at build time. And add a simplified module graph of which imports have TLA deps to our equivalent of 'package.json' [08:35:09.0814] IIUC the Matrix results show that it's useful on the web to have bundler-level syntax for this, but not that it's useful to have in browsers, right? [08:35:22.0291] we've made tons of progress by actually building things into JS; the code splitting situation was a mess before import(), and it resulted in code splitting not occurring. [08:35:30.0794] I am not proposing "give up on this"; I am proposing "have a path to standardize bundler-level syntax that isn't actually in browsers" [08:35:40.0746] TC39 is the JavaScript standards committee--our role is to find this common syntax [08:36:27.0193] once we find common syntax, it's OK if some implementations fall behind and don't implement everything, but it'd be a big cost to split the language in two [08:36:33.0100] my response is the thing Shu is saying out loud right now [08:36:54.0555] we should have this as an actual agenda item; that'd make it easier to discuss [08:39:05.0549] IMO Stage 3 serves this purpose of "it's in tools and not necessarily in browsers". Maybe we just want to leave things in Stage 3 for longer. [08:39:36.0712] fwiw eslint refuses to implement features prior to stage 4, though that's maybe a them problem [08:41:07.0294] stage 3 is when it gets shipped in browsers tho [08:41:10.0342] * stage 3 is when it gets shipped in (most) browsers tho [08:42:48.0786] John-David Dalton: why is it disingenuous? this is arguably _better_ handled by tools. tools have a different view (they can see the whole app) and optimization opportunities than a VM [08:43:14.0638] we designed a super static module system. it is not surprising to me that it has been leveraged to success with ahead-of-time tooling [08:44:10.0049] > <@bakkot:matrix.org> fwiw eslint refuses to implement features prior to stage 4, though that's maybe a them problem well, there's babel-eslint [08:46:23.0828] (`@babel/eslint-parser` as of babel 7) [08:47:03.0198] > <@ljharb:matrix.org> stage 3 is when it gets shipped in (most) browsers tho IMO browsers *should* ship features like this at that point, but if they want to leave some features out of browsers for now (but we still assess that the feature is solid enough for Stage 3), maybe they can just let them sit in that bucket. Doesn't require holding back 2.7 or 3. [08:47:22.0696] > <@ljharb:matrix.org> stage 3 is when it gets shipped in (most) browsers tho * I'd be happiest if browsers ship features like this at that point, but if they want to leave some features out of browsers for now (but we still assess that the feature is solid enough for Stage 3), maybe they can just let them sit in that bucket. Doesn't require holding back 2.7 or 3. [08:47:33.0695] 3 is a pretty clear signal, that's the big purpose of 2.7. i agree it wouldn't require holding back 2.7 [08:48:23.0429] so is this feature going to encourage the dreaded "barrel" module pattern? [08:48:36.0398] > <@michaelficarra:matrix.org> so is this feature going to encourage the dreaded "barrel" module pattern? it's about optimizing the feature--no encouragement is needed [08:48:44.0114] While that's technically true, I would be happier revising our process if we want to do that - I would prefer that stage 2.7/3 be taken as a commitment from browsers to implement a feature at some point. I don't want to get to a point where browsers allow features to reach 2.7 that they intend to never implement. [08:49:04.0020] agree [08:49:09.0469] the two design spaces are honestly different [08:49:14.0285] the constraints are different [08:49:17.0420] > <@michaelficarra:matrix.org> so is this feature going to encourage the dreaded "barrel" module pattern? oof, i hadn't thought about that. [08:49:29.0454] > <@bakkot:matrix.org> While that's technically true, I would be happier revising our process if we want to do that - I would prefer that stage 2.7/3 be taken as a commitment from browsers to implement a feature at some point. I don't want to get to a point where browsers allow features to reach 2.7 that they intend to never implement. ah OK well I'm happy to get browser commitments like that; I don't want to discourage that. I haven't thought this through enough. [08:49:54.0372] > <@littledan:matrix.org> it's about optimizing the feature--no encouragement is needed well it doesn't provide any benefit to those not using the pattern, so it seems like encouragement to use it [08:50:06.0567] littledan: i have been thinking about for most of this year, i'll give you something more thought out soon [08:51:05.0282] > <@michaelficarra:matrix.org> well it doesn't provide any benefit to those not using the pattern, so it seems like encouragement to use it I think you're overthinking it... there's a lot of existing usages of this pattern, and it's slow, and it is hard to migrate away from (a lot of effort has gone into this migration) [08:51:20.0789] it's not about newly incentivizing usage [08:51:54.0139] so someone who wants to get similar tree-shakeability can just dump this pattern? [08:52:24.0635] > <@michaelficarra:matrix.org> so someone who wants to get similar tree-shakeability can just dump this pattern? sure, if you can get all your dependencies to dump this pattern, then you'll have no reason to use this pattern in your dependency tree [08:52:44.0025] > <@michaelficarra:matrix.org> so someone who wants to get similar tree-shakeability can just dump this pattern? * sure, if you can get all your dependencies to dump this pattern, then you'll have no reason to use this feature in your dependency tree [08:52:59.0639] there's a growing group of vocal folks in the ecosystem telling people to get rid of barrel modules, fwiw [08:53:18.0876] (coinbase's RN app's binary size dropped 71% when we banned barrel exports) [08:53:40.0499] * (coinbase's RN app's binary size dropped 71% when we/they banned barrel exports back in 2021) [08:53:52.0538] > <@ljharb:matrix.org> there's a growing group of vocal folks in the ecosystem telling people to get rid of barrel modules, fwiw yes, they're doing good work; I think those two groups (the ecosystem effort and this proposal) should be understood to be supporting each other [08:54:42.0621] even with import defer, barrel exports will still result in a larger app than "just import what you need directly", no? [08:54:53.0357] I don't think "this feature is not useful in browsers" is a new category of objection? [08:54:57.0161] that's like... the main objection [08:55:03.0284] can someone remind me why people ever did that in the first place? [08:55:23.0889] i don't know why people tend to like "god objects" [08:55:44.0526] * i don't know why people tend to like "god objects", deep imports is The Way [08:55:53.0557] * i don't know why people tend to like "god objects", deep imports is The Way. but they do tend to like them. [08:56:02.0865] maybe the pattern was copied from python modules and `__init__.py`? [08:56:08.0294] > <@michaelficarra:matrix.org> can someone remind me why people ever did that in the first place? I always understood it to be a response to named exports being a thing, making use of that syntactic space, whereas require returning a single function was more natural [08:56:16.0208] i've seen people have a visceral preference for one `import` keyword that has N identifiers, instead of N `import` keywords [08:56:44.0865] > <@bakkot:matrix.org> that's like... the main objection yeah i feel like most of our concerns that have caused feature compromises and redesigns boil down to this. sometimes it's couched in more specific terms, like "performance footgun" etc [08:56:59.0201] I'm finding it very hard to find sympathy for these people... [08:57:00.0961] also i think that a number of major IDEs implemented auto-refactoring features for named exports but ignored default exports [08:57:06.0477] * also i think that a number of major IDEs implemented auto-refactoring features for named exports but ignored default exports (for no technical reason) [08:57:15.0173] * also i think that a number of major IDEs implemented auto-refactoring features for named exports but ignored default exports (for no technical reason) which drove increased usage of named exports [08:57:26.0804] > <@michaelficarra:matrix.org> I'm finding it very hard to find sympathy for these people... why does it matter whose fault this is? it's currently a performance issue, and this is a solution. [08:58:01.0118] but is "don't use barrel files" perhaps a better solution? [08:58:08.0095] * but is "don't use barrel files" perhaps a better solution? (genuine question) [08:58:53.0606] Barrels are so convenient, and so awful for performance (both browsers and bundlers) [08:58:56.0043] I dunno, there's a lot of recommendations about performance that people aren't taking up... [08:59:24.0498] @guybedford:matrix.org Your mic is echoing [08:59:47.0003] but wouldn't this be a recommendation for performance in exactly the same way? it requires work to adopt; it doesn't just give you performance for free [08:59:59.0606] sorry guybedford bad timing [09:00:06.0237] Timebox! [09:00:09.0827] and if the people in question were willing to do work to get performance they already can already do so, right? [09:01:13.0988] @nicolo-ribaudo:matrix.org your async feedback from me is that, for now, I'm unconvinced by the motivation [09:01:30.0332] > <@jridgewell:matrix.org> Barrels are so convenient, and so awful for performance (both browsers and bundlers) convenience often makes for better paving than good intentions [09:01:48.0748] > <@bakkot:matrix.org> but wouldn't this be a recommendation for performance in exactly the same way? it requires work to adopt; it doesn't just give you performance for free The uptake is a "semver-minor" change--it doesn't require that importers update [09:02:09.0563] > <@jridgewell:matrix.org> Barrels are so convenient, and so awful for performance (both browsers and bundlers) * convenience often makes for better road-paving than good intentions [09:03:04.0365] so importers keep thinking they're doing a fine thing, when they're doing a horrible thing, and the entire ecosystem has to move to `import defer` to avoid the education problem? [09:03:41.0791] education's super hard so maybe that's the right tradeoff to make, tbf [09:10:02.0762] > <@bakkot:matrix.org> but wouldn't this be a recommendation for performance in exactly the same way? it requires work to adopt; it doesn't just give you performance for free It moves the changes from the consumers to the library itself [09:10:08.0224] So 1 instead of N [09:10:47.0173] > <@ljharb:matrix.org> so importers keep thinking they're doing a fine thing, when they're doing a horrible thing, and the entire ecosystem has to move to `import defer` to avoid the education problem? There is currently a choice to make between convenience and performance, and the goal here is to not make them exclusive [09:43:07.0539] does using `import defer` on a barrel file with a bundler that supports it give the ~same results as using deep imports in the first place? [09:43:31.0739] * does using `import defer` on a barrel file with a bundler that supports it give the ~same results as using deep imports in the first place? because treeshaking so far still doesn't fully achieve "only importing what you need in the first place" afaik. [09:46:05.0602] in a language without so many hidden effects all over the place, it would be [09:49:25.0896] > <@ljharb:matrix.org> does using `import defer` on a barrel file with a bundler that supports it give the ~same results as using deep imports in the first place? because treeshaking so far still doesn't fully achieve "only importing what you need in the first place" afaik. Sorry no, it's `export defer`/`export optional` that helps with barrel files [09:49:50.0264] And `export defer` would have the same result as using deep imports [09:50:02.0350] ok, so that's a compelling argument in favor of that one [09:51:34.0893] so `import defer` would be to lessen the downside of importing a barrel file that did not use `export defer`? [09:52:04.0637] And the boundary is still at the `export defer` level, so if you do ```js // main.js import { x } from "library; // library export defer { x, y } from "./x-and-y"; export defer { z } from "./z"; // library/x-and-y export const x = 1; export const y = 2; ``` it will also load `y` (so it's not complete dead code elimination), but gives the building block to remove code if you put unrelated code in separate modules [09:52:09.0264] * And the boundary is still at the `export defer` level, so if you do ```js // main.js import { x } from "library"; // library export defer { x, y } from "./x-and-y"; export defer { z } from "./z"; // library/x-and-y export const x = 1; export const y = 2; ``` it will also load `y` (so it's not complete dead code elimination), but gives the building block to remove code if you put unrelated code in separate modules [09:52:39.0112] * And the boundary is still at the `export defer` level, so if you do ```js // main.js import { x } from "library"; // library export defer { x, y } from "./x-and-y"; export defer { z } from "./z"; // library/x-and-y export const x = 1; export const y = 2; ``` it will also load/run the code for `const y = 2` (so it's not complete dead code elimination), but gives the building block to remove code if you put unrelated code in separate modules [09:52:55.0016] Exactly like deep imports [09:53:14.0206] > <@ljharb:matrix.org> so `import defer` would be to lessen the downside of importing a barrel file that did not use `export defer`? `import defer` is not really related to barrel file [09:53:28.0915] It's in general for "big modules subgraphs" [09:53:40.0275] Even if you have a file with a single export but many dependencies, `import defer` is useful there [09:54:00.0084] One thing that's important to understand is, the barrel file stuff doesn't relate to the motivation for `import defer`--they solve for totally unrelated issues, just both about loading less code [10:14:46.0864] Agree with the various arguments for minimalism here, we just don't have any reason to go into this fractional stuff or BigInts, and IsSafeInteger is a good test. [10:16:38.0985] I agree with Kevin that this isn't especially confusing [10:17:57.0970] * ~~Agree with the various arguments for minimalism here, we just don't have any reason to go into this fractional stuff or BigInts, and IsSafeInteger is a good test.~~ I don't have a strong opinion about any of this and am just happy for range to happen [10:18:06.0226] is there maybe justification to have this produce its own iterator subclass that can have optimised helpers implemented on it? [10:18:33.0888]