Re: Using a try catch inside a future

Also, it means that bug is not in future or threads but in threaded-function itself which is swallowing all the exceptions.. Future is cancelled but it is just that bad-thread is not stopping. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post

Re: Using a try catch inside a future

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html#cancel%28boolean%29 may explain why future-cancelled? is returning true.. After this method returns, subsequent calls to isDone()

Re: Using a try catch inside a future

Ah, the weirdness was because I forgot to make future-try wait for the future it creates. (defmacro future-try [& body] `(let [thread-atom# (atom nil)] (try (reset! thread-atom# (future (try ~@body))) *@@thread-atom#* (catch Exception e# (if-let [thread#

Re: Using a try catch inside a future

Here's something to explore. (defmacro future-try [& body] `@(future (try ~@body))) (defn test-f2 [initial-v] (let [n (atom initial-v)] [n (future (while (not (Thread/interrupted)) (future-try (Thread/sleep 5000) (swap! n inc)

Re: Using a try catch inside a future

One technique for addressing this sort of issue has been described in Haskell-land: https://www.schoolofhaskell.com/user/snoyberg/general-haskell/exceptions/catching-all-exceptions http://hackage.haskell.org/package/enclosed-exceptions I'm unaware of any comparable clojure library, but the same

Re: Using a try catch inside a future

Hi Ashish, It actually appears that there is no exception thrown by default when future-cancel is called on the thread *unless* you manage to overlook java functions that include some type of interrupt status handling. As I managed to do. Take a look at my below test-interrupt-status-2 that

Re: Using a try catch inside a future

Hi, this actually boils down to a strong case of read the manual and one surprising effect. The executive summary: From the Java SE 8 docs description for Thread/sleep: Throws:IllegalArgumentException - if

Re: is reduce/reduced faster than loop/recur?

Yes, and it happens for most collections. Vectors, maps, etc. There's even a fast path for reduce-kv on maps that doesn't create key value entry objects. Timothy On Fri, Apr 29, 2016 at 6:06 PM, Mark Engelberg wrote: > So you're saying that this is an optimization

Re: is reduce/reduced faster than loop/recur?

So you're saying that this is an optimization that is automatically called when you invoke Clojure's standard reduce function on something like a vector? On Fri, Apr 29, 2016 at 1:14 PM, Alex Miller wrote: > The main internal protocol is really CollReduce for collections

Re: which GC optimizations work better with Clojure?

It depends. CMS or G1 would be better in common cases as you said, clojure runtime has many short-lived objects. We are using G1 in your production. But sometimes you would prefer system throughput rather than GC pause time, you may try Parallel GC. 2016-04-29 19:02 GMT+08:00 Camilo Roca

Re: is reduce/reduced faster than loop/recur?

The main internal protocol is really CollReduce for collections that can reduce themselves. InternalReduce is for concrete seq implementations that can reduce themselves. For cases where you are creating new things, you can also plug in a little more easily by implementing the IReduceInit

Re: is reduce/reduced faster than loop/recur?

puzzler, No, Clojure actually has quite a lot of protocols for reducing "things". But they are so many that I got lost in which does what and how, so I wanted a clarification on the subject. Alex miller, excellent answer already gave me some overview of the topic. Here is a link to Clojure's

Re: is reduce/reduced faster than loop/recur?

By "internal reduce", are you all talking about the Clojure reducers library, or something else? -- 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

Re: Schemas for DSLs on top of Clojure

The convention that I've seen among the Clojure community is to represent these kinds of things as data structures, and define your contraints using something like https://github.com/plumatic/schema On Friday, April 29, 2016 at 1:10:29 PM UTC-5, Olek wrote: > > Hi! > > Clojure data structures

Schemas for DSLs on top of Clojure

Hi! Clojure data structures can express tree data structures, same as in XML what is ideal for DSL. Especially that thanks to macros you can also change the evaluation order and hide execution complexity and treat DSL in terms of declarations and not statements nor functions. What is more the

Re: is reduce/reduced faster than loop/recur?

Both loop/recur and reduction/transduce via IReduce are similar in doing looping without consuming stack, building up an accumulated value, and not allocating memory. reduce/transduce always take an input collection - if that collection can be traversed via internal reduction or sequential

Re: Using a try catch inside a future

To stop any thread.. interrupts are send to it. And threads handle this by throwing exception so that programmer can decide what to do depending upon the kind of exception it gets. (you may get different exceptions) Since you are catching the exception, your thread is never stopped.. and

Re: is reduce/reduced faster than loop/recur?

hey Jozef, would you mind sharing a blog post or piece of documentation where I can learn about those strategies? The only one that I know so far is the local primitives for fast arithmetic, but besides from that I haven't heard of any ther optimization for loop/recur strategy :/ El

Re: is reduce/reduced faster than loop/recur?

There are many ways on how you can improve the performance of loop/recur, and most of them depends on the type of a thing you are iterating through. With reducers (and transducers), the iteration part is decoupled from the reduction part, so they offer a mechanism that chooses the optimal

which GC optimizations work better with Clojure?

Following this thread: http://stackoverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world I was wondering if anybody has some experience regarding GC optimizations that would work better for Clojure than the default: stop-the-world approach. My point being that given

is reduce/reduced faster than loop/recur?

I have been hearing a lot of Clojure's use of an internalReduce protocol, which seems to speed up things when using reduce. Now the thing is that a lot of people also claim that tail-call-recursion is also pretty fast, which lets me wondering: - if I could replace a loop/recur with an

Re: Porting Clojure to Native Platforms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.04.2016 16:29, Jason Felice wrote: > > > On Tue, Apr 26, 2016 at 7:42 PM, Plínio Balduino > > wrote: > > > * Is there a way to compile C++ code at runtime? This would be > essential for the