00:42:10  * gskachkov_quit (Quit: gskachkov_)
02:39:42  * bradleymeckquit (Quit: bradleymeck)
03:16:32  <Domenic>Wow this is not going to be a fun spec to edit anymore :(
03:16:39  <Domenic>Or read the source of
03:30:46  * gskachkov_joined
03:40:54  * jmdyckquit (Quit: Leaving.)
03:41:22  * gskachkov_quit (Quit: gskachkov_)
04:04:47  * not-an-aardvark_joined
04:10:46  * not-an-aardvarkquit (*.net *.split)
04:10:46  * TehShrikequit (*.net *.split)
04:10:54  * not-an-aardvark_changed nick to not-an-aardvark
04:42:05  <ljharb>what's the benefit of linking directly to a step, as opposed to an algorithm with a numbered step? is it just to protect against step reorderings?
04:42:20  <ljharb>(since it wouldn't help with step removals, or many refactors)
05:04:05  * gskachkov_joined
05:08:27  * gskachkov_quit (Ping timeout: 240 seconds)
05:28:50  <Bakkot>ljharb, did you see https://github.com/babel/babylon/issues/440 ?
05:29:24  <Bakkot>(I don't know why I have in my head that you are a person who cares about sourcetype and node + ESM compatibility, but I do, so now you get to be pinged)
05:29:31  <Bakkot>(plz ignore if you do not in fact care)
05:29:49  <ljharb>lol will look shortly
05:40:27  <ljharb>Bakkot: k commented
05:40:50  <Bakkot>thanks!
05:41:14  <Bakkot>I have not been keeping good track of the state of the various grammar proposals.
05:43:27  <ljharb>unambiguous is a nice idea, i like it, but a number of folks were super against it
05:43:43  <ljharb>and jdd really wants it to happen, but shipping it in lodash or eslint won't make it happen ¯\_(ツ)_/¯
05:47:15  <cmatheson>~/exit
05:49:09  <ljharb>error: exit not found
05:50:53  <not-an-aardvark>I think it was supposed to be ~/exit/, which is -1.
05:51:40  <ljharb>:-p
06:02:41  <dilijev>What about per-algorithm unique?
06:03:24  <dilijev>Still handles the ability to reorder steps in an algorithm. Moving the same step to another algorithm wouldn't be meaningful to have the same link. Reduces the need for large numbers.
06:03:27  <ljharb>ooh, that seems much nicer
06:41:24  * gskachkov_joined
06:45:25  * tarjeijoined
06:46:37  <tarjei>Good morning. I'm just wondering if Set.size is a work accident of if it was intended. Since arrays have .length it would have been great to follow that convention.
06:47:03  <ljharb>tarjei: nope, it's intentional and they aren't the same thing
06:47:10  <ljharb>tarjei: "length" would imply it's arraylike. which it isn't.
06:48:19  <tarjei>I can see that, but at the same time you end up increasing the developer overhead since one has to go look up the property
06:48:30  * gskachkov_quit (Quit: gskachkov_)
06:48:43  <tarjei>I just expected all collections to have a length.
06:49:05  <ljharb>theres a ton of differences; you simply can't "not know" if you have an Array, Map, or Set.
06:49:09  <Bakkot>Yes, it's a bit of a tradeoff, but I think it comes out overwhelmingly in favor of not looking arraylike.
06:49:34  <ljharb>really the only thing that's universal between all 3 collections is that they're iterable
06:49:46  <tarjei>Ok, you're the expert :P
06:50:03  * gskachkov_joined
06:50:12  <tarjei>Thank you for taking the time to answering me.
06:51:12  <ljharb>tarjei: np. fwiw, i think it would be nice to be able to take a generic collection - array, map, set, or "other" - and operate on it without knowing which kind it is. but that's not a goal of the current spec, and that'd be a monumental task i think.
06:51:32  <tarjei>It is too late now :P
06:51:58  <tarjei>Oh, and has anyone considered an operation for converting an array to a map? Something like:
06:51:58  <tarjei>myArray.mapToMap(function(item, i) { return [item.id, item] })
06:54:00  <ljharb>if you have an array of entries (like `[key, value]`) you can just pass it into `new Map()`
06:54:13  <ljharb>ie, `new Map([[1, 2], [3, 4]])` gets you a map of 1 → 2, and 3 → 4
06:54:35  <tarjei>duh! I didn't know!
06:54:36  <tarjei>thanks
06:54:56  <tarjei>You just made my day :)
06:55:09  <ljharb>also `Object.entries()` will take an object and give you that array of entries.
06:56:02  <tarjei>Yes, I've used that one a lot :P
06:56:52  <Bakkot>There's actually an annoying subtlety here, which is that Maps consider +0 and '0' to be different keys
06:57:08  <Bakkot>so (new Map(Object.entries(['a', 'b', 'c']))).get(0) will give you undefined
06:57:22  <Bakkot>whereas (new Map(['a', 'b', 'c'].map((v, i) => [i, v]))).get(0) will give you 'a'
06:57:37  <tarjei>wft. Thanks!
06:58:46  <ljharb>well sure but you wouldn't pass an array into Object.entries in the first place; you'd use `new Map(...arr.entries())`
06:58:52  <ljharb>Object.entries is for objects; arrays are special
06:58:59  <ljharb>(conceptually)
06:59:18  <ljharb>* oops, `new Map(arr.entries())`
06:59:22  <tarjei>;)
06:59:26  <ljharb>but i suppose that'd still have the problem where `0` would be a string, not a number
06:59:45  <ljharb>or hmm, maybe not, if the .entries() iterator provides integer indexes
07:00:01  <Bakkot>ah, yes, right
07:00:03  <Bakkot>and yes, it does
07:01:13  <Bakkot>that is, it gives integer indexes
07:02:04  <ljharb>sweet, that's what i'd expect
07:02:28  <Bakkot>.entries() also works better with holey arrays, looks like.
07:02:39  <Bakkot>because .map skips holes.
07:02:52  <ljharb>dense or bust
07:03:03  <Bakkot>So! `new Map(ar.entries())` is definitely the thing to do to get the behavior you'd expect.
07:03:20  <Bakkot>unless you expect the resulting map to not have keys for holes.
07:03:38  <Bakkot>I don't know if anyone really has intuitions about the behavior of arrays with holes though.
07:04:21  <Bakkot>for my part, my intuition about holey arrays that my arrays should not have holes.
07:20:31  <ljharb>that is mine as well
07:22:17  <tarjei>Again, thanks a lot for the tips. I also note that Map.length always is 0.
07:22:41  <tarjei>According to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
07:23:11  <ljharb>tarjei: Map.length is 0 because Map is a function that has 0 required arguments
07:23:44  <tarjei>ah! But new Map().length is undefined
07:23:55  <tarjei>My bad.
07:24:30  <ljharb>correct
07:35:47  <dilijev>another way to think about the difference between length and size is that length is an own property of an array, but size is a getter of Map and Set's prototypes
07:36:24  <ljharb>array length is exotic tho, so it's a bit weird
07:42:15  <dilijev>as a mental model, just another part of arrays being special
07:42:26  <dilijev>for the spec and implementation, that's a bit more important
07:42:36  <dilijev>imo
07:45:34  <dilijev>unless i'm missing something important from a js perspective
07:45:40  <dilijev>mental-model wise
10:10:04  * tcarequit (Quit: Connection closed for inactivity)
10:18:52  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:26:08  * mylesborinsquit (Quit: farewell for now)
10:26:38  * mylesborinsjoined
11:07:52  <annevk>I'm guessing most folks here are aware of the cancelable fetch thread. Since there's other interested consumers, there's a proposal floating around to make it more generic: https://github.com/whatwg/dom/pull/434. I pinged aklein already, but others might want to take a look too.
11:33:13  * jmdyckjoined
11:52:02  * gskachkov_quit (Quit: gskachkov_)
11:54:54  * tarjeiquit (Quit: Leaving.)
11:59:33  * gskachkov_joined
12:07:49  * sebmckjoined
12:33:24  * bradleymeckjoined
12:34:15  * bradleymeckquit (Client Quit)
12:43:34  * bradleymeckjoined
12:50:56  * bradleymeckquit (Quit: bradleymeck)
13:17:59  * bradleymeckjoined
14:11:38  * jeffmoquit (Ping timeout: 255 seconds)
14:13:00  * jeffmojoined
14:17:02  * ErikCorryquit (Ping timeout: 255 seconds)
14:17:46  * Havvyquit (Remote host closed the connection)
14:18:18  * Havvyjoined
14:19:19  * ErikCorryjoined
14:25:40  <TabAtkins>Domenic: All it means is that the algo steps will sprout a tiny `{#s-NN}`prefix after the step number. Hardly something to make the spec "unfun to edit".
14:28:44  <Domenic>I can only speak for myself, but that definitely would make it unfun for me
14:32:19  * Fishrock123joined
14:47:16  * gskachkov_quit (Quit: gskachkov_)
14:56:16  <annevk>When are these added?
15:08:40  <jmdyck>is adding them to master going to cause conflicts for every pending PR?
15:10:37  <jmdyck>maybe not every PR, but any PR with changes in or near an algorithm?
15:23:37  * jmdyckquit (Ping timeout: 268 seconds)
15:26:04  * jmdyckjoined
16:10:16  * sebmckquit (Ping timeout: 246 seconds)
16:14:48  * not-an-aardvarkjoined
16:18:16  * Fishrock123quit (Quit: Leaving...)
16:22:25  * bradleymeckquit (Quit: bradleymeck)
16:22:31  * Fishrock123joined
16:44:13  * gskachkov_joined
16:48:01  * bradleymeckjoined
16:54:12  * gskachkov_quit (Quit: gskachkov_)
17:07:32  * gskachkov_joined
17:07:47  <bterlson>jmdyck: it'll be a pain, but I'm pretty good with resolving these kinds of conflicts by now
17:08:58  <bterlson>Domenic: just to be clear are you thinking that the editing downsides outweigh the benefits of having every step linkable?
17:09:18  <bterlson>or are you just wishing we had a better way
17:09:59  * gskachkov_quit (Client Quit)
17:11:34  * gskachkov_joined
17:11:45  <bterlson>annevk: is there a higher level write up of this? It smells like cancellation tokens with a different name but I haven't looked deeply yrt
17:13:01  <annevk>bterlson: maybe in https://github.com/whatwg/fetch/issues/447
17:13:14  <annevk>bterlson: no easy tl;dr though
17:13:29  <annevk>bterlson: it kinda is like that
17:13:48  <annevk>bterlson: not sure how different or if
17:23:28  * tcarejoined
17:26:57  * bradleymeckquit (Quit: bradleymeck)
18:44:48  * rbucktonjoined
18:44:55  * sebmckjoined
18:45:27  * rbucktonquit (Client Quit)
18:50:37  * rbucktonjoined
18:54:21  * rbucktonquit (Client Quit)
18:57:09  * rbucktonjoined
19:01:28  * gskachkov_quit (Quit: gskachkov_)
19:01:38  * rbucktonquit (Client Quit)
19:03:05  * gskachkov_joined
19:03:34  * ronbucktonjoined
19:04:14  * bradleymeckjoined
19:06:00  * ronbucktonchanged nick to rbuckton
19:07:17  * ronbucktonjoined
19:10:33  * rbucktonquit (Ping timeout: 260 seconds)
19:10:43  * ronbucktonchanged nick to rbuckton
19:11:49  * gskachkov_quit (Quit: gskachkov_)
19:12:28  * ronbucktonjoined
19:13:09  <ronbuckton>bterlson brought https://github.com/whatwg/dom/pull/434 to my attention. It looks like WHATWG needs cancellation for asynchronous operations.
19:14:33  <annevk>ronbuckton: indeed, posted that here a lil earlier today
19:15:04  * rbucktonquit (Ping timeout: 246 seconds)
19:15:14  * ronbucktonchanged nick to rbuckton
19:16:16  * gskachkov_joined
19:16:56  <annevk>Thoughts welcome there and in private; we'll likely move somewhat quicker now after having waited for a long time
19:18:19  * ronbucktonjoined
19:18:27  <ronbuckton>A year ago I created the "prex" library to provide a number of asynchronous coordination primitives, partly as a means to illustrate possible future proposals for ECMA262. I wanted to bring up https://github.com/rbuckton/prex/blob/master/docs/cancellation.md as a possible topic (assuming my mobile hotspot stops dying on me repeatedly)
19:19:49  * rbucktonquit (Ping timeout: 260 seconds)
19:19:55  * ronbucktonchanged nick to rbuckton
19:20:40  * rbuckton2joined
19:22:22  <rbuckton2>unfortunately it seems my hotspot is a lost cause
19:24:44  * rbucktonquit (Ping timeout: 268 seconds)
19:26:35  * ronbucktonjoined
19:26:35  * ronbucktonchanged nick to rbuckton
19:28:53  * rbuckton_joined
19:29:39  * rbuckton2quit (Quit: Page closed)
19:31:05  * rbucktonquit (Ping timeout: 260 seconds)
19:32:50  <rbuckton_>I'm going to give webchat a try, and hopefully my hotspot won't continue to freak out on me.
19:34:23  <bterlson>rbuckton_: godspeed sir
19:34:55  <rbuckton_> With regards to cancellation. I am concerned that the WHATWG implementation, while good for the web, may not translate well into other host environments like NodeJS.
19:34:59  * rbuckton_changed nick to rbuckton
19:35:14  <bterlson>bradleymeck: ^
19:35:29  * bradleymeckperks up
19:35:44  * sebmckquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:35:44  <bradleymeck>not up to date on what the WHATWG is doing
19:37:51  <rbuckton>The current PR for WHATWG regarding cancellation introduces two new objects: CancellationController and CancellationSignal. My concern is that CancellationSignal inherits from the DOM EventTarget, which strongly ties the implementation to the DOM.
19:38:48  <rbuckton>For comparison to the implementation in 'prex', CancellationController is similar to https://github.com/rbuckton/prex/blob/master/docs/cancellation.md#class-cancellationtokensource, while CancellationSignal is similar to https://github.com/rbuckton/prex/blob/master/docs/cancellation.md#class-cancellationtoken
19:39:03  <bradleymeck>that certainly would be hard not just for that but I don't see the exact nature of how the CancellationSignal is passed down the chain
19:39:13  * sebmckjoined
19:40:03  <bradleymeck>i guess this doesn't propagate, it is just per invocation
19:40:06  <rbuckton>A CancellationSignal (or CancellationToken) is explicitly handed off to each running asynchronous operation as an argument to the user-defined function.
19:40:52  <rbuckton>You can pass the token on, or (with the 'prex' implementation) create a new source from an existing token to create an entire cancellation graph.
19:41:09  <bradleymeck>so that seems fine
19:41:26  <bradleymeck>probably wouldn't ship EventTarget
19:42:28  <bradleymeck>EventHandler using null instead of undefined would be :shrug:
19:42:35  <bradleymeck>mostly seems fine except EventTarget
19:42:39  <rbuckton>In general, I would like to propose https://github.com/rbuckton/prex/blob/master/docs/cancellation.md as a starting point for a discussion on bringing Cancellation Tokens to ES.
19:43:52  <rbuckton>My implementation/proposal is roughly the same as the one proposed to WHATWG, though it has a few more capabilities.
19:43:58  <bradleymeck>Domenic was the champion for Promise cancellation, I think we went very far down the investigations
19:44:07  <bradleymeck>more capabilities makes me worried
19:44:09  * sebmckquit (Ping timeout: 260 seconds)
19:45:36  <rbuckton>I'm not talking about a significant difference, though. Mainly in the 'prex' implementation, you can "close" or "dispose" of the source/controller in such a way that it cannot be cancelled in the future.
19:45:57  <rbuckton>This is somewhat similar to the design of CancellationTokenSource in the .NET Framework.
19:47:58  <rbuckton>The 'prex' CancellationTokenSource also can create a cancellation graph through linked tokens, which is a fairly powerful feature when building UIs that depend on multiple asynchronous operations (such as cancelling fetch operations and animations when navigating away from a page in a single-page-application)
19:49:50  <rbuckton>Other than that, the two approaches have the same goals. You have a single source (CancellationTokenSource/CancellationController) created by the caller whose role is to initiate a cancellation signal, and a sink (CancellationToken/CancellationSignal) whose role is to observe a cancellation signal.
19:51:53  <rbuckton>Both the 'prex' implementation and the WHATWG proposal support the ability to "unsubscribe" from cancellation. The WHATWG approach would be to use `removeEventListener`, whereas with the 'prex' approach you can call `unregister`
19:53:08  <rbuckton>Unfortunately, I have to run for a bit. I will be back on later to discuss further.
19:53:24  <bradleymeck>i'm +1 for not using a string based argument, but I think this ball is more in WHATWG court than Node right now
19:54:29  <rbuckton>True, but Promises were originally in WHATWG's court as well (nee. Futures), but it was definately worth TC39 adopting that proposal as part of the language.
19:54:37  <rbuckton>I'll return in a bit.
19:54:39  * rbucktonquit
20:08:26  <bradleymeck>@bterlson to sum up, w/o the EventTarget interface and the EventHandler defaulting to `null` it doesn't look unreasonable
20:08:57  * rbucktonjoined
20:18:04  <rbuckton>I know cancellation was investigated by domenic and others, but I am unsure as to the current status of that effort. I seem to recall it was withdrawn, but if that's the case I'm not certain what the reasons were.
20:28:52  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
20:44:50  * rbucktonquit (Disconnected by services)
20:45:07  * rbucktonjoined
20:49:39  * gskachkov_quit (Quit: gskachkov_)
20:55:34  * gskachkov_joined
21:10:49  <bterlson>rbuckton bradleymeck: it's dead, but its approach was also much less likely to succeed than this I think
21:10:57  <bterlson>not because it was worse but just a harder row to hoe
21:28:52  * Bakkotquit (Quit: death)
21:30:36  * gskachkov_quit (Quit: gskachkov_)
21:55:13  * ronbucktonjoined
21:58:16  * bradleymeckquit (Quit: bradleymeck)
21:59:59  * rbucktonquit (Remote host closed the connection)
22:00:00  * ronbucktonchanged nick to rbuckton
22:47:59  * Bakkotjoined
22:55:42  * Bakkotquit (Quit: death)
23:00:54  * Bakkotjoined
23:03:40  * Fishrock123quit (Quit: Leaving...)
23:07:19  * Bakkotquit (Quit: death)
23:11:21  <cloudshu>bterlson: did you mean with(prejudice)
23:12:35  <bterlson>cloudshu: lol
23:12:49  <bterlson>cloudshu: damnit should have used my humor consultant
23:12:51  <bterlson>too late now
23:15:28  * Bakkotjoined
23:17:28  * Bakkotquit (Client Quit)