Re: [ANN] Ring Jetty servlet adapter

[Michael Blume]

I was just about to start figuring out how to do this, for pretty much
exactly the same reason (the Hystrix metrics stream). Thanks for this, I'm
looking forward to trying it out.

On Thu, Nov 16, 2017 at 5:23 AM Jiacai Liu  wrote:

> Fork of official jetty adapter
>  enhanced
> with servlet-mapping support.
>
>
> Why
> another adapter
>
> Some Java libraries, such as hystrix-metrics-event-stream
> ,
> come with util servlets for exposing statistic infomation. But in a purely
> Ring-based app we can't use those directly, you must convert the servlet
> into a Ring handler function for use. This is cumbersome, and servlet
> support should be supported out of box.
>
>
> The codebase stays in step with the official, with version number
> unchanged. So you can replace the official adapter with this in the least
> amount of effort.
>
>
>
> https://github.com/jiacai2050/ring-jetty-servlet-adapter
>
>
>
> Let me know if you have any suggestions :-)
>
> --
> 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.

[ANN] Honeysql mailing list and slack channel

[Michael Blume]

I'm opening a Google group and Slack channel for discussion of Honeysql, 
the Clojure DSL for generating SQL. We have some issues that are likely to 
result in breaking changes, and I'd like to get more input on that than I'd 
be likely to get in a PR/Issue discussion.

Maling list: https://groups.google.com/forum/#!forum/honeysql
Slack channel: #honeysql

-- 
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 android activity?

[Michael Blume]

My impression is that if you want to write Clojure on Android in 2017 you
use React Native and write ClojureScript. Re-natal is a good starting point

On Fri, Jun 23, 2017, 3:57 PM Mike Meyer  wrote:

> Is there still any activity in the clojure-android space? The
> clojure-android mail list is largely inactive, seems like the developers of
> lein-droid haven't done anything in months (1.7.0-r4 is still used in the
> templates), and the numerous references If ind for an android-clojure web
> site are all dead.
>
> That said, things do seem to mostly work for stock android. But accessing
> API's for android wear seems problematical (see
> https://github.com/clojure-android/lein-droid/issues/162 for my bug
> report).
>
> --
> 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: Order preservation and duplicate removal policy in `distinct`

[Michael Blume]

Also, I'm assuming distinct uses .equals semantics which might be worth
calling out in the doc

On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez  wrote:

> The doc for `distinct` is:
> "Returns a lazy sequence of the elements of coll with duplicates removed.
>   Returns a stateful transducer when no collection is provided."
>
> (1) In the lazy sequence case, I've thought that maybe it is assuemd there
> is a guarantee that the order of the input seq is preserved.  However, this
> isn't stated.  Is this an assumption to rely on for `distinct` and, more
> generally, the Clojure seq-based API functions?
>
> (2) In either case, when there are duplicates, there do not seem to be any
> guarantees on which one of the duplicates will be preserved.  Should this
> be stated?  I'm thinking that maybe this is about Clojure's design
> philosophy being that equal values to not ever need to be distinguished
> between, so the API doesn't explicitly support this concern.  However,
> there are times when identity relationships can matter - performance would
> be one that comes to mind.
> - This has some relationship to the Scala question @
> http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order
>
> There have been a few occasions where I relied on (or wanted to rely on)
> (1).  I haven't had many cases where (2) matters, but I could see it coming
> up on perhaps rare occasions.
>
> --
> 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: Changing value of atom vector using swap

[Michael Blume]

It doesn't look like data is actually an atom? Maybe that's just an error
in your e-mail...

On Tue, Dec 20, 2016 at 8:24 AM Ghadi Shayban  wrote:

> swap! takes as its arguments the atom and the function to transition the
> state inside the atom.  It implicitly calls the function on the state:
> (swap! data replace-value)
>
> It also can accept trailing arguments too...
>
>
> https://www.conj.io/store/v1/org.clojure/clojure/1.8.0/clj/clojure.core/swap%21
>
> On Tuesday, December 20, 2016 at 11:04:11 AM UTC-5, Rickesh Bedia wrote:
>
> I have
> (def data {:headers ["A" "B" "C" "D"]
>  :rows [["1" "2" "3" "4"] ["5" "6" "7" "8"] ["9" "10" "11"
> "12"]]})
>
> And I have a function
> (defn replace-value [struct]
> (clojure.walk/prewalk-replace {"3" "hello"} (struct :rows)))
>
> When I do
> (replace-value @data) > [["1" "2" "hello" "4"] ["5" "6" "7" "8"] ["9" "10"
> "11" "12"]]
>
> which is what I am expecting.
>
> However I want to achieve this same result using swap! So I tried
> #(swap! data (replace-value %))
>
> but I get the error #object[user$eval1308$fn__1309 0x6caeefd7
> "user$eval1308$fn__1309@6caeefd7"]
>
> I don't know what this error means nor how to resolve 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.
>

-- 
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: Lym - written by clojurescript and react native is on apple store

[Michael Blume]

Cool, thanks =)

On Wed, Sep 14, 2016 at 12:32 AM Tienson Qin <tienson...@gmail.com> wrote:

> Hi Michael,
> There are still some minor works to release the android, have to port
> actionsheet from Ios to Android.
> They are using the same cljs codebase.
> Not too much challenges to get both platforms work.
>
> On Wed, Sep 14, 2016 at 3:02 PM Michael Blume <blume.m...@gmail.com>
> wrote:
>
>> I see an Android app in the tree, is it working too? is it using the same
>> cljs codebase were there any challenges getting both platforms to work?
>>
>> On Tue, Sep 13, 2016 at 10:24 PM Tienson Qin <tienson...@gmail.com>
>> wrote:
>>
>>> Just release that,
>>> https://github.com/tiensonqin/lymchat
>>>
>>>
>>> On Monday, August 29, 2016 at 6:28:56 AM UTC+8, Gary Schiltz wrote:
>>>>
>>>> Thanks for making this free! Any chance you are going to release the
>>>> source?
>>>>
>>>> On Sunday, August 28, 2016 at 3:28:57 AM UTC-5, Tienson Qin wrote:
>>>>>
>>>>> Hi everyone, happy to announce Lym <http://lymchat.com> is on apple
>>>>> store now!
>>>>> It's group chat app for learning different cultures, languages, also
>>>>> support 1-on-1 video chat.
>>>>>
>>>>> Libraries used:
>>>>> [[org.clojure/clojure "1.8.0"]
>>>>>  [org.clojure/clojurescript "1.9.36"]
>>>>>  [org.clojure/core.async "0.2.385"]
>>>>>  [com.taoensso/sente "1.10.0-SNAPSHOT"]
>>>>>  [com.taoensso/encore  "2.64.1"]
>>>>>  [org.clojure/tools.reader "0.10.0"]
>>>>>  [com.taoensso/timbre  "4.6.0"]
>>>>>  [reagent "0.6.0-SNAPSHOT" :exclusions [cljsjs/react
>>>>> cljsjs/react-dom cljsjs/react-dom-server]]
>>>>>  [re-frame "0.7.0"]
>>>>>  [prismatic/schema "1.0.4"]
>>>>>  [com.andrewmcveigh/cljs-time "0.4.0"]]
>>>>>
>>>>> Thanks for the community, especially David Nolen, Mike Fikes, and
>>>>> decker405.
>>>>>
>>>> --
>>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/UIxmTkhWyp8/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.
>

-- 
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: Lym - written by clojurescript and react native is on apple store

[Michael Blume]

I see an Android app in the tree, is it working too? is it using the same
cljs codebase were there any challenges getting both platforms to work?

On Tue, Sep 13, 2016 at 10:24 PM Tienson Qin  wrote:

> Just release that,
> https://github.com/tiensonqin/lymchat
>
>
> On Monday, August 29, 2016 at 6:28:56 AM UTC+8, Gary Schiltz wrote:
>>
>> Thanks for making this free! Any chance you are going to release the
>> source?
>>
>> On Sunday, August 28, 2016 at 3:28:57 AM UTC-5, Tienson Qin wrote:
>>>
>>> Hi everyone, happy to announce Lym  is on apple
>>> store now!
>>> It's group chat app for learning different cultures, languages, also
>>> support 1-on-1 video chat.
>>>
>>> Libraries used:
>>> [[org.clojure/clojure "1.8.0"]
>>>  [org.clojure/clojurescript "1.9.36"]
>>>  [org.clojure/core.async "0.2.385"]
>>>  [com.taoensso/sente "1.10.0-SNAPSHOT"]
>>>  [com.taoensso/encore  "2.64.1"]
>>>  [org.clojure/tools.reader "0.10.0"]
>>>  [com.taoensso/timbre  "4.6.0"]
>>>  [reagent "0.6.0-SNAPSHOT" :exclusions [cljsjs/react
>>> cljsjs/react-dom cljsjs/react-dom-server]]
>>>  [re-frame "0.7.0"]
>>>  [prismatic/schema "1.0.4"]
>>>  [com.andrewmcveigh/cljs-time "0.4.0"]]
>>>
>>> Thanks for the community, especially David Nolen, Mike Fikes, and
>>> decker405.
>>>
>> --
> 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: Cross platform date/time libarary

[Michael Blume]

Within your library you could probably use cljc to import one or the other,
though.

On Mon, Apr 4, 2016 at 9:04 AM Sean Corfield  wrote:

> On 4/3/16, 11:41 PM, "JvJ"  kfjwhee...@gmail.com> wrote:
> > OK.  As long as a single import in a cljc will suffice.
>
> Nope. The Clojure time libraries all lean very heavily on Java interop so
> a single source solution really is not feasible.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
>
>
>
> --
> 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: [ANN] Clojure 1.8.0-RC3

[Michael Blume]

No issues here.

On Tue, Dec 8, 2015 at 5:39 PM James Elliott  wrote:

> I’ve been working with it for a few days and have seen no issues yet.
>
>
> On Wednesday, December 2, 2015 at 10:03:31 AM UTC-6, Alex Miller wrote:
>
>> Clojure 1.8.0-RC3 is now available. *This build is a "release
>> candidate"!* We would appreciate any and all testing you can do on your
>> own libraries or internal projects to find problems.
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3
>>- Leiningen: [org.clojure/clojure "1.8.0-RC3"]
>>
>> Below are the changes since 1.8.0-RC2. See the full 1.8 change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>- CLJ-1845  / CLJ-1851
>> New ^:redef to mark
>>vars that should not be direct linked
>>   - The metadata ^:redef can be used to mark function vars that
>>   should not be direct linked
>>   - clojure.core/load was previously marked with ^:dynamic for this
>>   purpose, but is now marked ^:redef
>>- CLJ-1856  Direct
>>linking breaks clojure.test location reporting for failures
>>- CLJ-1854  Set line
>>number in bytecode prior to invokeStatic call
>>- CLJ-1853  In socket
>>server, require the ns of the accept-fn before resolving 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.
>

-- 
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: best practice with forked libraries

[Michael Blume]

If you have an internal maven repo, you can publish artifacts to it with
updated version string and with group/artifact unchanged.

On Wed, Nov 18, 2015 at 7:19 AM Herwig Hochleitner 
wrote:

> 2015-11-18 15:48 GMT+01:00 Max Gonzih :
>
>> I think lein deps :tree should be enough to spot issues like that.
>>
>
> If you're into skimming pages of transitive dependencies (or know how to
> use grep ;), sure. But lein-collisions also helps you find unexpected
> collisions (i.e. not related to renamed packages).
> Speaking of that, has `lein deps :tree` been broken for anybody else
> lately?
>
>
>> Also :exclusions should be used to remove original library from other
>> dependencies.
>>
>
> Sure, but that's no fun at all. Overall seems pretty awkward to me, still.
>
> --
> 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: Locking non-local variable inside macro

[Michael Blume]

The problem here is that you are splicing in obj when there is no need to.
You actually want your generated code to refer to obj. So just

(defmacro mac1 [& body] `(locking obj ~@body))

is fine.

dennis' solution will work too, but it will work almost accidentally? All
blank maps evaluate to the same object, so if you do (locking {}
(whatever)) it will lock on the same map every time, but if for some reason
someone else does the same trick, you'll be competing for the same lock.
Better to do what you're doing, but without the unnecessary splice.

On Sun, Nov 15, 2015 at 11:17 PM dennis zhuang  wrote:

> I think the reason is in macroexpand-1 result:
>
> user=> (macroexpand-1 '(mac1 1))
> (clojure.core/locking # 1)
>
> It's not a valid form to be read and eval by clojure reader,the object
> form can't be parsed.
>
> If define obj to be a map {}, it works fine:
>
> user=> (def obj {})
> #'user/obj
> user=> (mac1 1)
> 1
> user=> (macroexpand-1 '(mac1 1))
> (clojure.core/locking {} 1)
>
>
> 2015-11-16 13:55 GMT+08:00 Alice :
>
>> user=> (def obj (Object.))
>> #'user/obj
>> user=> (defmacro mac1 [& body] `(locking ~obj ~@body))
>> #'user/mac1
>> user=> (mac1 nil)
>> CompilerException java.lang.RuntimeException: Can't embed object in code,
>> maybe print-dup not defined: java.lang.Object@2a747a37,
>> compiling:(NO_SOURCE_PATH:1:1)
>>
>>
>> Why am I getting the error?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> 庄晓丹
> Email:killme2...@gmail.com xzhu...@avos.com
> Site:   http://fnil.net
> Twitter:  @killme2008
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Clojure 1.8.0-RC1 is now available

[Michael Blume]

Sorry, I'm confused now -- is the appropriate place to give a return type
hint for a function the arg list and not the function name? I've always
seen the function name hinted.

On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  wrote:

> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>
> On 12 Nov 2015, at 19:14, Nicola Mometto  wrote:
>
>
> Depends on how you look at it.
> From my point of view, both examples are using an otherwise valid type
> hint, at an invalid location, and in both cases the emitted code is
> nonsensical.
> So I'd say that if the decision for the CLJ-1846 issue was to handle that
> with a compile time error, this one should too.
>
>
> On 12 Nov 2015, at 16:47, Alex Miller  wrote:
>
> Neither is acceptable, so I either misunderstand or disagree with your
> question. :)
>
> The code below is an invalid type hint at that location. Are you maybe
> saying this should throw an error on definition?
>
> CLJ-1846 is instead a valid type hint that is in conflict with the call.
> Which now throws an error.
>
>
> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>
>> This is :rettag in action.
>> Any reason why this error should be acceptable while the CLJ-1846 one
>> isn't?
>>
>> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
>>
>> That's not a valid type hint. Var meta is evaluated, in this case to the
>> double function object. You really want:
>>
>> (defn timespi ^double [^double x] (* x 3.14))
>>
>>
>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com
>> wrote:
>>>
>>> Hello,
>>>
>>> the following stops executing on 1.8.0-rc1 or current master-head
>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix
>>> for CLJ-1846):
>>>
>>> [/Users/reborg]$ repl
>>> Clojure 1.8.0-master-SNAPSHOT
>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>> #'user/timespi
>>> user=> (timespi 2)
>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object;
>>> is abstract  user/timespi (NO_SOURCE_FILE:-1)
>>>
>>> It works if you enable direct linking (or if you use 1.7.0).
>>>
>>> Renzo
>>>
>>
> --
> 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: how to speedup lein uberjar?

[Michael Blume]

I think Matching Socks has definitely got the right answer -- anything that
prevents your code from being AOT-compiled is going to give you a huge
speedup.

On Sun, Nov 1, 2015 at 10:11 PM Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hi Asim,
>  I needed to run lein uberjar to submit the jar to run a distributed job
> on a apache-spark cluster.  and my uberjar is currently taking anywhere
> from 2 to 4 minutes to finish. I have have had to run uberjar fairly
> frequently during my iterations ( 4 to 5 times in an hour) . I am new to
> spark. So I need to quickly iterate with changes in the code.
>
> Thanks for asking.
> Regards,
> Sunil.
>
> On Mon, Nov 2, 2015 at 6:09 AM, Asim Jalis  wrote:
>
>> Hi Sunil,
>>
>> I am wondering why you want to speed up lein uberjar.
>>
>> How frequently do you need to run this?
>>
>> What is your use case and workflow around this?
>>
>> Thanks.
>>
>> Asim
>>
>> On Mon, Oct 26, 2015 at 2:04 AM, Sunil S Nandihalli <
>> sunil.nandiha...@gmail.com> wrote:
>>
>>> Hi Everybody,
>>>   My lein uberjar takes about 2 minutes to run. It also recompiles all
>>> the clj files everytime.  Is there a way to speedup lein-uberjar .. Or may
>>> be make it incremental?
>>> Thanks,
>>> Sunil.
>>>
>>> --
>>> 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 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: Calling object members with symbols

[Michael Blume]

Nope, still won't work.

(let [s 'toString] (invoke 1 s))

java.lang.IllegalArgumentException: No matching field found: s for class
java.lang.Long



On Sun, Oct 18, 2015 at 5:51 PM dennis zhuang  wrote:

> You may have to use macro:
>
> user=> (defmacro invoke [obj sym] `(. ~obj ~sym))
> #'user/invoke
> user=> (invoke 1 toString)
> "1"
>
> 2015-10-19 6:54 GMT+08:00 Timur :
>
>> Hi all,
>>
>> Is there anyway to call an object member using its symbol?
>>
>> For instance we have an object o, we get the symbol of a method, e.g.,
>> toString, of our object o using clojure.reflect/reflect and and I want to
>> execute this method on this object through the symbol.
>>
>> For instance *(. obj sym)* throws an exception. Here symbol for instance
>> contains toString
>>
>> Any ideas about how I can do this?
>>
>> Regards,
>>
>> Timur
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> 庄晓丹
> Email:killme2...@gmail.com xzhu...@avos.com
> Site:   http://fnil.net
> Twitter:  @killme2008
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Yesql 0.5.1 Released.

[Michael Blume]

The simple answer is
https://clojure.github.io/clojure/javadoc/clojure/java/api/package-summary.html

But since Yesql works by producing Clojure vars in a namespace, doing
*everything* from Java sounds painful -- you'd probably want to sneak in
like one Clojure file with a bunch of defquery statements and then call
into the resulting functions from Java

On Fri, Oct 9, 2015 at 10:12 AM Charles Harvey III 
wrote:

> Here's another crazy question...
>
> How would I use this from Java? Seriously though. I might be forced to use
> Java on my next project but I really like Yesql over MyBatis (the closest
> thing in Java Land). Has anyone done it before and can show a small
> example? I don't want to give up my .sql files for xml!!
>
>
> Thanks.
>
>
> Charlie
>
>
>
> On Wednesday, October 7, 2015 at 5:55:11 PM UTC-4, Kris Jenkins wrote:
>
>> Yesql - the Clojure library for using SQL - has just released v0.5.1.
>>
>> The API is much improved - especially if you're using queries with many
>> arguments - so see the migration guide if you're upgrading:
>>
>> My thanks to everyone who has contributed to this release, and for all
>> the users who've been patiently waiting for v0.5 to go official. :-)
>>
>> Kris
>>
> --
> 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: 4clojure count problem

[Michael Blume]

Reduce can take either two or three arguments; when it takes two arguments,
it makes some assumptions about the argument that was left out. You're
using reduce with two arguments, so you might want to rethink those
assumptions.

On Sat, Oct 3, 2015 at 2:19 PM Roelof Wobben  wrote:

> Hello,
>
> I have to make a function which counts a collection without using count.
>
> So I came up with this :
>
> (fn [coll]  (reduce (fn [counter _ ] (inc counter)) coll)))
>
> it works well with coll is [ 1 2 3]
>
> but it fails with "Hello World"
>
> How can I improve my code to work in both cases.
>
> Please , do not only give the answer but rather explain how I can make
> this work.
> So I learn a lot and not do only a copy/paste.
>
> 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: macro help

[Michael Blume]

 #foo gensyms don't survive across a 'break' in quoting

you can do

`(let [foo# bar]
  (other stuff
(foo# ...)))

but you can not do

`(let [foo# bar]
   ~(for [i s]
   `(foo# ...)))

or anything like that. The workaround is to create a gensym explicitly
using (gensym), let that, and splice it in wherever you need the gensym.

On Wed, Sep 30, 2015 at 1:29 PM Colin Yates  wrote:

> Hi all,
>
> I am banging my head against the wall - I think it is obvious but I have
> started too long:
>
> The use-case is that I want a form which takes a set of children. The form
> also takes in some form-wide state, like the form-wide validation, the
> values for each item etc. I want the macro, for each child, to decorate
> that child by extracting the validation errors and value from the form-wide
> state.
>
> So, assuming:
>  - validation looks like {:name "Duplicate name" :age "You must be at
> least 0"}
>  - form-values looks like {:name "a-duplicate-user" :age -1}
>
> then my form might look like:
>
> (form {:editing? true :values form-values :validation validation-report
> :on-change handle-form-change}
>   [form/text {:id :name}]
>   [form/number {:id :age}])
>
> After the macro I want the following code:
>
> [:div.form.horizontal
>   {:class "editing"}
>   [form/text {:id :name :value "a-duplicate-user" :errors "Duplicate name"
> :on-click (fn [e] (handle-form-change :name (-> e .target .value])]
>   [form/number {:id :age :value "-1" :errors "You must be at least 0"
> :on-click (fn [e] (handle-form-change :age (-> e .target .value))]]
>
> However, ideally the macro would _not_ emit the contents of the input as
> literals but would emit code that inspects the provided parameters at
> run-time (i.e. rather than :value "a-duplicate-user" I would much prefer
> :value (-> state values :name) as that will allow me to pass in an atom for
> example.
>
> I have tried so many variations and evaluating the state (e.g. (:editing?
> state)) works fine as the emitted code has the destructured values, but
> that doesn't work for an atom.
>
> Here is my attempt at trying to emit code that interrogates the provided
> parameter.
>
> (defmacro form [state & elements]
>   (let [state# state]
> `[:div.form.horizontal
>   {:class (if (:editing? state#) "editing" "editable")}
>   ~@(map (fn [[_ {:keys [id]} :as child]]
>(update child 1 assoc
>:editing? (:editing? state#)
>:value `(-> (:values state#) 'deref (get ~id))
>:on-change `(fn [e#]
>  (js/console.log "E: "
> (cljs.core/clj->js e#))
>  ((:on-change state#) ~id (-> e#
> .-target .-value)
>  elements)]))
>
> The error I am getting is that there is such var as the gen-sym's state#
> in the namespace.
>
> The generic thing I am trying to do is remove the boilerplate from each of
> the items in the form.
>
> Any and all suggestions are welcome.
>
> 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 receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about equality in HashMaps

[Michael Blume]

I wonder why instaREPL prints a as {"a" 3, "r" 1, "u" 1}

On Fri, Sep 11, 2015 at 3:42 PM Alex Miller  wrote:

> a uses characters (\a \b \c)
> b uses strings ("a" "b" "c")
>
> Those are not equal...
>
> Try:
> (def b {\a 3 \r 1 \u 1})
>
>
> On Friday, September 11, 2015 at 5:37:32 PM UTC-5, Erlis Vidal wrote:
>>
>> (def a (apply merge-with + (map #(hash-map %1 1) "aaaur")))
>> (def b {"a" 3, "r" 1, "u" 1})
>>
>>  (= a b)  ; why false
>>  (.equals a b)
>>
>>  (type a)
>>  (type b)
>>
>>  (identity a)
>>  (identity b)
>>
>> from http://web.clojurerepl.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.
>

-- 
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: Filter predicates and side-effects

[Michael Blume]

Don't call filter for side effects, don't rely on when side effects will or
will not happen, but yeah, your filter predicate can have side effects.
On Wed, Sep 2, 2015 at 9:13 AM James Elliott  wrote:

> Indeed, that would make sense for filter, but since filterv immediately
> puts them all into a vector, I was particularly puzzled by the warning on
> its doc string.
>
> In my case I am not relying on the side effects for anything, I merely
> cannot guarantee there are none (and even if chunking were an issue, the
> list is immediately fully consumed). So I tentatively think I am ok, but it
> is still an unsettling warning.
>
>
> On Wednesday, September 2, 2015 at 11:06:01 AM UTC-5, Raymond Huang wrote:
>
>> I believe the reason it's not recommended is because it returns a lazy
>> chunked sequence. This means that it's not guaranteed to eagerly perform
>> your side-effects, unless you wrap it in `doall`.
>>
> On Wed, Sep 2, 2015 at 8:48 AM, James Elliott  wrote:
>>
> I notice that the documentation for filter and filterv are emphatic that
>>> the predicate you are using be free of side effects. Why is that so? For
>>> example, I would like to use filterv to collect a list of lighting
>>> effects which respond false to a protocol method which asks whether
>>> they have finished. In the implementation of that method, the effects are
>>> free to update their internal state based on the current show state and
>>> time, when deciding whether or not they are finished, and so I can’t
>>> guarantee there will be no side effects while filtering the effects. Does
>>> that mean I can’t use filterv? If not, why not? Looking at the source,
>>> I see no obvious problems.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>>
>> To post to this group, send email to clo...@googlegroups.com
>>
>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>>
>> clojure+u...@googlegroups.com
>>
>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+u...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best Practice on loading namespaces

[Michael Blume]

This is component, all of it:
https://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj
-- that's well below the size threshold where I'm comfortable saying if
someone else is maintaining it, that's one less thing for me to do; if they
ever stop, this'll become part of my app

On Thu, Jul 23, 2015 at 2:42 PM keegan myers keeganmyers...@gmail.com
wrote:

 It's an interesting approach, the extra layers of abstraction feel
 reminiscent of my days with enterprise java.  As far as components go I
 think I might be able to achieve a similar effect using prismatic/plumbing
 graphs. The lazy compile option for graphs may be beneficial when there are
 a very large number of elements in the graph. Also I'm sure components is
 amazing but I try not to use any library that has fewer than a handful of
 active maintainers. The prospect of one of my core dependencies in a
 production app becoming outdated to the point of incompatibility is very
 worrisome.

 I've also considered the fact that If I have a large number of elements
 that each depend on the same thing like a database connection. I could
 apply that thing to each in sequence with a monad. Basically the monad's
  context would hold the database connection and then each element could be
 raised into that context when it needed the connect.  But, that's just my
 limited Haskell knowledge coming through again.


 On Wednesday, July 22, 2015 at 11:06:48 AM UTC-5, keegan myers wrote:

 I've begun building a rather complex web application in
 Clojure/ClojureScript. After some evaluation I decided that CQRS + event
 sourcing would fit the requirements well. As such I have a bunch of
 aggregates (models) each in their own namespace that contain all the
 applicable record definitions, their invariants, and the commands each
 responds to. Predictably there are numerous operations that are similar
 between all aggregates.

 In my controllers I will be evaluating JSON requests and creating a list
 of commands based on those requests. I would like to dynamically dispatch
 the commands to the aggregates and let the aggregates handle them by either
 returning more commands or committing an event to the db. What is the best
 practice to dynamically send a command to an aggregate's namespace? I'm
 aware of solutions that make use of protocols and multimethods. My primary
 concern is where should I be requiring the aggregate namespaces?

 Is it best to do as some web frameworks do and just require everything
 (all namespaces) in some kind of application wide superset (probably using
 tools.namespace). Should I have a superset for each type of namespace (eg
 all controllers required together, all aggregates ...) or should I only
 require a namespace on an as needed basis. If so how would I achieve
 dynamic dispatch between aggregates without requiring their namespace.

 Sorry I'm still pretty new to Clojure. I know I can achieve this in a
 number of ways, but I'm looking for the most idiomatic approach that will
 cause the least headaches as this application grows.

  --
 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: [ANN] Clojure 1.8.0-alpha2

[Michael Blume]

(It looks like you're depending on Potemkin through clj-http, so upgrading
to clj-http 2.0.0 will also solve the problem)

On Sun, Jul 19, 2015 at 4:53 PM Michael Blume blume.m...@gmail.com wrote:

 Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out

 On Sun, Jul 19, 2015 at 4:50 PM Michael Blume blume.m...@gmail.com
 wrote:

 Sean, I think that was identified as a bug in Potemkin. The pull was
 merged but I'm not sure if there's been a release since. Zack?

 https://github.com/ztellman/potemkin/pull/40


 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632

 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org wrote:

 On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote:
  Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this
 week. We may go to production with it fairly quickly.

 Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting
 here in case anyone knows immediately what the cause is, while I go
 debugging...

 Exception in thread main java.lang.NoClassDefFoundError: IllegalName:
 compile__stub.clj_http.headers.clj-http.headers/HeaderMap,
 compiling:(clj_http/headers.clj:105:1)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.analyze(Compiler.java:6553)
 at
 clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
 at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.analyze(Compiler.java:6553)
 at
 clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
 at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359)
 at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.eval(Compiler.java:6847)
 at clojure.lang.Compiler.eval(Compiler.java:6839)
 at clojure.lang.Compiler.load(Compiler.java:7295)
 at clojure.lang.RT.loadResourceScript(RT.java:372)
 at clojure.lang.RT.loadResourceScript(RT.java:363)
 at clojure.lang.RT.load(RT.java:453)
 at clojure.lang.RT.load(RT.java:419)
 at clojure.core$load$fn__5448.invoke(core.clj:5866)
 at clojure.core$load.doInvoke(core.clj:5865)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.core$load_one.invoke(core.clj:5671)
 at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
 at clojure.core$load_lib.doInvoke(core.clj:5710)
 at clojure.lang.RestFn.applyTo(RestFn.java:142)
 at clojure.core$apply.invoke(core.clj:632)
 at clojure.core$load_libs.doInvoke(core.clj:5749)
 at clojure.lang.RestFn.applyTo(RestFn.java:137)
 at clojure.core$apply.invoke(core.clj:632)
 at clojure.core$require.doInvoke(core.clj:5832)
 at clojure.lang.RestFn.invoke(RestFn.java:482)
 at
 clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1)
 at clj_http.core$eval855.invoke(core.clj:1)

 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.



-- 
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] Clojure 1.8.0-alpha2

[Michael Blume]

Sean, I think that was identified as a bug in Potemkin. The pull was merged
but I'm not sure if there's been a release since. Zack?

https://github.com/ztellman/potemkin/pull/40

http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632

On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org wrote:

 On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote:
  Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this
 week. We may go to production with it fairly quickly.

 Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting
 here in case anyone knows immediately what the cause is, while I go
 debugging...

 Exception in thread main java.lang.NoClassDefFoundError: IllegalName:
 compile__stub.clj_http.headers.clj-http.headers/HeaderMap,
 compiling:(clj_http/headers.clj:105:1)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.analyze(Compiler.java:6553)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
 at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.analyze(Compiler.java:6553)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
 at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359)
 at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.eval(Compiler.java:6847)
 at clojure.lang.Compiler.eval(Compiler.java:6839)
 at clojure.lang.Compiler.load(Compiler.java:7295)
 at clojure.lang.RT.loadResourceScript(RT.java:372)
 at clojure.lang.RT.loadResourceScript(RT.java:363)
 at clojure.lang.RT.load(RT.java:453)
 at clojure.lang.RT.load(RT.java:419)
 at clojure.core$load$fn__5448.invoke(core.clj:5866)
 at clojure.core$load.doInvoke(core.clj:5865)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.core$load_one.invoke(core.clj:5671)
 at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
 at clojure.core$load_lib.doInvoke(core.clj:5710)
 at clojure.lang.RestFn.applyTo(RestFn.java:142)
 at clojure.core$apply.invoke(core.clj:632)
 at clojure.core$load_libs.doInvoke(core.clj:5749)
 at clojure.lang.RestFn.applyTo(RestFn.java:137)
 at clojure.core$apply.invoke(core.clj:632)
 at clojure.core$require.doInvoke(core.clj:5832)
 at clojure.lang.RestFn.invoke(RestFn.java:482)
 at
 clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1)
 at clj_http.core$eval855.invoke(core.clj:1)

 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.


-- 
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] Clojure 1.8.0-alpha2

[Michael Blume]

Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out

On Sun, Jul 19, 2015 at 4:50 PM Michael Blume blume.m...@gmail.com wrote:

 Sean, I think that was identified as a bug in Potemkin. The pull was
 merged but I'm not sure if there's been a release since. Zack?

 https://github.com/ztellman/potemkin/pull/40


 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632

 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org wrote:

 On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote:
  Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this
 week. We may go to production with it fairly quickly.

 Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting
 here in case anyone knows immediately what the cause is, while I go
 debugging...

 Exception in thread main java.lang.NoClassDefFoundError: IllegalName:
 compile__stub.clj_http.headers.clj-http.headers/HeaderMap,
 compiling:(clj_http/headers.clj:105:1)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.analyze(Compiler.java:6553)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
 at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.analyze(Compiler.java:6553)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
 at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359)
 at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789)
 at clojure.lang.Compiler.analyze(Compiler.java:6592)
 at clojure.lang.Compiler.eval(Compiler.java:6847)
 at clojure.lang.Compiler.eval(Compiler.java:6839)
 at clojure.lang.Compiler.load(Compiler.java:7295)
 at clojure.lang.RT.loadResourceScript(RT.java:372)
 at clojure.lang.RT.loadResourceScript(RT.java:363)
 at clojure.lang.RT.load(RT.java:453)
 at clojure.lang.RT.load(RT.java:419)
 at clojure.core$load$fn__5448.invoke(core.clj:5866)
 at clojure.core$load.doInvoke(core.clj:5865)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.core$load_one.invoke(core.clj:5671)
 at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
 at clojure.core$load_lib.doInvoke(core.clj:5710)
 at clojure.lang.RestFn.applyTo(RestFn.java:142)
 at clojure.core$apply.invoke(core.clj:632)
 at clojure.core$load_libs.doInvoke(core.clj:5749)
 at clojure.lang.RestFn.applyTo(RestFn.java:137)
 at clojure.core$apply.invoke(core.clj:632)
 at clojure.core$require.doInvoke(core.clj:5832)
 at clojure.lang.RestFn.invoke(RestFn.java:482)
 at
 clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1)
 at clj_http.core$eval855.invoke(core.clj:1)

 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.



-- 
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: How do I expand a variable that I pass to a macro?

[Michael Blume]

First of all, I'm pretty sure compojure will let you do the thing, because
it's less macro-heavy than what you're using.

But to answer the general question, this is a fundamental problem with
macros. Once you're making heavy use of macros you start having to write
more macros in order to compose them.

On Sun, Jul 12, 2015 at 1:01 PM Lynn Dylan Hurley 
lynn.dylan.hur...@gmail.com wrote:

 Here is what I'm trying to do:

 ---

 ;; route defined outside of the defroutes macro
 (def foo-route [/ {:get foo-handler}])

 (defroutes routes
   [[[/
   ;; I'm trying to do this, but it does NOT work
   [/foo foo-route]

   ;; this does work
   [/bar [/ {:get bar-handler}])

 ---

 Where `defroutes` is a macro defined by pedestal. I've tried this a million 
 different ways and nothing seems to work. Is what I'm trying to do even 
 possible?

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

[Michael Blume]

Looking through the tickets at http://dev.clojure.org/jira/browse/ASYNC
might give you a better idea of what's planned.

On Sat, Jul 4, 2015 at 8:52 PM Martin Raison martinrai...@gmail.com wrote:

 thanks!

 Le samedi 4 juillet 2015 20:38:22 UTC-7, Alex Miller a écrit :

 Oh just busy. We will get to a new release at some point.

  --
 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: let vs. let*

[Michael Blume]

Basically you the user should not worry about the starred versions

On Thu, Jun 18, 2015 at 1:40 PM Johannes bra...@nordakademie.de wrote:

 thanks

 Am Donnerstag, 18. Juni 2015 22:35:53 UTC+2 schrieb raould:

 http://lmgtfy.com/?q=clojure+%22let+vs.+let*%22

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

[ANN] honeysql now available from Clojurescript

[Michael Blume]

Using reader conditionals, I've put up an experimental branch of honeysql
which seems to work just fine from both Clojure and Clojurescript. If you
need to generate SQL from your Node service, please try it out.

https://github.com/michaelblume/honeysql/tree/rcond

Will update soon with my experiences, ran into a few rough edges during the
port, but everything seems to work pretty nicely.

-- 
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: JDK8

[Michael Blume]

Not quite sure what you're asking -- I think Clojure itself is intended to
be fully supported on JDK 8, and I regularly build it/build my projects
with JDK 8 (though I think I'm using the Oracle version)

On Thu, May 7, 2015 at 1:25 PM Pierre-Yves Ritschard p...@spootnik.org
wrote:

 Hi,

 There hasn't been a JDK version thread in a while and a few projects we
 rely on will soon require a JDK8. Are people running large apps on JDK8 and
 if so, which one ? I'd be intent on trying to stick with OpenJDK if at all
 possible.

 Cheers,

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


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

Are keys and vals guaranteed to return in the same order?

[Michael Blume]

In other people's Clojure code I sometimes see things like

(zipmap
  (map some-fn (keys m))
  (map other-fn (vals m)))

If it were my code I'd be much more inclined to write

(into {}
  (for [[k v] m]
[(some-fn k) (other-fn v)]))

Is this a to-each-their-own thing or is the latter preferred?

-- 
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: Generating .clj files with content

[Michael Blume]

What James said -- if you want the results to be human readable, if you
want control of how it's formatted, if you want to be able to comment it,
if you want people to use it as a starting point for code they're going to
write, then check out the punctions in
https://github.com/technomancy/leiningen/blob/master/src/leiningen/new/templates.clj
-- if not, pr-str will do you fine.

On Wed, Apr 8, 2015 at 10:25 AM James Reeves ja...@booleanknot.com wrote:

 On 8 April 2015 at 14:20, Sven Richter sver...@googlemail.com wrote:

 I want to create clojure source files with some code and a namespace and
 everything else what is useful for some source code.
 What I am looking for is a templating language for clojure code, is there
 something like this already? What would be the most idiomatic way to do
 that besides just writing strings into a file?


 What's the purpose? If it's just to generate some Clojure code that will
 never be read by a human, then you can use Clojure's backtick syntax with
 the pr-str function. If it's to generate human-readable code, then you're
 probably best using a text templating language.

 You may also want to look at Leiningen templates or lein-generate.

 - 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: Has anyone seen this error while running lein-cloverage?

[Michael Blume]

Yes. Cloverage needs to merge https://github.com/lshift/cloverage/pull/59
-- in the meantime, you can add
https://github.com/MichaelBlume/cloverage-compojure-fix to your project and
it will route around the problem.

On Tue, Apr 7, 2015 at 11:27 AM Jonathon McKitrick jmckitr...@gmail.com
wrote:

 Here's a test in question:

 (deftest reports
   (testing PDF schedule
 (testing by api call
   (let [req (request :get /schedule.pdf)]
  (mocking
   [pts.reports/get-schedule-pdf]
   (app req); line 1035
   (verify-call-times-for pts.reports/get-schedule-pdf 1))

 The tests pass, but when run with lein-cloverage, I get this error.

 ERROR in (reports) (core_deftype.clj:544)
 Uncaught exception, not in assertion.
 expected: nil
   actual: java.lang.IllegalArgumentException: No implementation of method:
 :route-matches of protocol: #'clout.core/Route found for class:
 clojure.lang.PersistentArrayMap
  at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:544)
 clout.core$eval15857$fn__15858$G__15848__15865.invoke (core.clj:39)
 compojure.core$if_context$fn__16124.invoke (core.clj:188)
 compojure.core$routing$fn__16062.invoke (core.clj:127)
 clojure.core$some.invoke (core.clj:2515)
 compojure.core$routing.doInvoke (core.clj:127)
 clojure.lang.RestFn.applyTo (RestFn.java:139)
 clojure.core$apply.invoke (core.clj:626)
 compojure.core$routes$fn__16066.invoke (core.clj:132)
 pts.server_test$fn__28317$fn__28318$fn__28319.invoke
 (server_test.clj:1035)

 --
 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: Newbie question about filtrering defrecord

[Michael Blume]

your list doesn't contain the records, your list contains the symbols 'a1
and 'a2. You can't make a list the way you're trying to.

On Sat, Apr 4, 2015 at 5:14 PM Luc Préfontaine lprefonta...@softaddicts.ca
wrote:

 You mean the a1 record no ?


  Hi!
 
  I'm new to clojure, and have problem understanding how to filter a list
 of
  defrecords.
  I have tried different variations on the following:
 
  (defrecord Ape [fname lname])
  (def a1 (-Ape test1 test2))
  (def a2 (-Ape test3 test4))
  (def alist '(a1 a2))
 
  (filter #(= test1 (:fname %)) alist)
 
  I expect the filter to match the a2 record, but I obviously do something
  wrong and would appreciate any suggestion.
 
  Kind regards
  Magnus Jäverberg
 
  --
  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.
 
 --
 Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail!

 --
 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: [ANN] Clojure 1.7.0-alpha6 released

[Michael Blume]

I've proposed a patch to instaparse to fix this, I realize it's not the
most elegant version check ever, but it should fix the problem
https://github.com/Engelberg/instaparse/pull/94

On Tue, Mar 31, 2015 at 3:21 PM Sean Corfield s...@corfield.org wrote:

 Looks like a great set of updates!

 Unfortunately, as several of us found out today, the change to the
 StringReader invoke() signature breaks Instaparse so I’m blocked from
 testing the World Singles code base with alpha6 (or master) at the moment.
 Is that just a hazard of relying on the internals of reader classes or
 would Clojure/core consider that breakage avoidable (by adding an
 overloaded signature instead of just changing the current signature)? Since
 those readers extend AFn, it seems that there is an expectation that they
 would be used as functions in Clojure code out in the wild...

 Sean

 On Mar 31, 2015, at 9:50 AM, Alex Miller a...@puredanger.com wrote:

 Clojure 1.7.0-alpha6 is now available.

 Try it via
 - Download:
 https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
 - Leiningen: [org.clojure/clojure 1.7.0-alpha6]

 Regression fixes from previous alphas (and one from 1.6):

 1) CLJ-1544 was rolled back and will be investigated for a future release.
 2) CLJ-1637 fixed regression with vec on MapEntry
 3) CLJ-1663 fixed regression in classloader (affected Cursive)
 4) CLJ-1638 fixed regression with removed PersistentVector.create(List)
 method
 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for
 literal nil arg
 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that
 prevented update

 Some highlights new in alpha6:

 ## Transducer-related changes:

 The LazyTransformer introduced to create lazy transforming sequences has
 been
 replaced with a TransformingIterator. This was done to simplify the code
 around transformations and to make certain use cases around eduction more
 efficient.

 ## Faster reduce, iterator, and sequence paths

 A lot of work has been done across a set of tickets to improve the ability
 of
 collections to provide more efficient reduce or iterator performance, and
 also to
 make common sequence generators create faster sequence and reduce paths.
 You
 should see significant performance in many reduce-related paths (this
 includes
 reduce, transduce, into, and anything else built on reduce).

 Many of those changes also have beneficial sequence performance, so you
 may see
 some benefits even in code that does not use transducers.

 * Most uses of SeqIterator have now been replaced with iterators that
 directly walk
 the underlying source for improved efficiency. This includes maps, sets,
 records, etc.
 * repeat - now returns a faster sequence with a fast reduce path
 * cycle - now returns a faster sequence with a fast reduce path
 * iterate - now returns a faster sequence with a fast reduce path
 * range - (did not quite make it in, but coming soon...)
 * keys - iterates directly over the keys of a map, without seq or MapEntry
 allocation
 * vals - iterates directly over the vals of a map, without seq or MapEntry
 allocation
 * iterator-seq - now creates a chunked sequence when previously it was
 unchunked
 * vec and set - were not changed in this release but were set up in a
 previous alpha
   to take advantage of the reduce and iterator changes above

 ## Reader conditionals

 Reader Conditionals is a new capability to support portable code that
 can run on multiple Clojure platforms with only small changes. In
 particular, this feature aims to support the increasingly common case
 of libraries targeting both Clojure and ClojureScript.

 Code intended to be common across multiple platforms should use a new
 supported file extension: .cljc. When requested to load a namespace,
 the platform-specific file extension (.clj, .cljs) will be checked
 prior to .cljc.

 A new reader form can be used to specify reader conditional code in
 cljc files (and *only* cljc files). Each platform defines a feature
 identifying the platform (:clj, :cljs, :cljr). The reader conditional
 specifies code that is read conditionally based on the feature/

 Form #? takes a list of alternating feature and expression. These are
 checked like cond and the selected expression is read and returned. Other
 branches are unread. If no branch is selected, the reader reads nothing
 (not nil, but literally as if reading ). An optional :default branch
 can be used as a fallthrough.

 Reader conditional with 2 features and a default:

 #?(:clj Double/NaN
:cljsjs/NaN
:default nil)

 There is also a reader conditional splicing form. The evaluated expression
 should be sequential and will be spliced into the surrounded code, similar
 to unqoute-splicing.

 For example:

[1 2 #?@(:clj [3 4] :cljs [5 6])]

 This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript,
 and [1 2] on any other platform.

 Additionally, the reader can now be invoked with options for the 

Re: Clojure Culture Question on TDD

[Michael Blume]

It is rare to see an open source clojure project without tests. Clojure
itself is pretty thoroughly tested, as is leiningen. I don't know about
test-first. I think it's actually more common to see REPL-first -- build
something through exploration in the REPL and then turn whatever you did in
the REPL into a unit test.

On Tue, Mar 24, 2015 at 7:53 PM Daniel Hinojosa dh.evolutionn...@gmail.com
wrote:

 What is TDD culture in Clojure like? Is it strong in the community and
 other projects?  I am aware of Rich Hickey's guard rail analogy. Did that
 have an effect on how Clojurists view TDD or testing in general? Just
 asking for my own personal research.

 --
 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: Disk based caching for Clojure app

[Michael Blume]

Possibly stupid question: can you just pretend you have more memory than
you do and let the operating system do the heavy lifting?

On Fri, Mar 6, 2015, 10:54 AM JPatrick Davenport virmu...@gmail.com wrote:

 Hello,
 I'm been thinking about an idea for a cache layer. It's driven by two
 trends.

 Most caches are in memory. They might have fancy additions like
 multi-machine, but they are in-memory. The fast memory access reduces back
 end load and improves overall performance. It also assumes you have memory
 to spare.

 The second trend is that bootstrapping a start up means minimizing costs.
 This means paying for one or two low memory machines with at most 2 GB of
 RAM. Linode, for example, would cost $40/month to have two 2GB nodes (app
 and db).

 The two trends don't really overlap well. I want the caching, but I can't
 yet afford it.

 Where they *could* overlap is the fact that Linode's drives are SSD. They
 are not as fast as memory, but probably faster than DB + Network. Is there
 any pure Clojure library that does this? I'd like to say, Keep 30 MB of
 Cache in Ram and 2 GB of SSD cache. I guess another way to ask it: is
 there anything like Java Caching System in pure Clojure?

 Thanks,
 JPD

 --
 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: Is Caribou Dormant ?

[Michael Blume]

Sure looks dormant to me. My usual rule is, if you think you'd feel
comfortable maintaining it yourself if it ever became necessary, use it,
otherwise look elsewhere.

On Wed, Feb 25, 2015 at 3:36 PM Geraldo Lopes de Souza geraldo...@gmail.com
wrote:

 Hi,

 I'm checking Caribou, and wanna know if anyone is using it.
 It appears that it is a dormant project by the looks of the last update

 https://github.com/caribou/caribou

 Thanks in advance,

 Geraldo Lopes de Souza

 --
 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: Continuously Integrating Leiningen Projects

[Michael Blume]

Afraid the plugin's internal.

On Wed Feb 18 2015 at 2:34:32 AM Rick Moynihan rick.moyni...@gmail.com
wrote:

 This sounds very close to what I'm looking for.

 Is this plugin opensourced or something you're using locally, as the
 closest thing I can find to what you describe is lein-git-version:

 https://github.com/cvillecsteele/lein-git-version

 Which seems to follow project middleware approach you describe, but
 for a different use case.

 R.

 On 18 February 2015 at 06:18, Michael Blume blume.m...@gmail.com wrote:
  We use a Leiningen plugin to set the version dynamically
 
  https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md --
 if
  you skip down to project middleware you'll see how to create the kind
 of
  plugin I'm talking about. Within the middleware function, we update the
  :version key in the project map to a version string composed of a
 timestamp
  and the first few characters of the commit hash. The timestamp part is
  important because it ensures that maven/lein consider newer builds to be
  newer.
 
  As for lein-ancient, we don't really have it *do* anything, it just
 prints
  its suggestions in the build output, and if you look at your build from
 time
  to time, you'll see there are libraries you can upgrade. It's not a
 perfect
  system, but it helps.
 
  On Tue Feb 17 2015 at 4:23:03 PM Rick Moynihan rick.moyni...@gmail.com
  wrote:
 
  Thanks for the tip,  I had used lein-ancient in the past and it seems
  to have come along a bit since then.
 
  How is it that you have this configured?
 
  Do you run lein ancient upgrade before each build that you want to
  check its dependencies?  I tried this locally and I can't find a way
  to tell lein ancient to only try and upgrade certain libraries, rather
  than all or nothing.
 
  For example I have a dependency on incanter 1.5.5 - I don't want it to
  upgrade to 1.9.0 because it will break the build catastrophically just
  now...  I do however want to whitelist it to my library, which I'm
  expecting to keep more current.
 
  R.
 
  On 17 February 2015 at 19:14, Michael Blume blume.m...@gmail.com
 wrote:
   Related -- we run lein ancient as part of a lot of our builds so that
 we
   can
   easily pick up dependencies with newer available versions.
  
   On Tue Feb 17 2015 at 11:13:44 AM Michael Blume blume.m...@gmail.com
 
   wrote:
  
   What we do at Climate is avoid SNAPSHOT builds. Every build gets a
   version
   string with timestamp and git commit. If an upstream library is
   changed,
   it's up to downstream maintainers to update their dependency on it.
 If
   you
   update a dependency and your build fails, you a) don't update your
   dependency just yet b) complain to the library maintainer that their
   new
   version breaks your project.
  
   On Tue Feb 17 2015 at 9:51:18 AM Rick Moynihan
   rick.moyni...@gmail.com
   wrote:
  
   Hi all,
  
   At work, we use Jenkins to continuously integrate our Clojure
 projects
   which are factored into both applications and a small number of
   supporting libraries; all of which use Leiningen as their project
   build tool.
  
   Leiningen builds each project, and runs its tests; and then if they
   pass it lein installs the project jar into the local ~/.m2 repo and
   triggers any dependent builds to start.  The dependencies then start
   building and pick up the latest SNAPSHOT build from the ~/.m2
   directory.
  
   This works ok; but it has a relatively major flaw, which is that
 just
   because a project passes its local tests; it doesn't mean that it
   hasn't broken an upstream library.  When this happens the broken
   library is left in the shared ~/.m2 directory - breaking other
 builds
   and generally lying around causing havoc.
  
   Fortunately this rarely happens in practice; but it is a potential
   cause of hard to diagnose (unrepeatable build) problems - especially
   when using snapshot builds - which is what I think we want to use
 for
   tracking branches until we
  
   We currently use the Jenkins leiningen plugin, but I don't think it
   supports a more sophisticated setup than this.
  
   I was wondering if anyone with experience of running robust CI
 builds
   (with Jenkins) might have any ideas about to solve this in a more
   robust manner??
  
   Many thanks,
  
   Rick
   --
   http://twitter.com/RickMoynihan
  
   --
   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

Re: Continuously Integrating Leiningen Projects

[Michael Blume]

We use a Leiningen plugin to set the version dynamically

https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md -- if
you skip down to project middleware you'll see how to create the kind of
plugin I'm talking about. Within the middleware function, we update the
:version key in the project map to a version string composed of a timestamp
and the first few characters of the commit hash. The timestamp part is
important because it ensures that maven/lein consider newer builds to be
newer.

As for lein-ancient, we don't really have it *do* anything, it just prints
its suggestions in the build output, and if you look at your build from
time to time, you'll see there are libraries you can upgrade. It's not a
perfect system, but it helps.

On Tue Feb 17 2015 at 4:23:03 PM Rick Moynihan rick.moyni...@gmail.com
wrote:

 Thanks for the tip,  I had used lein-ancient in the past and it seems
 to have come along a bit since then.

 How is it that you have this configured?

 Do you run lein ancient upgrade before each build that you want to
 check its dependencies?  I tried this locally and I can't find a way
 to tell lein ancient to only try and upgrade certain libraries, rather
 than all or nothing.

 For example I have a dependency on incanter 1.5.5 - I don't want it to
 upgrade to 1.9.0 because it will break the build catastrophically just
 now...  I do however want to whitelist it to my library, which I'm
 expecting to keep more current.

 R.

 On 17 February 2015 at 19:14, Michael Blume blume.m...@gmail.com wrote:
  Related -- we run lein ancient as part of a lot of our builds so that we
 can
  easily pick up dependencies with newer available versions.
 
  On Tue Feb 17 2015 at 11:13:44 AM Michael Blume blume.m...@gmail.com
  wrote:
 
  What we do at Climate is avoid SNAPSHOT builds. Every build gets a
 version
  string with timestamp and git commit. If an upstream library is changed,
  it's up to downstream maintainers to update their dependency on it. If
 you
  update a dependency and your build fails, you a) don't update your
  dependency just yet b) complain to the library maintainer that their new
  version breaks your project.
 
  On Tue Feb 17 2015 at 9:51:18 AM Rick Moynihan rick.moyni...@gmail.com
 
  wrote:
 
  Hi all,
 
  At work, we use Jenkins to continuously integrate our Clojure projects
  which are factored into both applications and a small number of
  supporting libraries; all of which use Leiningen as their project
  build tool.
 
  Leiningen builds each project, and runs its tests; and then if they
  pass it lein installs the project jar into the local ~/.m2 repo and
  triggers any dependent builds to start.  The dependencies then start
  building and pick up the latest SNAPSHOT build from the ~/.m2
  directory.
 
  This works ok; but it has a relatively major flaw, which is that just
  because a project passes its local tests; it doesn't mean that it
  hasn't broken an upstream library.  When this happens the broken
  library is left in the shared ~/.m2 directory - breaking other builds
  and generally lying around causing havoc.
 
  Fortunately this rarely happens in practice; but it is a potential
  cause of hard to diagnose (unrepeatable build) problems - especially
  when using snapshot builds - which is what I think we want to use for
  tracking branches until we
 
  We currently use the Jenkins leiningen plugin, but I don't think it
  supports a more sophisticated setup than this.
 
  I was wondering if anyone with experience of running robust CI builds
  (with Jenkins) might have any ideas about to solve this in a more
  robust manner??
 
  Many thanks,
 
  Rick
  --
  http://twitter.com/RickMoynihan
 
  --
  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

Re: Continuously Integrating Leiningen Projects

[Michael Blume]

Related -- we run lein ancient as part of a lot of our builds so that we
can easily pick up dependencies with newer available versions.

On Tue Feb 17 2015 at 11:13:44 AM Michael Blume blume.m...@gmail.com
wrote:

 What we do at Climate is avoid SNAPSHOT builds. Every build gets a version
 string with timestamp and git commit. If an upstream library is changed,
 it's up to downstream maintainers to update their dependency on it. If you
 update a dependency and your build fails, you a) don't update your
 dependency just yet b) complain to the library maintainer that their new
 version breaks your project.

 On Tue Feb 17 2015 at 9:51:18 AM Rick Moynihan rick.moyni...@gmail.com
 wrote:

 Hi all,

 At work, we use Jenkins to continuously integrate our Clojure projects
 which are factored into both applications and a small number of
 supporting libraries; all of which use Leiningen as their project
 build tool.

 Leiningen builds each project, and runs its tests; and then if they
 pass it lein installs the project jar into the local ~/.m2 repo and
 triggers any dependent builds to start.  The dependencies then start
 building and pick up the latest SNAPSHOT build from the ~/.m2
 directory.

 This works ok; but it has a relatively major flaw, which is that just
 because a project passes its local tests; it doesn't mean that it
 hasn't broken an upstream library.  When this happens the broken
 library is left in the shared ~/.m2 directory - breaking other builds
 and generally lying around causing havoc.

 Fortunately this rarely happens in practice; but it is a potential
 cause of hard to diagnose (unrepeatable build) problems - especially
 when using snapshot builds - which is what I think we want to use for
 tracking branches until we

 We currently use the Jenkins leiningen plugin, but I don't think it
 supports a more sophisticated setup than this.

 I was wondering if anyone with experience of running robust CI builds
 (with Jenkins) might have any ideas about to solve this in a more
 robust manner??

 Many thanks,

 Rick
 --
 http://twitter.com/RickMoynihan

 --
 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: Continuously Integrating Leiningen Projects

[Michael Blume]

What we do at Climate is avoid SNAPSHOT builds. Every build gets a version
string with timestamp and git commit. If an upstream library is changed,
it's up to downstream maintainers to update their dependency on it. If you
update a dependency and your build fails, you a) don't update your
dependency just yet b) complain to the library maintainer that their new
version breaks your project.

On Tue Feb 17 2015 at 9:51:18 AM Rick Moynihan rick.moyni...@gmail.com
wrote:

 Hi all,

 At work, we use Jenkins to continuously integrate our Clojure projects
 which are factored into both applications and a small number of
 supporting libraries; all of which use Leiningen as their project
 build tool.

 Leiningen builds each project, and runs its tests; and then if they
 pass it lein installs the project jar into the local ~/.m2 repo and
 triggers any dependent builds to start.  The dependencies then start
 building and pick up the latest SNAPSHOT build from the ~/.m2
 directory.

 This works ok; but it has a relatively major flaw, which is that just
 because a project passes its local tests; it doesn't mean that it
 hasn't broken an upstream library.  When this happens the broken
 library is left in the shared ~/.m2 directory - breaking other builds
 and generally lying around causing havoc.

 Fortunately this rarely happens in practice; but it is a potential
 cause of hard to diagnose (unrepeatable build) problems - especially
 when using snapshot builds - which is what I think we want to use for
 tracking branches until we

 We currently use the Jenkins leiningen plugin, but I don't think it
 supports a more sophisticated setup than this.

 I was wondering if anyone with experience of running robust CI builds
 (with Jenkins) might have any ideas about to solve this in a more
 robust manner??

 Many thanks,

 Rick
 --
 http://twitter.com/RickMoynihan

 --
 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: Performant string concatenation (of many, large strings)

[Michael Blume]

Basically same way you profile java, I usually use jvisualvm, if you feel
like shelling out for yourkit that can be nicer.

On Sat Feb 14 2015 at 11:23:12 AM Ivan L ivan.laza...@gmail.com wrote:

 What is the best way to profile Clojure? I tried a reduce doto thing but
 it was way slowe than apply str.  would love to know why.

 --
 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: Performant string concatenation (of many, large strings)

[Michael Blume]

For minimal change to the presented code, what about

(defprotocol appendable (append-to [this ^StringBuilder sb]))

(extend-protocol appendable
  String
  (append-to [this ^StringBuilder sb] (.append sb this))
  clojure.lang.IFn
  (append-to [this ^StringBuilder sb] (this sb))
  Object
  (append-to [this ^StringBuilder sb] (.append sb (str this

(defn final-str [a]
  (let [sb (StringBuilder.)]
(append-to a sb)
(str sb)))

(defn par-join [sep xs]
  (fn [sb]
(when-let [xs (seq xs)]
  (append-to (first xs) sb)
  (doseq [x (next xs)]
(append-to sep sb)
(append-to x sb)

(let [f #(- % (map (comp val)) (par-join ,))]
  (- data-struct
(map f)
(par-join \n)
final-str))

Which winds up taking about a second and only creates one StringBuilder.



On Fri Feb 13 2015 at 8:02:27 PM Andy Chambers achambers.h...@gmail.com
wrote:

 Is there a reason you're collecting the result into a string rather than
 just writing out to a file?

 --
 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: Performant string concatenation (of many, large strings)

[Michael Blume]

er, s/(comp val)/val

On Sat Feb 14 2015 at 12:17:18 AM Michael Blume blume.m...@gmail.com
wrote:

 For minimal change to the presented code, what about

 (defprotocol appendable (append-to [this ^StringBuilder sb]))

 (extend-protocol appendable
   String
   (append-to [this ^StringBuilder sb] (.append sb this))
   clojure.lang.IFn
   (append-to [this ^StringBuilder sb] (this sb))
   Object
   (append-to [this ^StringBuilder sb] (.append sb (str this

 (defn final-str [a]
   (let [sb (StringBuilder.)]
 (append-to a sb)
 (str sb)))

 (defn par-join [sep xs]
   (fn [sb]
 (when-let [xs (seq xs)]
   (append-to (first xs) sb)
   (doseq [x (next xs)]
 (append-to sep sb)
 (append-to x sb)

 (let [f #(- % (map (comp val)) (par-join ,))]
   (- data-struct
 (map f)
 (par-join \n)
 final-str))

 Which winds up taking about a second and only creates one StringBuilder.



 On Fri Feb 13 2015 at 8:02:27 PM Andy Chambers achambers.h...@gmail.com
 wrote:

 Is there a reason you're collecting the result into a string rather than
 just writing out to a file?

 --
 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: Performant string concatenation (of many, large strings)

[Michael Blume]

...Annoyingly, almost all the time for my version is spent in protocol
dispatch, so there's probably a much faster way to do that.

On Sat Feb 14 2015 at 12:21:11 AM Michael Blume blume.m...@gmail.com
wrote:

 er, s/(comp val)/val

 On Sat Feb 14 2015 at 12:17:18 AM Michael Blume blume.m...@gmail.com
 wrote:

 For minimal change to the presented code, what about

 (defprotocol appendable (append-to [this ^StringBuilder sb]))

 (extend-protocol appendable
   String
   (append-to [this ^StringBuilder sb] (.append sb this))
   clojure.lang.IFn
   (append-to [this ^StringBuilder sb] (this sb))
   Object
   (append-to [this ^StringBuilder sb] (.append sb (str this

 (defn final-str [a]
   (let [sb (StringBuilder.)]
 (append-to a sb)
 (str sb)))

 (defn par-join [sep xs]
   (fn [sb]
 (when-let [xs (seq xs)]
   (append-to (first xs) sb)
   (doseq [x (next xs)]
 (append-to sep sb)
 (append-to x sb)

 (let [f #(- % (map (comp val)) (par-join ,))]
   (- data-struct
 (map f)
 (par-join \n)
 final-str))

 Which winds up taking about a second and only creates one StringBuilder.



 On Fri Feb 13 2015 at 8:02:27 PM Andy Chambers achambers.h...@gmail.com
 wrote:

 Is there a reason you're collecting the result into a string rather than
 just writing out to a file?

 --
 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: [newbie] strange behaviour in self-referential primes lazy-seq attempt

[Michael Blume]

Strange, when I run your code I don't get 9 or 15

On Thu Feb 12 2015 at 11:02:00 AM Jorge Marques Pelizzoni 
jorge.pelizz...@gmail.com wrote:

 Hi, there! Please bear with me as I am very new to Closure (this is my
 second program ever) but have a kind of solid Haskell background.

 I was trying to get a version of this Haskell code:

 divides x y = mod x y == 0
 primeub x = div x (if even x then 2 else 3)
 isprime primes x = all (not . divides x) (lowerprimes x)
 where
 lowerprimes x = takeWhile (= primeub x) primes

 primes = 2 : filter (isprime primes) [3..]


 which works fine. E.g.: take 10 primes == [2,3,5,7,11,13,17,19,23,29]. In
 Closure, I got this:

 (defn divides? [x y] (zero? (mod x y)))
 (defn prime-ub [x] (/ x (if (even? x) 2 3)))
 (defn lower-primes [primes x] (let [ub (prime-ub x)]
   (take-while #(= % ub) primes)))
 (defn prime? [primes x] (not-any? #(divides? x %)(lower-primes primes x)))

 (defn primes [] (let [primes' (atom nil)]
  (reset! primes' (cons 2 (filter #(prime? @primes' %)
 (drop 3 (range)))

 However, I am getting (take 10 (primes)) == (2 3 5 7 9 11 13 15 17 19)
 (please notice the undesirable presence of 9 and 15 there...).

 Any ideas why this is happening? Thanks in advance.


  --
 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: [newbie] strange behaviour in self-referential primes lazy-seq attempt

[Michael Blume]

Oh, well this is fun -- with bleeding edge clojure I get the right answer,
but with 1.6.0 I see the same results you did.

On Thu Feb 12 2015 at 11:47:54 AM Michael Blume blume.m...@gmail.com
wrote:

 Strange, when I run your code I don't get 9 or 15

 On Thu Feb 12 2015 at 11:02:00 AM Jorge Marques Pelizzoni 
 jorge.pelizz...@gmail.com wrote:

 Hi, there! Please bear with me as I am very new to Closure (this is my
 second program ever) but have a kind of solid Haskell background.

 I was trying to get a version of this Haskell code:

 divides x y = mod x y == 0
 primeub x = div x (if even x then 2 else 3)
 isprime primes x = all (not . divides x) (lowerprimes x)
 where
 lowerprimes x = takeWhile (= primeub x) primes

 primes = 2 : filter (isprime primes) [3..]


 which works fine. E.g.: take 10 primes == [2,3,5,7,11,13,17,19,23,29].
 In Closure, I got this:

 (defn divides? [x y] (zero? (mod x y)))
 (defn prime-ub [x] (/ x (if (even? x) 2 3)))
 (defn lower-primes [primes x] (let [ub (prime-ub x)]
   (take-while #(= % ub) primes)))
 (defn prime? [primes x] (not-any? #(divides? x %)(lower-primes primes x
 )))

 (defn primes [] (let [primes' (atom nil)]
  (reset! primes' (cons 2 (filter #(prime? @primes' %)
 (drop 3 (range)))

 However, I am getting (take 10 (primes)) == (2 3 5 7 9 11 13 15 17 19)
 (please notice the undesirable presence of 9 and 15 there...).

 Any ideas why this is happening? Thanks in advance.


  --
 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: [newbie] strange behaviour in self-referential primes lazy-seq attempt

[Michael Blume]

Hmm, upon further investigation I think I would not call this a bug in
Clojure that got fixed, I think I'd call this an unspecified behavior in
Clojure that happened to break your function and now happens to allow it to
work.

Your function depends heavily on Clojure's laziness, and laziness is an
area where Clojure actually does not make a lot of strong guarantees.

Here's an example:

user= (def r (into [] (range 1000)))
#'user/r
user= (defn print-and-inc [x] (println x) (inc x))
#'user/print-and-inc
user= (def s (map print-and-inc r))
#'user/s
user= (take 1 s)
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
(1)
user=

In this example we put a thousand numbers in a vector and call the vector
r, we map print-and-inc over r and then we take one element from the
resulting lazy sequence. You might expect this to mean we print one element
from r, but in fact we print 32. This is because of an optimization detail
in Clojure's map function. It's very easy to extract chunks from vectors,
so in Clojure, when we map over a vector, we quickly apply the mapping
function to the first chunk of the vector and return a sequence containing
the result chunk and a promise to map over the rest. In the long run, this
speeds up map quite a bit, but in the short run, it makes map much less
lazy than one might expect.

The upshot is that when a Clojure function promises to consume your list
lazily, you should assume that it will not, say, consume 1000 elements of
your list for no reason, or try to force its way to the end of a lazy
sequence. You should *not* assume you can know exactly when it will force
the next element, as that is essentially considered an implementation
detail.

Returning to your code, you have

(defn primes [] (let [primes' (atom nil)]
 (reset! primes' (cons 2 (filter #(prime? @primes' %) (drop
3 (range)))

When you dereference primes, you're essentially trusting that reset! has
already run and replaced nil with your empty sequence, but in fact you
cannot be certain of that. I can see two ways to ensure your function will
work. One is sort of gratuitous defensive programming -- make your initial
value of primes' something you *wouldn't mind getting*, say

(defn primes [] (let [primes' (atom (drop 2 (range)))]
 (reset! primes' (cons 2 (filter #(prime? @primes' %) (drop
3 (range)))

The other is to wrap your whole expression in lazy-seq -- then reset! will
definitely complete before any of the logic internal to your sequence runs:

(defn primes [] (let [primes' (atom nil)]
 (lazy-seq (reset! primes' (cons 2 (filter #(prime?
@primes' %) (drop 3 (range

For anyone wondering, the change was Ghadi's reified range in CLJ-1515
which I seem to recall removed/modified the chunked seq implementation from
range.

On Thu Feb 12 2015 at 12:06:28 PM Jorge Marques Pelizzoni 
jorge.pelizz...@gmail.com wrote:

 Well, that's a bug then :) And seems to have been fixed. Thanks!

 Em quinta-feira, 12 de fevereiro de 2015 17:51:13 UTC-2, Michael Blume
 escreveu:

 Oh, well this is fun -- with bleeding edge clojure I get the right
 answer, but with 1.6.0 I see the same results you did.


  --
 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: Is this the good way to write get-percentage

[Michael Blume]

I think you could replace your condp = with case, since all your mode
keywords are known at compile-time, otherwise looks about right.

On Tue Feb 10 2015 at 11:32:58 PM Cecil Westerhof cldwester...@gmail.com
wrote:

 I needed a function to get the percentage as an int. Input is place and
 total-count.
 I want the normal definition (which is the default) and a high and low
 variant.

 I came up with the following code:
 (defn get-percentage
   ([place total-count] (get-percentage :normal place total-count))
   ([mode place total-count]
 (let [percentage (/ (* place 100.0) total-count)]
   (condp = mode
 :high (int (Math/ceil  percentage))
 :low  (int (Math/floor percentage))
 :normal   (int (Math/round percentage))
 (throw (Exception. ERROR: get-percentage [:high|:low|:normal]
 PLACE TOTAL_COUNT))

 Is this a good version, or could it be done better?

 --
 Cecil Westerhof

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

Inconsistency in overflow handling between type-hinted and reflective calls

[Michael Blume]

(import 'java.io.DataOutputStream)
(import 'java.io.ByteArrayOutputStream)

(defn- -bytes
  Convert a Java primitive to its byte representation.
  [write v]
  (let [output-stream (ByteArrayOutputStream.)
data-output (DataOutputStream. output-stream)]
(write data-output v)
(seq (.toByteArray output-stream

(defn int-bytes [n]
  (-bytes
#(.writeInt ^DataOutputStream %1 %2)
n))

(defn int-bytes-ref [n]
  (-bytes
#(.writeInt %1 %2)
n))

user= (int-bytes 5)
(0 0 0 5)
user= (int-bytes-ref 5)
(0 0 0 5)
user= (int-bytes (inc Integer/MAX_VALUE))

IllegalArgumentException Value out of range for int: 2147483648
 clojure.lang.RT.intCast (RT.java:1115)
user= (int-bytes-ref (inc Integer/MAX_VALUE))
(-128 0 0 0)

So it looks like type-hinting the DataOutputStream results in bytecode
calling RT.intCast, which throws because the value is too large. In the
reflective case, we locate the method writeInt at runtime, and then do not
call RT.intCast, but instead allow the long to be downcast without bounds
checking.

It seems like we should be calling RT.intCast in both cases?

-- 
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: print-table bug?

[Michael Blume]

Difference looks like so:

https://github.com/MichaelBlume/clojure/compare/pr-str-table


On Mon Feb 02 2015 at 12:49:42 PM Steve Miner stevemi...@gmail.com wrote:

 Looks like a bug in clojure.pprint/print-table.  Probably should be use
 `pr-str` instead of `str`.

 user= (str ())
 clojure.lang.PersistentList$EmptyList@1
 user= (pr-str ())
 ()



  On Feb 2, 2015, at 3:10 PM, John Lawrence Aspden aspd...@googlemail.com
 wrote:
 
  These behave differently in 1.6 with respect to printing the empty list:
 
  (clojure.pprint/print-table (list {:a 1  :b 2 :c '()}))
  | :a | :b |  :c |
  |++-|
  |  1 |  2 | clojure.lang.PersistentList$EmptyList@1 |
 
  (clojure.pprint/pprint {:a 1  :b 2 :c '()})
  {:a 1, :b 2, :c ()}
 
  Is this a bug?
 
  I think I prefer the behaviour of the second one .
 
  Cheers, John.

 --
 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: call superclass constructor in clojure class generation with defrecord

[Michael Blume]

Yes, but that's for methods you're overriding and OP wants a constructor

On Sun, Feb 1, 2015, 12:22 AM Fluid Dynamics a2093...@trbvm.com wrote:

 On Saturday, January 31, 2015 at 6:34:10 PM UTC-5, Michael Blume wrote:

 The defn wrapping the call to proxy basically is the constructor, so you
 wind up with something roughly like

 (defn get-window []
   (let [this (proxy [Window] [My Window!]
   ; any methods you want to override on Window go here
   )
 ; stuff making panels goes here
  ]
 (.addComponent this horizontal-panel)
 this))

 Note, I'm calling a variable 'this' but it's *just a variable, the only
 reason I called it 'this' was to make it look more like the java version.


 Did either of the last two posters read the docs for proxy? :)

 https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/proxy

 ... Each method fn takes an additional implicit first arg, which is bound
 to 'this.

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: call superclass constructor in clojure class generation with defrecord

[Michael Blume]

The defn wrapping the call to proxy basically is the constructor, so you
wind up with something roughly like

(defn get-window []
  (let [this (proxy [Window] [My Window!]
  ; any methods you want to override on Window go here
  )
; stuff making panels goes here
 ]
(.addComponent this horizontal-panel)
this))

Note, I'm calling a variable 'this' but it's *just a variable, the only
reason I called it 'this' was to make it look more like the java version.

On Sat Jan 31 2015 at 9:53:30 AM coco clasesparticulares...@gmail.com
wrote:

 thanks Michael this does the job...in this code, now I've other doubt

 public class MyWindow extends Window
 {


 public MyWindow()  // --- not clear where I need declare it
 {
 super(My Window!);
 Panel horizontalPanel = new Panel(new Border.Invisible(), 
 Panel.Orientation.HORIZONTAL);
 Panel leftPanel = new Panel(new Border.Bevel(true), 
 Panel.Orientation.VERTICAL);
 Panel middlePanel = new Panel(new Border.Bevel(true), 
 Panel.Orientation.VERTICAL);
 Panel rightPanel = new Panel(new Border.Bevel(true), 
 Panel.Orientation.VERTICAL);

 horizontalPanel.addComponent(leftPanel);
 horizontalPanel.addComponent(middlePanel);
 horizontalPanel.addComponent(rightPanel);

 addComponent(horizontalPanel); // this is a confusing part too
 }
 }



 in this code addComponent(horizontalPanel)  is basically something like
 this.addComponent(horizontalPanel)

 does clojure have the this reference??...how can I call the
 constuctor...I'm thinkingin something like this

   (defn MyWindow []
   (proxy [Window] [My windows!!]
 (MyWindow [] (. this addComponent (Label. Bang!!) 

 is it wrong no? :D

 thanks!!!

 El viernes, 30 de enero de 2015, 18:47:48 (UTC-4:30), Michael Blume
 escribió:

 (defn my-window []
   (proxy [Window] []))

 should do the trick

 Proxy takes a vector of implemented interfaces and at most one superclass
 (in your case, Window), and then a second vector of arguments to pass to
 the superclass constructor (in your case, an empty vector) and then a
 series of methods implemented/overridden on the parent class/interfaces --
 in your case there's none of those.

 My understanding is that proxy is not quite as performant as
 reify/defrecord, but it's the only game in town if you actually want to
 subclass something.

 Hope this helps =)

 On Fri Jan 30 2015 at 3:05:11 PM coco clasespart...@gmail.com wrote:

 Hi everybody, I need implement this java code in clojure

  public class MyWindow extends Window
  {
 public MyWindow()
  {
   super(My Window!);
  }
 }

 MyWindow myWindow = new MyWindow();


 unfortunately the clojure documentation for generate classes is not so
 complete or straightforward for my understand...must I use gen-class or can
 I use defrecord for this task?...how can I call super class
 constructors??...

 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 this group and stop receiving emails from it, send an
 email to clojure+u...@googlegroups.com.


 For more options, visit https://groups.google.com/d/optout.

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email

Re: call superclass constructor in clojure class generation with defrecord

[Michael Blume]

(defn my-window []
  (proxy [Window] []))

should do the trick

Proxy takes a vector of implemented interfaces and at most one superclass
(in your case, Window), and then a second vector of arguments to pass to
the superclass constructor (in your case, an empty vector) and then a
series of methods implemented/overridden on the parent class/interfaces --
in your case there's none of those.

My understanding is that proxy is not quite as performant as
reify/defrecord, but it's the only game in town if you actually want to
subclass something.

Hope this helps =)

On Fri Jan 30 2015 at 3:05:11 PM coco clasesparticulares...@gmail.com
wrote:

 Hi everybody, I need implement this java code in clojure

  public class MyWindow extends Window
  {
 public MyWindow()
  {
   super(My Window!);
  }
 }

 MyWindow myWindow = new MyWindow();


 unfortunately the clojure documentation for generate classes is not so
 complete or straightforward for my understand...must I use gen-class or can
 I use defrecord for this task?...how can I call super class
 constructors??...

 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 receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vectorz, Unable to find implementation, uberjar, excluding source

[Michael Blume]

If you want to keep jar size down and avoid class loader problems, instead
of excluding source I'd avoid aot and only ship source. If you need the JVM
to find your main class you can write a shim and only aot-compile that.

On Wed Jan 21 2015 at 12:36:03 PM Brian Craft craft.br...@gmail.com wrote:

 Fixed it by adding :aot [mikera.vectorz.core] to the uberjar profile.


 On Wednesday, January 21, 2015 at 11:26:47 AM UTC-8, Brian Craft wrote:

 I'm excluding source when building uberjar, due to jar size and class
 loader problems at run time. However I now get Unable to find
 implementation :vectorz errors at run time. Is there some way to work
 around this?

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: aot resolve question

[Michael Blume]

Not sure what to tell you. If you can post code we can use to reproduce the
problem, that would help. Alternately, put some println statements into
load-sym so you can be sure it's getting the values you think it is?

On Tue Jan 20 2015 at 11:45:34 PM bob wee@gmail.com wrote:

 Hi,

 I have a function

 (defn load-sym
   [s]
   (require (symbol (namespace s)))
   (resolve s))


 There is no problem if not using the uberjar. when using the uberjar,

 (common/load-sym 'web/app-routes) // it can work


 {:route web/app-routes} //an edn file

 I read the edn file and put  the value of :route to the common/load-sym, it 
 return nil. quite wired, I have used this approach for many place, only one 
 has this problem.


 Thanks at advanced.



  --
 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: Satisfies? seems strangely slow

[Michael Blume]

It sounds like basically dispatch is fast because we bothered to make it
fast (by caching) and satisfies? is slow because we didn't. Is it worth
throwing caching at satisfies? to make it fast or should satisfies? just
not be on the critical path for Clojure code?

(To give a motivating example, satisfies? is on the critical path for
honeysql and will be until this pull is merged:
https://github.com/jkk/honeysql/pull/38)


On Thu Jan 22 2015 at 5:52:13 PM Ghadi Shayban gshay...@gmail.com wrote:

 Protocol call sites build an inline cache to optimize dispatch.  The
 benchmark is running many times and reaping benefit from the cache.
  satisfies? looks up the object's class in the protocol's implementation
 map [1], and the benchmark is stressing this.  You'll see that code checks
 if the protocol has the backing interface first, then checks for the
 object's class, then if necessary walks up the superclass chain.

 [1]
 https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_deftype.clj#L507-L516



 On Thursday, January 22, 2015 at 8:36:23 PM UTC-5, Michael Blume wrote:

 Extends seems to be defeated by superclassing. ie:

 (extends? my-protocol (class {})) = false

 because my-protocol is extended to IPersistentMap and (class {}) isn't
 IPersistentMap it's PersistentArrayMap (which implements IPersistentMap but
 extends? doesn't care)

 On Thu Jan 22 2015 at 5:28:30 PM Timothy Baldridge tbald...@gmail.com
 wrote:

 The logic of extends? is much simpler, so try that. IIRC it's something
 like extends? returns true if any method on the protocol is implemented by
 x, satisfies? returns true if all methods of a protocol are implemented
 by x.

 The docs don't seem to give much help here, so play with it in the repl
 a bit.

 Timothy

 On Thu, Jan 22, 2015 at 6:14 PM, Michael Blume blume...@gmail.com
 wrote:

 (defprotocol my-protocol
   (foo [this]))

 (extend-protocol my-protocol
   clojure.lang.IPersistentMap
   (foo [this] hello from map))

 (criterium.core/quick-bench
   (satisfies? my-protocol {}))

 (criterium.core/quick-bench
   (foo {}))

 Simply calling foo on an empty map takes 7 ns,
 but checking whether the map satisfies my-protocol takes 22 µs, 3000
 times longer.

 It seems like to call foo, some mechanism has to look up an
 implementation of my-protocol for maps -- how is it we can do that so
 quickly for a call and so slowly for satisfies?

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




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

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.

 To post to this group, send email to clo...@googlegroups.com


 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to

 clojure+u...@googlegroups.com


 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.

 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+u...@googlegroups.com.


 For more options, visit https://groups.google.com/d/optout.

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr

Re: Satisfies? seems strangely slow

[Michael Blume]

Wait isn't this caching?
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_deftype.clj#L480

On Thu Jan 22 2015 at 8:44:09 PM Bobby Eickhoff beickh...@gmail.com wrote:

 Clojure isn't doing the caching.  The JVM is doing the caching.  In this
 case, Clojure just has mechanical sympathy for how the JVM operates.


 On Thursday, January 22, 2015 at 11:10:56 PM UTC-5, Michael Blume wrote:

 It sounds like basically dispatch is fast because we bothered to make it
 fast (by caching) and satisfies? is slow because we didn't. Is it worth
 throwing caching at satisfies? to make it fast or should satisfies? just
 not be on the critical path for Clojure code?

 (To give a motivating example, satisfies? is on the critical path for
 honeysql and will be until this pull is merged: https://github.com/
 jkk/honeysql/pull/38)


 On Thu Jan 22 2015 at 5:52:13 PM Ghadi Shayban gsha...@gmail.com wrote:

 Protocol call sites build an inline cache to optimize dispatch.  The
 benchmark is running many times and reaping benefit from the cache.
  satisfies? looks up the object's class in the protocol's implementation
 map [1], and the benchmark is stressing this.  You'll see that code checks
 if the protocol has the backing interface first, then checks for the
 object's class, then if necessary walks up the superclass chain.

 [1] https://github.com/clojure/clojure/blob/master/
 src/clj/clojure/core_deftype.clj#L507-L516



 On Thursday, January 22, 2015 at 8:36:23 PM UTC-5, Michael Blume wrote:

 Extends seems to be defeated by superclassing. ie:

 (extends? my-protocol (class {})) = false

 because my-protocol is extended to IPersistentMap and (class {}) isn't
 IPersistentMap it's PersistentArrayMap (which implements IPersistentMap but
 extends? doesn't care)

 On Thu Jan 22 2015 at 5:28:30 PM Timothy Baldridge tbald...@gmail.com
 wrote:

 The logic of extends? is much simpler, so try that. IIRC it's something
 like extends? returns true if any method on the protocol is implemented 
 by
 x, satisfies? returns true if all methods of a protocol are implemented
 by x.

 The docs don't seem to give much help here, so play with it in the
 repl a bit.

 Timothy

 On Thu, Jan 22, 2015 at 6:14 PM, Michael Blume blume...@gmail.com
 wrote:

 (defprotocol my-protocol
   (foo [this]))

 (extend-protocol my-protocol
   clojure.lang.IPersistentMap
   (foo [this] hello from map))

 (criterium.core/quick-bench
   (satisfies? my-protocol {}))

 (criterium.core/quick-bench
   (foo {}))

 Simply calling foo on an empty map takes 7 ns,
 but checking whether the map satisfies my-protocol takes 22 µs, 3000
 times longer.

 It seems like to call foo, some mechanism has to look up an
 implementation of my-protocol for maps -- how is it we can do that so
 quickly for a call and so slowly for satisfies?

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




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

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.

 To post to this group, send email to clo...@googlegroups.com


 Note that posts from new members are moderated - please be patient
 with your first post.
 To unsubscribe from this group, send email to

 clojure+u...@googlegroups.com


 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.

 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.


 For more options, visit https://groups.google.com/d/optout.

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u

Re: Testing macros that throw errors at compile time?

[Michael Blume]

macroexpand-1 is a good start, I'd also recommend using the (is (thrown?
...)) special form, so

(is (thrown? IllegalArgumentException (macroexpend-1 '(my-macro
(ill-formed-arguments ...)

On Thu Jan 22 2015 at 5:05:36 PM Ben Wolfson wolf...@gmail.com wrote:

 (try (macroexpand-1 '(my-macro (ill-formed-arguments ...)))
   false ;; shouldn't get here
   (catch Exception _ true)) ;; whole expression should be true

 As long as you know that the *right* exception is being thrown.

 On Thu, Jan 22, 2015 at 4:41 PM, Scott Rabin scottra...@gmail.com wrote:

 We have a few macros in my employer's codebase that throw compile-time
 errors when you've given them invalid configurations, and have generally
 simply tested the result of these macros and not necessarily the direct
 expansion of said macros. What we would like to do is *test* that the
 macro blows up; but unfortunately, since this happens before tests are run,
 the result is that the compiler just complains at you instead of telling
 you that a specific test failed.

 Is there a decent way to test for thrown exceptions from macros other
 than writing a few cases and saying well, if the tests didn't even run,
 it's not right!?

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




 --
 Ben Wolfson
 Human kind has used its intelligence to vary the flavour of drinks, which
 may be sweet, aromatic, fermented or spirit-based. ... Family and social
 life also offer numerous other occasions to consume drinks for pleasure.
 [Larousse, Drink entry]

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

Satisfies? seems strangely slow

[Michael Blume]

(defprotocol my-protocol
  (foo [this]))

(extend-protocol my-protocol
  clojure.lang.IPersistentMap
  (foo [this] hello from map))

(criterium.core/quick-bench
  (satisfies? my-protocol {}))

(criterium.core/quick-bench
  (foo {}))

Simply calling foo on an empty map takes 7 ns,
but checking whether the map satisfies my-protocol takes 22 µs, 3000 times
longer.

It seems like to call foo, some mechanism has to look up an implementation
of my-protocol for maps -- how is it we can do that so quickly for a call
and so slowly for satisfies?

-- 
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: Satisfies? seems strangely slow

[Michael Blume]

Extends seems to be defeated by superclassing. ie:

(extends? my-protocol (class {})) = false

because my-protocol is extended to IPersistentMap and (class {}) isn't
IPersistentMap it's PersistentArrayMap (which implements IPersistentMap but
extends? doesn't care)

On Thu Jan 22 2015 at 5:28:30 PM Timothy Baldridge tbaldri...@gmail.com
wrote:

 The logic of extends? is much simpler, so try that. IIRC it's something
 like extends? returns true if any method on the protocol is implemented by
 x, satisfies? returns true if all methods of a protocol are implemented
 by x.

 The docs don't seem to give much help here, so play with it in the repl a
 bit.

 Timothy

 On Thu, Jan 22, 2015 at 6:14 PM, Michael Blume blume.m...@gmail.com
 wrote:

 (defprotocol my-protocol
   (foo [this]))

 (extend-protocol my-protocol
   clojure.lang.IPersistentMap
   (foo [this] hello from map))

 (criterium.core/quick-bench
   (satisfies? my-protocol {}))

 (criterium.core/quick-bench
   (foo {}))

 Simply calling foo on an empty map takes 7 ns,
 but checking whether the map satisfies my-protocol takes 22 µs, 3000
 times longer.

 It seems like to call foo, some mechanism has to look up an
 implementation of my-protocol for maps -- how is it we can do that so
 quickly for a call and so slowly for satisfies?

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




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

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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] clojure.jdbc 0.4.0-beta1: A jdbc library for clojure.

[Michael Blume]

I'm a little confused, by last major release do you mean the most recent
major release or do you mean clojure.jdbc is about to move into maintenance
mode?

On Sun Jan 11 2015 at 3:02:51 AM Andrey Antukh n...@niwi.be wrote:

 Hello!

 I wanted to announce the last major release of clojure.jdbc, a jdbc
 library for clojure.

 This release is focused mainly to simplify the code and use more clojure
 constructions
 like `with-open` macros instead of ad-hoc self defined macros.

 This release also, has some breaking changes related mainly to lazy
 queries. Now are much simple, and implemented without macros.

 You can find the complete changelog here:
 https://github.com/niwibe/clojure.jdbc/blob/master/CHANGES.adoc#version-040-beta1

 Github project: https://github.com/niwibe/clojure.jdbc
 Documentation: http://niwibe.github.io/clojure.jdbc/latest/

 Cheers.
 Andrey
 --
 Andrey Antukh - Андрей Антух - andrei.anto...@kaleidos.net / 
 n...@niwi.be
 http://www.niwi.be http://www.niwi.be/page/about/
 https://github.com/niwibe

 --
 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: Extend causes error in servlet container?

[Michael Blume]

TL;DR: If you wait for that lein-ring pull to get merged, you can upgrade
lein-ring and your problem will go away. If you wait for Clojure 1.7.0 it's
possible your problem will go away, though I'm less confident here (the
current alpha doesn't have a fix). If you want your problem to go away
*right now* then you want your ring handler listed in your project.clj to
be in a namespace that *doesn't import any of the rest of your project*.
That's what
https://github.com/MichaelBlume/extend-test/blob/6a676e6e326a91a1003e76b219b94a2664175587/src/extend_test/core/shim.clj
does. It has an initialize! function which, at run-time, rather than at
compile-time, manually imports your real handler and sticks it in an atom.
Then the handler exposed to ring just reads the real handler out of the
atom and applies it to the incoming request.


On Tue Jan 06 2015 at 1:24:40 PM Michael Blume blume.m...@gmail.com wrote:

 lein-ring uses AOT compilation to build war files. AOT compilation in
 clojure is, well, problematic sometimes. Fortunately it can almost always
 be avoided using clever indirection.

 For example: https://github.com/pdenhaan/extend-test/pull/1 builds a war
 that works =)

 I've got a pull open against lein-ring that will use this trick by default
 and avoid AOT in war builds, I'm hoping it'll get merged/released soon.

 There's a couple open bugs in Clojure right now to do with AOT that have
 patches that should land in 1.7.0. It's possible one of them will solve
 your problem, I'm poking at them now to check.


 On Tue Jan 06 2015 at 8:08:41 AM peter.denh...@qficonsulting.com wrote:

 I'm a relative newcomer to Clojure, and I'm puzzled by problems I have
 using extend in a webapp. Any help would be hugely appreciated.

 My use case is basically this:

 (defrecord FooRecord [msg])


 (defprotocol FooProtocol
   (bar [foo] to use with extend-type))


 (extend FooRecord
   FooProtocol
   {:bar (fn [foo] (str Test  (:msg foo)))})

 I'm calling bar on a newly created FooRecord:

 (bar (-FooRecord Successful))

 This works in a REPL, and also works great in a web application on ring
 server-headless:

 Test Successful


 But the moment I package the code in a war and deploy to Jetty 8 or
 Tomcat 7, it fails:

 java.lang.IllegalArgumentException: No implementation of method:
 :bar of protocol: #'extend-test.core.handler/FooProtocol found for
 class: extend_test.core.handler.FooRecord
 clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
 extend_test.core.handler$eval44$fn__45$G__35__50.invoke(hand
 ler.clj:8)
 extend_test.core.handler$fn__65.invoke(handler.clj:16)
 compojure.core$make_route$fn__1431.invoke(core.clj:104)
 ...


 I searched this group and the web for clues. It smells of a
 classloading/aliasing problem, but I could not find any information to
 indicate that this behaviour is expected when deploying to a servlet
 container, or what I can do about it apart from avoid using extend.

 If you'd like to check out the full code or run it yourself, I've
 created a Github project with a minimal test case
 https://github.com/pdenhaan/extend-test.

 The problem has me altogether stumped for the moment. Thanks for reading.

 --
 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: Extend causes error in servlet container?

[Michael Blume]

lein-ring uses AOT compilation to build war files. AOT compilation in
clojure is, well, problematic sometimes. Fortunately it can almost always
be avoided using clever indirection.

For example: https://github.com/pdenhaan/extend-test/pull/1 builds a war
that works =)

I've got a pull open against lein-ring that will use this trick by default
and avoid AOT in war builds, I'm hoping it'll get merged/released soon.

There's a couple open bugs in Clojure right now to do with AOT that have
patches that should land in 1.7.0. It's possible one of them will solve
your problem, I'm poking at them now to check.


On Tue Jan 06 2015 at 8:08:41 AM peter.denh...@qficonsulting.com wrote:

 I'm a relative newcomer to Clojure, and I'm puzzled by problems I have
 using extend in a webapp. Any help would be hugely appreciated.

 My use case is basically this:

 (defrecord FooRecord [msg])


 (defprotocol FooProtocol
   (bar [foo] to use with extend-type))


 (extend FooRecord
   FooProtocol
   {:bar (fn [foo] (str Test  (:msg foo)))})

 I'm calling bar on a newly created FooRecord:

 (bar (-FooRecord Successful))

 This works in a REPL, and also works great in a web application on ring
 server-headless:

 Test Successful


 But the moment I package the code in a war and deploy to Jetty 8 or Tomcat
 7, it fails:

 java.lang.IllegalArgumentException: No implementation of method: :bar
 of protocol: #'extend-test.core.handler/FooProtocol found for class:
 extend_test.core.handler.FooRecord
 clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
 extend_test.core.handler$eval44$fn__45$G__35__50.invoke(
 handler.clj:8)
 extend_test.core.handler$fn__65.invoke(handler.clj:16)
 compojure.core$make_route$fn__1431.invoke(core.clj:104)
 ...


 I searched this group and the web for clues. It smells of a
 classloading/aliasing problem, but I could not find any information to
 indicate that this behaviour is expected when deploying to a servlet
 container, or what I can do about it apart from avoid using extend.

 If you'd like to check out the full code or run it yourself, I've created
 a Github project with a minimal test case
 https://github.com/pdenhaan/extend-test.

 The problem has me altogether stumped for the moment. Thanks for reading.

 --
 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: Extend causes error in servlet container?

[Michael Blume]

On further investigation, it looks like you're suffering from
http://dev.clojure.org/jira/browse/CLJ-979 -- if I apply the patch for this
bug to clojure and recompile your project everything works fine. It looks
like this patch *is* slated to make it into Clojure 1.7.0, so that should
also make your problem go away.

On Tue Jan 06 2015 at 1:29:39 PM Michael Blume blume.m...@gmail.com wrote:

 TL;DR: If you wait for that lein-ring pull to get merged, you can upgrade
 lein-ring and your problem will go away. If you wait for Clojure 1.7.0 it's
 possible your problem will go away, though I'm less confident here (the
 current alpha doesn't have a fix). If you want your problem to go away
 *right now* then you want your ring handler listed in your project.clj to
 be in a namespace that *doesn't import any of the rest of your project*.
 That's what
 https://github.com/MichaelBlume/extend-test/blob/6a676e6e326a91a1003e76b219b94a2664175587/src/extend_test/core/shim.clj
 does. It has an initialize! function which, at run-time, rather than at
 compile-time, manually imports your real handler and sticks it in an atom.
 Then the handler exposed to ring just reads the real handler out of the
 atom and applies it to the incoming request.


 On Tue Jan 06 2015 at 1:24:40 PM Michael Blume blume.m...@gmail.com
 wrote:

 lein-ring uses AOT compilation to build war files. AOT compilation in
 clojure is, well, problematic sometimes. Fortunately it can almost always
 be avoided using clever indirection.

 For example: https://github.com/pdenhaan/extend-test/pull/1 builds a war
 that works =)

 I've got a pull open against lein-ring that will use this trick by
 default and avoid AOT in war builds, I'm hoping it'll get merged/released
 soon.

 There's a couple open bugs in Clojure right now to do with AOT that have
 patches that should land in 1.7.0. It's possible one of them will solve
 your problem, I'm poking at them now to check.


 On Tue Jan 06 2015 at 8:08:41 AM peter.denh...@qficonsulting.com wrote:

 I'm a relative newcomer to Clojure, and I'm puzzled by problems I have
 using extend in a webapp. Any help would be hugely appreciated.

 My use case is basically this:

 (defrecord FooRecord [msg])


 (defprotocol FooProtocol
   (bar [foo] to use with extend-type))


 (extend FooRecord
   FooProtocol
   {:bar (fn [foo] (str Test  (:msg foo)))})

 I'm calling bar on a newly created FooRecord:

 (bar (-FooRecord Successful))

 This works in a REPL, and also works great in a web application on ring
 server-headless:

 Test Successful


 But the moment I package the code in a war and deploy to Jetty 8 or
 Tomcat 7, it fails:

 java.lang.IllegalArgumentException: No implementation of method:
 :bar of protocol: #'extend-test.core.handler/FooProtocol found for
 class: extend_test.core.handler.FooRecord
 clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
 extend_test.core.handler$eval44$fn__45$G__35__50.invoke(hand
 ler.clj:8)
 extend_test.core.handler$fn__65.invoke(handler.clj:16)
 compojure.core$make_route$fn__1431.invoke(core.clj:104)
 ...


 I searched this group and the web for clues. It smells of a
 classloading/aliasing problem, but I could not find any information to
 indicate that this behaviour is expected when deploying to a servlet
 container, or what I can do about it apart from avoid using extend.

 If you'd like to check out the full code or run it yourself, I've
 created a Github project with a minimal test case
 https://github.com/pdenhaan/extend-test.

 The problem has me altogether stumped for the moment. Thanks for reading.

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

Re: lein uberjar not creating class files with :aot

[Michael Blume]

(in the clojure.java.jdbc namespace, I should have said)

On Sat Jan 03 2015 at 12:43:31 PM Michael Blume blume.m...@gmail.com
wrote:

 it's hard to say exactly what's going on without tinkering with your
 project, but Connectable is found in the clojure.java.jdbc, so I'd make
 absolutely sure that namespace has been required before Connectable is
 referred to. And then, well, if it were me, I'd just ditch AOT. In my
 experience it causes more problems than it solves.

 On Sat Jan 03 2015 at 11:39:35 AM Shoeb Bhinderwala shua...@gmail.com
 wrote:

 When I create a uberjar with aot compilation I am surprised to see .clj
 files in there. Then when I run the jar with the java -jar myuberjar
 command I get a ClassNotFoundException.

 For example, I am have the following dependency in my project.clj file:

  [org.clojure/java.jdbc 0.3.6]

 However, when running the uberjar I see the following exception

java.lang.ClassNotFoundException: clojure.java.jdbc.Connectable

 Inside the uberjar when I traverse to the location \clojure\java\jdbc I
 see only one file jdbc.clj and no .class files? I don't see the
 Connectable.class file there.  I am expecting to see the .class files here
 as I am specifying :aot :all in my project.clj file:

   :profiles
 {:dev   {:resource-paths [config_dev]}
  :stage {:resource-paths [config_stage]}
  :prod  {:resource-paths [config_prod]}
*  :uberjar {:aot :all}})*

 Have spent many hours hair pulling but not able to figure out how to
 solve this problem.

 Many thanks for your help.
 Regards,
 Shoeb

 Leiningen version 2.5.0
 Java version 1.7
 Issue is on both Windows 7 and Linux.

  --
 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: lein uberjar not creating class files with :aot

[Michael Blume]

it's hard to say exactly what's going on without tinkering with your
project, but Connectable is found in the clojure.java.jdbc, so I'd make
absolutely sure that namespace has been required before Connectable is
referred to. And then, well, if it were me, I'd just ditch AOT. In my
experience it causes more problems than it solves.

On Sat Jan 03 2015 at 11:39:35 AM Shoeb Bhinderwala shua...@gmail.com
wrote:

 When I create a uberjar with aot compilation I am surprised to see .clj
 files in there. Then when I run the jar with the java -jar myuberjar
 command I get a ClassNotFoundException.

 For example, I am have the following dependency in my project.clj file:

  [org.clojure/java.jdbc 0.3.6]

 However, when running the uberjar I see the following exception

java.lang.ClassNotFoundException: clojure.java.jdbc.Connectable

 Inside the uberjar when I traverse to the location \clojure\java\jdbc I
 see only one file jdbc.clj and no .class files? I don't see the
 Connectable.class file there.  I am expecting to see the .class files here
 as I am specifying :aot :all in my project.clj file:

   :profiles
 {:dev   {:resource-paths [config_dev]}
  :stage {:resource-paths [config_stage]}
  :prod  {:resource-paths [config_prod]}
*  :uberjar {:aot :all}})*

 Have spent many hours hair pulling but not able to figure out how to solve
 this problem.

 Many thanks for your help.
 Regards,
 Shoeb

 Leiningen version 2.5.0
 Java version 1.7
 Issue is on both Windows 7 and Linux.

  --
 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: How to handle fn args in a macro ?

[Michael Blume]

Sorry, that should be

(defmacro listen
  [[topic-sym topic-name]  body]
  `(on-message ~topic-name
 (fn [~topic-sym] (~@body)

On Thu Jan 01 2015 at 11:01:53 PM Michael Blume blume.m...@gmail.com
wrote:

 If it were me I'd avoid making 'topic a magic symbol and let the user
 choose a symbol to bind. It'd look something like

 (defmacro listen
   [[topic-sym topic-name]  body]
   `(on-message ~topicname
  (fn [~topic-name] (~@body)

 (listen [topic topic-test] (println topic test))

 this way it's relatively clear to the reader what the symbol is bound to
 and where.


 On Wed Dec 31 2014 at 1:41:41 PM Tobias Kortkamp 
 tobias.kortk...@gmail.com wrote:


 On 12/31/2014 18:56, rogergl wrote:
  To make this work I had to replace the symbol 'topic in the body with
  the gensym symbol. Is this the right way to do this ?

 Your macro is too complicated. You don't need to gensym a symbol in this
 case. Instead just quote a symbol before unquoting it (note the ~'), so
 that it appears as is in the resulting form:

   (defmacro listen
 [topic expression]
 `(on-message ~topic (fn [~'topic] ~expression)))

 Your example then expands to

   (on-message topic-test (fn [topic] (println topic test)))







 --
 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: How to handle fn args in a macro ?

[Michael Blume]

If it were me I'd avoid making 'topic a magic symbol and let the user
choose a symbol to bind. It'd look something like

(defmacro listen
  [[topic-sym topic-name]  body]
  `(on-message ~topicname
 (fn [~topic-name] (~@body)

(listen [topic topic-test] (println topic test))

this way it's relatively clear to the reader what the symbol is bound to
and where.


On Wed Dec 31 2014 at 1:41:41 PM Tobias Kortkamp tobias.kortk...@gmail.com
wrote:


 On 12/31/2014 18:56, rogergl wrote:
  To make this work I had to replace the symbol 'topic in the body with
  the gensym symbol. Is this the right way to do this ?

 Your macro is too complicated. You don't need to gensym a symbol in this
 case. Instead just quote a symbol before unquoting it (note the ~'), so
 that it appears as is in the resulting form:

   (defmacro listen
 [topic expression]
 `(on-message ~topic (fn [~'topic] ~expression)))

 Your example then expands to

   (on-message topic-test (fn [topic] (println topic test)))







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

:keys and :or destructuring where defaults refer to one another

[Michael Blume]

If I make my defaults on a :keys :or destructuring depend on the values of
other keys, I *can* get a compile-time error, depending on what order I
give the keys https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727

Is this on-spec behavior? Should the former be allowed but not the latter?
Should both be allowed? Should neither?

-- 
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: :keys and :or destructuring where defaults refer to one another

[Michael Blume]

Yep, I spent some time playing with the macro and the macroexpand. It looks
like

a) it only works if the dependent keys come *before* the keys they depend
on (ie the opposite of how you'd order, say, defs)

b) this ordering arises entirely from the seq ordering of
PersistentArrayMap (keys are stuck into the map here
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L4083
and taken out again here
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L4090
)

The latter makes it pretty clear that this is accidental behavior and, as
you say, shouldn't be relied on -- in particular, if you have more than
about 8 keys, you spill over to a PersistentHashMap and get everything in a
random order and it almost certainly fails.

The trouble is this behavior is already used by ring-middleware-format,
which then fails to compile if clojure uses a different implementation for
small maps.

I'm wondering if given the brittleness of this behavior we should make sure
it can't be used in future versions of clojure.

On Thu Dec 11 2014 at 6:56:22 PM adrian.med...@mail.yu.edu wrote:

 Whenever you want to get insight in how a macro is rewriting your code,
 try evaluating your form quoted with macroexpand.

 Here's a gist with the macroexpansion each form.

 https://gist.github.com/aamedina/542b084d31d4e0c9a7a8

 Hopefully the expansion makes things clear!

 On Thursday, December 11, 2014 6:11:59 PM UTC-5, Michael Blume wrote:

 If I make my defaults on a :keys :or destructuring depend on the values
 of other keys, I *can* get a compile-time error, depending on what order I
 give the keys https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727

 Is this on-spec behavior? Should the former be allowed but not the
 latter? Should both be allowed? Should neither?

  --
 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: Wouldn't it be nice if if-let allowed more bindings?

[Michael Blume]

Instead of the deshadowing logic, why not

(defn if-and-let*
  [bindings then-clause else-fn-name]
  (if (empty? bindings)
then-clause
`(if-let ~(vec (take 2 bindings))
   ~(if-and-let* (drop 2 bindings) then-clause else-fn-name)
   (~else-fn-name

(defmacro if-and-let
  [bindings then-clause else-clause]
  (let [efname (gensym)]
`(let [~efname (fn [] ~else-clause)]
   ~(if-and-let* bindings then-clause efname


On Wed Nov 26 2014 at 4:11:00 AM Fluid Dynamics a2093...@trbvm.com wrote:

 Wouldn't it be nice if if-let allowed more bindings?

 Try this, which I hereby dedicate into the public domain so that anyone
 may use it freely in their code without restrictions:

 (defn if-and-let*
   [bindings then-clause else-clause deshadower]
   (if (empty? bindings)
 then-clause
 `(if-let ~(vec (take 2 bindings))
~(if-and-let* (drop 2 bindings) then-clause else-clause deshadower)
(let ~(vec (apply concat deshadower))
  ~else-clause

 (defmacro if-and-let
   Like if-let, but with multiple bindings allowed. If all of the
 expressions in
the bindings evaluate truthy, the then-clause is executed with all of
 the
bindings in effect. If any of the expressions evaluates falsey,
 evaluation of
the remaining binding exprs is not done, and the else-clause is
 executed with
none of the bindings in effect. If else-clause is omitted, evaluates to
 nil
if any of the binding expressions evaluates falsey.

As with normal let bindings, each binding is available in the subsequent
bindings. (if-and-let [a (get my-map :thing) b (do-thing-with a)] ...)
 is
legal, and will not throw a null pointer exception if my-map lacks a
 :thing
key and (do-thing-with nil) would throw an NPE.

If there's something you want to be part of the then-clause's
 condition, but
whose value you don't care about, including a binding of it to _ is more
compact than nesting yet another if inside the then-clause.
   ([bindings then-clause]
 `(if-and-let ~bindings ~then-clause nil))
   ([bindings then-clause else-clause]
 (let [shadowed-syms (filter #(or ((or env {}) %) (resolve %))
   (filter symbol?
 (tree-seq coll? seq (take-nth 2 bindings
   deshadower (zipmap shadowed-syms (repeatedly gensym))]
   `(let ~(vec (apply concat (map (fn [[k v]] [v k]) deshadower)))
  ~(if-and-let* bindings then-clause else-clause deshadower)

 = (if-and-let [x (:a {:b 42}) y (first [(/ x 3)])] [x y] :nothing)
 :nothing
 = (if-and-let [x (:a {:a 42}) y (first [(/ x 3)])] [x y] :nothing)
 [42 14]
 = (if-and-let [x (:a {:a 42}) y (first [])] [x y] :nothing)
 :nothing

 Note that this is not quite as simple as the obvious naive implementation:

 (defmacro naive-if-and-let
   ([bindings then-clause]
 `(naive-if-and-let ~bindings ~then-clause nil))
   ([bindings then-clause else-clause]
 (if (empty? bindings)
   then-clause
   `(if-let ~(vec (take 2 bindings))
  (naive-if-and-let ~(vec (drop 2 bindings))
~then-clause
~else-clause)
  ~else-clause

 but what happens if a name used in the if-and-let is already bound in the
 enclosing context is instructive:

 = (let [x 6] (if-and-let [x (:a {:b 42}) y (first [(/ x 3)])] [x y] x))
 6
 = (let [x 6] (if-and-let [x (:a {:a 42}) y (first [])] [x y] x))
 6
 = (let [x 6] (naive-if-and-let [x (:a {:b 42}) y (first [(/ x 3)])] [x y]
 x))
 6
 = (let [x 6] (naive-if-and-let [x (:a {:a 42}) y (first [])] [x y] x))
 42

 As you can see, the x in the else clause in naive-if-and-let sometimes
 sees the x binding in the if-and-let (if that succeeded) and sometimes sees
 the enclosing binding (if not), when it should always refer to the
 enclosing (let [x 6] ...). The non-naive if-and-let discovers all local
 bindings that might be shadowed by walking the left hand sides of the new
 bindings and tree-walking the data structure there to extract symbols,
 which it filters further against env. It outputs an enclosing let that
 saves all of these to non-shadowed locals named with gensyms, and wraps
 every else clause emission in a let that restores the original bindings of
 these symbols from these gensym locals. The tree-walking makes it work even
 with destructuring its the binding vector:

 = (let [x 6] (if-and-let [{x :a} {:a 42} y (first [(/ x 3)])] [x y] x))
 [42 14]
 = (let [x 6] (if-and-let [{x :a} {:a 42} y (first [])] [x y] x))
 6

 It also unshadows defs:

 = (def x 6)
 = (if-and-let [{x :a} {:a 42} y (first [])] [x y] x)
 6

 That's from the (or ... (resolve %)) part of the outer filter on the
 walked tree. Remove that and leave the outer filter as just (filter (or
 env {}) ...), and that last test produces 42 instead.

 Not that you should really be shadowing defs with locals anyway. That's
 always prone to cause problems.

 Not bad for only 18 lines of actual code, hmm?

  --
 You 

Re: Get the value of the persistentArrayMap from the exception which was thrown

[Michael Blume]

Well, from the print of the exception, it looks unlikely, but let's look at 
the code. This stacktrace says the exception was thrown in line 429 of 
clojure.lang.AFn, and I'm going to assume you're using Clojure 1.6.0, so we 
want 
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/AFn.java#L429

Looking at that line of code, it's creating the exception object using only 
the arity (a number) and the name of the class of the object, a string. So 
no, the map is not recoverable from the exception.

On Wednesday, November 5, 2014 10:15:50 PM UTC-8, Sunil Nandihalli wrote:

 Hi Everybody,

 user= ({:a 1})

 ArityException Wrong number of args (0) passed to: PersistentArrayMap 
  clojure.lang.AFn.throwArity (AFn.java:429)
 user= *e
 #ArityException clojure.lang.ArityException: Wrong number of args (0) 
 passed to: PersistentArrayMap

 From *e is it possible to infer that the object which threw it was {:a 1}?

 Thanks,
 Sunil.


-- 
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] Clojure 1.7.0-alpha3 now available

[Michael Blume]

Picking up the variadic arguments discussion, it seems that in a simple 
definition like

(fn [ args] (apply f arg1 args))

One could conceivably put some sort of preprocessing smarts into the fn 
macro that notices that

a) this is a variadic arglist
b) the variadic arg (args) is a symbol, not some complicated destructuring 
expression
c) args is only ever used as the last argument to apply (maybe check this 
after thoroughly macroexpanding the function body)

and then autogenerates the various unrolled cases.

Even if we did only the simplest version of this, the new definition of 
partial would be

(defn partial
  Takes a function f and fewer than the normal arguments to f, and
  returns a fn that takes a variable number of additional args. When
  called, the returned function calls f with args + additional args.
  {:added 1.0
   :static true}
  ([f] f)
  ([f arg1]
   (fn [ args]
 (apply f arg1 args)))
  ([f arg1 arg2]
   (fn [ args]
 (apply f arg1 arg2 args)))
  ([f arg1 arg2 arg3]
   (fn [ args]
 (apply f arg1 arg2 arg3 args)))
  ([f arg1 arg2 arg3  more]
   (fn [ args] (apply f arg1 arg2 arg3 (concat more args)

which is shorter (and would be unrolled in more cases than it currently is)

The thing that concerns me is that such a preprocessing step would be 
treating 'clojure.core/apply as a magic token, when apply is supposed to be 
a function like any other. And sufficient smarts to make 'partial 
single-clause would probably require treating 'clojure.core/concat as a 
magic token as well.

On Sunday, October 26, 2014 8:43:23 PM UTC-7, Alex Miller wrote:

 Clojure 1.7.0-alpha3 is now available. 
  
 Try it via 
 - Download: 
 http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha3/
 - Download securely: 
 https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha3/
 - Leiningen: [org.clojure/clojure 1.7.0-alpha3]

 For users of Clojure 1.7.0-alpha2, there have been a few important changes 
 in features under development:

 Transducers:
 - iteration function renamed to eduction
 - Fixed several issues related to reduced values

 *unchecked-math* boxed math warnings:
 - warnings are now only emitted when (set! *unchecked-math* 
 :warn-on-boxed). for old behavior (no warnings), use (set! *unchecked-math* 
 true).

 For other changes new in alpha3, see the issues marked (alpha3) in the 
 changes below.

 
 Clojure 1.7.0-alpha3 has the changes below from 1.6.0:

 ## 1 New and Improved Features

 ### 1.1 Transducers

 Transducers is a new way to decouple algorithmic transformations from their
 application in different contexts. Transducers are functions that transform
 reducing functions to build up a recipe for transformation.

 Also see: http://clojure.org/transducers

 Many existing sequence functions now have a new arity (one fewer argument
 than before). This arity will return a transducer that represents the same
 logic but is independent of lazy sequence processing. Functions included 
 are:

 * conj (conjs to [])
 * map
 * mapcat
 * filter
 * remove
 * take
 * take-while
 * drop
 * drop-while
 * cycle
 * take-nth
 * replace
 * partition-by
 * partition-all
 * keep
 * keep-indexed

 Additionally some new transducer functions have been added:

 * cat - concatenates the contents of each input
 * de-dupe - removes consecutive duplicated values
 * random-sample - returns items from coll with random probability

 And this function can be used to make completing transforms:

 * completing

 There are also several new or modified functions that can be used to apply
 transducers in different ways:

 * sequence - takes a transformation and a coll and produces a lazy seq
 * transduce - reduce with a transformation (eager)
 * eduction - returns a reducible/seqable/iterable seq of applications of 
 the transducer to items in coll. Applications are re-performed with every 
 reduce/seq/iterator.
 * run! - run the transformation for side effects on the collection

 There have been a number of internal changes to support transducers:

 * volatiles - there are a new set of functions (volatile!, vswap!, 
 vreset!, volatile?) to create and use volatile boxes to hold state in 
 stateful transducers. Volatiles are faster than atoms but give up atomicity 
 guarantees so should only be used with thread isolation.
 * array iterators - added support for iterators over arrays

 Some related issues addressed during development:
 * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511)
 * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497)
 * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549) (alpha3)
 * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537) (alpha3)

 ### 1.2 Keyword and Symbol Construction

 In response to issues raised in [CLJ-1439](
 http://dev.clojure.org/jira/browse/CLJ-1439), several changes have been 
 made in symbol and keyword construction:

 1) The main bottleneck in construction of symbols (which 

Why is my function faster with eval?

[Michael Blume]

So I'm reading a bunch of rows from a huge csv file and marshalling those 
rows into maps using the first row as keys. I wrote the function two 
ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the 
version with eval is twice as fast and I'm kind of curious about why. 
Presumably the eval'd function still implicitly contains a list of keys, 
it's still implicitly treating each row as a seq and walking it, so I'm 
wondering what the seq-destructuring and the map literal are doing under 
the hood that's faster.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is my function faster with eval?

[Michael Blume]

https://github.com/MichaelBlume/eval-speed

eval-speed.core= (time-fn read-to-maps)
Elapsed time: 5551.011069 msecs
nil
eval-speed.core= (time-fn read-to-maps-fn)
Elapsed time: 5587.256991 msecs
nil
eval-speed.core= (time-fn read-to-maps-partial)
Elapsed time: 5606.649172 msecs
nil
eval-speed.core= (time-fn read-to-maps-eval)
Elapsed time: 2627.521592 msecs
nil

Ben, I'd still like to understand exactly what work the CPU is doing in the 
uneval'd version that it's skipping in the eval'd version. It seems like in 
the generated bytecode there's going to be *some* concept of iterating 
through the row in either case, if only as part of the destructuring 
process.


On Friday, October 10, 2014 1:07:08 PM UTC-7, Ben wrote:

 I believe it's because the `mapper` function is just creating and 
 returning a map literal. The mapper function in the evaled version is 
 something like this:

 user (def names '[n1 n2 n3 n4])
 #'user/names
 user (def headers '[h1 h2 h3 h4])
 #'user/headers
 user `(fn [[~@names]] ~(zipmap headers names))
 (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a 
 map literal, whose keys are already known.

 Whereas in the first version, zipmap has to be called, iterating over 
 headers and names each time.

 On Fri, Oct 10, 2014 at 1:04 PM, Sean Corfield se...@corfield.org 
 javascript: wrote:

 It may be more to do with the difference between `for` and `map`. How do 
 these versions compare in your benchmark:

 (defn read-to-maps-partial [rows]
   (let [headers (-
   rows
   first
   (take-while (complement #{}))
   (map keyword))]
 (map (partial zipmap headers) (rest rows

 (defn read-to-maps-fn [rows]
   (let [headers (-
   rows
   first
   (take-while (complement #{}))
   (map keyword))
 mapper (fn [row] (zipmap headers row))]
 (map mapper (rest rows

 Sean

 On Oct 10, 2014, at 11:42 AM, Michael Blume blume...@gmail.com 
 javascript: wrote:
  So I'm reading a bunch of rows from a huge csv file and marshalling 
 those rows into maps using the first row as keys. I wrote the function two 
 ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the 
 version with eval is twice as fast and I'm kind of curious about why. 
 Presumably the eval'd function still implicitly contains a list of keys, 
 it's still implicitly treating each row as a seq and walking it, so I'm 
 wondering what the seq-destructuring and the map literal are doing under 
 the hood that's faster.




 -- 
 Ben Wolfson
 Human kind has used its intelligence to vary the flavour of drinks, which 
 may be sweet, aromatic, fermented or spirit-based. ... Family and social 
 life also offer numerous other occasions to consume drinks for pleasure. 
 [Larousse, Drink entry]

  

-- 
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: Where can one find low hanging fruit for open source contribution?

[Michael Blume]

Agree with Michael Klishin, I've gotten a few patches into Leiningen as a 
relative Clojure newb and the maintainers have been super friendly and 
helpful.

On Friday, September 26, 2014 11:45:18 PM UTC-7, Michael Klishin wrote:

 On 27 September 2014 at 10:34:28, kurofune (jessel...@gmail.com 
 javascript:) wrote: 
  I am an looking for a good, active, open source Clojure library/project 
  to contribute to, but am not sure where to start. Could somebody 
  give an intermediate level programmer a few pointers as to where 
  to begin? 

 Leiningen has issues tagged newbie and its maintainers are some of the 
 nicest 
 people you'll find in open source: 

 https://github.com/technomancy/leiningen/labels/Newbie 

 Some (unfortunately, only a few to date) ClojureWerkz projects use a 
 similar 
 tag: 
 https://github.com/clojurewerkz/elastisch/labels/low-hanging%20fruit 

 Ultimately I'd recommend contributing to either what you can easily see 
 yourself 
 using or something that sounds really interesting. Leiningen is something 
 you will use if you use Clojure, which makes it a no-brainer. 
 -- 
 @michaelklishin, github.com/michaelklishin 


-- 
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: vim-fireplace debug workflow: modifying jars

[Michael Blume]

Don't worry about the jar, especially. You can have your own git checkout 
of the upstream project you're working with, and that'll work just fine. 
Open a source file you need to work with, connect with nrepl, edit a 
function, and eval -- that should be enough.

On Thursday, March 27, 2014 11:43:19 AM UTC-7, Brian Craft wrote:

 Describing my debug workflow woes at clojure/west, it was suggested to me 
 that I could jump into the jar file for a library and add print statements 
 to elucidate its inner workings. I guess this is supported in emacs? Jump 
 into the library source jar, edit, reload into the repl? How does this 
 work, exactly? Does it rewrite the zip file and load that to the repl, or 
 just update the repl from the working buffer?

 I just tried this in vim-fireplace, but it threw an error on writing to 
 the jar buffer. Alternatively, perhaps I should eval it w/o trying to save 
 the jar. That works so long as I then only evaluate expressions from the 
 same namespace. In other namespaces, the edits are not apparent. It's like 
 there are two versions of the namespace active in the repl. Not sure what's 
 going on, or how to make other namespaces aware of the changes.


-- 
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: Calling from a macro to a private macro

[Michael Blume]

You don't have the macro generate a call to the private function, you have 
the macro call the private function directly

replace:

(defmacro call-self* [x]
  `(~x ~x))

(defmacro call-self [x]
  `(do
(println calling form  ~(str x)  with itself)
(call-self ~x)))

with:

(defn- call-self* [x]
  `(~x ~x))

(defmacro call-self [x]
  `(do
(println calling form  ~(str x)  with itself)
~(call-self x)))

The function call-self* is still called at compile-time and is called *by 
the call-self macro*, not the generated client code. Make sense?


On Monday, March 17, 2014 10:31:36 AM UTC-7, Yoav Rubin wrote:

 I need to do it, as I need the arguments to remain not evaluated until 
 they get to that private macro. That private macro does some work on the 
 arguments before they get evaluated (the arguments themselves are 
 s-expressions).

 Still, even if it is a private function - how can I call it from a macro 
 that is called from another namespace?

 On Monday, March 17, 2014 4:19:19 PM UTC+2, James Reeves wrote:

 Don't use a private macro: use a function that spits out an s-expression.

 - James


 On 17 March 2014 06:02, Yoav Rubin yoav...@gmail.com wrote:

 Hi All,

 I have a namespace that has two macros as part of its public API, and 
 another macro that act as helpers for the public macro

 (defmacro helper-mac [arg1 arg2 f]
 ;; do stuff with f , arg1 and arg2
 )

 (defmacro m0 [arg1 arg2]
(priv-mac arg1 arg2 f1)
 )
  
 (defmacro m1 [arg1 arg2] (
   (priv-mac arg1 arg2 f2)
 )

 f1 and f2 are just two functions.

 I would like to make the helper macro private (using  ^:private), but 
 when I do it and call either m0 or m1 from another namespace, I get an 
 exception saying that helper-mac is private.

 Is it possible to call from to a macro in another namespace when that 
 macro is calling a private macro in its namespace?

 Thanks,

 Yoav

 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

deadlock when using clojure data structures at startup

[Michael Blume]

I work on a Java team, so our use of clojure is either

a) calling into clojure from java or
b) directly using the clojure data structures.

Recently we had an app fail because, as it was starting up, one thread was
trying to require a clojure namespace, and another was trying to use a
PersistentHashSet. Somehow these two threads wound up in deadlock. I've
reproduced the problem with minimal code here:

https://github.com/MichaelBlume/deadlock

Jstack output follows

Thread-0 prio=5 tid=0x7fa282077800 nid=0x5203 in Object.wait()
[0x00015dce4000]
   java.lang.Thread.State: RUNNABLE
at clojure.lang.Util.hasheq(Util.java:170)
at clojure.lang.PersistentHashMap.hash(PersistentHashMap.java:120)
 at clojure.lang.PersistentHashMap.assoc(PersistentHashMap.java:142)
at clojure.lang.PersistentHashSet.cons(PersistentHashSet.java:99)
 at clojure.lang.PersistentHashSet.create(PersistentHashSet.java:27)
at clojure.core__init.__init3(Unknown Source)
 at clojure.core__init.clinit(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
 at clojure.lang.RT.loadClassForName(RT.java:2098)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
 at clojure.lang.RT.doInit(RT.java:447)
at clojure.lang.RT.clinit(RT.java:329)
at deadlock.DeadLockMain$1.run(DeadLockMain.java:13)
 at java.lang.Thread.run(Thread.java:722)

main prio=5 tid=0x7fa282001000 nid=0x1703 in Object.wait()
[0x000103429000]
   java.lang.Thread.State: RUNNABLE
at clojure.lang.Numbers$BigDecimalOps.clinit(Numbers.java:824)
at clojure.lang.Numbers.clinit(Numbers.java:937)
 at clojure.lang.Util.hasheq(Util.java:170)
at clojure.lang.PersistentHashMap.hash(PersistentHashMap.java:120)
 at clojure.lang.PersistentHashMap.assoc(PersistentHashMap.java:142)
at clojure.lang.PersistentHashSet.cons(PersistentHashSet.java:99)
 at deadlock.DeadLockMain.main(DeadLockMain.java:17)


I've reproduced this behavior with clojure 1.4.0, 1.5.1, and 1.6.0-alpha3
(though the attached project uses 1.5.1, it should be trivial to change its
dependency)

Is this expected behavior? Is the take-away don't use clojure data
structures from java code? Make sure the clojure runtime is warm before
using clojure data structures?

-- 
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/groups/opt_out.

odd failure on recursive use of protocol member

[Michael Blume]

I have a protocol RestSerializable to represent data that can be serialized 
to json from a REST interface.

(defprotocol RestSerializable
  (rest-serialize [this]
   Convert to something Cheshire can JSONify))

By default, things are left alone

(extend Object
  RestSerializable
  {:rest-serialize identity})

But I want atoms and the like to be transparent when serialized

(extend clojure.lang.IDeref
  RestSerializable
  {:rest-serialize (comp rest-serialize deref)})

I would expect this to mean that, say, 

(- 42 atom atom atom atom rest-serialize)

would just unwrap to 42, but in fact it only unwraps the outer atom and 
leaves the inner ones alone.

Here's where it gets weird though. If I just evaluate the extend 
clojure.lang.IDeref form again, rest-serialize suddenly gains the ability 
to unwrap *two* layers of atoms. Eval it again and it can unwrap *three*. 
Kinda feels like the exercises in Little Schemer when they're building up 
to the Y Combinator.

Here's my REPL session demonstrating this (not shown, but I've verified 
this behavior is the same in Clojure 1.5.1 and Clojure 1.6.0-alpha3)

$ lein repl
nREPL server started on port 46049 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.1
Docs: (doc function-name-here)
  (find-doc part-of-name-here)
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user= (defprotocol RestSerializable
  #_=   (rest-serialize [this]
  #_=Convert to something Cheshire can JSONify))
RestSerializable
user= 

user= (extend Object
  #_=   RestSerializable
  #_=   {:rest-serialize identity})
nil
user= 

user= (extend clojure.lang.IDeref
  #_=   RestSerializable
  #_=   {:rest-serialize (comp rest-serialize deref)})
nil
user= (- 7 atom atom atom rest-serialize)
#Atom@56153406: #Atom@a0aa211: 7
user= (- 7 atom atom atom rest-serialize)
#Atom@3c19a5b0: #Atom@37cce4a3: 7
user= (- 7 atom atom atom rest-serialize)
#Atom@9f6e629: #Atom@308092db: 7
user= (extend clojure.lang.IDeref
  #_=   RestSerializable
  #_=   {:rest-serialize (comp rest-serialize deref)})
nil
user= (- 7 atom atom atom rest-serialize)
#Atom@7fb48906: 7
user= (- 7 atom atom atom rest-serialize)
#Atom@41e224a5: 7
user= (extend clojure.lang.IDeref
  #_=   RestSerializable
  #_=   {:rest-serialize (comp rest-serialize deref)})
nil
user= (- 7 atom atom atom rest-serialize)
7
user= (quit)
Bye for now!

-- 
-- 
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/groups/opt_out.

Re: odd failure on recursive use of protocol member

[Michael Blume]

Oh, interesting. I knew it was changing *some* state but I didn't realize
it was actually changing the binding of the rest-serialize var.  Thanks =)


On Tue, Dec 10, 2013 at 4:09 PM, Kevin Downey redc...@gmail.com wrote:

 extend mutates some state (the protocol definition), so what is happen
 here is comp is returning a new function built from the value of the
 rest-serialize var (the protocol function before the extend changes it)
 and the value of the deref var.

 I have not verified this, but I suspect if you use (fn [x]
 (rest-serialize (deref x))) instead of the comp version, you will get
 the behaviour you expected

 On 12/10/13, 11:50 AM, Michael Blume wrote:
  I have a protocol RestSerializable to represent data that can be
 serialized
  to json from a REST interface.
 
  (defprotocol RestSerializable
(rest-serialize [this]
 Convert to something Cheshire can JSONify))
 
  By default, things are left alone
 
  (extend Object
RestSerializable
{:rest-serialize identity})
 
  But I want atoms and the like to be transparent when serialized
 
  (extend clojure.lang.IDeref
RestSerializable
{:rest-serialize (comp rest-serialize deref)})
 
  I would expect this to mean that, say,
 
  (- 42 atom atom atom atom rest-serialize)
 
  would just unwrap to 42, but in fact it only unwraps the outer atom and
  leaves the inner ones alone.
 
  Here's where it gets weird though. If I just evaluate the extend
  clojure.lang.IDeref form again, rest-serialize suddenly gains the ability
  to unwrap *two* layers of atoms. Eval it again and it can unwrap *three*.
  Kinda feels like the exercises in Little Schemer when they're building up
  to the Y Combinator.
 
  Here's my REPL session demonstrating this (not shown, but I've verified
  this behavior is the same in Clojure 1.5.1 and Clojure 1.6.0-alpha3)
 
  $ lein repl
  nREPL server started on port 46049 on host 127.0.0.1
  REPL-y 0.2.1
  Clojure 1.5.1
  Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
   Javadoc: (javadoc java-object-or-class-here)
  Exit: Control+D or (exit) or (quit)
   Results: Stored in vars *1, *2, *3, an exception in *e
 
  user= (defprotocol RestSerializable
#_=   (rest-serialize [this]
#_=Convert to something Cheshire can JSONify))
  RestSerializable
  user=
 
  user= (extend Object
#_=   RestSerializable
#_=   {:rest-serialize identity})
  nil
  user=
 
  user= (extend clojure.lang.IDeref
#_=   RestSerializable
#_=   {:rest-serialize (comp rest-serialize deref)})
  nil
  user= (- 7 atom atom atom rest-serialize)
  #Atom@56153406: #Atom@a0aa211: 7
  user= (- 7 atom atom atom rest-serialize)
  #Atom@3c19a5b0: #Atom@37cce4a3: 7
  user= (- 7 atom atom atom rest-serialize)
  #Atom@9f6e629: #Atom@308092db: 7
  user= (extend clojure.lang.IDeref
#_=   RestSerializable
#_=   {:rest-serialize (comp rest-serialize deref)})
  nil
  user= (- 7 atom atom atom rest-serialize)
  #Atom@7fb48906: 7
  user= (- 7 atom atom atom rest-serialize)
  #Atom@41e224a5: 7
  user= (extend clojure.lang.IDeref
#_=   RestSerializable
#_=   {:rest-serialize (comp rest-serialize deref)})
  nil
  user= (- 7 atom atom atom rest-serialize)
  7
  user= (quit)
  Bye for now!
 


 --
 And what is good, Phaedrus,
 And what is not good—
 Need we ask anyone to tell us these things?



-- 
-- 
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/groups/opt_out.

Re: Functions using locks are slowed even when locks are never taken

[Michael Blume]

Sorry to be a bother, but any movement on this? This looks like a real
performance bug and I don't yet have the internals knowledge to chase it
down myself.


On Sun, Nov 3, 2013 at 12:10 PM, Michał Marczyk michal.marc...@gmail.comwrote:

 Well, that is interesting.

 The difference between the compiled versions of

 (defn foo [x]
   (if ( x 0)
 (inc x)
 (locking o
   (dec x

 and

 (defn bar [x]
   (if ( x 0)
 (inc x)
 (let [res (locking o
 (dec x))]
   res)))

 is quite significant. foo gets compiled to a single class, with
 invocations handled by a single invoke method; bar gets compiled to a
 class for bar + an extra class for an inner function which handles the
 (locking o (dec x)) part -- probably very similar to the output for
 the version with the hand-coded locking-part (although I haven't
 really looked at that yet). The inner function is a closure, so
 calling it involves an allocation of a closure object; its ctor
 receives the closed-over locals as arguments and stores them in two
 fields (lockee and x). Then they get loaded from the fields in the
 body of the closure's invoke method etc.

 I guess I'll have to play around with Java equivalents too...

 Cheers,
 Michał


 On 3 November 2013 20:46, Michael Blume blume.m...@gmail.com wrote:
  I mean, I'm probably being naive, but this suggests that one could write
 
  (defmacro locking' [ forms]
`(let [res# (locking ~@forms)] res#))
 
  and use locking' in place of locking for improved performance. Is this
  wrong? If it's right, does that suggest the macro in clojure.core should
 be
  changed?
 
 
  On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume blume.m...@gmail.com
 wrote:
 
  Huh, interesting.
 
  I have:
 
  (defn foo' [x]
(if ( x 0)
  (inc x)
  (let [res (locking o (dec x))] res)))
 
  (defn foo'' [x]
(if ( x 0)
  (inc x)
  (locking o
(dec x
 
  foo' is fast, but foo'' is slow. So something about wrapping the locking
  clause in a let makes it fast. Still no idea why.
 
  On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote:
 
  You have a typo in foo -- monitor-exit's argument is 0 (zero) rather
  than o (the sentinel object).
 
  Besides that, in foo both monitor-enter and monitor-exit get their
  arguments from a Var. Rewriting to use locking, which first puts the
  object whose monitor will be used in a local (that is, (let [lockee o]
  ...), where ... performs the locking using the newly introduced
  local), gives timings identical to those of bar and baz:
 
  (defn foo' [x]
(if ( x 0)
  (inc x)
  (let [res (locking o (dec x))] res)))
 
  So this is one reason not to use monitor-enter and monitor-exit
  directly. Another reason is that locking guarantees that the monitor
  will be released (by using try / finally, and of course by preventing
  situations where the matching monitor-enter  monitor-exit operate on
  different objects).
 
  In fact, both monitor-enter and monitor-exit carry docstrings which
  explicitly say that they should not be used in user code and point to
  locking as the user-facing equivalent to Java's synchronized.
 
  Cheers,
  Michał
 
 
  On 1 November 2013 19:34, Michael Blume blume...@gmail.com wrote:
   https://github.com/MichaelBlume/perf-test
  
   (ns perf-test
 (:use (criterium core))
 (:gen-class))
  
   (def o (Object.))
  
   (defn foo [x]
 (if ( x 0)
   (inc x)
   (do
 (monitor-enter o)
 (let [res (dec x)]
   (monitor-exit 0)
   res
  
   (defn bar [x]
 (if ( x 0)
   (inc x)
   (dec x)))
  
   (defn locking-part [x l]
 (monitor-enter l)
 (let [res (dec x)]
   (monitor-exit l)
   res))
  
   (defn baz [x]
 (if ( x 0)
   (inc x)
   (locking-part x o)))
  
   (defn -main []
 (println benching foo)
 (bench (foo 5) :verbose)
 (println benching bar)
 (bench (bar 5) :verbose)
 (println benching baz)
 (bench (baz 5) :verbose)
 (println done benching))
  
  
  
   I'm only ever calling these functions with positive values, so the
   monitor-enter branch should never be entered. Nevertheless, the
   performance
   of foo is much worse than bar or baz.
  
   The best guess I've got is that the fact that lock-taking is involved
   somehow changes how the function is compiled, somehow making the
   function
   slower. If the practical upshot is that I shouldn't write functions
   that
   only sometimes lock -- that the locking part of a function should
   always be
   its own function -- then I can do that, but I'm curious why.
  
   $ lein uberjar
   Compiling perf-test
   Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
   Created
   /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
   $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar
   benching foo
   WARNING: Final GC required 1.5974571326266802 % of runtime
   x86_64 Mac OS

Re: Functions using locks are slowed even when locks are never taken

[Michael Blume]

Huh, interesting.

I have:

(defn foo' [x]
  (if ( x 0)
(inc x)
(let [res (locking o (dec x))] res)))

(defn foo'' [x]
  (if ( x 0)
(inc x)
(locking o
  (dec x

foo' is fast, but foo'' is slow. So something about wrapping the locking 
clause in a let makes it fast. Still no idea why.

On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote:

 You have a typo in foo -- monitor-exit's argument is 0 (zero) rather 
 than o (the sentinel object). 

 Besides that, in foo both monitor-enter and monitor-exit get their 
 arguments from a Var. Rewriting to use locking, which first puts the 
 object whose monitor will be used in a local (that is, (let [lockee o] 
 ...), where ... performs the locking using the newly introduced 
 local), gives timings identical to those of bar and baz: 

 (defn foo' [x] 
   (if ( x 0) 
 (inc x) 
 (let [res (locking o (dec x))] res))) 

 So this is one reason not to use monitor-enter and monitor-exit 
 directly. Another reason is that locking guarantees that the monitor 
 will be released (by using try / finally, and of course by preventing 
 situations where the matching monitor-enter  monitor-exit operate on 
 different objects). 

 In fact, both monitor-enter and monitor-exit carry docstrings which 
 explicitly say that they should not be used in user code and point to 
 locking as the user-facing equivalent to Java's synchronized. 

 Cheers, 
 Michał 


 On 1 November 2013 19:34, Michael Blume blume...@gmail.com javascript: 
 wrote: 
  https://github.com/MichaelBlume/perf-test 
  
  (ns perf-test 
(:use (criterium core)) 
(:gen-class)) 
  
  (def o (Object.)) 
  
  (defn foo [x] 
(if ( x 0) 
  (inc x) 
  (do 
(monitor-enter o) 
(let [res (dec x)] 
  (monitor-exit 0) 
  res 
  
  (defn bar [x] 
(if ( x 0) 
  (inc x) 
  (dec x))) 
  
  (defn locking-part [x l] 
(monitor-enter l) 
(let [res (dec x)] 
  (monitor-exit l) 
  res)) 
  
  (defn baz [x] 
(if ( x 0) 
  (inc x) 
  (locking-part x o))) 
  
  (defn -main [] 
(println benching foo) 
(bench (foo 5) :verbose) 
(println benching bar) 
(bench (bar 5) :verbose) 
(println benching baz) 
(bench (baz 5) :verbose) 
(println done benching)) 
  
  
  
  I'm only ever calling these functions with positive values, so the 
  monitor-enter branch should never be entered. Nevertheless, the 
 performance 
  of foo is much worse than bar or baz. 
  
  The best guess I've got is that the fact that lock-taking is involved 
  somehow changes how the function is compiled, somehow making the 
 function 
  slower. If the practical upshot is that I shouldn't write functions that 
  only sometimes lock -- that the locking part of a function should always 
 be 
  its own function -- then I can do that, but I'm curious why. 
  
  $ lein uberjar 
  Compiling perf-test 
  Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar 
  Created 
 /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
  $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
  benching foo 
  WARNING: Final GC required 1.5974571326266802 % of runtime 
  x86_64 Mac OS X 10.8.3 4 cpu(s) 
  Java HotSpot(TM) 64-Bit Server VM 24.0-b28 
  Runtime arguments: 
  Evaluation count : 391582560 in 60 samples of 6526376 calls. 
Execution time sample mean : 167.426696 ns 
   Execution time mean : 167.459429 ns 
  Execution time sample std-deviation : 4.079466 ns 
  Execution time std-deviation : 4.097819 ns 
 Execution time lower quantile : 160.742869 ns ( 2.5%) 
 Execution time upper quantile : 175.453376 ns (97.5%) 
 Overhead used : 1.634996 ns 
  
  Found 2 outliers in 60 samples (3. %) 
  low-severe 2 (3. %) 
   Variance from outliers : 12.5602 % Variance is moderately inflated by 
  outliers 
  benching bar 
  x86_64 Mac OS X 10.8.3 4 cpu(s) 
  Java HotSpot(TM) 64-Bit Server VM 24.0-b28 
  Runtime arguments: 
  Evaluation count : 2174037300 in 60 samples of 36233955 calls. 
Execution time sample mean : 26.068923 ns 
   Execution time mean : 26.066422 ns 
  Execution time sample std-deviation : 0.887937 ns 
  Execution time std-deviation : 0.916861 ns 
 Execution time lower quantile : 23.996763 ns ( 2.5%) 
 Execution time upper quantile : 27.911936 ns (97.5%) 
 Overhead used : 1.634996 ns 
  
  Found 3 outliers in 60 samples (5. %) 
  low-severe 1 (1.6667 %) 
  low-mild 1 (1.6667 %) 
  high-mild 1 (1.6667 %) 
   Variance from outliers : 22.1874 % Variance is moderately inflated by 
  outliers 
  benching baz 
  x86_64 Mac OS X 10.8.3 4 cpu(s) 
  Java HotSpot(TM) 64-Bit Server VM 24.0-b28 
  Runtime arguments: 
  Evaluation count : 2270676660 in 60 samples of 37844611 calls. 
Execution time sample mean : 25.834142 ns 
   Execution time mean : 25.837429 ns

Re: Functions using locks are slowed even when locks are never taken

[Michael Blume]

I mean, I'm probably being naive, but this suggests that one could write

(defmacro locking' [ forms]
  `(let [res# (locking ~@forms)] res#))

and use locking' in place of locking for improved performance. Is this
wrong? If it's right, does that suggest the macro in clojure.core should be
changed?


On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume blume.m...@gmail.com wrote:

 Huh, interesting.

 I have:

 (defn foo' [x]
   (if ( x 0)
 (inc x)
 (let [res (locking o (dec x))] res)))

 (defn foo'' [x]
   (if ( x 0)
 (inc x)
 (locking o
   (dec x

 foo' is fast, but foo'' is slow. So something about wrapping the locking
 clause in a let makes it fast. Still no idea why.

 On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote:

 You have a typo in foo -- monitor-exit's argument is 0 (zero) rather
 than o (the sentinel object).

 Besides that, in foo both monitor-enter and monitor-exit get their
 arguments from a Var. Rewriting to use locking, which first puts the
 object whose monitor will be used in a local (that is, (let [lockee o]
 ...), where ... performs the locking using the newly introduced
 local), gives timings identical to those of bar and baz:

 (defn foo' [x]
   (if ( x 0)
 (inc x)
 (let [res (locking o (dec x))] res)))

 So this is one reason not to use monitor-enter and monitor-exit
 directly. Another reason is that locking guarantees that the monitor
 will be released (by using try / finally, and of course by preventing
 situations where the matching monitor-enter  monitor-exit operate on
 different objects).

 In fact, both monitor-enter and monitor-exit carry docstrings which
 explicitly say that they should not be used in user code and point to
 locking as the user-facing equivalent to Java's synchronized.

 Cheers,
 Michał


 On 1 November 2013 19:34, Michael Blume blume...@gmail.com wrote:
  https://github.com/MichaelBlume/perf-test
 
  (ns perf-test
(:use (criterium core))
(:gen-class))
 
  (def o (Object.))
 
  (defn foo [x]
(if ( x 0)
  (inc x)
  (do
(monitor-enter o)
(let [res (dec x)]
  (monitor-exit 0)
  res
 
  (defn bar [x]
(if ( x 0)
  (inc x)
  (dec x)))
 
  (defn locking-part [x l]
(monitor-enter l)
(let [res (dec x)]
  (monitor-exit l)
  res))
 
  (defn baz [x]
(if ( x 0)
  (inc x)
  (locking-part x o)))
 
  (defn -main []
(println benching foo)
(bench (foo 5) :verbose)
(println benching bar)
(bench (bar 5) :verbose)
(println benching baz)
(bench (baz 5) :verbose)
(println done benching))
 
 
 
  I'm only ever calling these functions with positive values, so the
  monitor-enter branch should never be entered. Nevertheless, the
 performance
  of foo is much worse than bar or baz.
 
  The best guess I've got is that the fact that lock-taking is involved
  somehow changes how the function is compiled, somehow making the
 function
  slower. If the practical upshot is that I shouldn't write functions
 that
  only sometimes lock -- that the locking part of a function should
 always be
  its own function -- then I can do that, but I'm curious why.
 
  $ lein uberjar
  Compiling perf-test
  Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
  Created 
  /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar

  $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar
  benching foo
  WARNING: Final GC required 1.5974571326266802 % of runtime
  x86_64 Mac OS X 10.8.3 4 cpu(s)
  Java HotSpot(TM) 64-Bit Server VM 24.0-b28
  Runtime arguments:
  Evaluation count : 391582560 in 60 samples of 6526376 calls.
Execution time sample mean : 167.426696 ns
   Execution time mean : 167.459429 ns
  Execution time sample std-deviation : 4.079466 ns
  Execution time std-deviation : 4.097819 ns
 Execution time lower quantile : 160.742869 ns ( 2.5%)
 Execution time upper quantile : 175.453376 ns (97.5%)
 Overhead used : 1.634996 ns
 
  Found 2 outliers in 60 samples (3. %)
  low-severe 2 (3. %)
   Variance from outliers : 12.5602 % Variance is moderately inflated by
  outliers
  benching bar
  x86_64 Mac OS X 10.8.3 4 cpu(s)
  Java HotSpot(TM) 64-Bit Server VM 24.0-b28
  Runtime arguments:
  Evaluation count : 2174037300 in 60 samples of 36233955 calls.
Execution time sample mean : 26.068923 ns
   Execution time mean : 26.066422 ns
  Execution time sample std-deviation : 0.887937 ns
  Execution time std-deviation : 0.916861 ns
 Execution time lower quantile : 23.996763 ns ( 2.5%)
 Execution time upper quantile : 27.911936 ns (97.5%)
 Overhead used : 1.634996 ns
 
  Found 3 outliers in 60 samples (5. %)
  low-severe 1 (1.6667 %)
  low-mild 1 (1.6667 %)
  high-mild 1 (1.6667 %)
   Variance from outliers : 22.1874 % Variance is moderately inflated by
  outliers
  benching baz
  x86_64 Mac OS

Re: Functions using locks are slowed even when locks are never taken

[Michael Blume]

Hmm, it seems like if it were JIT related you'd see the same issue with 
java code, but I get 5ns across the board.

https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java

On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote:

 Verified that I receive the same result patterns as you on my machine.

 One other possibility outside of what you have already mentioned would be 
 something JIT-related.  Perhaps there is an optimization that can be 
 performed if the locking sections of the code are in another function but 
 otherwise no, but I'm not sure how that dovetails with Clojure' fn 
 compilation.

 On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote:

 Since 1.6 alpha is out, I reran the tests with that -- basically the same 
 results.

 On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote:

 https://github.com/MichaelBlume/perf-test

 (ns perf-test
   (:use (criterium core))
   (:gen-class))

 (def o (Object.))

 (defn foo [x]
   (if ( x 0)
 (inc x)
 (do
   (monitor-enter o)
   (let [res (dec x)]
 (monitor-exit 0)
 res

 (defn bar [x]
   (if ( x 0)
 (inc x)
 (dec x)))

 (defn locking-part [x l]
   (monitor-enter l)
   (let [res (dec x)]
 (monitor-exit l)
 res))

 (defn baz [x]
   (if ( x 0)
 (inc x)
 (locking-part x o)))

 (defn -main []
   (println benching foo)
   (bench (foo 5) :verbose) 
   (println benching bar)
   (bench (bar 5) :verbose)
   (println benching baz)
   (bench (baz 5) :verbose)
   (println done benching))



 I'm only ever calling these functions with positive values, so the 
 monitor-enter branch should never be entered. Nevertheless, the performance 
 of foo is much worse than bar or baz.

 The best guess I've got is that the fact that lock-taking is involved 
 somehow changes how the function is compiled, somehow making the function 
 slower. If the practical upshot is that I shouldn't write functions that 
 only sometimes lock -- that the locking part of a function should always be 
 its own function -- then I can do that, but I'm curious why.

 $ lein uberjar
 Compiling perf-test
 Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
 Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
 $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
 benching foo
 WARNING: Final GC required 1.5974571326266802 % of runtime
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 391582560 in 60 samples of 6526376 calls.
   Execution time sample mean : 167.426696 ns
  Execution time mean : 167.459429 ns
 Execution time sample std-deviation : 4.079466 ns
 Execution time std-deviation : 4.097819 ns
Execution time lower quantile : 160.742869 ns ( 2.5%)
Execution time upper quantile : 175.453376 ns (97.5%)
Overhead used : 1.634996 ns

 Found 2 outliers in 60 samples (3. %)
 low-severe   2 (3. %)
  Variance from outliers : 12.5602 % Variance is moderately inflated by 
 outliers
 benching bar
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 2174037300 in 60 samples of 36233955 calls.
   Execution time sample mean : 26.068923 ns
  Execution time mean : 26.066422 ns
 Execution time sample std-deviation : 0.887937 ns
 Execution time std-deviation : 0.916861 ns
Execution time lower quantile : 23.996763 ns ( 2.5%)
Execution time upper quantile : 27.911936 ns (97.5%)
Overhead used : 1.634996 ns

 Found 3 outliers in 60 samples (5. %)
 low-severe   1 (1.6667 %)
 low-mild 1 (1.6667 %)
 high-mild1 (1.6667 %)
  Variance from outliers : 22.1874 % Variance is moderately inflated by 
 outliers
 benching baz
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 2270676660 in 60 samples of 37844611 calls.
   Execution time sample mean : 25.834142 ns
  Execution time mean : 25.837429 ns
 Execution time sample std-deviation : 0.718382 ns
 Execution time std-deviation : 0.729431 ns
Execution time lower quantile : 24.837925 ns ( 2.5%)
Execution time upper quantile : 27.595781 ns (97.5%)
Overhead used : 1.634996 ns

 Found 4 outliers in 60 samples (6.6667 %)
 low-severe   2 (3. %)
 low-mild 2 (3. %)
  Variance from outliers : 15.7591 % Variance is moderately inflated by 
 outliers
 done benching



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

Functions using locks are slowed even when locks are never taken

[Michael Blume]

https://github.com/MichaelBlume/perf-test

(ns perf-test
  (:use (criterium core))
  (:gen-class))

(def o (Object.))

(defn foo [x]
  (if ( x 0)
(inc x)
(do
  (monitor-enter o)
  (let [res (dec x)]
(monitor-exit 0)
res

(defn bar [x]
  (if ( x 0)
(inc x)
(dec x)))

(defn locking-part [x l]
  (monitor-enter l)
  (let [res (dec x)]
(monitor-exit l)
res))

(defn baz [x]
  (if ( x 0)
(inc x)
(locking-part x o)))

(defn -main []
  (println benching foo)
  (bench (foo 5) :verbose) 
  (println benching bar)
  (bench (bar 5) :verbose)
  (println benching baz)
  (bench (baz 5) :verbose)
  (println done benching))



I'm only ever calling these functions with positive values, so the 
monitor-enter branch should never be entered. Nevertheless, the performance of 
foo is much worse than bar or baz.

The best guess I've got is that the fact that lock-taking is involved somehow 
changes how the function is compiled, somehow making the function slower. If 
the practical upshot is that I shouldn't write functions that only sometimes 
lock -- that the locking part of a function should always be its own function 
-- then I can do that, but I'm curious why.

$ lein uberjar
Compiling perf-test
Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
$ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
benching foo
WARNING: Final GC required 1.5974571326266802 % of runtime
x86_64 Mac OS X 10.8.3 4 cpu(s)
Java HotSpot(TM) 64-Bit Server VM 24.0-b28
Runtime arguments:
Evaluation count : 391582560 in 60 samples of 6526376 calls.
  Execution time sample mean : 167.426696 ns
 Execution time mean : 167.459429 ns
Execution time sample std-deviation : 4.079466 ns
Execution time std-deviation : 4.097819 ns
   Execution time lower quantile : 160.742869 ns ( 2.5%)
   Execution time upper quantile : 175.453376 ns (97.5%)
   Overhead used : 1.634996 ns

Found 2 outliers in 60 samples (3. %)
low-severe   2 (3. %)
 Variance from outliers : 12.5602 % Variance is moderately inflated by outliers
benching bar
x86_64 Mac OS X 10.8.3 4 cpu(s)
Java HotSpot(TM) 64-Bit Server VM 24.0-b28
Runtime arguments:
Evaluation count : 2174037300 in 60 samples of 36233955 calls.
  Execution time sample mean : 26.068923 ns
 Execution time mean : 26.066422 ns
Execution time sample std-deviation : 0.887937 ns
Execution time std-deviation : 0.916861 ns
   Execution time lower quantile : 23.996763 ns ( 2.5%)
   Execution time upper quantile : 27.911936 ns (97.5%)
   Overhead used : 1.634996 ns

Found 3 outliers in 60 samples (5. %)
low-severe   1 (1.6667 %)
low-mild 1 (1.6667 %)
high-mild1 (1.6667 %)
 Variance from outliers : 22.1874 % Variance is moderately inflated by outliers
benching baz
x86_64 Mac OS X 10.8.3 4 cpu(s)
Java HotSpot(TM) 64-Bit Server VM 24.0-b28
Runtime arguments:
Evaluation count : 2270676660 in 60 samples of 37844611 calls.
  Execution time sample mean : 25.834142 ns
 Execution time mean : 25.837429 ns
Execution time sample std-deviation : 0.718382 ns
Execution time std-deviation : 0.729431 ns
   Execution time lower quantile : 24.837925 ns ( 2.5%)
   Execution time upper quantile : 27.595781 ns (97.5%)
   Overhead used : 1.634996 ns

Found 4 outliers in 60 samples (6.6667 %)
low-severe   2 (3. %)
low-mild 2 (3. %)
 Variance from outliers : 15.7591 % Variance is moderately inflated by outliers
done benching

-- 
-- 
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/groups/opt_out.

Re: Functions using locks are slowed even when locks are never taken

[Michael Blume]

Since 1.6 alpha is out, I reran the tests with that -- basically the same 
results.

On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote:

 https://github.com/MichaelBlume/perf-test

 (ns perf-test
   (:use (criterium core))
   (:gen-class))

 (def o (Object.))

 (defn foo [x]
   (if ( x 0)
 (inc x)
 (do
   (monitor-enter o)
   (let [res (dec x)]
 (monitor-exit 0)
 res

 (defn bar [x]
   (if ( x 0)
 (inc x)
 (dec x)))

 (defn locking-part [x l]
   (monitor-enter l)
   (let [res (dec x)]
 (monitor-exit l)
 res))

 (defn baz [x]
   (if ( x 0)
 (inc x)
 (locking-part x o)))

 (defn -main []
   (println benching foo)
   (bench (foo 5) :verbose) 
   (println benching bar)
   (bench (bar 5) :verbose)
   (println benching baz)
   (bench (baz 5) :verbose)
   (println done benching))



 I'm only ever calling these functions with positive values, so the 
 monitor-enter branch should never be entered. Nevertheless, the performance 
 of foo is much worse than bar or baz.

 The best guess I've got is that the fact that lock-taking is involved somehow 
 changes how the function is compiled, somehow making the function slower. If 
 the practical upshot is that I shouldn't write functions that only sometimes 
 lock -- that the locking part of a function should always be its own function 
 -- then I can do that, but I'm curious why.

 $ lein uberjar
 Compiling perf-test
 Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
 Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
 $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
 benching foo
 WARNING: Final GC required 1.5974571326266802 % of runtime
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 391582560 in 60 samples of 6526376 calls.
   Execution time sample mean : 167.426696 ns
  Execution time mean : 167.459429 ns
 Execution time sample std-deviation : 4.079466 ns
 Execution time std-deviation : 4.097819 ns
Execution time lower quantile : 160.742869 ns ( 2.5%)
Execution time upper quantile : 175.453376 ns (97.5%)
Overhead used : 1.634996 ns

 Found 2 outliers in 60 samples (3. %)
   low-severe   2 (3. %)
  Variance from outliers : 12.5602 % Variance is moderately inflated by 
 outliers
 benching bar
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 2174037300 in 60 samples of 36233955 calls.
   Execution time sample mean : 26.068923 ns
  Execution time mean : 26.066422 ns
 Execution time sample std-deviation : 0.887937 ns
 Execution time std-deviation : 0.916861 ns
Execution time lower quantile : 23.996763 ns ( 2.5%)
Execution time upper quantile : 27.911936 ns (97.5%)
Overhead used : 1.634996 ns

 Found 3 outliers in 60 samples (5. %)
   low-severe   1 (1.6667 %)
   low-mild 1 (1.6667 %)
   high-mild1 (1.6667 %)
  Variance from outliers : 22.1874 % Variance is moderately inflated by 
 outliers
 benching baz
 x86_64 Mac OS X 10.8.3 4 cpu(s)
 Java HotSpot(TM) 64-Bit Server VM 24.0-b28
 Runtime arguments:
 Evaluation count : 2270676660 in 60 samples of 37844611 calls.
   Execution time sample mean : 25.834142 ns
  Execution time mean : 25.837429 ns
 Execution time sample std-deviation : 0.718382 ns
 Execution time std-deviation : 0.729431 ns
Execution time lower quantile : 24.837925 ns ( 2.5%)
Execution time upper quantile : 27.595781 ns (97.5%)
Overhead used : 1.634996 ns

 Found 4 outliers in 60 samples (6.6667 %)
   low-severe   2 (3. %)
   low-mild 2 (3. %)
  Variance from outliers : 15.7591 % Variance is moderately inflated by 
 outliers
 done benching



-- 
-- 
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/groups/opt_out.

Re: Scala interop (or, aliasing imported Java classes)

[Michael Blume]

I ran into this problem using inner-class enums and wound up writing a 
macro to generate aliases for me. You could do something similar:

(defmacro def-class-alias
  Make name reference class

   (def-class-alias class-name foo.bar.baz.SomeClass)

   (class-name foo) - foo.bar.baz.SomeClass/foo
   ((class-name bar) arg1 arg2) - (foo.bar.baz.SomeClass/bar arg1 arg2)

  [name class]
  `(defmacro ~name
 ~(str automatically generated alias for class 
   class)
 [member#]
 (symbol (str (quote ~class) / member#


On Friday, November 1, 2013 1:40:41 PM UTC-7, Mark wrote:

 At work, we're primarily a Scala shop, but I've been writing some small 
 Clojure utilities to handle quick tasks here and there (stuff I'd written 
 in Python previously). I was hoping to make use of some of the Scala 
 libraries we'd already written, but I ran into an Java/Scala interop 
 problem that I couldn't solve cleanly.

 The problem is with Scala's package objects. If you're not familiar with 
 them, it's how Scala organizes top-level functions (ie, functions that do 
 not belong to an object or class). It looks like Scala compiles package 
 objects down to an object called package. They are lexically 
 distinguished from one another by the packages to which they belong.

 At the REPL, I was able to import one and call a method from it by doing:

  (import '(org.fooinstitute.team.libary.foo package))
 = org.fooinstitute.team.library.foo.package
  (package/isFoo foo)
 = true

 However, if I needed to use code from multiple Scala package objects, I 
 couldn't import them all individually, because there would be a name 
 conflict, and the last one imported would presumably shadow all the others.

 Alternatively, I could use the fully-qualified name for the package 
 objects, like so:

  (org.fooinstitute.team.library.foo.package/isFoo foo)
 = true

 But that's kind of verbose. The only other solution I can think of is to 
 write thin wrappers around the package objects I'd like to use, but as I 
 understand it, the general Clojure philosophy eschews that practice, since 
 Java interop should be fairly seamless (and is in just about every other 
 case I've encountered so far).

 I think my preferred solution would be to allow imported Java classes to 
 be aliased, so I could do this:

  (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
  (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in 
 Clojure.

 Has anyone encountered this and found a satisfying solution?

 Thanks,
 Mark


-- 
-- 
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/groups/opt_out.

Re: ClassNotFoundException: clojure.tools.logging.impl.LoggerFactory

[Michael Blume]

This seems to be a recurring issue. I don't see a public list/bug tracker 
for clojure.tools.logging, so I'm not clear on where I'm supposed to bring 
this bug.

On Friday, March 15, 2013 9:36:32 AM UTC-7, Michael Blume wrote:

 I'm seeing this problem in my builds more or less randomly, and don't seem 
 to be the only one


 http://stackoverflow.com/questions/8291910/noclassdeffounderror-with-clojure-tools-logging

 https://groups.google.com/forum/#!msg/datomic/6xWGFB-Dx68/_Hr2I4lv39gJ

 http://clojure-log.n01se.net/date/2012-10-16.html

 Second link seems to think it's a problem with datomic or maybe lein, but 
 I'm using maven and not using datomic, so it *seems* like there's some race 
 condition involving loading logging classes where this happens. I don't 
 understand this, since LoggerFactory is defined at top-level in 
 clojure.tools.logging.impl and impl is required in the ns declaration of 
 clojure.tools.logging.


-- 
-- 
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/groups/opt_out.

ClassNotFoundException: clojure.tools.logging.impl.LoggerFactory

[Michael Blume]

I'm seeing this problem in my builds more or less randomly, and don't seem 
to be the only one

http://stackoverflow.com/questions/8291910/noclassdeffounderror-with-clojure-tools-logging

https://groups.google.com/forum/#!msg/datomic/6xWGFB-Dx68/_Hr2I4lv39gJ

http://clojure-log.n01se.net/date/2012-10-16.html

Second link seems to think it's a problem with datomic or maybe lein, but 
I'm using maven and not using datomic, so it *seems* like there's some race 
condition involving loading logging classes where this happens. I don't 
understand this, since LoggerFactory is defined at top-level in 
clojure.tools.logging.impl and impl is required in the ns declaration of 
clojure.tools.logging.

-- 
-- 
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/groups/opt_out.