Re: scheduling with core.async?

[bahadir cambel]

Hi Leon, 

you may check http://www.clojure-toolbox.com/ and see the schedule section. 
Here are the suggestions; 

https://github.com/jarohen/chime (has core.async examples)
https://github.com/overtone/at-at
https://github.com/zcaudate/cronj

Also, if you're using HTTP-Kit http://www.http-kit.org/timer.html

Cheers,
Bahadir
twitter.com/bahadircambel






On Tuesday, September 22, 2015 at 4:35:37 PM UTC+2, Leon Grapenthin wrote:
>
> Is it recommended to use core.asyncs timeout channel to wait on hour or 
> even longer for light scheduling tasks?
>
> High precision is a nongoal.
>
> Kind regards,
>  Leon.
>

-- 
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: Boxed math in transducers

[Peter Taoussanis]

Sorry- that should read "a little better", not "little better" ;-)

-- 
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 metadata to specify how calls to a macro should be indented

[Artur Malabarba]

2015-09-23 10:32 GMT+01:00 Phillip Lord :

> Specifically wrt to CIDER, the easier solution is the cache the metadata
> map each time it is used. I suspect that CIDER would need this for
> performance -- I mean indentation requiring ongoing evaluation in
> Clojure is likely to be slow.
> Basically, I am suggesting automatic manual configuration if you will
> excuse the oxymoron.
>
Yes, that's what the current (but unmerged) implementation does. :)

> If this cache were persisted between Emacs sessions then the problem
> largely goes away.
>
Yes, that's very plausible to do.

-- 
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: Boxed math in transducers

[Peter Taoussanis]

Hey Alex,

Not sure I follow. If we deref (volatile! 5), the dereffed val is a number.

`(inc @(volatile! 5))` will involve boxed math but `(inc ^long @(volatile! 
5))` won't.

So, for example:

(defn core-take ; As in clojure.core
  ([n]
   (fn [rf]
 (let [nv (volatile! n)]
   (fn
 ([] (rf))
 ([result] (rf result))
 ([result input]
  (let [n @nv
nn (vswap! nv dec)
result (if (pos? n)
 (rf result input)
 result)]
(if (not (pos? nn))
  (ensure-reduced result)
  result

(defn new-take ; Without boxed math
  ([^long n]
   (fn [rf]
 (let [nv (volatile! n)]
   (fn
 ([] (rf))
 ([result] (rf result))
 ([result input]
  (let [^long n @nv
^long nn (vswap! nv #(dec ^long %))
result (if (pos? n)
 (rf result input)
 result)]
(if (not (pos? nn))
  (ensure-reduced result)
  result

Timing on the latter is little better. Does that make sense, or am I 
missing something?

-- 
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: Boxed math in transducers

[Alex Miller]

Given that the counter is held in a volatile (boxed) object, I don't think 
a hint would help.

On Wednesday, September 23, 2015 at 1:14:39 AM UTC-5, Peter Taoussanis 
wrote:
>
> Hi all,
>
> Just noticed some use of boxed math in a couple of the Clojure 1.7 
> transducers (e.g. `take`). Would there be interest in a PR to add some 
> numerical type hints?
>
> Cheers :-)
>

-- 
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 metadata to specify how calls to a macro should be indented

[Phillip Lord]

Artur Malabarba  writes:
>>
> Yes, that's what the current (but unmerged) implementation does. :)
>
>> If this cache were persisted between Emacs sessions then the problem
>> largely goes away.
>>
> Yes, that's very plausible to do.

I am happy to do the implementation for this (i.e. the persistance!),
given that I am raising the problem, if that would be a help.

Phil

-- 
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: scheduling with core.async?

[Thomas Heller]

To be honest I see no point in using core.async or any other library for 
that matter. Java already solves this problem very well.

(ns ...
  (:import [java.util.concurrent TimeUnit Executors]))

(def scheduler
  (doto (Executors/newSingleThreadScheduledExecutor)
(.scheduleAtFixedRate
 the-function-that-gets-called-every-hour
 0 ;; initial delay till execution starts
 1 ;; delay between each runs
 TimeUnit/HOURS ;; the unit of the above two values
 )))

When and where you set this up is dependent on your app and you must 
remember to (.shutdown scheduler) at some point, but beyond that it is 
pretty simple.

HTH,
/thomas

On Wednesday, September 23, 2015 at 1:00:32 PM UTC+2, bahadir cambel wrote:
>
>
> Hi Leon, 
>
> you may check http://www.clojure-toolbox.com/ and see the schedule 
> section. Here are the suggestions; 
>
> https://github.com/jarohen/chime (has core.async examples)
> https://github.com/overtone/at-at
> https://github.com/zcaudate/cronj
>
> Also, if you're using HTTP-Kit http://www.http-kit.org/timer.html
>
> Cheers,
> Bahadir
> twitter.com/bahadircambel
>
>
>
>
>
>
> On Tuesday, September 22, 2015 at 4:35:37 PM UTC+2, Leon Grapenthin wrote:
>>
>> Is it recommended to use core.asyncs timeout channel to wait on hour or 
>> even longer for light scheduling tasks?
>>
>> High precision is a nongoal.
>>
>> Kind regards,
>>  Leon.
>>
>

-- 
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: Clojure performance on Android

[Roger Keays]

Okay, thanks. Looks like I will have to do some experimenting to get the 
setup I want...

On Wednesday, September 23, 2015 at 3:02:01 AM UTC+2, Ben Brinckerhoff 
wrote:
>
> On my team, we tried using RoboVM to compile Clojure to iOS. It worked 
> fine once it booted, but startup time was a concern. We didn't spend a lot 
> of time optimizing it though. We also found the compile/boot cycle to be 
> quite long (over 50s to see a change). My understanding (perhaps mistaken) 
> is RoboVM must compile all code before boot, so live-loading code via a 
> REPL won't work.
>
> We switched to using Clojurescript/React Native and it's been a net 
> positive for us so far, even though we had to rewrite some internal 
> libraries for CLJS. We had a REPL briefly (Ambly, although we've recently 
> had to drop support for it due to breaking changes from React Native 
> upgrades) and our compile/boot cycle is about 20s.
>
> My coworker Chris Vermilion created these slides about our experience 
> https://docs.google.com/viewer?a=v=forums=MTUyOTIzOTE0MjU1MDA0MDI3NjQBMTExMTI3MjYwMjc1OTc4MDg3MzQBXzVfV0tNdUZDQUFKATAuMQEBdjI
>
> Hope that helps,
> Ben
>
> On Tuesday, September 22, 2015 at 3:51:04 PM UTC-7, Roger Keays wrote:
>>
>> Hi all,
>>
>> Thanks for giving the world Clojure. It's already made my life better 
>> just by applying the idioms to my Java code (e.g. 
>> http://www.ninthavenue.com.au/java-with-no-design-patterns).
>>
>> I'm starting on a new project soon and would like to use Clojure, however 
>> in my experiments so far performance seems to be a bit of a problem. Since 
>> the project will target mobile devices performance is pretty important 
>> (especially startup time).
>>
>> To be honest, even for the server I'm a little deterred by the stats I've 
>> seen online of Clojure vs Java performance. I can always just write Java in 
>> a functional style and embed beanshell for a REPL.
>>
>> So I guess it would be good to hear from the community how things have 
>> worked out for them performance-wise, and especially on Android/iOS.
>>
>> Also, are there any known showstoppers compiling Clojure bytecode to iOS 
>> using RoboVM?
>>
>> Thanks in advance,
>>
>> Roger
>>
>>
>>

-- 
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 metadata to specify how calls to a macro should be indented

[Artur Malabarba]

Great! ☺ Bring it up on the cider gitter room.
On 23 Sep 2015 3:55 pm, "Phillip Lord"  wrote:

> Artur Malabarba  writes:
> >>
> > Yes, that's what the current (but unmerged) implementation does. :)
> >
> >> If this cache were persisted between Emacs sessions then the problem
> >> largely goes away.
> >>
> > Yes, that's very plausible to do.
>
> I am happy to do the implementation for this (i.e. the persistance!),
> given that I am raising the problem, if that would be a help.
>
> Phil
>

-- 
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: A generalization of iterate

[nchurch]

Yeah, it consumes stack just like the Clojurescript version of Iterate. 
 I'm curious if anyone knows how to avoid this.  The Clojure version of 
Iterate is Java; and for some reason 'recur' can't be used inside of 
lazy-cat (not really documented, but apparently true). 

On Tuesday, September 22, 2015 at 9:21:57 PM UTC-7, Max Countryman wrote:
>
> I wonder if something like this is a little easier to read?
>
> (defn generate
>   ([f coll]
>(generate f coll (reverse coll)))
>   ([f coll args]
>(let [next-val (apply f args)]
>  (lazy-cat coll (generate f [next-val] (conj (butlast args) 
> next-val))
>
> Where your Fibonacci example becomes:
>
> (take 100 (generate +’ [1 1]))
>
> As for your other questions, I can’t be of much help. But isn’t there 
> nontrivial memory overhead to consider with this approach?
>
>
> On Sep 22, 2015, at 18:19, nchurch  
> wrote:
>
> I was going through 4clojure (highly recommended!) and doing the Fibonacci 
> exercise.  It occurred to me that the iterate function could be generalized 
> in a reasonable way, so that the next value is generated by applying the 
> function to the last N items so far, where N is the number of initial 
> arguments beyond the function.  Thus:
>
> (generate inc 1) 
>
> works just like iterate, while
>
> (generate + 1 1)
>
> generates the Fibonacci sequence.
>
> Here's the code:
>
> (defn generate
>   [f & more]
>   (letfn [(recurse
> [coll args]
> (let [next-val (apply f args)]
>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
> next-val)]
> (recurse more (reverse more
>
>
> Code is also on Github .
>
> I see this as part of a larger class of generalized sequence functions: for 
> instance, extra arguments in a function given to *reduce* could refer to N 
> arguments back in the sequence (might be useful, for instance, in smoothing a 
> sequence of values using an average).
>
> Questions: is there an existing home for this kind of functionality?  And 
> could the above code be improved?  (I just used the definition of *iterate* 
> as a starting point.)
>
>
>
>
> -- 
> 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.

Boxed math in transducers

[Peter Taoussanis]

Hi all,

Just noticed some use of boxed math in a couple of the Clojure 1.7 
transducers (e.g. `take`). Would there be interest in a PR to add some 
numerical type hints?

Cheers :-)

-- 
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: scheduling with core.async?

[Gerrit Jansen van Vuuren]

 from my own experience with core async I;d say yes

I've made two macros
 https://github.com/gerritjvv/fun-utils/blob/master/src/fun_utils/core.clj#L208 
and
https://github.com/gerritjvv/fun-utils/blob/master/src/fun_utils/core.clj#L220
 that does exactly what you're referring to.

Remember if you're going to schedule a task that uses IO or takes some time 
then you need to use a thread and not a general (go ) block, 
this is what fixdelay-thread does, otherwise you end up blocking the 
general core.async thread pool.


On Tuesday, 22 September 2015 16:35:37 UTC+2, Leon Grapenthin wrote:
>
> Is it recommended to use core.asyncs timeout channel to wait on hour or 
> even longer for light scheduling tasks?
>
> High precision is a nongoal.
>
> Kind regards,
>  Leon.
>

-- 
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] Leiningen 2.5.3

[Ning Sun]

Thanks for the release! I confirm the GPG issue is fixed in 2.5.3.

On 09/22/2015 06:04 AM, Jean Niklas L'orange wrote:
> Greetings, Clojurians.
>
> I am happy to announce the release of Leiningen version 2.5.3. This
> version
> contains mostly bugfixes, most notably an issue where environment
> variables were
> not propagated down to GPG. This caused `lein deploy` and similar
> commands to
> fail if you set up GPG with the `GPG_AGENT_INFO` environment variable. In
> addition, `lein vcs tag` now supports `--no-sign` if you do not want
> to sign
> your git tags.
>
> Here's a list of user-visible changes:
>
> ## 2.5.3 / 2015-09-21
>
> * Add CHANGELOG.md to default lein templates. (Daniel Compton)
> * `lein vcs tag` now supports the `--no-sign` flag. (Daniel Compton)
> * Fix a bug where javac errors were not printed to terminal. (Brandon
> Shimanek)
> * Fix a bug where environment variables were not propagated down to
> GPG. (Brandon Shimanek)
> * `lein retest` now saves information on which tests that fail.
> (Shalaka Patil)
>
> For those who manually installed, `lein upgrade` will pull in 2.5.3,
> and `lein
> downgrade 2.5.2` will bring you back to the previous version if you
> run into any
> issues.
>
> Thanks to all the contributors who made this happen!
>
> -- Jean Niklas
>
> -- 
> 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: A generalization of iterate

[nchurch]

A, right.  Silly me.  This is something I have trouble remembering.  For 
some reason when you use regular concat, the error message is helpful 
(can't recur from non-tail position); with lazy-cat it shows a mismatch of 
argument numbers.

On Wednesday, September 23, 2015 at 2:10:47 PM UTC-7, Max Countryman wrote:
>
> Your problem with recur is because you can only recur from the tail 
> position. 
>
> On Sep 23, 2015, at 12:28, nchurch  
> wrote:
>
> Yeah, it consumes stack just like the Clojurescript version of Iterate. 
>  I'm curious if anyone knows how to avoid this.  The Clojure version of 
> Iterate is Java; and for some reason 'recur' can't be used inside of 
> lazy-cat (not really documented, but apparently true). 
>
> On Tuesday, September 22, 2015 at 9:21:57 PM UTC-7, Max Countryman wrote:
>>
>> I wonder if something like this is a little easier to read?
>>
>> (defn generate
>>   ([f coll]
>>(generate f coll (reverse coll)))
>>   ([f coll args]
>>(let [next-val (apply f args)]
>>  (lazy-cat coll (generate f [next-val] (conj (butlast args) 
>> next-val))
>>
>> Where your Fibonacci example becomes:
>>
>> (take 100 (generate +’ [1 1]))
>>
>> As for your other questions, I can’t be of much help. But isn’t there 
>> nontrivial memory overhead to consider with this approach?
>>
>>
>> On Sep 22, 2015, at 18:19, nchurch  wrote:
>>
>> I was going through 4clojure (highly recommended!) and doing the 
>> Fibonacci exercise.  It occurred to me that the iterate function could be 
>> generalized in a reasonable way, so that the next value is generated by 
>> applying the function to the last N items so far, where N is the number of 
>> initial arguments beyond the function.  Thus:
>>
>> (generate inc 1) 
>>
>> works just like iterate, while
>>
>> (generate + 1 1)
>>
>> generates the Fibonacci sequence.
>>
>> Here's the code:
>>
>> (defn generate
>>   [f & more]
>>   (letfn [(recurse
>> [coll args]
>> (let [next-val (apply f args)]
>>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
>> next-val)]
>> (recurse more (reverse more
>>
>>
>> Code is also on Github .
>>
>> I see this as part of a larger class of generalized sequence functions: for 
>> instance, extra arguments in a function given to *reduce* could refer to N 
>> arguments back in the sequence (might be useful, for instance, in smoothing 
>> a sequence of values using an average).
>>
>> Questions: is there an existing home for this kind of functionality?  And 
>> could the above code be improved?  (I just used the definition of *iterate* 
>> as a starting point.)
>>
>>
>>
>>
>> -- 
>> 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 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: A generalization of iterate

[Max Countryman]

Your problem with recur is because you can only recur from the tail position. 

> On Sep 23, 2015, at 12:28, nchurch  wrote:
> 
> Yeah, it consumes stack just like the Clojurescript version of Iterate.  I'm 
> curious if anyone knows how to avoid this.  The Clojure version of Iterate is 
> Java; and for some reason 'recur' can't be used inside of lazy-cat (not 
> really documented, but apparently true). 
> 
>> On Tuesday, September 22, 2015 at 9:21:57 PM UTC-7, Max Countryman wrote:
>> I wonder if something like this is a little easier to read?
>> 
>> (defn generate
>>   ([f coll]
>>(generate f coll (reverse coll)))
>>   ([f coll args]
>>(let [next-val (apply f args)]
>>  (lazy-cat coll (generate f [next-val] (conj (butlast args) 
>> next-val))
>> 
>> Where your Fibonacci example becomes:
>> 
>> (take 100 (generate +’ [1 1]))
>> 
>> As for your other questions, I can’t be of much help. But isn’t there 
>> nontrivial memory overhead to consider with this approach?
>> 
>> 
>>> On Sep 22, 2015, at 18:19, nchurch  wrote:
>>> 
>>> I was going through 4clojure (highly recommended!) and doing the Fibonacci 
>>> exercise.  It occurred to me that the iterate function could be generalized 
>>> in a reasonable way, so that the next value is generated by applying the 
>>> function to the last N items so far, where N is the number of initial 
>>> arguments beyond the function.  Thus:
>>> 
>>> (generate inc 1) 
>>> 
>>> works just like iterate, while
>>> 
>>> (generate + 1 1)
>>> 
>>> generates the Fibonacci sequence.
>>> 
>>> Here's the code:
>>> 
>>> (defn generate
>>>   [f & more]
>>>   (letfn [(recurse
>>> [coll args]
>>> (let [next-val (apply f args)]
>>>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
>>> next-val)]
>>> (recurse more (reverse more
>>> 
>>> Code is also on Github.
>>> 
>>> I see this as part of a larger class of generalized sequence functions: for 
>>> instance, extra arguments in a function given to reduce could refer to N 
>>> arguments back in the sequence (might be useful, for instance, in smoothing 
>>> a sequence of values using an average).
>>> 
>>> Questions: is there an existing home for this kind of functionality?  And 
>>> could the above code be improved?  (I just used the definition of iterate 
>>> as a starting point.)
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 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.

-- 
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 metadata to specify how calls to a macro should be indented

[Phillip Lord]

Artur Malabarba  writes:

> You're right about indentation depending on the code being evaluated, but
> that's still better than nothing. ☺
>
> People who do a significant amount of coding without a live session can
> still manually configure indentation like they currently do, and they're no
> worse off.
>
> The editor can even parse the metadata map present in the defn/defmacro, so
> as to provide some "offline" support (though I don't foresee Cider doing
> that).


It's worth being explicit in the spec, then, about whether there is an
expectation that the indentation declaration is, itself, evaluated or
not.

IIRC, the (declare (indent 1)) forms of Emacs-Lisp are *not* evaluated
by the defun/defmacro macros, so are easy enough to pull out of code. If
there are eval'd then, it becomes impossible to do this with any
accuracy.

Specifically wrt to CIDER, the easier solution is the cache the metadata
map each time it is used. I suspect that CIDER would need this for
performance -- I mean indentation requiring ongoing evaluation in
Clojure is likely to be slow. If this cache were persisted between
Emacs sessions then the problem largely goes away.

Basically, I am suggesting automatic manual configuration if you will
excuse the oxymoron.

Phil

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

Lazy Sequence Results in Stack Overflow

[Charles Reese]

I want to compute a lazy sequence of primes.

Here is the interface:

user=> (take 10 primes)
(2 3 5 7 11 13 17 19 23 29)

So far, so good.

However, when I take 500 primes, this results in a stack overflow.

  core.clj:  133  clojure.core/seq
  core.clj: 2595  clojure.core/filter/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
  core.clj: 2626  clojure.core/take/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
 Cons.java:   39  clojure.lang.Cons/next
  LazySeq.java:   81  clojure.lang.LazySeq/next
   RT.java:  598  clojure.lang.RT/next
  core.clj:   64  clojure.core/next
  core.clj: 2856  clojure.core/dorun
  core.clj: 2871  clojure.core/doall
  core.clj: 2910  clojure.core/partition/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
  core.clj: 2551  clojure.core/map/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  LazySeq.java:   49  clojure.lang.LazySeq/seq
   RT.java:  484  clojure.lang.RT/seq
  core.clj:  133  clojure.core/seq
  core.clj: 3973  clojure.core/interleave/fn
  LazySeq.java:   40  clojure.lang.LazySeq/sval
  
I'm wondering what is the problem here and, more generally, when working 
with lazy sequences, how should I approach this class of error?

Here is the code.

(defn assoc-nth
  "Returns a lazy seq of coll, replacing every nth element by val

  Ex:
  user=> (assoc-nth [3 4 5 6 7 8 9 10] 2 nil)
  (3 nil 5 nil 7 nil 9 nil)
  "
  [coll n val]
  (apply concat
 (interleave
  (map #(take (dec n) %) (partition n coll)) (repeat [val]

(defn sieve
  "Returns a lazy seq of primes by Eratosthenes' method

  Ex:
  user=> (take 4 (sieve (iterate inc 2)))
  (2 3 5 7)

  user=> (take 10 (sieve (iterate inc 2)))
  (2 3 5 7 11 13 17 19 23 29)
  "
  [s]
  (lazy-seq
   (if (seq s)
 (cons (first s) (sieve
  (drop-while nil? (assoc-nth (rest s) (first s) 
nil
 [])))

(def primes
  "Returns a lazy seq of primes

  Ex:
  user=> (take 10 primes)
  (2 3 5 7 11 13 17 19 23 29)
  "
  (concat [2] (sieve (filter odd? (iterate inc 3)

-- 
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: Lazy Sequence Results in Stack Overflow

[Colin Yates]

This might help:
http://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects
On 24 Sep 2015 01:14, "Charles Reese"  wrote:

> I want to compute a lazy sequence of primes.
>
> Here is the interface:
>
> user=> (take 10 primes)
> (2 3 5 7 11 13 17 19 23 29)
>
> So far, so good.
>
> However, when I take 500 primes, this results in a stack overflow.
>
>   core.clj:  133  clojure.core/seq
>   core.clj: 2595  clojure.core/filter/fn
>   LazySeq.java:   40  clojure.lang.LazySeq/sval
>   LazySeq.java:   49  clojure.lang.LazySeq/seq
>RT.java:  484  clojure.lang.RT/seq
>   core.clj:  133  clojure.core/seq
>   core.clj: 2626  clojure.core/take/fn
>   LazySeq.java:   40  clojure.lang.LazySeq/sval
>   LazySeq.java:   49  clojure.lang.LazySeq/seq
>  Cons.java:   39  clojure.lang.Cons/next
>   LazySeq.java:   81  clojure.lang.LazySeq/next
>RT.java:  598  clojure.lang.RT/next
>   core.clj:   64  clojure.core/next
>   core.clj: 2856  clojure.core/dorun
>   core.clj: 2871  clojure.core/doall
>   core.clj: 2910  clojure.core/partition/fn
>   LazySeq.java:   40  clojure.lang.LazySeq/sval
>   LazySeq.java:   49  clojure.lang.LazySeq/seq
>RT.java:  484  clojure.lang.RT/seq
>   core.clj:  133  clojure.core/seq
>   core.clj: 2551  clojure.core/map/fn
>   LazySeq.java:   40  clojure.lang.LazySeq/sval
>   LazySeq.java:   49  clojure.lang.LazySeq/seq
>RT.java:  484  clojure.lang.RT/seq
>   core.clj:  133  clojure.core/seq
>   core.clj: 3973  clojure.core/interleave/fn
>   LazySeq.java:   40  clojure.lang.LazySeq/sval
>
> I'm wondering what is the problem here and, more generally, when working
> with lazy sequences, how should I approach this class of error?
>
> Here is the code.
>
> (defn assoc-nth
>   "Returns a lazy seq of coll, replacing every nth element by val
>
>   Ex:
>   user=> (assoc-nth [3 4 5 6 7 8 9 10] 2 nil)
>   (3 nil 5 nil 7 nil 9 nil)
>   "
>   [coll n val]
>   (apply concat
>  (interleave
>   (map #(take (dec n) %) (partition n coll)) (repeat [val]
>
> (defn sieve
>   "Returns a lazy seq of primes by Eratosthenes' method
>
>   Ex:
>   user=> (take 4 (sieve (iterate inc 2)))
>   (2 3 5 7)
>
>   user=> (take 10 (sieve (iterate inc 2)))
>   (2 3 5 7 11 13 17 19 23 29)
>   "
>   [s]
>   (lazy-seq
>(if (seq s)
>  (cons (first s) (sieve
>   (drop-while nil? (assoc-nth (rest s) (first s)
> nil
>  [])))
>
> (def primes
>   "Returns a lazy seq of primes
>
>   Ex:
>   user=> (take 10 primes)
>   (2 3 5 7 11 13 17 19 23 29)
>   "
>   (concat [2] (sieve (filter odd? (iterate inc 3)
>
> --
> 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: Primitive pseudocode parser in Clojure

[Vitaliy Vlasov]

This looks awesome! Thanks so much! I'm actually extending it with some 
additional statements of my own (Instaparse would be perhaps too general in 
my case)

On Tuesday, September 22, 2015 at 2:08:03 AM UTC+3, Matching Socks wrote:
>
> Vitaliy Akimov described an approach to a similar problem here recently...
>
> https://groups.google.com/d/msg/clojure/HNH66_KNaNM/BjpJGnl7AgAJ
>
>

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