| 13:47 | <ystartsev> | heads up everyone, notes go up tomorrow |
| 13:47 | <ystartsev> | please make sure you reviewed them |
| 15:35 | <shu> | akirose: bterlson: MylesBorins: do any of you know how i get write access to the TC39 calendar? |
| 15:37 | <MylesBorins> | I don |
| 15:37 | <MylesBorins> | 't |
| 15:37 | <MylesBorins> | but can ping chairs |
| 15:50 | <shu> | ty |
| 16:30 | <ystartsev> | shu: i will give it to you |
| 17:06 | <shu> | ystartsev: littledan: MylesBorins: i'll try to write up a document laying out participation expectations of champion group, core stakeholders, and non-core stakeholders for these calls |
| 17:06 | <MylesBorins> | thanks |
| 17:06 | <shu> | for us to iterate on, that is |
| 17:07 | <littledan> | good idea |
| 17:07 | <littledan> | maybe in the how-we-work repo? |
| 17:07 | <shu> | +1 |
| 17:07 | <MylesBorins> | I think perhaps the problem with how I expressed it was more "lets prioritize based on blockers" not "if this isn't brought up y'all can't say anything later |
| 17:08 | <MylesBorins> | but I'm happy to augment my approach or thinking on these calls if that framing is not productive |
| 17:10 | <ystartsev> | greeat |
| 17:21 | <ystartsev> | great first meeting by the way. Some more concrete feedback from my side: This is just a brain dump of what i was thinking, you can decide if this is realistic or not. Some "structures" i could see making this really useful are the following "types": |
| 17:21 | <ystartsev> | type 1: introduce major changes to the proposal or a new proposal for people to chew on (resource: readme / presentation with usecases and problems solved; expectation: clarifying questions, discussion points identified for new issues, follow on meeting expected), |
| 17:21 | <ystartsev> | type 2: walk through a small set of issues for deep discussion (resources: the set of issues, max 3? max 1?; expectation: feedback per issue / questions and clarifications, follow on meeting expected), |
| 17:21 | <ystartsev> | type 3: identify blockers (follow up meeting after a first meeting, resource: meeting notes + readme, expectation: deep discussion on identified blockers or issues, follow on meeting on this topic not expected), |
| 17:21 | <ystartsev> | type 4: open "lets just talk about whatever comes to mind" (resource: the problem statement; expectation: whatever, no follow on expected). |
| 17:21 | <ystartsev> | My preference would be to focus on one of these, and let stake holders know what is expected (read the explainer plus these issues) so that we don't rehash stuff. Also we should be careful about getting sidetracked -- for example the options bag discussion i think was something that could have been moved to a different forum. |
| 17:22 | <littledan> | I feel like we really didn't do a good job of laying things out in a clear way. I regret the use of everyone's time. |
| 17:23 | <ystartsev> | nah its fine, it was very similar to committee in a way |
| 17:23 | <ystartsev> | plus this is a learning experience, i am really glad we are doing this |
| 17:23 | <littledan> | I'd like to cycle through everyone else's topics before we get back to module attributes |
| 17:23 | <ystartsev> | being the first is pretty hard |
| 17:50 | <shu> | ystartsev: very good feedback, i'll try to incorporate them in the document |
| 17:56 | <littledan> | I do think the original format of doing multiple topics would be best. That's what I've found in outreach group calls |
| 17:56 | <littledan> | Half an hour or 40 minutes could be spent on one "main" topic, with 10-20 minutes on some other topics |
| 17:57 | <littledan> | so those topics where less time is spent may be more of "type 1" and the longer deep dive might be "type 2" for example |
| 17:57 | <littledan> | the agenda can include links to supporting resources for people to prepare, as well as timeboxes |
| 17:58 | <littledan> | I think module attributes needed something of "type 2", but our presentation style was sort of mixed between 1, 2 and 3 |
| 18:02 | <shu> | in general i want the guiding question to always be "would this discussion result in a more polished proposal for committee consideration at large?" |
| 18:08 | <littledan> | hmm, in that case, maybe we should focus on earlier stage proposals |
| 18:08 | <littledan> | module attributes is more in need of debating things out somehow than polishing |
| 18:10 | <littledan> | people have several kinds of disagreements about what the goals shoudl be of things which involve module loading |
| 18:12 | <shu> | littledan: i wouldn't categorically exclude existential disagreements from incubator calls, especially if it's new |
| 18:12 | <shu> | but otherwise i agree, re-raising an existential disagreement is usually not going to be worked through in ~30-40 mins |
| 18:13 | <littledan> | no, I definitely don't want to exclude any concerns people have |
| 18:13 | <littledan> | I'm just thinking, what are the proposals which would benefit from this sort of polishing format |
| 18:13 | <shu> | ah |
| 18:14 | <shu> | thinking on it now, existential disagreements are great to surface, and i hope at the end of the call there is no misunderstanding on what the disagreement is |
| 18:14 | <shu> | i hope to better understand realms in exactly this way, for instance |
| 18:20 | <littledan> | yes, I think it'll be a valuable discussion. At the same time, I've worked for a while with the Realms champions to polish Realms, and I doubt that "more polish" will come out of the discussion. |
| 18:21 | <littledan> | and that's after they have spent years refining the proposal, of course |
| 18:21 | <shu> | i see what you mean, fair enough |
| 18:21 | <littledan> | within the call, we might give guidance to some champion groups about what kinds of polish they should work on before presenting; that's just not the case with these groups |
| 20:34 | <keith_miller> | Am I crazy or is there no apparent reason why iteratorClose checks that the iterator.return function returns an Object? |
| 20:47 | <shu> | you had me at "iteratorClose" |
| 20:48 | <shu> | but let me see |
| 20:55 | <shu> | keith_miller: https://github.com/tc39/notes/blob/master/meetings/2014-06/jun-5.md#closing-iterators and https://github.com/tc39/notes/blob/master/meetings/2014-06/closing-iterators.pdf |
| 20:56 | <shu> | keith_miller: dherman's slide deck suggests the object return type is mainly for symmetry with all other iterator methods |
| 20:56 | <shu> | and i suppose no one objected? |
| 20:56 | <keith_miller> | weird |
| 20:56 | <keith_miller> | ok, w/e |
| 20:57 | <keith_miller> | Seems like that just adds a ergonomics overhead unnecessarily |
| 21:00 | <shu> | actually how do you even get out the final iteration result |
| 21:03 | <ljharb> | keith_miller: iterator return seems like an unnecessary overhead overall ¯\_(ツ)_/¯ |
| 21:04 | <keith_miller> | ljharb: True, for-of is so complicated that it completely blows out all our inlining heuristics... |
| 21:04 | <keith_miller> | So, we never inline anything that has a for-of loop |
| 21:05 | <shu> | dherman's slides also have the original motivation: async |
| 21:05 | <shu> | it concedes return for sync iterators seem not useful |
| 21:05 | <ljharb> | keith_miller: would it also be true to say you don't optimize them either? |
| 21:06 | <shu> | but now i'm just kind of confused how you even observe the returned object in iterator return |
| 21:06 | <keith_miller> | no, they're optimized just they're too big to inline into another function so you'll always make a call to them |
| 21:06 | <ljharb> | keith_miller: ah k |
| 21:06 | <shu> | at least when called as part of an abrupt completion in a loop |
| 21:06 | <keith_miller> | I guess you could say they're not optimized in that we won't infer things for the caller into the for-of loop but that's true for anything we don't inline |
| 21:06 | <ljharb> | gotcha |
| 21:07 | <keith_miller> | shu: You don't other than to ensure it's an object lol |
| 21:07 | <shu> | that is a dumdum |
| 21:07 | <keith_miller> | AFAICT, I could have missed something |
| 21:07 | <shu> | i implemented this too long ago now i don't really remember |
| 21:08 | <shu> | but i do remember being generally confused why it's there |
| 21:08 | <shu> | and how complicated it makes bytecode generation |
| 21:08 | <shu> | like, implicit try-finally around all iterator-protocol iterations, including destructuring |
| 21:08 | <shu> | kinda gross |
| 21:16 | <devsnek> | i really appreciate the existence of "closing-iterators.pdf" |
| 21:17 | <shu> | yes, especially after i recently found out that the link to one of my circa 2016 google sheets presentation is dead |
| 21:17 | <shu> | maybe i should export to pdf for the agenda/notes repos in the future |
| 21:18 | <ljharb> | that seems like a good idea in general |
| 21:18 | <ljharb> | we could probably build a bot to scrape all the slides links after every meeting |
| 21:18 | <shu> | it's possible that that sheets presentation was hosted on my old grandfathered, free gsuite instance |
| 21:18 | <shu> | and that's why it's gone |
| 21:18 | <devsnek> | speaking of bots |
| 21:18 | <devsnek> | i wanted to set up a thing that opens an issue in my engine262 repo every time someone pushes to ecma262 |
| 21:19 | <devsnek> | but that might require setting up a webhook in ecma262 |
| 21:19 | <devsnek> | which seems nasty |
| 21:19 | <ljharb> | it would, but that's not a huge deal |
| 21:19 | <ljharb> | for a known implementation |
| 21:31 | <Bakkot> | or just having a script somewhere which checks the most recent commit every five minutes or whatever |
| 21:31 | <devsnek> | maybe |
| 21:31 | <ljharb> | polling works absent a webhook, true |
| 21:31 | <shu> | yeah the directionality seems wrong, feels weird to have the specs do the pushing |
| 21:31 | <devsnek> | i know gh actions can do cronjob syntax |
| 21:32 | <devsnek> | i'm not entirely sure where to store "latest commit processed" |
| 21:32 | <ljharb> | true, i use one to automatically keep forks up to date |
| 21:32 | <ljharb> | devsnek: make a git submodule, and use its sha as that marker |
| 21:33 | <devsnek> | hm maybe this https://help.github.com/en/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts |
| 21:33 | <devsnek> | i'll into this more after i finish rewriting the parser |
| 21:34 | <Bakkot> | you can also just roll a gcp or aws instance. I have two or three scrapers running like this and they collectively cost me something like $5/yr, I think |