Re: [ANN] Chestnut 0.7.0

[Makoto Hashimoto]

Hi Tim,

I branched  from the original source and set the version like
0.6.1-SNAPSHOT.
Controlling versions in ~/.lein/profiles.clj was slightly convenient and
worked for
the 0.6.0.

Makoto

2015-03-11 13:35 GMT+09:00 Tim Gilbert :

> Oh, that's odd. I don't have any entries in my own user plugins for "lein
> new" templates. (I'm assuming you meant ~/.lein/profiles.clj, right?)
>
> Is there some reason you have them in there? "lein new chestnut" should
> work just fine without them, but maybe I'm not understanding what you're
> trying to do.
>
> Tim
>
>
> On Monday, March 9, 2015 at 6:30:48 PM UTC-4, webber wrote:
>>
>> I've commented chestnut/lein-template from the ~/.lein/projects.clj as
>> follows, then it worked.
>> It worked using 0.6.0 if there was the chestnut/lein-template definition.
>> Was my usage wrong ?
>>
>> {:user {:plugins [
>>   [lein-try "0.4.3"]
>>   ;[lein-pprint "1.1.1"]
>>   [lein-ancient "0.6.4" :exclusions
>> [org.clojure/core.cache]]
>>   [lein-bikeshed "0.2.0"]
>>   [lein-ritz "0.7.0"]
>>   [lein-marginalia "0.8.0"]
>>   [http-kit/lein-template "1.0.0-SNAPSHOT"]
>>   [cider/cider-nrepl "0.9.0-SNAPSHOT"]
>>   [cljs-complete "0.1.1"]
>>   ;;[chestnut/lein-template "0.7.0"]
>>   ;;[chestnut/lein-template "0.6.0"]
>>   ]
>> :dependencies [;;[nrepl-inspect "0.4.1"]
>>[compliment "0.2.0"]
>>[ritz/ritz-nrepl-middleware "0.7.0"]
>>[cider/cider-nrepl "0.9.0-SNAPSHOT"]
>>[alembic "0.2.1"]
>>[org.clojure/tools.nrepl "0.2.7"]
>>]
>>
>> :repl-options {:nrepl-middleware
>>[cider.nrepl.middleware.classpath/wrap-classpath
>> cider.nrepl.middleware.complete/wrap-complete
>> cider.nrepl.middleware.info/wrap-info
>> cider.nrepl.middleware.inspect/wrap-inspect
>> cider.nrepl.middleware.stacktrace/wrap-stacktrace
>> cider.nrepl.middleware.trace/wrap-trace
>> ]}
>>
>> }}
>>
>> Makoto
>>
>>
>>> I ran into this same behavior, and then I realized it only happened if I
>>> run the "lein new" command if I'm *already in* a previously-created
>>> project created with "lein new chestnut". I'm guessing that something in
>>> the generated project.clj interferes some of the lein new behavior somehow.
>>> At any rate, running lein new in a directory without a project.clj file in
>>> it is working fine for me.
>>>
>>> Tim
>>>
>>> On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote:

 I tested the v 0.7.0 of chestnut and I encountered the following error.
 The v 0.6.0 works fine.

 $ lein new chestnut test-app
 Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from
 clojars
 Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from
 clojars
 Exception in thread "main" java.lang.ExceptionInInitializerError
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:270)
 at clojure.lang.RT.loadClassForName(RT.java:2093)
 at clojure.lang.RT.load(RT.java:430)
 at clojure.lang.RT.load(RT.java:411)
 at clojure.core$load$fn__5066.invoke(core.clj:5641)
 at clojure.core$load.doInvoke(core.clj:5640)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.core$load_one.invoke(core.clj:5446)
 at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
 at clojure.core$load_lib.doInvoke(core.clj:5485)
 at clojure.lang.RestFn.applyTo(RestFn.java:142)
 at clojure.core$apply.invoke(core.clj:626)
 at clojure.core$load_libs.doInvoke(core.clj:5524)
 at clojure.lang.RestFn.applyTo(RestFn.java:137)
 at clojure.core$apply.invoke(core.clj:626)
 at clojure.core$require.doInvoke(core.clj:5607)
 at clojure.lang.RestFn.invoke(RestFn.java:421)
 at stencil.core$loading__4958__auto__.invoke(core.clj:1)
 at stencil.core__init.load(Unknown Source)
 at stencil.core__init.(Unknown Source)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:270)
 at clojure.lang.RT.loadClassForName(RT.java:2093)
 at clojure.lang.RT.load(RT.java:430)
 at clojure.lang.RT.load(RT.java:411)
 at clojure.core$load$fn__5066.invoke(core.clj:5641)
 at clojure.core$load.doInvoke(core.clj:5640)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.core$load_one.invoke(core.clj:5446)
 at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
 at clojure.core$load_lib.doInvoke(core.clj:5485)
 at clojure.lang.RestFn.applyTo(RestFn.java:142)
 at clojure.core$apply.invoke(core.clj:626)
 at clojure

Re: [ANN] Dunaj project, an alternative core API for Clojure

[Dave Sann]

very interesting work and well presented, keep going.

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

Re: [ANN] Dunaj project, an alternative core API for Clojure

[Jozef Wagner]

Having modern Clojure features at hand, and free from having to support old
versions and existing application code, Dunaj has more freedom to test new
things and can take more liberal and fresh approach.

Next experiment is a short one, a bit opinionated, and it mainly deals with 
how Dunaj designs its public API.

Experiment #4: Towards Simpler API

With core API splitted into separate namespaces and with protocols being 
used to specify core abstractions, Dunaj further simplifies its API by 
providing and adhering to additional idioms, conventions and best 
practices. Moreover, Dunaj changes how compiler recognizes special symbols 
and makes them fully qualified.

You can read more about this experiment at http://www.dunaj.org 

Jozef

On Thursday, March 5, 2015 at 10:33:53 PM UTC+1, Jozef Wagner wrote:
>
> I'm happy to announce a project called Dunaj [1], which provides an 
> alternative core API for Clojure. Its main aim is to experimentally test 
> major additions to the language. 
>
> Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve 
> Clojure language and its core API. It deals with language features that 
> require changes across different parts of Clojure and which cannot be 
> evaluated in isolation. Dunaj aims to bring Clojure even more towards 
> simplicity, consistency and performance. 
> It is intended to be used by regular Clojure developers, either for 
> application or library development.
>
> Dunaj was created to test 10 experiments that bring significant changes to 
> the Clojure language. As there is a substantial number of additions and 
> changes, I want to try a bit unconventional approach here. Before I'll 
> release the actual library, I will introduce Dunaj's experiments in a 
> series of individual posts. Every part states the motivation behind the 
> experiment, introduces changes and additions to the language and 
> demonstrates its intended use. If you do not want to miss any of this, you 
> may want to register for a mailing list at [1] or follow @dunajproject at 
> Twitter.
>
> -- Jozef Wagner
>
> [1] http://www.dunaj.org/ 
>
>

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

[Tassilo Horn]

Aaron France  writes:

> Here is output compiling on the different machines:
> https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a

What does your Makefile look like?  Does it just call "lein uberjar" or
what?

I think it's strange that even on the machine where it builds
successfully every namespace seems to get compiled twice.

Bye,
Tassilo

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

Re: Project fails to compile on different machines

[Aaron France]

Hi,

The relevant parts of the Makefile are 
here: https://gist.github.com/AeroNotix/f65a846781357db59ced

On Wednesday, 11 March 2015 14:01:20 UTC+1, Tassilo Horn wrote:
>
> Aaron France > writes: 
>
> > Here is output compiling on the different machines: 
> > https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a 
>
> What does your Makefile look like?  Does it just call "lein uberjar" or 
> what? 
>
> I think it's strange that even on the machine where it builds 
> successfully every namespace seems to get compiled twice. 
>
> Bye, 
> Tassilo 
>

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

Re: Project fails to compile on different machines

[Aaron France]

The makefile calls compile then uberjar, which is why things are compiled 
twice, so it seems my problem lies *just* with uberjar.


Any idea why compile would succeed but then uberjar would fail?

On Wednesday, 11 March 2015 14:22:17 UTC+1, Aaron France wrote:
>
> Hi,
>
> The relevant parts of the Makefile are here: 
> https://gist.github.com/AeroNotix/f65a846781357db59ced
>
> On Wednesday, 11 March 2015 14:01:20 UTC+1, Tassilo Horn wrote:
>>
>> Aaron France  writes: 
>>
>> > Here is output compiling on the different machines: 
>> > https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a 
>>
>> What does your Makefile look like?  Does it just call "lein uberjar" or 
>> what? 
>>
>> I think it's strange that even on the machine where it builds 
>> successfully every namespace seems to get compiled twice. 
>>
>> Bye, 
>> Tassilo 
>>
>

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

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times

[David Nolen]

A couple of people mentioned this happened while trying out the Quick
Start. If eval takes a long time it could be because you don't have the
right browser tab focused. If the REPL is truly hung due to some kind of
communication issue, try refreshing the browser. The bREPL uses an iframe
which can be a little finicky particularly in Safari in my experience.

HTH,
David

On Wed, Mar 11, 2015 at 9:38 AM, Peter West  wrote:

> On Tuesday, 10 March 2015 09:41:45 UTC+10, David Nolen  wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> > New release version: 0.0-3058
> >
> > The new Quick Start is essential reading even if you are a relatively
> > experienced ClojureScript developer.
>
>
> I did this, and worked through the example.  When I got to
>
> Require your namespace by evaluating (require '[hello-world.core :as
> hello])
>
> the REPL hung.  Any suggestions?
>
> --
> 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/d/optout.

Re: Could use a better error message here (using a list in update-in)

[John Gabriele]

Ok, done (CLJ-1672). Though, as an aside, that site doesn't allow 
connection via https. One has to send all their credentials in the clear...


On Tuesday, March 10, 2015 at 11:17:58 AM UTC-4, Stuart Sierra wrote:
>
> Please file a ticket in JIRA and tag it with "errormsg"
> http://dev.clojure.org/display/community/Creating+Tickets
>
> –S
>
>
> On Tuesday, March 10, 2015 at 3:13:36 PM UTC, John Gabriele wrote:
>>
>> In Clojure v1.6.0. This one confused me when I'd accidentally passed a 
>> list in to `update-in` instead of a vector:
>>
>

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

Re: [ANN] Chestnut 0.7.0

[Arne Brasseur]

Sorry for the delayed response, I didn't have email notifications set up 
correctly.

Interesting way of using ~/.lein/profiles.clj. I hadn't considered that yet.

If you want to run a modified Chestnut the easiest is to run lein install 
in your chestnut repo. You shouldn't have to manually bump the version. 
E.g. the current version is 0.7.0, if you locally install a different 0.7.0 
then lein new will use that one. One caveat, if it's a -SNAPSHOT version 
you're installing, you'll also have to use lein new --snapshot to use it.

Hope that helps!

On Wednesday, 11 March 2015 09:09:30 UTC+1, webber wrote:
>
> Hi Tim,
>
> I branched  from the original source and set the version like 
> 0.6.1-SNAPSHOT.
> Controlling versions in ~/.lein/profiles.clj was slightly convenient and 
> worked for 
> the 0.6.0.
>
> Makoto
>
> 2015-03-11 13:35 GMT+09:00 Tim Gilbert >:
>
>> Oh, that's odd. I don't have any entries in my own user plugins for "lein 
>> new" templates. (I'm assuming you meant ~/.lein/profiles.clj, right?)
>>
>> Is there some reason you have them in there? "lein new chestnut" should 
>> work just fine without them, but maybe I'm not understanding what you're 
>> trying to do.
>>
>> Tim
>>
>>
>> On Monday, March 9, 2015 at 6:30:48 PM UTC-4, webber wrote:
>>>
>>> I've commented chestnut/lein-template from the ~/.lein/projects.clj as 
>>> follows, then it worked.
>>> It worked using 0.6.0 if there was the chestnut/lein-template 
>>> definition. Was my usage wrong ?
>>>
>>> {:user {:plugins [
>>>   [lein-try "0.4.3"]
>>>   ;[lein-pprint "1.1.1"]
>>>   [lein-ancient "0.6.4" :exclusions 
>>> [org.clojure/core.cache]]
>>>   [lein-bikeshed "0.2.0"]
>>>   [lein-ritz "0.7.0"]
>>>   [lein-marginalia "0.8.0"]
>>>   [http-kit/lein-template "1.0.0-SNAPSHOT"]
>>>   [cider/cider-nrepl "0.9.0-SNAPSHOT"]
>>>   [cljs-complete "0.1.1"]
>>>   ;;[chestnut/lein-template "0.7.0"]
>>>   ;;[chestnut/lein-template "0.6.0"]
>>>   ]
>>> :dependencies [;;[nrepl-inspect "0.4.1"]
>>>[compliment "0.2.0"]
>>>[ritz/ritz-nrepl-middleware "0.7.0"]
>>>[cider/cider-nrepl "0.9.0-SNAPSHOT"]
>>>[alembic "0.2.1"]
>>>[org.clojure/tools.nrepl "0.2.7"]
>>>]
>>>
>>> :repl-options {:nrepl-middleware
>>>[cider.nrepl.middleware.classpath/wrap-classpath
>>> cider.nrepl.middleware.complete/wrap-complete
>>> cider.nrepl.middleware.info/wrap-info
>>> cider.nrepl.middleware.inspect/wrap-inspect
>>> cider.nrepl.middleware.
>>> stacktrace/wrap-stacktrace
>>> cider.nrepl.middleware.trace/wrap-trace
>>> ]}
>>>
>>> }}
>>>
>>> Makoto
>>>  
>>>
 I ran into this same behavior, and then I realized it only happened if 
 I run the "lein new" command if I'm *already in* a previously-created 
 project created with "lein new chestnut". I'm guessing that something in 
 the generated project.clj interferes some of the lein new behavior 
 somehow. 
 At any rate, running lein new in a directory without a project.clj file in 
 it is working fine for me.

 Tim

 On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote:
>
> I tested the v 0.7.0 of chestnut and I encountered the following error.
> The v 0.6.0 works fine.
>
> $ lein new chestnut test-app
> Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from 
> clojars
> Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from 
> clojars
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at clojure.lang.RT.loadClassForName(RT.java:2093)
> at clojure.lang.RT.load(RT.java:430)
> at clojure.lang.RT.load(RT.java:411)
> at clojure.core$load$fn__5066.invoke(core.clj:5641)
> at clojure.core$load.doInvoke(core.clj:5640)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5446)
> at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
> at clojure.core$load_lib.doInvoke(core.clj:5485)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:626)
> at clojure.core$load_libs.doInvoke(core.clj:5524)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:626)
> at clojure.core$require.doInvoke(core.clj:5607)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at stencil.core$loading__4958__auto__.invoke(core.clj:1)
> at st

Re: Project fails to compile on different machines

[Tassilo Horn]

Aaron France  writes:

Hi Aaron,

> The makefile calls compile then uberjar, which is why things are
> compiled twice, so it seems my problem lies *just* with uberjar.

So why do you compile and then let uberjar compile again?  And there's
also no need to call the deps target explicitly.  Leiningen does that
automatically.  (Or all in all, I don't see any reason why you use a
Makefile at all.)

> Any idea why compile would succeed but then uberjar would fail?

A shot in the blue: GNU make builds receipes in parallel if they don't
depend on each other and MAKEFLAGS contains the -jN flag where N denotes
the max number of parallel makes.  Your receipes don't depend on each
other thus could be executed in parallel.  But then there's a chance
that two compilations (one from lein compile, one from lein uberjar) run
in parallel and overwrite each other's files, or a file gets loaded
which is currently being written to.

So my guess is, on system 1 MAKEFLAGS is -j1 or unset, on system 2
MAKEFLAGS contains at least -j2.

Bye,
Tassilo

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

Re: Project fails to compile on different machines

[Aaron France]

The makefile is not ran in parallel -- the Makefile is being explicit for
non-Clojure users.

Read above -- the issue is solved, there's an issue with the profiles and
AOT.

On Wed, 11 Mar 2015 at 16:21 Tassilo Horn  wrote:

> Aaron France  writes:
>
> Hi Aaron,
>
> > The makefile calls compile then uberjar, which is why things are
> > compiled twice, so it seems my problem lies *just* with uberjar.
>
> So why do you compile and then let uberjar compile again?  And there's
> also no need to call the deps target explicitly.  Leiningen does that
> automatically.  (Or all in all, I don't see any reason why you use a
> Makefile at all.)
>
> > Any idea why compile would succeed but then uberjar would fail?
>
> A shot in the blue: GNU make builds receipes in parallel if they don't
> depend on each other and MAKEFLAGS contains the -jN flag where N denotes
> the max number of parallel makes.  Your receipes don't depend on each
> other thus could be executed in parallel.  But then there's a chance
> that two compilations (one from lein compile, one from lein uberjar) run
> in parallel and overwrite each other's files, or a file gets loaded
> which is currently being written to.
>
> So my guess is, on system 1 MAKEFLAGS is -j1 or unset, on system 2
> MAKEFLAGS contains at least -j2.
>
> Bye,
> Tassilo
>

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

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Timothy Baldridge]

This is interesting, but there could be many things in play here. Try
re-running the tests outside of lein (via compilation to a uberjar and then
running with java -jar) and also use criterium, as it will warn about many
things that coul effect performance .

https://github.com/hugoduncan/criterium

Timothy Baldridge

On Wed, Mar 11, 2015 at 9:38 AM, Brent Millare 
wrote:

> Doing some simple microbenchmarks, I found something unexpected:
>
> (time
>  (let [v (volatile! 1)]
>(dotimes [x 1]
>  (vreset! v @v
> "Elapsed time: 1016.992146 msecs"
>
> (time
>  (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>(dotimes [x 1]
>  (.set v (.get v)
> "Elapsed time: 672.869727 msecs"
>
> (time
>  (let [v (java.util.concurrent.atomic.AtomicReference. {})]
>(dotimes [x 1]
>  (.set v (.get v)
> "Elapsed time: 678.143133 msecs"
>
> (time
>  (let [v (atom 1)]
>(dotimes [x 1]
>  (reset! v @v
> "Elapsed time: 1100.689493 msecs"
>
> I expected volatile's to be faster. Maybe I'm not understanding the
> correct use case for volatiles but java.util.concurrent.atomic.Atomic*
> seems to be clearly the most performant. Given the downsides of using
> volatiles, is their existence justified when safer and faster alternatives
> exist?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Brent Millare]

Well not exactly what you said cause I'm lazy, but a little bit more 
controlled:

timereference.clj:
(println "Java: "(System/getProperty "java.version"))
(println (clojure-version))

(dotimes [y 10]
  (print "volatile: ")
  (time
   (let [v (volatile! 1)]
 (dotimes [x 1]
   (vreset! v @v

  (print "AtomicLong: ")
  (time
   (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
 (dotimes [x 1]
   (.set v (.get v)

  (print "AtomicReference: ")
  (time
   (let [v (java.util.concurrent.atomic.AtomicReference. {})]
 (dotimes [x 1]
   (.set v (.get v)

  (print "atom: ")
  (time
   (let [v (atom 1)]
 (dotimes [x 1]
   (reset! v @v)


[bmillare@sakura ~]$ java -server -cp 
.m2/repository/org/clojure/clojure/1.7.0-alpha5/clojure-1.7.0-alpha5.jar 
clojure.main timereference.clj 
Java:  1.7.0_75
1.7.0-alpha5
volatile: "Elapsed time: 793.525092 msecs"
AtomicLong: "Elapsed time: 606.658899 msecs"
AtomicReference: "Elapsed time: 606.253989 msecs"
atom: "Elapsed time: 881.198546 msecs"
volatile: "Elapsed time: 787.714655 msecs"
AtomicLong: "Elapsed time: 603.810759 msecs"
AtomicReference: "Elapsed time: 603.811366 msecs"
atom: "Elapsed time: 1417.625552 msecs"
volatile: "Elapsed time: 794.154652 msecs"
AtomicLong: "Elapsed time: 603.718131 msecs"
AtomicReference: "Elapsed time: 603.723479 msecs"
atom: "Elapsed time: 866.220579 msecs"
volatile: "Elapsed time: 787.459397 msecs"
AtomicLong: "Elapsed time: 603.735881 msecs"
AtomicReference: "Elapsed time: 603.720108 msecs"
atom: "Elapsed time: 866.208679 msecs"
volatile: "Elapsed time: 787.455661 msecs"
AtomicLong: "Elapsed time: 603.720906 msecs"
AtomicReference: "Elapsed time: 603.735316 msecs"
atom: "Elapsed time: 866.226066 msecs"
volatile: "Elapsed time: 787.455482 msecs"
AtomicLong: "Elapsed time: 603.720222 msecs"
AtomicReference: "Elapsed time: 603.718667 msecs"
atom: "Elapsed time: 866.205402 msecs"
volatile: "Elapsed time: 789.429405 msecs"
AtomicLong: "Elapsed time: 603.71242 msecs"
AtomicReference: "Elapsed time: 603.717922 msecs"
atom: "Elapsed time: 866.212896 msecs"
volatile: "Elapsed time: 787.461736 msecs"
AtomicLong: "Elapsed time: 603.728396 msecs"
AtomicReference: "Elapsed time: 603.727234 msecs"
atom: "Elapsed time: 866.203579 msecs"
volatile: "Elapsed time: 787.462185 msecs"
AtomicLong: "Elapsed time: 603.721207 msecs"
AtomicReference: "Elapsed time: 603.716769 msecs"
atom: "Elapsed time: 866.207913 msecs"
volatile: "Elapsed time: 787.468805 msecs"
AtomicLong: "Elapsed time: 603.721715 msecs"
AtomicReference: "Elapsed time: 603.73172 msecs"
atom: "Elapsed time: 866.210223 msecs"


On Wednesday, March 11, 2015 at 11:57:50 AM UTC-4, tbc++ wrote:
>
> This is interesting, but there could be many things in play here. Try 
> re-running the tests outside of lein (via compilation to a uberjar and then 
> running with java -jar) and also use criterium, as it will warn about many 
> things that coul effect performance . 
>
> https://github.com/hugoduncan/criterium
>
> Timothy Baldridge
>
> On Wed, Mar 11, 2015 at 9:38 AM, Brent Millare  > wrote:
>
>> Doing some simple microbenchmarks, I found something unexpected:
>>
>> (time
>>  (let [v (volatile! 1)]
>>(dotimes [x 1]
>>  (vreset! v @v
>> "Elapsed time: 1016.992146 msecs"
>>
>> (time
>>  (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>>(dotimes [x 1]
>>  (.set v (.get v)
>> "Elapsed time: 672.869727 msecs"
>>
>> (time
>>  (let [v (java.util.concurrent.atomic.AtomicReference. {})]
>>(dotimes [x 1]
>>  (.set v (.get v)
>> "Elapsed time: 678.143133 msecs"
>>
>> (time
>>  (let [v (atom 1)]
>>(dotimes [x 1]
>>  (reset! v @v
>> "Elapsed time: 1100.689493 msecs"
>>
>> I expected volatile's to be faster. Maybe I'm not understanding the 
>> correct use case for volatiles but java.util.concurrent.atomic.Atomic* 
>> seems to be clearly the most performant. Given the downsides of using 
>> volatiles, is their existence justified when safer and faster alternatives 
>> exist?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> pro

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Timothy Baldridge]

There's many other factors involved here though, GC, JIT warmup, etc.
That's kindof what criterium helps out with, removing all the variables and
running something until the JIT has warmed up enough (10 iterations
probably isn't enough).

Timothy

On Wed, Mar 11, 2015 at 10:19 AM, Brent Millare 
wrote:

> Well not exactly what you said cause I'm lazy, but a little bit more
> controlled:
>
> timereference.clj:
> (println "Java: "(System/getProperty "java.version"))
> (println (clojure-version))
>
> (dotimes [y 10]
>   (print "volatile: ")
>   (time
>(let [v (volatile! 1)]
>  (dotimes [x 1]
>(vreset! v @v
>
>   (print "AtomicLong: ")
>   (time
>(let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>  (dotimes [x 1]
>(.set v (.get v)
>
>   (print "AtomicReference: ")
>   (time
>(let [v (java.util.concurrent.atomic.AtomicReference. {})]
>  (dotimes [x 1]
>(.set v (.get v)
>
>   (print "atom: ")
>   (time
>(let [v (atom 1)]
>  (dotimes [x 1]
>(reset! v @v)
>
>
> [bmillare@sakura ~]$ java -server -cp
> .m2/repository/org/clojure/clojure/1.7.0-alpha5/clojure-1.7.0-alpha5.jar
> clojure.main timereference.clj
> Java:  1.7.0_75
> 1.7.0-alpha5
> volatile: "Elapsed time: 793.525092 msecs"
> AtomicLong: "Elapsed time: 606.658899 msecs"
> AtomicReference: "Elapsed time: 606.253989 msecs"
> atom: "Elapsed time: 881.198546 msecs"
> volatile: "Elapsed time: 787.714655 msecs"
> AtomicLong: "Elapsed time: 603.810759 msecs"
> AtomicReference: "Elapsed time: 603.811366 msecs"
> atom: "Elapsed time: 1417.625552 msecs"
> volatile: "Elapsed time: 794.154652 msecs"
> AtomicLong: "Elapsed time: 603.718131 msecs"
> AtomicReference: "Elapsed time: 603.723479 msecs"
> atom: "Elapsed time: 866.220579 msecs"
> volatile: "Elapsed time: 787.459397 msecs"
> AtomicLong: "Elapsed time: 603.735881 msecs"
> AtomicReference: "Elapsed time: 603.720108 msecs"
> atom: "Elapsed time: 866.208679 msecs"
> volatile: "Elapsed time: 787.455661 msecs"
> AtomicLong: "Elapsed time: 603.720906 msecs"
> AtomicReference: "Elapsed time: 603.735316 msecs"
> atom: "Elapsed time: 866.226066 msecs"
> volatile: "Elapsed time: 787.455482 msecs"
> AtomicLong: "Elapsed time: 603.720222 msecs"
> AtomicReference: "Elapsed time: 603.718667 msecs"
> atom: "Elapsed time: 866.205402 msecs"
> volatile: "Elapsed time: 789.429405 msecs"
> AtomicLong: "Elapsed time: 603.71242 msecs"
> AtomicReference: "Elapsed time: 603.717922 msecs"
> atom: "Elapsed time: 866.212896 msecs"
> volatile: "Elapsed time: 787.461736 msecs"
> AtomicLong: "Elapsed time: 603.728396 msecs"
> AtomicReference: "Elapsed time: 603.727234 msecs"
> atom: "Elapsed time: 866.203579 msecs"
> volatile: "Elapsed time: 787.462185 msecs"
> AtomicLong: "Elapsed time: 603.721207 msecs"
> AtomicReference: "Elapsed time: 603.716769 msecs"
> atom: "Elapsed time: 866.207913 msecs"
> volatile: "Elapsed time: 787.468805 msecs"
> AtomicLong: "Elapsed time: 603.721715 msecs"
> AtomicReference: "Elapsed time: 603.73172 msecs"
> atom: "Elapsed time: 866.210223 msecs"
>
>
> On Wednesday, March 11, 2015 at 11:57:50 AM UTC-4, tbc++ wrote:
>>
>> This is interesting, but there could be many things in play here. Try
>> re-running the tests outside of lein (via compilation to a uberjar and then
>> running with java -jar) and also use criterium, as it will warn about many
>> things that coul effect performance .
>>
>> https://github.com/hugoduncan/criterium
>>
>> Timothy Baldridge
>>
>> On Wed, Mar 11, 2015 at 9:38 AM, Brent Millare 
>> wrote:
>>
>>> Doing some simple microbenchmarks, I found something unexpected:
>>>
>>> (time
>>>  (let [v (volatile! 1)]
>>>(dotimes [x 1]
>>>  (vreset! v @v
>>> "Elapsed time: 1016.992146 msecs"
>>>
>>> (time
>>>  (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>>>(dotimes [x 1]
>>>  (.set v (.get v)
>>> "Elapsed time: 672.869727 msecs"
>>>
>>> (time
>>>  (let [v (java.util.concurrent.atomic.AtomicReference. {})]
>>>(dotimes [x 1]
>>>  (.set v (.get v)
>>> "Elapsed time: 678.143133 msecs"
>>>
>>> (time
>>>  (let [v (atom 1)]
>>>(dotimes [x 1]
>>>  (reset! v @v
>>> "Elapsed time: 1100.689493 msecs"
>>>
>>> I expected volatile's to be faster. Maybe I'm not understanding the
>>> correct use case for volatiles but java.util.concurrent.atomic.Atomic*
>>> seems to be clearly the most performant. Given the downsides of using
>>> volatiles, is their existence justified when safer and faster alternatives
>>> exist?
>>>
>>> --
>>> 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://gr

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Brent Millare]

I find it hard to believe GC would be a factor since there is very little 
being generated here. Also, while the outside loop is only 10 iterations of 
timings, in the inside loops the code is called for 100 million iterations. 
Anyways, running it with criterium didn't change the ranking.

Here is the output:
volatile: WARNING: Final GC required 1.149417308725186 % of runtime
Evaluation count : 4156079100 in 60 samples of 69267985 calls.
 Execution time mean : 12.975339 ns
Execution time std-deviation : 0.188921 ns
   Execution time lower quantile : 12.823222 ns ( 2.5%)
   Execution time upper quantile : 13.272950 ns (97.5%)
   Overhead used : 1.613416 ns
AtomicLong: Evaluation count : 6921767160 in 60 samples of 115362786 calls.
 Execution time mean : 7.155989 ns
Execution time std-deviation : 0.124147 ns
   Execution time lower quantile : 7.048738 ns ( 2.5%)
   Execution time upper quantile : 7.330448 ns (97.5%)
   Overhead used : 1.613416 ns
AtomicReference: Evaluation count : 5814704460 in 60 samples of 96911741 
calls.
 Execution time mean : 8.791224 ns
Execution time std-deviation : 0.185229 ns
   Execution time lower quantile : 8.564921 ns ( 2.5%)
   Execution time upper quantile : 9.340265 ns (97.5%)
   Overhead used : 1.613416 ns

Found 4 outliers in 60 samples (6.6667 %)
low-severe 2 (3. %)
low-mild 2 (3. %)
 Variance from outliers : 9.4134 % Variance is slightly inflated by outliers
atom: Evaluation count : 4038207840 in 60 samples of 67303464 calls.
 Execution time mean : 13.007604 ns
Execution time std-deviation : 0.202285 ns
   Execution time lower quantile : 12.819268 ns ( 2.5%)
   Execution time upper quantile : 13.275983 ns (97.5%)
   Overhead used : 1.613416 ns

Note: I bench the get/set expression, not the creation of the 
volatile/atomic*/atom

eg.
(let [v (volatile! 1)]
  (c/bench (vreset! v @v)))

On Wednesday, March 11, 2015 at 12:30:06 PM UTC-4, tbc++ wrote:
>
> There's many other factors involved here though, GC, JIT warmup, etc. 
> That's kindof what criterium helps out with, removing all the variables and 
> running something until the JIT has warmed up enough (10 iterations 
> probably isn't enough). 
>
> Timothy
>
>
>  

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

Composing Stuart Sierra's components

[Colin Yates]

I have a non-trivial component which requires a bunch of internal and 
external collaborators to work. This component is itself re-usable. 

What I really want to do is have ReusableComponent be a component in a 
system so it can pull its external collaborators. However, 
ReusableComponent constructs its own services etc. so it really want to be 
(or at least have access to) a system.

For example, let's say I have the following:

(defrecord InternalToReusableComponent [bus]
  (component/Lifecycle
(start [this]...))

(defrecord ReusableComponent [bus logger]
  (component/Lifecycle
(start [this]
  
  this)
))

(defn reusable-component-system [external-collaborator]
  (component/system-map
:bus ()
:logger ()
:reusable-component (component/using (map->ReusableComponent {}) [:bus 
:logger external-collaborator]))

Fine - I now have a system from which I can pull the reusable component. 
However, where does 'external-collaborator' come from? Obviously there is a 
larger system which I want this component to be part of so I can do:

(defn larger-system []
  (component/system-map
 :external-collaborator (...)
 :reusable-component (component/using (some-magic-glue) 
[:external-collaborator])))

I am struggling to see what (some-magic-glue) should be. I imagine it needs 
to be something like:

(defrecord SystemAdaptor [external-collaborator internal-system]
  component/Lifecycle
  (start [this]
(let [internal-system (or internal-system (reusable-component-system 
external-collaborator))
   internal-system (component/start internal-system)]
 (assoc this :internal-system internal-system)))
  (stop [this]
(let [internal-system (:internal-system this)
   internal-system (component/stop internal-system]
 (assoc this :internal-system internal-system)))

but it all feels a bit yuck.

I can't merge the two systems because the reusable component is chocka full 
of very fine grained command handlers and both the internal and external 
systems will have their own 'bus' for example. I could namespace the keys 
but that again feels painful...

Hope that is clear - and I look forward to your thoughts :).

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

[Pablo Nussembaum]

Have looked at http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ that 
comes with Postgres 9.4 and it's really really powerful and fast.

On 03/06/2015 09:25 PM, Sam Raker wrote:
> I'm trying to create an n-gram[1] corpus out of song lyrics. I'm breaking 
> individual songs into lines, which are then split into words, so you end up 
> with something like
>
> {0 {0 "go" 1 "tell" 2 "aunt" 3 "rhodie"} 1 {0 "the" 1 "old" 2 "grey" 3 
> "goose" 4 "is" 5 "dead"}...}
>
> (Yes, maps with integer keys is kind of dumb; I thought about using vectors, 
> but this is all going into MongoDB temporarily, and I'd rather just deal with 
> maps instead of messing with Mongo's
> somewhat lacking array-handling stuff.)
>
> The idea, ultimately, is to build a front-end that would allow users to, 
> e.g., search for all songs that contain the (sub)string "aunt rhodie", or see 
> how many times The Rolling Stones use the word
> "woman" vs how many times the Beatles do, etc. The inspiration comes largely 
> from projects like COCA[2]. 
>
> I'm wondering if any of you have opinions about which database to use (Mongo 
> is most likely just a stopgap), and how best to architect it. I'm most 
> familiar with MySQL and Mongo, but I'd rather not
> be limited by just those two if there's a better option out there. I'm 
> thinking that I'll probably end up storing tokens over types--e.g., each word 
> would be stored individually, as opposed to
> having an entry for, e.g., "the" that stores every instance of the word 
> "the." I was also thinking that I'll probably have to end up storing each 
> token's "previous" and "next", either as full
> references or just as strings. This seems potentially inefficient, however. 
>
> (I could've just gone to StackOverflow with this, but figured I'm more likely 
> to get a real answer here, because you all seem so smart and nice?)
>
>
> Thanks!
>
>
>
> [1] https://en.wikipedia.org/wiki/N-gram
> [2] http://corpus.byu.edu/coca/
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout.

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

Re: Composing Stuart Sierra's components

[adrian . medina]

You can specify component dependencies using the 'using' function as you 
know. As long as you know the key of the component in the system you can 
specify this dependency wherever you construct the component. If you want 
to parameterize dependencies, write a constructor function which takes the 
external dependency as a value. 

On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:
>
> I have a non-trivial component which requires a bunch of internal and 
> external collaborators to work. This component is itself re-usable. 
>
> What I really want to do is have ReusableComponent be a component in a 
> system so it can pull its external collaborators. However, 
> ReusableComponent constructs its own services etc. so it really want to be 
> (or at least have access to) a system.
>
> For example, let's say I have the following:
>
> (defrecord InternalToReusableComponent [bus]
>   (component/Lifecycle
> (start [this]...))
>
> (defrecord ReusableComponent [bus logger]
>   (component/Lifecycle
> (start [this]
>   
>   this)
> ))
>
> (defn reusable-component-system [external-collaborator]
>   (component/system-map
> :bus ()
> :logger ()
> :reusable-component (component/using (map->ReusableComponent {}) [:bus 
> :logger external-collaborator]))
>
> Fine - I now have a system from which I can pull the reusable component. 
> However, where does 'external-collaborator' come from? Obviously there is a 
> larger system which I want this component to be part of so I can do:
>
> (defn larger-system []
>   (component/system-map
>  :external-collaborator (...)
>  :reusable-component (component/using (some-magic-glue) 
> [:external-collaborator])))
>
> I am struggling to see what (some-magic-glue) should be. I imagine it 
> needs to be something like:
>
> (defrecord SystemAdaptor [external-collaborator internal-system]
>   component/Lifecycle
>   (start [this]
> (let [internal-system (or internal-system (reusable-component-system 
> external-collaborator))
>internal-system (component/start internal-system)]
>  (assoc this :internal-system internal-system)))
>   (stop [this]
> (let [internal-system (:internal-system this)
>internal-system (component/stop internal-system]
>  (assoc this :internal-system internal-system)))
>
> but it all feels a bit yuck.
>
> I can't merge the two systems because the reusable component is chocka 
> full of very fine grained command handlers and both the internal and 
> external systems will have their own 'bus' for example. I could namespace 
> the keys but that again feels painful...
>
> Hope that is clear - and I look forward to your thoughts :).
>

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

[Colin Yates]

Hi Adrian - I don't follow how that helps integrate two different
systems - I wonder if my question was unclear or I am missing
something in your answer. Would you mind posting some pseudo code to
clarify please?

On 11 March 2015 at 18:32,   wrote:
> You can specify component dependencies using the 'using' function as you
> know. As long as you know the key of the component in the system you can
> specify this dependency wherever you construct the component. If you want to
> parameterize dependencies, write a constructor function which takes the
> external dependency as a value.
>
> On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:
>>
>> I have a non-trivial component which requires a bunch of internal and
>> external collaborators to work. This component is itself re-usable.
>>
>> What I really want to do is have ReusableComponent be a component in a
>> system so it can pull its external collaborators. However, ReusableComponent
>> constructs its own services etc. so it really want to be (or at least have
>> access to) a system.
>>
>> For example, let's say I have the following:
>>
>> (defrecord InternalToReusableComponent [bus]
>>   (component/Lifecycle
>> (start [this]...))
>>
>> (defrecord ReusableComponent [bus logger]
>>   (component/Lifecycle
>> (start [this]
>>
>>   this)
>> ))
>>
>> (defn reusable-component-system [external-collaborator]
>>   (component/system-map
>> :bus ()
>> :logger ()
>> :reusable-component (component/using (map->ReusableComponent {}) [:bus
>> :logger external-collaborator]))
>>
>> Fine - I now have a system from which I can pull the reusable component.
>> However, where does 'external-collaborator' come from? Obviously there is a
>> larger system which I want this component to be part of so I can do:
>>
>> (defn larger-system []
>>   (component/system-map
>>  :external-collaborator (...)
>>  :reusable-component (component/using (some-magic-glue)
>> [:external-collaborator])))
>>
>> I am struggling to see what (some-magic-glue) should be. I imagine it
>> needs to be something like:
>>
>> (defrecord SystemAdaptor [external-collaborator internal-system]
>>   component/Lifecycle
>>   (start [this]
>> (let [internal-system (or internal-system (reusable-component-system
>> external-collaborator))
>>internal-system (component/start internal-system)]
>>  (assoc this :internal-system internal-system)))
>>   (stop [this]
>> (let [internal-system (:internal-system this)
>>internal-system (component/stop internal-system]
>>  (assoc this :internal-system internal-system)))
>>
>> but it all feels a bit yuck.
>>
>> I can't merge the two systems because the reusable component is chocka
>> full of very fine grained command handlers and both the internal and
>> external systems will have their own 'bus' for example. I could namespace
>> the keys but that again feels painful...
>>
>> Hope that is clear - and I look forward to your thoughts :).
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Composing Stuart Sierra's components

[adrian . medina]

I believe I misunderstood your question; I didn't realize it was system (as 
opposed to any general component) specific. I think systems can be merged 
together (via 'merge'). Would that help? 

On Wednesday, March 11, 2015 at 2:40:14 PM UTC-4, Colin Yates wrote:
>
> Hi Adrian - I don't follow how that helps integrate two different 
> systems - I wonder if my question was unclear or I am missing 
> something in your answer. Would you mind posting some pseudo code to 
> clarify please? 
>
> On 11 March 2015 at 18:32,  > wrote: 
> > You can specify component dependencies using the 'using' function as you 
> > know. As long as you know the key of the component in the system you can 
> > specify this dependency wherever you construct the component. If you 
> want to 
> > parameterize dependencies, write a constructor function which takes the 
> > external dependency as a value. 
> > 
> > On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote: 
> >> 
> >> I have a non-trivial component which requires a bunch of internal and 
> >> external collaborators to work. This component is itself re-usable. 
> >> 
> >> What I really want to do is have ReusableComponent be a component in a 
> >> system so it can pull its external collaborators. However, 
> ReusableComponent 
> >> constructs its own services etc. so it really want to be (or at least 
> have 
> >> access to) a system. 
> >> 
> >> For example, let's say I have the following: 
> >> 
> >> (defrecord InternalToReusableComponent [bus] 
> >>   (component/Lifecycle 
> >> (start [this]...)) 
> >> 
> >> (defrecord ReusableComponent [bus logger] 
> >>   (component/Lifecycle 
> >> (start [this] 
> >> 
> >>   this) 
> >> )) 
> >> 
> >> (defn reusable-component-system [external-collaborator] 
> >>   (component/system-map 
> >> :bus () 
> >> :logger () 
> >> :reusable-component (component/using (map->ReusableComponent {}) 
> [:bus 
> >> :logger external-collaborator])) 
> >> 
> >> Fine - I now have a system from which I can pull the reusable 
> component. 
> >> However, where does 'external-collaborator' come from? Obviously there 
> is a 
> >> larger system which I want this component to be part of so I can do: 
> >> 
> >> (defn larger-system [] 
> >>   (component/system-map 
> >>  :external-collaborator (...) 
> >>  :reusable-component (component/using (some-magic-glue) 
> >> [:external-collaborator]))) 
> >> 
> >> I am struggling to see what (some-magic-glue) should be. I imagine it 
> >> needs to be something like: 
> >> 
> >> (defrecord SystemAdaptor [external-collaborator internal-system] 
> >>   component/Lifecycle 
> >>   (start [this] 
> >> (let [internal-system (or internal-system 
> (reusable-component-system 
> >> external-collaborator)) 
> >>internal-system (component/start internal-system)] 
> >>  (assoc this :internal-system internal-system))) 
> >>   (stop [this] 
> >> (let [internal-system (:internal-system this) 
> >>internal-system (component/stop internal-system] 
> >>  (assoc this :internal-system internal-system))) 
> >> 
> >> but it all feels a bit yuck. 
> >> 
> >> I can't merge the two systems because the reusable component is chocka 
> >> full of very fine grained command handlers and both the internal and 
> >> external systems will have their own 'bus' for example. I could 
> namespace 
> >> the keys but that again feels painful... 
> >> 
> >> Hope that is clear - and I look forward to your thoughts :). 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times

[Christopher Graham]

It seems that (doc ...) and (source ...) do not print any text 
after (require '[hello-world.core :as hello] :reload) has been entered at 
the (browser) REPL.


On Monday, March 9, 2015 at 7:42:28 PM UTC-4, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-3058
>
>

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

[Jonah Benton]

Hey Colin, it sounds like:

* if the 2 systems really can't function without each other, and their
start/stop lifecycles are tightly bound, then somehow they have to be
merged into a single system

or

* if the 2 systems can't be merged into a single system because of true
functional or lifecycle independence and non-overlapping dependencies, then
semantics for what it means for each system to not have the other available
at lifecycle event times have to be established

It smells like the latter may be the way to go. So in pseudocode, the
reusable-component-system that "owns" the reusable-component would not
receive an instance of the external-collaborator at creation time. Instead,
the reusable-component would have a somewhat weaker definition of its start
semantics, and perhaps would have a way to refer to the
external-collaborator only by name.

That is, perhaps the external-collaborator provided to the
reusable-component is really an external-collaborator-client that is
configured to know the name of the external-collaborator- which is owned by
larger-system- and shields the reusable-component in cases where the larger
system has not been started or the collaborator isn't available.

And perhaps similarly the larger-system has a reusable-component-client or
reusable-client-proxy that is able to bridge appropriately from
larger-system to the reusable-component.

And maybe both client components are configured with the same :bus for
cross-system communication (and perhaps the cross-system bus is owned by a
bridge system). Just riffing, as it's not precisely clear what the
semantics of the systems are.

Stuart's comment that he hasn't run into a need for systems of systems is
coming to mind. Perhaps it makes sense to break these apart more explicitly
in accordance with guidelines around managing micro-services. Easy to say,
of course. :)

Not sure if that's helpful

Jonah



On Wed, Mar 11, 2015 at 3:01 PM, Colin Yates  wrote:

> merge won't help as there will be name space clashes.
>
> I wonder if a more elegant approach would be to construct the 'inner'
> system and then assoc onto it the external dependencies it needs
> before calling start.
>
> On 11 March 2015 at 18:49,   wrote:
> > I believe I misunderstood your question; I didn't realize it was system
> (as
> > opposed to any general component) specific. I think systems can be merged
> > together (via 'merge'). Would that help?
> >
> > On Wednesday, March 11, 2015 at 2:40:14 PM UTC-4, Colin Yates wrote:
> >>
> >> Hi Adrian - I don't follow how that helps integrate two different
> >> systems - I wonder if my question was unclear or I am missing
> >> something in your answer. Would you mind posting some pseudo code to
> >> clarify please?
> >>
> >> On 11 March 2015 at 18:32,   wrote:
> >> > You can specify component dependencies using the 'using' function as
> you
> >> > know. As long as you know the key of the component in the system you
> can
> >> > specify this dependency wherever you construct the component. If you
> >> > want to
> >> > parameterize dependencies, write a constructor function which takes
> the
> >> > external dependency as a value.
> >> >
> >> > On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:
> >> >>
> >> >> I have a non-trivial component which requires a bunch of internal and
> >> >> external collaborators to work. This component is itself re-usable.
> >> >>
> >> >> What I really want to do is have ReusableComponent be a component in
> a
> >> >> system so it can pull its external collaborators. However,
> >> >> ReusableComponent
> >> >> constructs its own services etc. so it really want to be (or at least
> >> >> have
> >> >> access to) a system.
> >> >>
> >> >> For example, let's say I have the following:
> >> >>
> >> >> (defrecord InternalToReusableComponent [bus]
> >> >>   (component/Lifecycle
> >> >> (start [this]...))
> >> >>
> >> >> (defrecord ReusableComponent [bus logger]
> >> >>   (component/Lifecycle
> >> >> (start [this]
> >> >>
> >> >>   this)
> >> >> ))
> >> >>
> >> >> (defn reusable-component-system [external-collaborator]
> >> >>   (component/system-map
> >> >> :bus ()
> >> >> :logger ()
> >> >> :reusable-component (component/using (map->ReusableComponent {})
> >> >> [:bus
> >> >> :logger external-collaborator]))
> >> >>
> >> >> Fine - I now have a system from which I can pull the reusable
> >> >> component.
> >> >> However, where does 'external-collaborator' come from? Obviously
> there
> >> >> is a
> >> >> larger system which I want this component to be part of so I can do:
> >> >>
> >> >> (defn larger-system []
> >> >>   (component/system-map
> >> >>  :external-collaborator (...)
> >> >>  :reusable-component (component/using (some-magic-glue)
> >> >> [:external-collaborator])))
> >> >>
> >> >> I am struggling to see what (some-magic-glue) should be. I imagine it
> >> >> needs to be something like:
> >> >>
> >> >> (defrecord SystemAdaptor [e

Re: Any Lispers in South Devon, UK?

[John Kane]

Hello Stephen,

Sorry for the late reply but we have been trying to get organised. The 
inaugural meeting of Exeter Clojurians will be:

7pm Wednesday 25th March 2015
City Gate Hotel, Iron Bridge, EX4 3RB

Hope to see you there, and anyone else who is interested!
John

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

Re: Any Lispers in South Devon, UK?

[Bruce Durling]

w00t!

On Wed, Mar 11, 2015 at 9:42 PM, John Kane  wrote:
> Hello Stephen,
>
> Sorry for the late reply but we have been trying to get organised. The
> inaugural meeting of Exeter Clojurians will be:
>
> 7pm Wednesday 25th March 2015
> City Gate Hotel, Iron Bridge, EX4 3RB
>
> Hope to see you there, and anyone else who is interested!
> John
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[ANN] munge-tout 0.1.2

[Edward Kimber]

Munge Tout is a Java-Clojure interop library that helps convert Java 
Objects into Clojure data structures.  It supports conversion of Java 
primitives, Lists, Sets, Maps and Enums and can be configured to perform 
custom conversions on a per-property basis, or generally for a type by 
extending the Mungeable protocol. 

We use this to construct Java classes to feed into legacy Java libraries. 
 Some of our classes have a complex structure with properties being lists 
of other classes and so on and this tool makes interop with our legacy code 
significantly simpler.  Hopefully it may also be of use to others. 
 Feedback welcomed.

https://github.com/flybe-dev/munge-tout
https://clojars.org/munge-tout

Edward

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

[Stephen Wakely]

Superb! I will make sure I am there. Looking forward to it!

On Wed, Mar 11, 2015 at 9:56 PM Bruce Durling  wrote:

> w00t!
>
> On Wed, Mar 11, 2015 at 9:42 PM, John Kane  wrote:
> > Hello Stephen,
> >
> > Sorry for the late reply but we have been trying to get organised. The
> > inaugural meeting of Exeter Clojurians will be:
> >
> > 7pm Wednesday 25th March 2015
> > City Gate Hotel, Iron Bridge, EX4 3RB
> >
> > Hope to see you there, and anyone else who is interested!
> > John
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Chestnut 0.7.0

[Makoto Hashimoto]

Hi Arne,

Thank you for your advice. I hope chestnut runs on the latest versions of
cljs and om.
Is there any info or suggestions ?

Makoto

2015-03-11 23:58 GMT+09:00 Arne Brasseur :

> Sorry for the delayed response, I didn't have email notifications set up
> correctly.
>
> Interesting way of using ~/.lein/profiles.clj. I hadn't considered that
> yet.
>
> If you want to run a modified Chestnut the easiest is to run lein install
> in your chestnut repo. You shouldn't have to manually bump the version.
> E.g. the current version is 0.7.0, if you locally install a different 0.7.0
> then lein new will use that one. One caveat, if it's a -SNAPSHOT version
> you're installing, you'll also have to use lein new --snapshot to use it.
>
> Hope that helps!
>
> On Wednesday, 11 March 2015 09:09:30 UTC+1, webber wrote:
>>
>> Hi Tim,
>>
>> I branched  from the original source and set the version like
>> 0.6.1-SNAPSHOT.
>> Controlling versions in ~/.lein/profiles.clj was slightly convenient and
>> worked for
>> the 0.6.0.
>>
>> Makoto
>>
>> 2015-03-11 13:35 GMT+09:00 Tim Gilbert :
>>
>>> Oh, that's odd. I don't have any entries in my own user plugins for
>>> "lein new" templates. (I'm assuming you meant ~/.lein/profiles.clj, right?)
>>>
>>> Is there some reason you have them in there? "lein new chestnut" should
>>> work just fine without them, but maybe I'm not understanding what you're
>>> trying to do.
>>>
>>> Tim
>>>
>>>
>>> On Monday, March 9, 2015 at 6:30:48 PM UTC-4, webber wrote:

 I've commented chestnut/lein-template from the ~/.lein/projects.clj as
 follows, then it worked.
 It worked using 0.6.0 if there was the chestnut/lein-template
 definition. Was my usage wrong ?

 {:user {:plugins [
   [lein-try "0.4.3"]
   ;[lein-pprint "1.1.1"]
   [lein-ancient "0.6.4" :exclusions
 [org.clojure/core.cache]]
   [lein-bikeshed "0.2.0"]
   [lein-ritz "0.7.0"]
   [lein-marginalia "0.8.0"]
   [http-kit/lein-template "1.0.0-SNAPSHOT"]
   [cider/cider-nrepl "0.9.0-SNAPSHOT"]
   [cljs-complete "0.1.1"]
   ;;[chestnut/lein-template "0.7.0"]
   ;;[chestnut/lein-template "0.6.0"]
   ]
 :dependencies [;;[nrepl-inspect "0.4.1"]
[compliment "0.2.0"]
[ritz/ritz-nrepl-middleware "0.7.0"]
[cider/cider-nrepl "0.9.0-SNAPSHOT"]
[alembic "0.2.1"]
[org.clojure/tools.nrepl "0.2.7"]
]

 :repl-options {:nrepl-middleware
[cider.nrepl.middleware.classpath/wrap-classpath
 cider.nrepl.middleware.complete/wrap-complete
 cider.nrepl.middleware.info/wrap-info
 cider.nrepl.middleware.inspect/wrap-inspect
 cider.nrepl.middleware.stacktr
 ace/wrap-stacktrace
 cider.nrepl.middleware.trace/wrap-trace
 ]}

 }}

 Makoto


> I ran into this same behavior, and then I realized it only happened if
> I run the "lein new" command if I'm *already in* a previously-created
> project created with "lein new chestnut". I'm guessing that something in
> the generated project.clj interferes some of the lein new behavior 
> somehow.
> At any rate, running lein new in a directory without a project.clj file in
> it is working fine for me.
>
> Tim
>
> On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote:
>>
>> I tested the v 0.7.0 of chestnut and I encountered the following
>> error.
>> The v 0.6.0 works fine.
>>
>> $ lein new chestnut test-app
>> Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from
>> clojars
>> Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from
>> clojars
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:270)
>> at clojure.lang.RT.loadClassForName(RT.java:2093)
>> at clojure.lang.RT.load(RT.java:430)
>> at clojure.lang.RT.load(RT.java:411)
>> at clojure.core$load$fn__5066.invoke(core.clj:5641)
>> at clojure.core$load.doInvoke(core.clj:5640)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.core$load_one.invoke(core.clj:5446)
>> at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
>> at clojure.core$load_lib.doInvoke(core.clj:5485)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invoke(core.clj:626)
>> at clojure.core$load_libs.doInvoke(cor

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Steven Yi]

I took a look at the bytecode of what was generated using no.disassemble 
(wrapping parts of the test code into defn's to disassemble it). I saw a 
couple of things going on, but I'm not sure exactly what it all means as 
I'm not super familiar with when Hotspot does method inlining.  Maybe 
someone else with more experience can help here. :) 

1. The first is that when you're calling vreset!/reset! and deref, you're 
actually doing two function calls to get and set values.  (i.e. you call 
vreset! and vreset! calls .reset, vs. calling .reset directly as in the 
last example by Timothy).  

2. The code when calling a function like reset! and vreset! generates 
invokeinterface calls.  You can get invokevirtual calls to be generated 
using something like:

(.invoke ^AFn vreset! v (.invoke ^AFn deref v))

which is pretty hideous, but works to get a call to AFn.invoke() instead of 
IFn.invoke().  However, that didn't change the speed of things here at 
all.  I don't know if that affects method inlining by Hotspot.

I would guess what's happening is that you're getting the overhead of the 
extra function call going through vreset! and reset!, rather than going 
directly to .reset (and again for @ and .deref; note the deref clojure 
function also has some extra logic for instance checking that would also 
add more processing).

When running the 1000 loop here (Macbook Pro 2011, Core i7), I get:

(vreset! v @v)
"Elapsed time: 2456.604192 
msecs"  
 


(vreset! v (.deref v))
"Elapsed time: 1124.21792 msecs"

(.reset v (.deref v))
"Elapsed time: 829.400429 msecs"

The 2nd result above show a big difference, and I imagine that's probably 
due to not having to do the (instance? clojure.lang.IDeref ref) that's in 
the deref function.  The 3rd one compared to the 2nd I think would be the 
difference from just the extra function call (assuming no method inlining 
has happened). 


On Wednesday, March 11, 2015 at 2:08:49 PM UTC-4, Brent Millare wrote:
>
> Good catch. With criterium, I can detect the small performance improvement.
>
> volatile: Evaluation count : 7550019420 in 60 samples of 125833657 calls.
>  Execution time mean : 6.345042 ns
> Execution time std-deviation : 0.126086 ns
>Execution time lower quantile : 6.223058 ns ( 2.5%)
>Execution time upper quantile : 6.525868 ns (97.5%)
>Overhead used : 1.651549 ns
> AtomicLong: Evaluation count : 6925392540 in 60 samples of 115423209 calls.
>  Execution time mean : 7.156855 ns
> Execution time std-deviation : 0.136142 ns
>Execution time lower quantile : 7.010743 ns ( 2.5%)
>Execution time upper quantile : 7.362120 ns (97.5%)
>Overhead used : 1.651549 ns
> AtomicReference: Evaluation count : 6014401080 in 60 samples of 100240018 
> calls.
>  Execution time mean : 8.342217 ns
> Execution time std-deviation : 0.126856 ns
>Execution time lower quantile : 8.129171 ns ( 2.5%)
>Execution time upper quantile : 8.511877 ns (97.5%)
>Overhead used : 1.651549 ns
>
>
> On Wednesday, March 11, 2015 at 1:50:37 PM UTC-4, tbc++ wrote:
>>
>> Actaully I think it comes down to the use of the rather generic Deref. I 
>> fired up a repl and ran the following 
>>
>> (let [v (clojure.lang.Volatile. {})]
>>   (dotimes [x ...]
>> (.reset v (.deref v
>>
>> I'm seeing very similar times to the one for the AtomicReference.
>>
>> Timothy
>>
>> On Wed, Mar 11, 2015 at 11:08 AM, Brent Millare  
>> wrote:
>>
>>> I find it hard to believe GC would be a factor since there is very 
>>> little being generated here. Also, while the outside loop is only 10 
>>> iterations of timings, in the inside loops the code is called for 100 
>>> million iterations. Anyways, running it with criterium didn't change the 
>>> ranking.
>>>
>>> Here is the output:
>>> volatile: WARNING: Final GC required 1.149417308725186 % of runtime
>>> Evaluation count : 4156079100 in 60 samples of 69267985 calls.
>>>  Execution time mean : 12.975339 ns
>>> Execution time std-deviation : 0.188921 ns
>>>Execution time lower quantile : 12.823222 ns ( 2.5%)
>>>Execution time upper quantile : 13.272950 ns (97.5%)
>>>Overhead used : 1.613416 ns
>>> AtomicLong: Evaluation count : 6921767160 in 60 samples of 115362786 
>>> calls.
>>>  Execution time mean : 7.155989 ns
>>> Execution time std-deviation : 0.124147 ns
>>>Execution time lower quantile : 7.048738 ns ( 2.5%)
>>>Execution time upper quantile : 7.330448 ns (97.5%)
>>>Overhead used : 1.613416 ns
>>> AtomicReference: Evaluation count : 5814704460 in 60 samples of 
>>> 96911741 calls.
>>>  Execution time mean : 8.791224 ns
>>> Execution time std-deviation : 0.185229 ns
>>>Execution time lower quantile : 8.564921 ns ( 2.5%)
>>>Execution time 

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Brent Millare]

Thanks for the extra analysis!

>  

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

Typed Clojure paper draft

[Ambrose Bonnaire-Sergeant]

Hi,

Please check out our new paper draft
 on core.typed's
type system.

The first few pages has a lot of executable code and is intended to be
accessible
to anyone. Feedback welcome!

Thanks,
Ambrose

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