Re: Why does interruptible-eval from tools.nrepl queue evaluations?

>I think dynamic vars in particular would be problematic. The repl is built >around being able to set! certain vars, and you can't do that to the same >binding from multiple threads. The dynamic thread bindings are established within the function passed to queue-eval, though, so it seems

Re: Why does interruptible-eval from tools.nrepl queue evaluations?

I think dynamic vars in particular would be problematic. The repl is built around being able to set! certain vars, and you can't do that to the same binding from multiple threads. On Wednesday, May 2, 2018 at 5:48:46 AM UTC-5, Carlo Zancanaro wrote: > > Hey there! > > With tools.nrepl, if you

Re: [ANN] editscript: a diffing library for Clojure data

This looks very nice, thank you! On 1 May 2018 at 06:52, wrote: > Hello, > > I am happy to make available a diffing/patching library for Clojure data > structures. > > https://github.com/juji-io/editscript > > Two flavors of diffing algorithms are provided, with very

Re: Spy - Clojure / ClojureScript library for stubs, spies and mocks

This looks great! Great timing, I was just struggling with some unit tests where I need a way to validate if a function was called -- 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

Re: Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

Rich has considered making some of the internal analysis stuff that is in the go macro available via the compiler (so it doesn't have to be re-built in go), but I don't think that includes anything related to channels or blocking takes/puts, unless I'm misremembering. You might want to look at

Re: Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

I remember a Rich Hickey talk on core.async where he mentioned building blocking takes/puts into the compiler, as a possible future extension, making the go macro obsolete. Is that on any roadmap? Tesser I have to look at again, it seemed to go into a similar direction. Fork/Join /w reducers

Re: Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

This seems well suited for tesser https://github.com/aphyr/tesser/blob/master/README.markdown Or you could just look at using fold https://clojure.org/reference/reducers#_reduce_and_fold -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to

Re: Why does interruptible-eval from tools.nrepl queue evaluations?

I suspect it's because queuing up operations is a relatively safe increment in convenience over the most naive implementation: having to wait for each evaluation to complete before submitting the next. Attempting to increasing the convenience further by evaluating expressions in parallel

Why does interruptible-eval from tools.nrepl queue evaluations?

Hey there! With tools.nrepl, if you eval two expressions they get queued up and evaluated in sequence. This means that if I evaluate (Thread/sleep 1), and then immediately evaluate (+ 1 2), then I have to wait ten seconds for the result of 3 to come back. Is there a particular reason