| 00:23 | <Ashley Claymore> | From my July slides, the benefit of caching unsurprisingly increases with the number of keys. Microbenchmark of a perfect sort cache (cache always hit, ~no lookup overhead) based on the shape showed: 3 properties: 0.53 µs → 0.46 µs (12% faster) 16 properties: 0.91 µs → 0.65 µs per composite (29% faster) 250 properties: 10.34 µs → 4.72 µs per composite (54% faster) |
| 00:23 | <Ashley Claymore> | A real cache wouldn't be so perfect, so I wouldn't expect there to actually be a win for the smaller sets of properties |
| 00:25 | <Ashley Claymore> | Talking with keith_miller yesterday, it's a fun one. I suspect people will by far only create smaller keys as those are the core use cases so the caching won't be critical. And if engines don't cache then that may also discourage large keys as would be relatively slow. But if large keys did become common for some reason, then engines would be pressured into optimizing for that case. |
| 00:33 | <bakkot> | Even if large numbers of keys did become common I think the obvious ways for that to happen all start out sorted anyway (e.g. this is what happens if you pass an array), so just handling that specific case probably gets you most of the value |
| 00:52 | <Ashley Claymore> | I've opened https://github.com/tc39/proposal-composites/issues/42 as a place to discuss potential API changes. cc: keith_miller |
| 00:58 | <Rob Palmer> | good morning, all |
| 00:58 | <Rob Palmer> | we're starting in 1 min |
| 01:49 | <peetk> | https://github.com/michaelficarra/michael-tcq/pull/66 |
| 02:12 | <ljharb> | in all seriousness can we please not use teams again? it is consistently the worst available option |
| 02:13 | <Jesse (🇯🇵)> | lgtm ship it |
| 02:18 | <Rob Palmer> | I'm sympathetic to this. In general it is the host that selects the AV system because they must take responsibility for providing the overall end-to-end service, handling in-room amplification and dealing with feedback and linking to sufficient mics. Maybe we could update host.md in how-we-work to express our preferences to influence hosts more explicitly, e.g. "Zoom and Google Meet are normally preferred over Microsoft Teams". |
| 02:20 | <ljharb> | True, but we ask our hosts to do all sorts of things they may not typically do, including not doing NDAs, and this seems like something we can ask for. I’d also phrase it stronger than “preferred”, more like “Teams is strongly discouraged in favor of Zoom or Google Meet” |
| 02:26 | <Rob Palmer> | This seems a good start for the PR. Please go ahead and see what review feedback we get. |
| 02:27 | <Rob Palmer> | Michael Ficarra: could you write your alternative problem framing here |
| 02:31 | <Michael Ficarra> | is "∉" not considered negative? |
| 02:32 | <Michael Ficarra> | the new formalism is more powerful, the mapping can only go one way |
| 02:39 | <Michael Ficarra> | Is our current usage of cover grammars causing readability/writability/implementability difficulties worth investigation and potential churn? In particular, consider the lack of explicit disambiguators (shown to be needed by all implementers), the non-locality of the grammar, and its interdependence with early error prose rather than being self-contained. |
| 02:46 | <Riki (SIE 🇯🇵 Coordinator)> |
The hosts completely understand the frustration, and we agree that Teams is far from ideal 🥲 In response to the point about asking hosts to accommodate TC39’s needs: We’re genuinely sorry about the inconvenience. If there were a way for us to accommodate this request, we absolutely would!! 😭 |
| 02:53 | <ljharb> | oof, good to know. |
| 03:01 | <Michael Ficarra> | "we" being Americans here |
| 03:02 | <Michael Ficarra> | also, I don't see how anyone would be willing to make a legal opinion on the spot on this topic |
| 03:17 | <dminor> | Chris de Almeida: Unfortunately, I think I'll probably be asleep by the time we get to your agenda deadline topic, but fwiw, I'd like to express my support for both making the deadline fall on a consistent day, and for having that deadline not be after working hours on Friday or on the weekend for anybody. |
| 03:19 | <dminor> | Thank you for bringing the topic. |
| 04:04 | <Michael Ficarra> | though of course it'd be great to have all the other iterator helpers on AsyncIterator.prototype in the future! |
| 04:05 | <Jesse (🇯🇵)> | if we want to avoid Friday evening, I might propose Wednesday AoE |
| 04:06 | <Jesse (🇯🇵)> | (Thursday AoE might be Friday evening SoE) |
| 04:08 | <Jesse (🇯🇵)> | (if only there were a datetime library for computing this kind of thing) |
| 04:28 | <Michael Ficarra> | @Christian Ulbrich I believe that's the method you were asking me for at the community event |
| 04:30 | <Michael Ficarra> | (https://docs.google.com/presentation/d/19xEFe4rHPDxpX_ai7dXrYY3wNtgwcsaKV25PwZiml54/edit?slide=id.g3fa9bcbfd42_1_85#slide=id.g3fa9bcbfd42_1_85) |
| 04:41 | <Christian Ulbrich> | Michael Ficarra: I think it is not. I want something, that completes, once from a list of promises any promise resolves to a certain value. |
| 04:43 | <ljharb> | meaning you have a list of promises, and as soon as any of them resolve to a certain value, you want something else to happen? |
| 04:44 | <Christian Ulbrich> | Yes. |
| 04:45 | <Michael Ficarra> | yeah then that's what you want |
| 04:54 | <Christian Ulbrich> | Michael Ficarra: No .asCompleted() returns all Promises in settling order, if I understand the code directly. But I am with you, that the idea is similar, it is a perpetual race with a filter. So I want Promise.raceWithFilter() |
| 04:55 | <Christian Ulbrich> | I think this can be solved with AsyncIterator.filter(). |
| 04:57 | <ljharb> | can someone explain to me why some has to wait until all the maps are done? like why can't it check each value as it settles? |
| 04:57 | <ljharb> | in sync iterators, i thought .map().filter() maps and then filters each value, rather than maps each value and then filters each value |
| 04:58 | <ljharb> | (i can ask this on the queue if it's useful but i assume i'm just missing something) |
| 04:59 | <Michael Ficarra> | yes exactly, await asCompleted(...).filter(x => !x).take(1) |
| 05:01 | <Christian Ulbrich> | Yes. Or Promise.all() with the golden Promise being a rejection :) |
| 05:04 | <Michael Ficarra> | we are over an hour in and we still haven't gotten to the first open question... |
| 05:05 | <Michael Ficarra> | not resolved, gotten to |
| 05:07 | <Ashley Claymore> | It's OK we'll handle the open questions concurrently |
| 05:11 | <Michael Ficarra> | @erights Mark Miller (Agoric) MM you can just press enter after pressing the new topic button if you don't want to (or have time to) type out a topic |
| 05:11 | <Chris de Almeida> | I don't think MM is active here |
| 05:23 | <Chris de Almeida> | I would like to reaffirm my appreciation for TCQ 2000 XP Millennium Edition |
| 05:27 | <Michael Ficarra> | 🤷♂️ I had a lot of time to wait on the queue |
| 05:28 | <Jesse (🇯🇵)> | just open the inspector and do Promise.all() while selecting everyone else's questions |
| 05:59 | <Michael Ficarra> | the support was for distinguishing based on thenableness |
| 05:59 | <bakkot> | great |
| 06:00 | <bakkot> | how do you feel about caching whether the first result was thenable vs checking for every call to .next()? |
| 06:03 | <bakkot> | asCompleted().find(pred) surely |
| 06:03 | <bakkot> | this actually came up on the discourse https://es.discourse.group/t/promise-pick-predicate-based-promise-selection/2496 |
| 06:21 | <Ashley Claymore> | don't we have to check for every call? Or we're assuming that promises only come from async functions and therefore consistent |
| 06:21 | <bakkot> | we would be assuming that it is either an async iterator or a sync iterator and that async iterators always have next() return a Promise |
| 06:22 | <bakkot> | this is admittedly not a totally valid assumption |
| 06:25 | <Ashley Claymore> | my gut is that it's a step too far to avoid the overhead of checking everytime, as the overhead feels very low. But have no data to back that up. |
| 06:27 | <waldemar> | What's the argument against having a deadline on a weekend? |
| 06:28 | <ljharb> | i'm curious about that too |
| 06:34 | <rkirsling> | people have done a terrible job of putting their acronyms on the notes |
| 06:34 | <rkirsling> | this is very hard |
| 06:35 | <Michael Ficarra> | @rkirsling https://github.com/tc39/notes/blob/main/delegates.txt |
| 06:35 | <rkirsling> | yeah lemme juggle that on top of everything else |
| 06:36 | <Michael Ficarra> | Ctrl-PgDn and Ctrl-PgUp is so much easier than scroll-up-to-top and scroll-back-down-to-bottom |
| 06:38 | <rkirsling> | that is true but I just feel overwhelmed the entire time when doing this |
| 06:39 | <Ashley Claymore> | I think we can get acronyms added to TCQ and will help a lot |
| 06:40 | <Andrew Paprocki> | It's the equivalent of "must be postmarked by MM/DD" |
| 06:42 | <Christian Ulbrich> | If you do take notes often, you know the acronyms by heart. |
| 06:42 | <Michael Ficarra> | I am shocked that people do not know what AoE means |
| 06:42 | <Michael Ficarra> | and a lot of people think they know what it means and also do not |
| 06:42 | <Christian Ulbrich> | Area of Effect! |
| 06:43 | <Richard Gibson> | Age of Empires! |
| 06:43 | <Christian Ulbrich> | Always favor AoE spells over targeted ones. |
| 06:43 | <Michael Ficarra> | 🚨👮 #⏱️💀 Temporal Dead Zone 💀⏱️ |
| 06:44 | <waldemar> | This is one of the strangest discussions I've been to in a while… |
| 06:44 | <Michael Ficarra> | I am about to lose it |
| 06:46 | <Michael Ficarra> | @ljharb your TCQ isn't working? |
| 06:49 | <ljharb> | sorry, i decided to reply too quick. will use it next time |