Re: Is still idiomatic the ant simulation code?

[Yann Schwartz]

That's great. I've also noticed the sample still uses defstruct which is
made obsolete by defrecord.

On Tue, Jun 12, 2012 at 7:59 AM, Baishampayan Ghose wrote:

> > Can you elaborate some suggestions?
>
> I have updated the Ants sim code to use the "idiomatic" JVM inter-op
> constructs and made some other minor changes.
>
> Will work fine on Clojure 1.4
>
> Here is the updated code - https://www.refheap.com/paste/3099
> This is the unified diff - https://www.refheap.com/paste/3100
>
> Needless to say, all mistakes are mine.
>
> 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
>

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

[Christophe Grand]

Hi,

To contrast our experiences of the language and the different approaches to
deal with some problems:

On Sun, Jun 10, 2012 at 4:47 AM, Kurt Harriger wrote:

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

Do you test only the functions or do you have also introduced "lint"
functions which check the shape of your data. To me, these are pretty
useful: you can use them in tests, pre/postconds, middlewares to guard
against untrusted sources etc.



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

Basically you are returning a "lazy map" a map of keys to delayed values
(why not use delays instead of fns as values?), while it is sometimes a
necessity to do so, the implied trade-off must not be overlooked: the map
can't be treated as a value anymore: if you call twice the pure function
which generates such a lazy map twice with the same arguments, you get two
lazy maps which are not equals! I'm not even speaking about being equal to
their non-lazy counterparts (which makes them a bit harder to test)


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

I think this is a premature optimization. If you need to get rid off
keywords acces later on, you can either do what you propose and modify all
the call sites to remove the colon (but the important thing is that it
won't change the shape of your code, it's a minor refactoring) OR if you
are really stuck and don't want to touch the codebase, don't forget that in
Clojure (unless you are using interop) you are always one abstraction away:
you can define your own associative type which will knows how to respond to
lookup for gets. Plus doing so you may even choose to leverage the
optimized code path for keyword lookups (see IKeywordLookup.java).

Christophe

-- 
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: Is still idiomatic the ant simulation code?

[Baishampayan Ghose]

On Tue, Jun 12, 2012 at 1:37 PM, Yann Schwartz  wrote:
> That's great. I've also noticed the sample still uses defstruct which is
> made obsolete by defrecord.

While I agree that one could use a record in place of a struct, I
don't think structs are "obsolete", at least not officially.

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: Explaining the thrush -> operator.

[Jacek Laskowski]

On Tue, Jun 12, 2012 at 2:08 AM, Frank Siebenlist
 wrote:

> (-> 2
>    (* 5)
>    (+ 3))

It also resembles a waterfall (not very friendly term in our
profession, but fits well in this case) where the result of an earlier
computation is passed on down the stack. It also works very similarly
to the let form (which gives a sort of imperative look to the code and
more powerful way to place the earlier results) as well as...the maybe
monad. The question is when to use each, but guess it's a matter of
taste.

Jacek

-- 
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

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

How about 'nth' accepts maps?

[Yoshinori Kohyama]

Hello forum,

Given

(def m (sorted-map 1 :a 2 :b 3 :c 4 :d 5 :e))

,

(nth m 0)

throws 'UnsupportedOperationException nth', while

(first m) ; -> [1 :a]
(next m)  ; -> ([2 :b] [3 :c] [4 :d] [5 :e])
(nthnext m 1) ; -> ([2 :b] [3 :c] [4 :d] [5 :e])
.

How do you think about nth accepts maps

(defn my-nth [coll index]
  (loop [n index xs (seq coll)]
(if-let [x (first xs)]

  (if (zero? n) x (recur (dec n) (next xs))

(my-nth m 0) ; -> [1 :a]

like the implementation of nthnext?

Of cource, this should be used for collections only which don't supported 
nth directly, I think.

A form

(let [[a b c & d :as e] [1 2 3 4 5]]
  [a b c d e]) 

returns

[1 2 3 (4 5) [1 2 3 4 5]]
, but

(let [[a b c & d :as e] (sorted-map 1 :a 2 :b 3 :c 4 :d 5 :e)]
  [a b c d e])
throws 'UnsupportedOperationException nth'.

What do you think if it returned

  [[1 :a] [2 :b] [3 :c] {4 :d 5 :e} {1 :a 2 :b 3 :c 4 :d 5 :e}]

.


Or isn't it good that you can write operations for a map like

(loop [[[k v :as x] & xs] m acc '()]
  (if x
  (recur xs (cons acc (some-operation-for k v)))
  acc))

?


Please let me hear opinions.


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: [PATCH] Enhance clojure.data/diff to cope with falsey values in maps

[Philip Aston]

I've opened JIRA CLJ-1011.

On Sunday, June 10, 2012 1:16:55 PM UTC+1, Philip Aston wrote:
>
> 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: How about 'nth' accepts maps?

[Chris Ford]

While it would be possible to support it, I don't think that it makes sense
for maps (or sets).

While first and next need to be supported to make maps and sets sequable, I
don't think that conceptually the elements are ordered.

Cheers,

Chris

On 12 June 2012 11:03, Yoshinori Kohyama  wrote:

> Hello forum,
>
> Given
>
> (def m (sorted-map 1 :a 2 :b 3 :c 4 :d 5 :e))
>
> ,
>
> (nth m 0)
>
> throws 'UnsupportedOperationException nth', while
>
> (first m) ; -> [1 :a]
> (next m)  ; -> ([2 :b] [3 :c] [4 :d] [5 :e])
> (nthnext m 1) ; -> ([2 :b] [3 :c] [4 :d] [5 :e])
> .
>
> How do you think about nth accepts maps
>
> (defn my-nth [coll index]
>   (loop [n index xs (seq coll)]
> (if-let [x (first xs)]
>
>   (if (zero? n) x (recur (dec n) (next xs))
>
> (my-nth m 0) ; -> [1 :a]
>
> like the implementation of nthnext?
>
> Of cource, this should be used for collections only which don't supported
> nth directly, I think.
>
> A form
>
> (let [[a b c & d :as e] [1 2 3 4 5]]
>   [a b c d e])
>
> returns
>
> [1 2 3 (4 5) [1 2 3 4 5]]
> , but
>
> (let [[a b c & d :as e] (sorted-map 1 :a 2 :b 3 :c 4 :d 5 :e)]
>   [a b c d e])
> throws 'UnsupportedOperationException nth'.
>
> What do you think if it returned
>
>   [[1 :a] [2 :b] [3 :c] {4 :d 5 :e} {1 :a 2 :b 3 :c 4 :d 5 :e}]
>
> .
>
>
> Or isn't it good that you can write operations for a map like
>
> (loop [[[k v :as x] & xs] m acc '()]
>   (if x
>   (recur xs (cons acc (some-operation-for k v)))
>   acc))
>
> ?
>
>
> Please let me hear opinions.
>
>
> 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

-- 
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: How about 'nth' accepts maps?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Dienstag, 12. Juni 2012 12:10:08 UTC+2 schrieb Chris Ford:
>
> While first and next need to be supported to make maps and sets sequable, 
> I don't think that conceptually the elements are ordered.


Take care! Neither maps nor sets (nor vectors for that matter) support 
first and next! These are sequence functions! They only work on sequences. 
The fact that you can pass in maps, sets or vectors is due to the fact that 
first and next are nice and call seq on the argument on your behalf so that 
you don't have to. But that doesn't mean, that the map itself supports 
first or next.

Neither maps nor sets are sequential data structures. So nth doesn't make 
much sense to work with them. I'm not sure about the sorted variants. 

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

Re: Is still idiomatic the ant simulation code?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Dienstag, 12. Juni 2012 10:24:31 UTC+2 schrieb Baishampayan Ghose:
>
>
> While I agree that one could use a record in place of a struct, I 
> don't think structs are "obsolete", at least not officially. 
>
>
>From http://clojure.org/datatypes:

Overall, records will be better than structmaps for all information-bearing 
>> purposes, and you should move such structmaps to defrecord. 
>>
>
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

Classpath problem with Java interop and Leiningen

[Denis Vulinovich]

I'm fairly new to Clojure and Java. When I try to call Clojure code
from Java, I get an error "java.io.FileNotFoundException: Could not
locate Clojure resource on classpath: bar.clj".

I've created a simple project in Eclipse with one Java file:

package sample;
import clojure.lang.*;
public class foo {
public static void main(String[] args) throws Exception {
RT.loadResourceScript("bar.clj");
Var foo = RT.var("sample.bar", "hello");
Object result = foo.invoke("world");
System.out.print(result);
}
}

This calls bar.clr:

(ns sample.bar)
(defn hello [name]
  (str "Hello," name))

I'm using Leiningen with project.clj:

(defproject sample "1.0.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.3.0"]]
  :aot [sample.bar])

When I run "lein compile", it creates three bar*.class files in C:\dev
\vaadin\sample\classes\sample. My Java classpath (in Windows) is C:\dev
\vaadin\sample.

Thanks for your help.

-- 
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: How about 'nth' accepts maps?

[Chris Ford]

Meikel is quite right. I should have said that maps and sets support seq...

I guess the question should then be, should nth call seq on its argument?

On 12 June 2012 11:31, Meikel Brandmeyer (kotarak)  wrote:

> Hi,
>
> Am Dienstag, 12. Juni 2012 12:10:08 UTC+2 schrieb Chris Ford:
>
>> While first and next need to be supported to make maps and sets sequable,
>> I don't think that conceptually the elements are ordered.
>
>
> Take care! Neither maps nor sets (nor vectors for that matter) support
> first and next! These are sequence functions! They only work on sequences.
> The fact that you can pass in maps, sets or vectors is due to the fact that
> first and next are nice and call seq on the argument on your behalf so that
> you don't have to. But that doesn't mean, that the map itself supports
> first or next.
>
> Neither maps nor sets are sequential data structures. So nth doesn't make
> much sense to work with them. I'm not sure about the sorted variants.
>
> 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 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: Is still idiomatic the ant simulation code?

[Baishampayan Ghose]

>> While I agree that one could use a record in place of a struct, I
>> don't think structs are "obsolete", at least not officially.
>>
>
> From http://clojure.org/datatypes:
>
>>> Overall, records will be better than structmaps for all
>>> information-bearing purposes, and you should move such structmaps to
>>> defrecord.

In that case, defstruct, etc. should bear the same warning in
docstrings/metadata as well.

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

If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

why can't I use the interface as function argument instead of the 
concrete class (record)?


example: (defprotocol IPiece
 blah blah blah)

(defrecord ChessPiece
IPiece
 blah blah blah)

(defrecord CheckersPiece
IPiece
 blah blah blah)

(defn move [^IPiece p]  ;will complain that it can't resolve type IPiece
blah blah blah)

do I need to do (derive ::ChessPiece ::IPiece) ???

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

Re: If a protocol creates a Java interface under the covers...

[Tassilo Horn]

"Jim - FooBar();"  writes:

> why can't I use the interface as function argument instead of the
> concrete class (record)?
>
> example: (defprotocol IPiece
>  blah blah blah)
>
> (defrecord ChessPiece
> IPiece
>  blah blah blah)
>
> (defrecord CheckersPiece
> IPiece
>  blah blah blah)
>
> (defn move [^IPiece p]  ;will complain that it can't resolve type IPiece
> blah blah blah)

The interface will reside in the current namespace, so you need to
qualify it.

--8<---cut here---start->8---
user> (defprotocol IPiece
  (frobnicate [this]))
IPiece
user> IPiece
{:on-interface user.IPiece, :on user.IPiece, :sigs {:frobnicate {:doc nil, 
:arglists ([this]), :name frobnicate}}, :var #'user/IPiece, :method-map 
{:frobnicate :frobnicate}, :method-builders {#'user/frobnicate 
#}}
user> user.IPiece
user.IPiece
user> (class user.IPiece)
java.lang.Class
user> (.isInterface user.IPiece)
true
--8<---cut here---end--->8---

However, that there is an interface is more or less an implementation
detail.  Protocol methods are dispatched dynamically and quickly enough,
so there's no benefit in type-hinting with generated interfaces.  Too
prove that:

--8<---cut here---start->8---
user> (defrecord Frob [x]
IPiece
(frobnicate [this] x))
user.Frob
user> (defn frob1 [p] (frobnicate p))
#'user/frob1
user> (defn frob2 [^user.IPiece p] (frobnicate p))
#'user/frob2
user> (use 'criterium.core)
nil
user> (let [f (->Frob 10)]
   (bench (frob1 f) :verbose)
   (bench (frob2 f) :verbose))
amd64 Linux 3.4.0-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n 
-XX:+TieredCompilation -Xmx1G 
-Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes 
-Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false
Evaluation count : 8495040
 Execution time mean : 6.474061 us  95.0% CI: (6.473442 us, 
6.474699 us)
Execution time std-deviation : 71.405519 ns  95.0% CI: (70.680926 ns, 
72.202375 ns)
 Execution time lower ci : 6.390741 us  95.0% CI: (6.390741 us, 
6.390741 us)
 Execution time upper ci : 6.595243 us  95.0% CI: (6.594962 us, 
6.595243 us)

Found 1 outliers in 60 samples (1.6667 %)
low-severe   1 (1.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
amd64 Linux 3.4.0-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n 
-XX:+TieredCompilation -Xmx1G 
-Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes 
-Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false
Evaluation count : 9339360
 Execution time mean : 6.482568 us  95.0% CI: (6.481979 us, 
6.483191 us)
Execution time std-deviation : 82.858647 ns  95.0% CI: (82.277583 ns, 
83.438706 ns)
 Execution time lower ci : 6.409230 us  95.0% CI: (6.409230 us, 
6.409230 us)
 Execution time upper ci : 6.648313 us  95.0% CI: (6.646894 us, 
6.648313 us)

Found 3 outliers in 60 samples (5. %)
low-severe   3 (5. %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
nil
--8<---cut here---end--->8---

Here you can see that calls to the hinted `frob2` are not faster than
calls to the non-hinted `frob1`.  So don't do that.

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

aaa ok I see...

however I only want to do this to avoid a specific reflection call...you 
see my move function take either any type that satisfies IPiece and so 
at each call reflection is needed to decide which one to use...I'd like 
to say in the argument that what is coming is a IPiece so stop doing 
reflection and dispatch directly to IPiece who will then decide between 
the correct implementation based on the first argument only...


am I missing something? Is this not correct? I want to keep 'move' as 
tight as possible - that's all!


Jim

ps: thanks for the detailed answer :-)


On 12/06/12 12:50, Tassilo Horn wrote:

"Jim - FooBar();"  writes:


why can't I use the interface as function argument instead of the
concrete class (record)?

example: (defprotocol IPiece
  blah blah blah)

(defrecord ChessPiece
IPiece
  blah blah blah)

(defrecord CheckersPiece
IPiece
  blah blah blah)

(defn move [^IPiece p]  ;will complain that it can't resolve type IPiece
blah blah blah)

The interface will reside in the current namespace, so you need to
qualify it.

--8<---cut here---start->8---
user>  (defprotocol IPiece
  (frobnicate [this]))
IPiece
user>  IPiece
{:on-interface user.IPiece, :on user.IPiece, :sigs {:frobnicate {:doc nil, :arglists 
([this]), :name frobnicate}}, :var #'user/IPiece, :method-map {:frobnicate 
:frobnicate}, :method-builders {#'user/frobnicate #}}
user>  user.IPiece
user.IPiece
user>  (class user.IPiece)
java.lang.Class
user>  (.isInterface user.IPiece)
true
--8<---cut here---end--->8---

However, that there is an interface is more or less an implementation
detail.  Protocol methods are dispatched dynamically and quickly enough,
so there's no benefit in type-hinting with generated interfaces.  Too
prove that:

--8<---cut here---start->8---
user>  (defrecord Frob [x]
IPiece
(frobnicate [this] x))
user.Frob
user>  (defn frob1 [p] (frobnicate p))
#'user/frob1
user>  (defn frob2 [^user.IPiece p] (frobnicate p))
#'user/frob2
user>  (use 'criterium.core)
nil
user>  (let [f (->Frob 10)]
   (bench (frob1 f) :verbose)
   (bench (frob2 f) :verbose))
amd64 Linux 3.4.0-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n 
-XX:+TieredCompilation -Xmx1G 
-Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes 
-Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false
Evaluation count : 8495040
  Execution time mean : 6.474061 us  95.0% CI: (6.473442 us, 
6.474699 us)
 Execution time std-deviation : 71.405519 ns  95.0% CI: (70.680926 ns, 
72.202375 ns)
  Execution time lower ci : 6.390741 us  95.0% CI: (6.390741 us, 
6.390741 us)
  Execution time upper ci : 6.595243 us  95.0% CI: (6.594962 us, 
6.595243 us)

Found 1 outliers in 60 samples (1.6667 %)
low-severe   1 (1.6667 %)
  Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
amd64 Linux 3.4.0-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n 
-XX:+TieredCompilation -Xmx1G 
-Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes 
-Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false
Evaluation count : 9339360
  Execution time mean : 6.482568 us  95.0% CI: (6.481979 us, 
6.483191 us)
 Execution time std-deviation : 82.858647 ns  95.0% CI: (82.277583 ns, 
83.438706 ns)
  Execution time lower ci : 6.409230 us  95.0% CI: (6.409230 us, 
6.409230 us)
  Execution time upper ci : 6.648313 us  95.0% CI: (6.646894 us, 
6.648313 us)

Found 3 outliers in 60 samples (5. %)
low-severe   3 (5. %)
  Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
nil
--8<---cut here---end--->8---

Here you can see that calls to the hinted `frob2` are not faster than
calls to the non-hinted `frob1`.  So don't do that.

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

Thanks Tassilo,

your suggestion of fully qualifying the protocol worked like a charm! I 
managed to eliminate my last 2 reflective calls on the whole 
namespace... this is good stuff!


Jim


On 12/06/12 12:57, Jim - FooBar(); wrote:

aaa ok I see...

however I only want to do this to avoid a specific reflection 
call...you see my move function take either any type that satisfies 
IPiece and so at each call reflection is needed to decide which one to 
use...I'd like to say in the argument that what is coming is a IPiece 
so stop doing reflection and dispatch directly to IPiece who will then 
decide between the correct implementation based on the first argument 
only...


am I missing something? Is this not correct? I want to keep 'move' as 
tight as possible - that's all!


Jim

ps: thanks for the detailed answer :-)


On 12/06/12 12:50, Tassilo Horn wrote:

"Jim - FooBar();"  writes:


why can't I use the interface as function argument instead of the
concrete class (record)?

example: (defprotocol IPiece
  blah blah blah)

(defrecord ChessPiece
IPiece
  blah blah blah)

(defrecord CheckersPiece
IPiece
  blah blah blah)

(defn move [^IPiece p]  ;will complain that it can't resolve type 
IPiece

blah blah blah)

The interface will reside in the current namespace, so you need to
qualify it.

--8<---cut here---start->8---
user>  (defprotocol IPiece
  (frobnicate [this]))
IPiece
user>  IPiece
{:on-interface user.IPiece, :on user.IPiece, :sigs {:frobnicate {:doc 
nil, :arglists ([this]), :name frobnicate}}, :var #'user/IPiece, 
:method-map {:frobnicate :frobnicate}, :method-builders 
{#'user/frobnicate #user$eval2292$fn__2293@62e6615f>}}

user>  user.IPiece
user.IPiece
user>  (class user.IPiece)
java.lang.Class
user>  (.isInterface user.IPiece)
true
--8<---cut here---end--->8---

However, that there is an interface is more or less an implementation
detail.  Protocol methods are dispatched dynamically and quickly enough,
so there's no benefit in type-hinting with generated interfaces.  Too
prove that:

--8<---cut here---start->8---
user>  (defrecord Frob [x]
IPiece
(frobnicate [this] x))
user.Frob
user>  (defn frob1 [p] (frobnicate p))
#'user/frob1
user>  (defn frob2 [^user.IPiece p] (frobnicate p))
#'user/frob2
user>  (use 'criterium.core)
nil
user>  (let [f (->Frob 10)]
   (bench (frob1 f) :verbose)
   (bench (frob2 f) :verbose))
amd64 Linux 3.4.0-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: 
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n 
-XX:+TieredCompilation -Xmx1G 
-Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes 
-Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false

Evaluation count : 8495040
  Execution time mean : 6.474061 us  95.0% CI: (6.473442 
us, 6.474699 us)
 Execution time std-deviation : 71.405519 ns  95.0% CI: 
(70.680926 ns, 72.202375 ns)
  Execution time lower ci : 6.390741 us  95.0% CI: (6.390741 
us, 6.390741 us)
  Execution time upper ci : 6.595243 us  95.0% CI: (6.594962 
us, 6.595243 us)


Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
  Variance from outliers : 1.6389 % Variance is slightly inflated by 
outliers

amd64 Linux 3.4.0-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: 
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n 
-XX:+TieredCompilation -Xmx1G 
-Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes 
-Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false

Evaluation count : 9339360
  Execution time mean : 6.482568 us  95.0% CI: (6.481979 
us, 6.483191 us)
 Execution time std-deviation : 82.858647 ns  95.0% CI: 
(82.277583 ns, 83.438706 ns)
  Execution time lower ci : 6.409230 us  95.0% CI: (6.409230 
us, 6.409230 us)
  Execution time upper ci : 6.648313 us  95.0% CI: (6.646894 
us, 6.648313 us)


Found 3 outliers in 60 samples (5. %)
low-severe 3 (5. %)
  Variance from outliers : 1.6389 % Variance is slightly inflated by 
outliers

nil
--8<---cut here---end--->8---

Here you can see that calls to the hinted `frob2` are not faster than
calls to the non-hinted `frob1`.  So don't do that.

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: Classpath problem with Java interop and Leiningen

[Jacek Laskowski]

On Tue, Jun 12, 2012 at 8:50 AM, Denis Vulinovich
 wrote:

> My Java classpath (in Windows) is C:\dev\vaadin\sample.

It misses "classes" subdirectory.

Also, I don't think you need lein for the example. Write a clj script
and have it loaded/compiled by RT.loadResourceScript.

If you're in Eclipse, use Counterclockwise plugin to manage your
Clojure project and have it be a dependency of the Java project with
the main class. I believe you can also create a multi-language project
with Clojure and Java side-by-side, but I'd rather suggest have many
smaller projects each with their own language than one big project
with many languages. I think it's a matter of taste, tough.

Jacek

-- 
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

-- 
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: Leiningen2 + lein-midje + lazytest question

[Jacek Laskowski]

On Mon, Jun 11, 2012 at 9:52 PM, Cédric Pineau  wrote:

> Also, can someone point me to a ~/lein/profiles.clj sample or a complete
> lein2 documentation ?

Just to add to Phil's answer:

The profiles in lein2 are just a map (obviously, isn't it?) where the
key is the name of the profile and the value another map with the
project's key-values as if you were to include in defproject. Unless
I'm mistaken, user, dev and...doh, forgot the one...are automatically
included while executing any lein commands. As you might've guessed,
the key-value pairs of a profile override the project's settings.

Jacek

-- 
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

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

Clojurescript (latest) advanced mode compilation => java.lang.ClassCastException ?

[Dave Sann]

I have started seeing java.lang.ClassCastException when compiling in 
advanced mode.

Compilation is fine with simple optimisations.

This happens with source code that previously did not complain...

I am wondering if this might be related to :

https://groups.google.com/d/topic/clojure/NHIzoUz0wmc/discussion

Anyone else see this?

D

-- 
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: If a protocol creates a Java interface under the covers...

[Tassilo Horn]

"Jim - FooBar();"  writes:

Hi Jim,

> however I only want to do this to avoid a specific reflection
> call... you see my move function take either any type that satisfies
> IPiece and so at each call reflection is needed to decide which one to
> use...

I don't get you.  If IPieces can be moved, then move should be a
protocol method declared in IPiece.

And when you say you have reflection warnings, can it be that you call a
protocol method foo with (.foo o) [note the .-syntax]...

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

On 12/06/12 13:16, Tassilo Horn wrote:

I don't get you.  If IPieces can be moved, then move should be a
protocol method declared in IPiece.


No what i have in IPiece is 'updatePosition' so each piece knows how to 
update its position. THere is more to a move though. 'move' is a regular 
function that builds a new board every time...a move might have killed 
some pieces etc...



And when you say you have reflection warnings, can it be that you call a
protocol method foo with (.foo o) [note the .-syntax]...

I'msure you will understand if you see the code:

(defn move
"The function responsible for moving Pieces. Each piece knows how to 
move itself. Returns the new board."

 ^clojure.lang.LazySeq
[^clojure.lang.Symbol game mappings ^Clondie24.core.IPiece p coords]
{:pre [(satisfies? IPiece p)]}  ;safety comes first
(if (in? mappings (vector-of-doubles coords)) ;check that position 
exists on the grid

(do  (.update-position p coords) ;coords should be of the form [x, y]
(reset! (current-items game true) ;replace the board atom
(clean (build-board game ;;replace the old board with the new
(throw (IllegalArgumentException. (str coords " is NOT a valid position 
according to the mappings provided!")



Notice the ''(.update-position p coords)" right after 'do'...this is 
where the reflection was occuring because I could not type-hint the 
argument  correctly! Now it is sorted though (as you can see)...


makes sense now?

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

Of course, I Just noticed that type-hinting 'p' renders the precondition 
useless...an extra performance bonus!


Jim

On 12/06/12 13:26, Jim - FooBar(); wrote:

On 12/06/12 13:16, Tassilo Horn wrote:

I don't get you.  If IPieces can be moved, then move should be a
protocol method declared in IPiece.


No what i have in IPiece is 'updatePosition' so each piece knows how 
to update its position. THere is more to a move though. 'move' is a 
regular function that builds a new board every time...a move might 
have killed some pieces etc...



And when you say you have reflection warnings, can it be that you call a
protocol method foo with (.foo o) [note the .-syntax]...

I'msure you will understand if you see the code:

(defn move
"The function responsible for moving Pieces. Each piece knows how to 
move itself. Returns the new board."

 ^clojure.lang.LazySeq
[^clojure.lang.Symbol game mappings ^Clondie24.core.IPiece p coords]
{:pre [(satisfies? IPiece p)]}  ;safety comes first
(if (in? mappings (vector-of-doubles coords)) ;check that position 
exists on the grid

(do  (.update-position p coords) ;coords should be of the form [x, y]
(reset! (current-items game true) ;replace the board atom
(clean (build-board game ;;replace the old board with the new
(throw (IllegalArgumentException. (str coords " is NOT a valid 
position according to the mappings provided!")



Notice the ''(.update-position p coords)" right after 'do'...this is 
where the reflection was occuring because I could not type-hint the 
argument  correctly! Now it is sorted though (as you can see)...


makes sense now?

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

And when you say you have reflection warnings, can it be that you call a
protocol method foo with (.foo o) [note the .-syntax]...


I'm not sure what you mean...Of course I'm calling a protocol method 
with (.update-position p coords) - with the '.'

How else can I call it?

Jim

On 12/06/12 13:28, Jim - FooBar(); wrote:
Of course, I Just noticed that type-hinting 'p' renders the 
precondition useless...an extra performance bonus!


Jim

On 12/06/12 13:26, Jim - FooBar(); wrote:

On 12/06/12 13:16, Tassilo Horn wrote:

I don't get you.  If IPieces can be moved, then move should be a
protocol method declared in IPiece.


No what i have in IPiece is 'updatePosition' so each piece knows how 
to update its position. THere is more to a move though. 'move' is a 
regular function that builds a new board every time...a move might 
have killed some pieces etc...


And when you say you have reflection warnings, can it be that you 
call a

protocol method foo with (.foo o) [note the .-syntax]...

I'msure you will understand if you see the code:

(defn move
"The function responsible for moving Pieces. Each piece knows how to 
move itself. Returns the new board."

 ^clojure.lang.LazySeq
[^clojure.lang.Symbol game mappings ^Clondie24.core.IPiece p coords]
{:pre [(satisfies? IPiece p)]}  ;safety comes first
(if (in? mappings (vector-of-doubles coords)) ;check that position 
exists on the grid

(do  (.update-position p coords) ;coords should be of the form [x, y]
(reset! (current-items game true) ;replace the board atom
(clean (build-board game ;;replace the old board with the 
new
(throw (IllegalArgumentException. (str coords " is NOT a valid 
position according to the mappings provided!")



Notice the ''(.update-position p coords)" right after 'do'...this is 
where the reflection was occuring because I could not type-hint the 
argument  correctly! Now it is sorted though (as you can see)...


makes sense now?

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: If a protocol creates a Java interface under the covers...

[Meikel Brandmeyer (kotarak)]

Hi,

Am Dienstag, 12. Juni 2012 14:28:21 UTC+2 schrieb Jim foo.bar:
>
> Of course, I Just noticed that type-hinting 'p' renders the precondition 
> useless...an extra performance bonus! 
>
>
If update-position is a protocol function just call it without the dot. 
Just like a normal function. Then any reflection will go away and no type 
hint is needed.

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

Re: Clojurescript (latest) advanced mode compilation => java.lang.ClassCastException ?

[David Nolen]

That ticket has been resolved.

For your own issue, more details required. If you can isolate it, open a
ticket.

David

On Tue, Jun 12, 2012 at 8:16 AM, Dave Sann  wrote:

> I have started seeing java.lang.ClassCastException when compiling in
> advanced mode.
>
> Compilation is fine with simple optimisations.
>
> This happens with source code that previously did not complain...
>
> I am wondering if this might be related to :
>
> https://groups.google.com/d/topic/clojure/NHIzoUz0wmc/discussion
>
> Anyone else see this?
>
> D
>
> --
> 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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
If update-position is a protocol function just call it without the 
dot. Just like a normal function. Then any reflection will go away and 
no type hint is needed.


WHAT??? Seriously??? I'll try it...

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

On 12/06/12 13:53, Jim - FooBar(); wrote:

On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
If update-position is a protocol function just call it without the 
dot. Just like a normal function. Then any reflection will go away 
and no type hint is needed.


WHAT??? Seriously??? I'll try it...

Jim


OMG! You were right Meikel... I cannot believe this! I don't recall 
reading about this anywhere...


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: Classpath problem with Java interop and Leiningen

[Laurent PETIT]

If your namespace is sample.bar, shouldn't the load() call
"sample/bar.clj" instead of "bar.clj" ?



Le 12 juin 2012 à 12:39, Denis Vulinovich
 a écrit :

> I'm fairly new to Clojure and Java. When I try to call Clojure code
> from Java, I get an error "java.io.FileNotFoundException: Could not
> locate Clojure resource on classpath: bar.clj".
>
> I've created a simple project in Eclipse with one Java file:
>
> package sample;
> import clojure.lang.*;
> public class foo {
>public static void main(String[] args) throws Exception {
>RT.loadResourceScript("bar.clj");
>Var foo = RT.var("sample.bar", "hello");
>Object result = foo.invoke("world");
>System.out.print(result);
>}
> }
>
> This calls bar.clr:
>
> (ns sample.bar)
> (defn hello [name]
>  (str "Hello," name))
>
> I'm using Leiningen with project.clj:
>
> (defproject sample "1.0.0-SNAPSHOT"
>  :description "FIXME: write description"
>  :dependencies [[org.clojure/clojure "1.3.0"]]
>  :aot [sample.bar])
>
> When I run "lein compile", it creates three bar*.class files in C:\dev
> \vaadin\sample\classes\sample. My Java classpath (in Windows) is C:\dev
> \vaadin\sample.
>
> Thanks for your help.
>
> --
> 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: If a protocol creates a Java interface under the covers...

[Tassilo Horn]

"Jim - FooBar();"  writes:

> No what i have in IPiece is 'updatePosition' so each piece knows how
> to update its position.

Ok.

>> And when you say you have reflection warnings, can it be that you call a
>> protocol method foo with (.foo o) [note the .-syntax]...
> I'msure you will understand if you see the code:
>
> (defn move
> "The function responsible for moving Pieces. Each piece knows how to move
> itself. Returns the new board."
>  ^clojure.lang.LazySeq
> [^clojure.lang.Symbol game mappings ^Clondie24.core.IPiece p coords]
> {:pre [(satisfies? IPiece p)]}  ;safety comes first
> (if (in? mappings (vector-of-doubles coords)) ;check that position exists on
> the grid
> (do  (.update-position p coords) ;coords should be of the form [x, y]

What's update-position?  Shouldn't that be (updatePosition p coords), as
you say IPieces have an updatePosition method?  And since you use that
for side effects (you don't use the return value), are your IPiece
implementors actually deftypes with :volatile-mutable or
:unsynchronized-mutable fields?

You see, it's still far from clear to me. ;-)

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: If a protocol creates a Java interface under the covers...

[Tassilo Horn]

"Jim - FooBar();"  writes:

>>> If update-position is a protocol function just call it without the
>>> dot. Just like a normal function. Then any reflection will go away
>>> and no type hint is needed.
>>
>> WHAT??? Seriously??? I'll try it...
>
> OMG! You were right Meikel... I cannot believe this! I don't recall
> reading about this anywhere...

I already demonstrated this is my very first reply. ;-)

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: If a protocol creates a Java interface under the covers...

[Tassilo Horn]

"Jim - FooBar();"  writes:

>> And when you say you have reflection warnings, can it be that you call a
>> protocol method foo with (.foo o) [note the .-syntax]...
>
> I'm not sure what you mean...Of course I'm calling a protocol method with
> (.update-position p coords) - with the '.'
> How else can I call it?

Like demonstrated in my first reply.  `frobnicate` is a protocol method,
and you call it like an ordinary function.

,
| user> (defn frob1 [p] (frobnicate p))
| #'user/frob1
| user> (defn frob2 [^user.IPiece p] (frobnicate p))
| #'user/frob2
`

Also see http://www.clojure.org/Protocols

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

destructuring with :or

[Jay Fields]

Is there any reason that (let [[x y :or {x 1 y 2}] nil] [x y]) can't work?

-- 
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: Leiningen2 + lein-midje + lazytest question

[Phil Hagelberg]

On Mon, Jun 11, 2012 at 1:46 PM, Phil Hagelberg  wrote:
> On Mon, Jun 11, 2012 at 12:52 PM, Cédric Pineau  
> wrote:
>> My question is with the lazy-test dependency. Do I really have to put it as
>> a project dependency ?
>> It doesn't seem to be on the lein-midje path when puting it in the
>> dev-dependencies..
>
> If it's required for lein-midje then lein-midje should add it to your
> dependencies without you needing to do anything.

I should clarify that I know nothing about lein-midje in particular;
I'm just commenting on what the proper behaviour of plugins should 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

Re: Leiningen2 + lein-midje + lazytest question

[Daniel E. Renfer]

On 06/12/2012 12:05 PM, Phil Hagelberg wrote:

On Mon, Jun 11, 2012 at 1:46 PM, Phil Hagelberg  wrote:

On Mon, Jun 11, 2012 at 12:52 PM, Cédric Pineau  wrote:

My question is with the lazy-test dependency. Do I really have to put it as
a project dependency ?
It doesn't seem to be on the lein-midje path when puting it in the
dev-dependencies..

If it's required for lein-midje then lein-midje should add it to your
dependencies without you needing to do anything.

I should clarify that I know nothing about lein-midje in particular;
I'm just commenting on what the proper behaviour of plugins should be.

-Phil


The issue here is that Midje and lein-midje don't need Lazytest for 
normal operation, only for the --lazytest support. What would be the 
proper way to specify that dependency without requiring that everyone 
that uses Midje also carry around Lazytest?


I know the answer would probably be needing a lein-midje-lazytest 
artifact that adds that support, but that seems overkill.


--
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: Leiningen2 + lein-midje + lazytest question

[Phil Hagelberg]

On Tue, Jun 12, 2012 at 9:11 AM, Daniel E. Renfer  wrote:
> The issue here is that Midje and lein-midje don't need Lazytest for normal
> operation, only for the --lazytest support. What would be the proper way to
> specify that dependency without requiring that everyone that uses Midje also
> carry around Lazytest?

If you can determine whether you need it at launch time, you can just
conj another entry onto :dependencies when calling eval-in-project. If
it's unknown until runtime then that's another story.

-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

Re: How about 'nth' accepts maps?

[Yoshinori Kohyama]

Hi all,

Thank you for commenting, Chris and Meikel.

In my Clojure 1.3.0 REPL,
  (def sm (sorted-map 0 {:name "Alice"} 1 {:name "Bob"} 2 {:name 
"Charlie"}))
  (loop [c sm acc []]
(if-let [[k v] (first c)]
  (recur (next c) (conj acc (assoc v :id k)))
  acc))
returns
  [{:name "Alice", :id 0} {:name "Bob", :id 1} {:name "Charlie", :id 2}]
. And
  (nthnext sm 1)
returns
  ([1 {:name "Bob"}] [2 {:name "Charlie"}])
.
'first', 'next' and 'nthnext' look to accept a map for me.
Do I misunderstand something?

I only want to write an example above like:
  (loop [[k v :as x] & xs] sm acc []]
(if c (recur xs (conj acc (assoc v :id k))) acc))
.
And it can be done only if 'nth' accepts a map, by implementing 'nth' using 
'seq', 'first', 'next', 'loop' and 'recur' like 'nthnext' or 'my-nth' in 
the first post.
https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/clj/clojure/core.clj#L2747

Note that the example above is done without a loop, I know, and  I forced 
to use a loop for a demonstrative purpose.

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

[Kurt Harriger]

On Tuesday, June 12, 2012 2:18:03 AM UTC-6, Christophe Grand wrote:
>
> Hi,
>
> To contrast our experiences of the language and the different approaches 
> to deal with some problems:
>
> On Sun, Jun 10, 2012 at 4:47 AM, Kurt Harriger wrote:
>
>>  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.
>>
>
> Do you test only the functions or do you have also introduced "lint" 
> functions which check the shape of your data. To me, these are pretty 
> useful: you can use them in tests, pre/postconds, middlewares to guard 
> against untrusted sources etc. 
>
>
I do use pre-conditions where the test condition is simple, ie is this a 
string? does the map have a :field-type? however I get a lot of my input 
data from http requests as json which have similar structures but different 
semantics, so I often do not have preconditions where type is not 
explicit. For example a string could be an list id or a contact id or an 
encoded json document. While it is possible to try to parse a string for 
json to verify its type this is seems very computationally expensive and 
therefore usually inferred from the context. 

I also felt that explicit type checking went against the spirit of duck 
typing, there was a couple of times I added type checks only to realize 
that the type checking was to strict... ie nil was an acceptable value and 
now the code through an assertion error. In many cases a function simply 
takes the argument and passes it to another function, so I don't really 
care what type the argument is as long as there is an implementation of the 
other function which supports that data type, maybe it doesn't know but in 
the future maybe it will should my code unnecessarily constrain the type 
based on an implementation detail?  

I have never been truely sold on duck typing however as I often find the 
time I spend debugging exceptions thrown deep down in the call stack 
because an error that could have been caught earlier when the problem was 
obvious was allowed to penetrate deep into call stack where the problem is 
no longer obvious often within a third party library that never expected 
that type of input.  In OO the argument is an interface which says nothing 
about the structure of the object, only that it provides the desired 
behavior.  Protocols are a step in this direction, however, if you extend a 
protocol to a map then (satisfy? TheProtocol {}) will return true for ALL 
maps, making satisfies? an otherwise useless precondition.  

For example, my first contact model I had {... :fields [{:field-type 
 :email :value "" ...}]}  I later realized that the endpoint to get the 
contact information provided them grouped and I was filtering a lot based 
on field-type anyway so a more effective data structure was {:emails 
[{:value "" ...}]}, :field-type was just an implementation detail, the 
email object still has a value and associated behavior but the map no 
longer contains a :field-type.  However, phone numbers have exactly the 
same {:value ""} structure so the only way to determine if it is an email 
or a phone number is from context or by parsing the string.


 
>
>> 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. 
>>
>
> Basically you are returning a "lazy map" a map of keys to delayed values 
> (why not use delays instead of fns as values?), while it is sometimes a 
> necessity to do so, the implied trade-off must not be overlooked: the map 
> can't be treated as a value anymore: if you call twice the pure function 
> which generates such a lazy map twice with the same arguments, you get two 
> lazy maps which are not equals! I'm not even speaking about being equal to 
> their non-lazy counterparts (which makes them a bit harder to test)
>

This is an excellent point. Initially I started passing maps of functions 
into other functions as optional parameter map for testing (new-correction 
[ & {:keys [get-current-date] :or [get-current-date get-current-date]). 
  This solved one problem but created others, the function was

Exclude some dependencies with lein uberjar

[Warren Lynn]

Hi,

As titled, I need to exclude certain dependencies from my final .jar
file (because those dependencies will already be there in the final
target Java environment). How can I do that? Thank you.

PS: I am using Leinengen 2

-- 
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: Exclude some dependencies with lein uberjar

[Phil Hagelberg]

On Tue, Jun 12, 2012 at 9:59 AM, Warren Lynn  wrote:
> As titled, I need to exclude certain dependencies from my final .jar
> file (because those dependencies will already be there in the final
> target Java environment). How can I do that? Thank you.

The uberjar task is designed to create jars meant for standalone
distribution. If you're deploying them to some other environment then
you might want a different plugin or something.

-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

Re: Exclude some dependencies with lein uberjar

[Jacek Laskowski]

On Tue, Jun 12, 2012 at 6:59 PM, Warren Lynn  wrote:

> As titled, I need to exclude certain dependencies from my final .jar
> file (because those dependencies will already be there in the final
> target Java environment). How can I do that? Thank you.

I'm trying to figure out where you're heading with the requirement (I
wish I had stated it more politely :)).

As the name says uberjar is what you should be able to run with no
worries about the classpath - all deps are included in the final jar.
Since you asked to exclude some deps, you likely run the final jar in
a kind of managed environment. Why are there some deps not the others?
What drives the exclusion? Wouldn't lein jar alone be enough? Why?
Just curious and try to understand what you've already done :)

Jacek

-- 
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

-- 
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: If a protocol creates a Java interface under the covers...

[Alan Malloy]

On Jun 12, 5:56 am, "Jim - FooBar();"  wrote:
> On 12/06/12 13:53, Jim - FooBar(); wrote:
>
> > On 12/06/12 13:47, Meikel Brandmeyer (kotarak) wrote:
> >> If update-position is a protocol function just call it without the
> >> dot. Just like a normal function. Then any reflection will go away
> >> and no type hint is needed.
>
> > WHAT??? Seriously??? I'll try it...
>
> > Jim
>
> OMG! You were right Meikel... I cannot believe this! I don't recall
> reading about this anywhere...

It's not just less convenient, but genuinely incorrect to use dot-
notation for protocol functions. Not every class that satisfies the
protocol will be implementing the interface directly, and so dot-
notation will fail on them. The interface generated by defprotocol
exists primarily to allow the compiler to optimize certain cases, not
because it's an interface your application should be using.

-- 
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: Classpath problem with Java interop and Leiningen

[Sean Corfield]

On Mon, Jun 11, 2012 at 11:50 PM, Denis Vulinovich
 wrote:
>                RT.loadResourceScript("bar.clj");

You talk about putting the .class files on your classpath (modulo the
correction to add the classes subdirectory as Jacek noted) but you are
trying to load a source file (from the classpath).

Here's what works for me:
* add the src path (in your Leiningen project) to your classpath
* load a namespace like this: RT.var( "clojure.core", "load" ).invoke(
"/sample/bar" );
* obtain a reference to the hello function as before:
>                Var foo = RT.var("sample.bar", "hello");

You don't need to compile Clojure to .class files in order to be able
to load it into your Java code - it will be compiled on the fly.

As your Clojure code grows and depends on other libraries, you'll need
to ensure those are also on your classpath (lib/*.jar from your
Leiningen project).
-- 
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: Classpath problem with Java interop and Leiningen

[Jacek Laskowski]

On Tue, Jun 12, 2012 at 8:41 PM, Sean Corfield  wrote:

> As your Clojure code grows and depends on other libraries, you'll need
> to ensure those are also on your classpath (lib/*.jar from your
> Leiningen project).

lein2 doesn't use lib/* anymore. All's in ~/.m2/repository. You need
the classpath? Use lein2 classpath.

Jacek

-- 
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

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

so why it has to be so complicated / Longest Increasing Sub-Seq

[Andy Coolware]

Hi,

First a quick disclaimer. Those are my first steps in Clojure so I am
not be super accustomed to the language entire landscape and might
miss some basics here. However I was able to solve my first 4clojure
hard problem https://www.4clojure.com/problem/53 and have some second
thoughts after looking up top contributor's solutions as well as mine.
Why it has to be so complicated???

Conceptually, you just reduce the list to list of lists using a simple
condition < . Then you filter items longer then 1. And at the same
time you reduce the output to a first longest list. In this case,
stack for recursion is really not required, although I did use it in
my solution since I could figure out the "reduction" based way to
partition the source sequence.

It also seems that imperative solution would be quite straightforward
although maintaining at least 4 state variables is not compelling at
all. Bottom line, I want to have a idiomatic Clojure solution ... Any
insight 

Thx,
Andy

-- 
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: destructuring with :or

[Tassilo Horn]

Jay Fields  writes:

Hi Jay,

> Is there any reason that (let [[x y :or {x 1 y 2}] nil] [x y]) can't
> work?

:or is only supported for map destructuring but you use sequence
destructuring.

user> (map #(let [{x :x, y :y :or {x 1, y 2}} %1]
  [x y])
   [{} {:x 17, :y 3} {:y 1}])
([1 2] [17 3] [1 1])

Well, you can use map destructuring also for vectors, because those are
associatives of their indexes.  However, then the :or doesn't seem to
work as expected.  Not sure if I'm doing something wrong or if it's
really not supported.  In the latter case, maybe an exception was
justified.

user> (map #(let [{x 0 y 1 :or {0 -1, 1 -2}} %1]
 [x y])
   [[] [10] [10 11]])
([nil nil] [10 nil] [10 11])

I had expected it to return ([-1 -2] [10 -2] [10 11]).

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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

On 12/06/12 14:43, Tassilo Horn wrote:

"Jim - FooBar();"  writes:


If update-position is a protocol function just call it without the
dot. Just like a normal function. Then any reflection will go away
and no type hint is needed.

WHAT??? Seriously??? I'll try it...

OMG! You were right Meikel... I cannot believe this! I don't recall
reading about this anywhere...

I already demonstrated this is my very first reply. ;-)

Bye,
Tassilo



Yes, but I was under the impression that it made no difference whether 
you call it with the '.' or not...I was just calling with '.' just to 
show that there actually exists a java class underneath but i never 
expected that loosing the dot would erase reflection warnings! that's 
what I meant...



What's update-position?  Shouldn't that be (updatePosition p coords), as
you say IPieces have an updatePosition method?  And since you use that
for side effects (you don't use the return value), are your IPiece
implementors actually deftypes with :volatile-mutable or
:unsynchronized-mutable fields?


No, my IPiece implementors are records  that hold a java.awt.Point 
object. This is indeed the only piece of mutable state in the whole 
namespace. (updatePosition p coords) will simply call 'setLocation()' on 
the Point of p. Are you saying that my defrecords should be deftypes? if 
yes, can you elaborate?



You see, it's still far from clear to me


better now? the project is on github in case you want to have a look -> 
Clondie24.core


any suggestions are welcome... I have to say I needed far less 
type-hints to get rid of reflection than I originally thought!


 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: If a protocol creates a Java interface under the covers...

[Jim - FooBar();]

On 12/06/12 19:41, Alan Malloy wrote:

It's not just less convenient, but genuinely incorrect to use dot-
notation for protocol functions. Not every class that satisfies the
protocol will be implementing the interface directly, and so dot-
notation will fail on them. The interface generated by defprotocol
exists primarily to allow the compiler to optimize certain cases, not
because it's an interface your application should be using.


Hmmm...that sort of makes sense but i wasn't planning on implementing 
the protocol outside the current namespace - only consuming its 
implementors. Perhaps from a java program - that is why I gave java-like 
names to my methods and overrode toString from object on my records. The 
original confusion arose from the fact that I wanted to pass IPiece as 
argument to avoid reflection which is not needed after all!


Within the definition of a record is it again recommended to call 
methods without the dot? for example is this completely wrong? (notice 
"(.getGridPosition this)" and (.getListPosition this))


(defrecord ChessPiece [^java.awt.Image image
   ^java.awt.Point position
rank ^Integer value]
 Piece
 (update-position [this np] ;mutable state inside Point!
   (.setLocation position   ;can accept ints or doubles
^double (first np) ^double (second np))) ;np should be [x, y]
 (die [this] (vary-meta this assoc :dead true)) ;communicate death 
through meta-data
 (promote [this] (make-chessItem image position :chess? true :rank 
'queen)) ;a pawn is promoted to a queen

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

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



Thanks everyone for your precious time...


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: Basic vector assoc

[Gabo]

Hello,

thank you very much for your answer, it is exactly what I was looking for !

Le vendredi 8 juin 2012 13:35:36 UTC+2, Gabo a écrit :
>
> Hello,
>
> I'm a beginner with Clojure and trying some basic stuff.
> I'm actually working on a simple function which would replace the nth 
> element of a vector.
>
> I'm using this function
>
> (def ids-in-use (ref [1 2 3]))
> (defn update-vector [v tid]
> (assoc v tid 10))
> (update-ids-in-use [2])
>
> The problem is that tid is not recognized as an Integer. I suppose I'm 
> doing it the right way, functional programming is new for me.
> My idea here is to parametrize the position where the assoc has to be done.
>
> I'm also looking for basic code examples to learn that kind of basic stuff.
>
> Thank you for your help.
>

-- 
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: core.logic for encoding the rules of chess or checkers? is it plausible/desirable ?

[Jim - FooBar();]

Hi Marek,

I did what you said and I translated the prolog code to core.logic. Your 
2 examples helped a lot and thanks again for that. The versionI've got 
now is this:

---
(defn knight-moves [x y]
(let [xmax 8 ymax 8]
 (run* [q] ;bring back all possible solutions
 (fresh [a b]
  (conde
[(< (+ x 1) xmax) (< (+ y 2) ymax) (== a (+ x 1)) (== b (+ y 2))] 
;1st possibility
[(< (+ x 2) xmax) (< (+ y 1) ymax) (== a (+ x 2)) (== b (+ y 1))] 
;2nd possibility
[(< (+ x 2) xmax) (>= (- y 1)   0) (== a (+ x 2)) (== b (- y 1))] 
;3rd possibility
[(< (+ x 1) xmax) (>= (- y 2)   0) (== a (+ x 1)) (== b (- y 2))] 
;4th possibility
[(>= (- x 1)   0) (>= (- y 2)   0) (== a (- x 1)) (== b (- y 2))] 
;5th possibility
[(>= (- x 2)   0) (>= (- y 1)   0) (== a (- x 2)) (== b (- y 1))] 
;6th possibility
[(>= (- x 2)   0) (< (+ y 1) ymax) (== a (- x 2)) (== b (+ y 1))] 
;7th possibility
[(>= (- x 1)   0) (< (+ y 2) ymax) (== a (+ x 1)) (== b (+ y 2))] 
;8th possibility

  )
   (== q [a b]))   ;return each solution as a vector [x, y]
)))


However now I get:
 ClassCastException java.lang.Boolean cannot be cast to clojure.lang.IFn
on the first clause! Is this what you meant that I need to define my own 
"greather than" and "lower than" operators? I'm suspecting that is 
exactly what you meant cos there is something definately missing! Why 
won't clojure's operators do the job? I'm just checking arithmetic 
values...what is the problem?


Jim

On 11/06/12 17:34, David Nolen wrote:
On Mon, Jun 11, 2012 at 12:30 PM, mnicky > wrote:


You can probably substitute the "is" operator of Prolog with the
"==" operator of core.logic, but very likely you will have to
define your own "greather than" and "lower than" operators...


Marek.


There is an arithmetic namespace that has these non-relational 
operators. I've started working on cKanren extensions again so the 
story around arithmetic should improve a lot in the next couple of weeks.


David

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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en 


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: core.logic for encoding the rules of chess or checkers? is it plausible/desirable ?

[Jim - FooBar();]

Nevermind...I found the namespace with these non-relational operators 
and the code works like a charm!!! I am so happy... :-)


Jim


On 12/06/12 22:18, Jim - FooBar(); wrote:

Hi Marek,

I did what you said and I translated the prolog code to core.logic. 
Your 2 examples helped a lot and thanks again for that. The 
versionI've got now is this:

---
(defn knight-moves [x y]
(let [xmax 8 ymax 8]
 (run* [q] ;bring back all possible solutions
 (fresh [a b]
  (conde
[(< (+ x 1) xmax) (< (+ y 2) ymax) (== a (+ x 1)) (== b (+ y 2))] 
;1st possibility
[(< (+ x 2) xmax) (< (+ y 1) ymax) (== a (+ x 2)) (== b (+ y 1))] 
;2nd possibility
[(< (+ x 2) xmax) (>= (- y 1)   0) (== a (+ x 2)) (== b (- y 1))] 
;3rd possibility
[(< (+ x 1) xmax) (>= (- y 2)   0) (== a (+ x 1)) (== b (- y 2))] 
;4th possibility
[(>= (- x 1)   0) (>= (- y 2)   0) (== a (- x 1)) (== b (- y 2))] 
;5th possibility
[(>= (- x 2)   0) (>= (- y 1)   0) (== a (- x 2)) (== b (- y 1))] 
;6th possibility
[(>= (- x 2)   0) (< (+ y 1) ymax) (== a (- x 2)) (== b (+ y 1))] 
;7th possibility
[(>= (- x 1)   0) (< (+ y 2) ymax) (== a (+ x 1)) (== b (+ y 2))] 
;8th possibility

  )
   (== q [a b]))   ;return each solution as a vector [x, y]
)))


However now I get:
 ClassCastException java.lang.Boolean cannot be cast to clojure.lang.IFn
on the first clause! Is this what you meant that I need to define my 
own "greather than" and "lower than" operators? I'm suspecting that is 
exactly what you meant cos there is something definately missing! Why 
won't clojure's operators do the job? I'm just checking arithmetic 
values...what is the problem?


Jim

On 11/06/12 17:34, David Nolen wrote:
On Mon, Jun 11, 2012 at 12:30 PM, mnicky > wrote:


You can probably substitute the "is" operator of Prolog with the
"==" operator of core.logic, but very likely you will have to
define your own "greather than" and "lower than" operators...


Marek.


There is an arithmetic namespace that has these non-relational 
operators. I've started working on cKanren extensions again so the 
story around arithmetic should improve a lot in the next couple of weeks.


David

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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en 




--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: Exclude some dependencies with lein uberjar

[Warren Lynn]

> As the name says uberjar is what you should be able to run with no 
> worries about the classpath - all deps are included in the final jar. 
> Since you asked to exclude some deps, you likely run the final jar in 
> a kind of managed environment. Why are there some deps not the others? 
> What drives the exclusion? Wouldn't lein jar alone be enough? Why? 
> Just curious and try to understand what you've already done :) 
>
>
I plan to deploy the jar as a lib in another Java framework. This clojure 
.jar file depends on some common lib (API kind of thing) that will be 
included in the Java framework itself so I don't want to include another 
copy.

"uberjar" might not be the right command (BTW: i don't know what that name 
means), but is there any way to do it, without manually pick-and-package? 
Thanks.

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

Re: Exclude some dependencies with lein uberjar

[Phil Hagelberg]

On Tue, Jun 12, 2012 at 3:00 PM, Warren Lynn  wrote:
> I plan to deploy the jar as a lib in another Java framework. This clojure
> .jar file depends on some common lib (API kind of thing) that will be
> included in the Java framework itself so I don't want to include another
> copy.
>
> "uberjar" might not be the right command (BTW: i don't know what that name
> means), but is there any way to do it, without manually pick-and-package?
> Thanks.

If you don't need AOT then you can include the common lib in
dependencies in the :dev profile.

If you need AOT then you'll have to write a plugin that works like a
more selective variant of uberjar.

-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

Re: destructuring with :or

[Sean Corfield]

On Tue, Jun 12, 2012 at 12:28 PM, Tassilo Horn  wrote:
> user> (map #(let [{x 0 y 1 :or {0 -1, 1 -2}} %1]
>             [x y])
>           [[] [10] [10 11]])
> ([nil nil] [10 nil] [10 11])
>
> I had expected it to return ([-1 -2] [10 -2] [10 11]).

It needs to be this:

user=> (map #(let [{x 0 y 1 :or {x -1 y -2}} %]
 [x y])
[ [] [10] [10 11] [10 11 12] ])

([-1 -2] [10 -2] [10 11] [10 11])
-- 
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: Central screwup

[Phil Hagelberg]

On Mon, Jun 11, 2012 at 1:48 PM, Phil Hagelberg  wrote:
> On Mon, Jun 11, 2012 at 9:36 AM, Phil Hagelberg  wrote:
>> These will be removed once Central gets back to working order, but
>> they should help stem the flow of catastrophic build failures.
>
> While this will allow most builds to work, it's a band-aid solution.
> Is there anyone on the Clojure/core team with a contact among those
> who run Central who could get them to look into this?

Central is back to normal, so I've removed the workaround jars on Clojars.

-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

Re: destructuring with :or

[Jay Fields]

right, I know it's possible to do what you guys are describing. What I meant to 
ask is, should :or be allowed in destructuring vectors? I can't see any reason 
for it not to be allowed.

On Jun 12, 2012, at 7:10 PM, Sean Corfield wrote:

> On Tue, Jun 12, 2012 at 12:28 PM, Tassilo Horn  wrote:
>> user> (map #(let [{x 0 y 1 :or {0 -1, 1 -2}} %1]
>> [x y])
>>   [[] [10] [10 11]])
>> ([nil nil] [10 nil] [10 11])
>> 
>> I had expected it to return ([-1 -2] [10 -2] [10 11]).
> 
> It needs to be this:
> 
> user=> (map #(let [{x 0 y 1 :or {x -1 y -2}} %]
> [x y])
>[ [] [10] [10 11] [10 11 12] ])
> 
> ([-1 -2] [10 -2] [10 11] [10 11])
> -- 
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> 
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: Exclude some dependencies with lein uberjar

[Warren Lynn]

If you don't need AOT then you can include the common lib in 

> dependencies in the :dev profile. 
>
> If you need AOT then you'll have to write a plugin that works like a 
> more selective variant of uberjar. 
>
> -Phil 
>

I do need AOT, and I am not ready yet to write any plugins. Maybe I can 
find some tools to remove the unwanted jars after "lein uberjar", just 
another thought.
 

-- 
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: If a protocol creates a Java interface under the covers...

[Softaddicts]

The dot firm is an explicit call to interop. Protocols are a clojure concept :)
The underlying mechanism happens to look like a Java interface today.
However you can expect to bypass some niceties by doing this.

This is what the JVM offers today to implementors. Might be different in
future releases of the JVM.

Luc P.


> On 12/06/12 14:43, Tassilo Horn wrote:
> > "Jim - FooBar();"  writes:
> >
>  If update-position is a protocol function just call it without the
>  dot. Just like a normal function. Then any reflection will go away
>  and no type hint is needed.
> >>> WHAT??? Seriously??? I'll try it...
> >> OMG! You were right Meikel... I cannot believe this! I don't recall
> >> reading about this anywhere...
> > I already demonstrated this is my very first reply. ;-)
> >
> > Bye,
> > Tassilo
> >
> 
> Yes, but I was under the impression that it made no difference whether 
> you call it with the '.' or not...I was just calling with '.' just to 
> show that there actually exists a java class underneath but i never 
> expected that loosing the dot would erase reflection warnings! that's 
> what I meant...
> 
> > What's update-position?  Shouldn't that be (updatePosition p coords), as
> > you say IPieces have an updatePosition method?  And since you use that
> > for side effects (you don't use the return value), are your IPiece
> > implementors actually deftypes with :volatile-mutable or
> > :unsynchronized-mutable fields?
> 
> No, my IPiece implementors are records  that hold a java.awt.Point 
> object. This is indeed the only piece of mutable state in the whole 
> namespace. (updatePosition p coords) will simply call 'setLocation()' on 
> the Point of p. Are you saying that my defrecords should be deftypes? if 
> yes, can you elaborate?
> 
> > You see, it's still far from clear to me
> 
> better now? the project is on github in case you want to have a look -> 
> Clondie24.core
> 
> any suggestions are welcome... I have to say I needed far less 
> type-hints to get rid of reflection than I originally thought!
> 
>   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
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
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: so why it has to be so complicated / Longest Increasing Sub-Seq

[Benny Tsai]

This is what I ended up with, which I think is relatively clear and 
straightforward (but then, I'm not entirely unbiased :)

The algorithm is very close to what you described.

- Generate all sub-sequences of length > 1
- Filter to keep only increasing subsequences
- Tack on the empty sequence, which is what needs to be returned if there 
are no increasing sub-sequences
- Sort by length in descending order
- Take the first (longest)

(fn [coll]
   (let [increasing? (fn [xs] (apply < xs))
 n (count coll)
 sub-seqs (mapcat #(partition % 1 coll) (range 2 (inc n)))]
 (->> sub-seqs
  (filter increasing?)
  (cons [])
  (sort-by count >)
  first)))

On Tuesday, June 12, 2012 12:11:07 PM UTC-7, Andy C wrote:
>
> Hi, 
>
> First a quick disclaimer. Those are my first steps in Clojure so I am 
> not be super accustomed to the language entire landscape and might 
> miss some basics here. However I was able to solve my first 4clojure 
> hard problem https://www.4clojure.com/problem/53 and have some second 
> thoughts after looking up top contributor's solutions as well as mine. 
> Why it has to be so complicated??? 
>
> Conceptually, you just reduce the list to list of lists using a simple 
> condition < . Then you filter items longer then 1. And at the same 
> time you reduce the output to a first longest list. In this case, 
> stack for recursion is really not required, although I did use it in 
> my solution since I could figure out the "reduction" based way to 
> partition the source sequence. 
>
> It also seems that imperative solution would be quite straightforward 
> although maintaining at least 4 state variables is not compelling at 
> all. Bottom line, I want to have a idiomatic Clojure solution ... Any 
> insight  
>
> Thx, 
> Andy 
>

-- 
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: so why it has to be so complicated / Longest Increasing Sub-Seq

[Andy Coolware]

Nice. But I wonder if sorting and (count coll) actually forces the
algorithm to load everything into memory. My Clojure solution is more
convoluted (will post it later) and suffers the same due to a
recursive algorithm doing the transformation I described at  the end.

However I think I have something more compact and very readable in
Scala I wrote aferwords. And this reads the input sequence as needed:

List[Int](6, 7, 8, 1, 2, 3, 4, 1, 11, 10 ,11 ,12 ,13,
3).foldLeft(List[List[Int]]()){(a,b)=>
  if(a.isEmpty) List(List(b))
  else if(a.last.last < b) a.dropRight(1):::List(a.last:+b)
  else a:::List(List(b))
  }.filter(_.length>1).foldLeft(List[Int]()){(a,b)=>if(a.length>=b.length)
a else b}

I do not mean to rant here or anything, it is more like I have problem
expressing in Clojure this transformation:

(6, 7, 8, 1, 2, 3, 4, 1, 11, 10 ,11 ,12 ,13, 3) => ((6, 7, 8), (1, 2,
3, 4), (1, 11), (10, 11, 12, 13), (3)) in a nonrecursive way as well
as that I do not have to read entire sequence into a memory ...

hmm...

-- 
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: so why it has to be so complicated / Longest Increasing Sub-Seq

[Andy Coolware]

forgot full listing:


scala> List[Int](6, 7, 8, 1, 2, 3, 4, 1, 11, 10 ,11 ,12 ,13,
 | 3).foldLeft(List[List[Int]]()){(a,b)=>
 |  if(a.isEmpty) List(List(b))
 |  else if(a.last.last < b) a.dropRight(1):::List(a.last:+b)
 |  else a:::List(List(b))
 |  
}.filter(_.length>1).foldLeft(List[Int]()){(a,b)=>if(a.length>=b.length)
 | a else b}
res0: List[Int] = List(1, 2, 3, 4)

-- 
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: If a protocol creates a Java interface under the covers...

[Michał Marczyk]

On 12 June 2012 14:28, Jim - FooBar();  wrote:
> Of course, I Just noticed that type-hinting 'p' renders the precondition
> useless...an extra performance bonus!

Not really -- only primitive type hints actually prevent the function
from accepting a non-matching argument:

(defn foo [^java.util.Map x] x)

(foo #{})
;= #{}

(defn foo [x]
  {:pre [(instance? java.util.Map x)]}
  x)

(foo #{})
; AssertionError

M.

-- 
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: If a protocol creates a Java interface under the covers...

[Michał Marczyk]

On 12 June 2012 22:00, Jim - FooBar();  wrote:
> On 12/06/12 19:41, Alan Malloy wrote:
>>
>> It's not just less convenient, but genuinely incorrect to use dot-
>> notation for protocol functions. Not every class that satisfies the
>> protocol will be implementing the interface directly, and so dot-
>> notation will fail on them. The interface generated by defprotocol
>> exists primarily to allow the compiler to optimize certain cases, not
>> because it's an interface your application should be using.
>
>
> Hmmm...that sort of makes sense but i wasn't planning on implementing the
> protocol outside the current namespace - only consuming its implementors.
> Perhaps from a java program - that is why I gave java-like names to my
> methods and overrode toString from object on my records. The original
> confusion arose from the fact that I wanted to pass IPiece as argument to
> avoid reflection which is not needed after all!

If convenience of calling into your code from Java is important, you
might want to investigate definterface -- it accepts type hints for
parameters and return values (attached to the method name in the
latter case) and it actually promises to create an interface.

M.

-- 
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: If a protocol creates a Java interface under the covers...

[Michał Marczyk]

On 13 June 2012 06:34, Michał Marczyk  wrote:
> Not really -- only primitive type hints actually prevent the function
> from accepting a non-matching argument:

Should have added a primitive hint example:

(defn foo [^long x] x)

(foo {})
; ClassCastException

M.

-- 
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: destructuring with :or

[Tassilo Horn]

Sean Corfield  writes:

>> user> (map #(let [{x 0 y 1 :or {0 -1, 1 -2}} %1]
>>             [x y])
>>           [[] [10] [10 11]])
>> ([nil nil] [10 nil] [10 11])
>>
>> I had expected it to return ([-1 -2] [10 -2] [10 11]).
>
> It needs to be this:
>
> user=> (map #(let [{x 0 y 1 :or {x -1 y -2}} %]
>  [x y])
> [ [] [10] [10 11] [10 11 12] ])
>
> ([-1 -2] [10 -2] [10 11] [10 11])

Ah, yes.  Thanks a lot.

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: core.logic for encoding the rules of chess or checkers? is it plausible/desirable ?

[mnicky]

Great!


On Tuesday, June 12, 2012 11:32:11 PM UTC+2, Jim foo.bar wrote:
>
>  Nevermind...I found the namespace with these non-relational operators and 
> the code works like a charm!!! I am so happy... :-) 
>
> Jim
>
>
> On 12/06/12 22:18, Jim - FooBar(); wrote: 
>
> Hi Marek,
>
> I did what you said and I translated the prolog code to core.logic. Your 2 
> examples helped a lot and thanks again for that. The versionI've got now is 
> this: 
>
> ---
> (defn knight-moves [x y]
> (let [xmax 8 ymax 8]
>  (run* [q] ;bring back all possible solutions
>  (fresh [a b]
>   (conde 
> [(< (+ x 1) xmax) (< (+ y 2) ymax) (== a (+ x 1)) (== b (+ y 2))] ;1st 
> possibility
> [(< (+ x 2) xmax) (< (+ y 1) ymax) (== a (+ x 2)) (== b (+ y 1))] ;2nd 
> possibility
> [(< (+ x 2) xmax) (>= (- y 1)   0) (== a (+ x 2)) (== b (- y 1))] ;3rd 
> possibility
> [(< (+ x 1) xmax) (>= (- y 2)   0) (== a (+ x 1)) (== b (- y 2))] ;4th 
> possibility
> [(>= (- x 1)   0) (>= (- y 2)   0) (== a (- x 1)) (== b (- y 2))] ;5th 
> possibility
> [(>= (- x 2)   0) (>= (- y 1)   0) (== a (- x 2)) (== b (- y 1))] ;6th 
> possibility
> [(>= (- x 2)   0) (< (+ y 1) ymax) (== a (- x 2)) (== b (+ y 1))] ;7th 
> possibility
> [(>= (- x 1)   0) (< (+ y 2) ymax) (== a (+ x 1)) (== b (+ y 2))] ;8th 
> possibility
>   ) 
>(== q [a b]))   ;return each solution as a vector [x, y]
> )))
>
> 
>
> However now I get:
>  ClassCastException java.lang.Boolean cannot be cast to clojure.lang.IFn 
> on the first clause! Is this what you meant that I need to define my own 
> "greather than" and "lower than" operators? I'm suspecting that is exactly 
> what you meant cos there is something definately missing! Why won't 
> clojure's operators do the job? I'm just checking arithmetic values...what 
> is the problem?
>
> Jim
>
> On 11/06/12 17:34, David Nolen wrote: 
>
> On Mon, Jun 11, 2012 at 12:30 PM, mnicky  wrote:
>  
>> You can probably substitute the "is" operator of Prolog with the "==" 
>> operator of core.logic, but very likely you will have to define your own 
>> "greather than" and "lower than" operators...
>>
>>  
>>  Marek.
>>  
>
>  There is an arithmetic namespace that has these non-relational 
> operators. I've started working on cKanren extensions again so the story 
> around arithmetic should improve a lot in the next couple of weeks.
>
>  David 
>  
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
>
>
>  
>  

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: destructuring with :or

[Tassilo Horn]

Jay Fields  writes:

> right, I know it's possible to do what you guys are describing. What I
> meant to ask is, should :or be allowed in destructuring vectors? I
> can't see any reason for it not to be allowed.

Hm, yes, I could think of these semantics, i.e., fill missing indices
with the values given by the :or vector.

(map #(let [[x y & more :or [1 2 3 4]] %1]
(apply vector x y more))
 [[2 3 4 5]
  [nil nil nil nil]
  [2 3 4]
  [nil 3]
  [nil 2 nil]
  [5]
  []]
;=> [[2 3 4 5]
 [nil nil nil nil]
 [2 3 4]
 [1 3 3 4]
 [1 2 nil]
 [5 2 3 4]
 [1 2 3 4]]

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