00:17:27  * Havvyquit (Ping timeout: 240 seconds)
00:19:39  * Havvyjoined
00:28:49  * keith_millerjoined
00:30:15  * araijoined
00:31:15  * araiquit (Remote host closed the connection)
00:32:24  * araijoined
00:36:53  * basicdaysquit (Ping timeout: 256 seconds)
00:53:55  * basicdaysjoined
01:22:03  * not-an-aardvarkjoined
01:42:34  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:53:44  * keith_millerjoined
01:55:31  <jmdyck>bterlson: ?
02:25:48  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:39:38  * srl295quit (Quit: Connection closed for inactivity)
02:46:46  * keith_millerjoined
02:47:29  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
03:18:14  * howdoijoined
04:06:47  * jmdyckquit (Quit: Leaving.)
05:06:12  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:07:09  * keith_millerjoined
05:40:35  * Havvyquit (Read error: Connection reset by peer)
05:41:03  * Havvyjoined
05:41:19  * keith_mi_joined
05:44:47  * keith_millerquit (Ping timeout: 276 seconds)
06:21:46  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
06:24:34  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:36:17  * keith_millerjoined
06:36:37  * keith_millerquit (Client Quit)
06:44:59  * keith_millerjoined
08:09:37  * Havvyquit (Read error: Connection reset by peer)
08:12:19  * Havvyjoined
08:16:10  * araiquit (Remote host closed the connection)
09:42:55  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:59:39  * vikash-afkquit (Remote host closed the connection)
10:15:51  * vikash-afkjoined
10:25:07  * mylesborinsquit (Quit: farewell for now)
10:25:38  * mylesborinsjoined
10:39:33  * AtumTjoined
10:50:01  * araijoined
11:40:40  * gibson042quit (Ping timeout: 265 seconds)
11:44:52  * keith_millerjoined
12:44:57  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:51:25  * keith_millerjoined
12:55:12  * keith_millerquit (Read error: Connection reset by peer)
12:55:49  * keith_millerjoined
13:05:10  <devsnek>how come the may meeting is a day longer than usual
13:05:41  <IgnoredAmbience>3 days? That's the usual length
13:05:52  <devsnek>aren't they usually 2
13:06:17  <IgnoredAmbience>Every one I've seen has been 3
13:06:32  <devsnek>maybe i can't count shrug
13:06:40  <devsnek>lel
13:10:49  * jmdyckjoined
14:03:15  * cloudshujoined
14:52:05  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:58:09  * keith_millerjoined
15:01:58  * howdoiquit (Quit: Connection closed for inactivity)
15:07:36  <rwaldron>devsnek they've been 3 days since the first meeting I attended, which was May 2012. Prior to that, meetings were 2 days
15:08:18  <devsnek>devsnek is crazy confirmed
15:54:32  * jwaldenjoined
16:13:03  * srl295joined
16:32:24  <leobalter>Domenic https://github.com/domenic/proposal-blocks#example-usage - I'm totally up for using top-level await in the worker blocks.
16:33:20  <leobalter>even if we start only with top level await inside workers
16:34:24  <leobalter>worker / blöck or whatever the name it gets
16:38:51  <Domenic>Why don't you like async function body?
16:50:04  <leobalter>I didn't say this. I'm supportive for top-level await, and supportive to start it within the proposed syntax for blöcks
17:00:58  <annevk>Domenic: https://github.com/domenic/proposal-blocks/issues/1 I initially thought this was about the base URL not being clear
17:01:02  <annevk>Domenic: it seems that's another issue
17:01:38  <Domenic>Yeah, the web side of how we define worker() is a whole separate thing
17:35:48  <devsnek>about the name, these are technically lambdas right?
17:36:31  <devsnek>if you stretch the definition of a lambda a bit
17:36:45  <devsnek>these feel closer to a c++ lambda than to a js block
17:37:37  <TabAtkins>Yes, they're (if you squint), lambdas.
17:37:44  <TabAtkins>Or, uh, closure-free closures. ^_^
17:37:55  <devsnek>lol
17:50:13  <zkat>I was literally working on a thing recently that would've benefited hugely from this. I was even doing value injection and managing the env to disable closures. I feel like there's pieces of this construct that are missing when you take certain real-world use into account. For example, how do you handle imports within blocks? Do you need to re-import everything? Does it -have- to be a dynamic import() or can I use `import` format?
17:50:51  <devsnek>i think you should be able to use static import
17:50:52  <zkat>(I mean I know this doesn't seem to have any allowances for imports right now -- but it's a pain point I ran into when playing around with a construct like this. Most JS devs I know don't just use whatever the current plain environment happens to have)
17:50:58  <devsnek>re-importing seems given
17:51:17  <devsnek>also i really like the idea of using the primordial state of the global
17:51:42  <zkat>I'd go so far as to suggest that any import-bindings that the block references should be auto-imported on the Other Side (or at least provide some facility to do so, like the var capture thing)
17:52:42  <zkat>and I say this instead of "just" using the var-capture-passing thing because passing arguments like that in a language like javascript is nowhere near the nice, smooth experience that it is in Erlang -- which gets around a lot of this by being universally immutable and fully serializable. JS is _not_ universally serializable and I don't know how one would prevent massive footgunning for users who don't understand this
17:52:58  <zkat>and then they start shoving args at these blocks and don't understand why everything went to hell
17:53:54  <zkat>my first impression is that I'm excited af to have something like this in JS and imagine a lot of the possibilities it opens up for concurrency and distribution.
17:54:33  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:54:58  <zkat>my second impression is that I feel like this proposal needs to be included with a much bigger picture about concurrency, serialization, and do more to address how non-obvious concurrency issues are to users.
17:56:06  <devsnek>i opened an issue a few months ago for whatwg about serialising js
17:56:36  <devsnek>like structured clone but with a standardised intermediate format
17:57:21  <zkat>I feel like that's a fool's errand to do right tbh
17:57:45  <devsnek>the biggest issue i can think of is that it would be another python pickle or erlang etf
17:58:08  <zkat>my instinct is to say that only buffer/string data can be sent over the pipe
17:58:39  <devsnek>have you ever played with v8's serialization api
17:58:53  <devsnek>its what they exposed so that chromium could make postMessage
17:59:11  <zkat>I haven't :)
17:59:28  <devsnek>https://nodejs.org/api/v8.html#v8_serialization_api
17:59:53  <devsnek>i imagine something like this but with a standardized format
18:18:08  * jwaldenquit (Ping timeout: 276 seconds)
18:18:16  <devsnek>why can't symbols be used as weak map keys
18:20:39  <TabAtkins>Probably by accident, as a semi-primitive? But they have object identity, so they should be fine to use. (I think.)
18:22:42  <devsnek>mdn even explicitly mentions it
18:23:11  <devsnek>`Primitive data types as keys are not allowed (e.g. a Symbol can't be a WeakMap key).`
18:23:48  <TabAtkins>Yeah, I suspect it's just accident of history, as they were defined at roughly the same time. Symbols are unforgeable, should be fine to WeakMap with.
18:26:19  <devsnek>so how do "spec bugs" get fixed
18:26:30  <TabAtkins>file them as issues in gh
18:26:41  <TabAtkins>Or yell at bterlson or something
18:27:29  <devsnek>so there doesn't need to be a "symbols as weakmap keys proposal"
18:27:53  <TabAtkins>Depends. If people end up thinking it's more than just a bug, it might get upgraded to that. But try it as a bug first.
18:32:08  <Bakkot>I don't think they should be, for consistency with other primitives and because of the interaction with the symbol registry
18:32:12  * keith_millerjoined
18:32:40  <devsnek>as a replacement i'm using frozen objects with null prototypes
18:33:05  <Bakkot>e.g. `let map = new WeakMap; { let x = Symbol.for(''); map.set(x, obj); }` means that `obj` can never be collected from the map
18:33:27  <devsnek>thats true with literally anything
18:33:38  <devsnek>although i get the point
18:33:47  <devsnek>wait
18:33:59  <devsnek>no
18:34:10  <devsnek>you can retrieve Symbol.for('') later
18:35:05  <Bakkot>The fact that you can retreive `Symbol.for('')` later is the reason that you can never collect `obj` from the map.
18:35:16  <Bakkot>same as if you'd put a string or other primitive in.
18:35:25  <TabAtkins>The Symbol registry, here, is just like any global reference. You can always stash objects globally and have them never get collected.
18:35:43  <devsnek>huh?
18:35:43  <devsnek>i'm not following your logic
18:35:59  <devsnek>oh collected as in gc'd
18:37:05  <ljharb>symbols are primitives; only objects can be weakmap keys, because only objects can be collected
18:37:24  <TabAtkins>Or, well, hm, I guess I get the objection to the symbol registry. It's akin to making *some* symbols forgeable.
18:37:25  <ljharb>altho it does seem reasonable that a non-global-registry symbol should be collectible
18:37:55  <ljharb>but then you'd have a weird thing where some symbols could be used as weakmap keys and not others
18:38:03  <ljharb>so it makes sense to prohibit them all
18:39:14  <TabAtkins>Eh. Symbols that return undefined from `Symbol.keyFor(x)` would be usable, others not. You can't create a Symbol and then toggle into being part of the registry, it's specially created by the runtime for you.
18:40:18  <TabAtkins>So since this property is stable for the lifetime of the symbol, seems like something you could reasonably key off of.
18:40:54  <TabAtkins>Alternately tho, just: if you use a registry Symbol, yeah, that key can't be collected. Don't do that. Same as using an object that you then stash into a global variable.
18:43:36  * jwaldenjoined
18:46:00  <TabAtkins>Like, `wmap.set(window, obj)` isn't going to go very well for you either.
18:49:19  <devsnek>+1 to that
19:00:21  <Domenic>zkat: dynamic import works right now. Unclear whether static import buys much beyond that given that this code is dynamically evaluated anyway.
19:02:08  <Domenic>And yes, working out the web side of how worker() would work is a big task, and I wouldn't anticipate this getting beyond the cross-cutting concerns stage without full buy in from the web side on some ready-to-go blöck tags.
19:02:27  <zkat>👍🏼
19:02:44  <zkat>v excite to see more work along this sort of thing. This bit's an important part of the story for sure ^_^
19:02:52  <zkat>thanks for working on it!
20:40:41  * keith_millerquit (Quit: Textual IRC Client: www.textualapp.com)
20:52:04  * keith_millerjoined
22:12:18  * not-an-aardvarkjoined
22:18:02  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:24:04  * keith_millerjoined
22:33:43  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:41:42  * araiquit (Ping timeout: 260 seconds)