Command to abort evaluation

[JonyEpsilon]

[JonyEpsilon]

Do what I think should work, but it doesn't ... may have to monitor some real nREPL traffic again to figure out what the difference is :-(

[JonyEpsilon]

Bump out of 0.2.0.

[JonyEpsilon]

This proves extremely difficult to debug! Send what looks like is the right message, same as what the REPLy client sends (I think) but can't get it to work. Not helped by the fact I can't inject my own NREPL version easily with debug statements in it because of this: https://github.com/technomancy/leiningen/issues/1569

Something so simple turning out to be so difficult :-(

[JonyEpsilon]

Give up on this for a second time! As far as I can tell, nREPL isn't always able to handle interrupt messages gracefully, and is sometimes left in a non-functional state. As a test case, running, and then interrupting the following:

(time (reduce +' (range 50000000)))

seems to result in nREPL sending no further done messages for any subsequent evaluations. On the terminal, if I try and run this and then cancel it with ctrl+c I get an exception:

SocketException The transport's socket appears to have lost its connection to the nREPL server
Exception in thread "Thread-3" clojure.lang.ExceptionInfo: Subprocess failed {:exit-code 130}
    at clojure.core$ex_info.invoke(core.clj:4403)
    at leiningen.core.eval$fn__4770.invoke(eval.clj:236)
    at clojure.lang.MultiFn.invoke(MultiFn.java:231)
    at leiningen.core.eval$eval_in_project.invoke(eval.clj:337)
...

So, I'm not sure this something fixable on the Gorilla REPL side at the moment.

[JonyEpsilon]

Going to close this, and will re-open if things change with nREPL's interrupt feature.

[JonyEpsilon]

Re-open, as CIDER's interrupt seems to work just fine.

[dasmoth]

I've been investigating this today. Things seem to have changed quite a bit since the existing feature/interrupt branch, so rather than trying to get that merging, I've re-implemented the basics. There's a minimal version at https://github.com/dasmoth/gorilla-repl.

In my hands, this seems to be working quite reliably so long as you don't try to start a new evaluation following the one you want to cancel.

To get round that limitation, it's going to need some kind of evaluation queue. I'm happy to have a go at this, but would be interested to hear your thoughts about where it should be implemented. It could go client-side rather like the feature/interrupt branch (but there's no longer an evaluator.js so it'll need to go somewhere else -- don't think repl-ws.js is a good fit, so I'd be inclined to add some queueing behaviour to worksheet.js instead?).

However, I wonder if putting it server-side instead might actually be more robust. This shouldn't be too complicated to do, but does mean that the server will need to start understanding at least some NREPL commands rather than relaying them directly.

Any preferences?

[dasmoth]

The "interupt" branch at dasmoth/gorilla-repl is now in a pretty-much usable state.

Rather than implementing an evaluation queue, I've added a check to prevent a new evaluation starting while one is already running. This keeps the "evaluate one segment" implementation pretty simple. There's a little bit of extra complexity to support "evaluate all", though.

This branch is now good enough for my purposes, but I can imagine a couple of refinements:

• There should probably be some kind of lock to prevent modification of worksheets during an "evaluate all".
• In this model, it would be fairly straightforward to abort an "evaluate all" in case a segment reports an error. I think, in general, I'd prefer this behaviour.
• The abort command should probably go back to "abort last evaluation" rather than "attempt to abort selected segment".

What do you think?

[JonyEpsilon]

Hey @dasmoth ... haven't time to look at this yet, but just wanted to send an ACK :-) Will hopefully have a bit of time in the next few days.

[JonyEpsilon]

This is neat! A couple of thoughts:

• I think we should preserve the ability to queue more than one evaluation. I very commonly hit shift+enter a few times to run a few segments in sequence, especially if they're long-running and I want to take a walk etc.
• I think the queueing probably would be better done server-side, as it's quite common to have more than one worksheet open in a project. At the moment you have to be really careful not to evaluate code in both worksheets at once, and it would be better not to have to worry about this.

I'm planning to make some pretty sweeping changes to the way nREPL connections are handled, to address the things talked about in #184 . My current plan is to head towards a single Gorilla process being able to manage multiple nREPL server connections (think like CIDER does). It would be good to sort out exactly how the evaluations should be queued/not-queued as part of that. (Like, for instance, I don't really know whether nREPL properly supports running two evaluations at once - might need to do some experimenting with the terminal client to figure out what is possible).