Re: Using a try catch inside a future

[Ashish Negi]

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 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: Using a try catch inside a future

[Ashish Negi]

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() 

 
will always return true. Subsequent calls to isCancelled() 

 
will always return true if this method returned true.

Thread will not stop.. but future is now cancelled.
Future represents some value in future and it should have one value after 
it is done.
The values that future is `still` calculating will now be not useful since 
its status is cancelled.
A cancelled future can also have some value but it's status means that it 
is not usable.

** It is true that i am trying to put logic after seeing the results. :(
Do correct me if something is wrong.


On Saturday, 30 April 2016 05:50:38 UTC+5:30, Tom Bodenheimer wrote:
>
> 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 the value of millis is negativeInterruptedException 
> 
>  - 
> if any thread has interrupted the current thread. The *interrupted status* of 
> the current thread is cleared when this exception is thrown.
>
> The key to my misunderstanding is right there is the InterruptedException 
> doc - the interrupted status is cleared by Thread/sleep.
>
> The remaining surprise is that the future-cancel call actually returns 
> true for all the cases (which is different from what I originally wrote). 
>  Check out the below examples.
>
> Example 1 - just a normal future with no try/catch
> user> (defn test-interrupt-status-1 [init-v]
>   (let [n (atom init-v)]
> [n
>  (future (while (not (Thread/interrupted))
>(swap! n inc)))]))
> #'user/test-interrupt-status-1
> user> (def test-1 (test-interrupt-status-1 10))
> #'user/test-1
> user> (future-cancel (test-1 1))
> true
> user> (future-cancelled? (test-1 1))
> true
> user> @(test-1 0)
> 43202690
> user> @(test-1 0)
> 43202690
>
> Example 2 - a future that contains a try/catch but doesn't have any sleep 
> included
> Notice that future-cancel works fine even with the try/catch - the atom 
> isn't updated
> after the future-cancel is called on the future.
> user> (defn test-interrupt-status-2 [init-v]
>   (let [n (atom init-v)]
> [n
>  (future (while (not (Thread/interrupted))
>(try
>  (swap! n inc)
>  (catch Exception e (println (str "Exception:\t" e 
> "\nisInterrupted:\t" (.isInterrupted (Thread/currentThread]))
> #'user/test-interrupt-status-2
> user> (def test-2 (test-interrupt-status-2 10))
> #'user/test-2
> user> (future-cancel (test-2 1))
> true
> user> (future-cancelled? (test-2 1))
> true
> user> @(test-2 0)
> 44066815
> user> @(test-2 0)
> 44066815
>
> Example 3 - now we have a future which includes a try/catch AND A 
> Thread/sleep
> Calling future-cancel returns true (!!) and we see that the Thread/sleep
> has cleared the interrupt status of the thread (e.g., the .isInterrupted 
> is false
> for the thread).  What is interesting here is that future-cancelled? 
> returns true
> but the thread is actually still happily running because the interrupt 
> status was 
> reset.  I'm not sure what I think about this - I hate surprises, but the 
> docs are pretty
> clear on what is happening here.  
> user> (defn test-interrupt-status-3 [init-v]
>   (let [n (atom init-v)]
> [n
>  (future (while (not (Thread/interrupted))
>(try
>  (Thread/sleep 1)
>  (swap! n inc)
>  (catch Exception e (println (str "Exception:\t" e 
> "\nisInterrupted:\t" (.isInterrupted (Thread/currentThread]))
> #'user/test-interrupt-status-3
> user> (def test-3 (test-interrupt-status-3 10))
> #'user/test-3
> user> (future-cancel (test-3 1))
> trueException: java.lang.InterruptedException: sleep interrupted
> isInterrupted: false
> user> (future-cancelled? (test-3 1))
> true
> user> @(test-3 0)
> 12
> user> @(test-3 0)
> 13
> user> (future-cancel (test-3 1))
> false
> user> (future-cancelled? (test-3 1))
> true
>
>
> On Thursday, April 28, 2016 at 11:48:29 AM UTC-4, Tom Bodenheimer wrote:
>>
>> Hi all,
>>
>> I have recently been playing with futures and have stumbled on the 
>> following situation.
>>
>> (defn test-f1 [initial-v]
>>   (let [n (atom initial-v)]
>> [n
>>  (future (while (not (Thread/interrupted))
>>(Thread/sleep 5000)
>>(swap! n inc)
>>(println @n)))]))
>>
>> (def t1 

Re: Using a try catch inside a future

[Dan Burton]

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# @thread-atom#]
   (future-cancel thread#))
 (throw e#)

Using this does cancel the inner thread as soon as you cancel the outer
one, it does run the "catch" branch of code, and it does stop the loop. You
can even replace (while (not (Thread/interrupted)) ...) with (while true
...) and it still behaves this way. It might seem unexpected or undesirable
that it runs the "catch" branch, but it does seem like a good idea to let a
future-try/catch block clean up after itself. /shrug

-- Dan Burton

On Fri, Apr 29, 2016 at 6:26 PM, Dan Burton 
wrote:

> 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)
>  (println @n)
>  (catch Exception e (println "whoops")]))
>
> (def t2 (test-f2 11))
>
> test-f2 is the same as in your original email, except it uses future-try
> instead of try.
> It seems to allow you to correctly cancel the thread. It doesn't hit the
> "whoops" branch.
>
> But something is off. It doesn't stop the inner block, and the final
> number is printed *after* the outer future is cancelled. I would expect
> canceling a future to cancel all of its children, but apparently this is
> not the case.
>
> --
>
> Want to see some really weird stuff? Here's how I tried to make future-try
> attempt to cancel its children:
>
> (defmacro future-try [& body]
>   `(let [thread-atom# (atom nil)]
>  (try
>(reset! thread-atom# (future (try ~@body)))
>(catch Exception e#
>  (if-let [thread# @thread-atom#]
>(future-cancel thread#))
>  (throw e#)
>
> Try running (def f2 (test-f2 11)) with that future-try, and it goes crazy.
> After waiting 5 seconds, it spews out numbers up to around 2031, then stops
> because (second f2) wasn't able to allocate any more threads. I have no
> explanation for this.
>
> -- Dan Burton
>
> On Fri, Apr 29, 2016 at 5:25 PM, Tom Bodenheimer <
> tom.bodenhei...@gmail.com> wrote:
>
>> 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 includes a try/catch
>> loop to see what I mean.
>>
>> Thanks.
>>
>>
>> On Friday, April 29, 2016 at 9:35:39 AM UTC-4, Ashish Negi wrote:
>>>
>>> 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
>>> hence future-cancel returns false.
>>>
>>> If you throw again.. exception would unwind your while loop and stop the
>>> thread.
>>> hence.. future-cancel is able to stop the thread and returns true.
>>>
>>> --
>> 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: Using a try catch inside a future

[Dan Burton]

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)
 (println @n)
 (catch Exception e (println "whoops")]))

(def t2 (test-f2 11))

test-f2 is the same as in your original email, except it uses future-try
instead of try.
It seems to allow you to correctly cancel the thread. It doesn't hit the
"whoops" branch.

But something is off. It doesn't stop the inner block, and the final number
is printed *after* the outer future is cancelled. I would expect canceling
a future to cancel all of its children, but apparently this is not the case.

--

Want to see some really weird stuff? Here's how I tried to make future-try
attempt to cancel its children:

(defmacro future-try [& body]
  `(let [thread-atom# (atom nil)]
 (try
   (reset! thread-atom# (future (try ~@body)))
   (catch Exception e#
 (if-let [thread# @thread-atom#]
   (future-cancel thread#))
 (throw e#)

Try running (def f2 (test-f2 11)) with that future-try, and it goes crazy.
After waiting 5 seconds, it spews out numbers up to around 2031, then stops
because (second f2) wasn't able to allocate any more threads. I have no
explanation for this.

-- Dan Burton

On Fri, Apr 29, 2016 at 5:25 PM, Tom Bodenheimer 
wrote:

> 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 includes a try/catch
> loop to see what I mean.
>
> Thanks.
>
>
> On Friday, April 29, 2016 at 9:35:39 AM UTC-4, Ashish Negi wrote:
>>
>> 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
>> hence future-cancel returns false.
>>
>> If you throw again.. exception would unwind your while loop and stop the
>> thread.
>> hence.. future-cancel is able to stop the thread and returns true.
>>
>> --
> 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: Using a try catch inside a future

[Dan Burton]

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 technique
probably works.

A simpler technique in this case would be to only catch the kinds of
exceptions that you expect the inner block to throw, rather than "catching
all exceptions" with (catch Exception e ...).

-- Dan Burton

On Fri, Apr 29, 2016 at 6:35 AM, Ashish Negi 
wrote:

> 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
> hence future-cancel returns false.
>
> If you throw again.. exception would unwind your while loop and stop the
> thread.
> hence.. future-cancel is able to stop the thread and returns true.
>
> --
> 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: Using a try catch inside a future

[Tom Bodenheimer]

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 includes a try/catch 
loop to see what I mean.

Thanks.

On Friday, April 29, 2016 at 9:35:39 AM UTC-4, Ashish Negi wrote:
>
> 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 
> hence future-cancel returns false.
>
> If you throw again.. exception would unwind your while loop and stop the 
> thread.
> hence.. future-cancel is able to stop the thread and returns true.
>
>

-- 
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: Using a try catch inside a future

[Tom Bodenheimer]

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 the value of millis is negativeInterruptedException 
 
- 
if any thread has interrupted the current thread. The *interrupted status* of 
the current thread is cleared when this exception is thrown.

The key to my misunderstanding is right there is the InterruptedException 
doc - the interrupted status is cleared by Thread/sleep.

The remaining surprise is that the future-cancel call actually returns true 
for all the cases (which is different from what I originally wrote).  Check 
out the below examples.

Example 1 - just a normal future with no try/catch
user> (defn test-interrupt-status-1 [init-v]
  (let [n (atom init-v)]
[n
 (future (while (not (Thread/interrupted))
   (swap! n inc)))]))
#'user/test-interrupt-status-1
user> (def test-1 (test-interrupt-status-1 10))
#'user/test-1
user> (future-cancel (test-1 1))
true
user> (future-cancelled? (test-1 1))
true
user> @(test-1 0)
43202690
user> @(test-1 0)
43202690

Example 2 - a future that contains a try/catch but doesn't have any sleep 
included
Notice that future-cancel works fine even with the try/catch - the atom 
isn't updated
after the future-cancel is called on the future.
user> (defn test-interrupt-status-2 [init-v]
  (let [n (atom init-v)]
[n
 (future (while (not (Thread/interrupted))
   (try
 (swap! n inc)
 (catch Exception e (println (str "Exception:\t" e 
"\nisInterrupted:\t" (.isInterrupted (Thread/currentThread]))
#'user/test-interrupt-status-2
user> (def test-2 (test-interrupt-status-2 10))
#'user/test-2
user> (future-cancel (test-2 1))
true
user> (future-cancelled? (test-2 1))
true
user> @(test-2 0)
44066815
user> @(test-2 0)
44066815

Example 3 - now we have a future which includes a try/catch AND A 
Thread/sleep
Calling future-cancel returns true (!!) and we see that the Thread/sleep
has cleared the interrupt status of the thread (e.g., the .isInterrupted is 
false
for the thread).  What is interesting here is that future-cancelled? 
returns true
but the thread is actually still happily running because the interrupt 
status was 
reset.  I'm not sure what I think about this - I hate surprises, but the 
docs are pretty
clear on what is happening here.  
user> (defn test-interrupt-status-3 [init-v]
  (let [n (atom init-v)]
[n
 (future (while (not (Thread/interrupted))
   (try
 (Thread/sleep 1)
 (swap! n inc)
 (catch Exception e (println (str "Exception:\t" e 
"\nisInterrupted:\t" (.isInterrupted (Thread/currentThread]))
#'user/test-interrupt-status-3
user> (def test-3 (test-interrupt-status-3 10))
#'user/test-3
user> (future-cancel (test-3 1))
trueException: java.lang.InterruptedException: sleep interrupted
isInterrupted: false
user> (future-cancelled? (test-3 1))
true
user> @(test-3 0)
12
user> @(test-3 0)
13
user> (future-cancel (test-3 1))
false
user> (future-cancelled? (test-3 1))
true


On Thursday, April 28, 2016 at 11:48:29 AM UTC-4, Tom Bodenheimer wrote:
>
> Hi all,
>
> I have recently been playing with futures and have stumbled on the 
> following situation.
>
> (defn test-f1 [initial-v]
>   (let [n (atom initial-v)]
> [n
>  (future (while (not (Thread/interrupted))
>(Thread/sleep 5000)
>(swap! n inc)
>(println @n)))]))
>
> (def t1 (test-f1 11))
>
> This works as expected.  I see the println outputs, can @(t1 0) and 
> (future-cancel (t1 1)) returns true.
>
> Then I have:
>
> (defn test-f2 [initial-v]
>   (let [n (atom initial-v)]
> [n
>  (future (while (not (Thread/interrupted))
>(try
>  (Thread/sleep 5000)
>  (swap! n inc)
>  (println @n)
>  (catch Exception e (println "whoops")]))
>
> (def t2 (test -f2 11))
>
> The same except now my while has a (try ... (catch Exception e ...). 
>  However, now (future-cancel (t2 1)) returns false and the future cannot be 
> cancelled - I also see the "whoops" at the REPL.  Seeing that "whoops" made 
> me wonder if the interrupt that would shutdown the thread is raising an 
> exception that is being caught by my (try  (catch ...)) block, thus 
> never interrupting the thread. 
>
> I made a change to throw the exception again:
>
> (defn test-f3 [initial-v]
>   (let [n (atom initial-v)]
> [n
>  (future (while (not (Thread/interrupted))
>(try
>  (Thread/sleep 5000)
>  (swap! n inc)
>  (println @n)
>  (catch Exception e (do (println 

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

[Timothy Baldridge]

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 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 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 (reduce with an init
>> value) or IReduce (extends IReduceInit for the case where an init value is
>> not supplied) Java interfaces. I would generally prefer these if you are
>> creating a new thing.
>>
>>
>> On Friday, April 29, 2016 at 2:41:10 PM UTC-5, Camilo Roca wrote:
>>>
>>> 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 protocols for reduce:
>>> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj
>>> 
>>>
>>> El viernes, 29 de abril de 2016, 21:17:42 (UTC+2), puzzler escribió:

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



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: is reduce/reduced faster than loop/recur?

[Mark Engelberg]

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 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 (reduce with an init value) or
> IReduce (extends IReduceInit for the case where an init value is not
> supplied) Java interfaces. I would generally prefer these if you are
> creating a new thing.
>
>
> On Friday, April 29, 2016 at 2:41:10 PM UTC-5, Camilo Roca wrote:
>>
>> 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 protocols for reduce:
>> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj
>> 
>>
>> El viernes, 29 de abril de 2016, 21:17:42 (UTC+2), puzzler escribió:
>>>
>>> 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 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: which GC optimizations work better with Clojure?

[dennis zhuang]

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 :

>
> 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 Clojure's immutable data structures, there is a
> lot of GC that is performed on young-objects which I guess could be
> optimized with some GC tweaks.
>
> Has anybody experience with something similar?
>
> So far the only reference that I have of a Clojure project using such
> optimizations is Overtone:
> https://github.com/overtone/overtone/blob/master/project.clj
>
> Which scenarios do you think that call for GC tweaks in Clojure?
>
> --
> 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.
>



-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

-- 
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: is reduce/reduced faster than loop/recur?

[Alex Miller]

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 (reduce with an init value) or 
IReduce (extends IReduceInit for the case where an init value is not 
supplied) Java interfaces. I would generally prefer these if you are 
creating a new thing.


On Friday, April 29, 2016 at 2:41:10 PM UTC-5, Camilo Roca wrote:
>
> 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 protocols for reduce: 
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj
>  
> 
>
> El viernes, 29 de abril de 2016, 21:17:42 (UTC+2), puzzler escribió:
>>
>> 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 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: is reduce/reduced faster than loop/recur?

[Camilo Roca]

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 protocols for reduce: 
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj

El viernes, 29 de abril de 2016, 21:17:42 (UTC+2), puzzler escribió:
>
> 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 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: is reduce/reduced faster than loop/recur?

[Mark Engelberg]

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 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: Schemas for DSLs on top of Clojure

[Michael Willis]

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 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 grammar 
> of such structure is simplified to what you can see in XML.
> For example let take the XML example:
>
> 
> 
> 
> 
>
> Now lets look at Clojure:
>
> (books
>   (book { :iban "31232" :title "some title" :author "some author" })
>  (book { :ban "43232" :title "another title2" :author "another author 2" 
> }) )
>
> You can notice that when you build macros & functions for that you have 
> simple structure of input arguments like:
>
> (defmacro/defn books[ attrs & books-col ]
>(do some stuff))
>
> (defn book[ attrs ]
>   (do some stuff))
>
> Now all you need is to slurp the specification made in terms of created 
> DSL, call eval on it and as the result of execution you will spit the 
> resulting data/mutate the state/do side effect.
> Finally for XML you can create XSD to constraint possibilities of tags 
> which can be put into DSL.
> But as you can see, such possibility is missing for Clojure. Do you have 
> any ready tool for that or do I have to create one?
>
> Thanks in advance,
> Olek
>
>
>
>

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

Schemas for DSLs on top of Clojure

[Olek]

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 grammar 
of such structure is simplified to what you can see in XML.
For example let take the XML example:






Now lets look at Clojure:

(books
  (book { :iban "31232" :title "some title" :author "some author" })
 (book { :ban "43232" :title "another title2" :author "another author 2" }) 
)

You can notice that when you build macros & functions for that you have 
simple structure of input arguments like:

(defmacro/defn books[ attrs & books-col ]
   (do some stuff))

(defn book[ attrs ]
  (do some stuff))

Now all you need is to slurp the specification made in terms of created 
DSL, call eval on it and as the result of execution you will spit the 
resulting data/mutate the state/do side effect.
Finally for XML you can create XSD to constraint possibilities of tags 
which can be put into DSL.
But as you can see, such possibility is missing for Clojure. Do you have 
any ready tool for that or do I have to create one?

Thanks in advance,
Olek



-- 
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: is reduce/reduced faster than loop/recur?

[Alex Miller]

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 
iteration, then I would favor using reduce over loop/recur. 

Take for example a vector, which is possibly the most interesting case with 
the most options. In a loop/recur how are you going to walk through the 
vector's elements? The most obvious way is to using the sequential 
functions like first/next/rest. Importantly, rest is going to give you a 
sequence over the vector, not the vector itself, which will incur extra 
cost. That said, the vector sequence is really fast - as much of the time 
it's just walking through an internal array node bumping an index. Or you 
might do indexed lookups into the vector ala nth. Your "iteration" has less 
overhead but on each index you must re-traverse the nodes of the vector.

Compare to a vector doing internal reduce - this is effectively an internal 
iteration that walks through the nodes of the vector data structure, 
evaluating the reduction function on each item it finds. There is no seq 
overhead and no re-traversal.

It's hard for me to say which of these is fastest without benchmarking a 
particular case, and it will matter a lot how many things are in the vector 
(as that affects the cost of lookup by index). My suspicion is that usually 
the cost for any of these is dominated by the function being applied per 
element, not by the iteration method.

loop/recur is beneficial in cases where the iteration is not based on 
traversing a collection (could be incrementing a counter, evaluating a 
function, iterating an external resource, etc), or traverses multiple 
collections in parallel, or any other "not sequentially traversing a 
collection" use case. Additionally, loop/recur is the only way in Clojure 
to get a loop that retains long or double primitives throughout the loop so 
for hot math loops you should definitely prefer loop/recur.

Alex


On Friday, April 29, 2016 at 5:46:03 AM UTC-5, Camilo Roca wrote:
>
>
> 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 equivalent reduce/reduced 
> approach, do I see performance gains?
>
> Obviously the immediate answer is just "benchmark it", but so far I 
> haven't found an stable solution to this question. The benchmark seems to 
> go sometimes for loop/recur and some others for reduce/reduced. I also know 
> that when doing primitive math, loop/recur performs better than 
> reduce/reduced, but I was wondering in which cases (regardless of idiomatic 
> or nor) would a reduce approach be preferred over a loop/recur?
>
> Any thoughts on this?
>

-- 
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: Using a try catch inside a future

[Ashish Negi]

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 
hence future-cancel returns false.

If you throw again.. exception would unwind your while loop and stop the 
thread.
hence.. future-cancel is able to stop the thread and returns true.

-- 
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: is reduce/reduced faster than loop/recur?

[Camilo Roca]

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 viernes, 29 de abril de 2016, 13:21:47 (UTC+2), Jozef Wagner escribió:
>
> 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 
> iteration strategy for the collection that is passed in.
>
> On Fri, Apr 29, 2016 at 12:46 PM, Camilo Roca  > wrote:
>
>>
>> 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 equivalent reduce/reduced 
>> approach, do I see performance gains?
>>
>> Obviously the immediate answer is just "benchmark it", but so far I 
>> haven't found an stable solution to this question. The benchmark seems to 
>> go sometimes for loop/recur and some others for reduce/reduced. I also know 
>> that when doing primitive math, loop/recur performs better than 
>> reduce/reduced, but I was wondering in which cases (regardless of idiomatic 
>> or nor) would a reduce approach be preferred over a loop/recur?
>>
>> Any thoughts on this?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: is reduce/reduced faster than loop/recur?

[Jozef Wagner]

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
iteration strategy for the collection that is passed in.

On Fri, Apr 29, 2016 at 12:46 PM, Camilo Roca  wrote:

>
> 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 equivalent reduce/reduced
> approach, do I see performance gains?
>
> Obviously the immediate answer is just "benchmark it", but so far I
> haven't found an stable solution to this question. The benchmark seems to
> go sometimes for loop/recur and some others for reduce/reduced. I also know
> that when doing primitive math, loop/recur performs better than
> reduce/reduced, but I was wondering in which cases (regardless of idiomatic
> or nor) would a reduce approach be preferred over a loop/recur?
>
> Any thoughts on this?
>
> --
> 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.

which GC optimizations work better with Clojure?

[Camilo Roca]

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 Clojure's immutable data structures, there is a 
lot of GC that is performed on young-objects which I guess could be 
optimized with some GC tweaks.

Has anybody experience with something similar?

So far the only reference that I have of a Clojure project using such 
optimizations is Overtone: 
https://github.com/overtone/overtone/blob/master/project.clj

Which scenarios do you think that call for GC tweaks in Clojure?

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

is reduce/reduced faster than loop/recur?

[Camilo Roca]

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 equivalent reduce/reduced 
approach, do I see performance gains?

Obviously the immediate answer is just "benchmark it", but so far I haven't 
found an stable solution to this question. The benchmark seems to go 
sometimes for loop/recur and some others for reduce/reduced. I also know 
that when doing primitive math, loop/recur performs better than 
reduce/reduced, but I was wondering in which cases (regardless of idiomatic 
or nor) would a reduce approach be preferred over a loop/recur?

Any thoughts on this?

-- 
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: Porting Clojure to Native Platforms

[Christian Weilbach]

-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 REPL and for Macros. - I never heard about on
> demand native code generation and execution. I think it could be a
> paradise for viruses, but I know almost nothing about this field.
> Unless of course you're generating code for (your own|a) virtual
> machine, so the rules are different.
> 
> 
> There is a Scheme (I can't remember which) that generates C, spawns
> the compiler, links and loads a dynamic library, then invokes the
> code.  I'm having a brain fart because I want to say it's Gambit
> but Gambit actually has an interpreter.  Maybe it was CHICKEN?

https://github.com/bertfrees/cljc.repl also works this way.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXIwRVAAoJEICbLivqiPOFyo8P/0PgnVHkAroD+fTUTFR5ULjX
CzrEBycHYd4ot1qbRKGW4kNJ/MC+NhuT7TPGcMbnnhULrTZX+A04NTaXaUhKahtO
pO4xspkxjXRJdXQwno7AyqLSOnutdSvjU3aECsqTJN17dxt0+YNjMvyb1dp1PHMr
2aofDx6Pu4UwEbBtqDe8qPWADwcBhNj+Ci5oT447qFZyBD4V1+wQwsdX6xJjiYz3
nyghxasZv9kx8U+qNeBEOKTcPKoD7N+WQs5AjcIq9aRiHNcIf0xAKztd68/+bpg7
lzR46fQg6McdzV8ohomcajlpeg0SMe2hOMmugAMUab9Wuz9JzTMBq0RuZ6GZEjQ6
vGVQTwqfVqbD1dU48MmSPivtd8Ijou03dtq/CuwV3//QePUqUqgKUA8OMdoiQlNv
s124MznjQHfA+YkZxNCo5+7Atc9+OafsIlfH7+WDnmJcy3kDYStksKuNRX+heIpH
j4Fv5e9ILvUHYltgM0Pi1VozpLXodS9d9t/IRyG/SZtk/JqUmmHohNbYGzLuLT1Q
dXXJoVxRLo+qHjaT0ZdmKyRayonVNaV7yLczXVyqWjKVLM8Q3NbanaRQofzSM6jD
M9KtW4CRc22skfWaPKS/pNMJjvkIMHmgyMSwD+HF0rG1SIh06u1Qno/1Wqf7ciiF
u/dBpT3Li4ELAkJVojMI
=3h7o
-END PGP SIGNATURE-

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