This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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.
@pataprogramming the :start option is to connect to a remote repl. is there a remote repl running on that ip and port?
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.
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
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
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 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?
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.
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.
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.