By channel you mean sessions right? That's a simple way to circumvent the serialized nature of evaluations - you can just spin a new session for each evaluation. Never benchmarked what's the overhead of this, though.
On 4 May 2018 at 00:36, Gary Fredericks <fredericksg...@gmail.com> wrote: > I used the hacky tactic of just sending messages through the nrepl > channels (while the eval is blocked) to implement this: > https://github.com/gfredericks/debug-repl > > Gary Fredericks > (803)-295-0195 > fredericksg...@gmail.com > gfredericks.com > > On Thu, May 3, 2018 at 4:31 PM, Carlo Zancanaro <carlozancan...@gmail.com> > wrote: > >> >> On Thu, May 03 2018, Gary Fredericks wrote: >> >>> Separately, I use this macro <https://github.com/gfrederick >>> s/repl-utils#bg> for running background things in the repl. It probably >>> targets different concerns, but seems related at least. >>> >> >> My use case is quite different. Requiring someone to decide ahead of time >> to run code in the background (ie. by wrapping it in another form) won't >> work for me at all. >> >> I'm trying to write a Common Lisp interactive restart system, somewhat >> similar to what Slime gives you. It actually works pretty well, but it's >> often helpful to be able to redefine things, or to run some code to change >> a data structure, before selecting a restart. While waiting for a restart >> selection the eval thread is blocked, though, so other evaluations have to >> happen in another thread. The nrepl protocol seems like it was designed for >> this, given how asynchronous it is, so I was surprised that >> interruptible-eval explicitly queued up evaluations and ran them >> sequentially. >> >> I've ended up doing this as a solution: https://github.com/czan/dont-g >> ive-up.nrepl/blob/acc20e0c25aa90a5c991b9cd1f7cc4abe2f1cd6b/s >> rc/dont_give_up/nrepl.clj#L335. This isn't perfect. There are further >> modifications required to be able to interrupt evaluations other than the >> most recent one, but it works well enough to be useful. If anyone has a >> reason why this is a terrible idea, I'm all ears. >> >> Carlo >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
