Much clearer now! Thank you!
On Mon, May 24, 2021 at 4:22 PM daniel szmulewicz <
daniel.szmulew...@gmail.com> wrote:
> Hi Sean,
>
> Thank you for explaining what was confusing. With that input, I've edited
> my blog post, separating the parts that apply to both REPL and nREPL and
> those that
Hi Sean,
Thank you for explaining what was confusing. With that input, I've edited
my blog post, separating the parts that apply to both REPL and nREPL and
those that apply to nREPL only.
I hope this avoids the pitfall you've described, and that the general
discussion on Clojure's on-the-fly code
It wasn't clear to me that the entire article only applies to nREPL.
Especially since most of the article just uses "REPL" and most of the code
does work in a normal REPL -- and you start with:
Our exploration of the topic makes heavy use of a REPL, I invite you to
fire one up and play along.
Hi Sean,
Absolutely, the growing stack of context class loaders is a quirk of the
nREPL client.
* something fairly unexpected is that with a CIDER/nREPL setup, each
evaluation adds an extra classloader*
And later I write:
In the default REPL, one instance of DynamicClassLoader stays associated
When I tried some of your code in a default REPL (via the Clojure CLI), I
don't see the same results. In particular:
user=> (hash (.getContextClassLoader (Thread/currentThread)))
1865201235
user=> (hash (.getContextClassLoader (Thread/currentThread)))
1865201235
user=> (hash
Every time you press ENTER at the REPL, a new class is created. In
addition, it comes with a new class loader instance exclusively dedicated
to loading it. That's Clojure behind the scenes doing its runtime magic. On
the other hand, in a nREPL client like Cider, not one but two class loader
