This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-17
Channels
- # adventofcode (2)
- # beginners (153)
- # cider (14)
- # clara (9)
- # cljs-dev (8)
- # cljsjs (1)
- # cljsrn (4)
- # clojure (124)
- # clojure-dev (9)
- # clojure-france (18)
- # clojure-greece (22)
- # clojure-italy (11)
- # clojure-nlp (5)
- # clojure-russia (9)
- # clojure-spec (21)
- # clojure-uk (40)
- # clojurescript (82)
- # core-async (12)
- # cursive (3)
- # data-science (2)
- # datomic (225)
- # devcards (8)
- # docs (2)
- # duct (1)
- # emacs (18)
- # figwheel (2)
- # fulcro (117)
- # graphql (13)
- # hoplon (10)
- # jobs (7)
- # jobs-discuss (7)
- # keechma (8)
- # leiningen (4)
- # off-topic (16)
- # om (2)
- # om-next (3)
- # perun (11)
- # precept (4)
- # re-frame (24)
- # reagent (2)
- # remote-jobs (8)
- # ring (2)
- # ring-swagger (9)
- # rum (42)
- # shadow-cljs (8)
- # spacemacs (3)
- # specter (7)
- # uncomplicate (10)
- # unrepl (58)
- # yada (9)
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?
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…
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?
I tried cat
, -i
and -e
and I can kill
the process just fine from another term
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)
Oh sorry. That was maybe misleading. I actually mean spawning multiple Socket REPLs, each one upgraded to an UNREPL.
I just tried closing all streams (in, out, err) on the process manually before calling .destroy
, did not change anything
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)
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?
clojure -e “(prn (some-> (get-in @#’clojure.core.server/servers [\“repl\” :socket]) .getLocalPort)) (read)”
Oh I see, would have used the -r
flag. But your solution also avoids printing a prompt.
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.
Is there another one? I was only aware of the last one, when you gave the talk at the meetup.
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
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
@cgrand you’re welcome to do the hack day here at our (nextjournal) office at Schinkestr. 9
@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
when side-loadinghttps://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.