Re: Calling macros by var
On 01.10.2010, at 03:07, Phil Hagelberg wrote: I suspect the answer may just be yeah... that's not something you should do with macros, but I'm curious. I suppose the compiler only checks the :macro metadata when it's literally in the call position rather than when there's indirection through calling var? Right. I use this for macro testing from the REPL for convenience, so I hope this won't change. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Changing keys in a map
On Oct 1, 2010, at 1:57 AM, Sean Corfield wrote: On Thu, Sep 30, 2010 at 12:52 AM, David Sletten da...@bosatsu.net wrote: Huh?! How many solutions do you want? You're starting to annoy me Sean. Sorry dude. I think it's really insightful to see lots of different solutions to small point problems like this when you're learning a language - particularly when the issue of idiom is being discussed. I've certainly found this thread educational and I hope I'm not annoying too many people :) Sean, Sean...I was just making fun of your signature. :) Keep up the questions! If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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
Macro Implementation: I Don't Understand This Error Message
Dear Clojure Group, I wanted to expand the 'infix' macro presented in chapter 7.3.1 of 'Clojure in Action' to handle nested s-expressions: My first version did not work: (defmacro my-infix [expr] (if (coll? expr) (let [ [left op right] expr] (list op (my-infix left) (my-infix right))) expr)) ;; Test: (my-infix ((3 * 5) - (1 + 1))) ;; Wrong number of args (1) passed to: user$my-infix ;; [Thrown class java.lang.IllegalArgumentException] However, the following version does work: (defmacro new-infix [expr] (if (coll? expr) (let [ [left op right] expr] `(~op (new-infix ~left) (new-infix ~right))) expr)) (new-infix ((3 * 5) - (1 + 1))) ;; -- 13 (macroexpand '(new-infix ((3 * 5) - (1 + 1 ;; (- (user/new-infix (3 * 5)) (user/new-infix (1 + 1))) I would love to know why the first version 'my-infix' throws an exception. Can anybody give me a hint? I hope the answer could give me a better understanding of how macros work. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
Yup, I'm wrong. According to the profiler (visualvm), doseq/bit-shift-left is spending over 80% of its time in clojure.lang.Reflector.getMethods, but any other combination (e.g., dotimes/bsl or doseq/+) doesn't spend any time there at all. For 100k iterations, the doseq/bsl hits getMethods just over 100k times; the other combinations call it 18-27 times. Something is definitely weird here. On Sep 30, 9:52 pm, Mark Engelberg mark.engelb...@gmail.com wrote: On Thu, Sep 30, 2010 at 9:13 PM, ataggart alex.tagg...@gmail.com wrote: As with most microbenchmarks you're measuring the test more than the subject. In the above case the seq generation dominates. Compare the following on my machine: user= (time (doseq [x (range 10)] (bit-shift-left x 1))) Elapsed time: 3531.198 msecs nil user= (time (dotimes [x 10] (bit-shift-left x 1))) Elapsed time: 3.744 msecs nil But if you replace the bit-shift-left operation with some other arithmetic operation in the doseq expression, it is quite fast, thus disproving your assertion that the slowdown is caused by the overhead of doseq. Furthermore, as we've already discussed, type hinting the x or removing the inline delcaration from bit-shift-left makes the problem go away -- inside the doseq expression. So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: disk-backed memoize?
On Sep 18, 7:25 pm, David McNeil mcneil.da...@gmail.com wrote: http://github.com/alienscience/cache-dot-clj Thanks for the link. That is helpful. Would JDBC suit your needs as a storage medium? I suppose that would work, but I am thinking that an ehcache based plugin forcache-dot-cljmight be a good solution. I've released cache-dot-clj version 0.0.3 and have added an ehcache based plugin. Saul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
On Fri 01/10/10 06:52 , Mark Engelberg mark.engelb...@gmail.com sent: On Thu, Sep 30, 2010 at 9:13 PM, ataggart agg...@gmail.com wrote: As with most microbenchmarks you're measuring the test more than the subject. In the above case the seq generation dominates. Compare the following on my machine: user= (time (doseq [x (range 10)] (bit-shift-left x 1))) Elapsed time: 3531.198 msecs nil user= (time (dotimes [x 10] (bit-shift-left x 1))) Elapsed time: 3.744 msecs nil But if you replace the bit-shift-left operation with some other arithmetic operation in the doseq expression, it is quite fast, thus disproving your assertion that the slowdown is caused by the overhead of doseq. Furthermore, as we've already discussed, type hinting the x or removing the inline delcaration from bit-shift-left makes the problem go away -- inside the doseq expression. So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to cloj u...@googlegroups.comnote that posts from new members are moderated - please be patient with your first post.To unsubscribe from this group, send email to clojure+ unsubscr...@googlegroups.comfor more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. [Oops - sorry for the blank email] I notice, that If you enable *warn-on-reflection*, you can see that a call using the inline version gets compiled as a reflective call. If you remove the inline definition, no such reflective call is made. Not sure why this is. -- Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Handling keystrokes
This is a Clojure Java interop problem.If you are doing GUI programming with Swing in Clojure this is a real problem. The question is how do you subclass (?) a built-in swing operation to extend it to include your own code.After the paste, I want to do something to the pasted text.This is done all the time, but I have no idea how to do it in Clojure. Bill On Sep 30, 8:16 am, Laurent PETIT laurent.pe...@gmail.com wrote: You have probably mistaken this clojure group for another ... 2010/9/30 WoodHacker ramsa...@comcast.net I have a keyboard paste problem, but I think it has more general interest. When the user types Control V in a JTextPane, data from the clipboard will be pasted into the text. I want to act on that pasted text. I can easily capture the keystroke. The problem is that my capture takes place BEFORE the actual paste. What do I do to make my handler occur AFTER the paste? Bill -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: anonymous fn or partial?
Am 30.09.2010 13:46, schrieb Nicolas Oury: Note that you can't make readermacros yet. It's a supported in CL not in Clojure but maybe in future versions how knows. I meant, if you want to modify Clojure to allow a shorter notation for partial application, it is better to add a reader macro (directly in Clojure) than to change evaluation semantic I am not sure it is a good idea anyway... I brought this issue up in late 2008 and Rich decided against a reader macro for that, as there already is the #() notation, which also has advantages over partial, namely allowing you to call macros. (map #(and true %) [1 2 3 nil 5]) == (1 2 3 nil 5) but (map (partial and true) [1 2 3 nil 5]) == Can't take value of a macro: #'clojure.core/and And this would also be the case for a currying reader macro. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: anonymous fn or partial?
There is a subtle difference in how fixed arguments are handled. partial evaluates the arguments only once while fn evaluates them on each call. For side-effects free code the former can yield better performance. To recap: (partial foo (baz 1 2)) == (let [b (baz 1 2)] (fn [ x] (apply foo b x)) As for syntax sugar, I would like to see the #() macro to be extended so that it curries when no implicit arguments are given: #(foo bar baz) = #(foo bar baz %) whilst keeping (and emphasising) partial for cases where evaluate-once semantics are required. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Macro Implementation: I Don't Understand This Error Message
2010/10/1 Stefan Rohlfing stefan.rohlf...@gmail.com: Dear Clojure Group, I wanted to expand the 'infix' macro presented in chapter 7.3.1 of 'Clojure in Action' to handle nested s-expressions: My first version did not work: (defmacro my-infix [expr] (if (coll? expr) (let [ [left op right] expr] (list op (my-infix left) (my-infix right))) expr)) ;; Test: (my-infix ((3 * 5) - (1 + 1))) ;; Wrong number of args (1) passed to: user$my-infix ;; [Thrown class java.lang.IllegalArgumentException] Macros a special functions meant to be called by the compiler during macro-expansion. But you a are calling a macro function directly in your function body, instead of generating code that will be expanded (calling your macro function) by the compiler: (defmacro my-infix [expr] (if (coll? expr) (let [ [left op right] expr] (list op `(my-infix ~left) `(my-infix ~right))) expr)) Jürgen -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: anonymous fn or partial?
There is a subtle difference in how fixed arguments are handled. partial evaluates the arguments only once while fn evaluates them on each call. For side-effects free code the former can yield better performance. To recap: Ah! What a nice caveat! (also applies to taking macros as arguments). Thanks for your insights, U -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
There is no java definition for (Number, long) or (Number, int). As 1 is now a primitive, I think it cannot find any corresponding function. Strangely, putting 1M or (num 1) might be faster. Can someone try? On Fri, Oct 1, 2010 at 10:28 AM, David Powell djpow...@djpowell.net wrote: So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. [Oops - sorry for the blank email] I notice, that If you enable *warn-on-reflection*, you can see that a call using the inline version gets compiled as a reflective call. If you remove the inline definition, no such reflective call is made. Not sure why this is. -- Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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 -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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
Not sure if it's a bug or not
Hi : In my web project the namespace is jinrou-clojure.army, and the file is at jinrou-clojure/army.clj, most the the classes are compiled to jinrou_clojure directory, but some files with name army$reify__3155.class are compiled into jinrou-clojure/army directory ( note: it's a - , not a _ like most of the files, which I think it should be _ like most of the files ) I am using leiningen with leiningen-war to compile the file though. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Not sure if it's a bug or not
2010/10/1 sailormoo...@gmail.com sailormoo...@gmail.com Hi : In my web project the namespace is jinrou-clojure.army, and the file is at jinrou-clojure/army.clj, I guess your file is at jinrou_clojure/army.clj, and not jinrou-clojure/army.clj This is a known bug I reported two weeks ago, and has just been vetted by Stu Halloway. For the moment, the workaround is to not use dashes where/if it causes problems. most the the classes are compiled to jinrou_clojure directory, but some files with name army$reify__3155.class are compiled into jinrou-clojure/army directory ( note: it's a - , not a _ like most of the files, which I think it should be _ like most of the files ) I am using leiningen with leiningen-war to compile the file though. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Way to Build String or Simply Use StringBuilder
On Sep 30, 2010, at 10:37 PM, HiHeelHottie wrote:
(ns test-test.parse
(:use [clojure.contrib.string :only (split)]))
(defn parse-char [m c]
(condp = (:state m)
:degree (cond
(Character/isDigit c) (assoc m :degree (+ (* (:degree
m) 10) (Character/digit c 10)))
(Character/isWhitespace c) (assoc
m :state :whitespace :buf (conj (:buf m) (:degree m) ) :degree 0))
:whitespace (cond
(Character/isDigit c) (assoc
m :state :degree :degree (+ (* (:degree m) 10) (Character/digit c
10)))
(Character/isWhitespace c) m)))
(defn parse [s]
(let [m (reduce parse-char {:state :degree :degree 0 :buf []} (str s
))]
(apply str (:buf m
(println (parse 1 2 33))
One minor improvement would be to use clojure.string/join instead of str. That
way you won't have to manually append a space after each number in :buf (nor
use apply).
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Macro Implementation: I Don't Understand This Error Message
On Oct 1, 3:59 am, Stefan Rohlfing stefan.rohlf...@gmail.com wrote:
I wanted to expand the 'infix' macro presented in chapter 7.3.1 of
'Clojure in Action' to handle nested s-expressions:
My first version did not work:
(defmacro my-infix [expr]
(if (coll? expr)
(let [ [left op right] expr]
(list op (my-infix left) (my-infix right)))
expr))
;; Test:
(my-infix ((3 * 5) - (1 + 1)))
;; Wrong number of args (1) passed to: user$my-infix
;; [Thrown class java.lang.IllegalArgumentException]
I would love to know why the first version 'my-infix' throws an
exception. Can anybody give me a hint? I hope the answer could give me
a better understanding of how macros work.
I think I can explain - someone correct me if I'm wrong.
The problem occurs while my-infix is being compiled. As the compiler
works its way into the body of my-infix, it comes across a call to
something called my-infix. Intuitively, you would expect that since my-
infix is a macro (or is it? more to come), the compiler would call it
then-and-there - but how could it? my-infix hasn't even finished
compiling, so how could it possibly be called?
So my next thought is that it should be an error - and this may very
well be true. But it seems that what actually happens is that the my-
infix var is in a sort of intermediate state - it exists, which is why
the compiler doesn't complain, but it has not yet been flagged as
being a macro. Try this:
(defmacro ct-prn [expr] ; compile-time prn
(prn (eval expr))
expr)
(defmacro my-infix [expr]
(ct-prn (meta #'my-infix))
(if (coll? expr)
(let [ [left op right] expr]
(list op (my-infix left) (my-infix right)))
expr))
(prn (meta #'my-infix))
Here's what I get printed out:
{:ns #Namespace user, :name my-infix}
{:macro true, :ns #Namespace user, :name my-infix, :file C:\\Temp\
\temp.clj, :line 5, :arglists ([expr])}
So while compiling, my-infix is not yet flagged as a macro, so the
call to it gets compliled into a regular, run-time call to a function.
Still this seems like it should be OK - what's up with the Wrong
number of args (1)... stuff? Isn't 1 the right number of args for my-
infix?
Actually, it's not. That's becuase the compiler inserts a couple of
extra implicit arguments to all calls to macros. So in fact, my-infix,
at runtime, expects 3 arguments. Check this out:
user= (defmacro foo [x] x)
#'user/foo
user= (foo 23)
23
user= (def foo2 (var-get #'foo))
#'user/foo2
user= (foo2 23)
java.lang.IllegalArgumentException: Wrong number of args (1) passed
to: user$foo (NO_SOURCE_FILE:0)
user= (foo2 23 34 45)
45
I hope that makes it clearer. I certainly feel like I understand
macros a little better after figuring this out.
As for what exactly the two implicit args to macros are - I don't
know. Someone else will have to explain that.
- Chris
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problems Running tests with fixtures
Hmmm, I'm using clojure 1.2. I'll try out 1.3 when I get home.
Thanks
Tim
On Thu, Sep 30, 2010 at 10:09 PM, Sean Corfield seancorfi...@gmail.comwrote:
On Thu, Sep 30, 2010 at 2:44 PM, Timothy Washington twash...@gmail.com
wrote:
Just in case anyone comes across this, I did get around it. In fig. 2 I
was
trying to run (use-fixtures) twice. One with a :once, and one with :each.
I just tried that and it worked fine for me:
(ns utest)
(use 'clojure.test)
(defn f [x] (println f before) (x) (println f after))
(use-fixtures :each f)
(defn g [x] (println g1)(x)(println g2))
(use-fixtures :once g)
(deftest test-me (is ( = 1 1)))
(deftest test-me-2 (is ( = 2 2 )))
(run-tests)
Produced:
Testing utest
g1
f before
f after
f before
f after
g2
Ran 2 tests containing 2 assertions.
0 failures, 0 errors.
{:type :summary, :pass 2, :test 2, :error 0, :fail 0}
I'm using Clojure 1.3.0 master.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
If you're not annoying somebody, you're not really alive.
-- Margaret Atwood
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
David pointed out what should have been the obvious overhead (I'll blame it on being up at 2am), and Nicolas pointed out the specific problem. Compare: user= (time (doseq [x (range 10)] (bit-shift-left x 1))) Reflection warning, NO_SOURCE_PATH:4 - call to shiftLeft can't be resolved. Reflection warning, NO_SOURCE_PATH:4 - call to shiftLeft can't be resolved. Elapsed time: 3572.769 msecs nil user= (time (doseq [x (range 10)] (bit-shift-left (long x) 1))) Elapsed time: 19.585 msecs user= (time (let [i (Long. 1)] (doseq [x (range 10)] (bit-shift- left x i Elapsed time: 25.228 msecs nil So now that literals are long primitives, there are areas where the inlined static methods' param types no longer align with the arg types, triggering reflection and a performance hit. Of course *warn- on-reflection* reveals the problem, but that may be cold comfort to extant systems wishing to move to 1.3. On Oct 1, 6:01 am, Nicolas Oury nicolas.o...@gmail.com wrote: There is no java definition for (Number, long) or (Number, int). As 1 is now a primitive, I think it cannot find any corresponding function. Strangely, putting 1M or (num 1) might be faster. Can someone try? On Fri, Oct 1, 2010 at 10:28 AM, David Powell djpow...@djpowell.net wrote: So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. [Oops - sorry for the blank email] I notice, that If you enable *warn-on-reflection*, you can see that a call using the inline version gets compiled as a reflective call. If you remove the inline definition, no such reflective call is made. Not sure why this is. -- Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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 -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
David pointed out what should have been the obvious overhead (I'll blame it on being up at 2am), and Nicolas pointed out the specific problem. two solutions: - writing all combinations of unboxed/boxed for every function - having a more clever code generator that try to box every primitive if it allows to prevent a reflective call. (And maybe emit a boxing warning) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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
Screencast of the Emacs front end to the Clojure Debugging Toolkit:
For your delectation: http://www.vimeo.com/15462015 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-mode bug in Emacs
I see the problem with clojure-mode versions 1.5 and 1.7.1 (I haven't tried any others). I do not use paredit. Not happening with the version i am using. Do you use paredit? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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
clojure-contrib 1.3.0-SNAPSHOT new combined targets
Fixes to the build provided by Andreas Brenk, who has just mailed a CA. You can now have a dependency on all modules in clojure-contrib with the following dependency targets: Dependency on single, large JAR: groupId: org.clojure.contrib artifactId: standalone version: 1.3.0-SNAPSHOT Dependency on multiple, small JARs: groupId: org.clojure.contrib artifactId: complete version: 1.3.0-SNAPSHOT Thanks for your patience, and thanks to Andreas for contributing the fixes. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
I'm working on the latter right now. Note there's already a ticket for the reflection problem: https://www.assembla.com/spaces/clojure/tickets/446 On Oct 1, 12:24 pm, Nicolas Oury nicolas.o...@gmail.com wrote: David pointed out what should have been the obvious overhead (I'll blame it on being up at 2am), and Nicolas pointed out the specific problem. two solutions: - writing all combinations of unboxed/boxed for every function - having a more clever code generator that try to box every primitive if it allows to prevent a reflective call. (And maybe emit a boxing warning) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Screencast of the Emacs front end to the Clojure Debugging Toolkit:
I don't have time to watch the whole thing until I get home from work, but just hearing the first 30 seconds has me drooling all over myself... On Oct 1, 1:32 pm, George Jahad cloj...@blackbirdsystems.net wrote: For your delectation:http://www.vimeo.com/15462015 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Little LISPer and Ten Commandments
Yeah, it has been a good educational resource for working through. I'm not finished, but I've put the Clojure version of all the code up here: https://www.assembla.com/code/little_clojure/subversion/nodes Looking forward to those last couple chapters. msd -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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
relational data aggregation language
Hi, This is probably an abuse of the Clojure forum, but it is a bit Clojure-related and strikes me as the sort of thing that a bright, eclectic bunch of Clojure users might know about. (Plus I'm not really a software person, so I need all the help I can get.) I am looking at the possibility of finding/building a declarative data aggregation language operating on a small relational representation. Each query identifies a set of rows satisfying some relational predicate and calculates some aggregate function of a set of values (e.g. min, max, sum). There might be ~20 input tables of up to ~1k rows. The data is immutable - it gets loaded and never changed. The results of the queries get loaded as new rows in other tables and are eventually used as input to other computations. There might be ~1k queries. There is no requirement for transaction management or any inherent concurrency (there is only one consumer of the results). There is no requirement for persistent storage - the aggregation is the only thing of interest. I would like the query language to map as directly as possible to the task (SQL is powerful enough, but can get very contorted and opaque for some of the queries). There is considerable scope for optimisation of the calculations over the total set of queries as partial results are common across many of the queries. I would like to be able to do this in Clojure (which I have not yet used), partly for some very practical reasons to do with Java interop and partly because Clojure looks very cool. * Is there any existing Clojure functionality which looks like a good fit to this problem? I have looked at Clojure-Datalog. It looks like a pretty good fit except that it lacks the aggregation operators. Apart from that the deductive power is probably greater than I need (although that doesn't necessarily cost me anything). I know that there are other (non- Clojure) Datalog implementations that have been extended with aggregation operators (e.g. DLV http://www.mat.unical.it/dlv-complex/dlv-complex). Tutorial D (what SQL should have been http://en.wikipedia.org/wiki/D_%28data_language_specification%29#Tutorial_D) might be a good fit, although once again, there is probably a lot of conceptual and implementation baggage (e.g. Rel http://dbappbuilder.sourceforge.net/Rel.php) that I don't need. * Is there a Clojure implementation of something like Tutorial D? If there is no implementation of anything that meets my requirements then I would be willing to look at the possibility of creating a Domain Specific language. However, I am wary of launching straight into that because of the probability that anything I dreamed up would be an ad hoc kludge rather than a semantically complete and consistent language. Optimised execution would be a whole other can of worms. * Does anyone know of any DSLs/formalisms for declaratively specifying relational data aggregations? Thanks Ross -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Screencast of the Emacs front end to the Clojure Debugging Toolkit:
Fantastic work George! On Oct 1, 4:32 pm, George Jahad cloj...@blackbirdsystems.net wrote: For your delectation:http://www.vimeo.com/15462015 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Calling macros by var
On Thu, Sep 30, 2010 at 11:09 PM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 01.10.2010, at 03:07, Phil Hagelberg wrote: I suspect the answer may just be yeah... that's not something you should do with macros, but I'm curious. I suppose the compiler only checks the :macro metadata when it's literally in the call position rather than when there's indirection through calling var? Right. I use this for macro testing from the REPL for convenience, so I hope this won't change. According to chouser in IRC it's undefined behaviour. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Screencast of the Emacs front end to the Clojure Debugging Toolkit:
On Fri, Oct 1, 2010 at 1:32 PM, George Jahad cloj...@blackbirdsystems.net wrote: For your delectation: http://www.vimeo.com/15462015 This is great; the ability to jump between Clojure and Java is really impressive. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Screencast of the Emacs front end to the Clojure Debugging Toolkit:
That's some great work there, George! Are there any basic obstructions in the backend to doing expression-oriented rather than line-oriented breakpoints and stepping? -Per On Sat, Oct 2, 2010 at 3:32 AM, George Jahad cloj...@blackbirdsystems.net wrote: For your delectation: http://www.vimeo.com/15462015 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: relational data aggregation language
Hi Ross,
I am working on something that may be of help to you, but it's very
early in development.
Basically I wanted to see if I could write a database server in
Clojure and what I have now sounds (kinda) like what you're after. It
was really simple.
Imagine a list of maps as a database table. To query the structure
we simply filter that list based on some predicate, and now you have a
new structure. My select function takes a database (a map of maps) a
table name and a predicate and does exactly that. Then, arbitrary
functions can be applied to the result. For example, suppose the
result is as follows:
({:name Daniel :salary 1000} {:name Ross :salary 1500})
The total of salaries can be calculated like this:
(defn sum [attr relation]
(reduce + (map attr relation)))
(sum :salary results)
2500
You can see how min, max and friends could just as easily be
implemented.
As far as building the database, I use classes as keys for the tables
and instances of those classes are the tuples (see defrecord). In
that sense what I have is declarative; the database is built by
successively applying Clojure functions to Clojure data structures.
Does this sound like something you could use? I'm happy to share it.
Daniel Phelps
On Oct 1, 8:55 pm, Ross Gayler r.gay...@gmail.com wrote:
Hi,
This is probably an abuse of the Clojure forum, but it is a bit
Clojure-related and strikes me as the sort of thing that a bright,
eclectic bunch of Clojure users might know about. (Plus I'm not really
a software person, so I need all the help I can get.)
I am looking at the possibility of finding/building a declarative data
aggregation language operating on a small relational representation.
Each query identifies a set of rows satisfying some relational
predicate and calculates some aggregate function of a set of values
(e.g. min, max, sum). There might be ~20 input tables of up to ~1k
rows. The data is immutable - it gets loaded and never changed. The
results of the queries get loaded as new rows in other tables and are
eventually used as input to other computations. There might be ~1k
queries. There is no requirement for transaction management or any
inherent concurrency (there is only one consumer of the results).
There is no requirement for persistent storage - the aggregation is
the only thing of interest. I would like the query language to map as
directly as possible to the task (SQL is powerful enough, but can get
very contorted and opaque for some of the queries). There is
considerable scope for optimisation of the calculations over the total
set of queries as partial results are common across many of the
queries.
I would like to be able to do this in Clojure (which I have not yet
used), partly for some very practical reasons to do with Java interop
and partly because Clojure looks very cool.
* Is there any existing Clojure functionality which looks like a good
fit to this problem?
I have looked at Clojure-Datalog. It looks like a pretty good fit
except that it lacks the aggregation operators. Apart from that the
deductive power is probably greater than I need (although that doesn't
necessarily cost me anything). I know that there are other (non-
Clojure) Datalog implementations that have been extended with
aggregation operators (e.g.
DLVhttp://www.mat.unical.it/dlv-complex/dlv-complex).
Tutorial D (what SQL should have
beenhttp://en.wikipedia.org/wiki/D_%28data_language_specification%29#Tuto...)
might be a good fit, although once again, there is probably a lot of
conceptual and implementation baggage (e.g.
Relhttp://dbappbuilder.sourceforge.net/Rel.php)
that I don't need.
* Is there a Clojure implementation of something like Tutorial D?
If there is no implementation of anything that meets my requirements
then I would be willing to look at the possibility of creating a
Domain Specific language. However, I am wary of launching straight
into that because of the probability that anything I dreamed up would
be an ad hoc kludge rather than a semantically complete and consistent
language. Optimised execution would be a whole other can of worms.
* Does anyone know of any DSLs/formalisms for declaratively specifying
relational data aggregations?
Thanks
Ross
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: relational data aggregation language
Thanks Daniel,
That sounds like it's in the right direction (although that is
probably true of anything that gives database-like functionality).
I would need some filtered-join-like functionality between tables in
order to select some of the rows of interest.
As to the declarative part: leaving aside the terminology (which I am
probably abusing) I currently have a bunch of colleagues who are even
less computer literate than me doing these queries in an imperative
language and it is a wonderfully fertile breeding ground for errors.
(If you really want to know, they are statisticians using SAS to
calculate things like Over all the companies of which this person was
a director at the time a loan application was made, count the number
of loan applications made in the last year where the purpose was debt
restructuring and the amount sought was less than $100k). I guess I
was trying to achieve two things by asking for a declarative query
language: 1) reduce the accidental complexity of the specification,
thereby reducing the opportunity for specification error, 2) I
presumed that optimizing the calculation would be easier from a
declarative specification (because there is no baked in ordering of
operations).
I think my next steps are to collect a small zoo (maybe only a
menagerie) of different query languages; assemble a collection of test
queries; code the queries in each of the query languages as a pencil
and paper exercise (or in the real software if it is trivial enough to
set up); try to rank the different query languages by usability for my
colleagues, potential for optimization, and compatibility with our
software environment and my minimal computing skills.
Does this sound like something you could use? I'm happy to share it.
Thanks. That would be great. At this stage (not knowing Clojure more
than a tiny bit) I'm likely to make the most use of examples of how it
would be used.
Cheers
Ross Gayler
On Oct 2, 2:26 pm, Daniel Phelps phelps...@gmail.com wrote:
Hi Ross,
I am working on something that may be of help to you, but it's very
early in development.
Basically I wanted to see if I could write a database server in
Clojure and what I have now sounds (kinda) like what you're after. It
was really simple.
Imagine a list of maps as a database table. To query the structure
we simply filter that list based on some predicate, and now you have a
new structure. My select function takes a database (a map of maps) a
table name and a predicate and does exactly that. Then, arbitrary
functions can be applied to the result. For example, suppose the
result is as follows:
({:name Daniel :salary 1000} {:name Ross :salary 1500})
The total of salaries can be calculated like this:
(defn sum [attr relation]
(reduce + (map attr relation)))
(sum :salary results)
2500
You can see how min, max and friends could just as easily be
implemented.
As far as building the database, I use classes as keys for the tables
and instances of those classes are the tuples (see defrecord). In
that sense what I have is declarative; the database is built by
successively applying Clojure functions to Clojure data structures.
Does this sound like something you could use? I'm happy to share it.
Daniel Phelps
On Oct 1, 8:55 pm, Ross Gayler r.gay...@gmail.com wrote:
Hi,
This is probably an abuse of the Clojure forum, but it is a bit
Clojure-related and strikes me as the sort of thing that a bright,
eclectic bunch of Clojure users might know about. (Plus I'm not really
a software person, so I need all the help I can get.)
I am looking at the possibility of finding/building a declarative data
aggregation language operating on a small relational representation.
Each query identifies a set of rows satisfying some relational
predicate and calculates some aggregate function of a set of values
(e.g. min, max, sum). There might be ~20 input tables of up to ~1k
rows. The data is immutable - it gets loaded and never changed. The
results of the queries get loaded as new rows in other tables and are
eventually used as input to other computations. There might be ~1k
queries. There is no requirement for transaction management or any
inherent concurrency (there is only one consumer of the results).
There is no requirement for persistent storage - the aggregation is
the only thing of interest. I would like the query language to map as
directly as possible to the task (SQL is powerful enough, but can get
very contorted and opaque for some of the queries). There is
considerable scope for optimisation of the calculations over the total
set of queries as partial results are common across many of the
queries.
I would like to be able to do this in Clojure (which I have not yet
used), partly for some very practical reasons to do with Java interop
and partly because Clojure looks very cool.
* Is there any existing Clojure functionality which looks like a
Re: clojure-contrib 1.3.0-SNAPSHOT new combined targets
Excellent! Thanx for this! On Fri, Oct 1, 2010 at 2:20 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: Fixes to the build provided by Andreas Brenk, who has just mailed a CA. You can now have a dependency on all modules in clojure-contrib with the following dependency targets: Dependency on single, large JAR: groupId: org.clojure.contrib artifactId: standalone version: 1.3.0-SNAPSHOT Dependency on multiple, small JARs: groupId: org.clojure.contrib artifactId: complete version: 1.3.0-SNAPSHOT Thanks for your patience, and thanks to Andreas for contributing the fixes. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts 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
