Dunno what CoderPad is, but Clojure 1.12 has add-lib and add-libs functions that you can use in a REPL.

The come from the clojure.repl.deps namespace that's automatically included when starting the default REPl.

Clojure 1.12.0-alpha9
user=> (add-lib 'com.github.seancorfield/honeysql)
[com.github.seancorfield/honeysql]
user=> (require '[honey.sql :as sql])
nil
user=> (sql/format {:select :* :from :t})
["SELECT * FROM t"]

https://app.coderpad.io/sandbox is an web-based coding environment. Some companies use it for live-coding interviews. Unfortunately, they’re on Clojure version 1.11.1.

> Some companies use it for live-coding interviews. Shame on them. :D And seems like yeah, manually copying the source over seems like the only viable approach in the case of CoderPad. But they do mention that you can email them with suggestions: > Are there any libraries or settings we missed? Feel free to <mailto:[email protected]?subject=CoderPad%20Language%20Suggestion|email us> with suggestions!

Ok. I’ll give that a shot. Thank you!

No. go-loop is literally (go (loop ...)).

The same block might be executed in parallel if you execute the (go-loop ...) form itself more than once. Just in case - don't do anything computationally intensive in there without using (core.async/thread ...). The thread pool that backs go blocks is very limited and isn't meant to be executing anything long-running.

Right, but so… only a single instance of go block is running, per go invocation, (even though multiple items could be taken from channel and processed, since channel is full)?

Yes. It's a regular single thread that runs the code.

@U66G3SGP5 while the go-loop itself doesn’t parallelize the items on the stream, it is trivial to add this using one of the pipeline primitives in core.async (for instance, https://clojuredocs.org/clojure.core.async/pipeline-async)

pipeline-async just leverages the core-async thread pools for go routines, but you can also use pipeline-blocking or pipeline if you need to branch out to other pools

Note that the async in the name means that the function that does the work is intended to be async. Same with blocking - it's about the operation itself, not about the pipelining. So, just in case, my "just in case" comment still applies. :) If you have computationally-intensive stuff, the blocking fn should be used.

Right, I didnt mean to suggest otherwise. My main point was that if you want to do more than one thing to a core.async channel at a time, pipeline* is your friend.

Of course, I wasn't poking at your comment, just adding info to the thread.

Thanks for the explanation. Actually I am trying to remove core.async from some code and I am trying to make it work exactly the same, so the question of whether go-loop was parallelized or not came up.