Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2018-01-23

Channels

#unrepl
<
2018-01-23
>
rarous07:01:38

@urzds You can connect to Socket REPL via Tubular and use it in Cursive, see http://planck-repl.org/ides.html

dominicm08:01:48

Given that this exists, I'm not sure there's a benefit to cursive in unrepl. If the goal is "socket repl", then tubular provides that.

cfleming10:01:44

I definitely plan to provide more REPL support, tubular is pretty fiddly and not ideal.

cfleming10:01:13

I’d like to provide a decent unrepl client, and a raw socket REPL one.

dominicm10:01:37

@U0567Q30W 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.

dominicm10:01:01

Supporting raw socket REPL could involve using the Unrepl protocol.

cfleming10:01:22

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.

dominicm10:01:27

@U0567Q30W I'm not sure that unrepl is much more than an implementation detail though, is it?

cgrand10:01:12

@U09LZR36F yeah I don’t think “unrepl inside” stickers are worthy 🙂

dominicm10:01:46

@cgrand You just wrote the message I will be writing into replant when I connect to a socket 😛

dominicm10:01:08

@cgrand The only thing that makes me hesitate on that slightly, is the concept of BYOB.

cgrand11:01:52

For now l consider that BYOB is for “power” users but I’m not done with it.

dominicm11:01:19

Which makes sense. So, no "unrepl inside" stickers 😛

cfleming11:01:53

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.

cgrand11:01:21

technically you can have unrepl on top of nrepl too...

cgrand11:01:14

maybe the choice should rather be “nrepl/socket/raw socket”

urzds12:01:55

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.

cgrand12:01:37

@urzds yes, so why advertise unrepl to the end user?

urzds13:01:45

Seems unnecessary, yes.

urzds13:01:55

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.

urzds13:01:13

So choosing between nREPL and Socket REPL would be sufficient in the Cursive "Run Configuration" settings, I guess.

rarous07:01:37

But, Unrepl needs another layer to work in Cursive

dominicm08:01:48

Given that this exists, I'm not sure there's a benefit to cursive in unrepl. If the goal is "socket repl", then tubular provides that.

cfleming10:01:55

@urzds Thanks for the issues!

volrath10:01:55

@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.

volrath10:01:15

here's a snippet of an evaluation

cgrand10:01:43

@volrath looks like a regression of my printer rework

volrath10:01:56

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

volrath10:01:45

I'll open an issue for the time being

volrath10:01:28

haha or not

cgrand10:01:46

it should fix the issue

volrath10:01:53

perfect 🙂

cgrand10:01:09

but you can open an issue to give more context

cgrand11:01:10

@volrath solved or not?

volrath11:01:59

we'll have to wait for @gcast to try it out, I do not have an easy way to reproduce it

cgrand11:01:09

before: 

((apply comp (repeat 6 vector)) (java.util.ArrayList. [1 2 3]))
[:eval [[[[[[#unrepl/object [#unrepl/... {:get (unrepl.replG__152/fetch :G__654)}]]]]]]] 1]
after: 
((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]

volrath13:01:52

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

cgrand13:01:48

good point

cgrand14:01:27

@volrath 

((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]

gcast16:01:37

@volrath ready to try out the fix. is it in SPIRAL? [EDIT] nvm. just saw the commit message

cgrand16:01:59

@volrath that’s the kind of cases where BYOB is useful

volrath16:01:21

Correct. I don't know if it's in MELPA unstable yet, but i guess it should be..

gcast18:01:33

did not fix. 

error in process filter: spiral-loop-side-loader-handler: [side-loader] Unrecognized message \.\.\.
error in process filter: [side-loader] Unrecognized message \.\.\.

volrath19:01:42

@gcast maybe that's the second error that @cgrand fixed, I just realized I didn't push that fix to spiral