Re: Efficiently typing an argument of implementation in deftype

[Jason Wolfe]

FWIW I observed the same thing profiling 1.5.1 with Yourkit a couple months 
ago and tried adding caching to the Clojure compiler, but I wasn't able to 
get any speedup.  It wasn't clear to me if I messed something up, or if the 
profiler was just lying about where the execution time was actually going.

On Friday, September 20, 2013 7:01:39 AM UTC-7, Dmitry Groshev wrote:
>
> In this mail I'm talking about Clojure 1.4, however, I believe that the 
> issue persists in later versions, too.
>
> I have quite a lot of code of the following form:
>
> (defprotocol sum-proto
>   (sum [x y]))
>
> (deftype Pair
> [^long a ^long b]
>   sum-proto
>   (sum [x y]
> (let [^Pair y y
>   new-a (+ (.a x) (.a y))
>   new-b (+ (.b x) (.b y))]
>   (Pair. new-a new-b
>
> In real code there are *a lot* of implementations in that deftype 
> generated by macroses. The problem is that compilation time skyrocketed. 
> Right now I'm facing 5-10 seconds of compilation, which makes incremental 
> development very painful. Profiler shows that the overwhelming majority of 
> this time is spent here: [1]. It follows that the problem is in that ^Pair 
> annotation: when symbol is tagged by a symbol, it should be resolved as a 
> class. It should be way faster if I can "cache" that resolution, but I 
> can't given that those implementation are inside of deftype, I can't 
> resolve in advance the class that isn't defined. And I can't use 
> extend-type either because of the cost of extra var lookup.
>
> The main question is: what can I do to make compilation faster? 
> Pre-resolving that class won't work, it seems.
>
> [1]: 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986
>

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

[Michał Marczyk]

On 21 September 2013 02:42, Michał Marczyk  wrote:
> [avl.clj "0.0.1"]
>
> 
>   avl.clj
>   avl.clj
>   0.0.1
> 

Make that

[avl.clj "0.0.2"]

and

 
   avl.clj
   avl.clj
   0.0.2
 

Cheers,
Michał

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

[Michał Marczyk]

Hi,

I have just released avl.clj, a library implementing drop-in
replacements for Clojure(Script)'s sorted maps and sets which
additionally support the transients API and logarithmic time rank
queries via clojure.core/nth:

(require '[avl.clj :as avl])

(nth (apply avl/sorted-set (range 10)) 5)
;= 5

Performance is mostly on a par with the built-in red-black-tree-based
variants in my preliminary benchmarking.

If you'd like to take it for a spin, here's the Leiningen/Maven
dependency information for the initial release:

[avl.clj "0.0.1"]


  avl.clj
  avl.clj
  0.0.1


Project repository:

https://github.com/michalmarczyk/avl.clj

Artefact's page on Clojars:

https://clojars.org/avl.clj

Cheers,
Michał

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

[Patrick Logan]

"Expansion Passing Style" is a similar mechanism described in 
http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=B1F3B3E99DE8FD3BD5CA489868730967?doi=10.1.1.50.4332

A number of interesting (and easy to implement) examples are in the paper, 
including debugging tools. This is an easy way to get symbolic debuggers 
and inspectors up and running.



On Wednesday, September 18, 2013 1:21:26 PM UTC-7, Zach Tellman wrote:
>
> This is a lein plugin which hijacks the Clojure reader and allows all 
> forms to be transformed before they're passed to the compiler.  Usage and 
> potential applications are described in the readme: 
> https://github.com/ztellman/sleight
>
> I wrote the original version of this a year ago, but due to the lack of 
> good code walking facilities it was more a sketch than anything else. 
>  Luckily, with the recent release of Riddley [1], this is newly useful. 
>  I'm looking forward to seeing what people use it for.
>
> Zach
>
> [1] https://github.com/ztellman/riddley
>

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

[Ambrose Bonnaire-Sergeant]

Just a thought, could implementing IKeywordInvoke and using keywords for
field lookups speed up compilation?

Thanks,
Ambrose


On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev wrote:

> In this mail I'm talking about Clojure 1.4, however, I believe that the
> issue persists in later versions, too.
>
> I have quite a lot of code of the following form:
>
> (defprotocol sum-proto
>   (sum [x y]))
>
> (deftype Pair
> [^long a ^long b]
>   sum-proto
>   (sum [x y]
> (let [^Pair y y
>   new-a (+ (.a x) (.a y))
>   new-b (+ (.b x) (.b y))]
>   (Pair. new-a new-b
>
> In real code there are *a lot* of implementations in that deftype
> generated by macroses. The problem is that compilation time skyrocketed.
> Right now I'm facing 5-10 seconds of compilation, which makes incremental
> development very painful. Profiler shows that the overwhelming majority of
> this time is spent here: [1]. It follows that the problem is in that ^Pair
> annotation: when symbol is tagged by a symbol, it should be resolved as a
> class. It should be way faster if I can "cache" that resolution, but I
> can't given that those implementation are inside of deftype, I can't
> resolve in advance the class that isn't defined. And I can't use
> extend-type either because of the cost of extra var lookup.
>
> The main question is: what can I do to make compilation faster?
> Pre-resolving that class won't work, it seems.
>
> [1]:
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: print-dup is not defined? Ok, what do you want me to do about that?

[Jamie Brandon]

JVM bytecode can't contain data-structures, only code. If you eval
something or embed it in macro output the clojure compiler needs to be
able to output code that reconstructs an equal object. There are some
types that it can't do that for.

user=> (def x)
#'user/x
user=> x
#
user=> (eval x)
#
user=> (eval [x])

CompilerException java.lang.RuntimeException: Can't embed object in
code, maybe print-dup not defined: Unbound: #'user/x,
compiling:(NO_SOURCE_PATH:1:1)

The compiler seems to be complaining that print-dup is not defined at
that the point that it is used. I *would* suspect some subtle
read-time/compile-time distinction in when vars are defined inside a
single form but I can't reproduce your problem:

user=> (binding [*foo* nil]
  #_=>   (def e 1)
  #_=>   `e)
user/e
user=> (binding [*foo* nil]
  #_=>   (def x 1)
  #_=>   x)
1
user=> (binding [*foo* nil]
  #_=>   (def y 1)
  #_=>   (eval `y))
1
user=> (binding [*foo* nil]
  #_=>   (def z 1)
  #_=>   ^{:tag `z} [])
[]
user=> (binding [*foo* nil]
  #_=>   (def q 1)
  #_=>   ^{:tag #=(eval `q)} [])
[]
user=> (binding [*foo* nil]
  #_=>   (defn bar [])
  #_=>   (bar))
nil

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

[Stephen Cagle]

Good eye. To your second point, I accidentally copied those namespaces out 
when attempting to "focus" my report of this problem. 

*   [com.samedhi.app.fixture :as f]*
*   [clojure.data.generators :as g]*

So clojure.test.generative as generative and clojure.data.generators as g. 

To your last point, yes, using zero? would be more concise and idiomatic.

Finally, to your first point. I don't know why I was using syntax-quotes as 
opposed to regular quotes.

 without quotes or with simple quotes, the namespace evaluates to 
clojure.data.generators (I guess because it is in the tag), the quote 
"hack" is mentioned in the middle of test.generative's github page.
*[^{:tag random-loc} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag view} value]*

OR
 
*[^{:tag 'random-loc} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag 'view} value]*

=> *java.lang.RuntimeException: No such var: 
clojure.data.generators/random-loc*

With the full expansion, the syntax quote, the quoted full expansion, and 
the syntax-quoted full-expansion, I get the print-dup error:

*[^{:tag com.samedhi.app.test.behavior-test/random-loc} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag com.samedhi.app.test.behavior-test/view} value]*

OR

*   [^{:tag `random-loc} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag `view} value]*

OR 

*  [^{:tag 'com.samedhi.app.test.behavior-test/random-loc} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag 'com.samedhi.app.test.behavior-test/view} value]*

OR

*  [^{:tag `com.samedhi.app.test.behavior-test/random-loc} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag `com.samedhi.app.test.behavior-test/view} value]*

=> *Caused by: java.lang.RuntimeException: Can't embed object in code, 
maybe print-dup not defined: Unbound: 
#'com.samedhi.app.test.behavior-test/random-loc*

Finally, with being "commented out" by just returning nil, it does compile 
but of course the actual test fail.

*   [^{:tag (clojure.core/constantly nil)} loc*
* ^{:tag (clojure.core/constantly :ignored)} key*
* ^{:tag (clojure.core/constantly nil)} value]*

=> Test fail as they were not expecting nil.

Finally, I thought to just remove the binding in its entirety, setting the 
atom in *view*'s def.

*(def ^:dynamic *view* (atom*
*  {:old-model [nil nil nil nil nil nil]*
*   :quiz [nil nil nil nil nil nil nil]*
*   :loc nil}))*
*
*
*(defn view [] @*view*)*
*
*
*(defn random-loc []*
*  (let [loc (-> (view) :loc random-walk-loc)*
*loc (if (= 0 (g/uniform 0 100)) (f/loc) loc)]*
*(swap! *view* assoc :loc loc)*
*loc))*
*
*
*(generative/defspec*
*  check-on-quiz-view*
*  b/quiz-view*
*  [^{:tag (clojure.core/constantly nil)} loc*
*   ^{:tag (clojure.core/constantly :ignored)} key*
*   ^{:tag (clojure.core/constantly nil)} value])*

This does work, but now I assume the atom is being shared among all 4 
threads, which isn't really what I wanted. Furthermore, without some 
additional synchronization, I am pretty sure that I could have some invalid 
state.

On Friday, September 20, 2013 12:01:41 AM UTC-7, Stephen Cagle wrote:
>
> *
> (ns com.samedhi.app.test.behavior-test
>   (:require
>[clojure.test.generative :as generative])
>
>   (:use
>[com.samedhi.quizry.app.test.defspec :only [defspec]]
> ))
>
> *
> *... ommited content ...*
> *
> *
> *(def ^:dynamic *view* nil)*
> *
> *
> *(binding [*view* (atom;; 
> this is line 69*
> *  {:old-model [nil nil nil nil nil nil]*
> *   :quiz [nil nil nil nil nil nil nil]*
> *   :loc nil})]*
> *  *
> *(defn view [] @*view*)*
> *  *
> *(defn random-loc []*
> *  (let [loc (-> (view) :loc random-walk-loc)*
> *loc (if (= 0 (g/uniform 0 100)) (f/new-loc) loc)]*
> *(swap! *view* assoc :loc loc)*
> *loc))*
> *
> *
> *(generative/defspec*
> *  check-on-quiz-view*
> *  b/quiz-view*
> *  [^{:tag `random-loc} loc*
> *   ^{:tag (clojure.core/constantly :ignored)} key*
> *   ^{:tag `view} value]))*
>
> Gives me the error:
> *Exception in thread "main" java.lang.RuntimeException: Can't embed 
> object in code, maybe print-dup not defined: Unbound: 
> #'com.samedhi.app.test.behavior-test/random-loc, 
> compiling:(com/samedhi/app/test/behavior_test.clj:69:1)
> *
>
> I vaguely understand that this is saying that something in here does not 
> have a print-dup method on it, and as such, cannot be "codified". How do I 
> determine what the problem is? 
>
> You might wonder why I am using a binding anyway? defspec is from 
> test.generative. This defspec is testing b/quiz-view with the supplied 
> argument vector. I have a dependency between the first argument (loc) and 
> the third argument (value), hence the shared atom. Furthermore, I wish each

ANN EEP 1.0.0-alpha5 is released

[Michael Klishin]

EEP [1] is a Clojure stream processing library.

1.0.0-alpha5 is a development release that introduces
a few minor API improvements and bug fixes.

Release notes:
http://blog.clojurewerkz.org/blog/2013/09/20/eep-1-dot-1-0-alpha5-is-released/

1. http://blog.clojurewerkz.org/blog/2013/08/29/stream-processing-with-eep/
-- 
MK

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

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

Lifecycle Composition

[Murtaza Husain]

Hi,

I am going through the blog of Stuart Sierra regarding lifecycle 
composition. http://stuartsierra.com/2013/09/15/lifecycle-composition

In the end there is this para - 

"This technique is a form of dependency injection through constructors.
The choice of whether to make the individual components mutable,
stateful objects has an impact on how I can use them later on. In the
original version of this pattern using mutable objects, each component
gets stable references to other components it depends on. In the later
version using immutable data structures, each component gets
references to the *constructed* versions of other components it
depends on, but not the *started* versions of those components,
i.e. the values returned from start."

I am unable to discern the pros and cons of both the versions (approaches). 
Any concrete examples will be appreciated. 

Thanks,
Murtaza

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

[Stephen Cagle]

(... don't you wish you could edit your post).

And shoot, the last example should have been the following (I had forgot to 
remove the (constantly nil) parts:

*(def ^:dynamic *view* (atom*
*   {:old-model [nil nil nil nil nil nil]*
*:quiz [nil nil nil nil nil nil nil]*
*:loc nil}))*
*
*
*(defn view [] @*view*)*
*
*
*(defn random-loc []*
*  (let [loc (-> (view) :loc random-walk-loc)*
*loc (if (= 0 (g/uniform 0 100)) (f/quiz) loc)]*
*(swap! *view* assoc :loc loc)*
*loc))*
*
*
*(generative/defspec*
*  check-on-quiz-view*
*  b/quiz-view*
*  [^{:tag `random-loc} loc*
*   ^{:tag (clojure.core/constantly :ignored)} key*
*   ^{:tag `view} value])*

On Friday, September 20, 2013 12:01:41 AM UTC-7, Stephen Cagle wrote:
>
> *
> (ns com.samedhi.app.test.behavior-test
>   (:require
>[clojure.test.generative :as generative])
>
>   (:use
>[com.samedhi.quizry.app.test.defspec :only [defspec]]
> ))
>
> *
> *... ommited content ...*
> *
> *
> *(def ^:dynamic *view* nil)*
> *
> *
> *(binding [*view* (atom;; 
> this is line 69*
> *  {:old-model [nil nil nil nil nil nil]*
> *   :quiz [nil nil nil nil nil nil nil]*
> *   :loc nil})]*
> *  *
> *(defn view [] @*view*)*
> *  *
> *(defn random-loc []*
> *  (let [loc (-> (view) :loc random-walk-loc)*
> *loc (if (= 0 (g/uniform 0 100)) (f/new-loc) loc)]*
> *(swap! *view* assoc :loc loc)*
> *loc))*
> *
> *
> *(generative/defspec*
> *  check-on-quiz-view*
> *  b/quiz-view*
> *  [^{:tag `random-loc} loc*
> *   ^{:tag (clojure.core/constantly :ignored)} key*
> *   ^{:tag `view} value]))*
>
> Gives me the error:
> *Exception in thread "main" java.lang.RuntimeException: Can't embed 
> object in code, maybe print-dup not defined: Unbound: 
> #'com.samedhi.app.test.behavior-test/random-loc, 
> compiling:(com/samedhi/app/test/behavior_test.clj:69:1)
> *
>
> I vaguely understand that this is saying that something in here does not 
> have a print-dup method on it, and as such, cannot be "codified". How do I 
> determine what the problem is? 
>
> You might wonder why I am using a binding anyway? defspec is from 
> test.generative. This defspec is testing b/quiz-view with the supplied 
> argument vector. I have a dependency between the first argument (loc) and 
> the third argument (value), hence the shared atom. Furthermore, I wish each 
> succesive call to b/quiz-view to be a slight modification of the previous 
> value, where the loc has been randomly moved around a bit. Ocasionally (1 
> in a 100), I just create a entirely new loc with f/new-loc. All of this 
> could have been done with a shared atom. However, it seems that 
> test.generative actually uses N-threads, which means I want each thread to 
> have its own atom. Hence, by my reasoning, the use of binding and 
> ^:dynamic. BTW, the tick before random-loc and view allows them to evaluate 
> in the the current namespace, as otherwise they would be evaluated in 
> clojure.core.generators (I don't really understand why).
>  
> https://github.com/clojure/test.generative ;; just for reference
>
> I am obviously wrong in my implementation (it does not compile), I could 
> be wrong in my reasoning as well, but I am most worried about the fact that 
> I have no real idea *what* is not working here. Any help is appreciated.
>

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

[Maik Schünemann]

great summary of your experience. I think others will find this helpful.
I was also surprised at first that the metadata is added to the
next form *read* if you use ^ reader macro. This explains the
following behaviour:
(meta ^:matrix 'x) ;=> nil
(meta ' ^:matrix x) ;=> {:matrix true}
in the first case the metadata is added to the expanded (quote x) and not
to x itself.

On Fri, Sep 20, 2013 at 6:46 PM, Dmitry Groshev  wrote:
> I've summarized a couple of things that wasn't obvious to me when I started
> to work on core.matrix's macroses. Comments are appreciated:
> http://si14.livejournal.com/51576.html
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: print-dup is not defined? Ok, what do you want me to do about that?

[Stephen Cagle]

ugh, I also see that for the last example, where I just removed the binding 
I said "all 4 threads", I should have said "all N threads". (There are 4 in 
my case, but that is just on my machine)

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

Reading single characters...?

[Simon Brooke]

I've discovered some interesting behaviour - not necessarily a bug, and (if 
it is a bug) not necessarily a bug in Clojure.

Essentially, to emulate a 1970s user interface, I want to read single key 
strokes from the console. I've found two recipes online, both using the 
JLine java package:

http://stackoverflow.com/questions/13435541/reading-unbuffered-keyboard-input-in-clojure
http://stackoverflow.com/questions/3225025/single-character-console-input-in-java-clojure

One of these recipes uses Terminal.getTerminal(), the other uses new 
ConsoleReader(). What happens in my context (Debian on 64 bit Intel) is 
that as soon as an instance of either class is instantiated, echoing to the 
console ceases. If you do (obviously, with the jline jar on the classpath):

(import 'jline.Terminal)
(def term (Terminal/getTerminal))
(.initializeTerminal term)
(.enableEcho term)


(or the equivalent things with a ConsoleReader), every keystroke is echoed 
twice. But if you do

user=> ((..ddiissaabblleeEEcchhoo  tteerrmm))
^Jnil

one single further character gets echoed and then nothing more, unless you 
type (blindly) (.enableEcho term), when the double-echoing behaviour 
resumes. This is consistent - on my Debian box - with Clojure 1.2, Clojure 
1.3, and Clojure 1.5.1, all using jline 1.0. I haven't yet compiled up a 
little Java app to find out what happens without Clojure, and I haven't 
tried compiling a little command-line Clojure app, because I want to be 
able to read single characters in the context of the REPL, so if, as I 
hypothesise, jline is fighting with the REPL, proving whether it works 
outwith the context of the REPL doesn't really help me.

Has anyone else seen this behaviour? Is there any solution?

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

[GSoC] Some subtle details of type-hinted macro expansion in Clojure

[Dmitry Groshev]

I've summarized a couple of things that wasn't obvious to me when I started 
to work on core.matrix's macroses. Comments are appreciated: 
http://si14.livejournal.com/51576.html

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

[Bogdan Opanchuk]

Hello all,

There was a thread a while ago with me asking about the ways to modify the 
S-expression syntax in Clojure as it's done in 
Scribble. 
Long story short, I'm happy to announce a working (well, to my current 
knowledge) implementation: on clojars , or on 
github . The readme file on 
github contains some usage instructions, and the list of differences from 
the original Scribble syntax (with explanations). The current version is a 
snapshot, since I depend on a snapshot version of 
chiara. 
I'll update the version as soon as chiara is released.

I've made this for my own purposes, but perhaps it may be useful to other 
people as a generalized template engine. Anyway, it is my first Clojure 
project, so I'll be grateful for any comments, or even pull requests.

P.S. Given the current list of differences from the original Scribble 
syntax, and the fact that the original Scribble is actually a syntax + a 
documentation generation system, I do not insist on keeping the name.  

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

Efficiently typing an argument of implementation in deftype

[Dmitry Groshev]

In this mail I'm talking about Clojure 1.4, however, I believe that the 
issue persists in later versions, too.

I have quite a lot of code of the following form:

(defprotocol sum-proto
  (sum [x y]))

(deftype Pair
[^long a ^long b]
  sum-proto
  (sum [x y]
(let [^Pair y y
  new-a (+ (.a x) (.a y))
  new-b (+ (.b x) (.b y))]
  (Pair. new-a new-b

In real code there are *a lot* of implementations in that deftype generated 
by macroses. The problem is that compilation time skyrocketed. Right now 
I'm facing 5-10 seconds of compilation, which makes incremental development 
very painful. Profiler shows that the overwhelming majority of this time is 
spent here: [1]. It follows that the problem is in that ^Pair annotation: 
when symbol is tagged by a symbol, it should be resolved as a class. It 
should be way faster if I can "cache" that resolution, but I can't given 
that those implementation are inside of deftype, I can't resolve in advance 
the class that isn't defined. And I can't use extend-type either because of 
the cost of extra var lookup.

The main question is: what can I do to make compilation faster? 
Pre-resolving that class won't work, it seems.

[1]: 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986

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

[François De Serres]

Bonne chance Cognitect !!!

Le lundi 16 septembre 2013 15:50:46 UTC+2, Rich Hickey a écrit :
>
> I just wanted to let everyone know that Metadata Partners (the company 
> behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, 
> Inc. This merger is great for Clojure, adding considerable resources and 
> stability to its development and support, including new enterprise support 
> offerings and reinvigorated community support. (You should read the hiring 
> of Alex Miller as the first example of the latter). 
>
> I hope the availability of enterprise support for the entire platform 
> makes it easier for people to introduce Clojure into their organizations. 
>
> This is a very exciting time for Clojure and the platform and ecosystem 
> surrounding it. You can find out more at: 
>
> http://cognitect.com 
>
> Thanks, 
>
> Rich

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

[Simon Brooke]

I'd like to announce fedit, a structure editor for Clojure, is now 
available on GitHub:

https://github.com/simon-brooke/fedit

It is experimental, proof of concept code, and has bugs and infelicities. 
It emulates the Portable Standard Lisp/Cambridge Lisp fedit, a terminal 
oriented structure editor, not the InterLisp DEdit display editor, but it 
is preliminary code towards writing a display editor (I've now worked out 
more or less how I would approach that). If it is to be developed further, 
it will need a substantial (but backwards compatible) reworking of the 
Clojure package system, since that is predicated on the concept of 
out-of-core text editing.
Usage

Preliminary, incomplete, alpha quality code. This implements a structure 
editor in a terminal, not a display editor in the tradition of InterLisp's 
DEdit. I do intend to follow up with a display editor, but this is 
exploratory proof-of-concept code.

To edit an arbitrary s-expression:

(sedit sexpr)

This pretty much works now; it returns an edited copy of the s-expression. 
Vectors are not handled intelligently (but could be).

To edit a function definition

(fedit 'name-of-function)

This is still broken (it cannot rebind the function symbol), but shows 
promise.

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

[Phillip Lord]

Meikel Brandmeyer  writes:
> 2013/9/20 Phillip Lord 
>> (def bob3 3)
>>
>> introduces a new symbol, I am struggling to see why
>>
>> (intern 'user 'bob3 3)
>>
>> cannot be recognised similarly.
>>
>
> Because intern happens at runtime. It's a normal function. The above intern
> call is easily translated to the def. intern is only interesting when bob3
> is computed based on runtime information, which is not available at compile
> time. But then the compile cannot special case it anyway.


>From a user perspective, I think that this is very messy. I can see your
example about "do", but then I think using a common form like do is a
mistake; having "do" behave differently depending on whether it is top
level or not is exposing a lot of detail that should not be.

Phil

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

[Jim]

On 20/09/13 08:01, Stephen Cagle wrote:

*
*
*(generative/defspec*
*  check-on-quiz-view*
*  b/quiz-view*
*  [^{:tag `random-loc} loc*
*   ^{:tag (clojure.core/constantly :ignored)} key*
*   ^{:tag `view} value]))*


It seems to me the problem is the above snippet...why are you 
syntax-quoting the :tag? Did you try simple-quoting? Does your code 
compile without this snippet? ignore line 69 for a second - it may be 
misleading.


on a different note, I couldn't help but noticing the following:

you declare this:
(:require
*
 [clojure.test.generative :as generative])

but you seem to be using 'g/uniform' & *'generative/defspec'

also, you do this:

*
*(if (= 0 (g/uniform 0 100)) ...

how about *
*(if (zero? (g/uniform 0 100))

hope that helps,

Jim
*
*

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

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

Re: Safely flush old value out of an atom

[Meikel Brandmeyer (kotarak)]

Hi,

don't bother. That's perfectly ok, and no, there is no library function for 
that. I know quite a number of developers having implemented exactly this 
function (myself included).

Kind regards
Meikel

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

Re: two pass compilation, intern and def

[Meikel Brandmeyer]

Hi,

2013/9/20 Phillip Lord 

>
> (def bob3 3)
>
> introduces a new symbol, I am struggling to see why
>
> (intern 'user 'bob3 3)
>
> cannot be recognised similarly.
>

Because intern happens at runtime. It's a normal function. The above intern
call is easily translated to the def. intern is only interesting when bob3
is computed based on runtime information, which is not available at compile
time. But then the compile cannot special case it anyway.

Meikel

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

Re: two pass compilation, intern and def

[Phillip Lord]

Gary Verhaegen  writes:

> As Meikel said in his previous mail, 'do' at the top-level is treated
> specially: each form is treated as a separate top-level form. This is, for
> example, useful for defining a macro that defines multiple functions.


I'd be interested to see an example, where this behaviour is important.
It is certainly producing a negative effect here. Or perphaps I should
say it is covering up a negative effect; given that the compiler is
capable of understanding that 

(def bob3 3) 

introduces a new symbol, I am struggling to see why 

(intern 'user 'bob3 3)

cannot be recognised similarly.


> So what Meikel was really trying to say is that the reason (do (intern
> 'user 'bob3 3) bob3) works is that it is treated the same as
> (intern 'user 'bob3 3)
> bob3
>
> This special handling only occurs when do appears as a top-level form,
> which is the reason why your other examples fail.


I did manage to work out why they failed (although only be inference),
but the exceptional behaviour of do confused me as it confounds the
explanation. I'm happy that I understand now the situation. Still think
it's a bug.

Phil

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

[Meikel Brandmeyer]

Not that I am aware of. do is special to allow macros expanding into
several defs where the later depend on the former.

(defmacro foo [a b]
  `(do
 (def ~a 5)
 (def ~b ~a)))

This is necessary, because a macro can only return one form.

And the name resolution for ns is special-cased, IIRC.

Meikel



2013/9/20 Colin Fleming 

> This is interesting - are there any other cases where forms are treated
> specially at top-level?
>
>
> On 20 September 2013 10:01, Gary Verhaegen wrote:
>
>> As Meikel said in his previous mail, 'do' at the top-level is treated
>> specially: each form is treated as a separate top-level form. This is, for
>> example, useful for defining a macro that defines multiple functions.
>>
>> So what Meikel was really trying to say is that the reason (do (intern
>> 'user 'bob3 3) bob3) works is that it is treated the same as
>>  (intern 'user 'bob3 3)
>> bob3
>>
>> This special handling only occurs when do appears as a top-level form,
>> which is the reason why your other examples fail.
>>
>> On Thursday, 19 September 2013, Phillip Lord wrote:
>>
>>> "Meikel Brandmeyer (kotarak)"  writes:
>>> > Clojure's compile unit is one toplevel form. Therefore
>>> >
>>> > (intern 'user 'bob3 3)
>>> > bob3
>>> >
>>> > works, while
>>> >
>>> > (is (do (intern 'user 'bob2 2) bob2))
>>> >
>>> > does not, because the former are two compilation units while the
>>> latter is
>>> > only one. (Note: (do ...) is a special case. (do (intern 'user 'bob3 3)
>>> > bob3) should actually work.)
>>>
>>> Yep, do on it's own does work.
>>>
>>> The problem, here, then is that a chunk of code like
>>>
>>> (do (intern 'user 'bob3 3) bob3)
>>>
>>> Sometimes works, and sometimes doesn't. And whether it does or does not
>>> depends on it's context. As I said in the last post, I'd worked out why
>>> the immediate reason it fails. But I cannot understand from looking at
>>> the code why
>>>
>>> (do (intern 'user 'bob3 3) bob3)
>>>
>>> is two compilation units, while
>>>
>>> (is (do (intern 'user 'bob3 3) bob3))
>>>
>>> or
>>>
>>> (try (do (intern 'user 'bob3 3) bob3))
>>>
>>> are both one (the latter fails also).
>>>
>>> Seems rather like a bug to me. If the compiler can identify that
>>>
>>>   (is (do (def bob3) bob3))
>>>
>>> is valid, the same should be true for an intern form.
>>>
>>> Phil
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/JMNLZ5slcqI/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 t

print-dup is not defined? Ok, what do you want me to do about that?

[Stephen Cagle]

*
(ns com.samedhi.app.test.behavior-test
  (:require
   [clojure.test.generative :as generative])

  (:use
   [com.samedhi.quizry.app.test.defspec :only [defspec]]
))

*
*... ommited content ...*
*
*
*(def ^:dynamic *view* nil)*
*
*
*(binding [*view* (atom;; 
this is line 69*
*  {:old-model [nil nil nil nil nil nil]*
*   :quiz [nil nil nil nil nil nil nil]*
*   :loc nil})]*
*  *
*(defn view [] @*view*)*
*  *
*(defn random-loc []*
*  (let [loc (-> (view) :loc random-walk-loc)*
*loc (if (= 0 (g/uniform 0 100)) (f/new-loc) loc)]*
*(swap! *view* assoc :loc loc)*
*loc))*
*
*
*(generative/defspec*
*  check-on-quiz-view*
*  b/quiz-view*
*  [^{:tag `random-loc} loc*
*   ^{:tag (clojure.core/constantly :ignored)} key*
*   ^{:tag `view} value]))*

Gives me the error:
*Exception in thread "main" java.lang.RuntimeException: Can't embed object 
in code, maybe print-dup not defined: Unbound: 
#'com.samedhi.app.test.behavior-test/random-loc, 
compiling:(com/samedhi/app/test/behavior_test.clj:69:1)
*

I vaguely understand that this is saying that something in here does not 
have a print-dup method on it, and as such, cannot be "codified". How do I 
determine what the problem is? 

You might wonder why I am using a binding anyway? defspec is from 
test.generative. This defspec is testing b/quiz-view with the supplied 
argument vector. I have a dependency between the first argument (loc) and 
the third argument (value), hence the shared atom. Furthermore, I wish each 
succesive call to b/quiz-view to be a slight modification of the previous 
value, where the loc has been randomly moved around a bit. Ocasionally (1 
in a 100), I just create a entirely new loc with f/new-loc. All of this 
could have been done with a shared atom. However, it seems that 
test.generative actually uses N-threads, which means I want each thread to 
have its own atom. Hence, by my reasoning, the use of binding and 
^:dynamic. BTW, the tick before random-loc and view allows them to evaluate 
in the the current namespace, as otherwise they would be evaluated in 
clojure.core.generators (I don't really understand why).
 
https://github.com/clojure/test.generative ;; just for reference

I am obviously wrong in my implementation (it does not compile), I could be 
wrong in my reasoning as well, but I am most worried about the fact that I 
have no real idea *what* is not working here. Any help is appreciated.

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