Re: Why isn't there a fold-right?

[Tassilo Horn]

Yoshinori Kohyama  writes:

Hi!

> Sorry for mere my continued report.

No apologies needed.  It's very interesting.

> Instead of reversing operands, I tried accumulating operators and
> reversing and applying it when stopping.
> https://gist.github.com/2896939
> It doesn't consume stack. (but heap...)

Very interesting again.  The theory should be that you iterate the
collection only once to create a big composition of function that
already know one of their args.  However, you have to reverse the list
of functions, which destroys the theoretical benefit.

user> (time (reduce-right - (range 200)))
"Elapsed time: 6375.358049 msecs"
-100

So use a vector and conjoin to the tail instead of consing to a list
that later needs to be reversed.

  https://gist.github.com/2908767

With that, I get this result:

user> (time (reduce-right - (range 200)))
"Elapsed time: 3352.812468 msecs"
-100

But still my reverse-the-collection-and-then-reduce-it approach is still
much faster, although it has to iterate the collection twice.

user> (time (foldr - 0 (range 200)))
"Elapsed time: 831.605479 msecs"
-100

I'm not exactly sure why, but I'd guess the allocation overhead for 2
million partial functions is rather expensive.

Bye,
Tassilo

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

Re: Why isn't there a fold-right?

[Yoshinori Kohyama]

Hi all.

Sorry for mere my continued report.
Instead of reversing operands, I tried accumulating operators and reversing 
and applying it when stopping.
https://gist.github.com/2896939
It doesn't consume stack. (but heap...)

Regards,
Yoshinori Kohyama

-- 
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

Re: Doseq, map-style

[David Jacobs]

I'm not really talking about semantics here, I'm saying that the semantic 
difference between the two methods (map and my hypothetical each) probably 
don't need to be reflected in the language syntax. To me, it feels weird 
that doseq *doesn't actually call the function you pass in for you*. 
Instead, you have to call it yourself on an item from the list that you 
*also locally bound yourself*.

On Sunday, June 10, 2012 12:46:27 AM UTC-7, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi,
>
> Beware the personal opinion!
>
> map applies a function to each element of a sequence and returns a 
> sequence of the results.
>
> If you call the "function" just for side-effects, but not the return 
> value, then the semantics of map don't apply.
>
> Kind regards
> Meikel
>
> -Ursprüngliche Nachricht-
>
> *Von: *David Jacobs *
> An: *clojure@googlegroups.com*
> Gesendet: *Sa, 09 Jun 2012, 23:08:21 MESZ*
> Betreff: *Re: Doseq, map-style
>
> Thanks, guys.
>
> I know there are easy ways to implement what I want. However, I'm more 
> curious as to why the language itself doesn't support this style of mapping 
> side-effects.
>
> In other words, why does doseq not follow map's lead here. Is there a 
> philosophical difference underlying the syntax difference (doseq [elem 
> coll] (f coll)) and (each f coll)?
>
> It seems to me that the side-effecty nature of (doseq) isn't quite enough 
> to justify the syntax difference between map and doseq. I guess one could 
> say that because doseq is built for side-effects, which are often 
> multiline, doseq should easily accept multiline statements. However, my 
> imaginary each macro could do the same: (each #(do … …) coll).
>
> What am I missing?
>
> Thanks!
> David
>
> On Friday, June 8, 2012 at 7:00 AM, Lars Nilsson wrote:
>
> > On Fri, Jun 8, 2012 at 9:54 AM, Allen Johnson wrote:
> > > Combine map with dorun and you get the same effect:
> > > 
> > > (dorun (map println logs))
> > > 
> > > 
> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
> > > 
> > > Allen
> > > 
> > > On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs wrote:
> > > > I would love to have a version of doseq that works like map (similar 
> to
> > > > "each" in other dynamic languages). In other words, instead of 
> (doseq [log
> > > > logs] (println log)), I would say something like (each println logs).
> > > > 
> > > > Is there a built-in Clojure method that works like this?
> > 
> > Not a built-in, but...
> > 
> > (defmacro for-each [f x] `(doseq [item# ~x] (~f item#)))
> > 
> > I suppose this solution is blindingly obvious though.
> > 
> > Also, I would be curious if there's any significant performance
> > difference using (dorun (map ...)) as I assume an intermediate result
> > is built and then thrown away. Or perhaps it's insignificant compared
> > to what the unspecified function does that is passed to map for
> > performing the side-effect work..
> > 
> > Lars Nilsson
> > 
> > -- 
> > 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 (mailto:
> 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 (mailto:
> 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 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
>
>
On Sunday, June 10, 2012 12:46:27 AM UTC-7, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi,
>
> Beware the personal opinion!
>
> map applies a function to each element of a sequence and returns a 
> sequence of the results.
>
> If you call the "function" just for side-effects, but not the return 
> value, then the semantics of map don't apply.
>
> Kind regards
> Meikel
>
> -Ursprüngliche Nachricht-
>
> *Von: *David Jacobs *
> An: *clojure@googlegroups.com*
> Gesendet: *Sa, 09 Jun 2012, 23:08:21 MESZ*
> Betreff: *Re: Doseq, map-style
>
> Thanks, guys.
>
> I know there are easy ways to implement what I want. However, I'm more 
> curious as to why the language itself doesn't support this style of mapping 
> side-effects.
>
> In other words, why does doseq not follow map's lead here. Is there a 
> philosophical difference underlying the syntax difference (doseq [elem 
> coll] (f coll)) and (each f coll)?
>
> It seems to me that the side-effecty nature of (doseq) isn't quite enough 
> to justify the syntax difference between map and doseq. I gu

Re: Doseq, map-style

[David Jacobs]

This is good stuff. I've certainly felt the same way about FP at some 
points--for me, Clojure really illuminates why people thought OO was such a 
good thing 15 years ago. Let me know if you write that blog post.

On Saturday, June 9, 2012 7:47:47 PM UTC-7, Kurt Harriger wrote:
>
>  
> You could also (dorun (map f coll)) 
>
> It is actually interesting you brought this up as I was recently 
> contrasting the OO principle "tell don't ask" with the functional way of 
> doing things.  In OO a void method taking a visitor is preferred over 
> return values.  One could perhaps say that (dorun (map f (generator))) is 
> pretty much the same thing as (each (generator) f) except that generator is 
> now a pure side effect free function where as visitors generally speaking 
> have side effects, although this isn't required for example (each coll 
> identity) is just as easy to use and test. 
>
> The more I thought about it the more I began to realize that the OO 
> visitor approach may still have some advantages over the functional 
> approach.  In a typed language the generator can overload based on the 
> visitor's type signature, this makes refactoring and evolving code easier 
> while still preserving backward compatibility as different versions of a 
> visitor might have different method parameter types.  Of course you could 
> do this in clojure explicitly but is less elegant ie (map f (generator 
> :non-default-type)) and is generally considered confusing to have functions 
> return different return types depending on their parameters. It is probably 
> better to just choose a different function name instead.
>
> One other difference that is not as easy to emulate functionally is when 
> the generator spawns multiple threads and delegates the work where each 
> worker may call the visitor back on different threads.  In clojure you can 
> easily (pmap f (generator)), however this requires generator to create a 
> sequence of return values from a specific thread regardless of how many 
> threads are used to generate the sequence or process the sequence, 
> ultimately the generator must first bring all these results together on a 
> single thread creating a synchronization bottleneck that does not 
> necessarily need to exist when using side effects instead of return values. 
>  For example, the side effect might be to write its results to a database 
> and the generator might partition the work to each visitor never expecting 
> a reply from any of them, the visitor might even forward the request to a 
> different machine on the network since no return value is expected or 
> required.  
>
> Many will say that side-effecting functions are more difficult to test 
> then pure functions... However after writing about 4000 lines of clojure 
> code, I realized that things in practice are never quite as simple as they 
> seem.  As functions are composed the data structures they work with grow 
> larger and more complex and this leads to maps containing maps containing 
> lists containing maps and a minor change downstream can ripple through the 
> program.  Tests become significantly more complex and fragile as the input 
> and output structures grow in complexity.
>
> This reminded me of another OO code smell "Don't talk to strangers" 
> and the Law of Demeter, instead sending and returning maps of lists of maps 
> I started returning maps of functions.  This provided additional decoupling 
> that enabled me to refactor a bit more easily additionally maps of maps of 
> lists of maps often need to be fully computed where as a map containing 
> functions allows me to defer computation until it is actually required 
> which may in many cases be never. Although very idiomatic to use keywords 
> to get from maps, I have started to think of this as a code smell and 
> instead prefer to (def value :value) and use this var instead of the 
> keyword because it allows me to later replace the implementation or rename 
> properties if it is necessary to refactor and I want to minimize changes to 
> existing code or make changes to the existing code in small incremental 
> units rather than all at once.  
>
> It is also very hard to write a useful program that does not contain 
> side-effects or reads data from an impure datasource and I used midje to 
> mock functions that such as (get-current-time), many times my function did 
> not use that function directly but was used by another function that my 
> function called.  I began to see this as a code smell in OO I would mock 
> the object that uses get-current-time not get-current-time itself which 
> then gave me the idea to start passing the functions used by the function 
> under test to the function as additional parameters, for testing I could 
> pass in an alternative function such as (constantly true) or (identity). 
>  However, some functions required many functions so I began to group these 
> into maps and began to realize that I was reinventing OO programming..

Re: clj-pdf for declarative PDF generation (status update)

[Baishampayan Ghose]

On Sun, Jun 10, 2012 at 10:16 PM, Dmitri  wrote:
> The reason I'm using strings for values is to make it easier to work with
> deserialized JSON. Currently I have it running as a service that our
> internal applications send a JSON request and get a PDF document back.

Internally you can call `name` on the arguments, that way the user can
pass in either a string or a keyword.

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.com

-- 
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

Re: Function minimizer a la fminunc

[David Jacobs]

I took it last year. I've started to build out a library, first slowly but 
now with a little more focus: github.com/davejacobs/ml. So far it's a lot 
of fun! I could definitely be interested in collaborating. (fminunc doesn't 
look like it would be impossible to port.)

On Sunday, June 10, 2012 4:05:25 PM UTC-7, Jason Lewis wrote:
>
> David - 
>
> You aren't taking the Stanford/Coursera ML class by any chance, are you? 
>
> I was just starting to look into porting some of that stuff over from 
> Octave to Clojure.
>
>
> Jason Lewis
>
>
>
>
> On Sun, Jun 10, 2012 at 8:24 AM, Lachlan wrote:
>
>> maybe http://commons.apache.org/math/apidocs/index.html will help?
>>
>> - lk
>>  On Jun 10, 2012 7:09 AM, "David Jacobs"  wrote:
>>
>>> Thanks! That section of Incanter must be new, I haven't seen it till 
>>> now. Will check it out and report back.
>>>
>>>
>>> On Friday, June 8, 2012 at 7:15 AM, Lars Nilsson wrote:
>>>
>>> > On Fri, Jun 8, 2012 at 12:30 AM, David Jacobs >> da...@wit.io)> wrote:
>>> > > Has anyone written a function minimizer in Clojure (or in Java)? I 
>>> want
>>> > > something like Octave's fminunc [0], where I can pass in a function 
>>> and a
>>> > > parameter list and find the parameters that minimize the function. 
>>> Anyone
>>> > > know of one?
>>> > >
>>> > > [0] http://octave.sourceforge.net/octave/function/fminunc.html
>>> >
>>> > Perhaps Incanter has something suitable?
>>> >
>>> > 
>>> http://liebke.github.com/incanter/optimize-api.html#incanter.optimize/non-linear-model
>>> >
>>> > Couldn't say for sure if this is exactly what you're looking for but
>>> > if nothing else, you get a lot of building blocks to build upon.
>>> >
>>> > Lars Nilsson
>>> >
>>> > --
>>> > 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 (mailto:
>>> 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 (mailto:
>>> 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 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 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 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

Re: Uniform exceptions – Clojure and ClojureScript?

[Dave Sann]

Has anyone made headway on this?

Does anyone have good practice that they can share?

Cheers

Dave



On Wednesday, 28 December 2011 08:52:00 UTC+11, Dave Sann wrote:
>
> I believe the capability to have a portable solution in specific cases is 
> in the pipeline
>
> https://github.com/clojure/clojurescript/wiki/Exception-Handling
>
>
>

-- 
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

Re: Why isn't there a fold-right?

[Yoshinori Kohyama]

Hi O. Masanori and all,

Thank you so much for your kindly explanation.

Sure that 'fold-right' itself is strict as you say.

But I think that various right-folded-type loops, which can be stopped 
middle of a list, can be lazy.
The continuation, which should be calculated in the later steps, should be 
determined when the list is searched to that point from head of it.

https://gist.github.com/2894687
https://gist.github.com/2896939

Does anyone have an idea not to eat large stack with an abstraction for 
these loops?

-- 
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

Re: Why isn't there a fold-right?

[OGINO Masanori]

Hello.

2012/6/11 Yoshinori Kohyama :
> If clojure's implementation of reverse don't consume stack, how does it do?

`reduce1` is a recursive function using `recur`, explicit tail
recursion with optimization.  So it doesn't.

> The source of 'reverse' says it uses 'reduce1' and commented "Not lazy".

Yes.  `reverse` must be strict, because all elements must be realized
(the value is computed) when you reverse a sequence.

> The source of 'reduce1' says it uses 'chunk-seq?', '.reduce', 'chunk-first'
> and 'chunk-next'.
> What are these?

See clojure.lang.{IChunk,IChunkedSeq}.

> And is there any lazy solution?

Probably no.  Both `fold-right` and `reverse` must be strict IMHO.

-- 
OGINO Masanori 
http://twitter.com/omasanori

-- 
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

Re: Why isn't there a fold-right?

[Yoshinori Kohyama]

Hello Tassilo and All,

Thank you for your comment.
Yes, it is sorry that my 'fold-right' eat large stack.
Using 'reverse' is good.

But I think 'reverse' is a special case of 'fold-right'.
(fold-right #(concat %2 (list %)) '() '(:a :b :c :d))
; -> (:d :c :b :a)
If clojure's implementation of reverse don't consume stack, how does it do?

https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/clj/clojure/core.clj#L883
The source of 'reverse' says it uses 'reduce1' and commented "Not lazy".

https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/clj/clojure/core.clj#L865
The source of 'reduce1' says it uses 'chunk-seq?', '.reduce', 'chunk-first' 
and 'chunk-next'.
What are these?

And is there any lazy solution?


Regards,
Yoshinori Kohyama

-- 
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

core.logic for encoding the rules of chess or checkers? is it plausible/desirable ?

[Jim - FooBar();]

Hello everyone,

I'm trying to decide if its worth writing the rules of chess/checkers 
using core.logic or go down the conventional road but unfortunately I'm 
inexperienced as far as core.logic goes. I mean I've played around for a 
bit but nothing serious.


What I want is NOT AI or anything like that...all I want is to encode 
the rules of the game somehow so i can then pass a board and a piece to 
some function that will be able to find all available moves that don't 
violate the rules of the game - no picking the best move or anything 
like that...just finding the legal moves efficiently...does this sound 
reasonable? I'm surprised there are so little on-line resources on the 
matter!


if someone can explain the advantages and the disadvantages of of doing 
so that would be fanatstic...Even better if someone can point me in the 
right direction (some similar project perhaps). I really have no idea 
how to start and its one of the few times g8ggle doesn't seem to help...


thanks in advance...


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

[ANN] clojure.java.jdbc 0.2.2

[Sean Corfield]

On its way to Maven Central!

Change Log

* Release 0.2.2 on 2012-06-10
  - Handle Oracle unknown row count affected JDBC-33
  - Handle jdbc: prefix in string db-specs JDBC-32
  - Handle empty columns in make column unique (Juergen Hoetzel) JDBC-31

For more details: https://github.com/clojure/java.jdbc
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Function minimizer a la fminunc

[Jason Lewis]

David -

You aren't taking the Stanford/Coursera ML class by any chance, are you?

I was just starting to look into porting some of that stuff over from
Octave to Clojure.


Jason Lewis




On Sun, Jun 10, 2012 at 8:24 AM, Lachlan  wrote:

> maybe http://commons.apache.org/math/apidocs/index.html will help?
>
> - lk
>  On Jun 10, 2012 7:09 AM, "David Jacobs"  wrote:
>
>> Thanks! That section of Incanter must be new, I haven't seen it till now.
>> Will check it out and report back.
>>
>>
>> On Friday, June 8, 2012 at 7:15 AM, Lars Nilsson wrote:
>>
>> > On Fri, Jun 8, 2012 at 12:30 AM, David Jacobs > da...@wit.io)> wrote:
>> > > Has anyone written a function minimizer in Clojure (or in Java)? I
>> want
>> > > something like Octave's fminunc [0], where I can pass in a function
>> and a
>> > > parameter list and find the parameters that minimize the function.
>> Anyone
>> > > know of one?
>> > >
>> > > [0] http://octave.sourceforge.net/octave/function/fminunc.html
>> >
>> > Perhaps Incanter has something suitable?
>> >
>> >
>> http://liebke.github.com/incanter/optimize-api.html#incanter.optimize/non-linear-model
>> >
>> > Couldn't say for sure if this is exactly what you're looking for but
>> > if nothing else, you get a lot of building blocks to build upon.
>> >
>> > Lars Nilsson
>> >
>> > --
>> > 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 (mailto:
>> 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 (mailto:
>> 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 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 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 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

Re: fully type-hinted record still uses reflection!

[David Nolen]

You can cast to primitive int with (int ...)

On Sun, Jun 10, 2012 at 1:53 PM, Jim - FooBar(); wrote:

> On 10/06/12 18:43, Ben Smith-Mannschott wrote:
>
>> "can accept ints or doubles"
>>
>> How is the Clojure compiler to know wether to compile a call to
>> Point.setLocation(double,**double) or Point.setLocation(int,int)?
>>
>> I think you need to tell the compiler the types of (first np) and
>> (second np), which means -- of course -- that you'll need to know
>> what they are statically.
>>
>> I'm a little rusty on my type hinting, but have you tried something
>> like:
>>
>> (.position setLocation ^double (first np) ^double (second np))
>> or
>> (.position setLocation ^int (first np) ^int (second np))
>>
>> // ben
>>
>
> Yep, it works...only 2 warnings now! btw, you can't have int primitive
> type-hinting - only double or long.
>
>
> 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+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 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

Re: fully type-hinted record still uses reflection!

[Jim - FooBar();]

On 10/06/12 18:43, Ben Smith-Mannschott wrote:

"can accept ints or doubles"

How is the Clojure compiler to know wether to compile a call to
Point.setLocation(double,double) or Point.setLocation(int,int)?

I think you need to tell the compiler the types of (first np) and
(second np), which means -- of course -- that you'll need to know
what they are statically.

I'm a little rusty on my type hinting, but have you tried something
like:

(.position setLocation ^double (first np) ^double (second np))
or
(.position setLocation ^int (first np) ^int (second np))

// ben


Yep, it works...only 2 warnings now! btw, you can't have int primitive 
type-hinting - only double or long.


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

Re: fully type-hinted record still uses reflection!

[Jim - FooBar();]

a.A moment of enlightment thank you so so much...

so what you're saying is that there is no confusion as to what object 
(record) to call  setLocation on. The confusion arises when trying to 
decide which one of the 2 methods to invoke (there are indeed 2 and I 
knew it from the start - that is why I've put the little comment there)


thanks a lot Ben...I do know i n advance which one of the 2 to call (the 
one accepting doubles) so I'll type-hint accordingly :-)


Jim


On 10/06/12 18:43, Ben Smith-Mannschott wrote:

On Sun, Jun 10, 2012 at 7:04 PM, Jim - FooBar();  wrote:

Hi again (busy day eh?),

well this doesn't make any sense either! Why is a record with  type-hinted
arguments still using reflection?
I've got the following example record:
--
(defrecord CheckersPiece [^java.awt.Color color
   ^java.awt.Point position
  rank]
  Piece
  (update-position [this np] ;mutable state inside Point!
   (. position setLocation  ;can accept ints or doubles
 (first np) (second np))) ;np should be [x, y]

"can accept ints or doubles"

How is the Clojure compiler to know wether to compile a call to
Point.setLocation(double,double) or Point.setLocation(int,int)?

I think you need to tell the compiler the types of (first np) and
(second np), which means -- of course -- that you'll need to know
what they are statically.

I'm a little rusty on my type hinting, but have you tried something
like:

(.position setLocation ^double (first np) ^double (second np))
or
(.position setLocation ^int (first np) ^int (second np))

// ben


  (die [this] (vary-meta this assoc :dead true)) ;communicate death
through meta-data
  (promote [this] (make-checker color position :rank 'prince)) ; a checker is
promoted to prince
  (getGridPosition [this] (vector (.getX position) (.getY position)))
  (getListPosition [this] (translate-position  (first  (.getGridPosition
this))
  (second (.getGridPosition
this)) board-mappings-checkers))
  (getPoint [this] position)
  (getMoves [this] nil) ;TODO
  Object
  (toString [this]
   (println "Checker (" rank ") at position:" (.getListPosition this) " ->"
(.getGridPosition this))) )
---
and whenever i call update-position it complains that setLocation cannot be
resolved. setLocation is a method in java.awt.Point so i don't see why this
happens!

any suggestions?

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 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

Re: fully type-hinted record still uses reflection!

[Ben Smith-Mannschott]

On Sun, Jun 10, 2012 at 7:04 PM, Jim - FooBar();  wrote:
> Hi again (busy day eh?),
>
> well this doesn't make any sense either! Why is a record with  type-hinted
> arguments still using reflection?
> I've got the following example record:
> --
> (defrecord CheckersPiece [^java.awt.Color color
>                                           ^java.awt.Point position
>                                              rank]
>  Piece
>  (update-position [this np] ;mutable state inside Point!
>   (. position setLocation  ;can accept ints or doubles
>     (first np) (second np))) ;np should be [x, y]

"can accept ints or doubles"

How is the Clojure compiler to know wether to compile a call to
Point.setLocation(double,double) or Point.setLocation(int,int)?

I think you need to tell the compiler the types of (first np) and
(second np), which means -- of course -- that you'll need to know
what they are statically.

I'm a little rusty on my type hinting, but have you tried something
like:

(.position setLocation ^double (first np) ^double (second np))
or
(.position setLocation ^int (first np) ^int (second np))

// ben

>  (die     [this] (vary-meta this assoc :dead true)) ;communicate death
> through meta-data
>  (promote [this] (make-checker color position :rank 'prince)) ; a checker is
> promoted to prince
>  (getGridPosition [this] (vector (.getX position) (.getY position)))
>  (getListPosition [this] (translate-position  (first  (.getGridPosition
> this))
>                                              (second (.getGridPosition
> this)) board-mappings-checkers))
>  (getPoint [this] position)
>  (getMoves [this] nil) ;TODO
>  Object
>  (toString [this]
>   (println "Checker (" rank ") at position:" (.getListPosition this) " ->"
> (.getGridPosition this))) )
> ---
> and whenever i call update-position it complains that setLocation cannot be
> resolved. setLocation is a method in java.awt.Point so i don't see why this
> happens!
>
> any suggestions?
>
> 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 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

Re: fully type-hinted record still uses reflection!

[Jim - FooBar();]

Thanks Lars but there is no difference...when i try to load my namespace 
I get this output:


Clondie24.core=> (load-file "src/Clondie24/core.clj")
#'Clondie24.core/-mainReflection warning, 
/home/sorted/clooJWorkspace/Clondie24/src/Clondie24/core.clj:104 - call 
to setLocation can't be resolved.
Reflection warning, 
/home/sorted/clooJWorkspace/Clondie24/src/Clondie24/core.clj:122 - call 
to setLocation can't be resolved.
Reflection warning, 
/home/sorted/clooJWorkspace/Clondie24/src/Clondie24/core.clj:206 - 
reference to field getListPosition can't be resolved.
Reflection warning, 
/home/sorted/clooJWorkspace/Clondie24/src/Clondie24/core.clj:251 - call 
to update_position can't be resolved.


Of the 4 warnings only the last 2 can be justified (it is not 
predetermined what type comes in)...the first 2 refer to 2 different 
records that do the same thing as far as updating the position goes and 
setLocation is the culprit again!


Jim

On 10/06/12 18:09, Lars Nilsson wrote:

On Sun, Jun 10, 2012 at 1:08 PM, Lars Nilsson  wrote:

On Sun, Jun 10, 2012 at 1:04 PM, Jim - FooBar();  wrote:

Hi again (busy day eh?),

well this doesn't make any sense either! Why is a record with  type-hinted
arguments still using reflection?
I've got the following example record:
--
(defrecord CheckersPiece [^java.awt.Color color
   ^java.awt.Point position
  rank]
  Piece
  (update-position [this np] ;mutable state inside Point!
   (. position setLocation  ;can accept ints or doubles
 (first np) (second np))) ;np should be [x, y]
  (die [this] (vary-meta this assoc :dead true)) ;communicate death
through meta-data
  (promote [this] (make-checker color position :rank 'prince)) ; a checker is
promoted to prince
  (getGridPosition [this] (vector (.getX position) (.getY position)))
  (getListPosition [this] (translate-position  (first  (.getGridPosition
this))
  (second (.getGridPosition
this)) board-mappings-checkers))
  (getPoint [this] position)
  (getMoves [this] nil) ;TODO
  Object
  (toString [this]
   (println "Checker (" rank ") at position:" (.getListPosition this) " ->"
(.getGridPosition this))) )
---
and whenever i call update-position it complains that setLocation cannot be
resolved. setLocation is a method in java.awt.Point so i don't see why this
happens!

Would (.setLocation position) possibly behave differently maybe? Worth a try?

Ehh... With the two arguments I forgot to include in the call obviously..

Lars Nilsson



--
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

Re: fully type-hinted record still uses reflection!

[Lars Nilsson]

On Sun, Jun 10, 2012 at 1:08 PM, Lars Nilsson  wrote:
> On Sun, Jun 10, 2012 at 1:04 PM, Jim - FooBar();  wrote:
>> Hi again (busy day eh?),
>>
>> well this doesn't make any sense either! Why is a record with  type-hinted
>> arguments still using reflection?
>> I've got the following example record:
>> --
>> (defrecord CheckersPiece [^java.awt.Color color
>>                                           ^java.awt.Point position
>>                                              rank]
>>  Piece
>>  (update-position [this np] ;mutable state inside Point!
>>   (. position setLocation  ;can accept ints or doubles
>>     (first np) (second np))) ;np should be [x, y]
>>  (die     [this] (vary-meta this assoc :dead true)) ;communicate death
>> through meta-data
>>  (promote [this] (make-checker color position :rank 'prince)) ; a checker is
>> promoted to prince
>>  (getGridPosition [this] (vector (.getX position) (.getY position)))
>>  (getListPosition [this] (translate-position  (first  (.getGridPosition
>> this))
>>                                              (second (.getGridPosition
>> this)) board-mappings-checkers))
>>  (getPoint [this] position)
>>  (getMoves [this] nil) ;TODO
>>  Object
>>  (toString [this]
>>   (println "Checker (" rank ") at position:" (.getListPosition this) " ->"
>> (.getGridPosition this))) )
>> ---
>> and whenever i call update-position it complains that setLocation cannot be
>> resolved. setLocation is a method in java.awt.Point so i don't see why this
>> happens!
>
> Would (.setLocation position) possibly behave differently maybe? Worth a try?

Ehh... With the two arguments I forgot to include in the call obviously..

Lars Nilsson

-- 
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

Re: fully type-hinted record still uses reflection!

[Lars Nilsson]

On Sun, Jun 10, 2012 at 1:04 PM, Jim - FooBar();  wrote:
> Hi again (busy day eh?),
>
> well this doesn't make any sense either! Why is a record with  type-hinted
> arguments still using reflection?
> I've got the following example record:
> --
> (defrecord CheckersPiece [^java.awt.Color color
>                                           ^java.awt.Point position
>                                              rank]
>  Piece
>  (update-position [this np] ;mutable state inside Point!
>   (. position setLocation  ;can accept ints or doubles
>     (first np) (second np))) ;np should be [x, y]
>  (die     [this] (vary-meta this assoc :dead true)) ;communicate death
> through meta-data
>  (promote [this] (make-checker color position :rank 'prince)) ; a checker is
> promoted to prince
>  (getGridPosition [this] (vector (.getX position) (.getY position)))
>  (getListPosition [this] (translate-position  (first  (.getGridPosition
> this))
>                                              (second (.getGridPosition
> this)) board-mappings-checkers))
>  (getPoint [this] position)
>  (getMoves [this] nil) ;TODO
>  Object
>  (toString [this]
>   (println "Checker (" rank ") at position:" (.getListPosition this) " ->"
> (.getGridPosition this))) )
> ---
> and whenever i call update-position it complains that setLocation cannot be
> resolved. setLocation is a method in java.awt.Point so i don't see why this
> happens!

Would (.setLocation position) possibly behave differently maybe? Worth a try?

Lars Nilsson

-- 
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

fully type-hinted record still uses reflection!

[Jim - FooBar();]

Hi again (busy day eh?),

well this doesn't make any sense either! Why is a record with  
type-hinted arguments still using reflection?

I've got the following example record:
--
(defrecord CheckersPiece [^java.awt.Color color
   ^java.awt.Point position
  rank]
 Piece
 (update-position [this np] ;mutable state inside Point!
   (. position setLocation  ;can accept ints or doubles
 (first np) (second np))) ;np should be [x, y]
 (die [this] (vary-meta this assoc :dead true)) ;communicate death 
through meta-data
 (promote [this] (make-checker color position :rank 'prince)) ; a 
checker is promoted to prince

 (getGridPosition [this] (vector (.getX position) (.getY position)))
 (getListPosition [this] (translate-position  (first  (.getGridPosition 
this))
  (second (.getGridPosition 
this)) board-mappings-checkers))

 (getPoint [this] position)
 (getMoves [this] nil) ;TODO
 Object
 (toString [this]
   (println "Checker (" rank ") at position:" (.getListPosition this) " 
->" (.getGridPosition this))) )

---
and whenever i call update-position it complains that setLocation cannot 
be resolved. setLocation is a method in java.awt.Point so i don't see 
why this happens!


any suggestions?

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

Re: Explaining the thrush -> operator.

[Fenton Travers]

All fantastic comments...I was thinking why didn't i use - instead of plus!
 I'll fix these up soon.

On Sun, Jun 10, 2012 at 6:05 AM, Ulises  wrote:

> Additional to all the positive comments, I'd suggest you use an
> operator which is not commutative, otherwise the differences between
> -> and ->> are less evident.
>
> U
>
> --
> 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
>



-- 
Mob. +1 778 707 0664 (Vancouver)
Home. +1 604 736 3000 (Vancouver)
Skype In. +852 8197 4719 (Hong Kong)
Mob. +852 6188 7470 (Hong Kong)
Work Tel. +852 3655 7748 (Hong Kong)
Google Tel. +1 347 433 6866 (North America)

-- 
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

Re: clj-pdf for declarative PDF generation (status update)

[Dmitri]

The reason I'm using strings for values is to make it easier to work with 
deserialized JSON. Currently I have it running as a service that our 
internal applications send a JSON request and get a PDF document back. 

On Sunday, June 10, 2012 12:25:39 PM UTC-4, Moritz Ulrich wrote:
>
> Looks cool! Unfortunately I currently don't have the time to have a 
> deep look at it. However, I have a small comment on the api: Many 
> parameters like 'style', 'size', 'orientation', etc. use strings for 
> their values. I think keywords would be a better fit there. 
>
> On Sun, Jun 10, 2012 at 5:59 PM, Dmitri  
> wrote: 
> > The goal of clj-pdf is to provide a straight forward way to generate 
> PDFs 
> > using markup similar to hiccup. It tries to do the right thing by 
> default, 
> > so all styling hints are optional. It's getting some production use at 
> the 
> > moment, and there don't appear to be any issues so far. 
> > 
> > https://github.com/yogthos/clj-pdf 
> > 
> > Any suggestions or feature requests are welcome. :) 
> > 
> > 
> > -- 
> > 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 
>
>
>
> -- 
> Moritz Ulrich 
>

-- 
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

Re: clj-pdf for declarative PDF generation (status update)

[Moritz Ulrich]

Looks cool! Unfortunately I currently don't have the time to have a
deep look at it. However, I have a small comment on the api: Many
parameters like 'style', 'size', 'orientation', etc. use strings for
their values. I think keywords would be a better fit there.

On Sun, Jun 10, 2012 at 5:59 PM, Dmitri  wrote:
> The goal of clj-pdf is to provide a straight forward way to generate PDFs
> using markup similar to hiccup. It tries to do the right thing by default,
> so all styling hints are optional. It's getting some production use at the
> moment, and there don't appear to be any issues so far.
>
> https://github.com/yogthos/clj-pdf
>
> Any suggestions or feature requests are welcome. :)
>
>
> --
> 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



-- 
Moritz Ulrich

-- 
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

clj-pdf for declarative PDF generation (status update)

[Dmitri]

The goal of clj-pdf is to provide a straight forward way to generate PDFs 
using markup similar to hiccup. It tries to do the right thing by default, 
so all styling hints are optional. It's getting some production use at the 
moment, and there don't appear to be any issues so far. 

https://github.com/yogthos/clj-pdf

Any suggestions or feature requests are welcome. :)


-- 
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

ANN: lein-guzheng 0.3.0, now with lein2 support

[David Greenberg]

After much toiling, I've made lein-guzheng compatible with lein2 as well as
lein1. The syntax is the same: "lein2 guzheng foo.core foo.util -- test" or
any other namespace you'd like to trampoline to.

Use [lein-guzheng "0.3.0"] to get it. It will work with lein1 and lein2.

https://github.com/dgrnbrg/lein-guzheng/

-- 
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

Re: clashing methods between 2 different protocols???

[Jim - FooBar();]

Ok sorted...
in case someone else is confused by this, this is how you can override 
the toString method on records:


(defrecord CheckersMove [^CheckersPiece p
  ^clojure.lang.PersistentVector start-pos
  ^clojure.lang.PersistentVector end-pos]
  MoveCommand
 (execute [this] (move-checker p end-pos))
 (undo[this] (move-checker p start-pos))
 (getMovingPiece [this] p)
 (getStartPos [this] start-pos)
 (getEndPos   [this] end-pos)
 Object   ;<<--i was missing this before!
 (toString [this]
   (println "Chess-move originating from" (.getStartPos this) "to" 
(.getEndPos this


Jim



On 10/06/12 14:58, Jim - FooBar(); wrote:

Hello everyone,

I am completely and utterly confused about this error that I just got:

Warning: protocol #'Clondie24.core/MoveCommand is overwriting method 
toString of protocol Piece



 (defprotocol MoveCommand
 "The Command design pattern in action."
 (execute [this])
 (undo[this])
 (getMovingPiece [this])
 (getStartPos [this])
 (getEndPos   [this])
 (toString [this]))


(defprotocol Piece "The Piece abstraction."
 (update-position [this new-position])
 (getGridPosition [this])
 (getListPosition [this])
 (getPoint [this])
 (die [this])
 (promote [this])
 (getMoves [this])
 (toString [this]))

My question is why can't I have a 'toString' method on both protocols? 
This is perfectly valid in Java - in fact it's considered good 
practice to do that ('clone' and 'equals' too)...Can somebody please 
elaborate?


an example implementation that I want is this : (unfortunately unless 
i change the name to 'asString' or something it complains!)


 (defrecord CheckersMove [^CheckersPiece p ;;implements Piece protocol

^clojure.lang.PersistentVector start-pos

^clojure.lang.PersistentVector end-pos]

  MoveCommand
 (execute [this] (move-checker p end-pos))
 (undo[this] (move-checker p start-pos))
 (getMovingPiece [this] p)
 (getStartPos [this] start-pos)
 (getEndPos   [this] end-pos)
 (toString [this]
   (println "Chess-move originating from" (.getStartPos this) "to" 
(.getEndPos this



Any ideas guys?

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

clashing methods between 2 different protocols???

[Jim - FooBar();]

Hello everyone,

I am completely and utterly confused about this error that I just got:

Warning: protocol #'Clondie24.core/MoveCommand is overwriting method 
toString of protocol Piece



 (defprotocol MoveCommand
 "The Command design pattern in action."
 (execute [this])
 (undo[this])
 (getMovingPiece [this])
 (getStartPos [this])
 (getEndPos   [this])
 (toString [this]))


(defprotocol Piece "The Piece abstraction."
 (update-position [this new-position])
 (getGridPosition [this])
 (getListPosition [this])
 (getPoint [this])
 (die [this])
 (promote [this])
 (getMoves [this])
 (toString [this]))

My question is why can't I have a 'toString' method on both protocols? 
This is perfectly valid in Java - in fact it's considered good practice 
to do that ('clone' and 'equals' too)...Can somebody please elaborate?


an example implementation that I want is this : (unfortunately unless i 
change the name to 'asString' or something it complains!)


 (defrecord CheckersMove [^CheckersPiece p ;;implements Piece protocol

^clojure.lang.PersistentVector start-pos

^clojure.lang.PersistentVector end-pos]

  MoveCommand
 (execute [this] (move-checker p end-pos))
 (undo[this] (move-checker p start-pos))
 (getMovingPiece [this] p)
 (getStartPos [this] start-pos)
 (getEndPos   [this] end-pos)
 (toString [this]
   (println "Chess-move originating from" (.getStartPos this) "to" 
(.getEndPos this



Any ideas guys?

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

Re: Explaining the thrush -> operator.

[Ulises]

Additional to all the positive comments, I'd suggest you use an
operator which is not commutative, otherwise the differences between
-> and ->> are less evident.

U

-- 
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

Re: Explaining the thrush -> operator.

[Tim Visher]

On Fri, Jun 8, 2012 at 2:02 PM, fenton  wrote:
> I created a tutorial explaining what the thrush -> and ->> operator is.
>
> https://github.com/ftravers/PublicDocumentation/blob/master/clojure-thrush.md
>
> My tutorials are aimed at people who appreciate VERY explicit explanations,
> which I think there is a bit of a gap among current internet available
> literature.

This is a very nice practical explanation of what those macros do.

For compatibility, I would recommend calling `->` 'thread-first macro'
and `->>` 'thread-last macro' throughout your article, as that's what
the rest of the community refers to them as, at least in my
experience. That'll help people find your article if they google for
idiomatic clojure terms.

-- 
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

Re: Function minimizer a la fminunc

[Lachlan]

maybe http://commons.apache.org/math/apidocs/index.html will help?

- lk
 On Jun 10, 2012 7:09 AM, "David Jacobs"  wrote:

> Thanks! That section of Incanter must be new, I haven't seen it till now.
> Will check it out and report back.
>
>
> On Friday, June 8, 2012 at 7:15 AM, Lars Nilsson wrote:
>
> > On Fri, Jun 8, 2012 at 12:30 AM, David Jacobs  da...@wit.io)> wrote:
> > > Has anyone written a function minimizer in Clojure (or in Java)? I want
> > > something like Octave's fminunc [0], where I can pass in a function
> and a
> > > parameter list and find the parameters that minimize the function.
> Anyone
> > > know of one?
> > >
> > > [0] http://octave.sourceforge.net/octave/function/fminunc.html
> >
> > Perhaps Incanter has something suitable?
> >
> >
> http://liebke.github.com/incanter/optimize-api.html#incanter.optimize/non-linear-model
> >
> > Couldn't say for sure if this is exactly what you're looking for but
> > if nothing else, you get a lot of building blocks to build upon.
> >
> > Lars Nilsson
> >
> > --
> > 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 (mailto:
> 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 (mailto:
> 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 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 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

[PATCH] Enhance clojure.data/diff to cope with falsey values in maps

[Philip Aston]

Current behaviour of clojure.data/diff:

=> (diff {:a false} {:a true})
(nil {:a true} nil)
=> (diff {:a false} {:a nil})
(nil nil nil)

With patch:

=> (diff {:a false} {:a true})
({:a false} {:a true} nil)
=> (diff {:a false} {:a nil})
({:a false} {:a nil} nil)


This seems more consistent and useful to me, but I may be missing something.

Should I open a JIRA?

- Phil


---

>From e03a8060214d122ea2ebadf9e8a368f7f593d9f4 Mon Sep 17 00:00:00 2001
From: Philip Aston 
Date: Sun, 10 Jun 2012 13:11:36 +0100
Subject: [PATCH] clojure.data/diff: cope with falsey values in maps

---
 src/clj/clojure/data.clj   |   18 +-
 test/clojure/test_clojure/data.clj |3 ++-
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/clj/clojure/data.clj b/src/clj/clojure/data.clj
index 6e8dbcf..345b234 100644
--- a/src/clj/clojure/data.clj
+++ b/src/clj/clojure/data.clj
@@ -30,6 +30,22 @@
  (vec (repeat (apply max (keys m))  nil))
  m)))
 
+(defn- diff-associative-key
+  "Diff associative things a and b, comparing only the key k."
+  [a b k]
+  (let [va (get a k)
+vb (get b k)
+[a* b* ab] (diff va vb)
+in-a (contains? a k)
+in-b (contains? b k)
+same (and in-a in-b
+  (or (not (nil? ab))
+  (and (nil? va) (nil? vb]
+[(when (and in-a (or (not (nil? a*)) (not same))) {k a*})
+ (when (and in-b (or (not (nil? b*)) (not same))) {k b*})
+ (when same {k ab})
+ ]))
+
 (defn- diff-associative
   "Diff associative things a and b, comparing only keys in ks."
   [a b ks]
@@ -38,7 +54,7 @@
  (doall (map merge diff1 diff2)))
[nil nil nil]
(map
-(fn [k] (map #(when % {k %}) (diff (get a k) (get b k
+(partial diff-associative-key a b)
 ks)))
 
 (defn- diff-sequential
diff --git a/test/clojure/test_clojure/data.clj 
b/test/clojure/test_clojure/data.clj
index 9bab766..5a241e0 100644
--- a/test/clojure/test_clojure/data.clj
+++ b/test/clojure/test_clojure/data.clj
@@ -27,5 +27,6 @@
[#{1} #{3} #{2}] (HashSet. [1 2]) (HashSet. [2 3])
[nil nil [1 2]] [1 2] (into-array [1 2])
[nil nil [1 2]] (into-array [1 2]) [1 2]
-   [{:a {:c [1]}} {:a {:c [0]}} {:a {:c [nil 2] :b 1}}] {:a {:b 1 :c 
[1 2]}} {:a {:b 1 :c [0 2]}}))
+   [{:a {:c [1]}} {:a {:c [0]}} {:a {:c [nil 2] :b 1}}] {:a {:b 1 :c 
[1 2]}} {:a {:b 1 :c [0 2]}}
+   [{:a nil} {:a false} {:b nil :c false}] {:a nil :b nil :c false} 
{:a false :b nil :c false}))
 
-- 
1.7.9.5

-- 
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

Re: Abridged summary of clojure@googlegroups.com - 28 Messages in 7 Topics

[clifford goldberg]

 On 02 Jun 2012 1:57 AM,  wrote:

>   Today's Topic Summary
>
> Group: http://groups.google.com/group/clojure/topics
>
>- When arithmetic on a computer bite 
> back<#137aa7bd6d6d4f87_group_thread_0>[3 Updates]
>- using -> on a nested hash-map with string 
> keywords.<#137aa7bd6d6d4f87_group_thread_1>[2 Updates]
>- clojure.reflect annotations <#137aa7bd6d6d4f87_group_thread_2> [4
>Updates]
>- [ANN] Itsy 0.1.0 released, a threaded web spider written in 
> Clojure<#137aa7bd6d6d4f87_group_thread_3>[4 Updates]
>- [ANN] Leiningen 2.0.0-preview5 
> released<#137aa7bd6d6d4f87_group_thread_4>[11 Updates]
>- ANN factual-clojure-driver 1.3.1, Factual's officially supported
>Clojure driver <#137aa7bd6d6d4f87_group_thread_5> [3 Updates]
>- Network Visual Layout Algorithm <#137aa7bd6d6d4f87_group_thread_6>[1 
> Update]
>
>   When arithmetic on a computer bite 
> back
>
>kawas  Jun 01 09:19AM -0700
>
>Hi,
>
>Can someone explain to me the behavior of this function when applied
>to different kind of numbers.
>
>(defn prime-factors [n]
>(loop [f 2 n n res []]
>(cond
>(<= n 1) res ...more
>
>
>Tassilo Horn  Jun 01 07:21PM +0200
>
>kawas  writes:
>
>Hi Laurent,
>
>
>> Problem 1 (solved): If you use (= n 1) in the first cond clause, the
>> function may not terminate because (= 1 1.0) may be false. ...more
>
>
>kawas  Jun 01 04:53PM -0700
>
>I've checked with a python repl, the correct value seems to be the one
>using BigDecs
>
>>>> from decimal import *
>>>> Decimal('1.4411518807585587E17') / Decimal(2)
>Decimal('72057594037927935')
>...more
>
>   using -> on a nested hash-map with string 
> keywords.
>
>"Boris V. Schmid"  Jun 01 12:08AM -0700
>
>Thanks, it was get-in that I was looking for, but couldn't find. Also
>thanks to Dave for explaining that keywords have some internal magic
>compared to strings. will remember!
>
>...more
>
>
>Sean Corfield  Jun 01 03:27PM -0700
>
>> Thanks, it was get-in that I was looking for, but couldn't find.
>
>At this point I'll give a plug for http://clojureatlas.com as a great
>way to explore the Clojure core/libraries by concept.
>-- ...more
>
>   clojure.reflect 
> annotations
>
>Jon Rose  Jun 01 11:38AM -0700
>
>Hello,
>
>I am wondering if anyone knows how to get method annotations from a
>method
>using the clojure.reflect library. I going of a Stuart Sierra ...more
>
>
>Jon Rose  Jun 01 11:42AM -0700
>
>sorry, typo. My bluetooth keyboard is geeking out. I meant, is it
>possible
>to do this with out using the Jave Reflection classes through interop.
>
>On Friday, June 1, 2012 11:38:17 AM UTC-7, Jon ...more
>
>
>Armando Blancas  Jun 01 01:39PM -0700
>
>That's the only way I've seen it done.
>
>Cool source box; how did you get it?
>
>
>On Friday, June 1, 2012 11:42:19 AM UTC-7, Jon Rose wrote:
>...more
>
>
>Jon Rose  Jun 01 01:42PM -0700
>
>Cool thanks for the info. I just pasted the code snippet in from stack
>overflow so it must copy the styles too.
>
>On Friday, June 1, 2012 1:39:05 PM UTC-7, Armando Blancas wrote:
>...more
>
>   [ANN] Itsy 0.1.0 released, a threaded web spider written in 
> Clojure
>
>Lee Hinman  May 31 09:49PM -0600
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Hi all,
>I'm pleased to announce the initial 0.1.0 release of Itsy. Itsy is a
>threaded web spider written in Clojure. A list of some of the Itsy
>...more
>
>
>"László Török"  Jun 01 01:24PM +0200
>
>Hi,
>
>interesting project. I was wondering though how do you make sure two
>crawlers do not crawl the same URL twice if there is no global state?
>:)
>
>If I read it correctly you're going to have to ...more
>
>
>Michael Klishin  Jun 01 11:53PM +0400
>
>László Török:
>
>> I was wondering though how do you make sure two
>> crawlers do not crawl the same URL twice if there is no global
>state? :)
>
>By adding sharing state, for a single app ...more
>
>
>"László Török"  Jun 01 10:22PM +0200
>
>Hi,
>
>don't want to turn this to a lengthy discussion about crawling, but
>happy
>to continue off list. ;)
>
>Sitemaps work surprisingly well in certain domains (web shops powered
>by ...more
>
>   [ANN] Leiningen 2.0.0-preview5 
> released
>
>Phil Hagelberg  May 31 10:11PM -0700
>
>I'm happy to announce the release of Leiningen 2.0.0-preview5.
>
>This release fixes a bug where the repl would hang under certain
>circumstances. It also adds support for encrypting credentials used
>   

Re: [PATCH] RFC: Add Functions `tabify` And `untabify`

[OGINO Masanori]

Hello.

> Please don't misinterpret my comments as saying you're wasting time.
> By all means, keep working on this. `tabify` and functions like it
> could be useful to others, I just don't know yet.

I see.

> If you can demonstrate an improvement to clojure.repl by adding these
> functions, then I think that's enough justification to add them --
> maybe first as private fns in clojure.repl. Later on, if they seem
> generally useful, we can incorporate them into clojure.string.

Yes, I'll post a patch for clojure.repl when I finish.

Many thanks to all suggestions and questions!

-- 
OGINO Masanori 
http://twitter.com/omasanori

-- 
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

Re: Why isn't there a fold-right?

[Tassilo Horn]

Yoshinori Kohyama  writes:

Hi!

> Here is my fold-right.
>
> (defn fold-right [f s coll]
>   ((reduce (fn [acc x] #(acc (f x %))) identity coll) s))

Very elegant, but sadly it blows the stack on larger collections.  On my
system, the threshold is somewhere beetween 15.000 and 16.000 elements.

Something much less elegant (and slower in cases where your variant also
does the trick) is:

(defn fold-right [f s coll]
  (reduce #(f %2 %1) s (reverse coll)))

Bye,
Tassilo

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

Re: Doseq, map-style

[Meikel Brandmeyer]

Hi,

Beware the personal opinion!

map applies a function to each element of a sequence and returns a sequence of 
the results.

If you call the "function" just for side-effects, but not the return value, 
then the semantics of map don't apply.

Kind regards
Meikel

-Ursprüngliche Nachricht-
Von: David Jacobs 
An: clojure@googlegroups.com
Gesendet: Sa, 09 Jun 2012, 23:08:21 MESZ
Betreff: Re: Doseq, map-style

Thanks, guys.

I know there are easy ways to implement what I want. However, I'm more curious 
as to why the language itself doesn't support this style of mapping 
side-effects.

In other words, why does doseq not follow map's lead here. Is there a 
philosophical difference underlying the syntax difference (doseq [elem coll] (f 
coll)) and (each f coll)?

It seems to me that the side-effecty nature of (doseq) isn't quite enough to 
justify the syntax difference between map and doseq. I guess one could say that 
because doseq is built for side-effects, which are often multiline, doseq 
should easily accept multiline statements. However, my imaginary each macro 
could do the same: (each #(do … …) coll).

What am I missing?

Thanks!
David

On Friday, June 8, 2012 at 7:00 AM, Lars Nilsson wrote:

> On Fri, Jun 8, 2012 at 9:54 AM, Allen Johnson  (mailto:akjohnso...@gmail.com)> wrote:
> > Combine map with dorun and you get the same effect:
> >  
> > (dorun (map println logs))
> >  
> > http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
> >  
> > Allen
> >  
> > On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs  > (mailto:da...@wit.io)> wrote:
> > > I would love to have a version of doseq that works like map (similar to
> > > "each" in other dynamic languages). In other words, instead of (doseq [log
> > > logs] (println log)), I would say something like (each println logs).
> > >  
> > > Is there a built-in Clojure method that works like this?
>  
> Not a built-in, but...
>  
> (defmacro for-each [f x] `(doseq [item# ~x] (~f item#)))
>  
> I suppose this solution is blindingly obvious though.
>  
> Also, I would be curious if there's any significant performance
> difference using (dorun (map ...)) as I assume an intermediate result
> is built and then thrown away. Or perhaps it's insignificant compared
> to what the unspecified function does that is passed to map for
> performing the side-effect work..
>  
> Lars Nilsson
>  
> --  
> 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 
> (mailto: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 
> (mailto: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 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 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

Re: Doseq, map-style

[David Jacobs]

I agree that it probably doesn't need to be a macro (your second suggestion was 
my first inclination).  

I didn't realize doseq took keyword options, that's good to know.  


On Saturday, June 9, 2012 at 7:51 PM, Walter Tetzner wrote:

> > Is there a philosophical difference underlying the syntax difference (doseq 
> > [elem coll] (f coll)) and (each f coll)?
>  
>  
> `doseq' is the side-effecty version of `'for', not map. It lets you do things 
> like
>  
> user> (doseq [x (range 100)
> :while (< x 20)
> :when (even? x)]
> (println x))
> 0
> 2
> 4
> 6
> 8
> 10
> 12
> 14
> 16
> 18
>  
> If you want a side-effecty version of map, I would avoid the macro suggested 
> earlier, and just do
>  
> (def each (comp dorun map))
>  
> or
>  
> (defn each [f coll] (doseq [x coll] (f x)))
>  
> -Walter
>  
> On Sat, Jun 9, 2012 at 5:08 PM, David Jacobs  (mailto:da...@wit.io)> wrote:
> > Thanks, guys.
> >  
> > I know there are easy ways to implement what I want. However, I'm more 
> > curious as to why the language itself doesn't support this style of mapping 
> > side-effects.
> >  
> > In other words, why does doseq not follow map's lead here. Is there a 
> > philosophical difference underlying the syntax difference (doseq [elem 
> > coll] (f coll)) and (each f coll)?
> >  
> > It seems to me that the side-effecty nature of (doseq) isn't quite enough 
> > to justify the syntax difference between map and doseq. I guess one could 
> > say that because doseq is built for side-effects, which are often 
> > multiline, doseq should easily accept multiline statements. However, my 
> > imaginary each macro could do the same: (each #(do … …) coll).
> >  
> > What am I missing?
> >  
> > Thanks!
> > David
> >  
> > On Friday, June 8, 2012 at 7:00 AM, Lars Nilsson wrote:
> >  
> > > On Fri, Jun 8, 2012 at 9:54 AM, Allen Johnson  > > (mailto:akjohnso...@gmail.com) (mailto:akjohnso...@gmail.com)> wrote:
> > > > Combine map with dorun and you get the same effect:
> > > >  
> > > > (dorun (map println logs))
> > > >  
> > > > http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
> > > >  
> > > > Allen
> > > >  
> > > > On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs  > > > (mailto:da...@wit.io) (mailto:da...@wit.io)> wrote:
> > > > > I would love to have a version of doseq that works like map (similar 
> > > > > to
> > > > > "each" in other dynamic languages). In other words, instead of (doseq 
> > > > > [log
> > > > > logs] (println log)), I would say something like (each println logs).
> > > > >  
> > > > > Is there a built-in Clojure method that works like this?
> > >  
> > > Not a built-in, but...
> > >  
> > > (defmacro for-each [f x] `(doseq [item# ~x] (~f item#)))
> > >  
> > > I suppose this solution is blindingly obvious though.
> > >  
> > > Also, I would be curious if there's any significant performance
> > > difference using (dorun (map ...)) as I assume an intermediate result
> > > is built and then thrown away. Or perhaps it's insignificant compared
> > > to what the unspecified function does that is passed to map for
> > > performing the side-effect work..
> > >  
> > > Lars Nilsson
> > >  
> > > --
> > > 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 
> > > (mailto:clojure@googlegroups.com) (mailto: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 
> > > (mailto:clojure%2bunsubscr...@googlegroups.com) 
> > > (mailto:clojure+unsubscr...@googlegroups.com 
> > > (mailto:clojure%2bunsubscr...@googlegroups.com))
> > > For more options, visit this group at
> > > http://groups.google.com/group/clojure?hl=en
> >  
> >  
> >  
> >  
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com 
> > (mailto: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 
> > (mailto:clojure%2bunsubscr...@googlegroups.com)
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>  
> --  
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> (mailto: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 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
You received this message bec