View number of concurrent requests #155

Closed
samaaron opened this Issue Oct 30, 2012 · 9 comments

3 participants

@samaaron

Slime has a feature whereby it displays the number of currently executing requests in the status bar. It would be very useful to have this in nrepl.el

@bbatsov
clojure-emacs member

Could you be a bit more specific about the functionality in question. I don't recall that particular stat at all.

@samaaron

In slime, every time you evaluated a form, it would create a new thread to execute the evaluation on the server. Somewhere there would be a count of the current number of live threads which would be displayed in the status bar. When a response has been received then the thread count would be reduced by one.

Essentially when there are outstanding requests waiting to be received from the server as a result of evaluating some form, the number of those outstanding requests is visible in the status bar.

@bbatsov
clojure-emacs member

I see. We'll basically have to display the number of items in nrepl-requests and update it when requests are added and removed. I'll think about the UI and I'll probably implement this at some point.

@bbatsov
clojure-emacs member

Based on @cemerick's comment in #237 I don't think that implementing this makes much sense for an nREPL backend.

@bbatsov bbatsov closed this Jul 22, 2014
@samaaron

Shame, this was a lovely feature in slime/swank.

The fact that @cemerick suggests that nREPL evaluates in strict order is very frustrating. When I live code I often fire off a long running request and want to be able to fire off shorter requests but can't with cider because it blocks.

Whilst I'm here I also find that having to manually download cider nrepl middleware separately frustrating too. This is another area where I preferred slime's approach. I talked to @cemerick about this a while back. He suggested he might make it possible to inject new middleware dynamically. I'm not sure if he got round to it or not.

@bbatsov
clojure-emacs member

Whilst I'm here I also find that having to manually download cider nrepl middleware separately frustrating too. This is another area where I preferred slime's approach. I talked to @cemerick about this a while back. He suggested he might make it possible to inject new middleware dynamically. I'm not sure if he got round to it or not.

While not ideal it's the best we can do for now. I'm quite sure that the added benefits of having the extra middleware far outweigh the inconvenience caused by its installation. That said, I'd prefer it if it was possible to automate the process.

@cemerick

nREPL evaluates expressions in order within the context of a given session. This is the only way to preserve user expectations around the environment, i.e. the values of dynamic vars like *1, etc. It is impossible to have multiple concurrent evaluations and be able to reason about what the state of your dynamic environment is going to be after all evaluations have completed.

There is nothing stopping cider (or any other tooling) from allowing users to send code for evaluation on a cloned session or on no session at all (which will implicitly create a session, eval, and dispose of the temporary session). These evaluations can be made completely independently and will not depend upon each other in any way.

I never fleshed out the middleware discovery/installation stuff. @technomancy took a whack at the concept with https://github.com/technomancy/nrepl-discover, though I don't know the status of it.

@samaaron
@bbatsov
clojure-emacs member

Feel free to open a ticket regarding this. If there's enough interest I'll implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment