01:23:46  * keith_millerjoined
02:37:20  * araiquit (Ping timeout: 276 seconds)
03:03:32  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:31:45  * jmdyckquit (Ping timeout: 260 seconds)
03:32:57  * jmdyckjoined
03:46:55  * jmdyckquit (Remote host closed the connection)
04:27:14  * aki_joined
04:28:07  * akirosequit (Ping timeout: 245 seconds)
05:39:05  * araijoined
06:40:22  * araiquit (Remote host closed the connection)
06:49:22  * araijoined
06:54:10  * araiquit (Ping timeout: 260 seconds)
07:33:36  * araijoined
07:37:42  * araiquit (Ping timeout: 245 seconds)
07:39:53  * araijoined
07:47:38  * araiquit (Remote host closed the connection)
08:22:55  * araijoined
08:27:47  * araiquit (Ping timeout: 276 seconds)
08:38:37  * araijoined
08:46:24  * araiquit (Remote host closed the connection)
09:54:13  * araijoined
09:59:20  * araiquit (Ping timeout: 276 seconds)
10:21:03  * araijoined
10:25:08  * mylesborinsquit (Quit: farewell for now)
10:25:34  * araiquit (Ping timeout: 264 seconds)
10:25:38  * mylesborinsjoined
10:30:37  * araijoined
10:35:11  * araiquit (Ping timeout: 276 seconds)
13:02:05  * jmdyckjoined
13:22:19  * howdoiquit (Quit: Connection closed for inactivity)
15:13:11  * zenparsingjoined
15:16:22  <zenparsing>I'm trying to remember why the Await macro creates a fresh promise via NewPromiseCapability instead of using PromiseResolve (and potentially skipping a promise creation). Any ideas?
15:17:05  * chalkerjoined
15:23:41  <TabAtkins>Presumably to avoid accidentally exposing expandos on the awaited promise?
15:24:15  * keith_millerjoined
15:24:58  * chalkerquit (Ping timeout: 264 seconds)
15:29:06  * keith_millerquit (Ping timeout: 265 seconds)
15:50:20  * gibson042quit (Ping timeout: 276 seconds)
15:51:30  * gibson042joined
16:34:58  * keith_millerjoined
17:14:39  * vikashlquit (Remote host closed the connection)
17:34:14  * mmurryjoined
17:43:16  * aki_changed nick to akirose
17:47:47  * akirosechanged nick to aki_
17:51:00  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:52:08  * vikash-afkjoined
17:56:14  * aki_changed nick to akirose
18:16:16  * jwaldenjoined
18:45:53  <littledan>zenparsing: Funny you mention that, actually some people are looking into proposing that change. It seems to be more intuitive to not insert an extra two microtask queue delays for each await of a promise, and in prototype implementations, it seems to get a pretty good performance boost
18:46:30  * keith_millerjoined
18:47:15  <zenparsing>it was brought to my attention by a dev on the chakra team
18:48:09  <zenparsing>I'm assuming that the intention was to (a) always call "then" and (b) ensure that "then" is called with a fresh stack. I also think it might be worthwhile to reexamine.
19:51:24  * jwaldenquit (Quit: brb)
20:06:23  * jwaldenjoined
20:24:39  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:25:41  * keith_millerjoined
20:31:47  * jwalden_joined
20:34:33  * jwaldenquit (Ping timeout: 264 seconds)
20:34:41  * jwalden_changed nick to jwalden
20:39:27  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:02:27  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
21:58:02  * keith_millerjoined
22:00:09  * keith_millerquit (Read error: Connection reset by peer)
22:00:13  * keith_mi_joined
22:12:13  <zenparsing>littledan: feel free to loop me into those "await" conversations :)
22:40:04  * jwaldenjoined
22:48:26  <littledan>zenparsing: Great, if you could send me the email address of the chakra dev(s) who are interested I can try to loop you both in
22:48:44  <littledan>PromiseResolve would achieve that goal just as well
22:48:59  <littledan>I thought the goal was about making a predictable number of microtask queue items. However, the current spec is way more than you'd ever expect
22:49:22  <ljharb>with using PromiseResolve, would it still always ensure at least one tick, including with `await somePrimitive`?
23:06:29  <bradleymeck>littledan: i wouldn't encourage reliably microtask queue counts, node has seen optimizations change them over time. i'd actually prefer a better explanation of this optimization behavior but 🤷 we get issues from time to time on exact ticks changing as Promises adopt eachother's state
23:07:35  <littledan>Well, the current specification implies specific tick counts. Personally I wouldn't mind weakening that, but I was under the impression that some felt strongly about reliability here.
23:08:13  <bradleymeck>littledan: I think the opposite is more true
23:09:07  <littledan>You mean you oppose the current specification's specificity? Sounds like we have people on both sides then
23:10:20  <bradleymeck>i need to dig up the conversation that I'm looking for about optimization but https://github.com/nodejs/node/issues/12356 was the last major visible thing that brought this up
23:11:06  <ljharb>test262 should be verifying precise tick counts.
23:11:11  <ljharb>the promise finally tests do, for example.
23:12:01  <bradleymeck>i'm not convinced of the value of precise ticks
23:12:25  <bradleymeck>ensuring 1+ ticks occur vs exactly n ticks seems the sides of debate on this
23:12:41  <ljharb>it's important that the spec be explicit, otherwise implementations will vary
23:13:01  <bradleymeck>i think variance here is actually a potential good thing
23:13:30  <bradleymeck>the fewer ticks we waste adopting state, the fewer things like async hooks for node need to be fired
23:13:49  <ljharb>users need to be able to write code that works on every JS engine the same, even if async_hooks is only in node
23:14:09  <ljharb>at least, if it's observable, then it needs to be exact - if it's unobservable then the spec doesn't need to require it
23:14:24  <bradleymeck>ljharb: i think users explicitly declaring their dependence for timing rather than knowing number of ticks is going to lead to better results
23:14:54  <bradleymeck>if number of ticks becomes reliable then libraries and hosts need to stay at the same tick count to be considered reliable
23:15:17  * araijoined
23:15:39  <bradleymeck>because like that issue above shows, they will try to judge how many ticks occur between their calls just by doing counting, which allows harder to enforce implementation guarantees for hosts
23:15:48  <bradleymeck>and fewer chances to drop unneeded ticks
23:16:12  <ljharb>it is already reliable, per spec, and yes, they all need to stay at the same tick count
23:16:16  <bradleymeck>i explicitly don't want hosts to have to keep exact tick counts as they evolve their implementations
23:16:27  <bradleymeck>i disagree and engines aren't giving reliable tick counts
23:16:28  <ljharb>i think the value of preventing variance is higher than the value of potential optimizations
23:16:52  <bradleymeck>i think exposing implementation details of number of ticks for things you call is a bad idea
23:17:01  <bradleymeck>it leads to bugs and fragility
23:18:05  * araiquit (Client Quit)
23:18:14  * araijoined
23:18:35  <ljharb>i guess i'm coming from the opposite perspective, which is that the implementation details being allowed to vary has caused bugs and fragility across browsers, and locking everything down fixes that
23:18:45  <ljharb>like object key ordering, and everything in annex b, eg
23:19:28  <bradleymeck>i'm coming from the host perspective where we would be tied to problems of ordering of ticks if people rely on how long it takes our functions to run in the microtask queue
23:19:44  <bradleymeck>we couldn't add/remove ticks without it being a major bump
23:20:43  <bradleymeck>if there were clear reasons why not to await timing of an implementation instead of queueing "n number of ticks" i could see where variance would be bad
23:21:19  <bradleymeck>but for now, I don't see how relying on the number of ticks is getting us anything except fragility of relying on timing info that I see as leaking out of implementations.
23:21:50  <ljharb>timing info is part of the spec for promise tho
23:21:59  <bradleymeck>it isn't how engines work tho
23:22:01  <ljharb>so it's not leaking, it's intentionally locked down
23:22:17  <bradleymeck>i disagree and think Domenic could comment on this better than I
23:22:31  <bradleymeck>i think "intentionally" might be subject to debate
23:23:03  <bradleymeck>written that way in current spec text, I agree that there is a specified timing
23:23:45  <littledan>I think we can do both things--eliminate many meaningless ticks while maintaining a precise tick count
23:23:49  <bradleymeck>I'm just stating having a weaker timing would match engines, remove people relying on internal details of things, and allow for refactoring of things with lighter timing oncstraints
23:24:31  <bradleymeck>littledan: if we can do that it would be ideal, but I still have concerns about leaking internal implementation details of how many ticks it takes library version 1 to do something versus library version 2
23:24:45  <bradleymeck>where 1->2 could be a bugfix version that added a tick
23:24:54  <littledan>We're just talking about the JS standard itself
23:25:12  <littledan>It's observable no matter how much nondeterminism we put in the spec
23:25:27  <littledan>Due to good test262 tests, many engines are actually correct on tick counts
23:25:37  <bradleymeck>littledan: observable and reliable/precise are different to me in this area
23:26:05  <littledan>I agree that, as a library author, it is not important to maintain a tick count
23:26:11  <bradleymeck>in particular I worry because it makes libraries have reliable numbers of ticks
23:26:22  <bradleymeck>if it is observable people will try to rely on it
23:26:27  <bradleymeck>hence that node issue above
23:26:34  <littledan>I don't think refusing to write down details in a spec makes things less reliable/observable
23:27:02  <devsnek>whats the original scope here? how many ticks `await` takes?
23:27:05  <littledan>As much as I agree with you from a design perspective
23:27:20  <littledan>devsnek: yes, basically
23:27:23  <devsnek>i've seen people do `await 'next tick'`
23:27:46  <bradleymeck>devsnek: that just waits for a new tick, not necessarily the next one
23:27:50  <littledan>devsnek: that would keep working
23:28:29  <zenparsing>devsnek: `await Promise.resolve(1)` creates 3 jobs, whereas we think maybe it should create only 1
23:28:58  <devsnek>so like if engines should be allowed to fold those as an optimisation
23:29:13  <devsnek>that seems like a pretty sane thing to allow
23:29:21  <bradleymeck>well not in the original topic, the original was changing the spec explicitly
23:29:47  <bradleymeck>but i think relying on ordering is troublesome for hosts/libraries
23:29:53  <bradleymeck>excluding the optimization concerns
23:29:57  <zenparsing>devsnek: they can't currently, because user code can interleave jobs between those 3 and observe them
23:30:22  <zenparsing>(can't currently optimize away the extra jobs)
23:30:48  <devsnek>like relying that that async function's completion will be pushed back an extra n ticks
23:31:20  <devsnek>that seems dangerous
23:31:27  <bradleymeck>if i had a clearer understanding of why we should guarantee the ordering vs telling people to use `await` or similar to guarantee *an* ordering I would be fine keeping it ordered, but I don't think having a specific ordering is getting us valuable things right now and might cause me to have headaches for things like using `await`
23:32:10  <bradleymeck>a lot of my vision is to have JS be a robust language for hosting environments/platforms, and this seems a behavior that makes that harder
23:35:57  <bradleymeck>we could tell hosts to produce indeterminate number of ticks / pauses before queueing ticks to get the ordering variance to alleviate reliance on these but I just don't see the actual gain to be given to people producing es hosts implementations, library authors, or to some extent application authors
23:41:34  <littledan>bradleymeck: I'm not the person to argue with here; in past conversations, IIRC, Mark Miller and Domenic were more opinionated, but maybe I'm remembering wrong
23:41:53  <littledan>I just think we can get our work done within this framework, either way
23:43:44  <ljharb>fewer ticks sounds great to me, regardless