This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-30
Channels
- # arachne (23)
- # bangalore-clj (2)
- # beginners (64)
- # boot (20)
- # cider (3)
- # clara (11)
- # cljs-dev (29)
- # cljsrn (10)
- # clojure (143)
- # clojure-brasil (4)
- # clojure-dev (22)
- # clojure-dusseldorf (3)
- # clojure-italy (26)
- # clojure-sanfrancisco (13)
- # clojure-seattle-old (2)
- # clojure-spec (15)
- # clojure-uk (27)
- # clojured (1)
- # clojurescript (52)
- # core-async (13)
- # cursive (2)
- # datomic (106)
- # fulcro (45)
- # garden (1)
- # graphql (11)
- # hoplon (98)
- # jobs (11)
- # juxt (7)
- # keechma (2)
- # leiningen (36)
- # off-topic (39)
- # parinfer (13)
- # re-frame (34)
- # reagent (5)
- # ring (1)
- # rum (4)
- # shadow-cljs (83)
- # sql (1)
- # timbre (1)
- # unrepl (49)
- # vim (1)
- # yada (42)
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
@volrath what about connecting to a repl behind ssh, could SPIRAL/emacs take care of setting up the ssh part?
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
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)
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
host and port, spiral-connect
uses elisp's make-network-process
internally, which creates network connections
spiral-connect
's api receives the host:port as a string, I could augment that to something like user@host:remote-port:local-port
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`
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.
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)
> considering that knowing where your teamās repl run is something that people just know as a consultant I disagree
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.