00:04:11  * kg4cjv_22joined
00:05:23  * kg4cjv_22quit (Remote host closed the connection)
00:34:33  * AtumTquit (Quit: AtumT)
01:49:10  * aki_joined
01:50:11  * akirosequit (Ping timeout: 260 seconds)
01:50:11  * aki_changed nick to akirose
02:15:14  * mickdermack8joined
02:19:58  * mickdermack8quit (Remote host closed the connection)
03:39:27  * howdoijoined
03:55:53  * aki_joined
03:57:21  * akirosequit (Ping timeout: 260 seconds)
03:57:21  * aki_changed nick to akirose
04:48:04  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
04:59:24  * jmdyckquit (Remote host closed the connection)
05:28:41  * Sulak9joined
05:32:05  * Sulak9quit (Remote host closed the connection)
06:01:38  * aki_joined
06:02:08  * akirosequit (Ping timeout: 252 seconds)
06:02:09  * aki_changed nick to akirose
06:04:31  * Aquazijoined
07:17:10  * rodsmithjoined
07:18:40  * rodsmithquit (K-Lined)
07:20:51  * akoserwajoined
07:52:27  * Jad8joined
07:54:04  * Jad8quit (Remote host closed the connection)
08:08:08  * akirosequit (Ping timeout: 244 seconds)
08:08:19  * akirosejoined
08:19:59  * bendoin4joined
08:21:06  * bendoin4quit (Remote host closed the connection)
09:09:45  * joze2joined
09:11:19  * joze2quit (Remote host closed the connection)
09:22:02  * modrobert26joined
09:24:31  * modrobert26quit (Killed (Sigyn (Spam is off topic on freenode.)))
09:27:06  * akoserwaquit (Remote host closed the connection)
09:28:15  * Belial`joined
09:29:47  * Belial`quit (Killed (Sigyn (Spam is off topic on freenode.)))
09:55:06  * LRN29joined
09:58:20  * LRN29quit (Remote host closed the connection)
10:01:45  * AtumTjoined
10:14:35  * aki_joined
10:15:56  * akirosequit (Ping timeout: 260 seconds)
10:15:56  * aki_changed nick to akirose
11:36:05  * lightstalker1joined
11:38:35  * lightstalker1quit (Remote host closed the connection)
12:22:06  * akirosequit (Ping timeout: 264 seconds)
12:22:19  * akirosejoined
12:33:04  * warthog925joined
12:33:15  * warthog925quit (Remote host closed the connection)
12:34:22  * jmdyckjoined
13:23:32  * cheets_joined
13:25:57  * cheets_quit (Killed (Sigyn (Spam is off topic on freenode.)))
14:29:35  * aki_joined
14:29:44  * akirosequit (Ping timeout: 272 seconds)
14:29:46  * aki_changed nick to akirose
14:52:51  * surrounder11joined
14:53:40  * surrounder11quit (Remote host closed the connection)
15:59:10  * jwaldenjoined
16:32:58  * psyhovijoined
16:33:19  * deem13joined
16:36:18  * akirosequit (Ping timeout: 245 seconds)
16:36:48  * akirosejoined
16:37:59  * deem13quit (Remote host closed the connection)
16:58:14  * Evilham5joined
16:59:06  * Evilham5quit (Remote host closed the connection)
17:02:17  * cloudshujoined
17:04:43  * cudgel17joined
17:05:39  * isiahmeadowsjoined
17:06:04  * isiahmeadowsquit (Client Quit)
17:06:26  * isiahmeadowsjoined
17:07:52  * cudgel17quit (Killed (Sigyn (Spam is off topic on freenode.)))
17:16:52  * isiahmeadowsquit (Quit: isiahmeadows)
17:18:45  * isiahmeadowsjoined
17:19:08  <isiahmeadows>So, I like the idea of ESM, but I've got an issue: I need the ability to load them without caching them. https://esdiscuss.org/topic/uncached-modules
17:19:45  <devsnek>export a function which you can call a bunch
17:19:49  <devsnek>or a class you construct
17:20:24  <devsnek>add a random query
17:20:42  <isiahmeadows>devsnek: I'm thinking more down the vein of hot loading, JS-based templates, etc.
17:20:58  <isiahmeadows>That's another use case for not caching.
17:21:03  <devsnek>hot reloading can be done by engines
17:21:09  <devsnek>without changing the spec
17:21:13  <isiahmeadows>True.
17:21:33  <devsnek>leaving debugging stuff out of the spec means implementors can go crazy
17:21:34  <isiahmeadows>But I'm also looking at the fact I'd like to export a module that depends on its parent path.
17:21:52  <devsnek>export a function that takes a path
17:22:05  <devsnek>`import { X } from 'x'; X(import.meta.url);`
17:22:24  <isiahmeadows>I know that's possible, but I'd rather avoid forcing that boilerplate upon the user.
17:24:06  <isiahmeadows>I have two specific use cases for that proposal: https://github.com/isiahmeadows/invoke-parallel, where I have to dynamically detect based on the parent path, and https://github.com/isiahmeadows/thallium, where I'd rather load the tests *without* caching, so I can dodge the retained memory overhead in, for example, a theoretical "watch" mode.
17:24:33  * AtumT_joined
17:24:56  <isiahmeadows>I also have a third-ish one, where I'd be developing a hot-reload mechanism for Node, and I'd like to avoid leaking memory in the process.
17:25:20  <isiahmeadows>That last one doesn't have any code written yet, but it's something I'd like to try to tackle.
17:26:34  <devsnek>for the first one... you can just not do weird require-resolve-magic stuff
17:26:57  <devsnek>nothing else in the ecosystem does that because its difficult to reason with
17:27:01  * AtumTquit (Ping timeout: 260 seconds)
17:27:37  <devsnek>as for the second one, you can just keep importing with different queries
17:27:51  <isiahmeadows>But that leaks.
17:27:51  <devsnek>whatever caching the host does is up to the host
17:28:20  <isiahmeadows>And the host doesn't necessarily know it'll never be loaded again with that query.
17:28:45  <isiahmeadows>So it'd be solving the halting problem to correctly infer it, when a directive to the engine would be sufficient.
17:29:11  <isiahmeadows>Alternatively, for the second, an "uncached import" would be enough for that.
17:29:21  <devsnek>what does that even mean
17:29:24  <isiahmeadows>Maybe something like `import.uncached(...)`
17:31:49  <isiahmeadows>devsnek: Here's a gist of something I'm currently using in Node: https://gist.github.com/isiahmeadows/6f983913e9bacd7cf7ddfa4c6e81f80e
17:32:10  <isiahmeadows>That's the CJS equivalent of my suggested `import.uncached(...)` above.
17:32:49  <devsnek>yeah but cjs and esm don't logically map together like that
17:32:52  <isiahmeadows>Alternatively, maybe a `{ignoreCache: true}` option.
17:33:17  <isiahmeadows>I'm aware, but the basic concept is to ignore caching the child altogether, and just do resolution.
17:33:20  <devsnek>cjs has this parent/child thing which esm has no concept of
17:33:31  <isiahmeadows>I'm aware.
17:33:40  <devsnek>because the parent/child thing is a terrible way to think about dependency graphs
17:33:50  <isiahmeadows>The concept is to avoid caching, and instead just resolve and load.
17:34:09  <isiahmeadows>Whatever that caching uses is of course an implementation detail, and that's the point.
17:36:09  <isiahmeadows>Another equivalent I could present is `var foo = r.require("ns.foo"); r.unload("ns.foo")`, where `r` is defined here: https://github.com/isiahmeadows/simple-require-loader/blob/master/r.js
17:36:27  <isiahmeadows>In that case, there, too, is no concept of a parent or child module, just a global cache.
17:37:05  <devsnek>i still would say that certain design patterns just don't translate between cjs and esm
17:37:41  * AtumTjoined
17:37:59  <devsnek>python might be a good example of how people build things in module systems like this
17:38:21  * AtumT_quit (Ping timeout: 252 seconds)
17:44:27  * isiahmeadowspart
17:44:43  * isiahmeadowsjoined
17:44:52  <isiahmeadows>devsnek: The first one (dynamically calculated imports) might not directly translate (I've been looking into dynamic imports), but for the non-caching import, you could add a third parameter to https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule, modify the third requirement to only require idempotence iff that third parameter is `true`, and update callers accordingly.
17:45:09  <devsnek>yeah you *could*
17:45:16  <devsnek>i think it would be bad practice though
17:45:45  <devsnek>i don't think the problem here is technical feasibility
17:45:49  <isiahmeadows>But my suggested verbose syntax of `import.uncached("foo")` would make it *abundantly clear* that it's not really what you want to do 99% of the time.
17:46:09  <devsnek>i don't think you ever want to do it
17:46:22  <isiahmeadows>My concern is memory, as noted above.
17:46:30  <devsnek>node has worker threads now
17:46:35  <devsnek>spawn a new one for each series of testing
17:46:48  <isiahmeadows>My framework runs in more than just Node, BTW.
17:46:56  <isiahmeadows>It also runs in the browser.
17:46:56  <devsnek>browsers have web workers
17:47:01  <devsnek>spawn a new one for each series of testing
17:47:05  <isiahmeadows>But you lack the DOM API.
17:47:42  <devsnek>lol if you're messing with some global state import.uncached feels even more dangerous
17:47:54  <isiahmeadows>How do you plan to do UI testing? (Not all frameworks run particularly well outside the DOM.)
17:48:00  <devsnek>use puppeteer
17:48:12  <bradleymeck>isiahmeadows: spawn an iframe, not worker if you want dom
17:48:23  <devsnek>oh yeah iframes are a thing
17:48:25  <isiahmeadows>That solves testing Chrome, but what about Safari/Firefox
17:48:39  <isiahmeadows>bradleymeck: Fair enough.
17:49:11  <isiahmeadows>What about other environments, like embedded and other server-side stuff?
17:49:26  <devsnek>it depends on the host
17:49:30  <devsnek>like i've been saying
17:49:50  <devsnek>perhaps you spawn a new process for each round of testing
17:49:56  <bradleymeck>isiahmeadows: run chrome/firefox headless or jsdom it
17:49:57  <isiahmeadows>Alternatively, would it make better sense to push implementations to offer the ability to remove a module from its cache via its `import.meta` or exports namespace?
17:50:11  <isiahmeadows>*"and", not "or"
17:50:20  <bradleymeck>removing stuff is not as simple as removing from the cache
17:50:29  <bradleymeck>lots of things leak references
17:50:48  <isiahmeadows>I'm aware. My main concern is that of module leakage, not other references.
17:51:07  <devsnek>in theory you can think up a system but in practice it will be much messier
17:51:17  <devsnek>and most likely nothing will ever be able to be collected
17:52:42  <isiahmeadows>devsnek: You can hack some module systems to properly uncache and collect an entire graph, and although I haven't developed such a thing for Node, I know I could. I'd have to do a mark + sweep to do it with any efficiency, though.
17:52:50  <isiahmeadows>A concurrent one, I mean.
17:53:54  <isiahmeadows>But a native assist would be helpful here. And where the engine also knows what references what (both modules and normal objects), it could also collect at least *some* things. I know that worst case, you can't collect anything, but I don't see the point in catering to that.
17:54:33  * azarus14joined
17:54:39  <isiahmeadows>The main thing they'd have to change is they can't treat modules as fully persistent internally.
17:54:48  <devsnek>engines already collect a lot of things, but no one is collecting modules because they represent the environment itself
17:55:25  <isiahmeadows>You can already change and manipulate the environment *some* - look at Node's loader hooks.
17:56:01  <isiahmeadows>For one ES6 analogy.
17:56:04  <devsnek>node has resolve and dynamic instantiate
17:56:09  <isiahmeadows>Yep.
17:56:11  <devsnek>dynamic instantiate is definitely getting removed
17:56:15  <devsnek>and resolve is part of the spec
17:56:17  * azarus14quit (Remote host closed the connection)
17:56:37  <isiahmeadows>devsnek: do you have any idea where the talk about dynamic instantiate being removed is taking place?
17:56:55  <devsnek>i don't think there's any formal discussion
17:57:03  <devsnek>but its a terrible api and we can do better
17:57:29  <isiahmeadows>Fair enough, and I agree the API is terrible.
17:57:33  <bradleymeck>isiahmeadows: its talked about in various places
17:57:53  <bradleymeck>if you join the Realms calls, or look at the youtube for the Modules WG whenever we had that loader presentation
17:58:02  <bradleymeck>basically exposing first class value manipution is hard
17:58:17  <isiahmeadows>Okay.
17:58:44  <isiahmeadows>I like the ES proposal that's written to replace it way better.
17:59:02  <devsnek>which proposal to replace what
17:59:15  <devsnek>the dynamic namespace one?
17:59:22  <isiahmeadows>https://github.com/guybedford/proposal-dynamic-modules
17:59:33  <devsnek>yeah
18:05:48  <isiahmeadows>But anyways, I'd still like the ability to load a module without caching it, to cut down on memory issues with reloading files. My two main use cases personally are that of 1. loading and watching large amounts of tests without creating memory issues, and 2. I'd like to experiment with server-side JS view templates (and hot-swapping those).
18:33:58  <isiahmeadows>devsnek: I just did a writeup of probably a better way to approach this: https://esdiscuss.org/topic/removing-a-module-from-the-cache
18:34:35  <devsnek>we 100% can't modify the cache
18:34:41  <isiahmeadows>It doesn't require actual syntax, just host cooperation (which it can always deny).
18:34:55  <devsnek>loading without cache is one thing
18:35:02  <devsnek>removing from cache is another entirely
18:35:18  <isiahmeadows>Fair enough.
18:35:43  <isiahmeadows>Either way, loading without cache and removing from cache would be functionally equivalent for my use cases.
18:36:10  <isiahmeadows>I just want the ability to override the cache somehow.
18:36:35  <isiahmeadows>Ignoring and removing both give me a means to the end.
18:42:57  * aki_joined
18:43:33  * akirosequit (Ping timeout: 252 seconds)
18:43:34  * aki_changed nick to akirose
19:08:24  <ljharb>that def sounds like something outside the language tho
19:11:54  * psyhoviquit (Quit: Page closed)
19:13:32  * s8548a_16joined
19:13:40  <isiahmeadows>The "removing from cache" concept is why I suggested only a few extra hooks and minor invariant tweaks, so an implementation + host choosing to allow removing modules from cache don't have to worry about violating the spec in the process.
19:14:56  <isiahmeadows>Technically, doing nothing (and not exposing anything) would still be spec-compatible with that change I suggested there - the extra restrictions would just be implementation-specific extensions to restrict that mutability.
19:15:03  * s8548a_16quit (K-Lined)
19:15:06  <isiahmeadows>ljharb:
19:35:11  <bradleymeck>isiahmeadows: i'm assuming you mean the global cache not the local cache
19:35:20  <bradleymeck>the localized cache invariant seems quite important
19:35:25  <isiahmeadows>Correct.
19:35:59  <isiahmeadows>Although I do need the local cache, too.
19:36:09  <bradleymeck>i'm still unsure of a variety of things about removing code though since dangling and gross behavior is easy to fall into
19:36:18  <bradleymeck>i would refuse to remove the local cache invariant
19:36:29  <bradleymeck>an alternative would be loading modules into an isolated cache
19:36:51  <isiahmeadows>But simply dodging the local cache is enough for my use case, because I can always reimplement the caching I need (I need something more complicated than the naive spec version).
19:37:05  <bradleymeck>i would not want to allow that
19:37:31  <isiahmeadows>This would be only something I would need to manage hot reloading, and I'd only be using absolute paths here.
19:38:08  <isiahmeadows>So in reality, I just need the ability to import globally rather than locally.
19:38:16  <isiahmeadows>And dodging the global cache in the process.
19:38:44  <isiahmeadows>Basically, it's a non-local import "proxy" of sorts - I'm not doing it for myself, but on behalf of others.
19:39:03  <bradleymeck>isiahmeadows: this sounds more like something that devtools would want to provide
19:39:13  <bradleymeck>it affects all sorts of things that have been listed before
19:39:22  <bradleymeck>mocking and APMs etc.
19:39:29  <isiahmeadows>This is for a particular development-oriented tool, yes.
19:39:35  <bradleymeck>APMs have been largely fine with the idea of doing these ahead of time
19:39:52  <isiahmeadows>It's for a test runner, and I need it for file watching.
19:39:55  <bradleymeck>stuff like https://github.com/bmeck/node-apm-loader-example
19:40:25  <bradleymeck>isiahmeadows: i don't have a good solution for you right now, but deleting seems a bit like the status quo, not necessarily the best approach
19:40:54  <bradleymeck>loading some dependency into a separate global module map than the default global one seems saner
19:40:56  <isiahmeadows>I don't need the ability to mock (although I could do a lot of mocking). And I agree that deleting isn't ideal - my initial request is for importing ignoring cache.
19:41:21  <bradleymeck>ignoring cache is complex as well since you probably don't want to reload *all* the dependencies
19:41:43  <bradleymeck>if I reload foo which imports bar, does that intend to completely reload bar
19:41:48  <bradleymeck>if so, why not just use a worker or something
19:41:50  <isiahmeadows>For a concrete example, if a file changes, I need to re-import it ignoring any cache, and I know I can't rely on the runtime to detect this - I know of none that does that.
19:42:19  <bradleymeck>reimport the file, or the entire dep graph that the file is an entrypoint to?
19:42:45  <bradleymeck>or something in between
19:43:48  <isiahmeadows>And I don't intend on reloading `bar` if it's a dependency (if it's a local module, I *do*).
19:43:52  <isiahmeadows>Specifically, I don't plan to reload it unless it changes.
19:44:01  <isiahmeadows>And of course, I'd need to reload its dependents.
19:44:16  <bradleymeck>what is a "local module"?
19:44:45  <isiahmeadows>Edit: just ignore that message. I didn't quite have all my thoughts collected when I typed that.
19:44:55  <bradleymeck>this isn't ignoring the global module map cache then
19:45:02  <isiahmeadows>But I plan to reload only files that changed.
19:45:16  <bradleymeck>that would be hard
19:45:20  <isiahmeadows>And that's why I'm veering more and more towards global cache manipulation.
19:45:29  <bradleymeck>it probably wouldn't help
19:45:46  <bradleymeck>if app imports foo and foo is reloaded, app still points to the old foo
19:45:49  <isiahmeadows>I know it's hard, but if I can get sufficient engine hooks to read modules' imports, I can build the graph and work from there.
19:46:07  <bradleymeck>you need to do more than cache manip is what i'm saying
19:46:07  <isiahmeadows>And the issue of dependents is why I need access to the graph (so I can invert it).
19:46:19  <bradleymeck>inverting the graph how
19:46:29  <isiahmeadows>But my point is I *also* need cache manipulation to help prevent memory leaks.
19:46:33  <bradleymeck>you shouldn't reorder evaluation, and you can't change the bindings
19:47:29  <isiahmeadows>And what I mean by "inverting the graph" is instead of modeling it like what Node does, parent to child, children would be aware of their parents instead. If I reload a child, I have to really reload all the parents first, and they can then just naturally reload the child if necessary.
19:47:49  <bradleymeck>you can't have child->parent really
19:48:01  <bradleymeck>you can have child->parent[] for static imports
19:48:08  <bradleymeck>and dynamic import gets even harder
19:48:11  <isiahmeadows>That's what I meant.
19:48:24  <isiahmeadows>And it's also why I want an engine hook, too (although that doesn't require a spec change)
19:48:26  <bradleymeck>so, not invert
19:48:29  <bradleymeck>just track?
19:48:47  * utrack4joined
19:48:49  <isiahmeadows>Probably a better term. I don't come from a CS background, so I don't always have all my terminology in order. :-)
19:49:39  * utrack4quit (Killed (Sigyn (Spam is off topic on freenode.)))
19:50:01  <bradleymeck>that sounds doable, but under the hood it probably would just be like adding unique query strings and kicking off the entrypoints when loading
19:50:25  <bradleymeck>i'm not sure how things like servers would work, since the top node of the module graph likely is spinning up a server that listens to a port
19:50:37  <isiahmeadows>Kind of, but unique query strings create a risk of memory leaks if I can't just flat out remove it from the global cache at least.
19:51:03  <bradleymeck>isiahmeadows: hence the recommendations of workers etc
19:51:10  <isiahmeadows>And I do get that it wouldn't always work perfectly, but I do plan to have a limit - it can't propagate outside the manager maintaining all of that mess.
19:51:21  <bradleymeck>is there a reason it needs to do all these replacements in the same realm?
19:52:38  <bradleymeck>deleting seems to be rather unsafe so taking that approach isn't super appealing
19:52:56  <bradleymeck>grouping modules to safe to GC sets seems sane
19:53:19  <bradleymeck>your reloading would have an overlap of the new graph and the old graph
19:54:02  <isiahmeadows>I'm okay if I have to do it on a dedicated realm, BTW. It doesn't have to be the same realm as the controller. I just want all the managed modules to be on the same realm relative to each other.
19:54:06  <bradleymeck>so just make sure that modules cannot GC if they are in a set that isn't marked as safe to delete once some event occurs
19:54:36  <isiahmeadows>*Separate, dedicated realm, I mean.
19:54:43  <bradleymeck>it seems doable but it seems like it would probably be saner to have `import` let you group modules and then a fn or something that says a group is safe to GC
19:54:58  <isiahmeadows>How so?
19:55:03  <bradleymeck>that would be interesting, but I'm not really at bandwidth to help
19:56:02  <isiahmeadows>I'll try to, if I can find time, prototype this for Node first using its CJS system, then I'll try to ping back with it to see if it could be adapted for ESM.
19:56:12  <bradleymeck>isiahmeadows: if I have app->b app->c, create a "module graph" with [app,b,c], never store it in the global module map
19:56:16  <bradleymeck>b updates
19:56:38  <bradleymeck>make an entirely new module graph with [updated a, updated b, old c], never store it in the global module map
19:56:48  <bradleymeck>mark the original graph as GC-able
19:57:13  <isiahmeadows>Fair enough, and that's basically an immutable equivalent to what I was previously thinking of doing.
19:57:24  <bradleymeck>old app & old b no longer being in strongly held graph would be able to be GC'd
19:58:17  <bradleymeck>isiahmeadows: just be aware that the less static/immutable stuff you do in CJS, the harder to get it to match the design of ESM
19:58:48  <isiahmeadows>I might try that at some point, just regenerating an immutable, persistent graph that, every time I "reload" a modue, I create a replacement "current" graph with all that ready. It's a bit more Erlang-like, and I think that's way better.
19:59:48  <bradleymeck>this is probably doable without changes to the spec itself since if you aren't wanting to replace bindings
20:00:11  <bradleymeck>the question is mostly how to expose these module graphs that are not directly in the global module map
20:01:05  <isiahmeadows>Potentially, but it'd still require some means of loading a module by absolute descriptor, and of course, I'd still need the ability to reference individual modules and create synthetic module graphs to cache.
20:02:25  <bradleymeck>to a cache
20:02:41  <bradleymeck>the key is you want modules that aren't in the permanent global cache
20:03:02  <isiahmeadows>I know, I meant "to cache locally using my own cache of sorts"
20:03:18  <isiahmeadows>Where that "cache" is basically just a `this.currentGraph` property.
20:03:45  <isiahmeadows>Sorry for a poor choice of words there.
20:06:46  <bradleymeck>i need to think on `import()`/`require()` a bit more
20:48:08  * aki_joined
20:49:07  * akirosequit (Ping timeout: 246 seconds)
20:49:07  * aki_changed nick to akirose
21:33:07  * isiahmeadowsquit (Quit: isiahmeadows)
21:33:43  * isiahmeadowsjoined
21:33:54  * isiahmeadowsquit (Client Quit)
22:48:34  * ryzokukenquit (Ping timeout: 252 seconds)
22:50:20  * ryzokukenjoined
22:54:38  * aki_joined
22:55:15  * akirosequit (Ping timeout: 252 seconds)
22:55:15  * aki_changed nick to akirose
23:14:02  * irclogger_comjoined
23:16:33  * irclogger_comquit (Killed (Unit193 (Spam is not permitted on freenode.)))
23:33:12  * DangerM4joined
23:34:23  * dhtns24joined
23:35:31  * DangerM4quit (Read error: Connection reset by peer)
23:36:57  * dhtns24quit (Remote host closed the connection)