Re: Problem filtering with definline'd function
So this has just happened to me again:
Clojure 1.5.1
(plugin.psi/symbol? 2)
= false
(filter plugin.psi/symbol? [1 2 3])
= (1 2 3)
((var-get #'plugin.psi/symbol?) 2)
= (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
What that looks like to me is that the macro fn (i.e. the one that is
usually in the :inline meta) is being stored in the var. So when it's used
by filter, it always returns true. Does anyone have any idea what else I
could try to debug this? I'll leave the REPL session open so I can try any
suggestions.
I just tried this, looks like the fns are not the same, at least, but they
do have the same effect:
(meta #'plugin.psi/symbol?)
= {:inline plugin.psi$symbol_QMARK_@3781ff7f, :ns plugin.psi, :name
symbol?, :arglists ([element]), :column 1, :line 35, :file plugin/psi.clj}
(= plugin.psi/symbol?
(:inline (meta #'plugin.psi/symbol?)))
= false
plugin.psi/symbol?
= plugin.psi$symbol_QMARK_@4ccc75ae
((:inline (meta #'plugin.psi/symbol?)) 2)
= (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
On 20 June 2013 22:48, Colin Fleming colin.mailingl...@gmail.com wrote:
ClSymbol is a Java class. I don't get the replacement warning because I've
excluded that symbol explicitly in my ns declaration using :refer-clojure
:exclude.
I haven't done a 'lein clean' because I'm not using lein, but I have
rebuilt various times. However, sometimes it will work and sometimes it
won't. I just tried this now, and I've been unable to reproduce. I guess
I'll keep working tomorrow and see if it crops up again. If I see it again
I'm going to try ((var-get #'symbol?) 2) to see if the results from the
function differ from the macroexpanded version.
On 20 June 2013 22:21, Jim - FooBar(); jimpil1...@gmail.com wrote:
On 20/06/13 10:59, Colin Fleming wrote:
Because this tests for something different - that the element is an
instance of ClSymbol. It's not testing the same thing as the core version.
I qualify it (psi/symbol? in the examples above) to distinguish it from the
core one.
Basically, I'm trying to use definline to allow me to have a more
Clojure-y API without having the performance hit of tons of tiny function
calls.
I agree that this is unlikely to be a bug in Clojure and is probably
something I'm missing, but I can't figure it out.
right I see...so if ClSymbol is a defrecord/deftype I don't see anything
wrong with your code...when you do (in-ns 'plugin.psi) do you get a warning
that core/symbol? is being replaced by psi/symbol? ?
what you tried on your repl works fine on mine:
user= (defrecord FOO [a])
user.FOO
user= (definline foo? [e]
#_= `(instance? FOO ~e))
#'user/foo?
user= (foo? 2)
false
user= (filter foo? [1 2 3])
()
user= (filter foo? [(FOO. 1) 2 3])
(#user.FOO{:a 1})
Did you try 'lein clean' to get rid of already compiled classes? I'm
suspecting you have different versions of the same class lying around
because of what you said about compiling and recompiling...
Jim
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
--- You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to
clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Function returns nil
Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
Only use 'doseq' when you don't care about the reuturn value. In other words only for side-effect-y code. Use 'for' instead... Jim On 21/06/13 11:17, Jay C wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
On 21 June 2013 11:17, Jay C ubuntu...@gmail.com wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) doseq returns nil, it's for side effecting code. If you want a return value you should use loop or something else that doesn't have side effects. Alan -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
(clojure 1.5.1) Weird performance results when using let versus def for variable
Hi all,
I am doing some (naive and trivial) performance tests before deciding
whether and how to use Clojure for some performance critical number
cruching and I wanted help understanding the behaviour.
I am defining an array inside a function, setting the contents to be 1 and
then summing them up (by areducing) them (I chose 1 instead of a random
number for consistency, obviously the contents will be different otherwise
it would all reduce to (n) :)). If I 'let' the array then it is factors of
10 faster than if I def the array.
The relevant code
(https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
[code]
(ns inc
(:gen-class))
(defn- inc-atom [n]
(def x (atom 0))
(dotimes [n n] (swap! x inc))
@x)
(defn- array-let [n]
(let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i)
(defn- array-def [n]
(def a (int-array n))
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i
(defn- run-test [subject n]
(time (do (def x (subject n)) (println x
(defn -main [ args]
(let [n 100]
(println inc atom)
(run-test inc-atom n)
(println array with let)
(run-test array-let n)
(println array with def)
(run-test array-def n))
)
[/code]
Interestingly, if I refactored an 'execute-on-array' def which array-let
and array-def delegated to then they had the same performance which seems
to imply it is about scoping, but the array in both array-let and array-def
have exactly the same scope... Setting the autoboxing warning to true
didn't point out anything either.
The output (from my VM, so a bit slow):
[code]
inc atom
100
Elapsed time: 213.214118 msecs
array with let
100
Elapsed time: 75.302602 msecs
array with def
100
Elapsed time: 12868.970203 msecs
[/code]
For comparison, the following java code:
[code]
package perf;
public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; in; i++) counter++;
long end = System.currentTimeMillis();
System.out.println (Naive + (end - start) + ms, counter is +
counter);
counter = 0;
int[] arr = new int[n];
start = System.currentTimeMillis();
for (int i=0; iarr.length; i++) arr[i]=1;
for (int i=0; iarr.length; i++) counter = counter + arr[i];
end = System.currentTimeMillis();
System.out.println (Array + (end - start) + ms, counter is +
counter);
}
}
[/code]
produces the (as expected, much faster) results :
[code]
Naive 3 ms, counter is 100
Array 6 ms, counter is 100
[/code]
I am not surprised that the atom/inc takes much longer than 3 ms, but I
don't understand why the array solution is so much more expensive in
Clojure?
On a related point - can anyone provide a faster implementation of summing
up the contents of an array?
A lein project can be found https://github.com/yatesco/clojure-perf, 'lein
uberjar; java -jar target/*.jar should demonstrate the output.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
fastest way to produce a PersistentList
Hi all, what do you guys do when you want to map a fn over a list but you want to produce a list as the result (not vector or lazy-seq). What is the fastest way of doing this? My first attempt was this: (- (mapv f coll) rseq ;;reverse fast (into '())) but I quickly realised that lists do not have transient counterparts. Therefore, the call to 'into' will be slow...in addition, I'm performing 2 passes with this... any ideas? Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
If you use for, which is lazy, wrap it in a doall to force it to do its work before with-open closes your reader. On Jun 21, 2013 6:52 AM, Jim jimpil1...@gmail.com wrote: Only use 'doseq' when you don't care about the reuturn value. In other words only for side-effect-y code. Use 'for' instead... Jim On 21/06/13 11:17, Jay C wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: fastest way to produce a PersistentList
(apply list the-seq) seems to work, but (list* the-seq), oddly, does not. In most contexts, PersistentLists and seqs are interchangeable. Are you needing to use the seq as a stack after constructing it in some manner that produces a seq? On Fri, Jun 21, 2013 at 8:37 AM, Jim - FooBar(); jimpil1...@gmail.comwrote: Hi all, what do you guys do when you want to map a fn over a list but you want to produce a list as the result (not vector or lazy-seq). What is the fastest way of doing this? My first attempt was this: (- (mapv f coll) rseq ;;reverse fast (into '())) but I quickly realised that lists do not have transient counterparts. Therefore, the call to 'into' will be slow...in addition, I'm performing 2 passes with this... any ideas? Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
a start would be to set *warn-on-reflection* *unchecked-math* to
true...I think you're not properly type-hinting your 'aget' calls.
areduce is the fastest way to sum up an array of primitives given that
there are no reflective calls. This takes just over 19 ms on my humble
machine and don't forget that we 're counting the time it takes to
populate the array as well...
(defn- array-sum-ints [n]
(let [^ints a (int-array n)]
(dotimes [n n] (aset a n 1))
(areduce a i ret 0
(+ ret (aget a i)
Jim
On 21/06/13 13:36, Colin Yates wrote:
Hi all,
I am doing some (naive and trivial) performance tests before deciding
whether and how to use Clojure for some performance critical number
cruching and I wanted help understanding the behaviour.
I am defining an array inside a function, setting the contents to be 1
and then summing them up (by areducing) them (I chose 1 instead of a
random number for consistency, obviously the contents will be
different otherwise it would all reduce to (n) :)). If I 'let' the
array then it is factors of 10 faster than if I def the array.
The relevant code
(https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
[code]
(ns inc
(:gen-class))
(defn- inc-atom [n]
(def x (atom 0))
(dotimes [n n] (swap! x inc))
@x)
(defn- array-let [n]
(let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i)
(defn- array-def [n]
(def a (int-array n))
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i
(defn- run-test [subject n]
(time (do (def x (subject n)) (println x
(defn -main [ args]
(let [n 100]
(println inc atom)
(run-test inc-atom n)
(println array with let)
(run-test array-let n)
(println array with def)
(run-test array-def n))
)
[/code]
Interestingly, if I refactored an 'execute-on-array' def which
array-let and array-def delegated to then they had the same
performance which seems to imply it is about scoping, but the array in
both array-let and array-def have exactly the same scope... Setting
the autoboxing warning to true didn't point out anything either.
The output (from my VM, so a bit slow):
[code]
inc atom
100
Elapsed time: 213.214118 msecs
array with let
100
Elapsed time: 75.302602 msecs
array with def
100
Elapsed time: 12868.970203 msecs
[/code]
For comparison, the following java code:
[code]
package perf;
public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; in; i++) counter++;
long end = System.currentTimeMillis();
System.out.println (Naive + (end - start) + ms, counter
is + counter);
counter = 0;
int[] arr = new int[n];
start = System.currentTimeMillis();
for (int i=0; iarr.length; i++) arr[i]=1;
for (int i=0; iarr.length; i++) counter = counter + arr[i];
end = System.currentTimeMillis();
System.out.println (Array + (end - start) + ms, counter
is + counter);
}
}
[/code]
produces the (as expected, much faster) results :
[code]
Naive 3 ms, counter is 100
Array 6 ms, counter is 100
[/code]
I am not surprised that the atom/inc takes much longer than 3 ms, but
I don't understand why the array solution is so much more expensive in
Clojure?
On a related point - can anyone provide a faster implementation of
summing up the contents of an array?
A lein project can be found https://github.com/yatesco/clojure-perf,
'lein uberjar; java -jar target/*.jar should demonstrate the output.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups Clojure group.
To unsubscribe from this group
Re: Function returns nil
I don't think that will work. for is lazy, so by the time it evals, the code will have dropped out of the scope of with-open. So: (defn read-stuff-2 [] (with-open [r (java.io.BufferedReader. (java.io.FileReader. myfile.txt))] (for [line (line-seq r)] line))) fails with an IOException. So, I think the OP needs: (defn read-stuff-3 [] (with-open [r (java.io.BufferedReader. (java.io.FileReader. myfile.txt))] (doall (for [line (line-seq r)] line or alternatively: (defn read-stuff-4 [] (with-open [r (java.io.BufferedReader. (java.io.FileReader. myfile.txt))] (for [line (doall (line-seq r))] line))) I really wish there were support for this in clojure.core: both dofor and domap would be very useful. Laziness is useful but when working with Java objecs with state, or anything with dynamic scope liberal use of doall is necessary which just adds extra brackets. Phil Jim jimpil1...@gmail.com writes: Only use 'doseq' when you don't care about the reuturn value. In other words only for side-effect-y code. Use 'for' instead... Jim On 21/06/13 11:17, Jay C wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: fastest way to produce a PersistentList
On 21/06/13 13:51, Cedric Greevey wrote: (apply list the-seq) seems to work, but (list* the-seq), oddly, does not. In most contexts, PersistentLists and seqs are interchangeable. Are you needing to use the seq as a stack after constructing it in some manner that produces a seq? No, my requirement is this: I'm extending a protocol to all major Clojure data-structures very much in the same way conj is implemented. The protocol defines a single fn which simply maps a transformer on whatever collection was passed in. However, each polymorphic call should not mess with the types. It should always return the same type and do the mapping in the most efficient manner... (apply list (map f the-seq)) does work but is not very efficient and I think you will get the results reversed... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
aaa yes, of course! :) Jim On 21/06/13 13:47, John D. Hume wrote: If you use for, which is lazy, wrap it in a doall to force it to do its work before with-open closes your reader. On Jun 21, 2013 6:52 AM, Jim jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote: Only use 'doseq' when you don't care about the reuturn value. In other words only for side-effect-y code. Use 'for' instead... Jim On 21/06/13 11:17, Jay C wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com mailto:clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com mailto:clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
I really wish there were support for this in clojure.core: both dofor and domap would be very useful. mapv is non-lazy, which gives you the semantics of a domap as long as you don't mind a vector over a sequence -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
On 21/06/13 14:01, Neale Swinnerton wrote: I really wish there were support for this in clojure.core: both dofor and domap would be very useful. mapv is non-lazy, which gives you the semantics of a domap as long as you don't mind a vector over a sequence exactly! also, that's why macros are for...every time I think I wish there was X in clojure.core..., the next thought is macros :) what you wish is rather trivial to implement and it doesn't even have to be a macro... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
Thanks for all the input. Using for as in Phillip's suggestion seems to have gotten me somewhere, but now the function returns during every iteration. What am I missing to have it only return when a conditional statement is satisfied? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: fastest way to produce a PersistentList
On 21 June 2013 13:37, Jim - FooBar(); jimpil1...@gmail.com wrote: Hi all, what do you guys do when you want to map a fn over a list but you want to produce a list as the result (not vector or lazy-seq). What is the fastest way of doing this? My first attempt was this: (- (mapv f coll) rseq ;;reverse fast (into '())) but I quickly realised that lists do not have transient counterparts. Therefore, the call to 'into' will be slow... Your logic here is incorrect. To say transients == fast, persistents == slow is to grossly oversimplify things. The default data structures are *fast*. Transients are offered, where they make sense, as optimization to make things go *faster*. Note that this does not change the big-O complexity. Transients make sense for vectors and maps since they are 32-wide tree-based data structures, and often a conj or assoc operation on a persistent data structure will entirely replace a tree node with a copy with one entry replaced. This operation can be optimized to a mutable bash-the-node-in-place operation provided you know you won't want the old value afterwards. There is no analogous case in lists. Every conj operation necessarly allocates a new cons cell; there is no scope for saving time by bashing in place. Therefore, there is no transient for lists. The fact that no transient optimization exists for lists does not mean that lists are slow. This logic simply does not follow. in addition, I'm performing 2 passes with this... any ideas? If you're afraid of performing 2 passes, you could take advantage of laziness: (- (rseq v) (map f) (into '())) Since map is lazy, this will only perform one pass (though it appears on first glance that it performs two). but I would be wary of your use of the word fastest at the top. Normally on the JVM, the answer to a what is the fastest way to..? question is it depends. A much easier question to answer is Is X fast enough? Phil Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
'for' accepts a :when clause which will get you even further :) Jim ps: it also accepts a :let clause if you find it useful On 21/06/13 14:06, Jay C wrote: Thanks for all the input. Using for as in Phillip's suggestion seems to have gotten me somewhere, but now the function returns during every iteration. What am I missing to have it only return when a conditional statement is satisfied? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
On Friday, 21 June 2013 11:17:44 UTC+1, Jay C wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
Cheers Jim, my problem is now solved using :when and then doing (apply str (fn)) to the return value. On Friday, 21 June 2013 14:08:19 UTC+1, Jim foo.bar wrote: 'for' accepts a :when clause which will get you even further :) Jim ps: it also accepts a :let clause if you find it useful On 21/06/13 14:06, Jay C wrote: Thanks for all the input. Using for as in Phillip's suggestion seems to have gotten me somewhere, but now the function returns during every iteration. What am I missing to have it only return when a conditional statement is satisfied? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
Using `def` like that is simply incorrect. `def` should always be at the
top level unlike say Scheme.
I would first remove all internal defs and then rerun your benchmarks.
On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates colin.ya...@gmail.com wrote:
Hi all,
I am doing some (naive and trivial) performance tests before deciding
whether and how to use Clojure for some performance critical number
cruching and I wanted help understanding the behaviour.
I am defining an array inside a function, setting the contents to be 1 and
then summing them up (by areducing) them (I chose 1 instead of a random
number for consistency, obviously the contents will be different otherwise
it would all reduce to (n) :)). If I 'let' the array then it is factors of
10 faster than if I def the array.
The relevant code (
https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
[code]
(ns inc
(:gen-class))
(defn- inc-atom [n]
(def x (atom 0))
(dotimes [n n] (swap! x inc))
@x)
(defn- array-let [n]
(let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i)
(defn- array-def [n]
(def a (int-array n))
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i
(defn- run-test [subject n]
(time (do (def x (subject n)) (println x
(defn -main [ args]
(let [n 100]
(println inc atom)
(run-test inc-atom n)
(println array with let)
(run-test array-let n)
(println array with def)
(run-test array-def n))
)
[/code]
Interestingly, if I refactored an 'execute-on-array' def which array-let
and array-def delegated to then they had the same performance which seems
to imply it is about scoping, but the array in both array-let and array-def
have exactly the same scope... Setting the autoboxing warning to true
didn't point out anything either.
The output (from my VM, so a bit slow):
[code]
inc atom
100
Elapsed time: 213.214118 msecs
array with let
100
Elapsed time: 75.302602 msecs
array with def
100
Elapsed time: 12868.970203 msecs
[/code]
For comparison, the following java code:
[code]
package perf;
public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; in; i++) counter++;
long end = System.currentTimeMillis();
System.out.println (Naive + (end - start) + ms, counter is
+ counter);
counter = 0;
int[] arr = new int[n];
start = System.currentTimeMillis();
for (int i=0; iarr.length; i++) arr[i]=1;
for (int i=0; iarr.length; i++) counter = counter + arr[i];
end = System.currentTimeMillis();
System.out.println (Array + (end - start) + ms, counter is
+ counter);
}
}
[/code]
produces the (as expected, much faster) results :
[code]
Naive 3 ms, counter is 100
Array 6 ms, counter is 100
[/code]
I am not surprised that the atom/inc takes much longer than 3 ms, but I
don't understand why the array solution is so much more expensive in
Clojure?
On a related point - can anyone provide a faster implementation of summing
up the contents of an array?
A lein project can be found https://github.com/yatesco/clojure-perf,
'lein uberjar; java -jar target/*.jar should demonstrate the output.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: fastest way to produce a PersistentList
On 21/06/13 14:08, Philip Potter wrote: Your logic here is incorrect. To say transients == fast, persistents == slow is to grossly oversimplify things. Yes, I am indeed oversimplifying things but that doesn't change the fact that 'into' will be *slower* for collections that don't have transient cousins than the ones that have. It will also be slower if you don't use the 'transient-capabilities' than when you use them. I didn't mean to say that persistents==slow but rather that filling up a transient will always be faster (for more than 5-6 elements I') than filling up a persistent. The default data structures are*fast*. Transients are offered, where they make sense, as optimization to make things go*faster*. Note that this does not change the big-O complexity. I did not imply otherwise did I? There is no analogous case in lists. Every conj operation necessarly allocates a new cons cell; there is no scope for saving time by bashing in place. Therefore, there is no transient for lists. The fact that no transient optimization exists for lists does not mean that lists are slow. This logic simply does not follow. again, I never said that lists are slow but that with my current implementation the extension-point for IPeristentList is consistently slower than all the rest extensions. Even lazy-seqs are faster (NOT the data-structure but the mapping operation). Therefore I'd like to get it in-par with at least lazy-seqs. If you're afraid of performing 2 passes, you could take advantage of laziness: (- (rseq v) (map f) (into '())) Since map is lazy, this will only perform one pass (though it appears on first glance that it performs two). I already tried that but cannot call 'rseq' on a PersistenList and reverse would do an entire pass. ClassCastException clojure.lang.PersistentList cannot be cast to clojure.lang.Reversible clojure.core/rseq (core.clj:1497) but I would be wary of your use of the word fastest at the top. Normally on the JVM, the answer to a what is the fastest way to..? question is it depends. A much easier question to answer is Is X fast enough? I thought I was very careful to provide all the details for the what does it depend on? question. Ok, the title just reads fastest way... but in the message I explained all the constraints of my problem. I carefully said the fastest way to produce a list from mapping and since I explained that these are all protocol extensions you can infer that I am extending it to PersistenLIsts and I want to produce PersistentLists. The question is much narrower now isn't it? in any case I apologise for potentially causing confusion... this wasn't even a question about performance...I don't care if the fastest way is fast enough. All I care is that I find the fastest way...if that's not fast-enough then the consumer can choose not to use it...but I do want to offer the fastest way to do it by default (should the user choose it)...much like 'conj' works polymorphically regards, Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
Thanks Jim and David.
David, can you expand on why it is incorrect? That is such a strong word.
Is it correct but simply non-idiomatic?
Also note that if I move the body out of the 'let' version of the array
into another function passing in the array then the performance is the same
as the 'def' version, so even if def is a problem it isn't the only cause.
On 21 June 2013 14:29, David Nolen dnolen.li...@gmail.com wrote:
Using `def` like that is simply incorrect. `def` should always be at the
top level unlike say Scheme.
I would first remove all internal defs and then rerun your benchmarks.
On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates colin.ya...@gmail.comwrote:
Hi all,
I am doing some (naive and trivial) performance tests before deciding
whether and how to use Clojure for some performance critical number
cruching and I wanted help understanding the behaviour.
I am defining an array inside a function, setting the contents to be 1
and then summing them up (by areducing) them (I chose 1 instead of a random
number for consistency, obviously the contents will be different otherwise
it would all reduce to (n) :)). If I 'let' the array then it is factors of
10 faster than if I def the array.
The relevant code (
https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
[code]
(ns inc
(:gen-class))
(defn- inc-atom [n]
(def x (atom 0))
(dotimes [n n] (swap! x inc))
@x)
(defn- array-let [n]
(let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i)
(defn- array-def [n]
(def a (int-array n))
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
(+ ret (aget a i
(defn- run-test [subject n]
(time (do (def x (subject n)) (println x
(defn -main [ args]
(let [n 100]
(println inc atom)
(run-test inc-atom n)
(println array with let)
(run-test array-let n)
(println array with def)
(run-test array-def n))
)
[/code]
Interestingly, if I refactored an 'execute-on-array' def which array-let
and array-def delegated to then they had the same performance which seems
to imply it is about scoping, but the array in both array-let and array-def
have exactly the same scope... Setting the autoboxing warning to true
didn't point out anything either.
The output (from my VM, so a bit slow):
[code]
inc atom
100
Elapsed time: 213.214118 msecs
array with let
100
Elapsed time: 75.302602 msecs
array with def
100
Elapsed time: 12868.970203 msecs
[/code]
For comparison, the following java code:
[code]
package perf;
public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; in; i++) counter++;
long end = System.currentTimeMillis();
System.out.println (Naive + (end - start) + ms, counter is
+ counter);
counter = 0;
int[] arr = new int[n];
start = System.currentTimeMillis();
for (int i=0; iarr.length; i++) arr[i]=1;
for (int i=0; iarr.length; i++) counter = counter + arr[i];
end = System.currentTimeMillis();
System.out.println (Array + (end - start) + ms, counter is
+ counter);
}
}
[/code]
produces the (as expected, much faster) results :
[code]
Naive 3 ms, counter is 100
Array 6 ms, counter is 100
[/code]
I am not surprised that the atom/inc takes much longer than 3 ms, but I
don't understand why the array solution is so much more expensive in
Clojure?
On a related point - can anyone provide a faster implementation of
summing up the contents of an array?
A lein project can be found https://github.com/yatesco/clojure-perf,
'lein uberjar; java -jar target/*.jar should demonstrate the output.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
On 21/06/13 14:34, Colin Yates wrote: Is it correct but simply non-idiomatic? no no it's actually very *dangerous*...by doing this you're essentially introducing mutable global state in your program and Clojure is a language that strives hard to minimise mutable and especially global state! I wouldn't say 'wrong' because the compiler lets you do it but it is certainly nasty code! Also note that if I move the body out of the 'let' version of the array into another function passing in the array then the performance is the same as the 'def' version, so even if def is a problem it isn't the only cause. using 'let' or passing the array as parameter is the nice and safe approach. The general performance of clojure when it comes to primitive arrays was discussed very recently in this thread [1] and was concluded that Clojure does indeed match java's performance. The specific use-case actually was summing up primitive arrays. I encourage you read it...In a nutshell, If you're using leiningen, add this entry to your project.clj and rerun your benchmarks. :jvm-opts ^replace [] Jim [1] https://groups.google.com/forum/#!topic/clojure/LTtxhPxH_ws https://groups.google.com/forum/#%21topic/clojure/LTtxhPxH_ws -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
2013/6/21 Colin Yates colin.ya...@gmail.com Is it correct but simply non-idiomatic? It's not how defs are supposed to be used. It's like using fields for everything in Java even though you could use local variables for a lot of things, just because you can. def produces a shared (well, namespace-local) var. You probably want a function-local one. On top of that, since the thread is about performance, vars have features that locals don't and no feature comes without performance overhead. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
2013/6/21 Jim - FooBar(); jimpil1...@gmail.com If you're using leiningen, add this entry to your project.clj and rerun your benchmarks. :jvm-opts ^replace [] Original post suggests the code is executed by building an uberjar running java -jar target/… so Leiningen default JVM options are not relevant. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
Did you read the entire thread? both Jason and Leon (who originally posted) admit that this was the problem...Stuart even opened this issue: https://github.com/technomancy/leiningen/pull/1230 the very last post reads: I should follow up on this and clarify that core.matrix's esum is in fact as fast as Java -- I apologize for the false statement (I was unaware that new versions of leiningen disable advanced JIT optimizations by default, which lead to the numbers I reported). Jim On 21/06/13 14:54, Michael Klishin wrote: 2013/6/21 Jim - FooBar(); jimpil1...@gmail.com mailto:jimpil1...@gmail.com If you're using leiningen, add this entry to your project.clj and rerun your benchmarks. :jvm-opts ^replace [] Original post suggests the code is executed by building an uberjar running java -jar target/… so Leiningen default JVM options are not relevant. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: fastest way to produce a PersistentList
The problem is the reversing of the list if you want to convert back to a list. You can avoid this but you have to use a custom mapping operation, continuation passing style, and a trampoline - it won't be fast. Another option is to realize that concrete types simply don't matter. What you're trying to avoid is getting stuck with a ISeq vs. a IPersistentList (note you shouldn't care about having a PersistentList as none of the Clojure fns target that). One bit of cleverness you could do is to create a new type that satisfies all the interfaces of IPersistentList and return that instead (under the hood you can hide the lazy sequence or whatever you like generated by the mapping operation). A bit more work but probably accomplishes what you want. David On Fri, Jun 21, 2013 at 9:32 AM, Jim - FooBar(); jimpil1...@gmail.comwrote: On 21/06/13 14:08, Philip Potter wrote: Your logic here is incorrect. To say transients == fast, persistents == slow is to grossly oversimplify things. Yes, I am indeed oversimplifying things but that doesn't change the fact that 'into' will be *slower* for collections that don't have transient cousins than the ones that have. It will also be slower if you don't use the 'transient-capabilities' than when you use them. I didn't mean to say that persistents==slow but rather that filling up a transient will always be faster (for more than 5-6 elements I') than filling up a persistent. The default data structures are **fast**. Transients are offered, where they make sense, as optimization to make things go **faster**. Note that this does not change the big-O complexity. I did not imply otherwise did I? There is no analogous case in lists. Every conj operation necessarly allocates a new cons cell; there is no scope for saving time by bashing in place. Therefore, there is no transient for lists. The fact that no transient optimization exists for lists does not mean that lists are slow. This logic simply does not follow. again, I never said that lists are slow but that with my current implementation the extension-point for IPeristentList is consistently slower than all the rest extensions. Even lazy-seqs are faster (NOT the data-structure but the mapping operation). Therefore I'd like to get it in-par with at least lazy-seqs. If you're afraid of performing 2 passes, you could take advantage of laziness: (- (rseq v) (map f) (into '())) Since map is lazy, this will only perform one pass (though it appears on first glance that it performs two). I already tried that but cannot call 'rseq' on a PersistenList and reverse would do an entire pass. ClassCastException clojure.lang.PersistentList cannot be cast to clojure.lang.Reversible clojure.core/rseq (core.clj:1497) but I would be wary of your use of the word fastest at the top. Normally on the JVM, the answer to a what is the fastest way to..? question is it depends. A much easier question to answer is Is X fast enough? I thought I was very careful to provide all the details for the what does it depend on? question. Ok, the title just reads fastest way... but in the message I explained all the constraints of my problem. I carefully said the fastest way to produce a list from mapping and since I explained that these are all protocol extensions you can infer that I am extending it to PersistenLIsts and I want to produce PersistentLists. The question is much narrower now isn't it? in any case I apologise for potentially causing confusion... this wasn't even a question about performance...I don't care if the fastest way is fast enough. All I care is that I find the fastest way...if that's not fast-enough then the consumer can choose not to use it...but I do want to offer the fastest way to do it by default (should the user choose it)...much like 'conj' works polymorphically regards, Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
:jvm-opts and that ticket for Leiningen only affect the options passed to the JVM if you let Leiningen invoke the JVM for you, e.g. via lein run ... Colin showed pretty clearly in his email that he was using lein uberjar followed by running the JVM explicitly with his own command line, so Leiningen has no way to affect the JVM command line options in that case. Andy On Fri, Jun 21, 2013 at 6:59 AM, Jim - FooBar(); jimpil1...@gmail.comwrote: Did you read the entire thread? both Jason and Leon (who originally posted) admit that this was the problem...Stuart even opened this issue: https://github.com/technomancy/leiningen/pull/1230 the very last post reads: I should follow up on this and clarify that core.matrix's esum is in fact as fast as Java -- I apologize for the false statement (I was unaware that new versions of leiningen disable advanced JIT optimizations by default, which lead to the numbers I reported). Jim On 21/06/13 14:54, Michael Klishin wrote: 2013/6/21 Jim - FooBar(); jimpil1...@gmail.com If you're using leiningen, add this entry to your project.clj and rerun your benchmarks. :jvm-opts ^replace [] Original post suggests the code is executed by building an uberjar running java -jar target/… so Leiningen default JVM options are not relevant. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: fastest way to produce a PersistentList
Hi David, On 21/06/13 14:51, David Nolen wrote: The problem is the reversing of the list if you want to convert back to a list. You can avoid this but you have to use a custom mapping operation, continuation passing style, and a trampoline - it won't be fast. Another option is to realize that concrete types simply don't matter. What you're trying to avoid is getting stuck with a ISeq vs. a IPersistentList (note you shouldn't care about having a PersistentList as none of the Clojure fns target that). Yes, but what about java interop? Why not being able to send data over from Java to that namespace? The protocol is also extended to Lists, Vectors, arrays etc. One is able to send his ArrayLists for normalisation to that namespace and get the same type back or a similar one (conforming to a common interface). I'll admit that sending PersistentLists from Java is extremely unlikely but it's been bugging me since this is the one extension-point where uniformity breaks. I will consider removing the extension-point to IPersistenList. If such a type is passed in, the extension-point for IPersistentCollection should catch it, which happens to return a vector. One bit of cleverness you could do is to create a new type that satisfies all the interfaces of IPersistentList and return that instead (under the hood you can hide the lazy sequence or whatever you like generated by the mapping operation). A bit more work but probably accomplishes what you want. that does sound more work but I'll look into it anyway...:) David thanks a lot, Jim On Fri, Jun 21, 2013 at 9:32 AM, Jim - FooBar(); jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote: On 21/06/13 14:08, Philip Potter wrote: Your logic here is incorrect. To say transients == fast, persistents == slow is to grossly oversimplify things. Yes, I am indeed oversimplifying things but that doesn't change the fact that 'into' will be *slower* for collections that don't have transient cousins than the ones that have. It will also be slower if you don't use the 'transient-capabilities' than when you use them. I didn't mean to say that persistents==slow but rather that filling up a transient will always be faster (for more than 5-6 elements I') than filling up a persistent. The default data structures are**fast**. Transients are offered, where they make sense, as optimization to make things go**faster**. Note that this does not change the big-O complexity. I did not imply otherwise did I? There is no analogous case in lists. Every conj operation necessarly allocates a new cons cell; there is no scope for saving time by bashing in place. Therefore, there is no transient for lists. The fact that no transient optimization exists for lists does not mean that lists are slow. This logic simply does not follow. again, I never said that lists are slow but that with my current implementation the extension-point for IPeristentList is consistently slower than all the rest extensions. Even lazy-seqs are faster (NOT the data-structure but the mapping operation). Therefore I'd like to get it in-par with at least lazy-seqs. If you're afraid of performing 2 passes, you could take advantage of laziness: (- (rseq v) (map f) (into '())) Since map is lazy, this will only perform one pass (though it appears on first glance that it performs two). I already tried that but cannot call 'rseq' on a PersistenList and reverse would do an entire pass. ClassCastException clojure.lang.PersistentList cannot be cast to clojure.lang.Reversible clojure.core/rseq (core.clj:1497) but I would be wary of your use of the word fastest at the top. Normally on the JVM, the answer to a what is the fastest way to..? question is it depends. A much easier question to answer is Is X fast enough? I thought I was very careful to provide all the details for the what does it depend on? question. Ok, the title just reads fastest way... but in the message I explained all the constraints of my problem. I carefully said the fastest way to produce a list from mapping and since I explained that these are all protocol extensions you can infer that I am extending it to PersistenLIsts and I want to produce PersistentLists. The question is much narrower now isn't it? in any case I apologise for potentially causing confusion... this wasn't even a question about performance...I don't care if the fastest way is fast enough. All I care is that I find the fastest way...if that's not fast-enough then the consumer can choose not to use it...but I do want to offer the fastest way to do it by default (should the user choose it)...much like 'conj' works polymorphically regards, Jim -- -- You received this message because you are
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
2013/6/21 Jim - FooBar(); jimpil1...@gmail.com Did you read the entire thread? both Jason and Leon (who originally posted) admit that this was the problem...Stuart even opened this issue: https://github.com/technomancy/leiningen/pull/1230 Leiningen's default only apply if you, hm, run Leiningen. If you run java -jar …, you don't run Leiningen and the JVM flags used are exactly what you provide. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
On 21/06/13 15:06, Andy Fingerhut wrote: Colin showed pretty clearly in his email that he was using lein uberjar followed by running the JVM explicitly with his own command line, so Leiningen has no way to affect the JVM command line options in that case. oops! I thought Michael meant the guys from Prismatic not the OP on this thread. Yes, this doesn't apply to Colin... my bad...I'm really sorry... Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
Jim - FooBar(); jimpil1...@gmail.com writes: On 21/06/13 14:01, Neale Swinnerton wrote: I really wish there were support for this in clojure.core: both dofor and domap would be very useful. mapv is non-lazy, which gives you the semantics of a domap as long as you don't mind a vector over a sequence exactly! also, that's why macros are for...every time I think I wish there was X in clojure.core..., the next thought is macros :) what you wish is rather trivial to implement and it doesn't even have to be a macro... Well, indeed, yes, I have implemented it. But, then I have to do require statements everywhere, or I redo the implementation in every package, or add a dependency. Lots of functions in clojure.core are trivial to implement after all. dofor really is different from doseq because it doesn't drop the head. Didn't know about mapv though. Will use that lots! Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
generating core.logic queries
Hi all, am toying around with the thought of generating core.logic
queries dynamically. However, I'm stuck at square one since all
the core.logic functions are macros and am not sure how to refer
to logic vars within a query generator fn.
E.g. given this list of facts...
(def myfacts
[[:karsten :spouse :mia]
[:fred :spouse :anna]
[:mia :name mia]
[:anna :name anna]])
...I'd like to find the person who's spouse's name is mia.
The SPARQL[1] equivalent for the above would be:
SELECT ?p WHERE { ?p :spouse ?s . ?s :name mia }
In core.logic I can do this equivalently, but have no idea how to
generate the lists of `conso`s dynamically:
(run* [p]
(fresh [s]
(conde
[(conso p [:spouse s] (myfacts 0))]
[(conso p [:spouse s] (myfacts 1))]
[(conso p [:spouse s] (myfacts 2))]
[(conso p [:spouse s] (myfacts 3))])
(conde
[(conso s [:name mia] (myfacts 0))]
[(conso s [:name mia] (myfacts 1))]
[(conso s [:name mia] (myfacts 2))]
[(conso s [:name mia] (myfacts 3))])))
; = (:karsten)
a) How would I go about generating such a single `conso` only given a
single logic var, var position in the triple and the fact triple
itself?
b) How can I refer to a logic var in a function outside the lexical
scope of `fresh` or `run*`?
c) What is the best way to produce and pass a seq of goals for `conde`? Since
it is a macro I can't use `apply`...
K.
[1] http://www.w3.org/TR/sparql11-overview/
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
matching, assigning and branching in one form
Hi, I am writing a simple IRC bot, pretty much just for fun, starting with a simple implementation originally posted by Nurullah Akkaya on his blog. It already does what it's supposed to, which is message a fortune from mod-fortune (shelling out) when someone asks it to. However, there's a bit of code I don't like. It looks like this: (cond (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg) (let [[_ from to message] (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg)] [...logic omitted...] What's happening is we're looking for a PRIVMSG, and if we find one, we scan the message again and pull out the chunks we're interested in, and use them in the logic part below. The problem is I don't like maintaining two regular expressions. I wish I could use it only once, and therefore change it only once if it needs to be modified. I'd prefer to see an expression that looks like this (for example): (cond (if-matched #^:(.*?)!.*PRIVMSG (.*) :(.*) msg [from to message] (true form) (optional false form))) The if-matched acts as a let block while pulling out groups and assigning to local variables at the same time. Also, it ignores the first match of re-find, which is the entire expression -- not generally useful to me. Maybe if-matched-groups would ignore the overall expression, and if-matched would include it. I suppose a macro might be the way to go to accomplish this, but I wonder if there are any Clojure tricks that could accomplish this short of a macro. Also, do any fellow Clojurians think a macro like this is a bad idea in general? Would you suggest taking a different tack to solve this problem? Thanks in advance! steven -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
database wrapper lib
Hi all, I'm looking for a decent database wrapper library. I'm probably going to end up using PostgrSQL maybe SQLite for testing. I've looked at Korma a few others, but I'm getting lost on how to *actually use* them. I'm new to Clojure, so something with a good tutorial would be best! Thanks! Justin -- * I am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand. - Douglas Adams --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?” -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
It's common misconception that core.logic is a bunch of macros. The macros
are just sugar, there are functions for *everything*.
You can load a stream of facts however you please, you should look at
`to-stream` which can take any Clojure sequence of data and make it useable
from core.logic as a list of facts. Note this is very naive - you'll have
to provide indexing yourself if you have a large data set. You might want
to take a look at the experimental Datomic integration notes on the
core.logic wiki for further guidance.
I would look into this approach first and see if this doesn't answer your
other questions as well.
David
On Fri, Jun 21, 2013 at 11:28 AM, Karsten Schmidt i...@toxi.co.uk wrote:
Hi all, am toying around with the thought of generating core.logic
queries dynamically. However, I'm stuck at square one since all
the core.logic functions are macros and am not sure how to refer
to logic vars within a query generator fn.
E.g. given this list of facts...
(def myfacts
[[:karsten :spouse :mia]
[:fred :spouse :anna]
[:mia :name mia]
[:anna :name anna]])
...I'd like to find the person who's spouse's name is mia.
The SPARQL[1] equivalent for the above would be:
SELECT ?p WHERE { ?p :spouse ?s . ?s :name mia }
In core.logic I can do this equivalently, but have no idea how to
generate the lists of `conso`s dynamically:
(run* [p]
(fresh [s]
(conde
[(conso p [:spouse s] (myfacts 0))]
[(conso p [:spouse s] (myfacts 1))]
[(conso p [:spouse s] (myfacts 2))]
[(conso p [:spouse s] (myfacts 3))])
(conde
[(conso s [:name mia] (myfacts 0))]
[(conso s [:name mia] (myfacts 1))]
[(conso s [:name mia] (myfacts 2))]
[(conso s [:name mia] (myfacts 3))])))
; = (:karsten)
a) How would I go about generating such a single `conso` only given a
single logic var, var position in the triple and the fact triple
itself?
b) How can I refer to a logic var in a function outside the lexical
scope of `fresh` or `run*`?
c) What is the best way to produce and pass a seq of goals for `conde`?
Since
it is a macro I can't use `apply`...
K.
[1] http://www.w3.org/TR/sparql11-overview/
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: database wrapper lib
2013/6/21 serialhex serial...@gmail.com Hi all, I'm looking for a decent database wrapper library. Relational databases: https://github.com/clojure/java.jdbc (this one is not very extensively documented but is also small compared to Korma) MongoDB: http://clojuremongodb.info Cassandra: http://clojurecassandra.info Riak: http://clojureriak.info Redis: https://github.com/ptaoussanis/carmine Graph databases: http://titanium.clojurewerkz.org, http://clojureneo4j.info ElasticSearch: http://clojureelasticsearch.info For data validation, http://clojurevalidations.info is one of about a dozen options you can easily find with a quick search. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: matching, assigning and branching in one form
Not a specific answer to your question, but it would be cool to see someone make the core.match regex facilities handle this. (match [msg] [(#^:(.*?)!.*PRIVMSG (.*) :(.*) : [from to message])] ... true form ... :else ... false form ..) David On Fri, Jun 21, 2013 at 11:43 AM, Steven D. Arnold thoth.amon.i...@gmail.com wrote: Hi, I am writing a simple IRC bot, pretty much just for fun, starting with a simple implementation originally posted by Nurullah Akkaya on his blog. It already does what it's supposed to, which is message a fortune from mod-fortune (shelling out) when someone asks it to. However, there's a bit of code I don't like. It looks like this: (cond (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg) (let [[_ from to message] (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg)] [...logic omitted...] What's happening is we're looking for a PRIVMSG, and if we find one, we scan the message again and pull out the chunks we're interested in, and use them in the logic part below. The problem is I don't like maintaining two regular expressions. I wish I could use it only once, and therefore change it only once if it needs to be modified. I'd prefer to see an expression that looks like this (for example): (cond (if-matched #^:(.*?)!.*PRIVMSG (.*) :(.*) msg [from to message] (true form) (optional false form))) The if-matched acts as a let block while pulling out groups and assigning to local variables at the same time. Also, it ignores the first match of re-find, which is the entire expression -- not generally useful to me. Maybe if-matched-groups would ignore the overall expression, and if-matched would include it. I suppose a macro might be the way to go to accomplish this, but I wonder if there are any Clojure tricks that could accomplish this short of a macro. Also, do any fellow Clojurians think a macro like this is a bad idea in general? Would you suggest taking a different tack to solve this problem? Thanks in advance! steven -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
On Fri, Jun 21, 2013 at 11:56 AM, David Nolen dnolen.li...@gmail.comwrote: Datomic integration notes on the core.logic wiki I'm concerned with this trend towards favoring Datomic over other solutions when adding database integration to libraries. If one DB is going to be singled out for preferred treatment by a lot of Clojure developers, I'd prefer it to be an open source one, and I doubt I am alone in this. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
I wasn't suggesting using Datomic. On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Jun 21, 2013 at 11:56 AM, David Nolen dnolen.li...@gmail.comwrote: Datomic integration notes on the core.logic wiki I'm concerned with this trend towards favoring Datomic over other solutions when adding database integration to libraries. If one DB is going to be singled out for preferred treatment by a lot of Clojure developers, I'd prefer it to be an open source one, and I doubt I am alone in this. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: interval trees..
Hi Sunil, I created one here: https://github.com/mobiusinversion/interval-trees Here is the marginalia documentation http://mobiusinversion.github.io/interval-trees/ and the Clojars page https://clojars.org/interval-trees Please let me know if you have a chance to try this out and I would greatly appreciate any feedback. On Monday, June 6, 2011 4:35:01 AM UTC-7, Sunil Nandihalli wrote: Hello everybody, Is there any implementation of Interval Treeshttp://en.wikipedia.org/wiki/Interval_tree in Clojure. I found this Java implementationhttp://www.thekevindolan.com/2010/02/interval-tree/index.html but it does not have remove operation. Even some other Java Implementation would do. Thanks, Sunil. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
Thanks, David! I wasn't aware the macros are just sugar. Time to study the source more closely! The above code was very naive indeed, but for sake of illustration only. These queries would only ever deal with a small subset of facts, which have already been selected from a number of indexes. K. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: (clojure 1.5.1) Weird performance results when using let versus def for variable
Ah OK, I didn't realise. I thought the vars would be locally scoped, i.e. semantically equivalent to 'let'ed symbols. Thanks everyone for contributing. On Friday, 21 June 2013 14:49:52 UTC+1, Jim foo.bar wrote: On 21/06/13 14:34, Colin Yates wrote: Is it correct but simply non-idiomatic? no no it's actually very *dangerous*...by doing this you're essentially introducing mutable global state in your program and Clojure is a language that strives hard to minimise mutable and especially global state! I wouldn't say 'wrong' because the compiler lets you do it but it is certainly nasty code! Also note that if I move the body out of the 'let' version of the array into another function passing in the array then the performance is the same as the 'def' version, so even if def is a problem it isn't the only cause. using 'let' or passing the array as parameter is the nice and safe approach. The general performance of clojure when it comes to primitive arrays was discussed very recently in this thread [1] and was concluded that Clojure does indeed match java's performance. The specific use-case actually was summing up primitive arrays. I encourage you read it...In a nutshell, If you're using leiningen, add this entry to your project.clj and rerun your benchmarks. :jvm-opts ^replace [] Jim [1] https://groups.google.com/forum/#!topic/clojure/LTtxhPxH_ws -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
Perhaps not, but apparently the developers of core.logic are. And it's only one of several similar instances to come to my attention in recent weeks. On Fri, Jun 21, 2013 at 12:22 PM, David Nolen dnolen.li...@gmail.comwrote: I wasn't suggesting using Datomic. On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey cgree...@gmail.comwrote: On Fri, Jun 21, 2013 at 11:56 AM, David Nolen dnolen.li...@gmail.comwrote: Datomic integration notes on the core.logic wiki I'm concerned with this trend towards favoring Datomic over other solutions when adding database integration to libraries. If one DB is going to be singled out for preferred treatment by a lot of Clojure developers, I'd prefer it to be an open source one, and I doubt I am alone in this. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
One reason why Datomic works so well with core.logic is that it exposes raw index data to the client. I am unaware of any other database that decouples data storage from the query engine. If you can find one that does, I'm sure someone could expose a core.logic interface to that DB as well. But, if you really can't stand the idea of using Datomic, and would prefer to see examples running against other DBs, I would recommend this tutorial that shows how core.logic can be used to query a graph database: http://tsdh.wordpress.com/2012/01/06/using-clojures-core-logic-with-custom-data-structures/ Timothy On Fri, Jun 21, 2013 at 10:41 AM, Cedric Greevey cgree...@gmail.com wrote: Perhaps not, but apparently the developers of core.logic are. And it's only one of several similar instances to come to my attention in recent weeks. On Fri, Jun 21, 2013 at 12:22 PM, David Nolen dnolen.li...@gmail.comwrote: I wasn't suggesting using Datomic. On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey cgree...@gmail.comwrote: On Fri, Jun 21, 2013 at 11:56 AM, David Nolen dnolen.li...@gmail.comwrote: Datomic integration notes on the core.logic wiki I'm concerned with this trend towards favoring Datomic over other solutions when adding database integration to libraries. If one DB is going to be singled out for preferred treatment by a lot of Clojure developers, I'd prefer it to be an open source one, and I doubt I am alone in this. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: database wrapper lib
Hey, thanks for the links!! I searched around but never found those, this helps a lot!!! Justin On Fri, Jun 21, 2013 at 11:56 AM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/6/21 serialhex serial...@gmail.com Hi all, I'm looking for a decent database wrapper library. Relational databases: https://github.com/clojure/java.jdbc (this one is not very extensively documented but is also small compared to Korma) MongoDB: http://clojuremongodb.info Cassandra: http://clojurecassandra.info Riak: http://clojureriak.info Redis: https://github.com/ptaoussanis/carmine Graph databases: http://titanium.clojurewerkz.org, http://clojureneo4j.info ElasticSearch: http://clojureelasticsearch.info For data validation, http://clojurevalidations.info is one of about a dozen options you can easily find with a quick search. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- * I am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand. - Douglas Adams --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?” -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Best practice for looping
Hi, I am new to clojure and I am trying to reimplement some optimization code that uses gradient descent. I have attached the source to this post. My experience with gradient descent is in Matlab, which is procedural. When I run my function gradient-descent I supply step sizes and error values of 0.01, it runs correctly and gives me good results. However, if I decrease the error value below 0.001 it produces a stack overflow error. I get the same error if my step value goes down to 0.001. Is my looping mechanism correct and I am just having numerical limitations? Am I abusing loop/recur? Any suggestions/critiques would be great! Thanks, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. core.clj Description: Binary data vec.clj Description: Binary data
Re: Problem filtering with definline'd function
Does anyone have an idea for what I might do to diagnose/fix this? Is this
just a misunderstanding on my part? If not I'll file a bug against
definline.
On 21 June 2013 18:04, Colin Fleming colin.mailingl...@gmail.com wrote:
So this has just happened to me again:
Clojure 1.5.1
(plugin.psi/symbol? 2)
= false
(filter plugin.psi/symbol? [1 2 3])
= (1 2 3)
((var-get #'plugin.psi/symbol?) 2)
= (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
What that looks like to me is that the macro fn (i.e. the one that is
usually in the :inline meta) is being stored in the var. So when it's used
by filter, it always returns true. Does anyone have any idea what else I
could try to debug this? I'll leave the REPL session open so I can try any
suggestions.
I just tried this, looks like the fns are not the same, at least, but they
do have the same effect:
(meta #'plugin.psi/symbol?)
= {:inline plugin.psi$symbol_QMARK_@3781ff7f, :ns plugin.psi, :name
symbol?, :arglists ([element]), :column 1, :line 35, :file plugin/psi.clj}
(= plugin.psi/symbol?
(:inline (meta #'plugin.psi/symbol?)))
= false
plugin.psi/symbol?
= plugin.psi$symbol_QMARK_@4ccc75ae
((:inline (meta #'plugin.psi/symbol?)) 2)
= (clojure.core/instance?
org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
On 20 June 2013 22:48, Colin Fleming colin.mailingl...@gmail.com wrote:
ClSymbol is a Java class. I don't get the replacement warning because
I've excluded that symbol explicitly in my ns declaration using
:refer-clojure :exclude.
I haven't done a 'lein clean' because I'm not using lein, but I have
rebuilt various times. However, sometimes it will work and sometimes it
won't. I just tried this now, and I've been unable to reproduce. I guess
I'll keep working tomorrow and see if it crops up again. If I see it again
I'm going to try ((var-get #'symbol?) 2) to see if the results from the
function differ from the macroexpanded version.
On 20 June 2013 22:21, Jim - FooBar(); jimpil1...@gmail.com wrote:
On 20/06/13 10:59, Colin Fleming wrote:
Because this tests for something different - that the element is an
instance of ClSymbol. It's not testing the same thing as the core version.
I qualify it (psi/symbol? in the examples above) to distinguish it from the
core one.
Basically, I'm trying to use definline to allow me to have a more
Clojure-y API without having the performance hit of tons of tiny function
calls.
I agree that this is unlikely to be a bug in Clojure and is probably
something I'm missing, but I can't figure it out.
right I see...so if ClSymbol is a defrecord/deftype I don't see anything
wrong with your code...when you do (in-ns 'plugin.psi) do you get a warning
that core/symbol? is being replaced by psi/symbol? ?
what you tried on your repl works fine on mine:
user= (defrecord FOO [a])
user.FOO
user= (definline foo? [e]
#_= `(instance? FOO ~e))
#'user/foo?
user= (foo? 2)
false
user= (filter foo? [1 2 3])
()
user= (filter foo? [(FOO. 1) 2 3])
(#user.FOO{:a 1})
Did you try 'lein clean' to get rid of already compiled classes? I'm
suspecting you have different versions of the same class lying around
because of what you said about compiling and recompiling...
Jim
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
--- You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: generating core.logic queries
Perhaps not, but apparently the developers of core.logic are. That's kinda a funny remark to make to David Nolen, who is *the* developer of core.logic. In this case, he's talking about this wiki page: https://github.com/clojure/core.logic/wiki/Extending-core.logic-(Datomic-example) That's not a recommendation to use Datomic, that's just one particularly interesting example of how to extend core.logic -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: representing clojure source code as data?
I think there are 2 representations that could be useful: I think there are really two axis: 1) Shape of the data and 2) Language being described You've outlined 2 out of the 3 interesting (to me) shapes: 1) raw data structures and 2) datoms. I think that the 3rd interesting one is a map/vector tree, like the CLJS analyzer output. The two languages to describe are EDN and Clojure. You can further break Clojure down by host platform, and even potentially further (for example: pre and post macro expansion variants of the language). 1. as pure EDN data that encodes the various reader macros within the strict EDN subset, as a kind of minimal AST I made a related design page here: http://dev.clojure.org/display/design/Representing+EDN The contents of that design page right now are focused on the raw data structures shape of EDN, hence the proposal for a TaggedLiteral type. Here's some code for parsing raw data with a TaggedLiteral record into a vector/map tree of sorts: https://github.com/brandonbloom/ascribe/blob/04384d21bd9e74e29d84cf2ec1c55dd5034195e0/test/ascribe/cljs/parse.clj As for the Code variant, the tools.analyzer library and CLJS compilers have an internal AST representation that should eventually be standardized. The important thing there for me is that we differentiate fundamental properties of AST nodes and synthesized/derived attributes that are attached to each node. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: database wrapper lib
Hey Justin, I'm also working on a wrapper lib for SQL queries (which can optionally use jdbc for performing the queries). At the moment it's pretty new, so it might not actually work for you, but if you want to take a look the code's at https://bitbucket.org/czan/clojure-sql. It's also been pushed to clojars (https://clojars.org/clojure-sql) if you want to try it out. The main idea is that all queries should be composable, so you can just think of them in terms of the fields they expose and then you should be able to join them together however you want. I plan to do a bit more work before actually announcing a release, but since it was so relevant to what you're asking about I just had to mention it. Carlo On 22 June 2013 04:38, serialhex serial...@gmail.com wrote: Hey, thanks for the links!! I searched around but never found those, this helps a lot!!! Justin On Fri, Jun 21, 2013 at 11:56 AM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/6/21 serialhex serial...@gmail.com Hi all, I'm looking for a decent database wrapper library. Relational databases: https://github.com/clojure/java.jdbc (this one is not very extensively documented but is also small compared to Korma) MongoDB: http://clojuremongodb.info Cassandra: http://clojurecassandra.info Riak: http://clojureriak.info Redis: https://github.com/ptaoussanis/carmine Graph databases: http://titanium.clojurewerkz.org, http://clojureneo4j.info ElasticSearch: http://clojureelasticsearch.info For data validation, http://clojurevalidations.info is one of about a dozen options you can easily find with a quick search. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- * I am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand. - Douglas Adams --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?” -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: database wrapper lib
On Fri, Jun 21, 2013 at 8:56 AM, Michael Klishin michael.s.klis...@gmail.com wrote: Relational databases: https://github.com/clojure/java.jdbc (this one is not very extensively documented but is also small compared to Korma) FYI, Korma is built on top of java.jdbc and if you want a different DSL on top of java.jdbc, I highly recommend HoneySQL. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Web Framework update
Some major changes have been made to the CHP framework. This library provides the following Clojure on the front end Run Clojure inside a HTML file with the clj/clj tagsStyle templates can be written in CHTML ex. chp.template/using-template Parameters Request params ex. ($p userid)Common web headers ex. ($ user-agent)Web Headers ex. ($$ cache-control)Environmental variables ex. (env java.vm.name) Path Routing Have multiple method handlers under a single route (get, post, put, delete, and head)Routes can be defined in seperate files and namespaces DB Create SQL database schemas ex. lein schemaPerform SQL database migrations ex. lein migratePerform migration rollbacks ex. lein rollbackManipulate SQL databases with KormaSQL Code Generation Generate _javascript_ / ECMAScriptGenerate HTMLGenerate CSS -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
