Re: clojure code to java

[Colin Fleming]

You could also check https://github.com/galdolber/clojure-objc, which uses
a modified Clojure compiler to output Java source instead of bytecode. It's
been subsequently modified to work with ObjC, I'm not sure whether that
affects its ability to execute the program as Java or not.


On 1 May 2014 16:56, Andy Fingerhut  wrote:

> Leiningen can convert Clojure source code to Java .class files (compiled
> Java byte code, not Java source code), with the help of the Clojure
> compiler.
>
> I don't know of a way Leiningen can convert that to Java source code,
> unless there is some feature of Leiningen I haven't learned about yet, or
> some plugin that does that.
>
> There are several programs out there, some open source, some commercial,
> that can decompile Java byte code files into Java source code, of varying
> quality.  I have used a trial version of the AndroChef Java Decompiler 1.0
> a few times in the past, and found its results better than one other open
> source Java decompiler I tried (I don't remember what that was called right
> now).
>
> http://www.neshkov.com/ac_decompiler.html
>
> Andy
>
>
> On Wed, Apr 30, 2014 at 7:05 PM, Julio Berina wrote:
>
>> I've been programming a bit in Clojure, and in my opinion it's like
>> making Java programs without typing long Java because of it running on the
>> JVM.  However, I wanna be able to convert my Clojure code to Java code.  I
>> know Leiningen can do that, but I am really clueless at this point, and I
>> don't know what other programs out there will convert Clojure to Java
>> .class file.  Does anyone have any tips?
>>
>> --
>> 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.
>

-- 
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 code to java

[Andy Fingerhut]

Leiningen can convert Clojure source code to Java .class files (compiled
Java byte code, not Java source code), with the help of the Clojure
compiler.

I don't know of a way Leiningen can convert that to Java source code,
unless there is some feature of Leiningen I haven't learned about yet, or
some plugin that does that.

There are several programs out there, some open source, some commercial,
that can decompile Java byte code files into Java source code, of varying
quality.  I have used a trial version of the AndroChef Java Decompiler 1.0
a few times in the past, and found its results better than one other open
source Java decompiler I tried (I don't remember what that was called right
now).

http://www.neshkov.com/ac_decompiler.html

Andy


On Wed, Apr 30, 2014 at 7:05 PM, Julio Berina  wrote:

> I've been programming a bit in Clojure, and in my opinion it's like making
> Java programs without typing long Java because of it running on the JVM.
>  However, I wanna be able to convert my Clojure code to Java code.  I know
> Leiningen can do that, but I am really clueless at this point, and I don't
> know what other programs out there will convert Clojure to Java .class
> file.  Does anyone have any tips?
>
> --
> 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: difference in behavior for :let modifiers in "for" vs. "doseq"

[Andy Fingerhut]

At least a few people consider it a bug, and two of them created a ticket,
the first of which was declined as not a bug.  That is some evidence that
it is considered not a bug:

http://dev.clojure.org/jira/browse/CLJ-1316
http://dev.clojure.org/jira/browse/CLJ-207

Andy


On Wed, Apr 30, 2014 at 9:39 PM, Yuri Niyazov wrote:

> Hello everyone,
>
>   In Clojure 1.6:
>
> user> (doseq [:let [a 1] b '(1 2 3)] (println a b))
> 1 1
> 1 2
> 1 3
> nil
> user> (for [:let [a 1] b '(1 2 3)] (println a b))
> IllegalStateException Can't pop empty vector
>  clojure.lang.PersistentVector.pop (PersistentVector.java:381)
> user>
>
> Is this expected behavior? a bug? Something I missed in the documentation?
>
> --
> 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.

clojure code to java

[Julio Berina]

I've been programming a bit in Clojure, and in my opinion it's like making 
Java programs without typing long Java because of it running on the JVM. 
 However, I wanna be able to convert my Clojure code to Java code.  I know 
Leiningen can do that, but I am really clueless at this point, and I don't 
know what other programs out there will convert Clojure to Java .class 
file.  Does anyone have any tips?

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

difference in behavior for :let modifiers in "for" vs. "doseq"

[Yuri Niyazov]

Hello everyone, 

  In Clojure 1.6:

user> (doseq [:let [a 1] b '(1 2 3)] (println a b))
1 1
1 2
1 3
nil
user> (for [:let [a 1] b '(1 2 3)] (println a b))
IllegalStateException Can't pop empty vector 
 clojure.lang.PersistentVector.pop (PersistentVector.java:381)
user> 

Is this expected behavior? a bug? Something I missed in the documentation?

-- 
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: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

Oh, right. (f m) instead of (apply f [m]). Duh.


On Wed, Apr 30, 2014 at 11:15 PM, Colin Fleming  wrote:

> I think it would because in that case you'd just pass your arg map
> straight through rather than having to reconstruct it. So if you weren't
> passed :y in g (in Mark's example), g wouldn't pass it on to f. By forcing
> the reconstruction of the map from explicit args, you're forced to use the
> value (incorrectly) destructured in g. Mark could work around it in his
> example by using (apply f (mapcat identity m)) in g, but it's far from
> intuitive.
>
>
> On 1 May 2014 15:04, Jim Crossley  wrote:
>
>> Unless I'm missing something subtle, all of your points would hold if you
>> removed the & in your argument vector to turn your kwargs into an explicit
>> map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
>> I'm not sure the :or logic would be any less troublesome.
>>
>>
>> On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg > > wrote:
>>
>>> Here's the thing I can't stand about keyword args:
>>>
>>> Let's start off with a simple function that looks for keys x and y, and
>>> if either is missing,
>>> replaces the value with 1 or 2 respectively.
>>>
>>> (defn f [& {:keys [x y] :or {x 1 y 2}}]
>>>   [x y])
>>>
>>> => (f :x 10)
>>> [10 2]
>>>
>>> So far, so good.
>>>
>>> Now, let's do an extremely simple test of composability.  Let's define a
>>> function g that destructures the keyword args, and if a certain keyword
>>> :call-f is set, then we're just going to turn around and call f, passing
>>> all the keyword args along to f.
>>>
>>> (defn g [& {call-f :call-f :as m}]
>>>   (when call-f
>>> (apply f m)))
>>>
>>> => (g :call-f true :x 10)
>>> [1 2]
>>>
>>> What?  Oh right, you can't apply the function f to the map m.  This
>>> doesn't work.  If we want to "apply" f, we somehow need to apply it to a
>>> sequence of alternating keys and values, not a map.
>>>
>>> Take 2:
>>>
>>> (defn g [& {:keys [call-f x y] :as m}]
>>>   (when call-f
>>> (f :x x :y y)))
>>>
>>> OK, so this time we try to workaround things by explicitly calling out
>>> the names of all the keywords we want to capture and pass along.  It's
>>> ugly, and doesn't seem to scale well to situations where you have an
>>> unknown but at first glance, it seems to work:
>>>
>>> => (g :call-f true :x 80 :y 20)
>>> [80 20]
>>>
>>> Or does it?
>>>
>>> => (g :call-f true :x 10)
>>> [10 nil]
>>>
>>> What is going on here?  Why is the answer coming out that :y is nil,
>>> when function f explicitly uses :or to have :y default to 2?
>>>
>>> The answer is that :or doesn't do what you think it does.  The word "or"
>>> implies that it substitutes the default value of :y any time the
>>> destructured :y is nil or false.  But that's not how it really works.  It
>>> doesn't destructure and then test against nil; instead the :or map only
>>> kicks in when :y is actually missing as a key of the map.
>>>
>>> This means that in g, when we actively destructured :y, it got set to a
>>> nil, and then that got passed along to f.  f's :or map didn't kick in
>>> because :y was set to nil, not absent.
>>>
>>> This is awful.  You can't pass through keyword arguments to other
>>> functions without explicitly destructuring them, and if you destructure
>>> them and pass them along explicitly, nil values aren't picked up as absent
>>> values, so the :or default maps don't work properly.
>>>
>>> To put it simply, keyword args are bad news for composability.
>>>
>>> It's a shame, and I'd love to see this improved (rather than just having
>>> the community give up on keyword arguments).
>>>
>>> --
>>> 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
>> em

Re: Parameter order for APIs

[Leif]

Hi, Colin.

I don't use 'partial' that much either, since anonymous functions are so 
easy to create.  A fn also has the advantage (to my mind) of making it 
clear what arity the old and new fns have.  'Partial' turns a multi-arity 
fn into another multi-arity fn, which I personally think is very hard to 
translate when reading code, even if you're familiar with the original fn.

I don't have any parameter order rules, either.  I just use the argument 
order of whichever clojure.core fn reminds me most of the fn I'm writing 
("This is like a reduction, I'll put the collection at the end; This adds 
an element, I'll put the collection at the beginning.").

--Leif

On Wednesday, April 30, 2014 11:22:55 PM UTC-4, Colin Fleming wrote:
>
> Hi everyone,
>
> After the very interesting keyword argument debate, I have another 
> question about API design. Specifically I'm interested in suggestions about 
> parameter order. The new API guidelines, which have changed very recently 
> to favour maps over keyword args, also changed to include a suggestion that 
> the keyword map be the first argument, since it's the "least variance" 
> argument. 
>
> I've been using some fairly simple rules to order my parameters, basically 
> 1) functions that operate on collections should have the collection last to 
> interoperate with ->>, and 2) functions operating on a "main" object should 
> accept that first, to interoperate with ->. #2 is generally pretty 
> intuitive since it's the same as Java interop and protocol calls, but 
> there's still a fair amount of ambiguity with just these rules unless all 
> your functions have one or two arguments.
>
> I'm interested in opinions about the "variance" ordering, since I assume 
> this is to facilitate use of partial and the like. I never really use 
> partial myself so I don't have a good feeling for how this ordering should 
> work - any comments or opinions?
>
> Thanks,
> Colin
>

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

Pedestal on Google App Engine (GAE)

[C K Kashyap]

Hi,I watched @rkneufeld 's webcast on pedestal recently and it was really
nice.I was wondering how I could go about deploying a pedestal based app on
GAE. I'd appreciate any pointers very much.Regards,Kashyap

-- 
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: Datascript and React.js for a Clojure web app

[Rudi Engelbrecht]

Wow

Thank you so much for this - I played with the demo on Heroku - and this is a 
great starter skeleton for someone like myself who wants to build a web app.

Please keep up the good work and I like your roadmap tasks in your todo list - 
they are all relevant and useful for someone like myself.

Kind regards

Rudi


On 30/04/2014, at 11:32 PM, "Gijs S."  wrote:

> Hi all,
> 
> I've released a Clojure web application. It includes a front-end using 
> DataScript and React.js in ClojureScript.
> 
> More details here: 
> http://thegeez.net/2014/04/30/datascript_clojure_web_app.html
> 
> The code is on github: https://github.com/thegeez/clj-crud
> 
> Demo on heroku: http://clj-crud.herokuapp.com/
> 
> Best regards,
> Gijs 
> 
> -- 
> 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.

Parameter order for APIs

[Colin Fleming]

Hi everyone,

After the very interesting keyword argument debate, I have another question
about API design. Specifically I'm interested in suggestions about
parameter order. The new API guidelines, which have changed very recently
to favour maps over keyword args, also changed to include a suggestion that
the keyword map be the first argument, since it's the "least variance"
argument.

I've been using some fairly simple rules to order my parameters, basically
1) functions that operate on collections should have the collection last to
interoperate with ->>, and 2) functions operating on a "main" object should
accept that first, to interoperate with ->. #2 is generally pretty
intuitive since it's the same as Java interop and protocol calls, but
there's still a fair amount of ambiguity with just these rules unless all
your functions have one or two arguments.

I'm interested in opinions about the "variance" ordering, since I assume
this is to facilitate use of partial and the like. I never really use
partial myself so I don't have a good feeling for how this ordering should
work - any comments or opinions?

Thanks,
Colin

-- 
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: Kwargs vs explicit parameter map for APIs?

[Colin Fleming]

I think it would because in that case you'd just pass your arg map straight
through rather than having to reconstruct it. So if you weren't passed :y
in g (in Mark's example), g wouldn't pass it on to f. By forcing the
reconstruction of the map from explicit args, you're forced to use the
value (incorrectly) destructured in g. Mark could work around it in his
example by using (apply f (mapcat identity m)) in g, but it's far from
intuitive.


On 1 May 2014 15:04, Jim Crossley  wrote:

> Unless I'm missing something subtle, all of your points would hold if you
> removed the & in your argument vector to turn your kwargs into an explicit
> map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
> I'm not sure the :or logic would be any less troublesome.
>
>
> On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg 
> wrote:
>
>> Here's the thing I can't stand about keyword args:
>>
>> Let's start off with a simple function that looks for keys x and y, and
>> if either is missing,
>> replaces the value with 1 or 2 respectively.
>>
>> (defn f [& {:keys [x y] :or {x 1 y 2}}]
>>   [x y])
>>
>> => (f :x 10)
>> [10 2]
>>
>> So far, so good.
>>
>> Now, let's do an extremely simple test of composability.  Let's define a
>> function g that destructures the keyword args, and if a certain keyword
>> :call-f is set, then we're just going to turn around and call f, passing
>> all the keyword args along to f.
>>
>> (defn g [& {call-f :call-f :as m}]
>>   (when call-f
>> (apply f m)))
>>
>> => (g :call-f true :x 10)
>> [1 2]
>>
>> What?  Oh right, you can't apply the function f to the map m.  This
>> doesn't work.  If we want to "apply" f, we somehow need to apply it to a
>> sequence of alternating keys and values, not a map.
>>
>> Take 2:
>>
>> (defn g [& {:keys [call-f x y] :as m}]
>>   (when call-f
>> (f :x x :y y)))
>>
>> OK, so this time we try to workaround things by explicitly calling out
>> the names of all the keywords we want to capture and pass along.  It's
>> ugly, and doesn't seem to scale well to situations where you have an
>> unknown but at first glance, it seems to work:
>>
>> => (g :call-f true :x 80 :y 20)
>> [80 20]
>>
>> Or does it?
>>
>> => (g :call-f true :x 10)
>> [10 nil]
>>
>> What is going on here?  Why is the answer coming out that :y is nil, when
>> function f explicitly uses :or to have :y default to 2?
>>
>> The answer is that :or doesn't do what you think it does.  The word "or"
>> implies that it substitutes the default value of :y any time the
>> destructured :y is nil or false.  But that's not how it really works.  It
>> doesn't destructure and then test against nil; instead the :or map only
>> kicks in when :y is actually missing as a key of the map.
>>
>> This means that in g, when we actively destructured :y, it got set to a
>> nil, and then that got passed along to f.  f's :or map didn't kick in
>> because :y was set to nil, not absent.
>>
>> This is awful.  You can't pass through keyword arguments to other
>> functions without explicitly destructuring them, and if you destructure
>> them and pass them along explicitly, nil values aren't picked up as absent
>> values, so the :or default maps don't work properly.
>>
>> To put it simply, keyword args are bad news for composability.
>>
>> It's a shame, and I'd love to see this improved (rather than just having
>> the community give up on keyword arguments).
>>
>> --
>> 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.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email t

Re: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

Unless I'm missing something subtle, all of your points would hold if you
removed the & in your argument vector to turn your kwargs into an explicit
map, wouldn't they? One advantage is you'd be able to (apply f [m]), but
I'm not sure the :or logic would be any less troublesome.


On Wed, Apr 30, 2014 at 8:06 PM, Mark Engelberg wrote:

> Here's the thing I can't stand about keyword args:
>
> Let's start off with a simple function that looks for keys x and y, and if
> either is missing,
> replaces the value with 1 or 2 respectively.
>
> (defn f [& {:keys [x y] :or {x 1 y 2}}]
>   [x y])
>
> => (f :x 10)
> [10 2]
>
> So far, so good.
>
> Now, let's do an extremely simple test of composability.  Let's define a
> function g that destructures the keyword args, and if a certain keyword
> :call-f is set, then we're just going to turn around and call f, passing
> all the keyword args along to f.
>
> (defn g [& {call-f :call-f :as m}]
>   (when call-f
> (apply f m)))
>
> => (g :call-f true :x 10)
> [1 2]
>
> What?  Oh right, you can't apply the function f to the map m.  This
> doesn't work.  If we want to "apply" f, we somehow need to apply it to a
> sequence of alternating keys and values, not a map.
>
> Take 2:
>
> (defn g [& {:keys [call-f x y] :as m}]
>   (when call-f
> (f :x x :y y)))
>
> OK, so this time we try to workaround things by explicitly calling out the
> names of all the keywords we want to capture and pass along.  It's ugly,
> and doesn't seem to scale well to situations where you have an unknown but
> at first glance, it seems to work:
>
> => (g :call-f true :x 80 :y 20)
> [80 20]
>
> Or does it?
>
> => (g :call-f true :x 10)
> [10 nil]
>
> What is going on here?  Why is the answer coming out that :y is nil, when
> function f explicitly uses :or to have :y default to 2?
>
> The answer is that :or doesn't do what you think it does.  The word "or"
> implies that it substitutes the default value of :y any time the
> destructured :y is nil or false.  But that's not how it really works.  It
> doesn't destructure and then test against nil; instead the :or map only
> kicks in when :y is actually missing as a key of the map.
>
> This means that in g, when we actively destructured :y, it got set to a
> nil, and then that got passed along to f.  f's :or map didn't kick in
> because :y was set to nil, not absent.
>
> This is awful.  You can't pass through keyword arguments to other
> functions without explicitly destructuring them, and if you destructure
> them and pass them along explicitly, nil values aren't picked up as absent
> values, so the :or default maps don't work properly.
>
> To put it simply, keyword args are bad news for composability.
>
> It's a shame, and I'd love to see this improved (rather than just having
> the community give up on keyword arguments).
>
> --
> 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: Clojure for web project? Talk me into it!

[Mike Haney]

Pedestal-app is pretty much dead, but pedestal (service)  is alive and well, 
and that is what I was talking about. 

I know some people were upset when pedestal-app was put on hiatus, but I look 
at it a different way.  Libraries like react (and its clojurescript 
counterparts) are changing the way people think about client-side development, 
and that's starting to look like the next big evolutionary step in ui's.  
Pedestal app was very new when this firestorm hit, with very little adoption, 
so I think Cognitect made a prudent choice to suspend it rather than encourage 
people to continue down a path that could end up in obsolescence.  Sure, they 
could have pressed on and made incremental changes as the technology coalesced, 
but why go down that path when it was still early enough to scrap the library 
without affecting many users?

Pedestal-service is a different story.  It's been around longer and from what 
I've seen Cognitect hasn't wavered at all in their support for it.

-- 
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] nginx-clojure v0.2.0 -- Let MySQL JDBC Driver & Apache HttpClient Fly With Epoll/Kqueue on Nginx

[Xfeep Zhang]

Thank you. It's my honour that nginx-clojure will  being used possibly.
As you said, coroutine based Java socket implementation can simplify 
asynchronous event model. 
We just write synchronous style code about java socket API and get the 
non-blocking and event driven executing on nginx.



On Tuesday, April 29, 2014 10:20:53 PM UTC+8, Rick Richardson wrote:
>
> This is excellent!  I definitely think there is a lot of opportunity for 
> fusion between Clojure and Nginx.  Clojure's model already supports the 
> cooperating threads model that can simplify Nginx's complex event model, as 
> you have demonstrated.  Work has already been done that proves this idea 
> can result in productivity and scale gains (nginx + Lua)  It can also 
> greatly simplify architectures by cutting out load-balancers making less to 
> patch for security/stability issues.   I look forward to using this on my 
> upcoming web projects. 
>
>
> On Friday, April 25, 2014 11:51:41 PM UTC-4, Xfeep Zhang wrote:
>>
>> nginx-clojure v0.2.0 includes new features:
>>
>>
>>1. non-blocking socket based on coroutine and compatible with largely 
>>existing java library such as apache http client, mysql jdbc drivers
>>2. asynchronous callback API of socket for some advanced usage
>>3. run initialization clojure code when nginx worker starting
>>4. provide a build-in tool to make setting of coroutine based socket 
>>easier
>>5. support Linux 32bit x86 now
>>6. publish [binary release compiled with lastes stable nginx 1.6.0](
>>https://sourceforge.net/projects/nginx-clojure/files/) about Linux 
>>x64, Linux i586, Win32 & MacOS X.
>>
>>
>> If the http service should do some slow I/O operations such as access 
>> external http service, database, etc.  nginx worker will be blocked by 
>> those operations 
>> and the new  user  request even static file request will be blocked. It 
>> really sucks！ Before v0.2.0 the only choice is using thread pool but now we 
>> have 
>> three choice  Now:
>>
>>1. Coroutine based Socket -- Let MySQL JDBC Driver & Apache 
>>HttpClient Fly With Epoll/Kqueue on  Nginx
>>- Java Socket API Compatible and work well with largely existing java 
>>   library such as apache http client, mysql jdbc drivers etc.
>>   - non-blocking, cheap, fast and let one java main thread be able 
>>   to handle thousands of connections.
>>   - Your old code **_need not be changed_** and those plain and old 
>>   java socket based code such as Apache Http Client, MySQL mysql jdbc 
>> drivers 
>>   etc. will be on the fly with epoll/kqueue on Linux/BSD!
>>   - You must do some steps to get the right class waving 
>>   configuration file and set it in the nginx conf file.
>>2. Asynchronous Socket
>>   - More details here: https://github.com/nginx-clojure/nginx-clojure
>>   3. Thread Pool
>>- More details here : https://github.com/nginx-clojure/nginx-clojure
>>   
>>
>> More details please visit nginx-clojure github site : 
>> https://github.com/nginx-clojure/nginx-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.

Re: Kwargs vs explicit parameter map for APIs?

[Mark Engelberg]

Here's the thing I can't stand about keyword args:

Let's start off with a simple function that looks for keys x and y, and if
either is missing,
replaces the value with 1 or 2 respectively.

(defn f [& {:keys [x y] :or {x 1 y 2}}]
  [x y])

=> (f :x 10)
[10 2]

So far, so good.

Now, let's do an extremely simple test of composability.  Let's define a
function g that destructures the keyword args, and if a certain keyword
:call-f is set, then we're just going to turn around and call f, passing
all the keyword args along to f.

(defn g [& {call-f :call-f :as m}]
  (when call-f
(apply f m)))

=> (g :call-f true :x 10)
[1 2]

What?  Oh right, you can't apply the function f to the map m.  This doesn't
work.  If we want to "apply" f, we somehow need to apply it to a sequence
of alternating keys and values, not a map.

Take 2:

(defn g [& {:keys [call-f x y] :as m}]
  (when call-f
(f :x x :y y)))

OK, so this time we try to workaround things by explicitly calling out the
names of all the keywords we want to capture and pass along.  It's ugly,
and doesn't seem to scale well to situations where you have an unknown but
at first glance, it seems to work:

=> (g :call-f true :x 80 :y 20)
[80 20]

Or does it?

=> (g :call-f true :x 10)
[10 nil]

What is going on here?  Why is the answer coming out that :y is nil, when
function f explicitly uses :or to have :y default to 2?

The answer is that :or doesn't do what you think it does.  The word "or"
implies that it substitutes the default value of :y any time the
destructured :y is nil or false.  But that's not how it really works.  It
doesn't destructure and then test against nil; instead the :or map only
kicks in when :y is actually missing as a key of the map.

This means that in g, when we actively destructured :y, it got set to a
nil, and then that got passed along to f.  f's :or map didn't kick in
because :y was set to nil, not absent.

This is awful.  You can't pass through keyword arguments to other functions
without explicitly destructuring them, and if you destructure them and pass
them along explicitly, nil values aren't picked up as absent values, so the
:or default maps don't work properly.

To put it simply, keyword args are bad news for composability.

It's a shame, and I'd love to see this improved (rather than just having
the community give up on keyword arguments).

-- 
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 for web project? Talk me into it!

[Daniel]

Wasn't Pedestal-app placed on hiatus?  What is the current status of that?

On Tuesday, April 29, 2014 10:35:25 AM UTC-5, Mike Haney wrote:
>
> Pedestal was developed by Cognitect and I would assume they use it on many 
> of their consulting projects.  Since future support appears be a major 
> concern for you (rightly so), Pedestal probably fulfills that requirement 
> better than anything else out there right now.  Even if you don't need all 
> the features it offers, it's worth considering building your server-side 
> stack around it for that reason alone.

-- 
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: testing clojure.core/group-by with clojure.test.check

[Andrew Chambers]

One approach you can use is write the generators in such a way that they 
generate the final answer group-by should return, then you write code
which does the inverse to group by and then you check the group by answer 
is equal to the originally generated solution.  

On Wednesday, April 30, 2014 11:38:19 PM UTC+12, henry w wrote:
>
> Hi, I wanted to get started with clojure.test.check (formerly 
> simple-check) and I am new to property based testing.
>
> I plucked clojure.core/group-by for no particular reason as a function to 
> test.
>
> I started by stating some properties i think should hold:
>
> ;; 1. applying the grouping key function to each member in a grouping 
> should result in the grouping key
> ;; 2. flattening the vals of the group-by result should give back the 
> contents of the original collection.
> ;; 3. no element appears in more than one grouping.
>
> so far so good I think. there may be others but this seems ok for now. 
>
> now, how to generate some data.
>
> for group-by we need two params:
> 1) a grouping function
> 2) a collection of items to be grouped
>
> If I start by naively generating collections of maps (containing keyword 
> keys and int vals, for example), the data is of the right shape to use in 
> group by, but there is no guarantee that:
> 1) any of the maps share a key that I could use for grouping
> 2) the values under a common key are shared
>
> This is really the crux of my problem ideally I would have the 
> generator *mostly* produce data which is actually doing to result in the 
> sort of collection i might want to call group-by on in real life (ie not 
> have everything grouped under nil on each generation). So should i create a 
> generator that creates keywords (which i will want to use as grouping 
> function) then have another generator that produces what are going to be 
> the values under this grouping key, then a generator that uses both of 
> these to create collections of maps from these. then i would have to find 
> out what the grouping keyword was that was generated this could all 
> work, I have read enough about generators to have a stab at this... but is 
> it the right approach?
>
> as far as implementing tests for the properties so far, I have done 
> property 2 above, using a basic generator and yanking out an arbitrary key 
> from it clearly a flawed approach as not much 'realistic' grouping is 
> going to happen here.
>
> (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that 
> not-empty (gen/map gen/keyword gen/int)
>
> (def all-elements-are-grouped
>   (prop/for-all [group-by-input vector-of-maps]
> (let [a-map-key (-> group-by-input first keys first)] ;; 
> hmm, seems far from ideal
>   (= (set group-by-input) (-> (group-by a-map-key 
> group-by-input) vals flatten set)
>
> help appreciated... perhaps I need to learn more about the paradigm first, 
> but resources linked from the readme are all a bit more basic than this. so 
> if you know of some more advanced tutorials please let me know.
>
> Thanks
>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Val Waeselynck]

Sorry I have been late to react to all this, since I'm the one who started 
it all.

First, *as a side note* : I have nothing against docstrings. I acknowledge 
their benefits, I think we should keep using them and I enjoy them every 
day like all of you. My point was just that they were not enough for all 
documentation, I probably wasn't very clear on that. Stop shooting :)

@Fergal : thanks for such a great tour. It seems I have a lot of catching 
up to do before I have a keen understanding of the currently existing 
options. Nevertheless, I'll try to make a relevant contribution to the 
discussion.

  Given some of the answers, I'd like as a precaution emphasize the fact 
that I'm not trying to "sell" you a documentation system nor impose a 
dogma. My intent in proposing these approximative features was that, 
through some refining, some proposing and some discarding, the discussion 
will converge to a precise idea of what we want for documentation and how 
we should do it.

  
  As for what Gregg and Sean objected - that Clojure code is 
self-sufficient as documenting itself - I have to simply disagree. I do not 
want to have a theoretical discussion on this, because I think it's 
pointless; it is an empirical observation to me that foreign Clojure code 
tends to be difficult to understand. I have felt that pain, many times and 
despite all my stubbornness, which is why I finally posted here. I I'm the 
only one, please tell me.

   I think it is very important to raise the awareness of all Clojure 
programmers, especially library authors, that there is a significant 
asymmetry of information here : namely, it's easier than ever to go from 
intent to code, and much harder to go the way back. I see it at work when I 
edit my own code too : the programs seem to organize themselves naturally 
as I write them, sometimes in such a mechanical way that I have 
difficulties finding names for the abstractions I program, and I do get a 
crystal-clear understanding of them; but I'm quite sure that it would be 
very obscure to me if I had not witnessed the process. Try to make a Ring 
middleware or a monad self-explanatory with just code and a schema.

  Undoubtedly, library authors will feel this duty of documentation like a 
hinderance. I believe this is a necessary tradeoff to make. Besides, if 
you're code changes so fast that documentation quickly becomes obsolete, 
isn't that a sign that your API isn't ready to be exported?

  
  Anyway, I think speculating about the necessity of such a documentation 
system is not the best thing to do - I suggest we give it a try, and then 
everyone can decide for themselves if it's useful. After all, it's in 
Clojure, so this should not take too long, right ? ;)
 
 samedi 26 avril 2014 18:39:04 UTC+2, Val Waeselynck a écrit :
>
> Hello to all,
>
> *Short version :* I think Clojure needs a documentation system in 
> Clojure, I would like to know if some efforts exist in that direction, and 
> I am willing to create it / contribute to it.
>
> *Long version :*
>
> I've been thinking for a while that the Clojure community could benefit a 
> lot from a more sophisticated and ergonomic documentation system. 
>
> I have seen some existing plugins like lein-sphinx, but I think it would 
> be really good to have documentation that would be written in Clojure, for 
> the following reasons :
>
>- we're all very fond of Clojure data structures and their syntax. (I 
>don't know about you, but I find that even HTML looks better in 
> Clojurethan in HTML). Plus, Clojure 
> programmers already know how to edit them.
>- (better reason) The facts that Vars are first-class citizens and 
>that symbols can be referred explicitly with hardly any ceremony (macros) 
>are a exceptional opportunity to make smart and highly-structured 
>documentation very easily.
>- if it's in Clojure, Clojure programmers can seamlessly build *ad 
> hoc*documentation functionality on top of it to suit their own particular 
> needs.
>
> I haven't found anything of the like yet, and if it exists, I would be 
> grateful if someone would redirect me to it.
>
> Here are *my thoughts on this :*
>
>1. Clojure doc-strings, although they are quite handy as reminders and 
>for doc-indexation, are *too raw a content*. Even when they are done 
>right, they tend to be cumbersome, and it's too bad to have such concise 
>code drown in the middle of so much documentation. What's more, I believe 
>that when programmers program a function (or anything), they tend to think 
>more about the implementation than the (uninformed) usage, so they have 
>little incentive to make it right.
>2. Building on 1. having a system where documentation and programs 
>live in separate files, in the same way as tests, would enforce a healthy 
>separation of concerns. Importantly, it would make life much easier on the 
>Version Control perspect

Re: testing clojure.core/group-by with clojure.test.check

[Alex Miller]

Some good links here:

https://github.com/clojure/test.check

But related communities like QuickCheck, ScalaCheck, etc are probably good 
places to look.

Someone should start making something great for test.check on the wiki:

https://github.com/clojure/test.check

Hint hint hint!


On Wednesday, April 30, 2014 3:10:34 PM UTC-5, Tim Visher wrote:
>
> As an aside to the discussion at hand, what papers/books/online 
> articles are good to read to learn about how to come up with good 
> properties and generators? 
>
> On Wed, Apr 30, 2014 at 3:36 PM, Alex Miller 
> > 
> wrote: 
> > The only hard parts about property based testing are the properties and 
> the 
> > generators. ;) 
> > 
> > On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: 
> >> 
> >> Hi, I wanted to get started with clojure.test.check (formerly 
> >> simple-check) and I am new to property based testing. 
> >> 
> >> I plucked clojure.core/group-by for no particular reason as a function 
> to 
> >> test. 
> >> 
> >> I started by stating some properties i think should hold: 
> >> 
> >> ;; 1. applying the grouping key function to each member in a grouping 
> >> should result in the grouping key 
> >> ;; 2. flattening the vals of the group-by result should give back the 
> >> contents of the original collection. 
> >> ;; 3. no element appears in more than one grouping. 
> > 
> > 
> > those seem good 
> > 
> >> 
> >> 
> >> so far so good I think. there may be others but this seems ok for now. 
> >> 
> >> now, how to generate some data. 
> >> 
> >> for group-by we need two params: 
> >> 1) a grouping function 
> >> 2) a collection of items to be grouped 
> >> 
> >> If I start by naively generating collections of maps (containing 
> keyword 
> >> keys and int vals, for example), the data is of the right shape to use 
> in 
> >> group by, but there is no guarantee that: 
> >> 1) any of the maps share a key that I could use for grouping 
> >> 2) the values under a common key are shared 
> >> 
> >> This is really the crux of my problem ideally I would have the 
> >> generator *mostly* produce data which is actually doing to result in 
> the 
> >> sort of collection i might want to call group-by on in real life (ie 
> not 
> >> have everything grouped under nil on each generation). So should i 
> create a 
> >> generator that creates keywords (which i will want to use as grouping 
> >> function) then have another generator that produces what are going to 
> be the 
> >> values under this grouping key, then a generator that uses both of 
> these to 
> >> create collections of maps from these. then i would have to find out 
> what 
> >> the grouping keyword was that was generated this could all work, I 
> have 
> >> read enough about generators to have a stab at this... but is it the 
> right 
> >> approach? 
> > 
> > 
> > You don't seem to be leveraging the possibilities of the grouping 
> function. 
> > If you create a grouping function that maps many random values into a 
> small 
> > number of groups, then everything may get easier. Some candidate 
> functions: 
> > first character of the keyword, length of the keyword, etc. 
> > 
> > Or working backwards is often useful with a generator - generate the 
> > grouping values first, then use the inverse of the grouping function to 
> > generate data that maps to that group and populate the input with that. 
> > 
> >> 
> >> 
> >> as far as implementing tests for the properties so far, I have done 
> >> property 2 above, using a basic generator and yanking out an arbitrary 
> key 
> >> from it clearly a flawed approach as not much 'realistic' grouping 
> is 
> >> going to happen here. 
> >> 
> >> (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that 
> >> not-empty (gen/map gen/keyword gen/int) 
> >> 
> >> (def all-elements-are-grouped 
> >>   (prop/for-all [group-by-input vector-of-maps] 
> >> (let [a-map-key (-> group-by-input first keys first)] 
> ;; 
> >> hmm, seems far from ideal 
> >>   (= (set group-by-input) (-> (group-by a-map-key 
> >> group-by-input) vals flatten set) 
> >> 
> >> help appreciated... perhaps I need to learn more about the paradigm 
> first, 
> >> but resources linked from the readme are all a bit more basic than 
> this. so 
> >> if you know of some more advanced tutorials please let me know. 
> >> 
> >> Thanks 
> > 
> > -- 
> > 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 

Re: Sliding Windows

[Leif]

Since you already like clojurewerkz EEP, why not just add a time-sliding 
window to it?

--Leif

On Wednesday, April 30, 2014 5:13:42 PM UTC-4, Paulo Suzart wrote:
>
> Humm. Actually narretor flushes all messages. Still not what I'm looking 
> for somethiing like this: 
> http://docs.oracle.com/cd/E13157_01/wlevs/docs30/epl_guide/overview.html(see 
> the images).
>
> Thanks anyway
>
>
> On 30 April 2014 12:15, Paulo Suzart >wrote:
>
>> Ow, exactly what I was looking for. Thanks a lot 
>> On 30 Apr 2014 10:26, "dgrnbrg" > 
>> wrote:
>>
>>> We've had lots of luck with Narrator: 
>>> https://github.com/ztellman/narrator
>>>
>>> It's got loads of powerful features, including realtime & batch mode, 
>>> integration with core.async and lamina, windows, functions, and recursive 
>>> analyses.
>>>
>>> On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote:

 Hi Guys,

 I was looking for a very simple stream processing lib. We have some in 
 clojure (lamina, meltdown, esper, eep).

 The simplest one was clojure werkz eep, but they don't provide sliding 
 windows. I ender up writing this: http://paulosuzart.
 github.io/blog/2014/04/27/sliding-window-events-with-clojure/

 And publishing this very small implementation using meltdown. 
 https://github.com/paulosuzart/sw . It is enough for a very simple use 
 case I have to deal. If anyone knows any other sliding window impl please 
 share.

 Regards

 -- 
 Paulo Suzart
 @paulosuzart 

>>>  -- 
>>> 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.
>>>
>>
>
>
> -- 
> Paulo Suzart
> @paulosuzart 
>

-- 
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: Kwargs vs explicit parameter map for APIs?

[Gary Trakhman]

I think they're unaware of the change, as it resulted from a recent
conversation on IRC that same day, where sentiment indicated that kwargs
are generally more trouble than they're worth and there's still confusion
around it.

What started it: the example of keys-destructuring on a list in a let
binding, very odd to explain.
> (let [{:keys [a b c]} '(:a 1 :b 2 :c 3)]
[a b c])

[1 2 3]





On Wed, Apr 30, 2014 at 5:53 PM, Sean Corfield  wrote:

> On Apr 30, 2014, at 8:03 AM, Jim Crossley  wrote:
>
> It's not obvious to me why the "bad" release-sharks example on the coding
> standards page [1] is bad. Why should the optional config be the "least
> variance argument"?
>
> I had to look up "laudable", btw. It's one of those good words that sounds
> bad. :)
>
> [1] http://dev.clojure.org/display/community/Library+Coding+Standards
>
>
> Well, that's a very recent change. Stuart Halloway's version has been the
> standard for years. Reid made those changes only a few days ago - and I saw
> no discussion of the proposed changes so I'd like to hear from Cognitect's
> folks about this: is it a change of heart by Clojure/core or are they
> unaware of the change?
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>

-- 
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: Kwargs vs explicit parameter map for APIs?

[Sean Corfield]

On Apr 30, 2014, at 8:03 AM, Jim Crossley  wrote:
> It's not obvious to me why the "bad" release-sharks example on the coding 
> standards page [1] is bad. Why should the optional config be the "least 
> variance argument"?
> 
> I had to look up "laudable", btw. It's one of those good words that sounds 
> bad. :)
> 
> [1] http://dev.clojure.org/display/community/Library+Coding+Standards

Well, that's a very recent change. Stuart Halloway's version has been the 
standard for years. Reid made those changes only a few days ago - and I saw no 
discussion of the proposed changes so I'd like to hear from Cognitect's folks 
about this: is it a change of heart by Clojure/core or are they unaware of the 
change?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Proposing a new Clojure documentation system (in Clojure)

[Sean Corfield]

On Apr 29, 2014, at 9:42 PM, Atamert Ölçgen  wrote:
> Since I don't use emacs, I would probably have found the former easier.

I don't think Emacs has anything to do with this, even tho' Phil used the 
example of org-mode etc. I agree that if working on the code - and keeping the 
copious documentation in sync - requires anything more than a simple text 
editor, it's going to create obstacles to the workflow.

For a project that has its auxiliary documentation on a Github wiki, you don't 
even need to git clone & edit the repo: you can simply click Edit Page. That's 
about a low a barrier to entry as there can be and we still don't see enough 
contribution to documentation.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Proposing a new Clojure documentation system (in Clojure)

[Sean Corfield]

On Apr 30, 2014, at 11:03 AM, Gregg Reynolds  wrote:
> Controversial:  literate programming is a bad, bad, bad idea.  There is a 
> reason it has never caught on.

I was going to stay out of this discussion but... I agree with Gregg here. All 
that prose just gets in the way and inhibits the largest portion of software 
development: maintenance. Sure, it's great in theory to have all that 
documentation right there when you're first learning a code base, but then it 
just gets in the way - and you're still not guaranteed that any maintenance 
that is done will keep the (extensive) documentation up to date. Most 
programmers just don't work well with prose - neither at reading it nor writing 
it.

I think Clojure's docstrings are a great compromise: something built into the 
language for each "file" (namespace) and each var and function. I wish 
docstrings could be added to some other constructs (defmethod, in particular, 
but also the "pure Java" definterface / defrecord / deftype stuff). Short, 
clear docstrings and well-structured code with well-named symbols short provide 
enough information for maintenance. Rationale, concepts and extensive examples 
belong outside the code for that "first use" scenario, IMO.

> The one thing that I think would be genuinely useful and developer friendly 
> with respect to Clojure is a means of making type signatures explicit.  
> Clojure may be dynamically typed, but everything has an intended type, and I 
> would like to see it.  I'm thinking of something along the way Haskell and 
> other languages express type sigs.  The paradigmatic example is factorial (or 
> fibonacci).  So given a factorial function "fact" I want to be able to write 
> something like (type-sig fact) and get something like "Int -> Int".

Having used core.typed at work, I'll posit that type inference on most Clojure 
code won't actually tell you a lot. The inferred types would be pretty general. 
Even when adding annotations (for core.typed's analysis), it's sometimes 
surprisingly hard to crank down the type signatures and still get everything to 
type check: you often need either much more general types than you might wish 
for or you end up with complex union types, partly due to nil-punning and 
Clojure's view of truthy / falsey.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Sliding Windows

[Paulo Suzart]

Humm. Actually narretor flushes all messages. Still not what I'm looking
for somethiing like this:
http://docs.oracle.com/cd/E13157_01/wlevs/docs30/epl_guide/overview.html(see
the images).

Thanks anyway


On 30 April 2014 12:15, Paulo Suzart  wrote:

> Ow, exactly what I was looking for. Thanks a lot
> On 30 Apr 2014 10:26, "dgrnbrg"  wrote:
>
>> We've had lots of luck with Narrator:
>> https://github.com/ztellman/narrator
>>
>> It's got loads of powerful features, including realtime & batch mode,
>> integration with core.async and lamina, windows, functions, and recursive
>> analyses.
>>
>> On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote:
>>>
>>> Hi Guys,
>>>
>>> I was looking for a very simple stream processing lib. We have some in
>>> clojure (lamina, meltdown, esper, eep).
>>>
>>> The simplest one was clojure werkz eep, but they don't provide sliding
>>> windows. I ender up writing this: http://paulosuzart.
>>> github.io/blog/2014/04/27/sliding-window-events-with-clojure/
>>>
>>> And publishing this very small implementation using meltdown.
>>> https://github.com/paulosuzart/sw . It is enough for a very simple use
>>> case I have to deal. If anyone knows any other sliding window impl please
>>> share.
>>>
>>> Regards
>>>
>>> --
>>> Paulo Suzart
>>> @paulosuzart
>>>
>>  --
>> 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.
>>
>


-- 
Paulo Suzart
@paulosuzart

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

Managing State Changes, using Component

[Timothy Washington]

Hi all,

I'm having a weird state problem with
Component.
Let's say I have a system component, like in fig.1. Starting / stopping and
loading state is fine.
However, let's say I have 2 other components (:updater , :reader) that use
component :a. This is the problem that occurs.

   1. When *:updater*, modifies an atom in *:a*, that change appears in
   path [*:core :a*], not path [*:updater :a*] or [*:a*].
   2. Because of the abouve, when *:reader* goes to it's local path [
   *:reader :a*] to read that change, it doesn't see those modifications.
   3. Using this scheme, *:a* is duplicated 4 times, in the system map.
   However, the modifications only appear in path [*:core :a*]. Thus
   :reader is unable to access it (it's local [*:a*] is unchanged).


(def system-components [:a :updater :reader])

(defrecord Core [env] component/Lifecycle
  (start [this] ...)
  (stop [this] ...))

(defn component-core [env]

  (component/system-map
   :a (component/using
  (ca/component-a env)
  {})
   :updater (component/using
 (cs/component-updater env)
 {:a :a})
   :reader(component/using
 (cs/component-reader env)
 {:a :a})
   :core (component/using
(map->Foobar {:env env})
{:a :a

 :updater :updater

 :reader :reader })))

*fig.1 *


I was hoping to use Component to manage all internal application state. But
maybe it's not designed for this use case (state changes between
components). I imagine that immutability is preventing all those duplicates
from seeing the modifications. However, in this case I do need an update to
:a in one component, to be accessed by another component.

Any suggestions on patterns here? I'm also looking at
component/update-system.
But again, I don't have access to the core *system* var, from within my
components.


Any insights appreciated

Tim Washington
Interruptsoftware.com 

-- 
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: testing clojure.core/group-by with clojure.test.check

[Tim Visher]

As an aside to the discussion at hand, what papers/books/online
articles are good to read to learn about how to come up with good
properties and generators?

On Wed, Apr 30, 2014 at 3:36 PM, Alex Miller  wrote:
> The only hard parts about property based testing are the properties and the
> generators. ;)
>
> On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote:
>>
>> Hi, I wanted to get started with clojure.test.check (formerly
>> simple-check) and I am new to property based testing.
>>
>> I plucked clojure.core/group-by for no particular reason as a function to
>> test.
>>
>> I started by stating some properties i think should hold:
>>
>> ;; 1. applying the grouping key function to each member in a grouping
>> should result in the grouping key
>> ;; 2. flattening the vals of the group-by result should give back the
>> contents of the original collection.
>> ;; 3. no element appears in more than one grouping.
>
>
> those seem good
>
>>
>>
>> so far so good I think. there may be others but this seems ok for now.
>>
>> now, how to generate some data.
>>
>> for group-by we need two params:
>> 1) a grouping function
>> 2) a collection of items to be grouped
>>
>> If I start by naively generating collections of maps (containing keyword
>> keys and int vals, for example), the data is of the right shape to use in
>> group by, but there is no guarantee that:
>> 1) any of the maps share a key that I could use for grouping
>> 2) the values under a common key are shared
>>
>> This is really the crux of my problem ideally I would have the
>> generator *mostly* produce data which is actually doing to result in the
>> sort of collection i might want to call group-by on in real life (ie not
>> have everything grouped under nil on each generation). So should i create a
>> generator that creates keywords (which i will want to use as grouping
>> function) then have another generator that produces what are going to be the
>> values under this grouping key, then a generator that uses both of these to
>> create collections of maps from these. then i would have to find out what
>> the grouping keyword was that was generated this could all work, I have
>> read enough about generators to have a stab at this... but is it the right
>> approach?
>
>
> You don't seem to be leveraging the possibilities of the grouping function.
> If you create a grouping function that maps many random values into a small
> number of groups, then everything may get easier. Some candidate functions:
> first character of the keyword, length of the keyword, etc.
>
> Or working backwards is often useful with a generator - generate the
> grouping values first, then use the inverse of the grouping function to
> generate data that maps to that group and populate the input with that.
>
>>
>>
>> as far as implementing tests for the properties so far, I have done
>> property 2 above, using a basic generator and yanking out an arbitrary key
>> from it clearly a flawed approach as not much 'realistic' grouping is
>> going to happen here.
>>
>> (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that
>> not-empty (gen/map gen/keyword gen/int)
>>
>> (def all-elements-are-grouped
>>   (prop/for-all [group-by-input vector-of-maps]
>> (let [a-map-key (-> group-by-input first keys first)] ;;
>> hmm, seems far from ideal
>>   (= (set group-by-input) (-> (group-by a-map-key
>> group-by-input) vals flatten set)
>>
>> help appreciated... perhaps I need to learn more about the paradigm first,
>> but resources linked from the readme are all a bit more basic than this. so
>> if you know of some more advanced tutorials please let me know.
>>
>> Thanks
>
> --
> 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 recei

Re: testing clojure.core/group-by with clojure.test.check

[Alex Miller]

The only hard parts about property based testing are the properties and the 
generators. ;) 

On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote:
>
> Hi, I wanted to get started with clojure.test.check (formerly 
> simple-check) and I am new to property based testing.
>
> I plucked clojure.core/group-by for no particular reason as a function to 
> test.
>
> I started by stating some properties i think should hold:
>
> ;; 1. applying the grouping key function to each member in a grouping 
> should result in the grouping key
> ;; 2. flattening the vals of the group-by result should give back the 
> contents of the original collection.
> ;; 3. no element appears in more than one grouping.
>

those seem good
 

>
> so far so good I think. there may be others but this seems ok for now. 
>
> now, how to generate some data.
>
> for group-by we need two params:
> 1) a grouping function
> 2) a collection of items to be grouped
>
> If I start by naively generating collections of maps (containing keyword 
> keys and int vals, for example), the data is of the right shape to use in 
> group by, but there is no guarantee that:
> 1) any of the maps share a key that I could use for grouping
> 2) the values under a common key are shared
>
> This is really the crux of my problem ideally I would have the 
> generator *mostly* produce data which is actually doing to result in the 
> sort of collection i might want to call group-by on in real life (ie not 
> have everything grouped under nil on each generation). So should i create a 
> generator that creates keywords (which i will want to use as grouping 
> function) then have another generator that produces what are going to be 
> the values under this grouping key, then a generator that uses both of 
> these to create collections of maps from these. then i would have to find 
> out what the grouping keyword was that was generated this could all 
> work, I have read enough about generators to have a stab at this... but is 
> it the right approach?
>

You don't seem to be leveraging the possibilities of the grouping function. 
If you create a grouping function that maps many random values into a small 
number of groups, then everything may get easier. Some candidate functions: 
first character of the keyword, length of the keyword, etc. 

Or working backwards is often useful with a generator - generate the 
grouping values first, then use the inverse of the grouping function to 
generate data that maps to that group and populate the input with that.
 

>
> as far as implementing tests for the properties so far, I have done 
> property 2 above, using a basic generator and yanking out an arbitrary key 
> from it clearly a flawed approach as not much 'realistic' grouping is 
> going to happen here.
>
> (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that 
> not-empty (gen/map gen/keyword gen/int)
>
> (def all-elements-are-grouped
>   (prop/for-all [group-by-input vector-of-maps]
> (let [a-map-key (-> group-by-input first keys first)] ;; 
> hmm, seems far from ideal
>   (= (set group-by-input) (-> (group-by a-map-key 
> group-by-input) vals flatten set)
>
> help appreciated... perhaps I need to learn more about the paradigm first, 
> but resources linked from the readme are all a bit more basic than this. so 
> if you know of some more advanced tutorials please let me know.
>
> Thanks
>

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

[ANN] packthread 0.1.0

[Jason Felice]

packthread

Threading macros for working with globs of state.
Why?

Many descriptions about state in Clojure fit into the following form:

State is hard to reason about, and so we use pure functions in Clojure. But
then we have a problem, we need to pass around *all*the application's
state. And that's just too hard, and it's basically just like having all
the global variables anyway, and you've coupled every function in the
system to this big ball of mud. So we need to separate it out and
encapsulate and therefore we've invented $library which does *x*, where *x* ∈
{*OO programming*, *global mutable state*, *...*}.

Packthread is different.

Packthread is for threading state through programs in a simple, composable
way. It does not compromise the ability to be functionally pure or reason
about one's program. It's pretty similar to the -> and ->> macros, with a
helper macro named in for creating different *projections* of the state to
manipulate with different functions.
+>

Threads value through forms in much the same way as ->, except for special
handling of the following forms:
if,
if-not, if-let, when, when-not, when-let:

The value is threaded through the then and else clauses independently,
leaving the test conditions alone. If an else clause is missing, it is will
be supplied as though the value had been threaded through identity in that
case.

For example,

(+> 42 (if true inc)) ;=> 43(+> 42 (if false inc)) ;=> 42

In when, when-not, and when-let forms, the value is threaded through each
form in the body, not just the last.
cond

The test clauses are left untouched and the value is threaded through the
expr clauses of each condition. If no :else condition was supplied, +> pretends
as though it has been (identity), and threads the value through that.

For example,

(+> 42
  (cond
(= 1 2)
inc)) ;=> 42
(+> 42
  (cond
(= 1 1)
dec)) ;=> 41

do

The current expr is threaded through the body forms of the do.
in

Threads the inner expressions through a projection of value.

projector is a function which takes two arguments: a value and a function.
It should apply the function to a *projection* of the value, take the
function's result, and reassemble from that result a value which can be
used again in the outer context.

For example,

(+> 42
(in (fn [v f]
  (* 2 (f (/ v 2
  inc)) ;=> 42.5

This can be thought of as 'lifting' the body expressions into the 'world
where things are twice as large'.

As a special case, if projector is a keyword, in assumes that value is a
map and that sub-key are threaded through the inner expressions.

For example,

(+> {:hello 42}
(in :hello
  (+ 5))) ;=> {:hello 47}

This macro can only be used inside +> or +>>.
+>>

Threads expressions like ->>, except with the handling of the special forms
above.

Installing

Leiningen  dependency information:

[com.maitria/packthread "0.1.0"]

Usage

(require '[packthread.core :refer :all])
(+> 42
(if true
  inc)) ;=> 43

See 
core_test.clj
for
examples of usage.
License

Copyright 2014 Maitria

You have permission to use this in any way you like (modify it, sell it,
republish it), provided you agree to all the following conditions:

   - you don't mislead anyone about it
   - you don't interfere with our ability to use it
   - you release us from any claims of liability if it causes problems for
   you

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

browser repl for clojurescript with counterclockwise

[Răzvan Rotaru]

Hi,

Is it possible to have a browser based repl for clojurescript with 
counterclockwise? I tried to set up one as described on the clojurescript 
site, but my impression was that ccw is not able to send forms for 
evaluation.

Cheers,
Razvan

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Jony Hudson]

On Wednesday, 30 April 2014 19:03:24 UTC+1, Gregg Reynolds wrote:

>
> The one thing that I think would be genuinely useful and developer 
> friendly with respect to Clojure is a means of making type signatures 
> explicit.  Clojure may be dynamically typed, but everything has an intended 
> type, and I would like to see it.  I'm thinking of something along the way 
> Haskell and other languages express type sigs.  The paradigmatic example is 
> factorial (or fibonacci).  So given a factorial function "fact" I want to 
> be able to write something like (type-sig fact) and get something like "Int 
> -> Int".
>

(I think someone might have mentioned it above, but it doesn't hurt to 
repeat) you might like schema https://github.com/Prismatic/schema/ .


Jony

-- 
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: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

Granted, but the word "bad" seems harsh without any explanation, especially
if the common usage is to pass an empty map.


On Wed, Apr 30, 2014 at 11:18 AM, Alex Robbins <
alexander.j.robb...@gmail.com> wrote:

> Maybe they want config in the least variance argument so it can be
> partial'ed?
>
>
> On Wed, Apr 30, 2014 at 10:03 AM, Jim Crossley  wrote:
>
>> We used kwargs for options extensively in Immutant 1.x, and we're moving
>> to explicit maps for Immutant 2.x, for the reasons cited above.
>>
>> It's not obvious to me why the "bad" release-sharks example on the coding
>> standards page [1] is bad. Why should the optional config be the "least
>> variance argument"?
>>
>> I had to look up "laudable", btw. It's one of those good words that
>> sounds bad. :)
>>
>> [1] http://dev.clojure.org/display/community/Library+Coding+Standards
>>
>>
>>
>> On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming <
>> colin.mailingl...@gmail.com> wrote:
>>
>>> And thinking about it (after pressing "send", of course), you'd get the
>>> same benefit from destructuring an explicit map in the function parameter
>>> anyway, wouldn't you?
>>>
>>>
>>> On 30 April 2014 22:11, Colin Fleming wrote:
>>>
 But that's only true for the variables which are explicitly
 destructured in the function definition, which in my experience many are
 not - they're often later picked out of an ":as args" argument, perhaps
 dependent on a combination of the parameters which are explicitly
 destructured. Seesaw never does this, for example. I think it's dangerous
 to rely on this rather than the documentation since it's often an
 incomplete view of what the function requires.

 Cheers,
 Colin


 On 30 April 2014 21:03, Joachim De Beule wrote:

> my two cents:
>
> The extra readability to users when using keyword args also comes from
> the fact that a function's options are explicit in its signature. So 
> during
> development, instead of having to look them up in the docs or in the code,
> my emacs mini-buffer simply shows them to me. Although I do agree with all
> the good reasons against keywords arguments, to me this is still the
> decisive reason to prefer them...
>
> Joachim
>
> Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:
>
>> On 30 April 2014 03:54, Sean Corfield  wrote:
>>
>>> I still think the keyword argument approach is far more readable to
>>> _users_
>>
>>
>>  --
> 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.
>>>
>>
>>  --
>> 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

Re: Proposing a new Clojure documentation system (in Clojure)

[Gregg Reynolds]

On Tue, Apr 29, 2014 at 7:44 PM, Phil Hagelberg  wrote:

> On Saturday, April 26, 2014 9:21:26 PM UTC-7, Mars0i wrote:
> > I like the general idea of the Valentin's proposal, but I don't
> > understand every bit of it.  It sounds complicated.  Personally, I'd
> > rather see something that's relatively simple, and good enough, than
> > something that's perfect but unwieldy.  If it's too difficult, people
> > won't use it, or they'll waste time, or feel that the Clojure
> > community expects them to spend too much time on something that
> > detracts from what's important.
>
> Double-inc[1] on this. Clojure needs people who care about documentation
> far more than it needs another documentation system. Don't try to apply a
> technical solution to a social problem.
>


Double-dog dinc.  Having followed this thread I hazard a few reminders of
the obvious.  Code *is* documentation.  Programmers don't like to write
"documentation" - it's hard enough to write good code, and then you want me
to translate my code into clear simple concise English?  (Are you nuts?
Learn to read code!)  Writing good documentation and writing good code are
distinct skills that are very rarely found in a single person.  Good
documentation is expensive.  "Good" means "good enough".

Less obvious: there are at least two distinct notions of documentation in
play.  One is the code: self-documenting documentation.  The other is
arguably meta-documentation: English (usually) prose *about* the code -
which means, about the self-documenting documentation.

Controversial:  literate programming is a bad, bad, bad idea.  There is a
reason it has never caught on.  Ever try to hack Tex?  Did Knuth's
"literate" code help?  Maybe; but people routinely tackle systems that are
just as complex without the added burden of tangle and weave, etc.  Many
years ago I had to do maintenance work on a banking system written entirely
in S/370 assembler.  It was a pain, but it was doable.  Literate
programming would have made it far worse, in my opinion.  Would it be
easier to hack TeX if it had been written without the lit prog cruft?  In
my view the answer is (probably) yes.  (Note that, until relatively
recently, (XeTeX and LuaTex) there was almost no work that built on TeX to
make new stuff - which is what Knuth had hoped for.)  But the more critical
point is that TeX was (mostly) a one-man show.  Literate programming fine
for that, but is utterly, irredeemably, terminally unsuitable for the sorts
of projects that work in the open source world - lots of different people,
scratching lots of different itches, with lots of different opinions about
the Way the World Ought To Work.  I can see no reason to think that
"literate code" is in any way immune to the problems that inevitably
afflict any successful software project - bitrot, feature creep,
over-engineering, under-specification, gradual divergence between
descriptions of the system and what it actually does, pressure to just make
the damn thing work (as opposed to "doing it right"), etc. etc. etc.  My
heart sinks whenever I see a project that looks good but is implemented in
"literate" programming.  If I really like it and want to bang on it, the
first thing I will do is terminate the literate stuff with extreme
prejudice - give me the code, please, and the minimal amount of local
commenting.  I'll read the "literate" docs, but will never code the stuff.

The one thing that I think would be genuinely useful and developer friendly
with respect to Clojure is a means of making type signatures explicit.
Clojure may be dynamically typed, but everything has an intended type, and
I would like to see it.  I'm thinking of something along the way Haskell
and other languages express type sigs.  The paradigmatic example is
factorial (or fibonacci).  So given a factorial function "fact" I want to
be able to write something like (type-sig fact) and get something like "Int
-> Int".

-Gregg

-- 
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: Do not understand the -> macro here

[Roelof Wobben]

Op woensdag 30 april 2014 19:46:41 UTC+2 schreef James Reeves:
>
> The __ needs to be replaced with a function. So essentially it boils down 
> to:
>
> (= (__ [1 2 3 4 5]) 5)
>
> What function when called with [1 2 3 4 5] returns 5?
>
> - James
>

Thats a easy one . That is last. 

But what I try to find out and do not understand is how it boils down to 
that question.
Why make a difficult thing if you could also write down the question that 
you have asked. 

Roelof
 

>
>
> On 30 April 2014 18:18, Roelof Wobben >wrote:
>
>>
>>
>> Op woensdag 30 april 2014 19:12:24 UTC+2 schreef James Reeves:
>>
>>> The 5 is just the last part of the equality statement. This might be 
>>> easier to see by adding in a "let":
>>>
>>> (let [x (__ (sort (rest (reverse [2 5 4 1 3 6]
>>>   y (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))]
>>>   (= x y 5))
>>>
>>> - James
>>>
>>>
>> Sorry I still do  not see it 
>>
>> If I understand it right it will be like this 
>>
>> (let [x (__ [ 1 2 3 4 5] 
>>y (-> [ 1 2 3 4 5] 
>>(= [1 2 3 4 5] [ 1 2 3 4 5]   5)) 
>>
>> it still looks very wierd to me 
>>
>> Roelof
>>  
>>
>
>

-- 
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: Do not understand the -> macro here

[James Reeves]

The __ needs to be replaced with a function. So essentially it boils down
to:

(= (__ [1 2 3 4 5]) 5)

What function when called with [1 2 3 4 5] returns 5?

- James


On 30 April 2014 18:18, Roelof Wobben  wrote:

>
>
> Op woensdag 30 april 2014 19:12:24 UTC+2 schreef James Reeves:
>
>> The 5 is just the last part of the equality statement. This might be
>> easier to see by adding in a "let":
>>
>> (let [x (__ (sort (rest (reverse [2 5 4 1 3 6]
>>   y (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))]
>>   (= x y 5))
>>
>> - James
>>
>>
> Sorry I still do  not see it
>
> If I understand it right it will be like this
>
> (let [x (__ [ 1 2 3 4 5]
>y (-> [ 1 2 3 4 5]
>(= [1 2 3 4 5] [ 1 2 3 4 5]   5))
>
> it still looks very wierd to me
>
> Roelof
>
>

-- 
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: Do not understand the -> macro here

[James Reeves]

The 5 is just the last part of the equality statement. This might be easier
to see by adding in a "let":

(let [x (__ (sort (rest (reverse [2 5 4 1 3 6]
  y (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))]
  (= x y 5))

- James


On 30 April 2014 18:09, Roelof Wobben  wrote:

>
>
> Op woensdag 30 april 2014 18:46:36 UTC+2 schreef James Reeves:
>
>> These two forms are equivalent:
>>
>> (__ (sort (rest (reverse [2 5 4 1 3 6]
>>
>> (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
>>
>> The -> macro turns the second form into the first. You can see this by
>> running macroexpand-all:
>>
>> (require '[clojure.walk :refer [macroexpand-all]])
>>
>> (macroexpand-all '(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__)))
>>
>> This should produce:
>>
>>(__ (sort (rest (reverse [2 5 4 1 3 6]
>>
>> - James
>>
>>
>>
> That what I expected.  what is the benefit of this if the first forms
> already gives the right answer.
> The only thing I still do not see is what the 5) is doing here.
>
> It looks to me of writing something very difficult  where it could be done
> very easy with just the first form.
>
> Roelof
>
>
>

-- 
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: Do not understand the -> macro here

[Roelof Wobben]

Op woensdag 30 april 2014 19:12:24 UTC+2 schreef James Reeves:
>
> The 5 is just the last part of the equality statement. This might be 
> easier to see by adding in a "let":
>
> (let [x (__ (sort (rest (reverse [2 5 4 1 3 6]
>   y (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))]
>   (= x y 5))
>
> - James
>
>
Sorry I still do  not see it 

If I understand it right it will be like this 

(let [x (__ [ 1 2 3 4 5] 
   y (-> [ 1 2 3 4 5] 
   (= [1 2 3 4 5] [ 1 2 3 4 5]   5)) 

it still looks very wierd to me 

Roelof
 

-- 
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: Do not understand the -> macro here

[Roelof Wobben]

Op woensdag 30 april 2014 18:46:36 UTC+2 schreef James Reeves:
>
> These two forms are equivalent:
>
> (__ (sort (rest (reverse [2 5 4 1 3 6]
>
> (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
>
> The -> macro turns the second form into the first. You can see this by 
> running macroexpand-all:
>
> (require '[clojure.walk :refer [macroexpand-all]])
>
> (macroexpand-all '(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__)))
>
> This should produce:
>
>(__ (sort (rest (reverse [2 5 4 1 3 6]
>
> - James
>
>
>
That what I expected.  what is the benefit of this if the first forms 
already gives the right answer. 
The only thing I still do not see is what the 5) is doing here. 

It looks to me of writing something very difficult  where it could be done 
very easy with just the first form. 

Roelof
 
 

-- 
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: Do not understand the -> macro here

[James Reeves]

These two forms are equivalent:

(__ (sort (rest (reverse [2 5 4 1 3 6]

(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))

The -> macro turns the second form into the first. You can see this by
running macroexpand-all:

(require '[clojure.walk :refer [macroexpand-all]])

(macroexpand-all '(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__)))

This should produce:

   (__ (sort (rest (reverse [2 5 4 1 3 6]

- James


On 30 April 2014 16:28, Roelof Wobben  wrote:

> On 4 clojure there it this exercise:
>
> (= (__ (sort (rest (reverse [2 5 4 1 3 6]
>(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
>5)
>
> if I understand it right this is happen
>
> reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ]
> Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2]
> Sort this and you get [ 1 2 3 4 5]
>
> This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [
> 1 2 3 4 5]
>
> what does the (__)) 5) does exactly. When I change the 5 to another number
> the outcome is not changed.
> And where does clojure put the first [ 1 2 3 4 5 ] in the second form ?
>
> Roelof
>
>
>
>  --
> 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: require and jtransforms

[Leif]

Hi, Alan.

'require' is only for clojure libs.  For Java packages, use 'import':

user=> (import '[edu.emory.mathcs.jtransforms.fft  DoubleFFT_1D])
edu.emory.mathcs.jtransforms.fft.DoubleFFT_1D
user=> (def da (double-array (range 0 10 0.01)))
#'user/da
user=> (def fft (DoubleFFT_1D. (count da)))
#'user/fft
user=> (.realForward fft da) ;; operates in-place
Reflection warning, /tmp/form-init1030205091778006036.clj:1:9 - call to 
realForward can't be resolved.
user=> (first da)
5004.9934

Also, as you may already be aware, the Maven coordinates and the Java 
package names are not necessarily the same or even similar.

--Leif

On Wednesday, April 30, 2014 11:40:31 AM UTC-4, Alan Forrester wrote:
>
> I would like to try the JTransforms Java FFT library from Clojure: 
>
> https://sites.google.com/site/piotrwendykier/software/jtransforms 
>
> I created a new folder went to that folder in a console and typed 
>
> lein try net.sourceforge.jtransforms/jtransforms "2.4.0" 
>
> lein try retrieved some jars and poms from central, presumably 
> jtransforms and its dependencies and started a REPL. 
>
> Having got this far I can't seem to figure out how to require 
> jtransforms in the REPL. I have tried 
>
> (require '[x :as trans]) 
>
> for various values of x such as 
> "net.sourceforge.jtransforms/jtransforms" and 
> "net.sourceforge.jtransforms.jtransforms", "jtransforms.jtransforms" 
> and the REPL keeps saying 
>
> FileNotFoundException Could not locate jtranforms__init.class or 
> jtransforms.clj on classpath: clojure.lang.RT.load (RT.java:443) 
>
> I think I must be misunderstanding how to download libraries and their 
> dependencies or how to require them when they have been downloaded. 
> Can anybody shed some light on this for me? 
>
> Thanks, 
> Alan 
>

-- 
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: require and jtransforms

[James Reeves]

Java libraries are handled differently to native Clojure libraries. You can
either enter the full class with packages, such as:

(java.util.UUID/randomUUID)

Or you can use import to access the class without the package:

(import 'java.util.UUID)
(UUID/randomUUID)

To check you have access to the java library, try entering the following
class name at the REPL:

edu.emory.mathcs.jtransforms.fft.DoubleFFT_1D

If the library is loaded, this should return a class object, rather than
erroring.

- James


On 30 April 2014 16:40, Alan Forrester
wrote:

> I would like to try the JTransforms Java FFT library from Clojure:
>
> https://sites.google.com/site/piotrwendykier/software/jtransforms
>
> I created a new folder went to that folder in a console and typed
>
> lein try net.sourceforge.jtransforms/jtransforms "2.4.0"
>
> lein try retrieved some jars and poms from central, presumably
> jtransforms and its dependencies and started a REPL.
>
> Having got this far I can't seem to figure out how to require
> jtransforms in the REPL. I have tried
>
> (require '[x :as trans])
>
> for various values of x such as
> "net.sourceforge.jtransforms/jtransforms" and
> "net.sourceforge.jtransforms.jtransforms", "jtransforms.jtransforms"
> and the REPL keeps saying
>
> FileNotFoundException Could not locate jtranforms__init.class or
> jtransforms.clj on classpath: clojure.lang.RT.load (RT.java:443)
>
> I think I must be misunderstanding how to download libraries and their
> dependencies or how to require them when they have been downloaded.
> Can anybody shed some light on this for me?
>
> Thanks,
> Alan
>
> --
> 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: Do not understand the -> macro here

[Dmitry Lipovoi]

It looks like a quiz. Which function should stand in place of underscores
to give 5 in result?


On Wed, Apr 30, 2014 at 7:28 PM, Roelof Wobben  wrote:

> On 4 clojure there it this exercise:
>
> (= (__ (sort (rest (reverse [2 5 4 1 3 6]
>(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
>5)
>
> if I understand it right this is happen
>
> reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ]
> Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2]
> Sort this and you get [ 1 2 3 4 5]
>
> This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [
> 1 2 3 4 5]
>
> what does the (__)) 5) does exactly. When I change the 5 to another number
> the outcome is not changed.
> And where does clojure put the first [ 1 2 3 4 5 ] in the second form ?
>
> Roelof
>
>
>
>  --
> 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: Example of using ANTLR from Clojure?

[kranthi rajoli]

Thank you very much. This definitely helps.

-Kranthi


On Sat, Apr 26, 2014 at 9:17 PM, Armando Blancas wrote:

> I haven't touched this project in a while, but it might be useful.
> https://github.com/blancas/tinypost
> This file has the relevant interop code:
> src/main/clojure/blancas/tinypost/scan.clj
>
> On Saturday, April 26, 2014 3:04:50 AM UTC-7, Kranthi Rajoli wrote:
>
>> Hi Paul,
>>   Do you mind outlining the method you used? I am exactly looking for the
>> same. My Java skills are pathetic too.
>>
>> Thanks,
>> Kras
>>
>> On Wednesday, September 9, 2009 4:17:07 AM UTC+5:30, Paul Henning wrote:
>>>
>>> Thanks for the information.  Once I bit the bullet and learned a bit
>>> of Java, it was actually pretty easy to call ANTLR from clojure, after
>>> getting all the package naming figured out.
>>>
>>> Paul
>>>
>>> On Sep 6, 6:22 am, Laurent PETIT  wrote:
>>> > 2009/9/5 Mike Hinchey 
>>> >
>>> > > I don't know anything about it, but counterclockwise uses antlr.
>>> >
>>> > >http://groups.google.com/group/clojuredev-devel/browse_
>>> thread/thread/...
>>> >
>>> > That's true. To be more precise, we have a clojure lexer which is
>>> > extensively used in Counterclockwise clojure source editor for syntax
>>> > coloration. There is also the lexer part but it was developed a long
>>> time
>>> > ago (so may not be still accurate), and is not used yet (so maybe the
>>> way
>>> > the AST is constructed is nood in the good shape for most purpose).
>>> >
>>> > But to come back to your concern of using antlr from clojure : no,
>>> > Counterclockwise is not yet written in clojure (just the client/server
>>> part
>>> > for communicating with running projects instances) and so you wil not
>>> be
>>> > able to find examples for that, sorry :-(
>>> >
>>> > --
>>> > Laurent
>>
>>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/vdUGQRwDYWo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kranthi Rajoli

-- 
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: Do not understand the -> macro here

[Walter van der Laan]

You have to replace the underscore with a function. The value of (= (_ [1 2 
3 4 5]) 5) must be true. So the value of (_ [1 2 3 4 5]) must be 5. So the 
function you are looking for will have to return the last element of the 
array.

On Wednesday, April 30, 2014 5:28:26 PM UTC+2, Roelof Wobben wrote:
>
> On 4 clojure there it this exercise: 
>
> (= (__ (sort (rest (reverse [2 5 4 1 3 6]
>(-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
>5)
>
> if I understand it right this is happen
>
> reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ] 
> Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2] 
> Sort this and you get [ 1 2 3 4 5] 
>
> This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [ 
> 1 2 3 4 5] 
>
> what does the (__)) 5) does exactly. When I change the 5 to another number 
> the outcome is not changed.
> And where does clojure put the first [ 1 2 3 4 5 ] in the second form ?
>
> Roelof
>
>
>
>

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

require and jtransforms

[Alan Forrester]

I would like to try the JTransforms Java FFT library from Clojure:

https://sites.google.com/site/piotrwendykier/software/jtransforms

I created a new folder went to that folder in a console and typed

lein try net.sourceforge.jtransforms/jtransforms "2.4.0"

lein try retrieved some jars and poms from central, presumably
jtransforms and its dependencies and started a REPL.

Having got this far I can't seem to figure out how to require
jtransforms in the REPL. I have tried

(require '[x :as trans])

for various values of x such as
"net.sourceforge.jtransforms/jtransforms" and
"net.sourceforge.jtransforms.jtransforms", "jtransforms.jtransforms"
and the REPL keeps saying

FileNotFoundException Could not locate jtranforms__init.class or
jtransforms.clj on classpath: clojure.lang.RT.load (RT.java:443)

I think I must be misunderstanding how to download libraries and their
dependencies or how to require them when they have been downloaded.
Can anybody shed some light on this for me?

Thanks,
Alan

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Sean Johnson]

Valentin, et al,

I'm a little late to the thread here, but I'm the author of lein-sphinx 
which you mentioned in your (well thought out) post so I thought I'd weigh 
in here.

I agree with a lot of what you wrote in your proposal, and for many 
projects (not all of them, but many) there is an important role for 
documentation that is separate from code. Maybe there needs to be a chapter 
length explanation of system X that your library is intending to interact 
with system X before the code (and docstrings) even make any sense to 
someone new to the codebase. You're going to put all that content in the 
code in doc strings? No. Maybe you put it in Markdown and let GitHub render 
it, but even with GH's proprietary extensions of MD, it's limited when 
compared to something like Sphinx and reStructured Text.

So that's where something like lein-sphinx comes in, and I built that 
simply as a necessary evil. I'm not a big Python guy, or a fan of 
reStructured Text or Sphinx, but I felt there was nothing equivalent for 
building up real substantial docs in Clojure.

I have some specific thoughts on your proposal are below:

I've been thinking for a while that the Clojure community could benefit a 
> lot from a more sophisticated and ergonomic documentation system. 
>

I would have said "usable", but I love your choice of "ergonomic" here to 
describe software. I think "usability" is a bit of an overused word that's 
lost some of its power. I'm going to steal this and start using 
"ergonomic". Thanks!

I have seen some existing plugins like lein-sphinx, but I think it would be 
> really good to have documentation that would be written in Clojure, for the 
> following reasons :
>
>- we're all very fond of Clojure data structures and their syntax. (I 
>don't know about you, but I find that even HTML looks better in 
> Clojurethan in HTML). Plus, Clojure 
> programmers already know how to edit them.
>
> hmmm... I like that we could use Clojure syntax to describe Clojure syntax 
and Clojure data structures. I'm not so sure I'm so fond of Clojure syntax 
that I want to use it for sentences. And I don't think HTML looks better in 
Clojure, there's a lot of really nasty HTML out there. Nasty HTML looks 
nasty in Clojure too, and nice HTML looks better in HTML than in Clojure. 

>
>- (better reason) The facts that Vars are first-class citizens and 
>that symbols can be referred explicitly with hardly any ceremony (macros) 
>are a exceptional opportunity to make smart and highly-structured 
>documentation very easily.
>
> mmk. 

>
>- if it's in Clojure, Clojure programmers can seamlessly build *ad 
> hoc*documentation functionality on top of it to suit their own particular 
> needs.
>
> I like this reason.
 

> I haven't found anything of the like yet, and if it exists, I would be 
> grateful if someone would redirect me to it.
>
It doesn't exist unless someone has built it internally and is keeping it 
for themselves (not likely). Fergal's suggestion of lein-midje-doc is 
probably the closest.
 

> Here are *my thoughts on this :*
>
>1. Clojure doc-strings, although they are quite handy as reminders and 
>for doc-indexation, are *too raw a content*. Even when they are done 
>right, they tend to be cumbersome, and it's too bad to have such concise 
>code drown in the middle of so much documentation. What's more, I believe 
>that when programmers program a function (or anything), they tend to think 
>more about the implementation than the (uninformed) usage, so they have 
>little incentive to make it right.
>
> I think doc strings are necessary, but not sufficient. I think there *is*a 
> role for documentation in the code, otherwise you end up duplicating 
documentation in the separate docs and docstrings, or in comments, so a 
Clojure documentation framework/solution probably out to be able to make 
use of doc strings by pulling out their content. It ought to also pull out 
things like :pre and :post. It ought to use the code to make writing the 
docs as easy and boilerplate free as possible. But again, when you need a 
lot of docs, tutorials, etc. putting that stuff directly in the code is a 
mess.

>
>1. Building on 1. having a system where documentation and programs 
>live in separate files, in the same way as tests, would enforce a healthy 
>separation of concerns. Importantly, it would make life much easier on the 
>Version Control perspective.
>
> Yes. And just how tests refer back to the code they are testing. I think 
docs need to be able to refer back to the vars/atoms/functions/doc strings 
etc. of the code they are documenting.
 

>
>1. Documentation should probably be made differently than what people 
>have got accustomed to by classical languages. Because you seldom find 
>types, and because IMHO Clojure programs are formed more by factoring out 
>recurring mechanisms in cod

Do not understand the -> macro here

[Roelof Wobben]

On 4 clojure there it this exercise: 

(= (__ (sort (rest (reverse [2 5 4 1 3 6]
   (-> [2 5 4 1 3 6] (reverse) (rest) (sort) (__))
   5)

if I understand it right this is happen

reverse[ 2 5 4 1 3 6] gives [ 6 3 1 4 5 2 ] 
Then rest [ 6 3 1 4 5 2] gives [ 3 1 4 5 2] 
Sort this and you get [ 1 2 3 4 5] 

This part : [2 5 4 1 3 6] (reverse) (rest) (sort) gives the same output: [ 
1 2 3 4 5] 

what does the (__)) 5) does exactly. When I change the 5 to another number 
the outcome is not changed.
And where does clojure put the first [ 1 2 3 4 5 ] in the second form ?

Roelof



-- 
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: Kwargs vs explicit parameter map for APIs?

[Alex Robbins]

Maybe they want config in the least variance argument so it can be
partial'ed?


On Wed, Apr 30, 2014 at 10:03 AM, Jim Crossley  wrote:

> We used kwargs for options extensively in Immutant 1.x, and we're moving
> to explicit maps for Immutant 2.x, for the reasons cited above.
>
> It's not obvious to me why the "bad" release-sharks example on the coding
> standards page [1] is bad. Why should the optional config be the "least
> variance argument"?
>
> I had to look up "laudable", btw. It's one of those good words that sounds
> bad. :)
>
> [1] http://dev.clojure.org/display/community/Library+Coding+Standards
>
>
>
> On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> And thinking about it (after pressing "send", of course), you'd get the
>> same benefit from destructuring an explicit map in the function parameter
>> anyway, wouldn't you?
>>
>>
>> On 30 April 2014 22:11, Colin Fleming wrote:
>>
>>> But that's only true for the variables which are explicitly destructured
>>> in the function definition, which in my experience many are not - they're
>>> often later picked out of an ":as args" argument, perhaps dependent on a
>>> combination of the parameters which are explicitly destructured. Seesaw
>>> never does this, for example. I think it's dangerous to rely on this rather
>>> than the documentation since it's often an incomplete view of what the
>>> function requires.
>>>
>>> Cheers,
>>> Colin
>>>
>>>
>>> On 30 April 2014 21:03, Joachim De Beule wrote:
>>>
 my two cents:

 The extra readability to users when using keyword args also comes from
 the fact that a function's options are explicit in its signature. So during
 development, instead of having to look them up in the docs or in the code,
 my emacs mini-buffer simply shows them to me. Although I do agree with all
 the good reasons against keywords arguments, to me this is still the
 decisive reason to prefer them...

 Joachim

 Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:

> On 30 April 2014 03:54, Sean Corfield  wrote:
>
>> I still think the keyword argument approach is far more readable to
>> _users_
>
>
>  --
 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.
>>
>
>  --
> 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 unsubscr

Re: Sliding Windows

[Paulo Suzart]

Ow, exactly what I was looking for. Thanks a lot
On 30 Apr 2014 10:26, "dgrnbrg"  wrote:

> We've had lots of luck with Narrator: https://github.com/ztellman/narrator
>
> It's got loads of powerful features, including realtime & batch mode,
> integration with core.async and lamina, windows, functions, and recursive
> analyses.
>
> On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote:
>>
>> Hi Guys,
>>
>> I was looking for a very simple stream processing lib. We have some in
>> clojure (lamina, meltdown, esper, eep).
>>
>> The simplest one was clojure werkz eep, but they don't provide sliding
>> windows. I ender up writing this: http://paulosuzart.
>> github.io/blog/2014/04/27/sliding-window-events-with-clojure/
>>
>> And publishing this very small implementation using meltdown.
>> https://github.com/paulosuzart/sw . It is enough for a very simple use
>> case I have to deal. If anyone knows any other sliding window impl please
>> share.
>>
>> Regards
>>
>> --
>> Paulo Suzart
>> @paulosuzart
>>
>  --
> 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: Kwargs vs explicit parameter map for APIs?

[Jim Crossley]

We used kwargs for options extensively in Immutant 1.x, and we're moving to
explicit maps for Immutant 2.x, for the reasons cited above.

It's not obvious to me why the "bad" release-sharks example on the coding
standards page [1] is bad. Why should the optional config be the "least
variance argument"?

I had to look up "laudable", btw. It's one of those good words that sounds
bad. :)

[1] http://dev.clojure.org/display/community/Library+Coding+Standards



On Wed, Apr 30, 2014 at 6:14 AM, Colin Fleming
wrote:

> And thinking about it (after pressing "send", of course), you'd get the
> same benefit from destructuring an explicit map in the function parameter
> anyway, wouldn't you?
>
>
> On 30 April 2014 22:11, Colin Fleming  wrote:
>
>> But that's only true for the variables which are explicitly destructured
>> in the function definition, which in my experience many are not - they're
>> often later picked out of an ":as args" argument, perhaps dependent on a
>> combination of the parameters which are explicitly destructured. Seesaw
>> never does this, for example. I think it's dangerous to rely on this rather
>> than the documentation since it's often an incomplete view of what the
>> function requires.
>>
>> Cheers,
>> Colin
>>
>>
>> On 30 April 2014 21:03, Joachim De Beule wrote:
>>
>>> my two cents:
>>>
>>> The extra readability to users when using keyword args also comes from
>>> the fact that a function's options are explicit in its signature. So during
>>> development, instead of having to look them up in the docs or in the code,
>>> my emacs mini-buffer simply shows them to me. Although I do agree with all
>>> the good reasons against keywords arguments, to me this is still the
>>> decisive reason to prefer them...
>>>
>>> Joachim
>>>
>>> Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:
>>>
 On 30 April 2014 03:54, Sean Corfield  wrote:

> I still think the keyword argument approach is far more readable to
> _users_


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

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Mars0i]

Tim, I am in full support of the approach to documentation that you 
describe, for individuals and organizations that feel that it best supports 
their needs.  It's a good approach.  I don't favor requiring an entire 
programming community to follow it.  That's too much of an imposition.  I 
do like the idea of more minimal norms for a community.  Docstrings are a 
good start, but I can see the benefits of slightly more systematic norms or 
tools for (e.g.) docstrings, or references to more information.  I think 
that it's a matter of degree.  Minimal norms shouldn't require too much of 
programmers.  It should be pretty obvious to any experienced programmer 
that such a norm will be worth following, and it should be easy to follow 
it.  Maybe there should also be norms for more elaborate kinds of 
documentation for those organizations that want more elaborate kinds--that 
way, there will be some uniformity among such organizations.  That might be 
the best of both worlds: An adequate minimal norm for documentation, with 
easy-to-use tool support, plus norms and tool support for extensions to the 
minimal norm.

On Wednesday, April 30, 2014 2:09:04 AM UTC-5, da...@axiom-developer.org 
wrote:
>
> > Imagine you're reading through some documentation and you notice a 
> > problem. Maybe a typo, or something out of date, or something that's 
> > confusing that you could explain better. In one scenario there's a "git 
> > clone" link in the sidebar to a repository that contains a bunch of 
> > markdown files. In another scenario there's an HTML rendering generated 
> > from a literate programming project where the prose is intermixed with 
> the 
> > code and requires a specific version of org-mode and the knowledge of 
> how 
> > to "untangle" something in order to render it. 
>
> This is a focus on the technology which I'm reluctant to do, mostly 
> because I have strong opinions about it. I will say from experience that 
> any technology that separates code from explanation will fail. If we 
> focus on what information we require and what structure has to be placed 
> on that information so it can be understood THEN we can ask about the 
> technologies and what they support. 
>
> > Can I ask, quite seriously and not intending any sarcasm, what you mean 
> > by "detracts from what's important"? 
> > 
> > For me, "what's important" is to communicate ideas, designs, and details 
> > from one developer to another so that others can maintain, modify, and 
> > extend what exists. I've already held forth on what I think that implies 
> > so I won't bore you with it. 
>
>
> Consider Clojure's primary data structure implementation. It is 
> basically an immutable, log32, red-black tree. For some people that is 
> more than sufficient, especially if they have been working in the code 
> base for years. 
>
> For others, especially as a developer new to the project, there is a lot 
> to know. Without this information it is very difficult to contribute. 
>
> A new developer needs an introduction to the IDEA of immutable data 
> structures with a reference to Okasaki's thesis which is online at 
> http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf (a bibliography). 
>
> A new developer needs to know that the DESIGN of Clojure relies on these 
> immutable data structures so they don't introduce any "quick and 
> efficient" hacks that violate the design. (a Clojure overview) 
>
> A new developer needs to know WHAT a red-black tree is, WHY it was 
> chosen, and HOW Clojure maps user-visible data structures to them.   
> (the chapter on this particular data structure) 
>
> A new developer needs to know the IMPLICATIONS of the choice of log32 
> since it defines the efficiency. (the design constraints section and 
> the algorithmic analysis section) 
>
> A new developer needs to know HOW to update a log32 immutable red-black 
> tree.  (a pseudocode explanation with pictures) 
>
> A new developer needs to know HOW the log32 red-black tree is 
> implemented.  It is not immediately obvious how the 5-bit chunks are 
> mapped into a 32 bit word. If the task was to re-implement it on a 64 
> bit word they'd have to know the details to understand the code.  (the 
> actual code with explanations of the variables) 
>
> If the new developer's task is to modify the code for a 64 bit 
> architecture they would need a way to find the code (the table of 
> contents) and places where this information is mentioned (an index). 
> All of the places where it is written need to be properly updated. 
>
> Even if we focus strictly on what a new developer needs to know 
> we end up with something that smells a lot like a book. From the 
> above we see the need for 
>
>   1) a bibliography 
>   2) a Clojure overview 
>   3) a chapter focus on this data structure 
>   4) sections on design constraints and algorithmic analysis 
>   5) a section of pseudocode with pictures 
>   6) a section with code and details of the actual implementation 
>   7) a table of

Datascript and React.js for a Clojure web app

[Gijs S.]

Hi all,

I've released a Clojure web application. It includes a front-end using 
DataScript and React.js in ClojureScript.

More details here: 
http://thegeez.net/2014/04/30/datascript_clojure_web_app.html

The code is on github: https://github.com/thegeez/clj-crud

Demo on heroku: http://clj-crud.herokuapp.com/

Best regards,
Gijs 

-- 
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: Sliding Windows

[dgrnbrg]

We've had lots of luck with Narrator: https://github.com/ztellman/narrator

It's got loads of powerful features, including realtime & batch mode, 
integration with core.async and lamina, windows, functions, and recursive 
analyses.

On Tuesday, April 29, 2014 10:25:39 PM UTC-4, Paulo Suzart wrote:
>
> Hi Guys,
>
> I was looking for a very simple stream processing lib. We have some in 
> clojure (lamina, meltdown, esper, eep).
>
> The simplest one was clojure werkz eep, but they don't provide sliding 
> windows. I ender up writing this: 
> http://paulosuzart.github.io/blog/2014/04/27/sliding-window-events-with-clojure/
>
> And publishing this very small implementation using meltdown. 
> https://github.com/paulosuzart/sw . It is enough for a very simple use 
> case I have to deal. If anyone knows any other sliding window impl please 
> share.
>
> Regards
>
> -- 
> Paulo Suzart
> @paulosuzart 
>

-- 
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 Office Hours

[Tim Visher]

This is getting to the point where it seems to make sense as a wiki
page like http://dev.clojure.org/display/community/Clojure+User+Groups

Maybe http://dev.clojure.org/display/community/Clojure+Office+Hours ?

On Tue, Apr 29, 2014 at 5:53 PM, Lynn Grogan  wrote:
> This is awesome, thank you Leif!
>
> I just set up an office hours account to help anyone who might be interested
> in organizing a Clojure tech conference or event, Meetup, etc.
> I chose some random office times, so ping me if you have a special timing
> request outside of the listed hours.
>
> https://lynn.youcanbook.me/
>
> Cheers! Lynn Grogan (Cognitect, Events Manager)
>
> On Monday, April 28, 2014 5:31:04 AM UTC-5, Ulises wrote:
>>
>> Thanks for the pointer Jakob. I've updated the form accordingly.
>>
>> Cheers,
>>
>>
>> On 28 April 2014 10:56, Jakub Holy  wrote:
>>>
>>> I too have booked a session with Ulises and am excited about it :-)
>>>
>>> @Ulises It would be nice if the timezone of the session was mentioned on
>>> the booking page (your [BST] 9-10am is mine [CEST] 10-11, I believe).
>>>
>>>
>>> 2014-04-28 11:09 GMT+02:00 Rudi Engelbrecht :

 Hi Ulises

 Just finished our session - wow!

 I have learned a lot by watching how you approach solving the problem I
 suggested.

 Looking forward to our next session and thanks a lot for sharing your
 knowledge.

 Kind regards

 Rudi Engelbrecht



 On 18/04/2014, at 7:41 PM, Ulises  wrote:

 Yikes! Got my first booking for Monday. That was quick!

 one thing I forgot to mention is that I have no preferred way to do
 this. I personally have emacs+cider set up, but I'm happy to work with your
 own set up.

 In the past I've used ScreenHero (not available for Linux unfortunately)
 for screen sharing, as well as Google hangouts.

 Once you've booked an appointment with me please email me privately to
 arrange the pairing set up so that I can be ready for you :)

 Cheers


 On 18 April 2014 10:35, Ulises  wrote:
>
> Inspired by Leif's offer, I've decided to offer Clojure office hours as
> well.
>
> I'm based in the UK so I reckon the times will be more amenable to
> those in Europe (not sure the times will be good for those in Asia
> unfortunately.)
>
> Sadly the offer is limited to 1h a day, but hopefully it'll still be
> useful.
>
> You can book me at https://ucb.youcanbook.me/
>
> Cheers!
>
>
> On 18 April 2014 03:03, Leif  wrote:
>>
>> @Miguel: There are somewhat subtle arrows on the sides for navigation.
>> Thursday, April 24 is still open.  I will give a slot to you if you want
>> one, just email me if the 24th is full when you check again.
>>
>> @all: But yes, this round of office hours is almost over.  I will be
>> in transit for at least a couple weeks in the beginning of May, but I 
>> will
>> probably book some more hours when I become stationary again.  It will
>> probably be more like 4 or 5 hours a week, though, not 8.
>>
>> @all: Several poor souls from Europe are going to stay up until 2 a.m.
>> for this, and people further east are probably just silent because the 
>> time
>> difference is so large; So, I definitely think some European / African /
>> Asian / Australian clojure devs' office hours would be popular.  It's 
>> fun,
>> and you might find some people to hire, if that's your thing!
>>
>> --Leif
>>
>>
>> On Thursday, April 17, 2014 10:43:50 AM UTC-4, Miguel Ping wrote:
>>>
>>> Hey, the schedule's full! :\
>>>
>>> On Wednesday, April 16, 2014 2:57:49 AM UTC+1, Marcus Blankenship
>>> wrote:

 Leif, thanks for the great session today.  Not only did I get a jump
 start on my next 4Clojure problems, but I learned some emacs as well!  
 Very
 enjoyable, and I look forward to next week’s session.  THANK YOU!

 All, if you’re trying to get a jumpstart on Clojure, I highly
 recommend Leif’s office hours.

 -Marcus

 On Apr 15, 2014, at 6:50 PM, Leif  wrote:

 @Jakub: Thanks for your kind words.  I'm definitely no "industry
 hero," but I hope Clojure devs of all levels start having more pair
 programming fun.

 @Tim: Clojurescript UI programming being way out of my comfort zone,
 I learned quite a lot from you yesterday.  So thank you.

 @Everyone:  To clarify / reiterate:  You do not need a plan, a
 project, or a specific problem.  If you want to work through Project 
 Euler,
 4clojure, clojure-koans, the ClojureBridge materials, some other 
 clojure
 tutorial, or just play it by ear, I am happy to try it out.

 --Leif

 On Tuesd

testing clojure.core/group-by with clojure.test.check

[henry w]

Hi, I wanted to get started with clojure.test.check (formerly simple-check) 
and I am new to property based testing.

I plucked clojure.core/group-by for no particular reason as a function to 
test.

I started by stating some properties i think should hold:

;; 1. applying the grouping key function to each member in a grouping 
should result in the grouping key
;; 2. flattening the vals of the group-by result should give back the 
contents of the original collection.
;; 3. no element appears in more than one grouping.

so far so good I think. there may be others but this seems ok for now. 

now, how to generate some data.

for group-by we need two params:
1) a grouping function
2) a collection of items to be grouped

If I start by naively generating collections of maps (containing keyword 
keys and int vals, for example), the data is of the right shape to use in 
group by, but there is no guarantee that:
1) any of the maps share a key that I could use for grouping
2) the values under a common key are shared

This is really the crux of my problem ideally I would have the 
generator *mostly* produce data which is actually doing to result in the 
sort of collection i might want to call group-by on in real life (ie not 
have everything grouped under nil on each generation). So should i create a 
generator that creates keywords (which i will want to use as grouping 
function) then have another generator that produces what are going to be 
the values under this grouping key, then a generator that uses both of 
these to create collections of maps from these. then i would have to find 
out what the grouping keyword was that was generated this could all 
work, I have read enough about generators to have a stab at this... but is 
it the right approach?

as far as implementing tests for the properties so far, I have done 
property 2 above, using a basic generator and yanking out an arbitrary key 
from it clearly a flawed approach as not much 'realistic' grouping is 
going to happen here.

(def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that 
not-empty (gen/map gen/keyword gen/int)

(def all-elements-are-grouped
  (prop/for-all [group-by-input vector-of-maps]
(let [a-map-key (-> group-by-input first keys first)] ;; 
hmm, seems far from ideal
  (= (set group-by-input) (-> (group-by a-map-key 
group-by-input) vals flatten set)

help appreciated... perhaps I need to learn more about the paradigm first, 
but resources linked from the readme are all a bit more basic than this. so 
if you know of some more advanced tutorials please let me know.

Thanks

-- 
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: Sliding Windows

[François Rey]

On 30/04/14 04:25, Paulo Suzart wrote:

If anyone knows any other sliding window impl please share.

Riemann seems to have one:
http://riemann.io/howto.html#group-events-in-time

--
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: Proposing a new Clojure documentation system (in Clojure)

[Phillip Lord]

Phil Hagelberg  writes:

> On Saturday, April 26, 2014 9:21:26 PM UTC-7, Mars0i wrote:
>> I like the general idea of the Valentin's proposal, but I don't
>> understand every bit of it.  It sounds complicated.  Personally, I'd
>> rather see something that's relatively simple, and good enough, than
>> something that's perfect but unwieldy.  If it's too difficult, people
>> won't use it, or they'll waste time, or feel that the Clojure
>> community expects them to spend too much time on something that
>> detracts from what's important.
>
> Double-inc[1] on this. Clojure needs people who care about documentation 
> far more than it needs another documentation system. Don't try to apply a 
> technical solution to a social problem.


Consider this argument, of the same form.

What the JVM needs is people who care about writing good code far more
than it needs another JVM hosted language. Don't try and apply a
technical solution to a social problem.


Following this logic, we can just dump Clojure and use Java; in fact, if
we do this, we will achieve a better documentation system than we have
at the moment, because javadoc is better than Clojure's system.

Of course, technical solutions don't solve all problems, and authoring
documentation is difficult to start off with; but Clojure's current
system -- an unstructured string -- is not a good tool. Compare Emacs
doc

Compare these two strings:

Returns a new seq where x is the first element and seq is
the rest.

Create a new cons, give it CAR and CDR as components, and return it.


In the latter, we can distinguish CAR and CDR as parameters. In the
former, cannot. We could look at arglist

:arglists '([x seq])

which tells us. However, we have "a new seq" and "seq is the rest" --
one refering to the formal parameter and the other refering to the
clojure abstraction. And neither refering to clojure.core/seq which we
might otherwise want to hyperlink to.

We could change it to this

Returns a new object implementing the ISeq interface, where the formal
parameter x is the first element and the formal parameter seq is the
rest.

which avoids the ambiguity, but this is long winded.

We need some structure, or at least conventions in Clojure
documentation. The lack of this is the technical problem. That we have
many potential technical solutions is social problem, not that we have
any.

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: find the last and the nth item without using last or nth

[James Reeves]

On 30 April 2014 11:41, Roelof Wobben  wrote:
>
>
> Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves:
>>
>>
>> Consider how you might add a counter to the loop. You'll want to
>> increment the counter, then stop when it reaches the desired number.
>>
>
>
> So without checking it so out of my head I would do this
>
>  (defn last* [coll, number]
>(loop [coll coll]
>  (if == counter number))
>(first coll)
>(recur (next coll) (+counter 1 ))
>

Essentially yes. You need to initiate the counter to zero, and you still
need a condition to make sure you don't go past the end of the seq (in case
n is more than the length of the list), but you've basically got it.

- James

-- 
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: find the last and the nth item without using last or nth

[Roelof Wobben]

Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves:
>
>
> On 30 April 2014 10:41, Roelof Wobben >wrote:
>
>>
>> Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves:
>>
>>>
>>> Unlike vectors, seqs are simple structures and don't know their own 
>>> length.
>>>
>>> You can count seqs, but this involves iterating through every element in 
>>> turn. If all you want to do is find out whether there is more than one 
>>> element, there's a much simpler and more efficient way.
>>>
>>>
>> Yep, if there is only 1 item is a list (rest coll) is nil.
>>
>
> Almost. Clojure distinguishes between nil and the empty list. The function 
> you want is "next":
>
>(rest [1]) => ()
>(next [1]) => nil
>
> Why the distinction between next and rest? It has to do with laziness, and 
> if you're interested I can go into more detail. Otherwise just remember 
> that rest returns an empty list, and next returns nil.
>
>  
>  (defn last* [coll]
>(loop [coll coll]
>  (if (nil? (next coll))
>(first coll)
>(recur (next coll
>
> Consider how you might add a counter to the loop. You'll want to increment 
> the counter, then stop when it reaches the desired number.
>


So without checking it so out of my head I would do this 

 (defn last* [coll, number]
   (loop [coll coll]
 (if == counter number))
   (first coll)
   (recur (next coll) (+counter 1 ))
 

-- 
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: Hosting Providers

[Adrian Mowat]

Hi Richard

Sorry for the delay.  We'll check that out!

Having said that, my inclination would be to avoid the compile step if we
can and just run on top of the leiningen project (e.e. analogous to ruby
apps).

Putting Engine Yard aside, it raises an interesting question so I am
wondering what other people on this list do.  Do you compile your code or
just run from the sources as you would in development?

Many Thanks

Adrian




On Thu, Apr 24, 2014 at 2:51 PM, Richard Watson wrote:

> Hi Adrian,
>
> You don't have far to look ... Engine Yard now supports Java, and by
> extension, Clojure.  If you can package up your Clojure app into a WAR file
> (using Leiningen's 'lein ring uberwar', for example) you can deploy it onto
> a Jetty or Tomcat server in an Engine Yard Java environment.
>
> This is a post I published recently on the Engine Yard blog describing the
> components of a basic Clojure Web app and how to deploy onto Engine Yard.
> https://blog.engineyard.com/2014/clojure-web-app-engine-yard
>
> I'm Richard, Product Manager for Java at Engine Yard. Please, drop me a
> line if you're interested in trying your Clojure code on Engine Yard, or
> just go ahead and try it out at http://ui.engineyard.com . We're offering
> a $100 credit to try out the Java platform and give us feedback.
>
> Richard.
>
>
> On Friday, April 18, 2014 11:36:05 AM UTC+1, Adrian Mowat wrote:
>>
>> Hi Everyone,
>>
>> I am currently looking at hosting providers for Clojure for my company.
>>  We are using Engine Yard for our Ruby applications and we looking for
>> something comparable in terms of providing an easy path to getting started
>> and easy ongoing maintenance (they allow you to apply OS patches with zero
>> downtime by simply clicking a button for example).  We also need 24/7
>> support for server issues.
>>
>> I was wondering if anyone here could share any experiences and/or
>> recommendations?
>>
>> Many Thanks
>>
>> Adrian
>>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/rdV-idmmGh0/unsubscribe.
> To unsubscribe from this group and all its topics, 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: find the last and the nth item without using last or nth

[James Reeves]

On 30 April 2014 10:41, Roelof Wobben  wrote:

>
> Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves:
>
>>
>> Unlike vectors, seqs are simple structures and don't know their own
>> length.
>>
>> You can count seqs, but this involves iterating through every element in
>> turn. If all you want to do is find out whether there is more than one
>> element, there's a much simpler and more efficient way.
>>
>>
> Yep, if there is only 1 item is a list (rest coll) is nil.
>

Almost. Clojure distinguishes between nil and the empty list. The function
you want is "next":

   (rest [1]) => ()
   (next [1]) => nil

Why the distinction between next and rest? It has to do with laziness, and
if you're interested I can go into more detail. Otherwise just remember
that rest returns an empty list, and next returns nil.



> Can you think of a way of making this function recursive to work with any
>> number of elements?
>>
>
> I think I can but I have to try some things but untested it looks
> like this
>
>  (defn last* [coll]
>   (if (nil? (rest coll)
>(first coll)))
>
>>   (last* (rest coll))
>>
>
That's pretty much right. You just need to use (nil? (next coll)) or
(empty? (rest coll))

 (defn last* [coll]
   (if (nil? (next coll))
 (first coll)
 (last* (next coll

You can also write it with loop/recur:

 (defn last* [coll]
   (loop [coll coll]
 (if (nil? (next coll))
   (first coll)
   (recur (next coll

See how the recursive step is replaced with "recur"? This is more efficient
because we're not filling the stack up as we would with recursion. You can
also write the above as:

 (defn last* [coll]
   (if (nil? (next coll))
 (first coll)
 (recur (next coll

If a recur is used without an outer loop, the whole function acts as an
implicit loop. There's one more optimisation you can perform, and that's to
take advantage of nil being a "falsey" value.

(defn last* [coll]
  (if (next coll)
(recur (next coll))
(first coll)))

If (next coll) isn't nil, it recurs. If it is, then the if statement fails
and the first item of the collection is returned. The above code is
actually how it's defined in clojure.core.


Now I wonder how I can make it work if I want to find lets say the 5th
> value of a array of any number of elements
> Then rest is never nil. So at first glance if I do not know the length it
> cannnot be done recursive.
> I have to do it in a for loop.
>

You need a counter. Take a look at the version of last* that has a
loop/recur:

 (defn last* [coll]
   (loop [coll coll]
 (if (nil? (next coll))
   (first coll)
   (recur (next coll

Consider how you might add a counter to the loop. You'll want to increment
the counter, then stop when it reaches the desired number.

- James

-- 
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: Kwargs vs explicit parameter map for APIs?

[Colin Fleming]

And thinking about it (after pressing "send", of course), you'd get the
same benefit from destructuring an explicit map in the function parameter
anyway, wouldn't you?


On 30 April 2014 22:11, Colin Fleming  wrote:

> But that's only true for the variables which are explicitly destructured
> in the function definition, which in my experience many are not - they're
> often later picked out of an ":as args" argument, perhaps dependent on a
> combination of the parameters which are explicitly destructured. Seesaw
> never does this, for example. I think it's dangerous to rely on this rather
> than the documentation since it's often an incomplete view of what the
> function requires.
>
> Cheers,
> Colin
>
>
> On 30 April 2014 21:03, Joachim De Beule wrote:
>
>> my two cents:
>>
>> The extra readability to users when using keyword args also comes from
>> the fact that a function's options are explicit in its signature. So during
>> development, instead of having to look them up in the docs or in the code,
>> my emacs mini-buffer simply shows them to me. Although I do agree with all
>> the good reasons against keywords arguments, to me this is still the
>> decisive reason to prefer them...
>>
>> Joachim
>>
>> Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:
>>
>>> On 30 April 2014 03:54, Sean Corfield  wrote:
>>>
 I still think the keyword argument approach is far more readable to
 _users_
>>>
>>>
>>>  --
>> 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: Kwargs vs explicit parameter map for APIs?

[Colin Fleming]

But that's only true for the variables which are explicitly destructured in
the function definition, which in my experience many are not - they're
often later picked out of an ":as args" argument, perhaps dependent on a
combination of the parameters which are explicitly destructured. Seesaw
never does this, for example. I think it's dangerous to rely on this rather
than the documentation since it's often an incomplete view of what the
function requires.

Cheers,
Colin


On 30 April 2014 21:03, Joachim De Beule  wrote:

> my two cents:
>
> The extra readability to users when using keyword args also comes from the
> fact that a function's options are explicit in its signature. So during
> development, instead of having to look them up in the docs or in the code,
> my emacs mini-buffer simply shows them to me. Although I do agree with all
> the good reasons against keywords arguments, to me this is still the
> decisive reason to prefer them...
>
> Joachim
>
> Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:
>
>> On 30 April 2014 03:54, Sean Corfield  wrote:
>>
>>> I still think the keyword argument approach is far more readable to
>>> _users_
>>
>>
>>  --
> 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: Clojure for web project? Talk me into it!

[Bernhard Mäder]

 

Hoplon looks really interesting. It’s just that I don’t want to build a 
single page application, so it’s kind of moot to consider it, I guess.

I was planning to have a lot of server rendered pages in the app, not least 
to make the content accessible for search engine bots. For the dynamic UI 
parts I will definitely use React.js or some of the clojure “bindings” for 
it (Om, Reagent?). We'll see.

Guys, thank you all for your comments! 

On Tuesday, April 29, 2014 6:40:41 PM UTC+2, Daniel Jomphe wrote:
>
> Not to make it more complicated for you, but have you looked at Hoplon too?
>
> http://hoplon.io/
>
> I was *very* impressed by the author's presentations, the later of which 
> is https://www.youtube.com/watch?v=wVXjExRiFy0
> And podcast about it: 
> http://thinkrelevance.com/blog/2014/03/18/alan-dipert-cognicast-episode-052
>
> It's optimized around single-page web apps.
>
> I'm not saying that's what I'd necessarily use for your product; you may 
> want to use all of it, or parts of it (it's modular) along something else.
>
> If this kind of approach isn't what you'd use on your front-end, make sure 
> you look at Om, Reagent and Quiescent for that.
>
> And obviously, I'm forgetting a few other batteries-included frameworks 
> I've seen (because there are a few, apart from Caribou).
>
> On Tuesday, April 29, 2014 4:22:58 AM UTC-4, Bernhard Mäder wrote:
>>
>> Hey guys,
>>
>> I need your help in choosing a web stack for a medium sized website 
>> project, which is going to take the better half of my time for the next 
>> year. I really want to use clojure, because of various reasons, but have 
>> never done web development with it before. Frankly, it’s quite hard to feel 
>> confident about such a decision, as there are so many libraries to choose 
>> from, many of which seem to be abandoned or with very little (public) 
>> momentum.
>>
>> These are the notable features I need on the server side:
>>
>>- Internationalization of content, with multilingual URLs
>>- Authentication through username / password and through xing (oauth) 
>>and linkedin (oath2).
>>- Image and PDF upload
>>- A small (and pretty basic) CMS
>>- Beautiful reports renderings
>>- A basic admin backend 
>>
>> First, I was thinking along the compojure/hiccup/friend stack. I like it 
>> for the simplicity, the flexibility and the abundance of documentation on 
>> the web. Unfortunately, I see myself reinventing the wheel a few times with 
>> this approach…
>>
>> Then there is caribou. I like that it’s very well documented and that 
>> it’s already being used in production. It appears to be the most feature 
>> complete solution for the time being. It handles images, has backend 
>> scaffolding and i18n. OTOH, authentication isn’t really built-in (other 
>> than basic auth, if I got that right) and, it’s very new, so adoption seems 
>> to be still low. Also, it is developed in-house, so there’s the risk of 
>> abandonment, too.
>>
>> Finally, I took a look at pedestal (services). I like its overall design 
>> and I especially welcome the URL generator, which is going to be a boon in 
>> larger projects. But all in all, it seems to be little more than a 
>> (powerful) routing engine (again, maybe I’m missing something) and lacks 
>> internationalization as well as authentication (although I read that the 
>> snapshot version of friend will work with it). Also, it is developed 
>> in-house and not declared production-ready yet. 
>>
>> I don’t feel very comfortable with either choice and would appreciate the 
>> thoughts of seasoned clojure web devs on that topic. Please talk me into 
>> it! I don’t want to end up with scala and play… :-)
>>
>> Thanks for your thought!
>> Bernhard
>>
>>

-- 
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 for web project? Talk me into it!

[Bernhard Mäder]

Yes, one would hope so. Then again, they've been using Pedestal-App for 
their projects as well... :-)

Anyway, pedestal seems the way to go. After all, I could also see myself 
replacing it with the latest and greatest routing library without much 
hassle, should it once be deprecated.

On Tuesday, April 29, 2014 5:35:25 PM UTC+2, Mike Haney wrote:
>
> Pedestal was developed by Cognitect and I would assume they use it on many 
> of their consulting projects.  Since future support appears be a major 
> concern for you (rightly so), Pedestal probably fulfills that requirement 
> better than anything else out there right now.  Even if you don't need all 
> the features it offers, it's worth considering building your server-side 
> stack around it for that reason alone.

-- 
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: find the last and the nth item without using last or nth

[Roelof Wobben]

Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves:
>
> On 30 April 2014 07:49, Roelof Wobben >wrote:
>>
>>
>> Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves:
>>
>>>
>>> 1. How do you find the last element of a seq with exactly one element?
>>>
>>
>>the last and the first element are the same
>>
>
>  Right. So to formalise it:
>
> (defn last* [coll]
>   (first coll))
>  
> I'm using "last*" as the name so that it doesn't conflict with the 
> function "last" in clojure.core.
>
>
> 2. How do you find out whether a seq has one element, or more than one 
>>> element?
>>>
>>
>> Look at the length of the seq
>>
>
> Unlike vectors, seqs are simple structures and don't know their own length.
>
> You can count seqs, but this involves iterating through every element in 
> turn. If all you want to do is find out whether there is more than one 
> element, there's a much simpler and more efficient way
>

Yes , with only 1 item (res col) is nill.  

>  
>

-- 
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: find the last and the nth item without using last or nth

[Roelof Wobben]

Op woensdag 30 april 2014 09:58:26 UTC+2 schreef James Reeves:
>
> On 30 April 2014 07:49, Roelof Wobben >wrote:
>>
>>
>> Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves:
>>
>>>
>>> 1. How do you find the last element of a seq with exactly one element?
>>>
>>
>>the last and the first element are the same
>>
>
>  Right. So to formalise it:
>
> (defn last* [coll]
>   (first coll))
>  
> I'm using "last*" as the name so that it doesn't conflict with the 
> function "last" in clojure.core.
>
>
> 2. How do you find out whether a seq has one element, or more than one 
>>> element?
>>>
>>
>> Look at the length of the seq
>>
>
> Unlike vectors, seqs are simple structures and don't know their own length.
>
> You can count seqs, but this involves iterating through every element in 
> turn. If all you want to do is find out whether there is more than one 
> element, there's a much simpler and more efficient way.
>
>
>
Yep, if there is only 1 item is a list (rest coll) is nil.
 

 

> In code, this would be:
>
>  (defn last* [coll]
>   (if (more-than-one-element? coll)
> (first (rest coll))
> (first coll)))
>
> The "more-than-one-element?" to be replaced with the answer to question 2, 
> of course.
>
> Can you think of a way of making this function recursive to work with any 
> number of elements?
>


I think I can but I have to try some things but untested it looks like this 

 (defn last* [coll]
  (if (nil? (rest coll)
   (first coll)))

>(last* (rest coll))
>

Now I wonder how I can make it work if I want to find lets say the 5th 
value of a array of any number of elements
Then rest is never nil. So at first glance if I do not know the length it 
cannnot be done recursive. 
I have to do it in a for loop.



> - James
>

-- 
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: Kwargs vs explicit parameter map for APIs?

[Joachim De Beule]

my two cents:

The extra readability to users when using keyword args also comes from the 
fact that a function's options are explicit in its signature. So during 
development, instead of having to look them up in the docs or in the code, 
my emacs mini-buffer simply shows them to me. Although I do agree with all 
the good reasons against keywords arguments, to me this is still the 
decisive reason to prefer them...

Joachim

Op woensdag 30 april 2014 05:41:29 UTC+2 schreef James Reeves:
>
> On 30 April 2014 03:54, Sean Corfield >wrote:
>
>> I still think the keyword argument approach is far more readable to 
>> _users_
>
>
>

-- 
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: find the last and the nth item without using last or nth

[Tassilo Horn]

Roelof Wobben  writes:

>>> For nth, you need a counter that you can increment in each recursion
>>> step.  For last, you return the first element of the list whose rest
>>> is the empty list.
>>
>> Thanks, and if I use cons (item, list) then item is the value I
>> want. I only have to print it.

I think you should return it, not just print it.

> If I look at the documentations I think I have to use doseq for
> running and cons for finding and a if then to stop at the right place.

No.  doseq doesn't allow you to stop after you've found the right item,
and cons constructs a new list given an item and another list.

You want either an explicit recursion or `loop`/`recur` for running
through the list, and in each step you want to use `first` and `rest` to
split the list into its head item and its tail.

Bye,
Tassilo

-- 
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: Observing the same non-dynamic var in two different states

[James Reeves]

When a namespace is reloaded any vars defined in it are re-evaluated. In
your case it would seem that some quirk of the Leiningen test architecture
is leading to vartest.test-data being loaded twice.

In general namespaces should be robust when it comes to being reloaded.
Clojure provides a macro, defonce, for variables you only want defined once
across reloads. Using defonce in your test-data namespace should solve your
problem.

- James


On 30 April 2014 07:29, Antti Karanta  wrote:

>
>
> I thought that once defined clojure vars are immutable and retain their
> values. However, I
> accidentally bumped into a situation where I observe the same var in two
> different states.
> Here's how to reproduce:
>
> lein new app vartest
>
> Add the following files to the test folder:
>
> -
>
> (ns vartest.test-data)
>
> (def uuid (java.util.UUID/randomUUID))
>
> -
>
> (ns vartest.core-test
>   (:require [clojure.test :refer :all]
> [vartest.test-data :as td]))
>
> (def my-uuid td/uuid)
>
> (deftest a-test
>   (testing "accessing same var twice"
> (is (= my-uuid td/uuid
>
> 
>
> Now run the tests:
>
> C:\temp\vartest>lein test :all
>
> lein test vartest.core-test
>
> lein test :only vartest.core-test/a-test
>
> FAIL in (a-test) (core_test.clj:9)
> accessing same var twice
> expected: (= my-uuid td/uuid)
>   actual: (not (= #uuid "030d2fe8-407b-4d67-a505-261bc3650729" #uuid
> "f8405611-e2da-4dd2-973b-508831
> 27ef6a"))
>
> lein test vartest.test-data
>
> Ran 1 tests containing 1 assertions.
> 1 failures, 0 errors.
> Tests failed.
>
> However, if I run
>
> lein test :only vartest.core-test/a-test
>
> then the very same test passes.
>
> What's going on here?
>
> Environment: Clojure 1.5.1 and 1.6.0, Leiningen 2.3.4, Java 1.7.0_51
> 64-Bit, Windows 7 64-bit
>
>
>   ::Antti::
>
>
> --
> 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.

Observing the same non-dynamic var in two different states

[Antti Karanta]

I thought that once defined clojure vars are immutable and retain their 
values. However, I
accidentally bumped into a situation where I observe the same var in two 
different states. 
Here's how to reproduce:

lein new app vartest

Add the following files to the test folder:

-

(ns vartest.test-data)

(def uuid (java.util.UUID/randomUUID))

-

(ns vartest.core-test
  (:require [clojure.test :refer :all]
[vartest.test-data :as td]))

(def my-uuid td/uuid)

(deftest a-test
  (testing "accessing same var twice"
(is (= my-uuid td/uuid



Now run the tests:

C:\temp\vartest>lein test :all

lein test vartest.core-test

lein test :only vartest.core-test/a-test

FAIL in (a-test) (core_test.clj:9)
accessing same var twice
expected: (= my-uuid td/uuid)
  actual: (not (= #uuid "030d2fe8-407b-4d67-a505-261bc3650729" #uuid 
"f8405611-e2da-4dd2-973b-508831
27ef6a"))

lein test vartest.test-data

Ran 1 tests containing 1 assertions.
1 failures, 0 errors.
Tests failed.

However, if I run

lein test :only vartest.core-test/a-test

then the very same test passes.

What's going on here?

Environment: Clojure 1.5.1 and 1.6.0, Leiningen 2.3.4, Java 1.7.0_51 
64-Bit, Windows 7 64-bit


  ::Antti::
   

-- 
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: Kwargs vs explicit parameter map for APIs?

[Alex Baranosky]

Thanks James, that's a useful version to experiment with :)


On Wed, Apr 30, 2014 at 12:04 AM, Colin Fleming  wrote:

> After posting this last week I decided to go down the explicit map route,
> and I'm already really glad I did. Amongst other things, it has allowed me
> to have two similar calls easily share their common options and merge in
> the differences. I'm generally a fan of maintaining fairly minimal APIs, I
> don't think I'll be duplicating functions, I don't really see a need - two
> extra braces are just not that much noise for me. I'd rather use Alex's
> last example with the optional map arg than have my-function and
> my-function-from-map everywhere.
>
>
> On 30 April 2014 17:55, James Reeves  wrote:
>
>>
>> On 30 April 2014 06:07, Alex Baranosky wrote:
>>
>>> I especially dislike that my non-kwarg fns no-longer can elegantly
>>> accept no options.  Let me illustrate:
>>>
>>> (defn foo [& {:keys [a b]}]
>>>   [a b])
>>>
>>> (foo :a 1 :b 2)
>>> (foo)
>>>
>>
>> You could write:
>>
>> (defn foo [& [{:keys [a b]}]]
>>   [a b])
>>
>> (foo {:a 1 :b 2})
>> (foo)
>>
>> - James
>>
>> --
>> 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.
>

-- 
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: find the last and the nth item without using last or nth

[James Reeves]

On 30 April 2014 07:49, Roelof Wobben  wrote:
>
>
> Op woensdag 30 april 2014 08:21:40 UTC+2 schreef James Reeves:
>
>>
>> 1. How do you find the last element of a seq with exactly one element?
>>
>
>the last and the first element are the same
>

Right. So to formalise it:

(defn last* [coll]
  (first coll))

I'm using "last*" as the name so that it doesn't conflict with the function
"last" in clojure.core.


2. How do you find out whether a seq has one element, or more than one
>> element?
>>
>
> Look at the length of the seq
>

Unlike vectors, seqs are simple structures and don't know their own length.

You can count seqs, but this involves iterating through every element in
turn. If all you want to do is find out whether there is more than one
element, there's a much simpler and more efficient way.


 3. How do you find out the last element if a seq with exactly two elements?
>>
>
> take the first element away and you have a seq of one element .
>

So in other words:

(defn last* [coll]
  (first (rest coll)))


4. How do you find out the last element of a seq that may have one *or* two
>> elements?
>>
>
> Look at the length. If it has one element , see question 1
> if it has 2 elements, see question 3.
>

In code, this would be:

(defn last* [coll]
  (if (more-than-one-element? coll)
(first (rest coll))
(first coll)))

The "more-than-one-element?" to be replaced with the answer to question 2,
of course.

Can you think of a way of making this function recursive to work with any
number of elements?

- James

-- 
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: Kwargs vs explicit parameter map for APIs?

[Colin Fleming]

After posting this last week I decided to go down the explicit map route,
and I'm already really glad I did. Amongst other things, it has allowed me
to have two similar calls easily share their common options and merge in
the differences. I'm generally a fan of maintaining fairly minimal APIs, I
don't think I'll be duplicating functions, I don't really see a need - two
extra braces are just not that much noise for me. I'd rather use Alex's
last example with the optional map arg than have my-function and
my-function-from-map everywhere.


On 30 April 2014 17:55, James Reeves  wrote:

>
> On 30 April 2014 06:07, Alex Baranosky wrote:
>
>> I especially dislike that my non-kwarg fns no-longer can elegantly accept
>> no options.  Let me illustrate:
>>
>> (defn foo [& {:keys [a b]}]
>>   [a b])
>>
>> (foo :a 1 :b 2)
>> (foo)
>>
>
> You could write:
>
> (defn foo [& [{:keys [a b]}]]
>   [a b])
>
> (foo {:a 1 :b 2})
> (foo)
>
> - James
>
> --
> 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: find the last and the nth item without using last or nth

[Roelof Wobben]

Op woensdag 30 april 2014 08:50:22 UTC+2 schreef Roelof Wobben:
>
>
>
> Op woensdag 30 april 2014 08:22:07 UTC+2 schreef Tassilo Horn:
>>
>> Roelof Wobben  writes: 
>>
>> > Could a recurvice way or a loop do the trick. 
>>
>> Yes. 
>>
>> > And how do I then take the right value. 
>>
>> For nth, you need a counter that you can increment in each recursion 
>> step.  For last, you return the first element of the list whose rest is 
>> the empty list. 
>>
>> Bye, 
>> Tassilo 
>>
>
> Thanks, and if I use cons (item, list) then item is the value I want. I 
> only have to print it. 
>
> Roelof
>


If I look at the documentations I think I have to use doseq for running and 
cons for finding and a if then to stop at the right place. 

Am I at the right track.  

>  
>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Tim Daly]

> Imagine you're reading through some documentation and you notice a
> problem. Maybe a typo, or something out of date, or something that's
> confusing that you could explain better. In one scenario there's a "git
> clone" link in the sidebar to a repository that contains a bunch of
> markdown files. In another scenario there's an HTML rendering generated
> from a literate programming project where the prose is intermixed with the
> code and requires a specific version of org-mode and the knowledge of how
> to "untangle" something in order to render it.

This is a focus on the technology which I'm reluctant to do, mostly
because I have strong opinions about it. I will say from experience that
any technology that separates code from explanation will fail. If we
focus on what information we require and what structure has to be placed
on that information so it can be understood THEN we can ask about the
technologies and what they support.

> Can I ask, quite seriously and not intending any sarcasm, what you mean 
> by "detracts from what's important"? 
>
> For me, "what's important" is to communicate ideas, designs, and details 
> from one developer to another so that others can maintain, modify, and 
> extend what exists. I've already held forth on what I think that implies 
> so I won't bore you with it. 


Consider Clojure's primary data structure implementation. It is
basically an immutable, log32, red-black tree. For some people that is
more than sufficient, especially if they have been working in the code
base for years.

For others, especially as a developer new to the project, there is a lot
to know. Without this information it is very difficult to contribute.

A new developer needs an introduction to the IDEA of immutable data
structures with a reference to Okasaki's thesis which is online at
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf (a bibliography).

A new developer needs to know that the DESIGN of Clojure relies on these
immutable data structures so they don't introduce any "quick and
efficient" hacks that violate the design. (a Clojure overview)

A new developer needs to know WHAT a red-black tree is, WHY it was
chosen, and HOW Clojure maps user-visible data structures to them.  
(the chapter on this particular data structure)

A new developer needs to know the IMPLICATIONS of the choice of log32
since it defines the efficiency. (the design constraints section and
the algorithmic analysis section)

A new developer needs to know HOW to update a log32 immutable red-black
tree.  (a pseudocode explanation with pictures)

A new developer needs to know HOW the log32 red-black tree is
implemented.  It is not immediately obvious how the 5-bit chunks are
mapped into a 32 bit word. If the task was to re-implement it on a 64
bit word they'd have to know the details to understand the code.  (the
actual code with explanations of the variables)

If the new developer's task is to modify the code for a 64 bit
architecture they would need a way to find the code (the table of
contents) and places where this information is mentioned (an index). 
All of the places where it is written need to be properly updated.

Even if we focus strictly on what a new developer needs to know
we end up with something that smells a lot like a book. From the
above we see the need for 

  1) a bibliography
  2) a Clojure overview
  3) a chapter focus on this data structure
  4) sections on design constraints and algorithmic analysis
  5) a section of pseudocode with pictures
  6) a section with code and details of the actual implementation
  7) a table of contents
  8) an index

And that's only a few dozen lines of the Clojure source code.

Now we know what information we require and what structure has to be
placed on that information so it can be understood, managed, and kept up
to date with the code. NOW let's talk about technologies that support
these requirements.

We can examine the ideas for possible technologies to properly organize
the above information. Do inline comments in source code files work?
Does a Javadoc kind of technology work? Does a wiki on an external
website work? Do separate markdown files in the directory tree work? Do
we create videos to explain code?  Do any of these technologies
integrate with the normal edit-compile-test code developement cycle?
Does changing the code generate an immediate expectation to update
the associated words?

I would claim that only a technology that is fully integrated into the
developer's main line, day-to-day work cycle will ensure that the
associated information up to date.

Checking in code ought to require a review of the associated 
information to ensure that it is up to date; essentially the role
of an "editor-in-chief" whose job it is to maintain high quality,
READABLE, natural language.

Our standard needs to be that anyone can read the words and KNOW
that the code is correct, complete, efficent, and well integrated
with the rest of the design.

This isn't really a tec