Re: Why isn't a docstring allowed for defrecord?

[Cedric Greevey]

(Point. x y) is resolved as if "Point." was a special form. Nothing Lisp-2
about it. :)


On Thu, Oct 31, 2013 at 11:48 AM, Mars0i  wrote:

> OK, I get it now.  By using Point. I'm ... temporarily descending into the
> Java world, on top of which Clojure is built.
>
> By using ->Point I remain in the more harmonious Clojure world, which
> usually hides the darkness of Java from me.
>
> (No offense meant to Java afficionados.  One of the things I love about
> Clojure is its Java interop.)
>
> On Thursday, October 31, 2013 10:38:31 AM UTC-5, Mauricio Aldazosa wrote:
>
>> On Thu, Oct 31, 2013 at 9:15 AM, Mars0i  wrote:
>>
>>> Excellent.  Thanks Tassilo.  I had attempted to do the same sort of
>>> thing using
>>> Point.
>>> rather than
>>> ->Point
>>> which didn't work:
>>> user => (doc Point.)
>>> nil
>>> user=> Point.
>>> CompilerException java.lang.ClassNotFoundException: Point.,
>>> compiling:(NO_SOURCE_PATH:0:0)
>>> user=> ->Point
>>> #>> 3c90fa05>
>>>
>>> I had assumed that Point. and ->Point were the same thing, but they are
>>> apparently not.  ->Point names something real, while Point. is just some
>>> kind of magic, I guess.
>>>
>>
>> The thing to remember here is that by defining a record you are creating
>> a new Java class. As a convenience a factory function (Point->) is created
>> for you, but you can always create instances of your record via the
>> constructor (Point.). Point. is a macro that expands to (new Point).
>>
>> Take a look at http://clojure.org/datatypes for an introduction of what
>> is going on when you use defrecord and http://clojure.org/java_
>> interop#Java%20Interop-The%20Dot%20special%20form-(new%
>> 20Classname%20args*) for the constructor documentation.
>>
>> Mauricio
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: road map for clojure?

[Cedric Greevey]

Who else is amused to find that gmail offers to make you an appointment in
your calendar for even something as distant as "15 years from now"?


On Thu, Oct 31, 2013 at 1:12 PM, Alex Miller  wrote:

> Hi Julius,
>
> Clojure is (always) under dev. The issue and commit pipeline is bursty due
> to the process followed by contributors (
> http://dev.clojure.org/display/community/JIRA+workflow, more links here:
> http://dev.clojure.org/display/community/Contributing). Tickets pool in
> the Screened list and periodically Rich Hickey reviews and ok's them in
> batches. In general, Rich values quality (of patches and Clojure in
> general) and stability much higher than quantity of patches. Most tickets
> go through 2 rounds of triage (screener and Rich) and 2+ rounds of review
> (screener, Rich, sometimes Stu, sometimes multiple rounds) before being
> committed.
>
> The choice of which tickets move through the process into development is
> largely initiated by me at the moment (as I'm the only one actively
> triaging tickets recently). That process is unscientific but I am more
> likely to triage defects over enhancements, problems seen in real apps over
> corner cases, more votes/watches over less 
> (report),
> and focus areas (error msgs, performance) over non-focus, etc.
>
> Clojure 1.6 is in the final stages right now with a push toward an
> expected release probably in December timeframe. A road map for 1.6 and
> things that were pushed out of 1.6 can be found at
> http://dev.clojure.org/display/design/Release.Next+Planning. Sometime in
> the next month or two that list will be updated for the next release (and
> possibly one beyond).
>
> I was hired by Cognitect to provide an active, continuous level of
> attention to this and other areas of Clojure development (docs, events,
> etc). For various reasons, I have actually been on client work 60-80% of
> the time but that is now ramping down so I can spend a greater percentage
> of my time solely on Clojure.
>
> Happy to answer any other questions about the current state of things.
>
> Alex Miller
> alex.mil...@cognitect.com
>
>
> On Wednesday, October 30, 2013 6:02:18 PM UTC-5, julius wrote:
>>
>> Hi,
>>
>> Is clojure under dev? there is no much commits in months, any plan or
>> road map  for clojure?
>>
>> 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/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Any interest in Compojure/Ring screencasts?

[Josh Kamau]

I am interested.

Thanks.
Josh


On Fri, Nov 1, 2013 at 3:57 AM, Tilak Thapa  wrote:

> +1, @James, i'm in.
>
>
> On Wednesday, October 30, 2013 4:32:18 AM UTC+5:45, Russell Whitaker wrote:
>
>> I, for one, would happily pay (my employer's) money for such a thing.
>>
>> R
>>
>> On Tue, Oct 29, 2013 at 3:39 PM, James Reeves 
>> wrote:
>> > I'm considering putting together a screencast, or a series of
>> screencasts,
>> > based on my Functional Web Architecture talk. The base presentation
>> would be
>> > improved, and I'd probably wind up going into more detail on certain
>> topics.
>> > I'll probably charge a small fee (perhaps $10 or so) to cover costs.
>> >
>> > Would there be any interest in this?
>> >
>> > - James
>>
>> --
>> Russell Whitaker
>> http://twitter.com/**OrthoNormalRuss 
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ANN] cljs-start with batteries included

[Shantanu Kumar]

Hi Mimmo,

I think it is a really nice project, but I was not able to run it 
successfully:

$ lein new cljs-start foo
Failed to resolve version for cljs-start:lein-template:jar:RELEASE: Could 
not find metadata cljs-start:lein-template/maven-metadata.xml in local 
(/home/shantanukumar/.m2/repository)
This could be due to a typo in :dependencies or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment 
variable.
Could not find template cljs-start on the classpath.

I saw that on Clojars it has only SNAPSHOT versions are uploaded: 
https://clojars.org/cljs-start/lein-template -- could that be a reason why 
it does not automatically download the template? I am running Leiningen 
2.3.3 with Java 7 on 64-bit Linux.

Shantanu

On Friday, 1 November 2013 04:03:32 UTC+5:30, Magomimmo wrote:
>
> Hi all,
> I just create a simple leon-template to create CLJS libs with batteries 
> included:
>
> - separation of concerns between the user view and the dev view of the 
> created lib (obtained by using the profiles.clj local to the project
> - http server and brepl (with piggieback by Chas) to bREPLing with the 
> project (everything is kept separated in the profiles.clj)
> - unit test lib included (clojurescript.test by Chas)
> - compilatation included of each build optimisation
> - test-command already defined for phantoms
> - and few other minutiae
>
> I also started to write a quick README to use it.
>
> https://github.com/magomimmo/cljs-start
>
> Here is a very quick start
>
> lein new cljs-start your-project
> cd your-project
> lein compile
> lein test
>
> To connect with the browser
>
> lein repl
> >(require '[ring.server :as http])
> > (http/run)
> > (browser-repl)
>
> Now visit localhost:3000 and wait a moment to go back to repl
>
> cljs.user> (cemerick.cljs.test/run-all-tests)
>
> To generate the jar
>
> lein jar
>
> Everything is just started, so be benevolent with me. 
>
> Feedback are appreciated, even the bad ones.
>
> HIH 
>
> mimmo
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Any interest in Compojure/Ring screencasts?

[Nando Breiter]

Yes.



Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia


On Fri, Nov 1, 2013 at 9:19 AM, Josh Kamau  wrote:

> I am interested.
>
> Thanks.
> Josh
>
>
> On Fri, Nov 1, 2013 at 3:57 AM, Tilak Thapa  wrote:
>
>> +1, @James, i'm in.
>>
>>
>> On Wednesday, October 30, 2013 4:32:18 AM UTC+5:45, Russell Whitaker
>> wrote:
>>
>>> I, for one, would happily pay (my employer's) money for such a thing.
>>>
>>> R
>>>
>>> On Tue, Oct 29, 2013 at 3:39 PM, James Reeves 
>>> wrote:
>>> > I'm considering putting together a screencast, or a series of
>>> screencasts,
>>> > based on my Functional Web Architecture talk. The base presentation
>>> would be
>>> > improved, and I'd probably wind up going into more detail on certain
>>> topics.
>>> > I'll probably charge a small fee (perhaps $10 or so) to cover costs.
>>> >
>>> > Would there be any interest in this?
>>> >
>>> > - James
>>>
>>> --
>>> Russell Whitaker
>>> http://twitter.com/**OrthoNormalRuss
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ClojureScript] [ANN] cljs-start with batteries included

[Mimmo Cosenza]

Yeah,
yestarday I forgot to publish the release 0.0.1. Sorry about that. I did it 
this morning. 

Now it should works.

Could you confirm me please?

Thanks so much.

Mimmo

p.s. In the next release I think I'm going to add both :crossovers and :clix in 
such a way to have a complete starting setup. Have you any more needs to start 
from?

 
On Nov 1, 2013, at 9:26 AM, Shantanu Kumar  wrote:

> Hi Mimmo,
> 
> I think it is a really nice project, but I was not able to run it 
> successfully:
> 
> $ lein new cljs-start foo
> Failed to resolve version for cljs-start:lein-template:jar:RELEASE: Could not 
> find metadata cljs-start:lein-template/maven-metadata.xml in local 
> (/home/shantanukumar/.m2/repository)
> This could be due to a typo in :dependencies or network issues.
> If you are behind a proxy, try setting the 'http_proxy' environment variable.
> Could not find template cljs-start on the classpath.
> 
> I saw that on Clojars it has only SNAPSHOT versions are uploaded: 
> https://clojars.org/cljs-start/lein-template -- could that be a reason why it 
> does not automatically download the template? I am running Leiningen 2.3.3 
> with Java 7 on 64-bit Linux.
> 
> Shantanu
> 
> On Friday, 1 November 2013 04:03:32 UTC+5:30, Magomimmo wrote:
> Hi all,
> I just create a simple leon-template to create CLJS libs with batteries 
> included:
> 
> - separation of concerns between the user view and the dev view of the 
> created lib (obtained by using the profiles.clj local to the project
> - http server and brepl (with piggieback by Chas) to bREPLing with the 
> project (everything is kept separated in the profiles.clj)
> - unit test lib included (clojurescript.test by Chas)
> - compilatation included of each build optimisation
> - test-command already defined for phantoms
> - and few other minutiae
> 
> I also started to write a quick README to use it.
> 
> https://github.com/magomimmo/cljs-start
> 
> Here is a very quick start
> 
> lein new cljs-start your-project
> cd your-project
> lein compile
> lein test
> 
> To connect with the browser
> 
> lein repl
> >(require '[ring.server :as http])
> > (http/run)
> > (browser-repl)
> 
> Now visit localhost:3000 and wait a moment to go back to repl
> 
> cljs.user> (cemerick.cljs.test/run-all-tests)
> 
> To generate the jar
> 
> lein jar
> 
> Everything is just started, so be benevolent with me. 
> 
> Feedback are appreciated, even the bad ones.
> 
> HIH 
> 
> mimmo
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ClojureScript] [ANN] cljs-start with batteries included

[Shantanu Kumar]

On Friday, 1 November 2013 15:45:01 UTC+5:30, Magomimmo wrote:
>
> Yeah,
> yestarday I forgot to publish the release 0.0.1. Sorry about that. I did 
> it this morning. 
>
> Now it should works.
>
> Could you confirm me please?
>

It works now. Thanks!

Shantanu

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ClojureScript] [ANN] cljs-start with batteries included

[Mimmo Cosenza]

thanks Shantanu!

Let me know if you find ant issue. I started commenting both profiles.clj and 
project.clj to try to explain what each setting is used for. 

IMHO there is a big open issue regarding lein-cljsbuild:

As pointed to me by David Nolen, you need to fill the leaning :source-paths 
with the set union al all the :source-paths from each cljsbuild to not incur in 
unexpected behaviour. But if you do  it, you loose control on the jar package 
generated by lein jar task and if you use the :jar true setting for including 
any cljs source file in the jar package, you'll get a double entry error when 
you issue the lein jar task. 

To me this is a something to be solved someway. My personal opinion about that 
is that I would never see any cljs pathname in any cli directory (and 
viceversa). Even to see a macros.clj in a cljs dir disturb me a lot. 

Anyway…. let me know if it works as you expect

thanks so much.

Mimmo

On Nov 1, 2013, at 11:26 AM, Shantanu Kumar  wrote:

> 
> 
> On Friday, 1 November 2013 15:45:01 UTC+5:30, Magomimmo wrote:
> Yeah,
> yestarday I forgot to publish the release 0.0.1. Sorry about that. I did it 
> this morning. 
> 
> Now it should works.
> 
> Could you confirm me please?
> 
> It works now. Thanks!
> 
> Shantanu
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ClojureScript] [ANN] cljs-start with batteries included

[Deniz Kurucu]

Hi,

It doesn't work for me :

lein new cljs-start battery-cljs

Retrieving
cljs-start/lein-template/0.0.1-SNAPSHOT/lein-template-0.0.1-20131101.074510-2.pom
from clojars
Retrieving cljs-start/lein-template/0.0.1/lein-template-0.0.1.pom from
clojars
Retrieving
cljs-start/lein-template/0.1.0-SNAPSHOT/lein-template-0.1.0-20131028.235447-1.pom
from clojars
Retrieving
cljs-start/lein-template/0.1.0-SNAPSHOT/lein-template-0.1.0-20131028.235447-1.jar
from clojars
Generating fresh 'lein new' cljs-start project.
Template resource 'leiningen/new/cljs_start/README.MD' not found.

After that there is not battery-cljs directory created.

Am i doing something wrong or is it just a bug ?


On Fri, Nov 1, 2013 at 12:39 PM, Mimmo Cosenza wrote:

> thanks Shantanu!
>
> Let me know if you find ant issue. I started commenting both profiles.clj
> and project.clj to try to explain what each setting is used for.
>
> IMHO there is a big open issue regarding lein-cljsbuild:
>
> As pointed to me by David Nolen, you need to fill the leaning
> :source-paths with the set union al all the :source-paths from each
> cljsbuild to not incur in unexpected behaviour. But if you do  it, you
> loose control on the jar package generated by lein jar task and if you use
> the :jar true setting for including any cljs source file in the jar
> package, you'll get a double entry error when you issue the lein jar task.
>
> To me this is a something to be solved someway. My personal opinion about
> that is that I would never see any cljs pathname in any cli directory (and
> viceversa). Even to see a macros.clj in a cljs dir disturb me a lot.
>
> Anyway…. let me know if it works as you expect
>
> thanks so much.
>
> Mimmo
>
> On Nov 1, 2013, at 11:26 AM, Shantanu Kumar 
> wrote:
>
>
>
> On Friday, 1 November 2013 15:45:01 UTC+5:30, Magomimmo wrote:
>>
>> Yeah,
>> yestarday I forgot to publish the release 0.0.1. Sorry about that. I did
>> it this morning.
>>
>> Now it should works.
>>
>> Could you confirm me please?
>>
>
> It works now. Thanks!
>
> Shantanu
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.

[ANN] repetition-hunter 1.0.0

[mynomoto]

I released repetition-hunter v1.0.0 - 
https://github.com/mynomoto/repetition-hunter

repetition-hunter is a library to find repetitions in your code. It works 
in multiple namespaces and gives you the repeated code and it's location on 
file. You can sort the repetitions by complexity or number of repetitions.

>From the readme:

user=> (use 'repetition.hunter)
nil
user=> (require 'your.namespace)
nil
user=> (hunt 'your.namespace)
2 repetitions of complexity 5

Line 474 - your.namespace:
(or (modifiers->str mname) (name mname))

Line 479 - your.namespace:
(or (modifiers->str m) (name m))

==

3 repetitions of complexity 5

Line 50 - your.namespace:
(str "(" (first t) ")")

Line 294 - your.namespace:
(str "(" (first f) ")")

Line 360 - your.namespace:
(str "(" (first c) ")")

==

2 repetitions of complexity 7

Line 162 - your.namespace:
(str/join ", " (map (partial identifier->str db) column))

Line 170 - your.namespace:
(str/join ", " (map (partial identifier->str db) column))

==

Enjoy,
mynomoto

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Potential improvement to select-keys ?

[Andy Fingerhut]

Looks like a reasonable enhancement to me.  I have filed ticket CLJ-1287
with a proposed patch for it:

http://dev.clojure.org/jira/browse/CLJ-1287

No guarantees when or if it will get into Clojure.  You can modify your own
local copy of select-keys (or even alter-var-root its definition) if you
would like the new behavior sooner, for yourself.

By the way, there is a funjible.set library published on Github that is
like clojure.set except it has preconditions that its arguments are sets or
maps, the functions have longer more explicit doc strings, and there are a
few behavior changes like ensuring metadata or sortedness of return values.

https://github.com/jafingerhut/funjible

Andy


On Thu, Oct 31, 2013 at 7:21 PM, Don Jackson <
cloj...@clark-communications.com> wrote:

>
> select-keys currently returns a regular hash-map, regardless of the kind
> of map provided as the input argument.
>
> Alternately, select-keys could call empty on it’s map argument to obtain
> the map it will return,  thereby preserving the type of map provided.
>
> FYI, Mark Engelberg recently pushed a change to data.priority-map that
> ensures that the specific flavor of priority-map is preserved through calls
> to empty…
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.

Cursive IntelliJ working on multiple Leiningen projects & require - refer :as not working

[Niels van Klaveren]

The release notes mention that working on multiple Leiningen projects has 
been improved, but how to get it working ?
I wondered if there's a preferred way to work on multiple Leiningen 
projects, so changes in one are reflected in the other.

- Leiningen has the option to work with the checkouts directory containing 
a simlink (linux) / junction link (windows) to the directories in question
- CounterClockWise has the option to add the other project to the project 
build path

I got things working by using the checkout directory / junction link 
method, and in Cursive marking the checkout source directory as a Source 
Root.
Is this the intended way to do it, or is there another way ?

Another thing I noticed is that require :as alias and require :refer aren't 
picked up, and all aliased / referred function calls are marked as "cannot 
resolved be resolved" warnings.
Any way I can get rid of those ?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ClojureScript] [ANN] cljs-start with batteries included

[Mimmo Cosenza]

It seems that you're using the SNAPSHOT version instead of the release one. 
Probably this has been caused by the fact that yesterday night I forgot to 
publish the 0.0.1 as a release (I did it this morning).

Could you please try the following:

rm -rf ~/.m2/repository/cljs-start

and try again?

Please, let me know if you succeeded

Thanks

Mimmo

On Nov 1, 2013, at 11:54 AM, Deniz Kurucu  wrote:

> Hi,
> 
> It doesn't work for me :
> 
> lein new cljs-start battery-cljs
> 
> Retrieving 
> cljs-start/lein-template/0.0.1-SNAPSHOT/lein-template-0.0.1-20131101.074510-2.pom
>  from clojars
> Retrieving cljs-start/lein-template/0.0.1/lein-template-0.0.1.pom from clojars
> Retrieving 
> cljs-start/lein-template/0.1.0-SNAPSHOT/lein-template-0.1.0-20131028.235447-1.pom
>  from clojars
> Retrieving 
> cljs-start/lein-template/0.1.0-SNAPSHOT/lein-template-0.1.0-20131028.235447-1.jar
>  from clojars
> Generating fresh 'lein new' cljs-start project.
> Template resource 'leiningen/new/cljs_start/README.MD' not found.
> 
> After that there is not battery-cljs directory created.
> 
> Am i doing something wrong or is it just a bug ?
> 
> 
> On Fri, Nov 1, 2013 at 12:39 PM, Mimmo Cosenza  
> wrote:
> thanks Shantanu!
> 
> Let me know if you find ant issue. I started commenting both profiles.clj and 
> project.clj to try to explain what each setting is used for. 
> 
> IMHO there is a big open issue regarding lein-cljsbuild:
> 
> As pointed to me by David Nolen, you need to fill the leaning :source-paths 
> with the set union al all the :source-paths from each cljsbuild to not incur 
> in unexpected behaviour. But if you do  it, you loose control on the jar 
> package generated by lein jar task and if you use the :jar true setting for 
> including any cljs source file in the jar package, you'll get a double entry 
> error when you issue the lein jar task. 
> 
> To me this is a something to be solved someway. My personal opinion about 
> that is that I would never see any cljs pathname in any cli directory (and 
> viceversa). Even to see a macros.clj in a cljs dir disturb me a lot. 
> 
> Anyway…. let me know if it works as you expect
> 
> thanks so much.
> 
> Mimmo
> 
> On Nov 1, 2013, at 11:26 AM, Shantanu Kumar  wrote:
> 
>> 
>> 
>> On Friday, 1 November 2013 15:45:01 UTC+5:30, Magomimmo wrote:
>> Yeah,
>> yestarday I forgot to publish the release 0.0.1. Sorry about that. I did it 
>> this morning. 
>> 
>> Now it should works.
>> 
>> Could you confirm me please?
>> 
>> It works now. Thanks!
>> 
>> Shantanu
>> 
>> -- 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescr...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/clojurescript.
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Cursive IntelliJ working on multiple Leiningen projects & require - refer :as not working

[Niels van Klaveren]

I don't think it's the way to do it, because the checkouts /src directory 
gets unmarked when the project is loaded anew after an IntelliJ restart.

On Friday, November 1, 2013 4:44:49 PM UTC+1, Niels van Klaveren wrote:
>
> The release notes mention that working on multiple Leiningen projects has 
> been improved, but how to get it working ?
> I wondered if there's a preferred way to work on multiple Leiningen 
> projects, so changes in one are reflected in the other.
>
> - Leiningen has the option to work with the checkouts directory containing 
> a simlink (linux) / junction link (windows) to the directories in question
> - CounterClockWise has the option to add the other project to the project 
> build path
>
> I got things working by using the checkout directory / junction link 
> method, and in Cursive marking the checkout source directory as a Source 
> Root.
> Is this the intended way to do it, or is there another way ?
>
> Another thing I noticed is that require :as alias and require :refer 
> aren't picked up, and all aliased / referred function calls are marked as 
> "cannot resolved be resolved" warnings.
> Any way I can get rid of those ?
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: .length vs. count for string length

[vrakade]

On Thursday, October 31, 2013 10:37:33 PM UTC-5, Mikera wrote:
>
> OTOH, count is much more generic since it can handle arbitrary sequences 
> etc. Also count doesn't require type hints. You should definitely prefer 
> count when writing most high level code.
>

Yes, I'd prefer count in higher level code over .length for easier Clojure 
/ ClojureScript code sharing.

For what it's worth, src/clj/clojure/string.clj uses `.length` throughout 
(except the capitalize function for I don't 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/groups/opt_out.

[ANN] Clojure 1.6.0-alpha1 release

[Alex Miller]

Clojure 1.6.0-alpha1 is now available.

Try it via
- Download:
http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha1/
- Leiningen: [org.clojure/clojure "1.6.0-alpha1"]

A list of tickets included is below. Please note that CLJ-1252 introduces a
breaking change such that keywords beginning with a digit are no longer
considered valid by the reader. This has caused some failures in java.jdbc
and other contrib libs and has already been rolled back for alpha2.

Please try it and reply to this post (or email alex.mil...@cognitect.com)
with feedback on breakage, performance, or other concerns.

# CONTENTS

## 1 Deprecated and Removed Features

None.

## 2 New and Improved Features

### 2.1 Java API

The clojure.api package provides a minimal interface to bootstrap Clojure
access from other JVM languages. It does this by providing:
1. The ability to use Clojure's namespaces to locate an arbitrary var,
returning the var's clojure.lang.IFn interface.
2. A convenience method read for reading data using Clojure's edn reader

IFns provide complete access to Clojure's APIs. You can also access any
other library written in Clojure, after adding either its source or
compiled form to the classpath.

The public Java API for Clojure consists of the following classes and
interfaces:
* clojure.api.API
* clojure.lang.IFn

All other Java classes should be treated as implementation details, and
applications should avoid relying on them.

To lookup and call a Clojure function:

IFn plus = API.var("clojure.core", "+");
plus.invoke(1, 2);

Functions in clojure.core are automatically loaded. Other namespaces can be
loaded via require:

IFn require = API.var("clojure.core", "require");
require.invoke(API.read("clojure.set"));

IFns can be passed to higher order functions, e.g. the example below passes
plus to read:

IFn map = API.var("clojure.core", "map");
IFn inc = API.var("clojure.core", "inc");
map.invoke(inc, API.read("[1 2 3]"));

Most IFns in Clojure refer to functions. A few, however, refer to
non-function data values. To access these, use deref instead of fn:

IFn printLength = API.var("clojure.core", "*print-length*");
API.var("clojure.core", "deref").invoke(printLength);

### 2.2 JDK and Dependency Version Updates

Clojure now builds with Java SE 1.6 and emits bytecode requiring Java SE
1.6 instead of Java SE 1.5. [CLJ-1268]

### 2.3 Printing

* [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
  Print metadata for functions when *print-meta* is true and remove errant
space at beginning.
* [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937)
  pprint cl-format now supports E, F, and G formats for ratios.

### 2.4 Other improvements

* [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
  Make *default-data-reader-fn* set!-able in REPL, similar to
*data-readers*.
* [CLJ-783](http://dev.clojure.org/jira/browse/CLJ-783)
  Make clojure.inspector/inspect-tree work on sets.
* [CLJ-896](http://dev.clojure.org/jira/browse/CLJ-896)
  Make browse-url aware of xdg-open.
* [CLJ-1160](http://dev.clojure.org/jira/browse/CLJ-1160)
  Fix clojure.core.reducers/mapcat does not stop on reduced? values.
* [CLJ-1121](http://dev.clojure.org/jira/browse/CLJ-1121)
  -> and ->> have been rewritten to work with a broader set of macros.

## 3 Improved error messages

* [CLJ-1099](http://dev.clojure.org/jira/browse/CLJ-1099)
  If non-seq passed where seq is needed, error message now is an
ExceptionInfo with the instance value, retrievable via ex-data.
* [CLJ-1083](http://dev.clojure.org/jira/browse/CLJ-1083)
  Fix error message reporting for "munged" function names (like a->b).
* [CLJ-1056](http://dev.clojure.org/jira/browse/CLJ-1056)
  Handle more cases and improve error message for errors in defprotocol
definnitions.
* [CLJ-1102](http://dev.clojure.org/jira/browse/CLJ-1102)
  Better handling of exceptions with empty stack traces.

## 4 Improved documentation strings

* [CLJ-1164](http://dev.clojure.org/jira/browse/CLJ-1164)
  Fix typos in clojure.instant/validated and other internal instant
functions.
* [CLJ-1143](http://dev.clojure.org/jira/browse/CLJ-1143)
  Correct doc string for ns macro.
* [CLJ-196](http://dev.clojure.org/jira/browse/CLJ-196)
  Clarify value of *file* is undefined in the REPL.
* [CLJ-1228](http://dev.clojure.org/jira/browse/CLJ-1228)
  Fix a number of spelling errors in namespace and doc strings.
* [CLJ-835](http://dev.clojure.org/jira/browse/CLJ-835)
  Update defmulti doc to clarify expectations for hierarchy argument.

## 5 Bug Fixes

* [CLJ-1018](http://dev.clojure.org/jira/browse/CLJ-1018)
  Make range consistently return () with a step of 0.
* [CLJ-863](http://dev.clojure.org/jira/browse/CLJ-863)
  Make interleave return () on 0 args and identity on 1 args.
* [CLJ-1072](http://dev.clojure.org/jira/browse/CLJ-1072)
  Update internal usages of the old metadata reader syntax to new syntax.
* [CLJ-1193](http://dev.clojure.org/jira/browse/CLJ-1193)
  Make bigint and biginteg

Re: Potential improvement to select-keys ?

[Alex Miller]

I'm not sure I agree with the intent of the patch (as I can certainly 
imagine times when I'd want a pure map from select-keys, not one that has 
the characteristics of the source map).

Also, due to empty not being supported on records (yet - separate ticket 
for that), I think this breaks select-keys for records, which would be bad 
as that is a common usage. [This would imply sequencing of changes.]


On Friday, November 1, 2013 9:39:57 AM UTC-5, Andy Fingerhut wrote:
>
> Looks like a reasonable enhancement to me.  I have filed ticket CLJ-1287 
> with a proposed patch for it:
>
> http://dev.clojure.org/jira/browse/CLJ-1287
>
> No guarantees when or if it will get into Clojure.  You can modify your 
> own local copy of select-keys (or even alter-var-root its definition) if 
> you would like the new behavior sooner, for yourself.
>
> By the way, there is a funjible.set library published on Github that is 
> like clojure.set except it has preconditions that its arguments are sets or 
> maps, the functions have longer more explicit doc strings, and there are a 
> few behavior changes like ensuring metadata or sortedness of return values.
>
> https://github.com/jafingerhut/funjible
>
> Andy
>
>
> On Thu, Oct 31, 2013 at 7:21 PM, Don Jackson <
> clo...@clark-communications.com > wrote:
>
>>
>> select-keys currently returns a regular hash-map, regardless of the kind 
>> of map provided as the input argument.
>>
>> Alternately, select-keys could call empty on it’s map argument to obtain 
>> the map it will return,  thereby preserving the type of map provided.
>>
>> FYI, Mark Engelberg recently pushed a change to data.priority-map that 
>> ensures that the specific flavor of priority-map is preserved through calls 
>> to empty…
>>
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Request for help optimising a Clojure program

[Alex Miller]

Has anyone created a design page on dev.clojure for this yet? 


On Thursday, October 31, 2013 9:19:23 AM UTC-5, Andy Fingerhut wrote:
>
> Just a follow up after a fair amount of thinking and experimentation has 
> been done on this problem.
>
> Mark Engelberg has a very nice document describing the existing hash 
> functions used by Clojure, examples with why they can cause collisions so 
> often, and suggestions for changes to them to have fewer collisions in 
> these cases.  
> https://docs.google.com/document/d/10olJzjNHXn1Si1LsSvjNqF_X1O7OTPZLuv3Uo_duY5o/edit
>
> I have made modifications to a fork of the Clojure code base with his 
> suggested hash modifications here, for experimentation purposes: 
> https://github.com/jafingerhut/clojure   I also have some modifications 
> to Paul's N-queens Clojure program to print out additional statistics and 
> try out different hash functions here: 
> https://github.com/jafingerhut/chess-clojure
>
> Running Paul's N-queens problem with a 6x6 board without any changes to 
> Clojure takes about 7 mins on one of my computers.  With those changes to 
> the hash functions it finishes in about 12 sec.
>
> I haven't let a 6x9 board run to completion without those hash changes, 
> but it takes a long time :-)  With those changes to the hash functions it 
> finishes in about 11 minutes.
>
> The reason for the currently slow behavior is a combination of the current 
> hash functions and the implementation of the PersistentHashSet data 
> structure used to implement sets.  A PersistentHashSet is, very roughly, a 
> 32-way branching tree with the hash function of the elements used to decide 
> which branch to take.  When you hit a leaf in the tree, all elements with 
> the same hash function value are put into an array that is scanned linearly 
> whenever you want to check whether a value is already in the set.  So the 
> more hash collisions, the more it is like using an array to store and look 
> up set elements in O(n) time.
>
> With the 6x9 board, there are 20,136,752 solutions.  The way those 
> solutions are represented in the program as sets of vectors, those 20 
> million values only have 17,936 different hash values.  Thus the average 
> length of those arrays of values in the tree leaves is 1,122 values.  The 
> longest of those arrays has 81,610 values in it, all with the same hash 
> function.
>
> With Mark's proposed hash function changes, those 20,136,752 values hash 
> to 20,089,488 different ints, for an average array length of 1 value, and a 
> longest array length of 3 values.  Big speedup.
>
> There is nothing unique about Mark's particular hash functions that 
> achieves this.  Other hash modifications can give similar improvements.  
> The Clojure dev team is considering which changes would be good ones to 
> make, in hopes of changing them once and not having to do it again.
>
> Andy
>
>
> On Tue, Oct 22, 2013 at 9:28 AM, Paul Butcher 
> 
> > wrote:
>
>> I've been playing around with a generalised version of the N-Queens 
>> problem that handles other chess pieces. I have a Scala implementation that 
>> uses an eager depth-first search. Given enough RAM (around 12G - it's very 
>> memory hungry!) it can solve a 6x9 board with 6 pieces in around 2.5 
>> minutes on my MacBook Pro.
>>
>> I then created a Clojure version of the same algorithm with the intention 
>> of (eventually) using laziness to avoid the memory issue. However, the 
>> performance of the Clojure version is several orders of magnitude worse 
>> than the Scala version (I've left it running overnight on the problem that 
>> the Scala version solves in 2.5 minutes and it still hasn't completed).
>>
>> I'm struggling to see why the performance of the Clojure version is so 
>> much worse than the Scala. Profiling in YourKit suggests that it's spending 
>> 99% of its time in PersistentHashSet.cons, but I'm at a loss to explain 
>> why. I would be grateful for any insight.
>>
>> The code for the two different versions is on GitHub:
>>
>> https://github.com/paulbutcher/chess-scala
>> https://github.com/paulbutcher/chess-clojure
>>
>> Notes:
>>
>> - I know that an exhaustive depth-first search isn't a great way to 
>> tackle this problem. But I'd like to understand why I see such a dramatic 
>> difference between the performance of the Scala and Clojure versions.
>>
>> - I believe that I've implemented the same algorithm in both Scala and 
>> Clojure - certainly they both generate the same results for small problems 
>> (there are 3x3 and 4x4 problems commented out in the source). But clearly I 
>> can't rule out the possibility that I've made a mistake in the Clojure 
>> implementation. If anyone can spot my stupid mistake, I'd greatly 
>> appreciate it.
>>
>> Thanks in advance for any insight that anyone can offer.
>>
>> --
>> paul.butcher->msgCount++
>>
>> Snetterton, Castle Combe, Cadwell Park...
>> Who says I have a one track mind?
>>
>> http://www.paulbutcher.com/
>> LinkedIn: http://www.l

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: .length vs. count for string length

[Sean Corfield]

This thread made me run a quick audit of our code and we had about a
dozen calls to .length, a dozen calls to .substring, and a handful of
calls to .replace - of which a few were in truly performance sensitive
code (doing Unicode-related processing across large strings, so they
had lots of other Java interop and type hints, and were deliberately
procedural). Replacing the rest with count, subs, and
clojure.string/replace (renamed to str-replace to avoid
clojure.core/replace) definitely looks "nicer" and runs plenty faster
enough for what we need.

So thanks to Alice for raising this and spurring me to make our code
more idiomatic :)

Sean

On Fri, Nov 1, 2013 at 9:38 AM,   wrote:
>
>
> On Thursday, October 31, 2013 10:37:33 PM UTC-5, Mikera wrote:
>>
>> OTOH, count is much more generic since it can handle arbitrary sequences
>> etc. Also count doesn't require type hints. You should definitely prefer
>> count when writing most high level code.
>
>
> Yes, I'd prefer count in higher level code over .length for easier Clojure /
> ClojureScript code sharing.
>
> For what it's worth, src/clj/clojure/string.clj uses `.length` throughout
> (except the capitalize function for I don't 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/groups/opt_out.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"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/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: Potential improvement to select-keys ?

[Mark Engelberg]

On Fri, Nov 1, 2013 at 11:20 AM, Alex Miller  wrote:

> I'm not sure I agree with the intent of the patch (as I can certainly
> imagine times when I'd want a pure map from select-keys, not one that has
> the characteristics of the source map).
>

I'm sure it's possible to imagine both needs, but if you have have a
sorted-map, and you do a select-keys, don't you think the "principle of
least surprise" is for it to stay a sorted-map?  I think intuitively,
select-keys is about *restricting* the existing map in some way -- you
expect things like the metadata and the type of the map to stay the same.
Similarly, my intuition tells me that if you want a new kind of map, you'd
have to "pour" the contents of the map into the other type of map via into.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Potential improvement to select-keys ?

[Cedric Greevey]

I agree with Engelberg, except that records need to be treated specially.
Select-keys (and empty) on a record preserving the type but omitting one of
the record's predefined keys would make no sense, so I'd argue that records
have to give rise to normal (unsorted) maps when these are used on them.
So, sortedness and unsortedness (and any particular sort-key or sort-fn)
would be preserved by these operations, but not exact type.

Besides, exact type isn't preserved by even conjing in the case of
PersistentArrayMap/PersistentHashMap.


On Fri, Nov 1, 2013 at 3:18 PM, Mark Engelberg wrote:

> On Fri, Nov 1, 2013 at 11:20 AM, Alex Miller  wrote:
>
>> I'm not sure I agree with the intent of the patch (as I can certainly
>> imagine times when I'd want a pure map from select-keys, not one that has
>> the characteristics of the source map).
>>
>
> I'm sure it's possible to imagine both needs, but if you have have a
> sorted-map, and you do a select-keys, don't you think the "principle of
> least surprise" is for it to stay a sorted-map?  I think intuitively,
> select-keys is about *restricting* the existing map in some way -- you
> expect things like the metadata and the type of the map to stay the same.
> Similarly, my intuition tells me that if you want a new kind of map, you'd
> have to "pour" the contents of the map into the other type of map via into.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.

Running Leiningen inside Jenkins CI server

[Simon Brooke]

I've installed Jenkins 1.537 on Debian 6, using Tomcat 6 as a servlet 
container; brief note about the installation here: 
http://blog.journeyman.cc/2013/11/getting-jenkins-ci-running-on-debian-6.html 
Now, 
I'm trying to get it to run Leiningen  and currently it isn't working. What 
I'm getting is as follows:

Started by user Simon Brooke 
Building in workspace /var/local/jenkins/workspace/et-clj
Cloning the remote Git repository
Cloning repository file:///srv/git/et-clj
git --version
git version 1.7.2.5
Checking out Revision 958f8466a11bef34143e43ba554b0d897942c2de (origin/master)
First time build. Skipping changelog.
FATAL: leiningen failed: leiningen jar path is 
emptyjava.lang.IllegalArgumentException 
:
 leiningen jar path is empty
at 
org.spootnik.LeiningenBuilder.getLeinCommand(LeiningenBuilder.java:111) 

at org.spootnik.LeiningenBuilder.perform(LeiningenBuilder.java:80) 

at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 

at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:781)
 

at hudson.model.Build$BuildExecution.build(Build.java:199) 

at hudson.model.Build$BuildExecution.doRun(Build.java:160) 

at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562) 

at hudson.model.Run.execute(Run.java:1665) 

at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 

at hudson.model.ResourceController.execute(ResourceController.java:88) 

at hudson.model.Executor.run(Executor.java:230) 

Build step 'Build project using leiningen' changed build result to FAILURE
Build step 'Build project using leiningen' marked build as failure
Finished: FAILURE


Can anyone suggest what I need to be looking at?


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

Scala interop (or, aliasing imported Java classes)

[Mark]

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: Scala interop (or, aliasing imported Java classes)

[Cedric Greevey]

I vote for adding :as to import. I've personally thought of other
situations where this could be useful.

Being able to alias a (Java) package might be useful too:

(import '((java.util.concurrent :as juc) LinkedBlockingQueue ReadWriteLock))

(def my-queue (juc/LinkedBlockingQueue.))

Most useful with conflicting class names, e.g. java.util.Date and
javax.sql.Date:

UDate vs. SDate

u/Date vs. s/Date

etc.



On Fri, Nov 1, 2013 at 4:40 PM, 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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)

[Plínio Balduino]

+1


On Fri, Nov 1, 2013 at 6:49 PM, Cedric Greevey  wrote:

> I vote for adding :as to import. I've personally thought of other
> situations where this could be useful.
>
> Being able to alias a (Java) package might be useful too:
>
> (import '((java.util.concurrent :as juc) LinkedBlockingQueue
> ReadWriteLock))
>
> (def my-queue (juc/LinkedBlockingQueue.))
>
> Most useful with conflicting class names, e.g. java.util.Date and
> javax.sql.Date:
>
> UDate vs. SDate
>
> u/Date vs. s/Date
>
> etc.
>
>
>
> On Fri, Nov 1, 2013 at 4:40 PM, 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.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Potential improvement to select-keys ?

[Michael Gardner]

On Nov 1, 2013, at 14:18 , Mark Engelberg  wrote:

> I'm sure it's possible to imagine both needs, but if you have have a 
> sorted-map, and you do a select-keys, don't you think the "principle of least 
> surprise" is for it to stay a sorted-map?

I'm not sure about that, given how map and similar functions behave. And with 
the point Cedric raised about records, I think it's better to have consistent 
behavior (always return a regular map).

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Cursive IntelliJ working on multiple Leiningen projects & require - refer :as not working

[Colin Fleming]

Right, this is still a little messy - this is actually something I'll be
working on this week. I fixed up the existing support which wouldn't allow
multiple modules at all (or at least would throw exceptions when Aether
couldn't resolve the dependencies), but it's still not smart about adding
one module to the classpath of another, sorry. I'll try to fix this in the
next build.

The require :as alias and require :refer should definitely be working,
could you let me know what your ns form looks like? Maybe drop me a mail at
curs...@cursiveclojure.com rather than on the list. I'd be interested to
know what your multi-project lein project looks like, too. Thanks!


On 2 November 2013 05:24, Niels van Klaveren wrote:

> I don't think it's the way to do it, because the checkouts /src directory
> gets unmarked when the project is loaded anew after an IntelliJ restart.
>
>
> On Friday, November 1, 2013 4:44:49 PM UTC+1, Niels van Klaveren wrote:
>>
>> The release notes mention that working on multiple Leiningen projects has
>> been improved, but how to get it working ?
>> I wondered if there's a preferred way to work on multiple Leiningen
>> projects, so changes in one are reflected in the other.
>>
>> - Leiningen has the option to work with the checkouts directory
>> containing a simlink (linux) / junction link (windows) to the directories
>> in question
>> - CounterClockWise has the option to add the other project to the project
>> build path
>>
>> I got things working by using the checkout directory / junction link
>> method, and in Cursive marking the checkout source directory as a Source
>> Root.
>> Is this the intended way to do it, or is there another way ?
>>
>> Another thing I noticed is that require :as alias and require :refer
>> aren't picked up, and all aliased / referred function calls are marked as
>> "cannot resolved be resolved" warnings.
>> Any way I can get rid of those ?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Potential improvement to select-keys ?

[Alex Miller]

I think about it as extracting a subset, and I don't particularly expect 
the subset container to have the properties of the original container - 
similar to keys or vals (and different from filter). Neither of these 
perspectives is right or wrong, but the presence of more than one leads me 
to believe that "intuitive" is dependent on the brain of the beholder in 
this case. :) 

>From the perspective of "extraction" I feel like select-keys on a record 
returning a record feels even weirder to me. 

None of this is to say that I am correct, just sharing my opinion. :)  


On Friday, November 1, 2013 2:18:33 PM UTC-5, puzzler wrote:
>
> On Fri, Nov 1, 2013 at 11:20 AM, Alex Miller 
> 
> > wrote:
>
>> I'm not sure I agree with the intent of the patch (as I can certainly 
>> imagine times when I'd want a pure map from select-keys, not one that has 
>> the characteristics of the source map).
>>
>
> I'm sure it's possible to imagine both needs, but if you have have a 
> sorted-map, and you do a select-keys, don't you think the "principle of 
> least surprise" is for it to stay a sorted-map?  I think intuitively, 
> select-keys is about *restricting* the existing map in some way -- you 
> expect things like the metadata and the type of the map to stay the same.  
> Similarly, my intuition tells me that if you want a new kind of map, you'd 
> have to "pour" the contents of the map into the other type of map via into.
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ANN] Clojure 1.6.0-alpha1 release

[Sean Corfield]

Thanx Alex. Are these release notes kept somewhere in the Github repo?
I looked at changes.md but that's still 1.5.1 and couldn't see any
obvious new document for 1.6 Alpha 1...?

Sean

On Fri, Nov 1, 2013 at 11:14 AM, Alex Miller  wrote:
> Clojure 1.6.0-alpha1 is now available.
>
> Try it via
> - Download:
> http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha1/
> - Leiningen: [org.clojure/clojure "1.6.0-alpha1"]
>
> A list of tickets included is below. Please note that CLJ-1252 introduces a
> breaking change such that keywords beginning with a digit are no longer
> considered valid by the reader. This has caused some failures in java.jdbc
> and other contrib libs and has already been rolled back for alpha2.
>
> Please try it and reply to this post (or email alex.mil...@cognitect.com)
> with feedback on breakage, performance, or other concerns.
>
> # CONTENTS
>
> ## 1 Deprecated and Removed Features
>
> None.
>
> ## 2 New and Improved Features
>
> ### 2.1 Java API
>
> The clojure.api package provides a minimal interface to bootstrap Clojure
> access from other JVM languages. It does this by providing:
> 1. The ability to use Clojure's namespaces to locate an arbitrary var,
> returning the var's clojure.lang.IFn interface.
> 2. A convenience method read for reading data using Clojure's edn reader
>
> IFns provide complete access to Clojure's APIs. You can also access any
> other library written in Clojure, after adding either its source or compiled
> form to the classpath.
>
> The public Java API for Clojure consists of the following classes and
> interfaces:
> * clojure.api.API
> * clojure.lang.IFn
>
> All other Java classes should be treated as implementation details, and
> applications should avoid relying on them.
>
> To lookup and call a Clojure function:
>
> IFn plus = API.var("clojure.core", "+");
> plus.invoke(1, 2);
>
> Functions in clojure.core are automatically loaded. Other namespaces can be
> loaded via require:
>
> IFn require = API.var("clojure.core", "require");
> require.invoke(API.read("clojure.set"));
>
> IFns can be passed to higher order functions, e.g. the example below passes
> plus to read:
>
> IFn map = API.var("clojure.core", "map");
> IFn inc = API.var("clojure.core", "inc");
> map.invoke(inc, API.read("[1 2 3]"));
>
> Most IFns in Clojure refer to functions. A few, however, refer to
> non-function data values. To access these, use deref instead of fn:
>
> IFn printLength = API.var("clojure.core", "*print-length*");
> API.var("clojure.core", "deref").invoke(printLength);
>
> ### 2.2 JDK and Dependency Version Updates
>
> Clojure now builds with Java SE 1.6 and emits bytecode requiring Java SE 1.6
> instead of Java SE 1.5. [CLJ-1268]
>
> ### 2.3 Printing
>
> * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>   Print metadata for functions when *print-meta* is true and remove errant
> space at beginning.
> * [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937)
>   pprint cl-format now supports E, F, and G formats for ratios.
>
> ### 2.4 Other improvements
>
> * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>   Make *default-data-reader-fn* set!-able in REPL, similar to
> *data-readers*.
> * [CLJ-783](http://dev.clojure.org/jira/browse/CLJ-783)
>   Make clojure.inspector/inspect-tree work on sets.
> * [CLJ-896](http://dev.clojure.org/jira/browse/CLJ-896)
>   Make browse-url aware of xdg-open.
> * [CLJ-1160](http://dev.clojure.org/jira/browse/CLJ-1160)
>   Fix clojure.core.reducers/mapcat does not stop on reduced? values.
> * [CLJ-1121](http://dev.clojure.org/jira/browse/CLJ-1121)
>   -> and ->> have been rewritten to work with a broader set of macros.
>
> ## 3 Improved error messages
>
> * [CLJ-1099](http://dev.clojure.org/jira/browse/CLJ-1099)
>   If non-seq passed where seq is needed, error message now is an
> ExceptionInfo with the instance value, retrievable via ex-data.
> * [CLJ-1083](http://dev.clojure.org/jira/browse/CLJ-1083)
>   Fix error message reporting for "munged" function names (like a->b).
> * [CLJ-1056](http://dev.clojure.org/jira/browse/CLJ-1056)
>   Handle more cases and improve error message for errors in defprotocol
> definnitions.
> * [CLJ-1102](http://dev.clojure.org/jira/browse/CLJ-1102)
>   Better handling of exceptions with empty stack traces.
>
> ## 4 Improved documentation strings
>
> * [CLJ-1164](http://dev.clojure.org/jira/browse/CLJ-1164)
>   Fix typos in clojure.instant/validated and other internal instant
> functions.
> * [CLJ-1143](http://dev.clojure.org/jira/browse/CLJ-1143)
>   Correct doc string for ns macro.
> * [CLJ-196](http://dev.clojure.org/jira/browse/CLJ-196)
>   Clarify value of *file* is undefined in the REPL.
> * [CLJ-1228](http://dev.clojure.org/jira/browse/CLJ-1228)
>   Fix a number of spelling errors in namespace and doc strings.
> * [CLJ-835](http://dev.clojure.org/jira/browse/CLJ-835)
>   Update defmulti doc to clarify expectations for hierarchy argument.
>
> ## 5 Bug F

Re: Cursive IntelliJ working on multiple Leiningen projects & require - refer :as not working

[Colin Fleming]

BTW as a workaround you can import the dependency as a module in your
project (File->Import Module...), and manually add a dependency on that
module to your main project (Project
Structure->Modules->{your_module}->Dependencies. That will allow symbols to
be resolved from one project to the other and is basically manually doing
what any future support will do automatically. That link will also survive
a project refresh.


On 2 November 2013 10:06, Colin Fleming  wrote:

> Right, this is still a little messy - this is actually something I'll be
> working on this week. I fixed up the existing support which wouldn't allow
> multiple modules at all (or at least would throw exceptions when Aether
> couldn't resolve the dependencies), but it's still not smart about adding
> one module to the classpath of another, sorry. I'll try to fix this in the
> next build.
>
> The require :as alias and require :refer should definitely be working,
> could you let me know what your ns form looks like? Maybe drop me a mail at
> curs...@cursiveclojure.com rather than on the list. I'd be interested to
> know what your multi-project lein project looks like, too. Thanks!
>
>
> On 2 November 2013 05:24, Niels van Klaveren 
> wrote:
>
>> I don't think it's the way to do it, because the checkouts /src directory
>> gets unmarked when the project is loaded anew after an IntelliJ restart.
>>
>>
>> On Friday, November 1, 2013 4:44:49 PM UTC+1, Niels van Klaveren wrote:
>>>
>>> The release notes mention that working on multiple Leiningen projects
>>> has been improved, but how to get it working ?
>>> I wondered if there's a preferred way to work on multiple Leiningen
>>> projects, so changes in one are reflected in the other.
>>>
>>> - Leiningen has the option to work with the checkouts directory
>>> containing a simlink (linux) / junction link (windows) to the directories
>>> in question
>>> - CounterClockWise has the option to add the other project to the
>>> project build path
>>>
>>> I got things working by using the checkout directory / junction link
>>> method, and in Cursive marking the checkout source directory as a Source
>>> Root.
>>> Is this the intended way to do it, or is there another way ?
>>>
>>> Another thing I noticed is that require :as alias and require :refer
>>> aren't picked up, and all aliased / referred function calls are marked as
>>> "cannot resolved be resolved" warnings.
>>> Any way I can get rid of those ?
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Potential improvement to select-keys ?

[Mark Engelberg]

Having select-keys on records returning regular maps is *not* inconsistent
with preserving the "type" of map in the sense of sorted-map, priority-map,
etc.

Here's why:

If you think of select-keys as dissoc'ing all the irrelevant keys, that
would preserve the type of sorted-map, priority-map, but it would also turn
a record into a regular map (because as soon as you dissoc a required key
from a record, it turns into a plain map).

If you think of select-keys as emptying out *all* the keys, and then
building back up with the selected keys (a more accurate representation of
what's going on under the covers), it still lends itself to exactly the
same model.  Emptying out the keys preserves the type of a map, but
converts records to regular maps (because that's what already happens when
you get rid of required keys from a record).

So, I think the behavior that Cedric described is exactly what mental
models would predict.

Alex Miller has said that he thinks of it as just nebulously selecting some
sort of undefined subset of the map, but I think that's far too vague to
base the design on.  I think the above two mental models are the ones that
someone would settle on if they spent a few seconds trying to think about
how it's probably implemented.  Both predict the same behavior, and that's
the "principle of least surprise" we should be targeting.


On Fri, Nov 1, 2013 at 2:02 PM, Michael Gardner  wrote:

> On Nov 1, 2013, at 14:18 , Mark Engelberg 
> wrote:
>
> > I'm sure it's possible to imagine both needs, but if you have have a
> sorted-map, and you do a select-keys, don't you think the "principle of
> least surprise" is for it to stay a sorted-map?
>
> I'm not sure about that, given how map and similar functions behave. And
> with the point Cedric raised about records, I think it's better to have
> consistent behavior (always return a regular map).
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Running Leiningen inside Jenkins CI server

[Jason Bennett]

Assuming you installed this plugin: 
https://wiki.jenkins-ci.org/display/JENKINS/leiningen+plugin you need to 
configure it.

Make sure that lein is installed in a place that Jenkins can get to. You 
should probably log into the box, su to jenkins, and run the lein install 
procedure. Then, go to the Jenkins configuration page (/configure) and 
scroll down to the "Leiningen Builder" section. Enter the full path to the 
lein jar (very possibly 
/var/lib/jenkins/.lein/self-installs/leiningen-2.3.3-standalone.jar). You 
should be good to go.

jason

On Friday, November 1, 2013 1:15:40 PM UTC-7, Simon Brooke wrote:
>
> I've installed Jenkins 1.537 on Debian 6, using Tomcat 6 as a servlet 
> container; brief note about the installation here: 
> http://blog.journeyman.cc/2013/11/getting-jenkins-ci-running-on-debian-6.html 
> Now, 
> I'm trying to get it to run Leiningen  and currently it isn't working. What 
> I'm getting is as follows:
>
> Started by user Simon Brooke 
> Building in workspace /var/local/jenkins/workspace/et-clj
> Cloning the remote Git repository
> Cloning repository file:///srv/git/et-clj
> git --version
> git version 1.7.2.5
> Checking out Revision 958f8466a11bef34143e43ba554b0d897942c2de (origin/master)
> First time build. Skipping changelog.
> FATAL: leiningen failed: leiningen jar path is 
> emptyjava.lang.IllegalArgumentException 
> :
>  leiningen jar path is empty
>   at 
> org.spootnik.LeiningenBuilder.getLeinCommand(LeiningenBuilder.java:111) 
> 
>   at org.spootnik.LeiningenBuilder.perform(LeiningenBuilder.java:80) 
> 
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 
> 
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:781)
>  
> 
>   at hudson.model.Build$BuildExecution.build(Build.java:199) 
> 
>   at hudson.model.Build$BuildExecution.doRun(Build.java:160) 
> 
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562) 
> 
>   at hudson.model.Run.execute(Run.java:1665) 
> 
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 
> 
>   at hudson.model.ResourceController.execute(ResourceController.java:88) 
> 
>   at hudson.model.Executor.run(Executor.java:230) 
> 
> Build step 'Build project using leiningen' changed build result to FAILURE
> Build step 'Build project using leiningen' marked build as failure
> Finished: FAILURE
>
>
> Can anyone suggest what I need to be looking at?
>
>
> Many 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/groups/opt_out.

Re: Potential improvement to select-keys ?

[Alex Miller]

On Friday, November 1, 2013 5:57:08 PM UTC-5, puzzler wrote:
>
> Having select-keys on records returning regular maps is *not* inconsistent 
> with preserving the "type" of map in the sense of sorted-map, priority-map, 
> etc.
>
> Here's why:
>
> If you think of select-keys as dissoc'ing all the irrelevant keys, that 
> would preserve the type of sorted-map, priority-map, but it would also turn 
> a record into a regular map (because as soon as you dissoc a required key 
> from a record, it turns into a plain map).
>

The "irrelevant keys" would be the (infinite) complement of the set of 
specified keys, so this wouldn't work.

If you think of select-keys as emptying out *all* the keys, and then 
> building back up with the selected keys (a more accurate representation of 
> what's going on under the covers), it still lends itself to exactly the 
> same model.  Emptying out the keys preserves the type of a map, but 
> converts records to regular maps (because that's what already happens when 
> you get rid of required keys from a record).
>

I think of it as creating a new map and filling it with entries from any 
keys in the specified set that exist in the map (which is essentially what 
it does now). My bias is purely that I'm used to and comfortable with that 
behavior.

Altering an existing function like select-keys is going to be harder to get 
accepted if it breaks existing code and that seems possible with the 
suggested alternative (certainly around records for now and possibly around 
performance). 

Instead, what if this was a new operation? Perhaps broader in scope would 
be a function that takes a map and a filter function (on key/value/both?) 
in that it filters a map based on a function of key/value/or both. This 
links back to a prior discussion (possibly on clojure-dev, can't remember 
now) about providing a richer set of operations that take and return maps. 
A similar function that does the inverse (removes based on a function) is 
another possibility - I see both of these re-implemented in many code bases 
in a variety of forms.

I personally would love to have a richer set of built-in map-oriented 
functions comparable to the seq functions but with awareness of key-value 
entries and optimized for performance in those cases. Would require some 
serious "hammock" time to determine the right set of fns.

Whatcha think?



So, I think the behavior that Cedric described is exactly what mental 
> models would predict.
>
> Alex Miller has said that he thinks of it as just nebulously selecting 
> some sort of undefined subset of the map, but I think that's far too vague 
> to base the design on.  I think the above two mental models are the ones 
> that someone would settle on if they spent a few seconds trying to think 
> about how it's probably implemented.  Both predict the same behavior, and 
> that's the "principle of least surprise" we should be targeting.
>
>
> On Fri, Nov 1, 2013 at 2:02 PM, Michael Gardner 
> 
> > wrote:
>
>> On Nov 1, 2013, at 14:18 , Mark Engelberg 
>> > 
>> wrote:
>>
>> > I'm sure it's possible to imagine both needs, but if you have have a 
>> sorted-map, and you do a select-keys, don't you think the "principle of 
>> least surprise" is for it to stay a sorted-map?
>>
>> I'm not sure about that, given how map and similar functions behave. And 
>> with the point Cedric raised about records, I think it's better to have 
>> consistent behavior (always return a regular map).
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Potential improvement to select-keys ?

[Mark Engelberg]

One other point:
Sometimes people use sorted maps and array maps specifically for scenarios
in which the keys are not hashable and therefore hash maps would not
apply.   Dumping the contents into a regular map in such cases doesn't make
much sense.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ANN] Clojure 1.6.0-alpha1 release

[Alex Miller]

Those are the updates (so far) that will go into changes.md. Stu H released 
before they were added. :)  But that is where they will go. 


On Friday, November 1, 2013 5:38:49 PM UTC-5, Sean Corfield wrote:
>
> Thanx Alex. Are these release notes kept somewhere in the Github repo? 
> I looked at changes.md but that's still 1.5.1 and couldn't see any 
> obvious new document for 1.6 Alpha 1...? 
>
> Sean 
>
> On Fri, Nov 1, 2013 at 11:14 AM, Alex Miller 
> > 
> wrote: 
> > Clojure 1.6.0-alpha1 is now available. 
> > 
> > Try it via 
> > - Download: 
> > http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha1/ 
> > - Leiningen: [org.clojure/clojure "1.6.0-alpha1"] 
> > 
> > A list of tickets included is below. Please note that CLJ-1252 
> introduces a 
> > breaking change such that keywords beginning with a digit are no longer 
> > considered valid by the reader. This has caused some failures in 
> java.jdbc 
> > and other contrib libs and has already been rolled back for alpha2. 
> > 
> > Please try it and reply to this post (or email 
> > alex@cognitect.com) 
>
> > with feedback on breakage, performance, or other concerns. 
> > 
> > # CONTENTS 
> > 
> > ## 1 Deprecated and Removed Features 
> > 
> > None. 
> > 
> > ## 2 New and Improved Features 
> > 
> > ### 2.1 Java API 
> > 
> > The clojure.api package provides a minimal interface to bootstrap 
> Clojure 
> > access from other JVM languages. It does this by providing: 
> > 1. The ability to use Clojure's namespaces to locate an arbitrary var, 
> > returning the var's clojure.lang.IFn interface. 
> > 2. A convenience method read for reading data using Clojure's edn reader 
> > 
> > IFns provide complete access to Clojure's APIs. You can also access any 
> > other library written in Clojure, after adding either its source or 
> compiled 
> > form to the classpath. 
> > 
> > The public Java API for Clojure consists of the following classes and 
> > interfaces: 
> > * clojure.api.API 
> > * clojure.lang.IFn 
> > 
> > All other Java classes should be treated as implementation details, and 
> > applications should avoid relying on them. 
> > 
> > To lookup and call a Clojure function: 
> > 
> > IFn plus = API.var("clojure.core", "+"); 
> > plus.invoke(1, 2); 
> > 
> > Functions in clojure.core are automatically loaded. Other namespaces can 
> be 
> > loaded via require: 
> > 
> > IFn require = API.var("clojure.core", "require"); 
> > require.invoke(API.read("clojure.set")); 
> > 
> > IFns can be passed to higher order functions, e.g. the example below 
> passes 
> > plus to read: 
> > 
> > IFn map = API.var("clojure.core", "map"); 
> > IFn inc = API.var("clojure.core", "inc"); 
> > map.invoke(inc, API.read("[1 2 3]")); 
> > 
> > Most IFns in Clojure refer to functions. A few, however, refer to 
> > non-function data values. To access these, use deref instead of fn: 
> > 
> > IFn printLength = API.var("clojure.core", "*print-length*"); 
> > API.var("clojure.core", "deref").invoke(printLength); 
> > 
> > ### 2.2 JDK and Dependency Version Updates 
> > 
> > Clojure now builds with Java SE 1.6 and emits bytecode requiring Java SE 
> 1.6 
> > instead of Java SE 1.5. [CLJ-1268] 
> > 
> > ### 2.3 Printing 
> > 
> > * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908) 
> >   Print metadata for functions when *print-meta* is true and remove 
> errant 
> > space at beginning. 
> > * [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937) 
> >   pprint cl-format now supports E, F, and G formats for ratios. 
> > 
> > ### 2.4 Other improvements 
> > 
> > * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908) 
> >   Make *default-data-reader-fn* set!-able in REPL, similar to 
> > *data-readers*. 
> > * [CLJ-783](http://dev.clojure.org/jira/browse/CLJ-783) 
> >   Make clojure.inspector/inspect-tree work on sets. 
> > * [CLJ-896](http://dev.clojure.org/jira/browse/CLJ-896) 
> >   Make browse-url aware of xdg-open. 
> > * [CLJ-1160](http://dev.clojure.org/jira/browse/CLJ-1160) 
> >   Fix clojure.core.reducers/mapcat does not stop on reduced? values. 
> > * [CLJ-1121](http://dev.clojure.org/jira/browse/CLJ-1121) 
> >   -> and ->> have been rewritten to work with a broader set of macros. 
> > 
> > ## 3 Improved error messages 
> > 
> > * [CLJ-1099](http://dev.clojure.org/jira/browse/CLJ-1099) 
> >   If non-seq passed where seq is needed, error message now is an 
> > ExceptionInfo with the instance value, retrievable via ex-data. 
> > * [CLJ-1083](http://dev.clojure.org/jira/browse/CLJ-1083) 
> >   Fix error message reporting for "munged" function names (like a->b). 
> > * [CLJ-1056](http://dev.clojure.org/jira/browse/CLJ-1056) 
> >   Handle more cases and improve error message for errors in defprotocol 
> > definnitions. 
> > * [CLJ-1102](http://dev.clojure.org/jira/browse/CLJ-1102) 
> >   Better handling of exceptions with empty stack traces. 
> > 
> > ## 4 Improved documentation strings 
> > 
> > * [CLJ-1164](http://dev.clojur

Re: [ANN] Clojure 1.6.0-alpha1 release

[Sean Corfield]

Thanx. Just wanted to check I wasn't looking in the wrong place.

On Fri, Nov 1, 2013 at 5:02 PM, Alex Miller  wrote:
> Those are the updates (so far) that will go into changes.md. Stu H released
> before they were added. :)  But that is where they will go.
>
>
> On Friday, November 1, 2013 5:38:49 PM UTC-5, Sean Corfield wrote:
>>
>> Thanx Alex. Are these release notes kept somewhere in the Github repo?
>> I looked at changes.md but that's still 1.5.1 and couldn't see any
>> obvious new document for 1.6 Alpha 1...?
>>
>> Sean
>>
>> On Fri, Nov 1, 2013 at 11:14 AM, Alex Miller  wrote:
>> > Clojure 1.6.0-alpha1 is now available.
>> >
>> > Try it via
>> > - Download:
>> > http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha1/
>> > - Leiningen: [org.clojure/clojure "1.6.0-alpha1"]
>> >
>> > A list of tickets included is below. Please note that CLJ-1252
>> > introduces a
>> > breaking change such that keywords beginning with a digit are no longer
>> > considered valid by the reader. This has caused some failures in
>> > java.jdbc
>> > and other contrib libs and has already been rolled back for alpha2.
>> >
>> > Please try it and reply to this post (or email alex@cognitect.com)
>> > with feedback on breakage, performance, or other concerns.
>> >
>> > # CONTENTS
>> >
>> > ## 1 Deprecated and Removed Features
>> >
>> > None.
>> >
>> > ## 2 New and Improved Features
>> >
>> > ### 2.1 Java API
>> >
>> > The clojure.api package provides a minimal interface to bootstrap
>> > Clojure
>> > access from other JVM languages. It does this by providing:
>> > 1. The ability to use Clojure's namespaces to locate an arbitrary var,
>> > returning the var's clojure.lang.IFn interface.
>> > 2. A convenience method read for reading data using Clojure's edn reader
>> >
>> > IFns provide complete access to Clojure's APIs. You can also access any
>> > other library written in Clojure, after adding either its source or
>> > compiled
>> > form to the classpath.
>> >
>> > The public Java API for Clojure consists of the following classes and
>> > interfaces:
>> > * clojure.api.API
>> > * clojure.lang.IFn
>> >
>> > All other Java classes should be treated as implementation details, and
>> > applications should avoid relying on them.
>> >
>> > To lookup and call a Clojure function:
>> >
>> > IFn plus = API.var("clojure.core", "+");
>> > plus.invoke(1, 2);
>> >
>> > Functions in clojure.core are automatically loaded. Other namespaces can
>> > be
>> > loaded via require:
>> >
>> > IFn require = API.var("clojure.core", "require");
>> > require.invoke(API.read("clojure.set"));
>> >
>> > IFns can be passed to higher order functions, e.g. the example below
>> > passes
>> > plus to read:
>> >
>> > IFn map = API.var("clojure.core", "map");
>> > IFn inc = API.var("clojure.core", "inc");
>> > map.invoke(inc, API.read("[1 2 3]"));
>> >
>> > Most IFns in Clojure refer to functions. A few, however, refer to
>> > non-function data values. To access these, use deref instead of fn:
>> >
>> > IFn printLength = API.var("clojure.core", "*print-length*");
>> > API.var("clojure.core", "deref").invoke(printLength);
>> >
>> > ### 2.2 JDK and Dependency Version Updates
>> >
>> > Clojure now builds with Java SE 1.6 and emits bytecode requiring Java SE
>> > 1.6
>> > instead of Java SE 1.5. [CLJ-1268]
>> >
>> > ### 2.3 Printing
>> >
>> > * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>> >   Print metadata for functions when *print-meta* is true and remove
>> > errant
>> > space at beginning.
>> > * [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937)
>> >   pprint cl-format now supports E, F, and G formats for ratios.
>> >
>> > ### 2.4 Other improvements
>> >
>> > * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>> >   Make *default-data-reader-fn* set!-able in REPL, similar to
>> > *data-readers*.
>> > * [CLJ-783](http://dev.clojure.org/jira/browse/CLJ-783)
>> >   Make clojure.inspector/inspect-tree work on sets.
>> > * [CLJ-896](http://dev.clojure.org/jira/browse/CLJ-896)
>> >   Make browse-url aware of xdg-open.
>> > * [CLJ-1160](http://dev.clojure.org/jira/browse/CLJ-1160)
>> >   Fix clojure.core.reducers/mapcat does not stop on reduced? values.
>> > * [CLJ-1121](http://dev.clojure.org/jira/browse/CLJ-1121)
>> >   -> and ->> have been rewritten to work with a broader set of macros.
>> >
>> > ## 3 Improved error messages
>> >
>> > * [CLJ-1099](http://dev.clojure.org/jira/browse/CLJ-1099)
>> >   If non-seq passed where seq is needed, error message now is an
>> > ExceptionInfo with the instance value, retrievable via ex-data.
>> > * [CLJ-1083](http://dev.clojure.org/jira/browse/CLJ-1083)
>> >   Fix error message reporting for "munged" function names (like a->b).
>> > * [CLJ-1056](http://dev.clojure.org/jira/browse/CLJ-1056)
>> >   Handle more cases and improve error message for errors in defprotocol
>> > definnitions.
>> > * [CLJ-1102](http://dev.clojure.org/jira/browse/CLJ-1102)
>> >   Better hand

Re: Potential improvement to select-keys ?

[Mark Engelberg]

On Fri, Nov 1, 2013 at 4:59 PM, Alex Miller  wrote:

> I think of it as creating a new map and filling it with entries from any
> keys in the specified set that exist in the map (which is essentially what
> it does now). My bias is purely that I'm used to and comfortable with that
> behavior.
>

Our emails crossed paths, timing-wise, but my response to this is that not
all types of maps can safely be dumped into a regular map, so there's not
much reason to think that the standard behavior would be to build up from
scratch using a regular map.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Running Leiningen inside Jenkins CI server

[Simon Brooke]

Thank you, that answer was correct and complete in every detail.

Very grateful!

On Friday, 1 November 2013, Jason Bennett wrote:

> Assuming you installed this plugin:
> https://wiki.jenkins-ci.org/display/JENKINS/leiningen+plugin you need to
> configure it.
>
> Make sure that lein is installed in a place that Jenkins can get to. You
> should probably log into the box, su to jenkins, and run the lein install
> procedure. Then, go to the Jenkins configuration page (/configure) and
> scroll down to the "Leiningen Builder" section. Enter the full path to the
> lein jar (very possibly
> /var/lib/jenkins/.lein/self-installs/leiningen-2.3.3-standalone.jar). You
> should be good to go.
>
> jason
>
> On Friday, November 1, 2013 1:15:40 PM UTC-7, Simon Brooke wrote:
>>
>> I've installed Jenkins 1.537 on Debian 6, using Tomcat 6 as a servlet
>> container; brief note about the installation here:
>> http://blog.journeyman.**cc/2013/11/getting-jenkins-ci-**
>> running-on-debian-6.html
>>  Now,
>> I'm trying to get it to run Leiningen  and currently it isn't working. What
>> I'm getting is as follows:
>>
>> Started by user Simon Brooke 
>> Building in workspace /var/local/jenkins/workspace/**et-clj
>> Cloning the remote Git repository
>> Cloning repository file:///srv/git/et-clj
>> git --version
>> git version 1.7.2.5
>> Checking out Revision 958f8466a11bef34143e43ba554b0d**897942c2de 
>> (origin/master)
>> First time build. Skipping changelog.
>> FATAL: leiningen failed: leiningen jar path is 
>> emptyjava.lang.**IllegalArgumentException 
>> :
>>  leiningen jar path is empty
>>  at 
>> org.spootnik.LeiningenBuilder.**getLeinCommand(**LeiningenBuilder.java:111) 
>> 
>>  at org.spootnik.LeiningenBuilder.**perform(LeiningenBuilder.java:**80) 
>> 
>>  at 
>> hudson.tasks.BuildStepMonitor$**1.perform(BuildStepMonitor.**java:20) 
>> 
>>  at 
>> hudson.model.AbstractBuild$**AbstractBuildExecution.**perform(AbstractBuild.java:**781)
>>  
>> 
>>  at hudson.model.Build$**BuildExecution.build(Build.**java:199) 
>> 
>>  at hudson.model.Build$**BuildExecution.doRun(Build.**java:160) 
>> 
>>  at 
>> hudson.model.AbstractBuild$**AbstractBuildExecution.run(**AbstractBuild.java:562)
>>  
>> 
>>  at hudson.model.Run.execute(Run.**java:1665) 
>> 
>>  at hudson.model.FreeStyleBuild.**run(FreeStyleBuild.java:46) 
>> 
>>  at 
>> hudson.model.**ResourceController.execute(**ResourceController.java:88) 
>> 
>>  at hudson.model.Executor.run(**Executor.java:230) 
>> 
>> Build step 'Build project using leiningen' changed build result to FAILURE
>> Build step 'Build project using leiningen' marked build as failure
>> Finished: FAILURE
>>
>>
>> Can anyone suggest what I need to be looking at?
>>
>>
>> Many 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 'clojure@googlegroups.com');>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com  'clojure%2bunsubscr...@googlegroups.com');>
> 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/-81qyY-OmOQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com  'clojure%2bunsubscr...@googlegroups.com');>.
> For more 

Re: Resources for learning techniques for isolating pure functions

[Ben Brinckerhoff]

Thanks for the links to the talks. I enjoyed them.

In particular, in "Thinking in Data", Stuart discussed a way to isolate 
side effects:

;; Bad
(defn complex-process [state]
  (let [result (computation state)]
(if (condition? result)
  (launch-missile)
  (erase-hard-drive

;; Better
(defn complex-process [state]
  (assoc state :analysis (computation state)))

(defn decision [state]
  (assoc state :response
(if (condition? (:analysis state))
  :launch-missile
  :erase-hard-drive)))

(defn defend-nation [state]
  (case (:response state)
:launch-missle (launch-missile)
:erase-hard-drive (erase-hard-drive)))

The benefits of the second approach are that you don't have to use mocks to 
test the interesting parts of the code.

However, I wonder how to expand this approach when the "state" itself 
requires IO - say, it exists in the DB. One approach would be to construct 
the full "state" before calling "complex-process" by querying the DB. But 
that would be inefficient especially if "complex-process" only 
conditionally needs some of the data.

"That's more a matter of dependency injection, passing components around, 
and being careful to return a new object from each operation. Once you 
decouple your components from each other via some kind of abstract 
interface (protocols are nice for this), it would be relatively easy to 
create side-effect-free mock implementations for your tests or other use 
cases."

Can you expand on that? It's very intriguing but I'm not quite seeing how 
it all fits together.

One approach I've been trying is to have functions return a "request" 
(which describes some IO action) plus a callback. So, instead of reading 
directly from the DB, a function would describe a DB query that should 
occur, and then provide a callback for processing the result. When I write 
my tests, I can just test that the function returns the right request (or 
series of requests).

Ben


On Thursday, October 31, 2013 9:56:52 AM UTC-7, Gary Trakhman wrote:
>
> Well, though your DB is side-effects, your functions that write to it 
> don't have to be aware of that.  That's more a matter of dependency 
> injection, passing components around, and being careful to return a new 
> object from each operation.
>
> Once you decouple your components from each other via some kind of 
> abstract interface (protocols are nice for this), it would be relatively 
> easy to create side-effect-free mock implementations for your tests or 
> other use cases.
>
> So, 
> 1. Create a suitable functional abstraction, where the side-effects are a 
> hidden implementation detail.
> 2. Be rigorous about using it.
>
> We do this in our code via datomic, though we're not disciplined about 
> using a functional style with return-values from DB operations.  Injecting 
> the database as a dependency is enough to help testing use-cases and 
> overall code decoupling, and the implementation is all hidden behind a set 
> of protocols specific to our app.
>
>
> On Thu, Oct 31, 2013 at 6:31 AM, Jozef Wagner 
> 
> > wrote:
>
>> Following presentations may help
>>
>>  http://www.infoq.com/presentations/Clojure-Design-Patterns
>> http://www.infoq.com/presentations/Thinking-in-Data
>>
>> JW
>>
>>
>> On Thu, Oct 31, 2013 at 3:42 AM, Ben Brinckerhoff 
>> 
>> > wrote:
>>
>>> Clojure is the first functional programming language I've used for 
>>> anything more than toy examples, so I'm learning functional programming in 
>>> general as well as Clojure specifically. I understand the value of 
>>> creating pure functions in theory, but when writing applications, I'm 
>>> finding that logic and IO are getting hopelessly entangled.
>>>
>>> Specifically, in my web application, there is interaction with the DB on 
>>> most requests. The interaction may be quite complicated: e.g. first get 
>>> some user data, inspect it, and then make more DB calls if a user is 
>>> allowed to view some resource.
>>>
>>> Does anyone know of any books or articles on structuring functional code 
>>> to separate pure and impure functions? Or other resources? Projects that 
>>> are good examples?
>>>
>>> Although I've found good resources on writing pure functions and good 
>>> resources on using Clojure IO libraries, I haven't yet found anything that 
>>> talks about architectures that let you cleanly integrate the two in 
>>> real-world projects.
>>>
>>> Thanks,
>>> Ben
>>>
>>> -- 
>>> -- 
>>> 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 unsu

Re: Any interest in Compojure/Ring screencasts?

[John Jackaman]

+1

On Tuesday, October 29, 2013 5:39:05 PM UTC-5, James Reeves wrote:
>
> I'm considering putting together a screencast, or a series of screencasts, 
> based on my Functional Web 
> Architecture talk. 
> The base presentation would be improved, and I'd probably wind up going 
> into more detail on certain topics. I'll probably charge a small fee 
> (perhaps $10 or so) to cover costs.
>
> Would there be any interest in this?
>
> - 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/groups/opt_out.

.NET's 101 LINQ Examples ported to Clojure

[Demis Bellot]

Hi Group! 

I've just published a port of C#'s 101 LINQ examples into Clojure at: 
https://github.com/mythz/clojure-linq-examples 

Hopefully it will serve as a good learning resource for others wanting to 
learn Clojure. 
I've tried to translate the examples to idiomatic Clojure but as I'm just 
starting out with Clojure myself I'm not sure if I've got all the idioms 
right. 
Any suggestions / gists or pull-requests to improve readability or make the 
examples more idiomatic are very welcomed :)

Thanks!
- Demis

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.