Fork me on GitHub
#unrepl
<
2018-01-30
>
ghadi16:01:04

in SPIRAL, how can I control client-side printing?

volrath16:01:16

@ghadi do you mean add pretty printing to the repl returned data structures?

ghadi16:01:51

and stuff like printing a UUID as #uuid "..." not #object []

volrath16:01:48

pretty printing is something we've discussed to implement as part of parseclj (https://github.com/clojure-emacs/parseclj) but it's not yet there

volrath16:01:54

the second thing also needs to be implemented, but in spiral's code... I only implemented it for functions and images so far

volrath16:01:02

PRs are welcome šŸ™‚

cgrand17:01:59

@volrath what about connecting to a repl behind ssh, could SPIRAL/emacs take care of setting up the ssh part?

volrath17:01:13

I haven't worked on something similar to that, but I think it could

cgrand17:01:00

So ssh:cgrand@server:2222 could be used to connect to a repl?

volrath17:01:05

how would you connect to a socket repl through ssh in any other client or from your terminal?

volrath17:01:50

right now, spiral only connects to host ports, but not through ssh, I'm trying to figure that part out

gcast17:01:28

@volrath I do this all the time. ssh -fNTL local-port:localhost:remote-repl-port user@remote

gcast17:01:47

thats how I connect using SPIRAL

volrath17:01:23

right, so it's just a port forwarding, that's what I was thinking

volrath17:01:23

I could make emacs exec that prior connecting

volrath17:01:32

although I would do it as a separate command from spiral-connect, cause besides behaving differently, it needs extra connection data (username and remote repl port)

gcast17:01:35

so there is one difficulty with the command line approach I currently use

cgrand17:01:13

what does spiral-connect takes?

gcast17:01:22

there are cases where for some reason the port-forwarding collides and I have to kill all ssh tunnels to start new ones. Basically, I have no way to label my ssh tunnels to kill specific ones

cgrand17:01:40

the client should allocate the lcoal port or use a socket

volrath17:01:03

host and port, spiral-connect uses elisp's make-network-process internally, which creates network connections

cgrand17:01:25

could spiral-connect also takes a single arg? (a uri)

volrath17:01:36

spiral-connect's api receives the host:port as a string, I could augment that to something like user@host:remote-port:local-port

volrath17:01:01

but seemps a bit complicated, I'd rather have a command specific for this case

cgrand18:01:55

I donā€™t know from the user point of you, knowing that he just have to enter the connection string seems simple (but not easy for the implementer) ā€¢ port, assumes localhost ā€¢`host:port`

cgrand18:01:35

ā€¢ ssh:user@server:remote-port local port as an impl detail

cgrand18:01:08

ā€¢ nrepl:server:port

cgrand18:01:36

and the list may grow with cljs

volrath18:01:11

yep, my thought is that I rather skip the protocol prefix (`ssh:`, nrepl:, ...) and create different commands for them

cgrand18:01:03

It makes communication harder imo: you canā€™t just slack the connection string to your coworker you have to specify the protocol and then she has to find the right connect command for her env.

cgrand18:01:23

Or printing the connection string in a log etc.

gcast18:01:01

I personally would prefer one command, prefix the protocol but I don't know the implementation hurdle required

cgrand18:01:56

well if you have N commands I guess writing the one command to dispatch them all according to the protocol is doable

volrath18:01:39

re. slack, true, but I don't feel that's such a big deal, considering that knowing where your team's repl run is something that people just know. re. logging, not really, spiral can log whatever data it has on the connection, including the connection protocol (or other things like the project directory to which that repl belongs to, if any)

volrath18:01:47

implementation is definitely not a problem

volrath18:01:56

is just a matter of UI

cgrand18:01:19

> considering that knowing where your teamā€™s repl run is something that people just know as a consultant I disagree

volrath18:01:22

but I'll be open to implement it as well, as a secondary thing

volrath18:01:32

or accept it as a PR

cgrand18:01:41

and also the ability to assist a colleague on a random project/container/server

volrath18:01:51

haha I believe you.. but maybe that problem has a root some place else

volrath18:01:06

what do you mean by that last comment?

cgrand18:01:19

I donā€™t know I like the bazar too much

volrath18:01:46

I don't understand šŸ˜³

cgrand18:01:55

I assumed by ā€œa root some place elseā€ you hinted at shared and documented practices etc. I was just answering that I like to imagine approaches to dev that donā€™t require too much coordination or agreement.

volrath18:01:34

ah, got it, I thought you were referring to the last comment: "and also the ability to assist a colleague on a random project/container/server"

volrath18:01:41

but anyway, I do understand your point.. maybe after any of these connections methods/protocols are implemented, we could expand spiral-connect, most likely if there's more than 2 (say local, nrepl, and ssh)