| 07:10 | <justingrant> | One of the entrance requirements for Stage 3 is "All ECMAScript editors have signed off on the current spec text". How should champions go about getting that signoff? I'm asking because we're hoping to ask for Stage 3 for proposal-canonical-tz at the July TC39 meeting. For Stage 3 reviewers, I've been creating issues like https://github.com/tc39/proposal-canonical-tz/issues/33 and https://github.com/tc39/proposal-canonical-tz/issues/35. Should I do the same for each of the ECMA-262 editors? Should I open one issue and tag @tc39/ecma262-editors? Something else? |
| 07:17 | <nicolo-ribaudo> | Tagging ecma262-editors is enough to get their attention. I recommend doing it as early as possible to make it easier for them, because reviewing proposals is very time consuming |
| 15:17 | <Michael Ficarra> | justingrant: Yeah, you can simply ping @tc39/ecma262-editors on a tracking issue. Personally, I prefer to review as a PR against tc39/ecma262 (you're going to have to open one eventually anyway), but that's not necessary. |
| 15:20 | <Michael Ficarra> | Every editor call, we check the agenda for proposals marked for advancement to stage 3/4 to prepare for reviews. If a lot of stuff gets added just before the deadline for advancement, it can get pretty hard to get reviews in on time. It's why we've had to do "conditional advancement" a few times, though we'd prefer not to have to do that again. So the earlier you let us know about it, the better. |
| 15:23 | <Michael Ficarra> | Also you can ask us questions any time in #tc39-editors:matrix.org |
| 15:23 | <mgaudet> | question for implementers: the current design of the base64 proposal, in the streaming case, allocations a new Uint8Array window (of a pre-existing buffer) once per chunk. is that actually expensive enough to warrant reconsidering the design? I would have assumed that new views of existing buffers would be cheap |
| 15:35 | <shu> | mgaudet: does SM keep a list of views from each array buffer? perhaps i'm misremembering |
| 15:36 | <mgaudet> | shu: AIUI a hash set, but yes |
| 15:37 | <shu> | that's the thing i wasn't sure is acceptable, not so much the short-lived objects part |
| 15:37 | <mgaudet> | Mostly it should be ok unless we have to resize; but that's the cost of amortized cost data structures |
| 15:49 | <rbuckton> | bakkot, Michael Ficarra: The Async Iterator Helpers proposal uses the term "async method" to allow Await() in its algorithm steps without the heavy lifting of manually writing out interactions with PromiseCapability, but this isn't formalized either in that proposal or in ECMA-262 proper. I've been considering how I could use that to simplify the algorithm steps of AsyncDisposableStack.prototype.disposeAsync(), so I was wondering if any formal description of "async method" had been written yet, since I couldn't find one in https://tc39.es/proposal-async-iterator-helpers/. |
| 16:09 | <Michael Ficarra> | rbuckton: it's here: https://github.com/tc39/ecma262/pull/2942 |
| 16:11 | <rbuckton> | Thanks! |
| 16:12 | <Michael Ficarra> | we're still trying to figure out whether we actually want to allow this form in the spec though: https://github.com/tc39/ecma262/pull/2942#issuecomment-1515412109 |
| 16:13 | <Michael Ficarra> | Shu has some concerns |
| 16:19 | <shu> | i lean towards "this is our (V8)'s problem to solve, not really the spec's", but there's also a principled argument to be made about maximizing interop likelihood for multiple implementation techniques |
| 16:20 | <shu> | there is also some evidence that the act of speccing at the high level of async functions or generators gives rise to blind spots, like in iterator helpers |
| 17:12 | <snek> | time to add await to torque |
| 19:14 | <justingrant> | Also you can ask us questions any time in #tc39-editors:matrix.org |
| 19:15 | <littledan> | Thanks Michael, will do... except I get a "You do not have permission to post to this room" error in Matrix after joining that room. Expected? |
| 19:38 | <Michael Ficarra> | oh, I didn't know that not everyone could post in the editors channel |
| 19:38 | <Michael Ficarra> | I'll see what we can do about that |
| 20:31 | <ljharb> | the original intention was to be just for editors to speak, but i can open it up to anyone easily. to only open it up to delegates would require manually adding everyone, and also updating the onboarding/offboarding templates. |
| 20:34 | <Michael Ficarra> | I would only want delegates. I'll ask the other editors about it during today's call. |
| 20:43 | <bakkot> | probably this is possible to automate |
| 20:44 | <bakkot> | the API is fairly simple |
| 20:59 | <ljharb> | if you can automate it for the delegates channel too, based on the github team, that'd help out a lot :-) |
| 21:03 | <bakkot> | not without a canonical machine-readable mapping between github usernames and matrix handles |
| 21:04 | <bakkot> | given such a thing it's probably easy enough |
| 21:13 | <ljharb> | the info is largely contained in Admin and Business github issues, but it'd be reasonable enough to move it to a file or wiki page or something in that repo |