Separated nrepl code, added CLI options, added failover#220
Separated nrepl code, added CLI options, added failover#220chrisbetz wants to merge 5 commits intoJonyEpsilon:developfrom
Conversation
…nrepl server (without relying on "busy" ports for nrepl startup failure)
…This is necessary to "repair" a broken tunnel, or to re-connect to a restarted nrepl server. However, this is not without problems, as the current REPL state might get lost. At the moment, there's no client-side warning of this happening! That's a big todo!
|
Hi Chris, thanks, this is great :-) That is a feature I'd really like to get into the next release (see #137). I should have time in a few weeks to sit down and put a release together, so will return to this PR then. Thanks again, Jony |
|
Oh, you're welcome. Didn't see that discussion before ;) Just take your time! On Tue, Jun 30, 2015 at 12:35 PM, Jony Hudson notifications@github.com
|
|
There's a broader discussion that might be of some interest too, thinking about what the relationship should be between nREPL, Gorilla etc. It's at #184 in case you'd like to look :-) |
Hi,
I'm not sure whether you're interested in this sort of changes or not, so feel free to just drop this PR. But for my use-case (combining GorillaREPL with ApacheSpark) it's really important, so it might be interesting for others. Main rational is I needed to avoid dependency conflicts.
Here's what I did:
Feel free to take whatever is necessary and wanted and be assured that I find GorillaREPL a really cool project!
Cheers,
Chris
This change is