Re: Why does `lein new` default to clojure 1.5.1?

[Cecil Westerhof]

2014-05-05 22:08 GMT+02:00 mynomoto :

> The default lein template has clojure 1.5.1 hardcoded. It will only change
> when it's updated there.
>

​I was wondering the same also. Would it not be a good idea​ to have the
possibility to overrule this?


On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim wrote:
>
> I have Clojure 1.6.0 installed so why does `lein new app myapp` default
>> to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade
>> :all` doesn't return an upgrade for Clojure 1.5.1
>>
>
-- 
Cecil Westerhof

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

Re: Why does `lein new` default to clojure 1.5.1?

[Alex Miller]

The default leiningen templates have already been updated to Clojure 1.6.0:
https://github.com/technomancy/leiningen/commit/a296ff8918a581c975f49127d7e37a3f0c510d22

However, I don't think that change will be visible till the next lein 
release.


On Monday, May 5, 2014 3:08:56 PM UTC-5, mynomoto wrote:
>
> The default lein template has clojure 1.5.1 hardcoded. It will only change 
> when it's updated there.
> You can check the lein ancient help with `lein help ancient`. There you 
> will find how to include clojure on the verification.
>
> HTH,
> Marcelo
>
> On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim wrote:
>>
>> I have Clojure 1.6.0 installed so why does `lein new app myapp` default 
>> to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade 
>> :all` doesn't return an upgrade for Clojure 1.5.1 
>>
>> gvim 
>>
>

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

Re: Why does `lein new` default to clojure 1.5.1?

[mynomoto]

The default lein template has clojure 1.5.1 hardcoded. It will only change 
when it's updated there.
You can check the lein ancient help with `lein help ancient`. There you 
will find how to include clojure on the verification.

HTH,
Marcelo

On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim wrote:
>
> I have Clojure 1.6.0 installed so why does `lein new app myapp` default 
> to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade 
> :all` doesn't return an upgrade for Clojure 1.5.1 
>
> gvim 
>

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

Why does `lein new` default to clojure 1.5.1?

[gvim]

I have Clojure 1.6.0 installed so why does `lein new app myapp` default 
to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade 
:all` doesn't return an upgrade for Clojure 1.5.1


gvim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Penumbra anyone in clojure 1.5.1

[Kuba Roth]

ok I think got it working at least black frame shows up.


On Monday, January 27, 2014 12:51:45 PM UTC-8, Kuba Roth wrote:
>
> Hi there,
> I'm trying to get Penumbra working with clojure 1.5.1 and was wondering if 
> there is still anyone using that library...?
>
> Also I've just discovered a fork of penumbra in the clojars (
> https://clojars.org/prismofeverything/penumbra/versions/0.6.12) which 
> claims to be compatible with clojure 1.3, adn address some changes to 
> lein2. Is that version preferable to the original git? So far I have had 
> not luck with any.
>
> The ('use penumbra.opengl) line gives the following error: 
> CompilerException java.lang.ClassNotFoundException: penumbra.opengl, 
> compiling:(NO_SOURCE_PATH:1:1) 
>
> Does that mean the native library can not be found or perhaps I'm missing 
> something in project.clj?
>
>   :dependencies [[org.clojure/clojure "1.5.1"]
>  [prismofeverything/penumbra "0.6.12"]]
>   :jvm-opts ["-Djava.library.path=./target/native/linux"]
>
>
> Checking ./target/native/linux indicates some native lib do exist there, 
> but ./target/classes folder is empty. I assume all the jars are loaded now 
> from ~/.m2/repository/prismofeverything/penumbra/0.6.12 (in my case)
>
> Thanks for help,
>
> kuba
>

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

Penumbra anyone in clojure 1.5.1

[Kuba Roth]

Hi there,
I'm trying to get Penumbra working with clojure 1.5.1 and was wondering if 
there is still anyone using that library...?

Also I've just discovered a fork of penumbra in the clojars 
(https://clojars.org/prismofeverything/penumbra/versions/0.6.12) which 
claims to be compatible with clojure 1.3, adn address some changes to 
lein2. Is that version preferable to the original git? So far I have had 
not luck with any.

The ('use penumbra.opengl) line gives the following error: 
CompilerException java.lang.ClassNotFoundException: penumbra.opengl, 
compiling:(NO_SOURCE_PATH:1:1) 

Does that mean the native library can not be found or perhaps I'm missing 
something in project.clj?

  :dependencies [[org.clojure/clojure "1.5.1"]
 [prismofeverything/penumbra "0.6.12"]]
  :jvm-opts ["-Djava.library.path=./target/native/linux"]


Checking ./target/native/linux indicates some native lib do exist there, 
but ./target/classes folder is empty. I assume all the jars are loaded now 
from ~/.m2/repository/prismofeverything/penumbra/0.6.12 (in my case)

Thanks for help,

kuba

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

[Christian Sperandio]

Thanks for your answer.
I'm wrapping the Java methods so. Without regret or remorse :)

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

[Plínio Balduino]

Hi, Christian

If you look the sources of create-server, you will see it's using Java
sockets wrapped as Clojure functions. The same thing about Java
threads.

It's not a bad thing and soon or later you will find some Java object
wrapped somewhere.

IMHO, I don't think Clojure need something specific to work with
socket, so you can work that way without regrets.

Regards

Plínio

On Sun, Aug 11, 2013 at 3:04 PM, Christian Sperandio
 wrote:
> Hi,
>
> Is there a socket management with Clojure 1.5.1?
>
> I found the create-server function in the clojure.contrib but (except any
> error) the clojure.contrib is outdated with the last version of Clojure.
> And I didn't find any clue about client socket management.
>
> Should I wrap Java classes?
>
> 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.

Clojure 1.5.1 and Sockets

[Christian Sperandio]

Hi,

Is there a socket management with Clojure 1.5.1?

I found the create-server function in the clojure.contrib but (except any 
error) the clojure.contrib is outdated with the last version of Clojure.
And I didn't find any clue about client socket management.

Should I wrap Java classes?

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: clojure 1.5.1, emacs/nrepl and clojure.repl

[Colin Yates]

That works a treat - thanks.


On 8 July 2013 16:49, Neale Swinnerton  wrote:

> Hi Col,
>
> On Mon, Jul 8, 2013 at 4:43 PM, Colin Yates  wrote:
>
>> Alternatively, in the vein of just getting things done, can I do some
>> emacs fu to automatically load clojure.repl?  Silly me - of course I can -
>> this is emacs :).  No idea what that fu would be though...  Any hints?
>>
>>
> Since nrepl calls lein to establish the repl session, You can add the
> necessary require as an injection in ${HOME}/.lein/profiles.clj
>
> e.g. I have this:
>
> :injections [(require 'clojure.repl)]
>
> I don't know if this is the right way™, but it works for me...
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/vyO60o58RPE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: clojure 1.5.1, emacs/nrepl and clojure.repl

[Colin Yates]

Ah yes - nice find.


On 8 July 2013 17:24, Tim Visher  wrote:

> On Mon, Jul 8, 2013 at 11:43 AM, Colin Yates 
> wrote:
> > If using clojure 1.4.0 then when I start nrepl (CcMj) then I the
> > clojure.repl namespace is automatically 'used.  If I upgrade to Clojure
> > 1.5.1 then it doesn't.  I can still (use 'clojure.repl) but is this a
> bug?
> >
> > I can't believe I would be the first to spot this but there I couldn't
> find
> > any useful google results other than some obscure reference to 1.5's
> > increased strictness in enforcing correctness.
>
> I believe this is being tracked and discussed here:
> https://github.com/kingtim/nrepl.el/issues/292
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://blog.twonegatives.com/
> http://five.sentenc.es/ -- Spend less time on mail
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/vyO60o58RPE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: clojure 1.5.1, emacs/nrepl and clojure.repl

[Tim Visher]

On Mon, Jul 8, 2013 at 11:43 AM, Colin Yates  wrote:
> If using clojure 1.4.0 then when I start nrepl (CcMj) then I the
> clojure.repl namespace is automatically 'used.  If I upgrade to Clojure
> 1.5.1 then it doesn't.  I can still (use 'clojure.repl) but is this a bug?
>
> I can't believe I would be the first to spot this but there I couldn't find
> any useful google results other than some obscure reference to 1.5's
> increased strictness in enforcing correctness.

I believe this is being tracked and discussed here:
https://github.com/kingtim/nrepl.el/issues/292

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

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

[Neale Swinnerton]

Hi Col,

On Mon, Jul 8, 2013 at 4:43 PM, Colin Yates  wrote:

> Alternatively, in the vein of just getting things done, can I do some
> emacs fu to automatically load clojure.repl?  Silly me - of course I can -
> this is emacs :).  No idea what that fu would be though...  Any hints?
>
>
Since nrepl calls lein to establish the repl session, You can add the
necessary require as an injection in ${HOME}/.lein/profiles.clj

e.g. I have this:

:injections [(require 'clojure.repl)]

I don't know if this is the right way™, but it works for me...

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

clojure 1.5.1, emacs/nrepl and clojure.repl

[Colin Yates]

Hi all,

If using clojure 1.4.0 then when I start nrepl (CcMj) then I the 
clojure.repl namespace is automatically 'used.  If I upgrade to Clojure 
1.5.1 then it doesn't.  I can still (use 'clojure.repl) but is this a bug?

I can't believe I would be the first to spot this but there I couldn't find 
any useful google results other than some obscure reference to 1.5's 
increased strictness in enforcing correctness.

Alternatively, in the vein of just getting things done, can I do some emacs 
fu to automatically load clojure.repl?  Silly me - of course I can - this 
is emacs :).  No idea what that fu would be though...  Any hints?

Thanks a bunch.

Col

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

[Kevin Downey]

On 7/1/13 3:49 AM, Gerrard McNulty wrote:
> Suppose I had code like:
> 
> ((fn [rs] (take-last 3 rs)) (range 2000))
> 
> This seems to run fine with no head holding.  But if I write something like:
> 
> (defn- log [f]
>   (println "start")
>   (f)
>   (println "end"))
> 
> ((fn [rs] (log #(take-last 3 rs))) (range 2000))
> 
> Then this seems to hold on to the head.  Is there a way I can write code 
> like this where I can add functions like log without the head being held?
>

Closing over a sequence causes the head to be held. When a sequence is
passed as an argument clojure can do "locals clearing" to help avoid
holding on to head, but doesn't do so for closed over values, and doing
so for closed over values in an automated way is non-trivial.

You can tag closures you know are only going to be used once with ^:once
which will do the equivalent of locals clearing for closed over values,
but it will clear closed over values after they are used, so it is not
generally safe unless you know you are only calling the function once.
And :once may be considered an implementation detail, so I wouldn't
sprinkle it around everywhere.

If you pass a function that produces a seq instead of passing a seq it
avoids the whole mess:

((fn [rs] (log #(take-last 3 (rs #(range 20))

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



signature.asc
Description: OpenPGP digital signature

Re: Clojure 1.5.1 head holding

[Gerrard McNulty]

Hi Meikel,

That works for me too.  I can use that when I control the definition of 
that function.  However sometimes I don't e.g. when I use with-redefs, 
which calls with-redefs-fn.

On Monday, July 1, 2013 12:23:34 PM UTC+1, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi,
>
> I did a slight variation which does not close over the head and it seems 
> to work fine.
>
> (defn log
>   [f & args]
>   (println "start")
>   (apply f args)
>   (println "stop"))
>
> ((fn [xs] (log take-last 3 xs)) (range 2))
>
> Kind regards
> Meikel
>
>

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

[Meikel Brandmeyer (kotarak)]

Hi,

I did a slight variation which does not close over the head and it seems to 
work fine.

(defn log
  [f & args]
  (println "start")
  (apply f args)
  (println "stop"))

((fn [xs] (log take-last 3 xs)) (range 2))

Kind regards
Meikel

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

Clojure 1.5.1 head holding

[Gerrard McNulty]

Suppose I had code like:

((fn [rs] (take-last 3 rs)) (range 2000))

This seems to run fine with no head holding.  But if I write something like:

(defn- log [f]
  (println "start")
  (f)
  (println "end"))

((fn [rs] (log #(take-last 3 rs))) (range 2000))

Then this seems to hold on to the head.  Is there a way I can write code 
like this where I can add functions like log without the head being held?

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

[Colin Yates]

Ah OK, I didn't realise.  I thought the vars would be locally scoped, i.e. 
semantically equivalent to 'let'ed symbols.

Thanks everyone for contributing.

On Friday, 21 June 2013 14:49:52 UTC+1, Jim foo.bar wrote:
>
>  On 21/06/13 14:34, Colin Yates wrote:
>  
>  Is it correct but simply non-idiomatic?
>
>
> no no it's actually very *dangerous*...by doing this you're essentially 
> introducing mutable global state in your program and Clojure is a language 
> that strives hard to minimise mutable and especially global state! I 
> wouldn't say 'wrong' because the compiler lets you do it but it is 
> certainly nasty code!
>
> Also note that if I move the body out of the 'let' version of the array 
> into another function passing in the array then the performance is the same 
> as the 'def' version, so even if def is a problem it isn't the only cause.
>
>
> using 'let' or passing the array as parameter is the nice and safe 
> approach. The general performance of clojure when it comes to primitive 
> arrays was discussed very recently in this thread [1] and was concluded 
> that Clojure does indeed match java's performance. The specific use-case 
> actually was summing up primitive arrays. I encourage you read it...In a 
> nutshell, If you're using leiningen, add this entry to your project.clj and 
> rerun your benchmarks.
>
> :jvm-opts ^replace []
>
> Jim
>
> [1] https://groups.google.com/forum/#!topic/clojure/LTtxhPxH_ws
>
>  

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

[Jim - FooBar();]

On 21/06/13 15:06, Andy Fingerhut wrote:
Colin showed pretty clearly in his email that he was using "lein 
uberjar" followed by running the JVM explicitly with his own command 
line, so Leiningen has no way to affect the JVM command line options 
in that case.


oops! I thought Michael meant the guys from Prismatic not the OP on this 
thread. Yes, this doesn't apply to Colin...

my bad...I'm really sorry...

Jim

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

To unsubscribe from 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: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Michael Klishin]

2013/6/21 Jim - FooBar(); 

> Did you read the entire thread?
> both Jason and Leon (who originally posted) admit that this was the
> problem...Stuart even opened this issue:
> https://github.com/technomancy/leiningen/pull/1230
>

Leiningen's default only apply if you, hm, run Leiningen.

If you run java -jar …, you don't run Leiningen and the JVM flags used
are exactly what you provide.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Andy Fingerhut]

:jvm-opts and that ticket for Leiningen only affect the options passed to
the JVM if you let Leiningen invoke the JVM for you, e.g. via "lein run ..."

Colin showed pretty clearly in his email that he was using "lein uberjar"
followed by running the JVM explicitly with his own command line, so
Leiningen has no way to affect the JVM command line options in that case.

Andy


On Fri, Jun 21, 2013 at 6:59 AM, Jim - FooBar(); wrote:

>  Did you read the entire thread?
> both Jason and Leon (who originally posted) admit that this was the
> problem...Stuart even opened this issue:
> https://github.com/technomancy/leiningen/pull/1230
>
> the very last post reads:
>
> I should follow up on this and clarify that core.matrix's esum is in fact
> as fast as Java -- I apologize for the false statement (I was unaware that
> new versions of leiningen disable advanced JIT optimizations by default,
> which lead to the numbers I reported).
>
> Jim
>
>
>
>
> On 21/06/13 14:54, Michael Klishin wrote:
>
>  2013/6/21 Jim - FooBar(); 
>
>> If you're using leiningen, add this entry to your project.clj and rerun
>> your benchmarks.
>>
>> :jvm-opts ^replace []
>>
>
> Original post suggests the code is executed by building an uberjar running
> java -jar target/…
> so Leiningen default JVM options are not relevant.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

Did you read the entire thread?
both Jason and Leon (who originally posted) admit that this was the 
problem...Stuart even opened this issue:

https://github.com/technomancy/leiningen/pull/1230

the very last post reads:

I should follow up on this and clarify that core.matrix's esum is in 
fact as fast as Java -- I apologize for the false statement (I was 
unaware that new versions of leiningen disable advanced JIT 
optimizations by default, which lead to the numbers I reported).


Jim



On 21/06/13 14:54, Michael Klishin wrote:
2013/6/21 Jim - FooBar(); >


If you're using leiningen, add this entry to your project.clj and
rerun your benchmarks.

:jvm-opts ^replace []


Original post suggests the code is executed by building an uberjar 
running java -jar target/…

so Leiningen default JVM options are not relevant.
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/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: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Michael Klishin]

2013/6/21 Jim - FooBar(); 

> If you're using leiningen, add this entry to your project.clj and rerun
> your benchmarks.
>
> :jvm-opts ^replace []
>

Original post suggests the code is executed by building an uberjar running
java -jar target/…
so Leiningen default JVM options are not relevant.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Michael Klishin]

2013/6/21 Colin Yates 

> Is it correct but simply non-idiomatic?


It's not how defs are supposed to be used. It's like using fields for
everything in Java
even though you could use local variables for a lot of things, just because
you can.

def produces a shared (well, namespace-local) var. You probably
want a function-local one.

On top of that, since the thread is about performance, vars have features
that locals don't
and no feature comes without performance overhead.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

On 21/06/13 14:34, Colin Yates wrote:

 Is it correct but simply non-idiomatic?


no no it's actually very *dangerous*...by doing this you're essentially 
introducing mutable global state in your program and Clojure is a 
language that strives hard to minimise mutable and especially global 
state! I wouldn't say 'wrong' because the compiler lets you do it but it 
is certainly nasty code!


Also note that if I move the body out of the 'let' version of the 
array into another function passing in the array then the performance 
is the same as the 'def' version, so even if def is a problem it isn't 
the only cause.


using 'let' or passing the array as parameter is the nice and safe 
approach. The general performance of clojure when it comes to primitive 
arrays was discussed very recently in this thread [1] and was concluded 
that Clojure does indeed match java's performance. The specific use-case 
actually was summing up primitive arrays. I encourage you read it...In a 
nutshell, If you're using leiningen, add this entry to your project.clj 
and rerun your benchmarks.


:jvm-opts ^replace []

Jim

[1] https://groups.google.com/forum/#!topic/clojure/LTtxhPxH_ws 



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

To unsubscribe from 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: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Colin Yates]

Thanks Jim and David.

David, can you expand on why it is incorrect?  That is such a strong word.
 Is it correct but simply non-idiomatic?

Also note that if I move the body out of the 'let' version of the array
into another function passing in the array then the performance is the same
as the 'def' version, so even if def is a problem it isn't the only cause.



On 21 June 2013 14:29, David Nolen  wrote:

> Using `def` like that is simply incorrect. `def` should always be at the
> top level unlike say Scheme.
>
> I would first remove all internal defs and then rerun your benchmarks.
>
>
> On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates wrote:
>
>> Hi all,
>>
>> I am doing some (naive and trivial) performance tests before deciding
>> whether and how to use Clojure for some performance critical number
>> cruching and I wanted help understanding the behaviour.
>>
>> I am defining an array inside a function, setting the contents to be 1
>> and then summing them up (by areducing) them (I chose 1 instead of a random
>> number for consistency, obviously the contents will be different otherwise
>> it would all reduce to (n) :)).  If I 'let' the array then it is factors of
>> 10 faster than if I def the array.
>>
>> The relevant code (
>> https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
>>
>> [code]
>> (ns inc
>>   (:gen-class))
>>
>> (defn- inc-atom [n]
>>   (def x (atom 0))
>>   (dotimes [n n] (swap! x inc))
>>   @x)
>>
>> (defn- array-let [n]
>>   (let [a (int-array n)]
>> (dotimes [n n] (aset-int a n 1))
>> (areduce a i ret 0
>>  (+ ret (aget a i)
>>
>> (defn- array-def [n]
>>   (def a (int-array n))
>>   (dotimes [n n] (aset-int a n 1))
>>   (areduce a i ret 0
>>(+ ret (aget a i
>>
>> (defn- run-test [subject n]
>>   (time (do (def x (subject n)) (println x
>>
>> (defn -main [& args]
>>   (let [n 100]
>> (println "inc atom")
>> (run-test inc-atom n)
>> (println "array with let")
>> (run-test array-let n)
>> (println "array with def")
>> (run-test array-def n))
>> )
>> [/code]
>>
>> Interestingly, if I refactored an 'execute-on-array' def which array-let
>> and array-def delegated to then they had the same performance which seems
>> to imply it is about scoping, but the array in both array-let and array-def
>> have exactly the same scope...  Setting the autoboxing warning to true
>> didn't point out anything either.
>>
>> The output (from my VM, so a bit slow):
>> [code]
>> inc atom
>> 100
>> "Elapsed time: 213.214118 msecs"
>> array with let
>> 100
>> "Elapsed time: 75.302602 msecs"
>> array with def
>> 100
>> "Elapsed time: 12868.970203 msecs"
>> [/code]
>>
>> For comparison, the following java code:
>>
>> [code]
>> package perf;
>>
>> public class Inc {
>> public static void main(String[] args) {
>> int n = 100;
>> int counter = 0;
>> long start = System.currentTimeMillis();
>> for (int i=0; i> long end  = System.currentTimeMillis();
>> System.out.println ("Naive " + (end - start) + " ms, counter is "
>> + counter);
>>
>> counter = 0;
>> int[] arr = new int[n];
>> start = System.currentTimeMillis();
>> for (int i=0; i> for (int i=0; i> end  = System.currentTimeMillis();
>> System.out.println ("Array " + (end - start) + " ms, counter is "
>> + counter);
>>}
>> }
>> [/code]
>>
>> produces the (as expected, much faster) results :
>>
>> [code]
>> Naive 3 ms, counter is 100
>> Array 6 ms, counter is 100
>> [/code]
>>
>> I am not surprised that the atom/inc takes much longer than 3 ms, but I
>> don't understand why the array solution is so much more expensive in
>> Clojure?
>>
>> On a related point - can anyone provide a faster implementation of
>> summing up the contents of an array?
>>
>> A lein project can be found https://github.com/yatesco/clojure-perf,
>> 'lein uberjar; java -jar target/*.jar should demonstrate the output.
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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 tha

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[David Nolen]

Using `def` like that is simply incorrect. `def` should always be at the
top level unlike say Scheme.

I would first remove all internal defs and then rerun your benchmarks.


On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates  wrote:

> Hi all,
>
> I am doing some (naive and trivial) performance tests before deciding
> whether and how to use Clojure for some performance critical number
> cruching and I wanted help understanding the behaviour.
>
> I am defining an array inside a function, setting the contents to be 1 and
> then summing them up (by areducing) them (I chose 1 instead of a random
> number for consistency, obviously the contents will be different otherwise
> it would all reduce to (n) :)).  If I 'let' the array then it is factors of
> 10 faster than if I def the array.
>
> The relevant code (
> https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
>
> [code]
> (ns inc
>   (:gen-class))
>
> (defn- inc-atom [n]
>   (def x (atom 0))
>   (dotimes [n n] (swap! x inc))
>   @x)
>
> (defn- array-let [n]
>   (let [a (int-array n)]
> (dotimes [n n] (aset-int a n 1))
> (areduce a i ret 0
>  (+ ret (aget a i)
>
> (defn- array-def [n]
>   (def a (int-array n))
>   (dotimes [n n] (aset-int a n 1))
>   (areduce a i ret 0
>(+ ret (aget a i
>
> (defn- run-test [subject n]
>   (time (do (def x (subject n)) (println x
>
> (defn -main [& args]
>   (let [n 100]
> (println "inc atom")
> (run-test inc-atom n)
> (println "array with let")
> (run-test array-let n)
> (println "array with def")
> (run-test array-def n))
> )
> [/code]
>
> Interestingly, if I refactored an 'execute-on-array' def which array-let
> and array-def delegated to then they had the same performance which seems
> to imply it is about scoping, but the array in both array-let and array-def
> have exactly the same scope...  Setting the autoboxing warning to true
> didn't point out anything either.
>
> The output (from my VM, so a bit slow):
> [code]
> inc atom
> 100
> "Elapsed time: 213.214118 msecs"
> array with let
> 100
> "Elapsed time: 75.302602 msecs"
> array with def
> 100
> "Elapsed time: 12868.970203 msecs"
> [/code]
>
> For comparison, the following java code:
>
> [code]
> package perf;
>
> public class Inc {
> public static void main(String[] args) {
> int n = 100;
> int counter = 0;
> long start = System.currentTimeMillis();
> for (int i=0; i long end  = System.currentTimeMillis();
> System.out.println ("Naive " + (end - start) + " ms, counter is "
> + counter);
>
> counter = 0;
> int[] arr = new int[n];
> start = System.currentTimeMillis();
> for (int i=0; i for (int i=0; i end  = System.currentTimeMillis();
> System.out.println ("Array " + (end - start) + " ms, counter is "
> + counter);
>}
> }
> [/code]
>
> produces the (as expected, much faster) results :
>
> [code]
> Naive 3 ms, counter is 100
> Array 6 ms, counter is 100
> [/code]
>
> I am not surprised that the atom/inc takes much longer than 3 ms, but I
> don't understand why the array solution is so much more expensive in
> Clojure?
>
> On a related point - can anyone provide a faster implementation of summing
> up the contents of an array?
>
> A lein project can be found https://github.com/yatesco/clojure-perf,
> 'lein uberjar; java -jar target/*.jar should demonstrate the output.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

a start would be to set *warn-on-reflection* & *unchecked-math* to 
true...I think you're not properly type-hinting your 'aget' calls. 
areduce is the fastest way to sum up an array of primitives given that 
there are no reflective calls. This takes just over 19 ms on my humble 
machine and don't forget that we 're counting the time it takes to 
populate the array as well...


(defn- array-sum-ints [n]
  (let [^ints a (int-array n)]
(dotimes [n n] (aset a n 1))
(areduce a i ret 0
 (+ ret (aget a i)

Jim


On 21/06/13 13:36, Colin Yates wrote:

Hi all,

I am doing some (naive and trivial) performance tests before deciding 
whether and how to use Clojure for some performance critical number 
cruching and I wanted help understanding the behaviour.


I am defining an array inside a function, setting the contents to be 1 
and then summing them up (by areducing) them (I chose 1 instead of a 
random number for consistency, obviously the contents will be 
different otherwise it would all reduce to (n) :)).  If I 'let' the 
array then it is factors of 10 faster than if I def the array.


The relevant code 
(https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):


[code]
(ns inc
  (:gen-class))

(defn- inc-atom [n]
  (def x (atom 0))
  (dotimes [n n] (swap! x inc))
  @x)

(defn- array-let [n]
  (let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
 (+ ret (aget a i)

(defn- array-def [n]
  (def a (int-array n))
  (dotimes [n n] (aset-int a n 1))
  (areduce a i ret 0
   (+ ret (aget a i

(defn- run-test [subject n]
  (time (do (def x (subject n)) (println x

(defn -main [& args]
  (let [n 100]
(println "inc atom")
(run-test inc-atom n)
(println "array with let")
(run-test array-let n)
(println "array with def")
(run-test array-def n))
)
[/code]

Interestingly, if I refactored an 'execute-on-array' def which 
array-let and array-def delegated to then they had the same 
performance which seems to imply it is about scoping, but the array in 
both array-let and array-def have exactly the same scope...  Setting 
the autoboxing warning to true didn't point out anything either.


The output (from my VM, so a bit slow):
[code]
inc atom
100
"Elapsed time: 213.214118 msecs"
array with let
100
"Elapsed time: 75.302602 msecs"
array with def
100
"Elapsed time: 12868.970203 msecs"
[/code]

For comparison, the following java code:

[code]
package perf;

public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; iSystem.out.println ("Naive " + (end - start) + " ms, counter 
is " + counter);


counter = 0;
int[] arr = new int[n];
start = System.currentTimeMillis();
for (int i=0; iSystem.out.println ("Array " + (end - start) + " ms, counter 
is " + counter);

   }
}
[/code]

produces the (as expected, much faster) results :

[code]
Naive 3 ms, counter is 100
Array 6 ms, counter is 100
[/code]

I am not surprised that the atom/inc takes much longer than 3 ms, but 
I don't understand why the array solution is so much more expensive in 
Clojure?


On a related point - can anyone provide a faster implementation of 
summing up the contents of an array?


A lein project can be found https://github.com/yatesco/clojure-perf, 
'lein uberjar; java -jar target/*.jar should demonstrate the output.


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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from 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.

(clojure 1.5.1) Weird performance results when using let versus def for variable

[Colin Yates]

Hi all,

I am doing some (naive and trivial) performance tests before deciding 
whether and how to use Clojure for some performance critical number 
cruching and I wanted help understanding the behaviour.

I am defining an array inside a function, setting the contents to be 1 and 
then summing them up (by areducing) them (I chose 1 instead of a random 
number for consistency, obviously the contents will be different otherwise 
it would all reduce to (n) :)).  If I 'let' the array then it is factors of 
10 faster than if I def the array.

The relevant code 
(https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):

[code]
(ns inc
  (:gen-class))

(defn- inc-atom [n]
  (def x (atom 0))
  (dotimes [n n] (swap! x inc))
  @x)

(defn- array-let [n]
  (let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
 (+ ret (aget a i)

(defn- array-def [n]
  (def a (int-array n))
  (dotimes [n n] (aset-int a n 1))
  (areduce a i ret 0
   (+ ret (aget a i

(defn- run-test [subject n]
  (time (do (def x (subject n)) (println x

(defn -main [& args]
  (let [n 100]
(println "inc atom")
(run-test inc-atom n)
(println "array with let")
(run-test array-let n)
(println "array with def")
(run-test array-def n))
)
[/code]

Interestingly, if I refactored an 'execute-on-array' def which array-let 
and array-def delegated to then they had the same performance which seems 
to imply it is about scoping, but the array in both array-let and array-def 
have exactly the same scope...  Setting the autoboxing warning to true 
didn't point out anything either.

The output (from my VM, so a bit slow):
[code]
inc atom
100
"Elapsed time: 213.214118 msecs"
array with let
100
"Elapsed time: 75.302602 msecs"
array with def
100
"Elapsed time: 12868.970203 msecs"
[/code]

For comparison, the following java code:

[code]
package perf;

public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; ihttps://github.com/yatesco/clojure-perf, 'lein 
uberjar; java -jar target/*.jar should demonstrate the output.

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

[alexi]

Hi Stream,

I have resolved the problem you are referring to. See comment in the issue 
you have opened

https://github.com/apolenur/vert.x-mod-lang-clojure/issues/1

Regards, Alexi

On Monday, 17 June 2013 23:15:37 UTC-4, Stream wrote:
>
>
>
> 在 2013年5月9日星期四UTC+8下午2时00分54秒，Stream写道：
>>
>> Hi all 
>>
>> i wanna change the classloader of Clojure RT. in 1.5.1 
>> so , i try to 
>> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
>> clojure.lang.Compiler.LOADER, cl) ); 
>>
>> but throws exception that cojure.lang.Compiler.LOADER is null 
>>
>> Caused by: java.lang.NullPointerException 
>> at clojure.lang.RT.baseLoader(RT.java:2043) 
>> at clojure.lang.RT.load(RT.java:417) 
>> at clojure.lang.RT.load(RT.java:411) 
>> at clojure.lang.RT.doInit(RT.java:447) 
>> at clojure.lang.RT.(RT.java:329) 
>> ... 9 more 
>>
>>
>> However this is work in the 1.4.0 
>>
>> someone could tell me what had happened in 1.5.1 
>> thanks
>
>
> --
>
> Sorry , i have disappear a month for my own things..
>
> the problem is still hung. i don't how to resolve it , except back version 
> of clojure to 1.4.0
>
> The intention is that vertx project http://vertx.io/ use clojure as one 
> of scriptlang to execute some logical
>
> so, i have own classloader which is cl, could load any other lib of jar 
> dynamically.
>
> as @atkaaz desc, it seems  LOADER has set NULL. and reason @sean corfield 
> has given.
>
> i hope someone could give me a idea 
>
> thanks again.
>
>
>
>
>  
>

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

[Stream]

在 2013年5月9日星期四UTC+8下午2时00分54秒，Stream写道：
>
> Hi all 
>
> i wanna change the classloader of Clojure RT. in 1.5.1 
> so , i try to 
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
> clojure.lang.Compiler.LOADER, cl) ); 
>
> but throws exception that cojure.lang.Compiler.LOADER is null 
>
> Caused by: java.lang.NullPointerException 
> at clojure.lang.RT.baseLoader(RT.java:2043) 
> at clojure.lang.RT.load(RT.java:417) 
> at clojure.lang.RT.load(RT.java:411) 
> at clojure.lang.RT.doInit(RT.java:447) 
> at clojure.lang.RT.(RT.java:329) 
> ... 9 more 
>
>
> However this is work in the 1.4.0 
>
> someone could tell me what had happened in 1.5.1 
> thanks


--

Sorry , i have disappear a month for my own things..

the problem is still hung. i don't how to resolve it , except back version 
of clojure to 1.4.0

The intention is that vertx project http://vertx.io/ use clojure as one of 
scriptlang to execute some logical

so, i have own classloader which is cl, could load any other lib of jar 
dynamically.

as @atkaaz desc, it seems  LOADER has set NULL. and reason @sean corfield 
has given.

i hope someone could give me a idea 

thanks again.




 

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

[Sean Corfield]

Daniel hinted at it in his response and it's been discussed several
times in the past but most of clojure.lang.RT and pretty much all of
clojure.lang.{anything-else} is considered a private implementation
detail and subject to change, so relying on it in code is very
brittle. I think Rich has indicated that pretty much only
clojure.lang.RT.var() is really "supported" and everything else should
be considered off-limits.

That doesn't help you with changing the classloader so maybe someone
from Clojure/core can weigh in on whether that's even considered
safe...?

Sean

On Wed, May 8, 2013 at 11:00 PM, stream  wrote:
> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
> clojure.lang.Compiler.LOADER, cl) );
>
> but throws exception that cojure.lang.Compiler.LOADER is null
>
> Caused by: java.lang.NullPointerException
> at clojure.lang.RT.baseLoader(RT.java:2043)
> at clojure.lang.RT.load(RT.java:417)
> at clojure.lang.RT.load(RT.java:411)
> at clojure.lang.RT.doInit(RT.java:447)
> at clojure.lang.RT.(RT.java:329)
> ... 9 more
>
>
> However this is work in the 1.4.0
>
> someone could tell me what had happened in 1.5.1
> 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.
>
>



-- 
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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[AtKaaZ]

is not this one is it ?
https://github.com/CmdrDats/clj-minecraft/blob/master/javasrc/cljminecraft/BasePlugin.java#L82


On Thu, May 9, 2013 at 7:12 PM, AtKaaZ  wrote:

> is there any chance that we can see the full code (maybe's on github
> already?)
>
>
> On Thu, May 9, 2013 at 9:00 AM, stream  wrote:
>
>> Hi all
>>
>> i wanna change the classloader of Clojure RT. in 1.5.1
>> so , i try to
>> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
>> clojure.lang.Compiler.LOADER, cl) );
>>
>> but throws exception that cojure.lang.Compiler.LOADER is null
>>
>> Caused by: java.lang.NullPointerException
>> at clojure.lang.RT.baseLoader(RT.java:2043)
>> at clojure.lang.RT.load(RT.java:417)
>> at clojure.lang.RT.load(RT.java:411)
>> at clojure.lang.RT.doInit(RT.java:447)
>> at clojure.lang.RT.(RT.java:329)
>> ... 9 more
>>
>>
>> However this is work in the 1.4.0
>>
>> someone could tell me what had happened in 1.5.1
>> 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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[AtKaaZ]

is there any chance that we can see the full code (maybe's on github
already?)


On Thu, May 9, 2013 at 9:00 AM, stream  wrote:

> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
> clojure.lang.Compiler.LOADER, cl) );
>
> but throws exception that cojure.lang.Compiler.LOADER is null
>
> Caused by: java.lang.NullPointerException
> at clojure.lang.RT.baseLoader(RT.java:2043)
> at clojure.lang.RT.load(RT.java:417)
> at clojure.lang.RT.load(RT.java:411)
> at clojure.lang.RT.doInit(RT.java:447)
> at clojure.lang.RT.(RT.java:329)
> ... 9 more
>
>
> However this is work in the 1.4.0
>
> someone could tell me what had happened in 1.5.1
> 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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[AtKaaZ]

Caused by: java.lang.NullPointerException
at clojure.lang.RT.*baseLoader*(RT.java:2043)

hmm, it's almost as if:
static final public Var LOADER = Var.create().setDynamic();
had no effect as in: LOADER=null;



On Thu, May 9, 2013 at 4:51 PM, semperos wrote:

> Is there a reason you don't use one of the methods exposed in
> clojure.lang.RT, e.g., makeClassLoader() or baseLoader() ?
>
>
> On Thursday, May 9, 2013 2:00:54 AM UTC-4, Stream wrote:
>>
>> Hi all
>>
>> i wanna change the classloader of Clojure RT. in 1.5.1
>> so , i try to
>> clojure.lang.Var.**pushThreadBindings(clojure.**lang.RT.map(
>> clojure.lang.Compiler.LOADER, cl) );
>>
>> but throws exception that cojure.lang.Compiler.LOADER is null
>>
>> Caused by: java.lang.NullPointerException
>> at clojure.lang.RT.baseLoader(RT.**java:2043)
>> at clojure.lang.RT.load(RT.java:**417)
>> at clojure.lang.RT.load(RT.java:**411)
>> at clojure.lang.RT.doInit(RT.**java:447)
>> at clojure.lang.RT.(RT.**java:329)
>> ... 9 more
>>
>>
>> However this is work in the 1.4.0
>>
>> someone could tell me what had happened in 1.5.1
>> 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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[semperos]

Is there a reason you don't use one of the methods exposed in 
clojure.lang.RT, e.g., makeClassLoader() or baseLoader() ?

On Thursday, May 9, 2013 2:00:54 AM UTC-4, Stream wrote:
>
> Hi all 
>
> i wanna change the classloader of Clojure RT. in 1.5.1 
> so , i try to 
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
> clojure.lang.Compiler.LOADER, cl) ); 
>
> but throws exception that cojure.lang.Compiler.LOADER is null 
>
> Caused by: java.lang.NullPointerException 
> at clojure.lang.RT.baseLoader(RT.java:2043) 
> at clojure.lang.RT.load(RT.java:417) 
> at clojure.lang.RT.load(RT.java:411) 
> at clojure.lang.RT.doInit(RT.java:447) 
> at clojure.lang.RT.(RT.java:329) 
> ... 9 more 
>
>
> However this is work in the 1.4.0 
>
> someone could tell me what had happened in 1.5.1 
> 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.

why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[stream]

Hi all

i wanna change the classloader of Clojure RT. in 1.5.1
so , i try to 
clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
clojure.lang.Compiler.LOADER, cl) );

but throws exception that cojure.lang.Compiler.LOADER is null

Caused by: java.lang.NullPointerException
at clojure.lang.RT.baseLoader(RT.java:2043)
at clojure.lang.RT.load(RT.java:417)
at clojure.lang.RT.load(RT.java:411)
at clojure.lang.RT.doInit(RT.java:447)
at clojure.lang.RT.(RT.java:329)
... 9 more


However this is work in the 1.4.0

someone could tell me what had happened in 1.5.1
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: Clojure 1.5.1

[Stuart Halloway]

Fixed, thanks.

Stu


On Sun, Mar 10, 2013 at 7:28 PM,  wrote:

> I think there's a typo in the download link on
> http://clojure.org/downloads:
>
> It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0*
> /clojure-1.5.1.zip<http://repo1.maven.org/maven2/org/clojure/clojure/1.5.0/clojure-1.5.1.zip>
> whereas it should be
> http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*1*
> /clojure-1.5.1.zip<http://repo1.maven.org/maven2/org/clojure/clojure/1.5.1/clojure-1.5.1.zip>
> (note the "1.5.1" vs. "1.5.0" in the second to last part of the URL)
>
>
> Am Sonntag, 10. März 2013 19:35:34 UTC+1 schrieb stuart@gmail.com:
>
>> Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:
>>
>> https://groups.google.com/d/**msg/clojure-dev/uAFM0Ti4AcQ/**GmnKmphF1BgJ<https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ>
>>
>> Getting Clojure:
>>
>>   Web:  http://clojure.org/downloads
>>   Lein/Maven:   :dependencies [[org.clojure/clojure "1.5.1"]]
>>
>> Note that it will take a few hours for the links above to become live,
>> as the completed build moves into Maven Central.
>>
>> Thanks,
>>
>> Stu Halloway
>> Clojure/core
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Clojure 1.5.1

[ke . mar . 92]

I think there's a typo in the download link on http://clojure.org/downloads:

It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0*
/clojure-1.5.1.zip<http://repo1.maven.org/maven2/org/clojure/clojure/1.5.0/clojure-1.5.1.zip>
whereas it should be http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*
1*/clojure-1.5.1.zip<http://repo1.maven.org/maven2/org/clojure/clojure/1.5.1/clojure-1.5.1.zip>
(note the "1.5.1" vs. "1.5.0" in the second to last part of the URL)


Am Sonntag, 10. März 2013 19:35:34 UTC+1 schrieb stuart@gmail.com:
>
> Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:
>
> https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ
>
> Getting Clojure:
>
>   Web:  http://clojure.org/downloads
>   Lein/Maven:   :dependencies [[org.clojure/clojure "1.5.1"]]
>
> Note that it will take a few hours for the links above to become live,
> as the completed build moves into Maven Central.
>
> Thanks,
>
> Stu Halloway
> Clojure/core
>

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

[Ghadi Shayban]

fyi - Rich's .idea/ crept in on the bug fix commit.

On Sunday, March 10, 2013 8:35:34 PM UTC+2, Stuart Halloway wrote:
>
> Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:
>
> https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ
>
> Getting Clojure:
>
>   Web:  http://clojure.org/downloads
>   Lein/Maven:   :dependencies [[org.clojure/clojure "1.5.1"]]
>
> Note that it will take a few hours for the links above to become live,
> as the completed build moves into Maven Central.
>
> Thanks,
>
> Stu Halloway
> Clojure/core
>

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

Clojure 1.5.1

[Stuart Halloway]

Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:

https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ

Getting Clojure:

  Web:  http://clojure.org/downloads
  Lein/Maven:   :dependencies [[org.clojure/clojure "1.5.1"]]

Note that it will take a few hours for the links above to become live,
as the completed build moves into Maven Central.

Thanks,

Stu Halloway
Clojure/core

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