Clojurians Log v2

Hey folks. :spock-hand: Is it supported to upgrade to an UNREPL via -e, or -i options of the clojure command (we are using the blob from the unrepl github repo for now)? It seems to upgrade the REPL correctly, but we we are facing issues when trying to shut down the process (process start and killing handled via the conch library). Or is the intended use to only upgrade via a socket?

Hi @nblumoe, good question. I sometimes do cat resources/unrepl/blob.clj - | clojure to test.

I see, I can try that. But an upgrade like that would not result in upgraded REPLs on new socket connections, right?

Right. Tell me more about what you are trying to achieve

We need to spawn multiple UNREPLs on a single host. By using 0 as the port, the port handling can be done by clojure itself. Of course we still need to the port to be able to connect to it and it can be retrieved in the REPL via (.getLocalPort (get-in @#'clojure.core.server/servers ["repl" :socket])). Already did this with a non-upgraded REPL via stdout and then later upgraded to UNREPL via socket. But we had the idea of doing the UNREPL upgrade as early as possible, so even before retrieving the port and have the socket port already in an UNREPL message.

Funny thing now is, that it kinda of works already. But when trying to stop the process via the conch lib, this fails when upgraded the REPL via -e or -i options…

(the lib just does (.destroy process) in the end)

Do you use stdout for anything else?

ok, re-read your message. So basically you want two things: 1/ know the port 2/ have the socket be already an unrepl connection without further upgrade Right?

The 2/ rises a number of questions: • do you want one session per socket • aren’t you going to use auxillary connections?

Yes and be able to stop the process! :)

May I ask why you “need to spawn multiple UNREPLs on a single host.“?

Yeah, kill from the CLI works for me too. But not killing it from within Clojure code that spawned the process.

We need to spawn multiple UNREPLs to create isolated environments in which we can run Clojure code (for nextjournal)

Thats’s weird. Do you close stdin/stdout prior to killing?

unrepl doesn’t provide isolation, namespaces are shared

Oh sorry. That was maybe misleading. I actually mean spawning multiple Socket REPLs, each one upgraded to an UNREPL.

so nextjournal backend (a part of) is an unrepl client, right?

I just tried closing all streams (in, out, err) on the process manually before calling .destroy, did not change anything

Yes, @ backend + unrepl-client

if you are going to use sideloading or a tooling connection I recommend against putting new sockets connectsion directly in unrepl mode (granted actually it may work because of the way further upgrades are handled but I’m not happy with this behaviour and may revisit it — and break it)

The cost that you want to avoid is to send the blob for each socket, right?

Well, primarily I would like to avoid to first have to process normal REPL stdout messages (to retrieve the port) and then switch to working with UNREPL messages.

When passing the blob to clojure, the very first thing I get on the output, is the UNREPL :hello. It would be quite convenient being able to work with this.

> Well, primarily I would like to avoid to first have to process normal REPL stdout messages (to retrieve the port) and then switch to working with UNREPL messages. But you are not doing to do further interaction on stdout, right?

That is correct

clojure -e “(prn (some-> (get-in @#’clojure.core.server/servers [\“repl\” :socket]) .getLocalPort)) (read)”

That’s what I just have done! 🙂

so no repl output on tsdout

why the (read) in the end?

to prevent exit

(.wait (Object.)) if you prefer

Oh I see, would have used the -r flag. But your solution also avoids printing a prompt.

yup

Cool, going to upgrade to UNREPL via socket then again. Regarding auxiliary connections and sessions per socket: Not sure yet, guess I need read about that first and refine a concept.

do you plan coming to the hack-together day?

Is there another one? I was only aware of the last one, when you gave the talk at the meetup.

ok there will be another on the friday before :clojureD

Cool, I missed that apparently. Is there some information available at some URL? 😄

@pesterhazy ^^

Did you already get in touch with :clojureD people? We could do some advertisement for it if you would like us to.

To summarize: somewhere in Berlin, send us (@volrath, @pesterhazy or me) a mail so that we know you are planning to come.

Do you have start and end times already? Would also propose it to others @ nextjournal

10-18 iirc

and we are open to suggestions for locations (as it may be a larger crowd)

How many people would you plan for?

Let’s count: @pesterhazy, @volrath, me, Robert Marius Avram, Meikel Brandmeyer, @bozhidar (invited but I don’t know if he gave an answer) you and your folks 🙂 I most certainly have forgotten someone

between 6 and 12?

@cgrand you’re welcome to do the hack day here at our (nextjournal) office at Schinkestr. 9

@mkvlr thank you for the offer!

@mkvlr nice!!

not sure if this is a known bug, but across several dependencies I get this error

[13] user=> (require '[gregor.core])
~ Unhandled Exception
              clojure.lang.ArityException: Wrong number of args (4) passed to: core/to-array
  clojure.lang.Compiler$CompilerException: clojure.lang.ArityException: Wrong number of args (4) passed to: core/to-array, compiling:(gregor/core.clj:1:1)

                 AFn.java: 429 - clojure.lang.AFn/throwArity
                 AFn.java:  44 - clojure.lang.AFn/invoke
           NO_SOURCE_FILE: 342 - unrepl.replG__22$classloader$fn__269/invoke
                      nil:  -1 - unrepl.replG__22.proxy$java.lang.ClassLoader$ff19274a/findClass
         ClassLoader.java: 424 - java.lang.ClassLoader/loadClass
                      nil:  -1 - unrepl.replG__22.proxy$java.lang.ClassLoader$ff19274a/loadClass
         ClassLoader.java: 411 - java.lang.ClassLoader/loadClass
  DynamicClassLoader.java:  77 - clojure.lang.DynamicClassLoader/loadClass
         ClassLoader.java: 411 - java.lang.ClassLoader/loadClass
  DynamicClassLoader.java:  77 - clojure.lang.DynamicClassLoader/loadClass
         ClassLoader.java: 411 - java.lang.ClassLoader/loadClass
  DynamicClassLoader.java:  77 - clojure.lang.DynamicClassLoader/loadClass
         ClassLoader.java: 411 - java.lang.ClassLoader/loadClass
  DynamicClassLoader.java:  77 - clojure.lang.DynamicClassLoader/loadClass
         ClassLoader.java: 357 - java.lang.ClassLoader/loadClass
               Class.java:  -2 - java.lang.Class/forName0
               Class.java: 348 - java.lang.Class/forName
                  RT.java: 2183 - clojure.lang.RT/classForName
                  RT.java: 2196 - clojure.lang.RT/classForNameNonLoading
                 core.clj:   1 - gregor.core$eval1265$loading__7717__auto____1266/invoke

client is SPIRAL btw

https://github.com/vvvvalvalval/scope-capture-nrepl somewhat good example of a reason to intercept the eval stages. It's not a game changer or anything, but it's something to consider.

“Our stacktraces are bad because we don’t need them!”

@gcast huh? Ok a pair of square brackets are missing in unrepl.

@cgrand not sure if this helps, but side-loading works much of the time, but Ive received this error with about half a dozen distinct libraries.