Re: Typedef-like functionality for Clojure records?

[Vincent Chen]

On Thu, Sep 26, 2013 at 1:49 AM, Marshall Bockrath-Vandegrift
 wrote:
> Vincent Chen  writes:
>
>> - Use something else than records to model structs (suggestions welcome)?
>
> Maps.
>
> Records have concrete Java types, which allows them to implement
> interfaces and participate in protocols.  Fields defined on a record
> type are backed by JVM object fields, which can increase performance.
> But there are no strictness benefits – a record may have any number of
> additional keys associated to values:
>
> (defrecord Foo [bar])
> ;;=> user.Foo
> (map->Foo {:bar 1, :baz 2})
> ;;=> #user.Foo{:bar 1, :baz 2}
> (class (map->Foo {:bar 1, :baz 2}))
> ;;=> user.Foo
>
> So my suggestion would be to instead turn your `struct` definitions into
> functions validating that the expected fields are present within plain
> maps.  (Assuming some sort of strictness/validation is the goal.)
>
Thanks for the suggestions.

My records (structs) do actually implement protocols, since the
structs represent something which has to be sent over the wire.
Clojure being a dynamic language means that I have to specify the
types of each field of a struct, and I do it as part of a protocol
implemented by the records.

If I'm getting you correctly, you're suggesting that instead of

(defrecord Foo [a b c])

I should rather have

(defn make-foo [a b c]
  {:a a, :b b, :c c})

? That could work, even though I had tried to avoid having to do this
when I started. I guess rather than protocols I'll just use
multimethods instead.

Thanks for your help,

Vincent

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

[Sebastian Rojas]

I took it as a challenge, so i made this tiny library to play with:

https://github.com/sebastiansen/mummy

Adios amigo

On Tuesday, September 24, 2013 10:35:38 AM UTC-3, Bill Piel wrote:
>
> I want to use clojure to build a web service with a RESTful API that 
> exposes resources stored in a relational database (mysql in this case). I'd 
> like to use a library that, given a specification of the db schema, would 
> translate incoming requests to db queries, or korma constructs.
>
> Examples might be:
>
> GET /users?status=4
>
> translates to something like:
>
> SELECT * FROM `users` WHERE `status` = 4;
>
> or:
>
> PUT /users/12
>
> would be:
>
> UPDATE `users` SET ... WHERE `id` = 12
>
> Is there anything out there that would facilitate this?
>
> 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: Typedef-like functionality for Clojure records?

[Vincent Chen]

Thanks for the suggestion. I'll take a look at prismatic/schema.

On Thu, Sep 26, 2013 at 5:21 PM, Jason Wolfe  wrote:
> I'm not sure if this would meet your need (it doesn't help with your
> proximate defrecord issue), but if you're primarily interested in
> documentation and validation you could consider prismatic/schema [1] as a
> translation target, and just represent your data with maps.
>
> [1] https://github.com/Prismatic/schema
>
>
> On Wednesday, September 25, 2013 10:47:35 PM UTC-7, Vincent Chen wrote:
>>
>> Hi,
>>
>> I have in my hands an XML description of data structures that I want
>> to mechanically translate into Clojure. There are  and
>>  elements, with  being similar to structs in C (list
>> of fields) and  being similar to typedef in C (defining new
>> name for already defined s).
>>
>> I model s using Clojure records, but I'm not sure how to refer
>> to them with a new name when it comes to s. Given the
>> following specification:
>>
>> 
>>   
>>   
>> 
>>
>> 
>>
>> I would create records:
>>
>> (defrecord foo [a b])
>> (defrecord bar [a b])
>>
>> The problem is that struct foo and typedef bar lives in different
>> namespaces, i.e. I don't have foo's specification when I encounter
>> typedef bar. What I'd like to do is (def bar some-ns/foo), but what
>> about ->foo and map->foo?
>>
>> So should I:
>> - (def bar some-ns/foo) (def ->bar some-ns/->foo) (def map->bar
>> some-ns/map->foo), while hoping that Clojure doesn't extend records
>> syntax/capabilities in the future?
>> - Use something else than records to model structs (suggestions welcome)?
>> - Other?
>>
>> Thanks,
>>
>> Vincent
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in central

[Ambrose Bonnaire-Sergeant]

Hi,

Use `lein deps :tree` to figure out what the clojure 1.2.0-master-SNAPSHOT
release is transitively depending on.

You can then exclude the dependency like this for the problematic "lib":
[lib "0.1" :exclusions [org.clojure/clojure]]

Thanks,
Ambrose


On Sat, Sep 28, 2013 at 11:21 AM,  wrote:

> Hi,
>   I run "lein deps",then error message:
> D:\clojure\4clojure-develop>lein deps
> Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in
> central
>  (http://repo1.maven.org/maven2)
> Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in
> clojars
>  (https://clojars.org/repo/)
> Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in
> clojure
>  (http://build.clojure.org/releases)
> Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in
> clojure
> -snapshots (http://build.clojure.org/snapshots)
>
> the project.clj :
> (defproject foreclojure "1.3.0.1"
>   :description "4clojure - a website for lisp beginners"
>   :dependencies [[org.clojure/clojure "1.2.1"]
>  [org.clojure/clojure-contrib "1.2.0"]
>  [compojure "1.1.5"]
>  [hiccup "0.2.4"]
>  [clojail "0.4.0-SNAPSHOT"]
>  [sandbar "0.4.0-SNAPSHOT"]
>  [org.clojars.christophermaier/congomongo "0.1.4-SNAPSHOT"]
>  [org.jasypt/jasypt "1.7"]
>  [useful "0.7.0-beta1"]
>  [amalloy/ring-gzip-middleware "[0.1.0,)"]
>  [clj-github "1.0.1"]
>  [ring "0.3.7"]
>  [clj-config "0.1.0"]
>  [incanter/incanter-core "1.2.3"]
>  [incanter/incanter-charts "1.2.3"]
>  [org.apache.commons/commons-email "1.2"]]
>   :dev-dependencies [[lein-ring "0.4.5"]
>  [swank-clojure "1.2.1"]
>  [midje "1.1.1"]]
>   :main foreclojure.core
>   :ring {:handler foreclojure.core/app
>  :init foreclojure.mongo/prepare-mongo})
>
> who can give some explain? thank you!
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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.

Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in central

[ljcppunix]

Hi,
  I run "lein deps",then error message:
D:\clojure\4clojure-develop>lein deps
Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in 
central
 (http://repo1.maven.org/maven2)
Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in 
clojars
 (https://clojars.org/repo/)
Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in 
clojure
 (http://build.clojure.org/releases)
Could not find artifact org.clojure:clojure:pom:1.2.0-master-SNAPSHOT in 
clojure
-snapshots (http://build.clojure.org/snapshots)

the project.clj :
(defproject foreclojure "1.3.0.1"
  :description "4clojure - a website for lisp beginners"
  :dependencies [[org.clojure/clojure "1.2.1"]
 [org.clojure/clojure-contrib "1.2.0"]
 [compojure "1.1.5"]
 [hiccup "0.2.4"]
 [clojail "0.4.0-SNAPSHOT"]
 [sandbar "0.4.0-SNAPSHOT"]
 [org.clojars.christophermaier/congomongo "0.1.4-SNAPSHOT"]
 [org.jasypt/jasypt "1.7"]
 [useful "0.7.0-beta1"]
 [amalloy/ring-gzip-middleware "[0.1.0,)"]
 [clj-github "1.0.1"]
 [ring "0.3.7"]
 [clj-config "0.1.0"]
 [incanter/incanter-core "1.2.3"]
 [incanter/incanter-charts "1.2.3"]
 [org.apache.commons/commons-email "1.2"]]
  :dev-dependencies [[lein-ring "0.4.5"]
 [swank-clojure "1.2.1"]
 [midje "1.1.1"]]
  :main foreclojure.core
  :ring {:handler foreclojure.core/app
 :init foreclojure.mongo/prepare-mongo})

who can give some explain? thank you!

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

Re: Parallelising over a lazy sequence - request for help

[Rich Morin]

> On Sat, May 25, 2013 at 12:34 PM, Paul Butcher  wrote:
> I'm currently working on a book on concurrent/parallel development for The 
> Pragmatic Programmers. ...

Ordered; PDF just arrived (:-).


I don't know yet whether the book has anything like this, but I'd
like to see a table that shows which concurrency and parallelism
approaches are supported (and to what extent) by various languages.

So, actors, agents, queues, reducers (etc) would be on one axis;
Clojure, Erlang, Go, and Ruby (etc) would be on the other.  I'd
expect Clojure to have pretty complete coverage; Ruby, not so much.

-r

 -- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation


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

Re: Parallelising over a lazy sequence - request for help

[Stuart Halloway]

Hi Paul,

I have posted an example that shows partition-then-fold at
https://github.com/stuarthalloway/exploring-clojure/blob/master/examples/exploring/reducing_apple_pie.clj
.

I would be curious to know how this approach performs with your data.  With
the generated data I used, the partition+fold and partition+pmap approaches
both used most of my cores and had similar perf.

Enjoying your book!

Stu


On Sat, May 25, 2013 at 12:34 PM, Paul Butcher  wrote:

> I'm currently working on a book on concurrent/parallel development for The
> Pragmatic Programmers. One of the subjects I'm covering is parallel
> programming in Clojure, but I've hit a roadblock with one of the examples.
> I'm hoping that I can get some help to work through it here.
>
> The example counts the words contained within a Wikipedia dump. It should
> respond well to parallelisation (I have Java and Scala versions that
> perform excellently) but I've been incapable of coming up with a nice
> solution in Clojure.
>
> The code I'm working with is checked into 
> GitHub
> :
>
> The basic sequential algorithm is:
>
> (frequencies (mapcat get-words pages))
>
>
> If I run that on the first 10k pages in Wikipedia dump, it takes ~21s on
> my MacBook Pro.
>
> One way to parallelise it is to create a parallel version of frequencies
> that uses reducers:
>
> (defn frequencies-fold [words]
>   (r/fold (partial merge-with +)
>   (fn [counts word] (assoc counts word (inc (get counts word 0
>
>   words))
>
>
> And sure enough, if I use that, along with use the 
> foldable-seq
>  utility
> I posted about 
> here are
> while ago it runs in ~8s, almost a 3x speedup, not bad given that the
> parallel version is unable to use transients.
>
> Unfortunately, as they currently stand, reducers have a fatal flaw that
> means that, even with foldable-seq, they're basically useless with lazy
> sequences. Reducers always hold onto the 
> head of
> the sequence they're given, so there's no way to use this approach for a
> complete Wikipedia dump (which runs to around 40GiB).
>
> So the other approach I've tried is to use pmap:
>
> (defn frequencies-pmap [words]
>   (reduce (partial merge-with +)
> (pmap frequencies
>   (partition-all 1 words
>
>
> But, for reasons I don't understand, this performs dreadfully - taking
> ~26s, i.e. significantly slower than the sequential version.
>
> I've tried playing with different partition sizes without materially
> affecting the result.
>
> So, what I'm looking for is either:
>
> a) An explanation for why the pmap-based solution performs so badly
>
> b) A way to fix the "holding onto head" problem that's inherent within
> reducers.
>
> With the last of these in mind, it strikes me that the problem
> fundamentally arises from the desire for reducers to follow the same basic
> API as "normal" code. So:
>
> (reduce (filter ... (map ... coll)))
>
> becomes:
>
> (r/fold (r/filter ... (r/map ... coll)))
>
> A very small change to the reducers API - passing the collection to the
> reduce and/or fold - would avoid the problem:
>
> (r/fold (r/filter ... (r/map ...)) coll)
>
> Anyway - I'd be very grateful for any insight into either of the above
> questions. Or for suggestions for an alternative approach that might be
> more fruitful.
>
> Many thanks in advance,
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

[zcaudate]

I just thought of another feature that I want - persistence... Like saving the 
rules into some file and loading them back 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.

ANN: core.match 0.2.0

[David Nolen]

No change since the last release candidate.

http://github.com/clojure/core.match

Have fun!

David

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

[Rich Morin]

On Sep 27, 2013, at 09:51, Ambrose Bonnaire-Sergeant wrote:
> I have started a crowdfunding campaign to support full-time
> work on Typed Clojure.
> 
> Please share!
> 
> http://www.indiegogo.com/projects/typed-clojure

Still in its first day, the campaign is already an eighth
of the way to its goal!  I encourage other Typed Clojure
fans to make a contribution.

-r

 -- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation


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

Re: core.async repl :reload-all issue?

[Ben Mabey]

When you call the `timeout` fn you are modifying the state of 
core.async's global queue and map.  The global state for core.async's 
timer is defonced[1] and so you need to destroy the entire ns before 
reloading it.  This is what tools.namespace will do instead of a simple 
reload where the defonce value would not be touched.


-Ben


1. 
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/timers.clj#L17-L21


On 9/27/13 12:18 PM, Russell Christopher wrote:

Hi Ben,

But the example doesn't have any state in def's, hence I thought it 
did conform to Stuart's workflow. In my (more) real app I am trying to 
follow his workflow protocol and it was reloading fine but now is not 
maybe i need to read the link again,


Thanks


On Fri, Sep 27, 2013 at 2:06 PM, Ben Mabey > wrote:


Hi Russell,
This doesn't look like a core.async specific problem, but rather
the more general problem that protocols and records are not reload
safe.  What I believe is happening is the TimeoutQueueEntry type
is being recompiled when you do reload all but old instances with
the older compilation remain in core.async's DelayQueue.

In order to fix this you would need to recreate the internal
DelayQueue that core.async uses to store the timeouts.  Luckily,
this will happen for you automatically if you use tools.namespace
and adopt a workflow as explained by Stuart Sierra in this blog post:

http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded

Keep in mind that this remove any timeouts you may be awaiting on
but I think that is probably the desired effect since you are
trying to get a clean state of the system.

HTH,
Ben


On 9/27/13 11:49 AM, Russell Christopher wrote:

Anyone encountered after a few reloads at the repl core.async
stops working.?

Thanks

(ns repl.core
  (:require [clojure.core.async :refer :all])) ;;0.1.0-SNAPSHOT

(defn producer[c]
  (Thread/sleep 1000)
  (go (>! c true))
  (println "sleeping")
  (Thread/sleep 1))

(defn consumer [c]
  (let [res (alts!! [c (timeout 2000)])]
(if (= c (second res))
  (println "true")
  (println "timeout"

(defn main []
  (let [c (chan)]
(future (producer c))
(consumer c)))

nREPL server started on port 50616 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.0
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)

user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> Exception in thread
"clojure.core.async.timers/timeout-daemon"
java.lang.ClassCastException: clojure.core.async.i
mpl.timers.TimeoutQueueEntry cannot be cast to
clojure.core.async.impl.timers.TimeoutQueueEntry
at
clojure.core.async.impl.timers$timeout_worker.invoke(timers.clj:61)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Unknown Source)


user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)

ClassCastException
clojure.core.async.impl.timers.TimeoutQueueEntry cannot be
cast to clojure.core.async.impl.timers.Tim
eoutQueueEntry
 clojure.core.async.impl.timers.TimeoutQueueEntry (timers.clj:33)
user=> sleeping
-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

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

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

Re: core.async repl :reload-all issue?

[Russell Christopher]

Hi Ben,

But the example doesn't have any state in def's, hence I thought it did
conform to Stuart's workflow. In my (more) real app I am trying to follow
his workflow protocol and it was reloading fine but now is not maybe i need
to read the link again,

Thanks


On Fri, Sep 27, 2013 at 2:06 PM, Ben Mabey  wrote:

> Hi Russell,
> This doesn't look like a core.async specific problem, but rather the more
> general problem that protocols and records are not reload safe.  What I
> believe is happening is the TimeoutQueueEntry type is being recompiled when
> you do reload all but old instances with the older compilation remain in
> core.async's DelayQueue.
>
> In order to fix this you would need to recreate the internal DelayQueue
> that core.async uses to store the timeouts.  Luckily, this will happen for
> you automatically if you use tools.namespace and adopt a workflow as
> explained by Stuart Sierra in this blog post:
>
> http://thinkrelevance.com/**blog/2013/06/04/clojure-**workflow-reloaded
>
> Keep in mind that this remove any timeouts you may be awaiting on but I
> think that is probably the desired effect since you are trying to get a
> clean state of the system.
>
> HTH,
> Ben
>
>
> On 9/27/13 11:49 AM, Russell Christopher wrote:
>
>> Anyone encountered after a few reloads at the repl core.async stops
>> working.?
>>
>> Thanks
>>
>> (ns repl.core
>>   (:require [clojure.core.async :refer :all])) ;;0.1.0-SNAPSHOT
>>
>> (defn producer[c]
>>   (Thread/sleep 1000)
>>   (go (>! c true))
>>   (println "sleeping")
>>   (Thread/sleep 1))
>>
>> (defn consumer [c]
>>   (let [res (alts!! [c (timeout 2000)])]
>> (if (= c (second res))
>>   (println "true")
>>   (println "timeout"
>>
>> (defn main []
>>   (let [c (chan)]
>> (future (producer c))
>> (consumer c)))
>>
>> nREPL server started on port 50616 on host 127.0.0.1
>> REPL-y 0.2.1
>> Clojure 1.5.0
>> Docs: (doc function-name-here)
>>   (find-doc "part-of-name-here")
>>   Source: (source function-name-here)
>>  Javadoc: (javadoc java-object-or-class-here)
>> Exit: Control+D or (exit) or (quit)
>>
>> user=> (require '[repl.core :as r] :reload-all)
>> nil
>> user=> (r/main)
>> sleeping
>> true
>> nil
>> user=> (require '[repl.core :as r] :reload-all)
>> nil
>> user=> (r/main)
>> sleeping
>> true
>> nil
>> user=> Exception in thread "clojure.core.async.timers/**timeout-daemon"
>> java.lang.ClassCastException: clojure.core.async.i
>> mpl.timers.TimeoutQueueEntry cannot be cast to clojure.core.async.impl.**
>> timers.TimeoutQueueEntry
>> at clojure.core.async.impl.**timers$timeout_worker.invoke(**
>> timers.clj:61)
>> at clojure.lang.AFn.run(AFn.java:**24)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>> user=> (require '[repl.core :as r] :reload-all)
>> nil
>> user=> (r/main)
>> sleeping
>> true
>> nil
>> user=> (require '[repl.core :as r] :reload-all)
>> nil
>> user=> (r/main)
>>
>> ClassCastException clojure.core.async.impl.**timers.TimeoutQueueEntry
>> cannot be cast to clojure.core.async.impl.**timers.Tim
>> eoutQueueEntry  clojure.core.async.impl.**timers.TimeoutQueueEntry
>> (timers.clj:33)
>> user=> sleeping
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> clojure+unsubscribe@**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+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>

-- 
-- 
You received this message becau

Re: core.async repl :reload-all issue?

[Ben Mabey]

Hi Russell,
This doesn't look like a core.async specific problem, but rather the 
more general problem that protocols and records are not reload safe.  
What I believe is happening is the TimeoutQueueEntry type is being 
recompiled when you do reload all but old instances with the older 
compilation remain in core.async's DelayQueue.


In order to fix this you would need to recreate the internal DelayQueue 
that core.async uses to store the timeouts.  Luckily, this will happen 
for you automatically if you use tools.namespace and adopt a workflow as 
explained by Stuart Sierra in this blog post:


http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded

Keep in mind that this remove any timeouts you may be awaiting on but I 
think that is probably the desired effect since you are trying to get a 
clean state of the system.


HTH,
Ben

On 9/27/13 11:49 AM, Russell Christopher wrote:
Anyone encountered after a few reloads at the repl core.async stops 
working.?


Thanks

(ns repl.core
  (:require [clojure.core.async :refer :all])) ;;0.1.0-SNAPSHOT

(defn producer[c]
  (Thread/sleep 1000)
  (go (>! c true))
  (println "sleeping")
  (Thread/sleep 1))

(defn consumer [c]
  (let [res (alts!! [c (timeout 2000)])]
(if (= c (second res))
  (println "true")
  (println "timeout"

(defn main []
  (let [c (chan)]
(future (producer c))
(consumer c)))

nREPL server started on port 50616 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.0
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)

user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> Exception in thread "clojure.core.async.timers/timeout-daemon" 
java.lang.ClassCastException: clojure.core.async.i
mpl.timers.TimeoutQueueEntry cannot be cast to 
clojure.core.async.impl.timers.TimeoutQueueEntry
at 
clojure.core.async.impl.timers$timeout_worker.invoke(timers.clj:61)

at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Unknown Source)


user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)

ClassCastException clojure.core.async.impl.timers.TimeoutQueueEntry 
cannot be cast to clojure.core.async.impl.timers.Tim
eoutQueueEntry  clojure.core.async.impl.timers.TimeoutQueueEntry 
(timers.clj:33)

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

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

core.async repl :reload-all issue?

[Russell Christopher]

Anyone encountered after a few reloads at the repl core.async stops
working.?

Thanks

(ns repl.core
  (:require [clojure.core.async :refer :all])) ;;0.1.0-SNAPSHOT

(defn producer[c]
  (Thread/sleep 1000)
  (go (>! c true))
  (println "sleeping")
  (Thread/sleep 1))

(defn consumer [c]
  (let [res (alts!! [c (timeout 2000)])]
(if (= c (second res))
  (println "true")
  (println "timeout"

(defn main []
  (let [c (chan)]
(future (producer c))
(consumer c)))

nREPL server started on port 50616 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.0
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)

user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> Exception in thread "clojure.core.async.timers/timeout-daemon"
java.lang.ClassCastException: clojure.core.async.i
mpl.timers.TimeoutQueueEntry cannot be cast to
clojure.core.async.impl.timers.TimeoutQueueEntry
at
clojure.core.async.impl.timers$timeout_worker.invoke(timers.clj:61)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Unknown Source)


user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)
sleeping
true
nil
user=> (require '[repl.core :as r] :reload-all)
nil
user=> (r/main)

ClassCastException clojure.core.async.impl.timers.TimeoutQueueEntry cannot
be cast to clojure.core.async.impl.timers.Tim
eoutQueueEntry  clojure.core.async.impl.timers.TimeoutQueueEntry
(timers.clj:33)
user=> sleeping

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

Re: ANN: ClojureScript 0.0-1909

[David Nolen]

Oops bumping data.json and tools.reader are not breaking changes! :)


On Fri, Sep 27, 2013 at 1:00 PM, 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-1909
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-1909"]
>
> *Breaking Changes: *
> * Bump data.json to 0.2.3 and tools.reader to 0.7.8
>
> *Enhancements: *
> * Use tools.reader everywhere, pass file information allowing errors at
> read time to give accurate locations
>
> *Fixes:*
> ** *CLJS-595: keyword invoke default bug
> * CLJS-594: declare divide so accidental redeclaration is caught
> * CLJS-599: keyword fn not idempotent
> * CLJS-587: stack overflow on lazy seqs
>

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

ANN: ClojureScript 0.0-1909

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-1909

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1909"]

*Breaking Changes: *
* Bump data.json to 0.2.3 and tools.reader to 0.7.8

*Enhancements: *
* Use tools.reader everywhere, pass file information allowing errors at
read time to give accurate locations

*Fixes:*
** *CLJS-595: keyword invoke default bug
* CLJS-594: declare divide so accidental redeclaration is caught
* CLJS-599: keyword fn not idempotent
* CLJS-587: stack overflow on lazy seqs

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

Crowdfunding for full-time core.typed development

[Ambrose Bonnaire-Sergeant]

Hi,

I have started a crowdfunding campaign to support full-time work on Typed
Clojure.

Please share!

http://www.indiegogo.com/projects/typed-clojure

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

Re: [ANN] ribol "v0.2.1" - comprehensive document on conditional restart systems

[Lee Spector]

PS the rousing applause during Hugo's talk when he shows how you can view 
locals reminded me that I had seen this before, and indeed when I checked I 
remembered that I was even involved in a previous conversation about ritz-nrepl 
on this list. And I remember that the main obstacle to my happiness here is 
that this only seems to be available so far in emacs. 

I guess that Common Lisp-style universality is probably not in the cards, but I 
think that getting this from from "lein run" would be a pretty good 
alternative. I say that not only because that's how I often run my code, but 
also because I guessing that many people, no matter their IDE preferences or 
how they usually run their code, could pretty easily do a "lein run" run if 
they knew that they needed to do some debugging. Even if that's not how you 
normally run your code it involves a lot less overhead than having to 
install/configure/learn/etc emacs if you just to see locals when an exception 
occurs.

 -Lee

On Sep 27, 2013, at 10:32 AM, Lee Spector wrote:

> 
> Thanks so much Chris.
> 
> I've started watching Hugo Duncan's ritz talk and it is definitely what I 
> need to see.
> 
> It's funny because I never thought of this as platform or IDE functionality 
> -- although it clearly is -- because in the Common Lisp world that I come 
> from, some version of this is available universally as part of the language. 
> You can do it whether you are running from a bare-bones terminal repl or from 
> emacs or from some other IDE. The fancier environments can and do provide 
> fancier interfaces and more options, but I think that the core functionality 
> is everywhere.
> 
> I should finish watching Hugo's video before I say much more, but FWIW I 
> think that ritz is exactly what I want except I'd want it ideally to be 
> available from runs launched via "lein run" on the os command line. Or in 
> Eclipse/CCW.
> 
> -Lee
> 
> 
> On Sep 27, 2013, at 3:09 AM, Chris Zheng wrote:
> 
>> Hey Lee.
>> 
>> I'm learning conditional restarts myself…. thus the reason why I implemented 
>> the library so I'm probably not the best person to ask
>> 
>> As far as I know… restarts have to be supported by the language itself in 
>> order for it to truly blossom the way you are describing it. ribol is just a 
>> library, not a platform and definitely not a development environment.
>> 
>> I'm not sure what the state is with https://github.com/pallet/ritz but I 
>> think that it may be what you are looking for in a development environment.
>> 
>> Chris.
>> 
> 

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

Functional Programming conference Code Mesh 3-5 Dec London

[Andra Dinu]

 

http://codemesh.io/

We’ll talk Clojure, Scala, Haskell, Erlang, Elixir, Julia, and  more.  The 
list of speakers is not final, but among over 30 confirmed speakers such as 
data-centric functional programmer Dean Wampler, author of 'The Pragmatic 
Programmer' Dave Thomas, Elixir creator José Valim, Akka inventor Jonas 
Bonér, Erlang co-inventor Joe Armstrong, Trifork CTO Kresten Krab Thorup, 
creator of Catnip IDE Bodil Stokke,  co-creator of Julia Stefan Karpinski, 
author of ZeroMQ book Pieter Hintjens, functional languages expert Amanda 
Laucher, CTO of SkillsMatter Rob Harrop and many many more! 

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

Re: [ANN] ribol "v0.2.1" - comprehensive document on conditional restart systems

[Lee Spector]

Thanks so much Chris.

I've started watching Hugo Duncan's ritz talk and it is definitely what I need 
to see.

It's funny because I never thought of this as platform or IDE functionality -- 
although it clearly is -- because in the Common Lisp world that I come from, 
some version of this is available universally as part of the language. You can 
do it whether you are running from a bare-bones terminal repl or from emacs or 
from some other IDE. The fancier environments can and do provide fancier 
interfaces and more options, but I think that the core functionality is 
everywhere.

I should finish watching Hugo's video before I say much more, but FWIW I think 
that ritz is exactly what I want except I'd want it ideally to be available 
from runs launched via "lein run" on the os command line. Or in Eclipse/CCW.

 -Lee


On Sep 27, 2013, at 3:09 AM, Chris Zheng wrote:

> Hey Lee.
> 
> I'm learning conditional restarts myself…. thus the reason why I implemented 
> the library so I'm probably not the best person to ask
> 
> As far as I know… restarts have to be supported by the language itself in 
> order for it to truly blossom the way you are describing it. ribol is just a 
> library, not a platform and definitely not a development environment.
> 
> I'm not sure what the state is with https://github.com/pallet/ritz but I 
> think that it may be what you are looking for in a development environment.
> 
> Chris.
> 

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

[Neale Swinnerton]

The disruptor project from LMAX has wrestled with these sort of issues at
length and achieved astounding levels of performance on the JVM

Martin Thompson, the original author of the disruptor, is a leading light
in the JVM performance space, his mechanical sympathy blog is a goldmine of
information and a must read for anyone wanting to understand the JVM /
hardware interface.

Find more info at:

http://mechanical-sympathy.blogspot.co.uk/

http://lmax-exchange.github.io/disruptor/


*Neale Swinnerton*
{t: @sw1nn , w: sw1nn.com }


On 27 September 2013 12:29, Wm. Josiah Erikson  wrote:

> Interesting! If that is true of Java (I don't know Java at all), then your
> argument seems plausible. Cache-to-main-memory writes still take many more
> CPU cycles (an order of magnitude more, last I knew) than
> processor-to-cache. I don't think it's so much a bandwidth issue as
> latency, AFAIK. Thanks for thinking about this more, so long after the
> fact. We still see the issue.
>  On Sep 26, 2013 11:43 PM, "Andy Fingerhut" 
> wrote:
>
>> Adding to this thread from almost a year ago.  I don't have conclusive
>> proof with experiments to show right now, but I do have some experiments
>> that have led me to what I think is a plausible cause of not just Clojure
>> programs running more slowly when multi-threaded than when single-threaded,
>> but any programs running on JVM's memory model doing so.  Qualification: My
>> explanation would be true only for multi-threaded programs running on the
>> JVM that store significant amounts of data in memory, even if the data
>> written by each thread is only read by that thread, and there is no locking
>> or other inter-thread communication, i.e. for "embarrasingly parallel"
>> problems.
>>
>> Outline of the argument:
>>
>> When you start a thread, and then wait for the thread to complete, the
>> JVM memory model requires all loads and stores to satisfy certain
>> restrictions.  One of these is that any store done before the thread is
>> created should 'happen before' the thread start, and thus the updated
>> stored values must be visible to the new thread.  'Visible' here means that
>> the thread doing the store must cause the CPU it is running on to update
>> main memory from whatever locally modified values it has written into its
>> local cache.  That rule isn't so relevant to my argument.
>>
>> The one that is relevant is that any store performed by the thread is
>> considered to 'happen before' a join operation on the thread.  Thus any
>> store done by a thread must be written back to main memory, *even if the
>> store is to a JVM object that later becomes garbage*.
>>
>> So imagine a single-threaded program that creates X bytes of garbage
>> while it runs.  Those X bytes will definitely be written to the CPU's local
>> cache, but they will only be written to main memory if the cache space runs
>> out before the garbage collector does its work and allows that memory to be
>> reused for allocations.  The CPU-to-local-cache bandwidth in many modern
>> systems is significantly faster than local-cache-to-main-memory bandwidth.
>>
>> Now take that same program and spread its work across 2 or more threads,
>> with a join at the end of each one.  For the sake of example, say that each
>> thread will write X/N bytes of data while it runs.  Even if the only data
>> needed later in the rest of the program is a single Long object, for
>> example, all of those X/N bytes of data will be copied from the local cache
>> to main memory (if that did not already happen before the thread
>> terminated).
>>
>> If the number of threads is large enough, the amount of data written from
>> all local caches to main memory can be higher in the multi-threaded case
>> than in the single-threaded case.
>>
>> Anyway, that is my hypothesis about what could be happening here.  It
>> isn't Clojure-specific, but it can be exacerbated by the common behavior of
>> a lot of Clojure code to allocate significant amounts of memory that
>> becomes garbage.
>>
>> Andy
>>
>>
>>
>> On Wed, Jan 30, 2013 at 6:20 PM, Lee Spector wrote:
>>
>>>
>>> FYI we had a bit of a discussion about this at a meetup in Amherst MA
>>> yesterday, and while I'm not sufficiently on top of the JVM or system
>>> issues to have briefed everyone on all of the details there has been a
>>> little of followup since the discussion, including results of some
>>> different experiments by Chas Emerick, at:
>>> http://www.meetup.com/Functional-Programming-Connoisseurs/messages/boards/thread/30946382
>>>
>>>  -Lee
>>>
>>> On Jan 30, 2013, at 8:39 PM, Marshall Bockrath-Vandegrift wrote:
>>> >
>>> > Apologies for my very-slow reply here.  I keep thinking that I’ll have
>>> > more time to look into this issue, and keep having other things
>>> > requiring my attention.  And on top of that, I’ve temporarily lost the
>>> > many-way AMD system I was using as a test-bed.
>>> >
>>> > I very much want to see if I can get my hands on 

Re: abysmal multicore performance, especially on AMD processors

[Wm. Josiah Erikson]

Interesting! If that is true of Java (I don't know Java at all), then your
argument seems plausible. Cache-to-main-memory writes still take many more
CPU cycles (an order of magnitude more, last I knew) than
processor-to-cache. I don't think it's so much a bandwidth issue as
latency, AFAIK. Thanks for thinking about this more, so long after the
fact. We still see the issue.
On Sep 26, 2013 11:43 PM, "Andy Fingerhut"  wrote:

> Adding to this thread from almost a year ago.  I don't have conclusive
> proof with experiments to show right now, but I do have some experiments
> that have led me to what I think is a plausible cause of not just Clojure
> programs running more slowly when multi-threaded than when single-threaded,
> but any programs running on JVM's memory model doing so.  Qualification: My
> explanation would be true only for multi-threaded programs running on the
> JVM that store significant amounts of data in memory, even if the data
> written by each thread is only read by that thread, and there is no locking
> or other inter-thread communication, i.e. for "embarrasingly parallel"
> problems.
>
> Outline of the argument:
>
> When you start a thread, and then wait for the thread to complete, the JVM
> memory model requires all loads and stores to satisfy certain
> restrictions.  One of these is that any store done before the thread is
> created should 'happen before' the thread start, and thus the updated
> stored values must be visible to the new thread.  'Visible' here means that
> the thread doing the store must cause the CPU it is running on to update
> main memory from whatever locally modified values it has written into its
> local cache.  That rule isn't so relevant to my argument.
>
> The one that is relevant is that any store performed by the thread is
> considered to 'happen before' a join operation on the thread.  Thus any
> store done by a thread must be written back to main memory, *even if the
> store is to a JVM object that later becomes garbage*.
>
> So imagine a single-threaded program that creates X bytes of garbage while
> it runs.  Those X bytes will definitely be written to the CPU's local
> cache, but they will only be written to main memory if the cache space runs
> out before the garbage collector does its work and allows that memory to be
> reused for allocations.  The CPU-to-local-cache bandwidth in many modern
> systems is significantly faster than local-cache-to-main-memory bandwidth.
>
> Now take that same program and spread its work across 2 or more threads,
> with a join at the end of each one.  For the sake of example, say that each
> thread will write X/N bytes of data while it runs.  Even if the only data
> needed later in the rest of the program is a single Long object, for
> example, all of those X/N bytes of data will be copied from the local cache
> to main memory (if that did not already happen before the thread
> terminated).
>
> If the number of threads is large enough, the amount of data written from
> all local caches to main memory can be higher in the multi-threaded case
> than in the single-threaded case.
>
> Anyway, that is my hypothesis about what could be happening here.  It
> isn't Clojure-specific, but it can be exacerbated by the common behavior of
> a lot of Clojure code to allocate significant amounts of memory that
> becomes garbage.
>
> Andy
>
>
>
> On Wed, Jan 30, 2013 at 6:20 PM, Lee Spector wrote:
>
>>
>> FYI we had a bit of a discussion about this at a meetup in Amherst MA
>> yesterday, and while I'm not sufficiently on top of the JVM or system
>> issues to have briefed everyone on all of the details there has been a
>> little of followup since the discussion, including results of some
>> different experiments by Chas Emerick, at:
>> http://www.meetup.com/Functional-Programming-Connoisseurs/messages/boards/thread/30946382
>>
>>  -Lee
>>
>> On Jan 30, 2013, at 8:39 PM, Marshall Bockrath-Vandegrift wrote:
>> >
>> > Apologies for my very-slow reply here.  I keep thinking that I’ll have
>> > more time to look into this issue, and keep having other things
>> > requiring my attention.  And on top of that, I’ve temporarily lost the
>> > many-way AMD system I was using as a test-bed.
>> >
>> > I very much want to see if I can get my hands on an Intel system to
>> > compare to.  My AMD system is in theory 32-way – two physical CPUs, each
>> > with 16 cores.  However, Linux reports (via /proc/cpuinfo) the cores in
>> > groups of 8 (“cpu cores : 8” etc).  And something very strange happens
>> > when extending parallelism beyond 8-way...  I ran several experiments
>> > using a version of your whole-application benchmark I modified to
>> > control the level of parallelism.  At parallelism 9+, the real time it
>> > takes to complete the benchmark hardly budges, but the user/CPU time
>> > increases linearly with the level of parallelism!  As far as I can tell,
>> > multi-processor AMD *is* a NUMA architecture, which might potentially
>> > explain thing

Re: ANN: Pulsar 0.2.0 Released

[Hank]

Hi Ron,

Different concern from the above so another post. :) Do you think Pulsar 
can help make Oz-style dataflow 
concurrencya
 reality on the JVM? As discussed in the popular Concepts, 
Techniques & Models of Programming, 
e.g. chapter 4.5 See the Ozma effort on bringing this to the 
JVM-- yes I know the talk is about 
Scala but Clojure would equally benefit 
from such an extension -- the key takeaway being that a lack of lightweight 
threads on the JVM doesn't make this feasible just yet.

Cheers
-- hank

On Saturday, July 20, 2013 1:49:55 AM UTC+10, pron wrote:
>
> Featuring: distributed actors, supervisors, fiber-blocking IO, and an 
> implementation of core.async.
> Read the announcement 
> here
> .
>
> Imagine running an entire Ring handler inside a go-block...
>
>

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

Re: ANN: Pulsar 0.2.0 Released

[Hank]

Hi Ron,

Does this have any chance of running on Android at all? There is no "java 
agent" on Android's VM "Dalvik" so the byte code instrumentation would have 
to be plugged in elsewhere. Clojure on Android already involves byte code 
manipulation as JVM byte code generated by Clojure's compiler has to be 
passed through a second step called "Dex" to turn it into Dalvik byte code. 
Currently this is done by (a) AOT-compiling the Clojure application as much 
as possible and doing the Dex as part of your build process and (b) using 
custom class loader that instruments byte code generated at runtime through 
"eval".

If only application generated byte code has to be instrumented in order for 
Pulsar to work, then Pulsar's instrumentation could be plugged into the 
same places one step before the Dex step. However you can't reach byte code 
from system classes/the run time library this way. Does Pulsar need to 
instrument system classes/the runtime library to do its thing?

Cheers
-- hank

On Saturday, July 20, 2013 1:49:55 AM UTC+10, pron wrote:
>
> Featuring: distributed actors, supervisors, fiber-blocking IO, and an 
> implementation of core.async.
> Read the announcement 
> here
> .
>
> Imagine running an entire Ring handler inside a go-block...
>
>

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

Re: [ANN] ribol "v0.2.1" - comprehensive document on conditional restart systems

[zcaudate]

Hi Dima,
>
>
I've push v0.2.3 to clojars... an example can be seen 
here: http://z.caudate.me/ribol/#raise-on

(raise-on [[NumberFormatException ArithmeticException] :divide-by-zero
   Throwable :throwing]
  (throw (Throwable. "oeuoeu"))
  (finally (println 1)))
=> (raises-issue {:throwing true}) ;; prints 1

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

Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure

[Chris Zheng]

thanks for your thoughts!


On 27/09/2013, at 12:45 PM, Ryan Brush  wrote:

> Hey, I appreciate the thoughts. Funny how posting a project yields use cases 
> you've never thought of. I went ahead and logged an issue to track arbitrary 
> maps as facts here:
> 
> https://github.com/rbrush/clara-rules/issues/6
> 
> I'm looking for ways to align with you needs, but I don't see an immediately 
> obvious way to do so. Out of respect for this mailing list, it probably seems 
> best to use the github issue to go deeper on this one. 
> 
> -Ryan
> 
> On Thursday, September 26, 2013 5:03:24 PM UTC-5, zcaudate wrote:
> Hi Ryan!
> 
> Thanks for your response. I would love to see maps and nested maps as part of 
> the rules. I find that clara provides great syntax for defining inputs and 
> outputs and I would love to use it as a rules engine just beneath my front 
> end. 
> 
> However, most of my work is web based, data is javascript and so I'm 
> converting it into clojure maps and dispatching based on routes
> 
> I'm not sure adding a :type field would be a good idea. I've implemented 
> something much simpler to work with arrays of elements with different ways 
> that elements can be selected and its better to work directly with the data 
> itself rather than tag….
> 
> I'm really hoping that something similar could be implemented in with routes 
> and data… something like:
> 
> (defmaprule notify-client-rep
>   "Find the client represntative and send a notification of a support 
> request."
>[:support/request [req] (== ?client (:client req))
>[:add/client/representive [req]  ((req :clients) ?client) (== ?name (:name 
> req))]
> => (println "Notify" ?name "that" ?client "has a support request")
> )
> 
> 
> On 27/09/2013, at 12:23 AM, Ryan Brush  wrote:
> 
>> Not yet, although I would like to make use of simple maps natural. I had 
>> been toying with the idea of typing into the :type metadata that could be 
>> attached to a map, allowing expressions like:
>> 
>> (defrule test-rule 
>>[:example/person-map-type (= "Alice" (:first-name this))]
>>=>
>>(println "Hello, Alice!"))
>> 
>> That way any map with that type annotation could be used in the rule. Today 
>> Clara does automatically bind "this" as a reference to the matched object, 
>> so functions can be called against it. (I'm not particularly thrilled by the 
>> implicit binding of "this", but it is common in rules engines so I included 
>> it here.)
>> 
>> The advantage of records is they have a pre-defined type and pre-defined 
>> fields, so they are a natural alternative to facts and slots seen in other 
>> production systems. But since simple maps are so common in Clojure code I do 
>> want to incorporate them here, either by tapping into the type metadata as 
>> seen in the above example, or by doing something akin to how multimethods 
>> work, where the fact "type" is effectively defined by a function.
>> 
>> I'd love to hear suggestions on this one. The goal is to get the advantages 
>> of a production system in a way that feels natural to Clojure developers. 
>> What would feel most natural to members of this group?
>> 
>> On Wednesday, September 25, 2013, zcaudate wrote:
>> Hi Ryan!
>> 
>> Great work. Can normal clojure maps can be used instead of records?
>> 
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 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/pfeFyZkoRdU/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 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/pfeFyZkoRdU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_ou

Re: [ANN] ribol "v0.2.1" - comprehensive document on conditional restart systems

[Chris Zheng]

Hey Lee.

I'm learning conditional restarts myself…. thus the reason why I implemented 
the library so I'm probably not the best person to ask

As far as I know… restarts have to be supported by the language itself in order 
for it to truly blossom the way you are describing it. ribol is just a library, 
not a platform and definitely not a development environment.

I'm not sure what the state is with https://github.com/pallet/ritz but I think 
that it may be what you are looking for in a development environment.

Chris.



On 27/09/2013, at 11:06 AM, Lee Spector  wrote:

> 
> I apologize for the naivety of this question, but whenever I see 
> libraries/discussions of enhanced mechanisms for 
> exceptions/conditions/errors/restarts/etc in Clojure I wonder if they could 
> provide a couple of features that I dearly miss from Common Lisp, and this 
> contribution makes me wonder the same thing. I looked briefly through the 
> guide (nice diagrams!) but couldn't quite tell if it could do what I miss 
> from Common Lisp in Clojure, and therefore whether I should take the time to 
> study it in more detail.
> 
> What do I miss from Common Lisp condition handling?
> 
> When you hit an error in Common Lisp you get a REPL (sometimes called a 
> "break loop") that lives in the context where the error occurred. The most 
> useful thing to me is that you can examine the state of the system there 
> (through normal REPL interactions) and look at the values of local variables 
> all up and down the stack. In addition, you can change the values of 
> variables and restart the computation, and the restart mechanisms can be 
> customized based on the type of error/condition... which is very cool and 
> occasionally useful, but for me personally the big win is in just being able 
> to really examine the state at the point of the error (including running 
> little pieces of code to help to examine the state, etc.).
> 
> Note that this happens in Common Lisp wherever an error occurs, and the 
> programmer doesn't have to mark or wrap expressions in any special way to get 
> this functionality. Which is crucial, because many of the situations in which 
> this is useful are ones when you hit an error that you had no idea existed, 
> and you certainly didn't know in advance where errors would occur.
> 
> Another Common Lisp feature that's very handy in this context is the ability 
> to trigger an interrupt manually from the keyboard and end up in the same 
> kind of break loop. Your program seems to be hung and you have no idea what 
> it's doing? Interrupt it and look at the stack and the local variables. 
> Everything looks okay but it's just taking a long time? Restart and you're 
> back in action, continuing from where the interrupt occurred. If it doesn't 
> look okay then examine the state to try to figure out what went wrong, abort 
> the computation, fix the problem and re-run from the beginning.
> 
> My sense has been that this kind of functionality doesn't exist in any 
> Clojure environment, maybe due to something about how the JVM works (about 
> which I don't know very much, which may be very clear to all of you :-). But 
> when I see fancy new conditional restart mechanisms etc. then I get a glimmer 
> of hope that maybe I'm wrong about this.
> 
> So, can any existing libraries/systems in the Clojure ecosystem provide this 
> functionality? Is it conceivable that any would in the future?
> 
> Thanks,
> 
> -Lee
> 
> 
> 
> 
> On Sep 25, 2013, at 3:14 AM, zcaudate wrote:
> 
>> I've done a pretty comprehensive guide on conditional restart systems in 
>> clojure with diagrams to show why it is much more flexible over try/catch 
>> mechanism
>> 
>> Project:
>>https://github.com/zcaudate/ribol
>> 
>> Generated Documentation:
>>http://z.caudate.me/ribol/
>> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/elRWA13Iidg/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