This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-18
Channels
- # aleph (45)
- # aws (4)
- # beginners (56)
- # boot (2)
- # cider (45)
- # clara (2)
- # cljs-dev (9)
- # cljsrn (31)
- # clojure (71)
- # clojure-dusseldorf (8)
- # clojure-gamedev (1)
- # clojure-italy (22)
- # clojure-nl (1)
- # clojure-russia (46)
- # clojure-sg (1)
- # clojure-spec (5)
- # clojure-uk (40)
- # clojurescript (30)
- # community-development (3)
- # cursive (17)
- # data-science (1)
- # datomic (18)
- # emacs (3)
- # figwheel (1)
- # fulcro (19)
- # hoplon (12)
- # jobs (5)
- # leiningen (42)
- # off-topic (12)
- # om (2)
- # onyx (41)
- # re-frame (19)
- # ring-swagger (1)
- # rum (3)
- # shadow-cljs (4)
- # specter (7)
- # unrepl (2)
- # vim (25)
- # yada (24)
Here’s one I haven’t run into before. I’m trying to start a REPL from the command line on OS X (10.12.6), with lein 2.7.1. It starts up fine with just lein repl
but lein repl :start :host 192.168.x.x :port 9009
gives a “connection refused” message.
Not a port problem, as I can start up and connect to netcat on that IP and port.
Doesn’t work if I leave off the port, either.
@pataprogramming the :start option is to connect to a remote repl. is there a remote repl running on that ip and port?
@bfabry: No…isn’t that :connect, not :start? Or are the docs misleading me?
I’m trying to start the REPL to connect to from a VM.
So I could try :headless and see if that allows connection from another process…but I’m also wondering why it isn’t working.
Just tried the same command (:start) inside a Linux VM, with similar results. Hm.
what if you give it 0.0.0.0 as a host
(and @noisesmith beats me to the punch again!)
Definitely weird, if I start with :headless, I can indeed connect from another lein process using :connect.
@pataprogramming it’s better to host the repl on 0.0.0.0 and use ssh with port forwarding
even if it’s only running on a container - a repl is a huge root hole with no security
if you bind to a visible IP it’s just asking for trouble
Do you mean 127.0.0.1? 0.0.0.0 should be all interfaces.
umm… maybe I’m getting this wrong
This is an internal VMware bridge interface, so it’s not actually externally exposed.
OK - yeah - 127.0.0.1 is the safe one - but I still think it’s a better practice to only host on loopback and use ssh to forward the port to another loopback on the client machine
but if you know that’s safe with your vm, go for it
I should have though of port forwarding, I admit…it’s kind of a weird thing I’m trying to do. O
the nice thing with port forwarding is you can use the same work flow with staging, or even prod if you need to
I do most of my dev in a Linux VM, and have been working with Overtone.
oh, with overtone you’ll likely never have a staging or prod box haha
I have a similar setup: host O/S is OS X and I run various O/S in Parallels Desktop. The host REPL needs to bind to an address that can be reached from the VMs. IME with OS X and Parallels, that means either 0.0.0.0 or 127.0.0.1 -- not the 192.* IP.
Overtone needs to run in the Mac context to pick up the MIDI devices, but I want to keep working in my xmonad setup (and the VM’s virtual clock messes badly with synthesis).
(but I may have a different network config to you for my VMs -- I think I just let it pick the default)
what about running the supercollider server on the mac and then forwarding the osc ports to the vm process?
or does overtone abstract the scsynth process in a way that makes that difficult?
Heh, I wasted several commutes trying to get that working before throwing up my hands. You’re on target that Overtone is making some assumptions about scsynth.
with signal processing I always prefer to default to “closer to the actual metal” (whether that means skipping virtualization, using a lower level language, eliminating “helpful” user space drivers that do annoying things like sample rate conversion…)
perhaps this is a hold over from the trauma of trying to do low latency real time work on 1990s laptop hardware
Oh, and Overtone’s MIDI support uses the host OS, rather than routing it through SC. So when I finally manage to coax Overtone into connecting (I had to up the number of allowed connections), I discovered that the Linux JVM was still trying to use the VM’s MIDI devices.
haha wow
Yeah, bare metal is better…if only OS X had a real, multi-desktop tiling WM! So I’m trying to just do the control from the comfy VM environment, and run the synthesis/MIDI on the host OS.
I’ll give the SSH tunnel a shot, thanks for the assistance.
But it does look like there may be some sort of a bug in :start
. Should I submit an issue for this? If I have some time, I can try to trace it down.
Not sure it's a bug. For me, lein repl :start :host 0.0.0.0 :port 9009
works just fine, as does lein repl :start :host 127.0.0.1 :port 9009
. If I try an internal IP (10.0.0.* for me), I get that same connection refused error -- which matches my experience with other server processes on my Mac.
@seancorfield: Is there a reason that it shouldn’t work, if starting one process with :headless
and another process with :connect
does? I’d sort of assumed that :start
would be a combination of the two.
Guessing, it might be that :start always tries connect on the loopback interface…0.0.0.0 listens on loopback, so that would still work.
@pataprogramming I'm not enough of a network guy to know -- I've just never seen lein
connect over a private IP even when I start a headless REPL server on 0.0.0.0.