Clojurians Log v2

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

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

yeah

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

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

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

PRs are welcome 🙂

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

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

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

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

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

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

thats how I connect using SPIRAL

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

I could make emacs exec that prior connecting

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)

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

what does spiral-connect takes?

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

the client should allocate the lcoal port or use a socket

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

https://www.gnu.org/software/emacs/manual/html_node/elisp/Network-Processes.html

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

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

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

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`

• ssh:user@server:remote-port local port as an impl detail

• nrepl:server:port

and the list may grow with cljs

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

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.

Or printing the connection string in a log etc.

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

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

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)

implementation is definitely not a problem

is just a matter of UI

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

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

or accept it as a PR

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

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

what do you mean by that last comment?

I don’t know I like the bazar too much

I don't understand 😳

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.

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"

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)