liverepl
liverepl copied to clipboard
djpowell
nREPL support, possibly via sockets
On top of https://github.com/djpowell/liverepl/issues/6 I'm also considering adding nREPL support so that I can get a couple of benefits:
- attach an external client (lein repl, emacs, etc.)
- get line-editing superior to rlwrap
- have a persistent session (optional)
If I make a persistent session there's some trickiness; opening a port is dangerous since it allows users other than root and the one who launched the JVM to send commands to it, so I'll probably be using domain sockets or fifos or similar instead.
Would this be a feature you'd consider accepting a PR for?
Great I'll take a look when I get the chance. I have a branch (offline) that I started on ages ago, where I tried making it run under lein, and also got rid of the socket repl and made it inject nrepl server, and then use reply as the client. So I'll try and work out where I got with that too.
We have a fork at work that uses lein for building. I'm planning on polishing that up and pushing it to a public place. What I'm thinking at this point is that there would be a total of three artifacts: The client/main jar (complete with options parsing), the agent jar, the server jar, and a tarball. The script would be eliminated, but a sample one would be provided that would pass the right options to the client jar for development mode.
I think people's needs vary quite a bit in terms of deployment; at work it's much easier to pull jar files from a Maven repository and have our own variant on the shell script anyhow. One change we made was the addition of a -F (force) flag that you have to pass; if you don't include it, you get a scary warning about using liverepl carefully and the script exits. (Liverepl causes a classloader to leak on each invocation under certain circumstances which we haven't yet figured out, but it might involve Hibernate. Whenever we use it for debugging, we bounce the server afterwards to avoid permgen exhaustion.) We could implement that as a wrapper around liverepl.sh, but at this point we don't, and that works fine.
I'll push my v1.2 branch soonish, that sounds vaguely similar - it moves to having a lein plugin, and separate dependencies on the client, server, and agent.
In the meantime it is here: https://bitbucket.org/djpowell/liverepl/src/37778f65282e00436c1ff38ef199fd23c432b47d?at=1.2-alpha
Btw, for tracking classloader leaks, jvisualvm has a button called Heap Dump on the Monitor tab. This opens up an explorable UI that you might be able to use to find one of the liverepl classes, clojure classes, or classloader, and then you can follow the references to see where it is being hung on to from.
I don't think I have access to the bitbucket link.
I just pushed our changes to a public repo: https://github.com/brightcove/liverepl -- this incorporates the changes I was making on timmc/liverepl as well as some internal changes.
The group and artifact change to com.brightcove.___ but that was just because we had a private fork; if public development continues, it would make sense to switch back to your group and artifact IDs.
Here's the big change I pushed today: https://github.com/brightcove/liverepl/commit/c32d56ebbc9dac3abbfef4ea314c442b0721ddc8 -- obviously, feel free to grab anything useful.
ETA: Oh, and my big plan: Add GNU getopt to the client so that it can take multiple paths to extra jars, incorporate nREPL client, etc.
Would you be able to go ahead and push the v1.2 branch to a public place? I may be able to work on my fork of liverepl some this week, and it would be nice to refer to those commits publicly.
Hi, Thanks for looking at this - sounds great - I'll try to push them across to github as-is, so you can reference them from there...
lein sub install - to deploy the artifacts locally; then add [lein-liverepl "1.2.0-SNAPSHOT"] to your plugins, and you should be able to run lein liverepl
Thanks! I ended up not getting a chance to work on liverepl this week, but this will be good for the next time.