Clojurians Log v2
unrepl
@urzds You can connect to Socket REPL via Tubular and use it in Cursive, see http://planck-repl.org/ides.html
I definitely plan to provide more REPL support, tubular is pretty fiddly and not ideal.
I’d like to provide a decent unrepl client, and a raw socket REPL one.
@cfleming Just to be clear, it's not the intention of unrepl that users start it directly. A client (e.g. cursive) should "bring along" it's own version of unrepl.
Supporting raw socket REPL could involve using the Unrepl protocol.
Right, so at some point the user will select “I’d like to start an unrepl”, and Cursive will connect the socket REPL and send its blob.
@cfleming I'm not sure that unrepl is much more than an implementation detail though, is it?
@dominicm yeah I don’t think “unrepl inside” stickers are worthy 🙂
@cgrand You just wrote the message I will be writing into replant when I connect to a socket 😛
@cgrand The only thing that makes me hesitate on that slightly, is the concept of BYOB.
For now l consider that BYOB is for “power” users but I’m not done with it.
Which makes sense. So, no "unrepl inside" stickers 😛
Presumably users will want to choose, right? Not all socket REPL users will want unrepl, so at some point the user will have to say if they want one or the other.
technically you can have unrepl on top of nrepl too...
maybe the choice should rather be “nrepl/socket/raw socket”
As I understand it, the Cursive REPL could be "Unrepl-based-Cursive-REPL over Socket REPL". And "Unrepl-based-Cursive-REPL" would mean regular REPL features plus anything that Cursive needs in order to support hot reloading, auto-completion, live variable inspection, etc.
@urzds yes, so why advertise unrepl to the end user?
Seems unnecessary, yes.
But Unrepl would help in having a good support of Socket REPLs, as far as I understand, because it implements a common process to upgrade the Socket REPL to something with the features that e.g. Cursive needs to implement good IDE experience on top of the REPL.
So choosing between nREPL and Socket REPL would be sufficient in the Cursive "Run Configuration" settings, I guess.
But, Unrepl needs another layer to work in Cursive
@urzds Thanks for the issues!
@cgrand what do you think of this?: @gcast reported a problem in spiral when working with datomic transactions... long story short, the objects that @gcast is dealing with are represented in unrepl by deeply nested maps, and at some point, I'm getting objects which contents are elided, i.e. #unrepl/object [#unrepl/... {:get (unrepl.replG__8056/fetch :G__8577)}] -- so my #unrepl/object reader fails in this case. I'm guessing this is happening because of :nesting-depth restrictions.
here's a snippet of an evaluation
@volrath uploaded a file: https://clojurians.slack.com/files/U1D1GTBR7/F8WG95PTK/-.clj
@volrath looks like a regression of my printer rework
hmm not sure which one you are talking about, was that before or after my global-print-settings branch? right now spiral is dispatching a merge between that branch and master
@volrath this one https://github.com/Unrepl/unrepl/commit/98757689e92eafe8669667f813faecefa165cbb5
alright
I'll open an issue for the time being
haha or not
it should fix the issue
perfect 🙂
but you can open an issue to give more context
ok I will
@volrath solved or not?
we'll have to wait for @gcast to try it out, I do not have an easy way to reproduce it
before:
((apply comp (repeat 6 vector)) (java.util.ArrayList. [1 2 3]))
[:eval [[[[[[#unrepl/object [#unrepl/... {:get (unrepl.replG__152/fetch :G__654)}]]]]]]] 1]
((apply comp (repeat 6 vector)) (java.util.ArrayList. [1 2 3]))
[:eval [[[[[[#unrepl/object [#unrepl.java/class java.util.ArrayList "0x3704122f" "[1, 2, 3]" {#unrepl/... nil #unrepl/... {:get (unrepl.replG__152/fetch :G__660)}}]]]]]]] 1]shouldn't we also 'un-elide' the object's 4th element? the map where you can get :beam? otherwise is kind of the same problem
good point
((apply comp (repeat 6 vector)) (java.util.ArrayList. [1 2 3]))
[:eval [[[[[[#unrepl/object [#unrepl.java/class java.util.ArrayList "0x3704122f" "[1, 2, 3]" {:bean {#unrepl/... nil #unrepl/... {:get (unrepl.replG__152/fetch :G__660)}}}]]]]]]] 1]
@volrath ready to try out the fix. is it in SPIRAL? [EDIT] nvm. just saw the commit message
Correct. I don't know if it's in MELPA unstable yet, but i guess it should be..
did not fix.
error in process filter: spiral-loop-side-loader-handler: [side-loader] Unrecognized message \.\.\.
error in process filter: [side-loader] Unrecognized message \.\.\.