14:59 | <ryzokuken ๐ท๐ธ> | Draft Schedule is up on the Reflector: https://github.com/tc39/Reflector/issues/545 |
16:58 | <Rob Palmer> | The meeting begins in 1 minute!!! |
17:00 | <Michael Ficarra> | FYI we still don't have a TCQ link |
17:03 | <nicolo-ribaudo> | If Google meet is stuck on "Getting ready... You'll be able to join in just a moment", is it a problem on my side? |
17:03 | <ljharb> | https://tcq.app/meeting/RKti |
17:03 | <ljharb> | probably, there's a bunch of us in it |
17:04 | <nicolo-ribaudo> | Ok thanks, time to restart everything |
17:12 | <nicolo-ribaudo> | Chairs, last minute change. It seems like I will be the one presenting the TG4 status report |
17:40 | <littledan> | I like Saminaโs idea to have a liaison from TC39 to IETF, analogous to our close relationship with W3C and Unicode. Is anyone interested in playing this role? |
17:45 | <saminahusain> | In the past, I think 2021, Mathew Miller was the liaison contact from tc39 |
17:49 | <bakkot> | sorry, I forgot to add to the agenda constraints that I'm not available the first hour today |
17:50 | <bakkot> | hope we can get to my iterator closing topic after that |
17:54 | <nicolo-ribaudo> | Did Chris change which diff he's showing? |
17:54 | <Michael Ficarra> | yes |
17:57 | <Michael Ficarra> | whoever is doing notes right now, please refer to https://github.com/tc39/notes/blob/main/delegates.txt for abbreviations, don't just make something up |
18:15 | <Michael Ficarra> | @eemeli please add a link to the slides in the notes |
18:22 | <nicolo-ribaudo> | I always assumed the motivation for this proposal was about ergonomics and not really about performance |
18:27 | <eemeli> | @eemeli please add a link to the slides in the notes |
18:28 | <eemeli> | https://github.com/eemeli/proposal-intl-currency-display-choices |
18:29 | <rbuckton> | We don't throw when you mutate a Map while iterating. I'd almost rather getOrInsertComputed just overwrites the key, whether it was set or deleted during the callback. If you want full locking, you can implement it yourself? |
18:30 | <shu> | rbuckton: that IS my understanding of the non-throwing approach |
18:30 | <shu> | is it not? |
18:31 | <bakkot> | the four options:
sounds like people like option 2 (which I'm also happy with) |
18:32 | <nicolo-ribaudo> | I dislike these names but I have no constructive suggestion |
18:32 | <rbuckton> | I personally prefer getOrAdd /getOrCreate , but I've been too busy over the last few weeks to comment on the issue :/ |
18:33 | <ljharb> | bakkot: option 3 would basically be "actual upsert"? or is that something else |
18:33 | <bakkot> | no |
18:33 | <bakkot> | we're accounting for mutation during the callback |
18:33 | <bakkot> | not passing new values to the callback |
18:33 | <ljharb> | ah k |
18:35 | <rbuckton> | Regarding the naming, neither of these methods are actually an "upsert", which normally consists of either "updating an existing value" or "inserting a new value", hence the portmanteau of "update" and "insert". |
18:45 | <Mikhail Barash> | University of Bergen's students have written a tutorial on upsert proposal prototype implementations in SpiderMonkey and V8. The current preliminary (rough) draft is available here: https://github.com/bldl/emplace-spidermonkey . It currently lacks the description of the implementation in V8; this will be added soon. |
18:47 | <ljharb> | https://github.com/tc39/proposal-is-error/issues/7 |
18:47 | <bakkot> | chairs: can you make sure my "iterator helpers close receiver on argument validation failure (10m, Kevin Gibbons)" topic doesn't get lost? currently it's up with the already-presented items on the agenda |
19:00 | <Aki> | ljharb: reminder to record your summary/conclusion |
19:00 | <Aki> | bakkot: see ๐๐ป |
19:01 | <nicolo-ribaudo> | You can get an AsyncContext candy |
19:58 | <Rob Palmer> | Plenary resumes in one minute! |
20:08 | <nicolo-ribaudo> | Can we get the transcriptioner to disable automatic-newline? |
20:09 | <ryzokuken ๐ท๐ธ> | how bad is it? should I file a POO? |
20:09 | <nicolo-ribaudo> | It's just annoying |
20:09 | <nicolo-ribaudo> | Because if I add a newline anywhere then the line is too short and looks bad |
20:09 | <ljharb> | (also more than one space after a period) |
20:20 | <nicolo-ribaudo> | This note taker is very good |
20:20 | <nicolo-ribaudo> | They are even adding parentheses in function calls |
20:43 | <nicolo-ribaudo> | The results of the temp check are "we should flip a coin" |
20:45 | <bakkot> | I can't speak but note: |
20:45 | <rbuckton> | My concern is that reuse promotes weird corner cases |
20:45 | <bakkot> | this means you can't implement concat with a generator |
20:45 | <rbuckton> | i.e., accessors, proxies, etc. |
20:46 | <shu> | yeah i'm confused by the flipped polarity |
20:46 | <shu> | why are agoric folks okay with concat doing reuse? |
20:46 | <nicolo-ribaudo> | this means you can't implement concat with a generator
|
20:46 | <nicolo-ribaudo> | Since yield* re-uses |
20:46 | <bakkot> | ah, true |
20:46 | <shu> | oh i see |
20:46 | <bakkot> | ok then i am indifferent |
20:46 | <rbuckton> | this means you can't implement concat with a generator yield* |
20:47 | <bakkot> | though return is a little trickier |
20:47 | <rbuckton> |
|
21:00 | <Michael Ficarra> | Since yield* re-uses |
21:02 | <Chris de Almeida> | https://github.com/tc39/proposal-shadowrealm/issues/393 |
21:17 | <nicolo-ribaudo> | waldemar There is also random which is technically I. I guess the actual principle is "web APIs don't expose I/O other than what is already exposed by ECMAScript itself" |
21:28 | <shu> | brother i don't know of any API that doesn't allocate memory |
21:30 | <Richard Gibson> | brother i don't know of any API that doesn't allocate memory destroy() |
21:31 | <shu> | where do you think the stack space needed to push the frames to make the call comes from? |
21:31 | <Richard Gibson> | lol |
21:33 | <Chris de Almeida> | should we consider elaborating on stage 3 acceptance criteria re: tests being merged? |
21:33 | <shu> | Chris de Almeida: i honestly thought that was already the case |
21:33 | <Chris de Almeida> | it's hand-wavy |
21:33 | <shu> | like what's the point of having tests that are floating out there but not merged |
21:33 | <Chris de Almeida> |
|
21:34 | <shu> | sorry, i meant i thought it was the case that being merged is a necessary condition for being considered "sufficient testing" |
21:34 | <shu> | not just that some tests were written, somewhere |
21:34 | <Chris de Almeida> | I understand; the question is, would it help to make the text more explicit? |
21:34 | <ljharb> | i think we've generally considered merging a requirement |
21:35 | <ljharb> | but we also don't usually block advancements on procedural things whose completion is unambiguous - we usually grant conditional advancement pending that thing (a PR review, a PR merge, resolving an open question between known stakeholders, etc) |
21:40 | <Chris de Almeida> | generally speaking, is the status quo that tests have been merged before asking for stage 3? |
21:40 | <ljharb> | for non-large proposals, yes, i believe so |
21:42 | <shu> | i think how much leniency we give definitely will vary case-by-case. in the particular case of ShadowRealms, it got to stage 3 the first time on that promise that the integration work will be done, and the ball got dropped |
21:52 | <bakkot> | ptomato I am happy to open an issue about crypto.subtle somewhere if you'd like. is the shadowrealm proposal the right place for that kind of bikeshedding issue? also if you want to just look at it without bothering with an issue that's fine |
22:10 | <ptomato> | ptomato I am happy to open an issue about crypto.subtle somewhere if you'd like. is the shadowrealm proposal the right place for that kind of bikeshedding issue? also if you want to just look at it without bothering with an issue that's fine |
22:13 | <bakkot> | dminor: mozilla doesn't usually bother with standards-positions on TC39 proposals, yeah? https://github.com/mozilla/standards-positions/issues/1133 |
23:04 | <Michael Ficarra> | sorry, i meant i thought it was the case that being merged is a necessary condition for being considered "sufficient testing" |
23:07 | <Michael Ficarra> | and if someone has reviewed and said "yes, these look both correct and exhaustive to me", then it has met that criterion |
23:15 | <shu> | i'm hoping the delta between that last bit, where someone has reviewed and +1'd it, and merging it into a test suite, is trivial |
23:15 | <shu> | if it isn't then we should rework the test suite workflow |
23:29 | <Michael Ficarra> | well atm the test262 maintainers group holds those keys and they may have additional criteria that they need to review for before it gets merged |
23:37 | <dminor> | dminor: mozilla doesn't usually bother with standards-positions on TC39 proposals, yeah? https://github.com/mozilla/standards-positions/issues/1133 |