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

[Carlo Zancanaro]

>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 like it will be as close to sensible as 
possible. (That is: use the bindings that were current at the point when the 
evaluation was started.)

I just looked into the interruption code, which is the only thing that looks 
like it actually depends on the serial nature of the evaluation. I think it 
would be possible to make it work with parallel evaluations, though, by storing 
a "message id to thread" map on the session instead of a single message id and 
thread. That would let you interrupt the thread for a given evaluation.

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.

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

[Gary Fredericks]

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 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 for this? Given that it's quite easy 
> to make it evaluate them in parallel, I figure there's a reason 
> why it was decided to evaluate them in sequence. 
>
> I have a use-case where I would like to be able to run evaluations 
> in parallel without having to wrap everything in (future ...), so 
> I'm considering writing some middleware to redefine 
> clojure.tools.nrepl.middleware.interruptible-eval/queue-eval to 
> just put things straight on the executor. It seems to work from my 
> limited tests, but are there any reasons why this would break 
> horribly? 
>
> 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.

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

[Colin Fleming]

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 different
> performance characteristics, suitable for different applications.
>
> * One optimizing diffing algorithm aimed to reduce the size of diffs. It
> is an A* based graph search algorithm that is optimized for speed, though
> much slower than the next one, it is still practical.
> * Another is a straightforward tree walking algorithm that is about two
> orders of magnitude faster, but produce suboptimal results.
>
> Hope this library will be of some use for someone. Comments, suggestions
> and contributions are also welcome.
>
> -huahai
>
> --
> 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.

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

[Travis Daudelin]

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 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.

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

[Alex Miller]

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 the clojure.parallel namespace in core - it's 
deprecated and not in the docs but is a wrapper for fork/join from an older 
time.

On Wednesday, May 2, 2018 at 2:00:56 PM UTC-5, Leon Grapenthin wrote:
>
> 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 is not a possibility in my algorithm since forks 
> itself dynamically.
>
>

-- 
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.

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

[Leon Grapenthin]

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 is not a possibility in my algorithm since forks itself 
dynamically.

-- 
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.

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

[Didier]

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 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.

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

[squeegee]

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 incurs the risk that a given evaluation might produce a side 
effect (e.g., a state change) that a later evaluation depends on.

--Steve 

On Wednesday, May 2, 2018 at 6:48:46 AM UTC-4, Carlo Zancanaro wrote:
>
> 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 for this? Given that it's quite easy 
> to make it evaluate them in parallel, I figure there's a reason 
> why it was decided to evaluate them in sequence. 
>
> I have a use-case where I would like to be able to run evaluations 
> in parallel without having to wrap everything in (future ...), so 
> I'm considering writing some middleware to redefine 
> clojure.tools.nrepl.middleware.interruptible-eval/queue-eval to 
> just put things straight on the executor. It seems to work from my 
> limited tests, but are there any reasons why this would break 
> horribly? 
>
> 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.

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

[Carlo Zancanaro]

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 for this? Given that it's quite easy 
to make it evaluate them in parallel, I figure there's a reason 
why it was decided to evaluate them in sequence.


I have a use-case where I would like to be able to run evaluations 
in parallel without having to wrap everything in (future ...), so 
I'm considering writing some middleware to redefine 
clojure.tools.nrepl.middleware.interruptible-eval/queue-eval to 
just put things straight on the executor. It seems to work from my 
limited tests, but are there any reasons why this would break 
horribly?


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.


signature.asc
Description: PGP signature