Any wisdom in the math speed of different clojure libraries?
user (time (dotimes [i 10] (contribmath-ceil (rand Elapsed time: 4500.530303 msecs nil user (time (dotimes [i 10] (contribgenericmath-ceil (rand Elapsed time: 44.707193 msecs nil user (time (dotimes [i 10] (incanterprocessing-ceil (rand Elapsed time: 38.322599 msecs nil user (time (dotimes [i 10] (inc (int (rand) Elapsed time: 28.939557 msecs Observing the huge differences in speed of certain math functions in different clojure libraries, I was wondering if anyone knows which clojure math library is fastest in general? Is there any wisdom in this, or is it just up to users to check for each function where to get an efficient implementation. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?
On May 3, 12:38 am, bOR_ boris.sch...@gmail.com wrote: user (time (dotimes [i 10] (contribmath-ceil (rand Elapsed time: 4500.530303 msecs nil user (time (dotimes [i 10] (contribgenericmath-ceil (rand Elapsed time: 44.707193 msecs nil user (time (dotimes [i 10] (incanterprocessing-ceil (rand Elapsed time: 38.322599 msecs nil user (time (dotimes [i 10] (inc (int (rand) That's a terrible ceil method: (inc (int 0)) is 1. The reason it's fast is that (int x) is a java primitive. It acts like the *floor* function, making it not useful to you. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Serialising functions...
see inline
On Friday, 29 April 2011 04:25:58 UTC+1, kovasb wrote:
Thats some serious hacking. Definitely agree that distributed clojure
would be awesome.
Two points/questions:
1) Is this just a bug in DynamicClassLoader? Why doesn't it call
super.defineClass instead of falling back on the URLClassLoader?:
public Class defineClass(String name, byte[] bytes){
return defineClass(name, bytes, 0, bytes.length);
}
I wondered this.
Perhaps the guy who wrote it thought it conceptually cleaner to map his
defineClass into another method at the same inheritance-level, rather than
super, or he intended that you be able to make use of the UCL fn-ality
within DCL, or that it is just how the code has turned out after being
edited several times by several people
If it simply called super, then I believe I can pass in the right
bytecode preserving class with the context class loader, thus
avoiding modifications to the clojure source.
You could try patching it to do so, so that you could try out your approach.
If it is successful it might provide a less intrusive way of achieving the
same thing. I have messed wih ClassLoaders before and just took the simplest
approach that I could see to get where I wanted to go. I did try aspecting
the DCL to get my bytecode memo table working without code modification - no
joy, but I can't remember if I tried slipping my own ClassLoader into the
hierarchy...
Given that, without my patch, there are no URLs to fall back on, would the
code not fall through and do what you want to do anyway ?
2) Do you know how to serialize an entire namespace? This largely
avoids the issue of closures.
I haven't tried this - you are ahead of me here.
Right now I'm serializing the classes, and serializing all the vars in
the NS, and then containing them in some ad-hoc format on disk.
Obviously this somehow can be done with a single class, but how the
compiler does it is too hairy for me to understand.
This sounds like a bit more of a challenge.
Is the idea that you are dynamically creating a namespace and then
dynamically creating types/functions within it and that you then want to
persist/migrate this construct ?
I haven't investigated how ns-es are implemented, but I expect that you are
going to have to chase down a list of nested references and ensure that you
have marshalled up everything that you need. Along the way, you will
probably have to filter out references to other static ns-es on which you
depend.
This sounds like the sort of code that I would want to write in Clojure
rather than in Java. You are likely to come across types that are not
serialisable as well and have to write custom serialisation routines for
them.
Sounds interesting :-) - wish I could help more - please keep the list
posted.
Jules
On Thu, Apr 28, 2011 at 9:28 AM, Jules jules@gmail.com wrote:
well spotted :-)
I have ported it up to 1.3.0-alpha5 - alpha6 gave me some trouble that I
haven't had time to sort out.
[BTW - the following is from memory]
You set the JVM's UID via a sys property.
If this property is set it is incorporated into the names of new classes
created in this JVM.
The DynamicClassLoader maintains a map of classname : bytecode.
I run a Jetty in this JVM which knows how to respond to URLClassLoader
requests for class bytecode by looking them up in this map.
I think I hacked DynamicClassLoader (which ?inherits? from
URLClassLoader)
so that you can optionally set a system property that is a URL from which
it
can request classes that it cannot find locally. So you do this on client
JVMs
Putting this all together, you can basically create types/fns on the-fly
in
a one JVM, serialise instances of these and send them to another JVM,
then
deserialise them (transparently pulling their class over from their
parent
JVM) and use them as if they had been created at compile rather than
runtime.
This plugs what I have found to be a bit of a hole in Clojure, namely
dynamism is great, but I want to use it in a distributed app...
The patches are not prodction ready, but I have been using them for some
time with no problem. I'd be very happy to find other people with similar
interest, improve the patches and see if we can persuade the powers that
be
to accept them or something providing similar fn-ality into e.g.
Clojure-1.4
:-)
If you need any help getting this stuff to work, just shout.
Jules
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
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
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are
Key order of literal maps
Hey everyone,
I'm busy implementing a macro whose usage looks like this:
(defentity Person
{:name {:type String :validator name-validator}
:id-number {:type String :validator id-number-validator}
:height{:type Float :default 0.0}
:weight{:type Float :default 0.0}
:bmi {:type Float :internal true}})
The macro generates a defrecord like so:
(defrecord Person [name id-number height weight bmi])
Which can later be used in the application like this:
(Person. David 123 1 2 3)
Obviously the argument order is important. So my question is:
Can I rely on (keys some-literal-map) always returning the keys in the
order they were defined in the literal map? In my experiment, a map
literal will create a PersistentArrayMap which I understand has sorted
keys. Can someone confirm that this is reliable (e.g. across
implementations?)
Thanks!
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Any wisdom in the math speed of different clojure libraries?
Why not? user (time (dotimes [_ 10] (Math/ceil 0.1))) Elapsed time: 626.867 msecs David On Tue, May 3, 2011 at 3:38 AM, bOR_ boris.sch...@gmail.com wrote: user (time (dotimes [i 10] (contribmath-ceil (rand Elapsed time: 4500.530303 msecs nil user (time (dotimes [i 10] (contribgenericmath-ceil (rand Elapsed time: 44.707193 msecs nil user (time (dotimes [i 10] (incanterprocessing-ceil (rand Elapsed time: 38.322599 msecs nil user (time (dotimes [i 10] (inc (int (rand) Elapsed time: 28.939557 msecs Observing the huge differences in speed of certain math functions in different clojure libraries, I was wondering if anyone knows which clojure math library is fastest in general? Is there any wisdom in this, or is it just up to users to check for each function where to get an efficient implementation. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Let over defmacro
Hello,
Evaluating the form
(let [cache (atom {})]
(defmacro eval-cached
Just as eval, however it will return an existing object if it has
already been evaluated with it
[obj]
(when-not (contains? @cache obj)
(reset! cache (assoc @cache obj (eval obj
(@cache obj))
(defmacro def-cached
Just as def, however it will return an existing object if it has
already been defined with it
[fname fbody]
(intern *ns* (symbol fname) (eval-cached fbody
Gives me a java.lang.UnsupportedOperationException: Can't eval locals
- for the last line of def-cached
However, when I use eval the first defmacro by itself as a closure -
it works perfectly. How can I make those share the cache state without
binding it to a public symbol ?
Best regards,
Stanislav Paskalev
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
[ANN] Lacij v.0.1 a graph visualization library
Hello, I would like to announce the version 0.1 of the Lacij library, a graph visualization library written in Clojure. I would be really happy with any feedbacks and comments, on the code or the architecture. Help is welcome to implement additional layout algorithms. From the README file: Lacij is a graph visualization library written in Clojure. It allows the display and the dynamic modification of graphs as SVG documents that can be viewed with a Web browser or with a Swing component. Undo/redo is supported for the dynamic modification. Automatic layout is provided for the visualization. The library is available on GitHub: https://github.com/pallix/lacij and on Clojars: http://clojars.org/lacij This library is being developed as part of the Carneades project: http://carneades.berlios.de/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Let over defmacro
Hello again,
This has solved the issue:
(let [cache (atom {})
cache-eval (fn [obj]
(when-not (contains? @cache obj)
(reset! cache (assoc @cache obj (eval obj
(@cache obj))]
(defmacro def-cached
Just as def, however it will return an existing object if it has
already been defined with it
[fname fbody]
(intern *ns* (symbol fname) (cache-eval fbody)))
(defmacro eval-cached
Just as eval, however it will return an existing object if it has
already been evaluated with it
[obj]
(cache-eval obj)))
However it'll be good if someone could share some insight why a macro
cannot call another one and what is the general solution in such a
case
Stanislav Paskalev
On Tue, May 3, 2011 at 3:50 PM, Stanislav Paskalev ksh...@gmail.com wrote:
Hello,
Evaluating the form
(let [cache (atom {})]
(defmacro eval-cached
Just as eval, however it will return an existing object if it has
already been evaluated with it
[obj]
(when-not (contains? @cache obj)
(reset! cache (assoc @cache obj (eval obj
(@cache obj))
(defmacro def-cached
Just as def, however it will return an existing object if it has
already been defined with it
[fname fbody]
(intern *ns* (symbol fname) (eval-cached fbody
Gives me a java.lang.UnsupportedOperationException: Can't eval locals
- for the last line of def-cached
However, when I use eval the first defmacro by itself as a closure -
it works perfectly. How can I make those share the cache state without
binding it to a public symbol ?
Best regards,
Stanislav Paskalev
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?
Because I did not remember Math/ceil :-). Point is, is there any consensus on what math library to use? Is (Math/... in general the fastest? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?
On Tue, May 3, 2011 at 9:50 AM, bOR_ boris.sch...@gmail.com wrote: Because I did not remember Math/ceil :-). Point is, is there any consensus on what math library to use? Is (Math/... in general the fastest? For basic math, I'm not sure what could be faster than Java primitive operators and methods. For more sophisticated things you'll probably have to look at the various Java libs which I'm not all that familiar with. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Key order of literal maps
Keys from literal maps aren't sorted; you need a sorted map.
user= (keys {:z 1 :f 2 :a 0})
(:z :a :f)
user= (keys (sorted-map :z 1 :f 2 :a 0))
(:a :f :z)
On May 3, 4:08 am, David Jagoe davidja...@gmail.com wrote:
Hey everyone,
I'm busy implementing a macro whose usage looks like this:
(defentity Person
{:name {:type String :validator name-validator}
:id-number {:type String :validator id-number-validator}
:height {:type Float :default 0.0}
:weight {:type Float :default 0.0}
:bmi {:type Float :internal true}})
The macro generates a defrecord like so:
(defrecord Person [name id-number height weight bmi])
Which can later be used in the application like this:
(Person. David 123 1 2 3)
Obviously the argument order is important. So my question is:
Can I rely on (keys some-literal-map) always returning the keys in the
order they were defined in the literal map? In my experiment, a map
literal will create a PersistentArrayMap which I understand has sorted
keys. Can someone confirm that this is reliable (e.g. across
implementations?)
Thanks!
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Multi-level bucketing problem
I'm sure this can be simplyfied:
(defn mlg [attrs data]
(if (empty? attrs)
[ (reduce + (map :mv data)) {:children data}]
(let [parts (group-by (first attrs) data)
subtrees (map (fn [[value data]]
[value (mlg (rest attrs) (map #(dissoc % (first
attrs)) data))])
parts)]
(reduce (fn [[sum tree] [value [sumsubtree subtree]]]
[(+ sum sumsubtree)
(update-in tree [:children] conj (assoc subtree
:path [(first attrs)
value]
:mv sumsubtree))]
)
[ 0.0 { :children [] }]
subtrees
Returns a pair with the sum for all items and a tree.
Each tree is represented as a dictionary, and inner nodes of the tree have
three keys:
- :mv the sum of :mv's of its children
- :path a pair of attr-value that represents all the leaves in the subtree
- :children the subtrees of this level
Leaves are represented as dictionaries with only the keys :sec_id and :mv.
Best regards,
Juan Manuel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Key order of literal maps
On May 3, 2011, at 7:08 AM, David Jagoe wrote: Can I rely on (keys some-literal-map) always returning the keys in the order they were defined in the literal map? In general, the key order is not guaranteed, but an array-map will maintain the insertion order of the keys. Use the array-map function to create one. There's a bit more info here: http://clojuredocs.org/clojure_core/clojure.core/array-map An array-map maintains the insertion order of the keys. Look up is linear, which is not a problem for small maps (say less than 10 keys). If your map is large, you should use hash-map instead. When you assoc onto an existing array-map, the result is a new array-map with the new key as the first key. The rest of the keys are in the same order as the original. Functions such as seq and keys will respect the key order. Note that assoc will decide to return a hash-map if the result is too big to be efficient. For your specific purpose, I would be careful about using a map as an entity specification. If the order is significant, a vector of field specifiers would be better. Instead of taking a map as the second argument to defentity, you could make it variadic like (defmacro defentity [ent specs] ...). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: RE: Multi-level bucketing problem
I'm sure this can be simplyfied:
(defn mlg [attrs data]
(if (empty? attrs)
[ (reduce + (map :mv data)) {:children data}]
(let [parts (group-by (first attrs) data)
subtrees (map (fn [[value data]]
[value (mlg (rest attrs) (map #(dissoc % (first
attrs)) data))])
parts)]
(reduce (fn [[sum tree] [value [sumsubtree subtree]]]
[(+ sum sumsubtree)
(update-in tree [:children] conj (assoc subtree
:path [(first
attrs) value]
:mv sumsubtree))]
)
[ 0.0 { :children [] }]
subtrees
Returns a pair with the sum for all items and a tree.
Each tree is represented as a dictionary, and inner nodes of the tree have
three keys:
- :mv the sum of :mv's of its children
- :path a pair of attr-value that represents all the leaves in the subtree
- :children the subtrees of this level
Leaves are represented as dictionaries with only the keys :sec_id and :mv.
I've forked your gist, so you can grab the code directly from
github https://gist.github.com/952861
Best regards,
Juan Manuel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: RE: Multi-level bucketing problem
Whoa! Thanks Juan. I will start to understand/analyze this...
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On
Behalf Of JuanManuel Gimeno Illa
Sent: Tuesday, May 03, 2011 11:40 AM
To: clojure@googlegroups.com
Subject: Re: RE: Multi-level bucketing problem
I'm sure this can be simplyfied:
(defn mlg [attrs data]
(if (empty? attrs)
[ (reduce + (map :mv data)) {:children data}]
(let [parts (group-by (first attrs) data)
subtrees (map (fn [[value data]]
[value (mlg (rest attrs) (map #(dissoc %
(first attrs)) data))])
parts)]
(reduce (fn [[sum tree] [value [sumsubtree subtree]]]
[(+ sum sumsubtree)
(update-in tree [:children] conj (assoc
subtree
:path
[(first attrs) value]
:mv
sumsubtree))]
)
[ 0.0 { :children [] }]
subtrees
Returns a pair with the sum for all items and a tree.
Each tree is represented as a dictionary, and inner nodes of the tree
have three keys:
- :mv the sum of :mv's of its children
- :path a pair of attr-value that represents all the leaves in the
subtree
- :children the subtrees of this level
Leaves are represented as dictionaries with only the keys :sec_id and
:mv.
I've forked your gist, so you can grab the code directly from github
https://gist.github.com/952861
Best regards,
Juan Manuel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from 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: Key order of literal maps
Thanks for the responses. On 3 May 2011 17:39, Steve Miner stevemi...@gmail.com wrote: On May 3, 2011, at 7:08 AM, David Jagoe wrote: For your specific purpose, I would be careful about using a map as an entity specification. If the order is significant, a vector of field specifiers would be better. Instead of taking a map as the second argument to defentity, you could make it variadic like (defmacro defentity [ent specs] ...). Yes, that looks like the solution. Thanks again. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Lacij v.0.1 a graph visualization library
Hi Pierre This looks very cool, I'd love to try it. The version on clojars is 0.1.0-SNAPSHOT, could you upload 0.1.0? How do you build it from source? I can't locate a build script. Thanks, Ambrose On Tue, May 3, 2011 at 9:26 PM, Pierre Allix pierre.allix.w...@googlemail.com wrote: Hello, I would like to announce the version 0.1 of the Lacij library, a graph visualization library written in Clojure. I would be really happy with any feedbacks and comments, on the code or the architecture. Help is welcome to implement additional layout algorithms. From the README file: Lacij is a graph visualization library written in Clojure. It allows the display and the dynamic modification of graphs as SVG documents that can be viewed with a Web browser or with a Swing component. Undo/redo is supported for the dynamic modification. Automatic layout is provided for the visualization. The library is available on GitHub: https://github.com/pallix/lacij and on Clojars: http://clojars.org/lacij This library is being developed as part of the Carneades project: http://carneades.berlios.de/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
I've previously linked[1] to my preview of Clojure Atlas – my attempt at producing a more useful, more tractable medium for understanding programming languages and the libraries that go along with them – so I won't repeat that material here. I did think I'd let the list know that Clojure Atlas is now available publicly however: http://clojureatlas.com And a few comments on its release are available on my blog[2]. There is a free (nagging) demo, but I assure you kittens will purr just for you if you support Clojure Atlas' future development with your purchase. FYI, you can currently get $10 off of Clojure Atlas for Clojure 1.3 when you preorder it now with your 1.2 purchase[3]. I suspect I'll not clutter up the ML with further announcements (though I'll happily answer questions, if any are posed), so make sure you follow @ClojureAtlas[4] or subscribe to updates by email[5] if you'd like to be notified as Clojure Atlas is expanded and improved. Thanks, - Chas [1] http://groups.google.com/group/clojure/browse_thread/thread/3b8e2eaed664e3ca [2] http://cemerick.com/2011/05/03/clojure-atlas-now-available/ [3] http://clojureatlas.com/buy [4] http://twitter.com/ClojureAtlas [5] http://www.clojureatlas.com/#status -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Let over defmacro
You had: (defmacro eval-cached [obj] (when-not (contains? @cache obj) (reset! cache (assoc @cache obj (eval obj (@cache obj)) and: (eval-cached fbody) This results in eval-cached being called with obj bound to the symbol 'fbody rather than to the second argument to def-cached -- probably not what you intended. It checks the cache for containing a value at the key 'fbody, fails, and so goes to create the entry -- and calls (eval 'fbody), rather than (eval the-code-you-passed-to-def-cached). You really did need a function and not a macro for eval-cached. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?
On Tue, May 3, 2011 at 8:03 AM, David Nolen dnolen.li...@gmail.com wrote: Why not? user (time (dotimes [_ 10] (Math/ceil 0.1))) Elapsed time: 626.867 msecs David It's optimizing your loop away, or else you're using ridiculously powerful hardware. user= (time (dotimes [_ 100] (Math/ceil (rand Elapsed time: 142.86748 msecs nil Making it a local of type double seems slightly faster: user= (time (dotimes [_ 100] (let [x (double (rand))] (Math/ceil x Elapsed time: 136.96752 msecs nil But to really time a ceil function we should have premade random numbers and avoid including their generation in the time. We'll also get rid of some boxing and function call overheads: user= (let [nums (double-array (repeatedly 100 rand))] (time (dotimes [i 100] (Math/ceil (aget nums i) Elapsed time: 47.99892 msecs nil Now the only things in the timing loop are: counting to 1 million, aget from a primitive array, and Math/ceil itself. That's about as good as it's gonna get. Substitute calls to other ceil implementations as appropriate. Oh, and by the way, (int x) is not quite floor either: user= (int -2.1) -2 It truncates towards 0 rather than -infinity. #(quot % 1) does the same thing (and is slower by nearly a factor of 10). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Monadic implementation of the Shunting-yard algorithm
I wrote a simple implementation: http://gist.github.com/953966https://gist.github.com/953966 (only supports operators) It's not very elegant (I don't know how to use fnparse..), but it is functional. What it does is find out what the next element in the operator stack and the out stack should be, and then recursively update the stacks and output the finished out stack. As I said I don't know how to use fnparse and therefore I couldn't really understand your code. Either way I hope that this code helps in some way.. ;) Jonathan On Tue, May 3, 2011 at 2:23 AM, Nicolas Buduroi nbudu...@gmail.com wrote: Hi, I'm working on my parsing skills using fnparse 2.2.7 and have written the following implementation of the Shunting-yard algorithm: https://gist.github.com/952607 I plan to make a lightning talk about monadic parser at the next Bonjure meeting and I'd like to hear what people here think about that implementation first. It is more imperative that I would like, but that is the nature of this algorithm I think. Would a non-monadic implementation would be better in some ways? How would you make this code more flexible, faster and/or cleaner? Is there a more functional way of writing it? Thanks in advance for any comments! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
On Tue, May 3, 2011 at 2:34 PM, Chas Emerick cemer...@snowtide.com wrote: There is a free (nagging) demo, but I assure you kittens will purr just for you if you support Clojure Atlas' future development with your purchase. You've put this thing behind a *paywall*? It's *information*. If you really want to monetize it you'll probably get far more by having it freely and easily accessible, so lots of people will link into it, and putting AdSense on every page. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
There is a free (nagging) demo, but I assure you kittens will purr just for you if you support Clojure Atlas' future development with your purchase. You know it's nice, the search is pretty cool. But it takes me longer to go and search, or to chase little (i) symbols around than it does to actually go to the repl and hit (doc assoc). Maybe it's just too much eye candy for my liking. Timothy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Monadic implementation of the Shunting-yard algorithm
On Mon, May 2, 2011 at 8:23 PM, Nicolas Buduroi nbudu...@gmail.com wrote: Is there a more functional way of writing it? If you have imperative code implementing a conceptually-pure function, the answer to this is always yes, in at least a trivial sense: you can write a pure-functional interpreter for the imperative code's language that that is something like (defn step [world-state] (apply-instruction (get-next-instruction world-state) world-state)) (defn run [program arg-list] (let [world-state (initial-state-for program arg-list)] (extract-output-from (first (drop-while #(not (done-state? %)) (iterate step world-state)) Here, get-next-instruction figures out what instruction to apply next from a world-state (e.g. it reads a program counter and then an opcode from an address); apply-instruction applies an instruction to a world-state to output a new world-state; initial-state-for? takes an imperative function and an argument list and returns an initial world-state for executing it in the virtual machine; done-state? checks if a world-state represents an imperative function that's finished running rather than still running; and extract-output-from extracts the return value of that program. If all of those are pure functions, then so is run. But I expect most who ask is there a more functional way of writing it? are hoping for something less trivial. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
On Tue, May 3, 2011 at 3:15 PM, Timothy Baldridge tbaldri...@gmail.com wrote: There is a free (nagging) demo, but I assure you kittens will purr just for you if you support Clojure Atlas' future development with your purchase. You know it's nice, the search is pretty cool. But it takes me longer to go and search, or to chase little (i) symbols around than it does to actually go to the repl and hit (doc assoc). Not to mention that (doc assoc) is free. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?
On Tue, May 3, 2011 at 2:51 PM, Ken Wesson kwess...@gmail.com wrote: It's optimizing your loop away, or else you're using ridiculously powerful hardware. user= (time (dotimes [_ 100] (Math/ceil (rand Elapsed time: 142.86748 msecs nil Maybe, maybe not: (do (set! *unchecked-math* true) (let [nums (double-array (repeatedly 1e3 rand))] (dotimes [_ 10] (time (dotimes [i 1e8] (Math/ceil (double (aget nums (rem i 1e3) Elapsed time: 1405.835 msecs (do (set! *unchecked-math* true) (let [nums (double-array (repeatedly 1e3 rand))] (dotimes [_ 10] (time (dotimes [i 1e8] (double (aget nums (rem i 1e3 Elapsed time: 1409.305 msecs Given that the i7 is far into the gigaflops territory, I don't find this particularly surprising. But I'm not a hardware architecture expert by any means nor an expert of what kind of magic the JVM can do. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
Boo. Keep the paywall. Don't make me look at ads. And for the record, you're not paying for information, but rather to have the information presented in a particular way. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
This is awesome job, Chas, thanks for creating this! 2011/5/3 Chas Emerick cemer...@snowtide.com I've previously linked[1] to my preview of Clojure Atlas – my attempt at producing a more useful, more tractable medium for understanding programming languages and the libraries that go along with them – so I won't repeat that material here. I did think I'd let the list know that Clojure Atlas is now available publicly however: http://clojureatlas.com And a few comments on its release are available on my blog[2]. There is a free (nagging) demo, but I assure you kittens will purr just for you if you support Clojure Atlas' future development with your purchase. FYI, you can currently get $10 off of Clojure Atlas for Clojure 1.3 when you preorder it now with your 1.2 purchase[3]. I suspect I'll not clutter up the ML with further announcements (though I'll happily answer questions, if any are posed), so make sure you follow @ClojureAtlas[4] or subscribe to updates by email[5] if you'd like to be notified as Clojure Atlas is expanded and improved. Thanks, - Chas [1] http://groups.google.com/group/clojure/browse_thread/thread/3b8e2eaed664e3ca [2] http://cemerick.com/2011/05/03/clojure-atlas-now-available/ [3] http://clojureatlas.com/buy [4] http://twitter.com/ClojureAtlas [5] http://www.clojureatlas.com/#status -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
On May 3, 2011, at 3:15 PM, Timothy Baldridge wrote: There is a free (nagging) demo, but I assure you kittens will purr just for you if you support Clojure Atlas' future development with your purchase. You know it's nice, the search is pretty cool. But it takes me longer to go and search, or to chase little (i) symbols around than it does to actually go to the repl and hit (doc assoc). Maybe it's just too much eye candy for my liking. Check out the 'help' link in the upper-right; you can hold down Ctrl while scrubbing over nodes to see docs, source, etc. Indeed, if you're just after (doc foo) for some known foo, Clojure Atlas has little to offer. The hope is that this will make it easier to (a) find an unknown bar that is relevant to the operation/data structure/etc you're working with, and (b) understand the relationships between different types, data structures, classes of operations, etc. And, yes, the overanimated quality of the visualization is the #1-reported problem so far. I've prioritized it appropriately. Thanks for the feedback, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any wisdom in the math speed of different clojure libraries?
On Tuesday, May 3, 2011 3:20:25 PM UTC-4, David Nolen wrote: On Tue, May 3, 2011 at 2:51 PM, Ken Wesson kwes...@gmail.com wrote: It's optimizing your loop away, or else you're using ridiculously powerful hardware. user= (time (dotimes [_ 100] (Math/ceil (rand Elapsed time: 142.86748 msecs nil Maybe, maybe not: Either way, it's got a weird profile (increasing, but not monotonically): user= (doseq [n (map #(Math/pow 10 %) (range 10))] (time (dotimes [_ n] (Math/ceil 0.1 Elapsed time: 0.238077 msecs Elapsed time: 0.007346 msecs Elapsed time: 0.030386 msecs Elapsed time: 0.255107 msecs Elapsed time: 10.399609 msecs Elapsed time: 5.677462 msecs Elapsed time: 1.423789 msecs Elapsed time: 9.779539 msecs Elapsed time: 65.505686 msecs Elapsed time: 651.333768 msecs nil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
On Tue, May 3, 2011 at 2:28 PM, Jeffrey Schwab j...@schwabcenter.comwrote: Boo. Keep the paywall. Don't make me look at ads. And for the record, you're not paying for information, but rather to have the information presented in a particular way. Well I think it's more of the case that with a paywall you'll get a very small number of people generating income. With ads every user could be generating ads. I don't know how many programs I don't use simply because it's a cool program but not $20 cool... From a business standpoint one as to ask if program X that costs Y will save developers Y worth of work. Timothy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
On May 3, 2011, at 3:28 PM, Jeffrey Schwab wrote: Boo. Keep the paywall. Don't make me look at ads. And for the record, you're not paying for information, but rather to have the information presented in a particular way. No worries, I've zero intention of using advertising of any sort. Besides it being a pitiful source of actual revenue except in very specific circumstances, I'd much rather optimize to make the product more useful for its users, rather than compromising it in various ways in the hopes of earning 5¢ from Google. - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
On Tuesday, May 3, 2011 3:31:33 PM UTC-4, tbc++ wrote: On Tue, May 3, 2011 at 2:28 PM, Jeffrey Schwab je...@schwabcenter.comwrote: Boo. Keep the paywall. Don't make me look at ads. And for the record, you're not paying for information, but rather to have the information presented in a particular way. Well I think it's more of the case that with a paywall you'll get a very small number of people generating income. With ads every user could be generating ads. I don't know how many programs I don't use simply because it's a cool program but not $20 cool... From a business standpoint one as to ask if program X that costs Y will save developers Y worth of work. Maybe the best model is: Ads by default, or pay your way out of them. /. has a nice implementation of this, where you can fine-tune the frequency with which you see ads. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: resultset-seq
Since this thread from October focused on clojure.core/resultset-seq,
I thought I'd bump it again in the context of the (new)
clojure.java.jdbc library (formerly clojure.contrib.sql).
In order to support naming strategies, c.j.j uses an internal,
modified copy of resultset-seq that allows you to control the way SQL
entity names are converted to keywords. The default is still
clojure.string/lower-case but you can override the behavior for calls
to c.j.j. Naming strategies also allow you to control how keywords are
converted to SQL entity names within c.j.j.
I'm undecided on whether to expose this function (it's currently
clojure.java.jdbc.internal/resultset-seq*) as part of the public API
for c.j.j. In favor of exposing it: it would provide a way to get the
behavior most people in this thread seem to want. Against exposing it:
potential confusion with the version in clojure.core?
This is the only decision I want to tie up before declaring a 0.0.1
release of c.j.j (and moving on to other requested enhancements for
0.0.2).
If anyone has any input...?
Sean
On Fri, Oct 15, 2010 at 2:04 PM, Laurent PETIT laurent.pe...@gmail.com wrote:
2010/10/15 Mark Engelberg mark.engelb...@gmail.com
On Fri, Oct 15, 2010 at 1:49 AM, David Powell djpow...@djpowell.net
wrote:
I'm in favour of down-casing - at least by default. Some processing is
going to happen anyway, as column names might contain spaces, which
wouldn't
be allowed in keywords.
--
Dave
One of the more significant nuisances in Clojure/Java interop is that
if you use some sort of wrapper library which converts Clojure things
to Java, and then converts from Java back to Clojure, you often end up
with something different than you started. Anywhere we can ameliorate
this, we should.
For example, if I create a table using clojure.contrib.sql, where the
column names are things like :numberOfApples, and then I load in a
bunch of maps of the form {:numberOfApples 2}, {:numberOfApples 5},
and so on, then when I fetch them out of the database, I really need
them to be {:numberOfApples 2}, etc. so that I can compare them with
the original maps used to fill the database to begin with.
Right now, I get back {:numberofapples 2}. Yes, SQL is usually case
insensitive, but Clojure is not, so everything breaks down if you
don't get back the maps in the form you started with. Since SQL
typically *stores* the column names internally in mixed case (even
though it ignores the case for querying purposes), you might as well
retrieve them in mixed case so it matches the form you started with.
Why would I write my column names using mixed case? Because I once
tried using :number-of-apples to match Clojure's conventions, but got
burned by a number of third-party tools gagging on the hyphens.
I guess most of the time column names are written with
names_separated_by_underscores, but anyway, it seems indeed weird that such
downcase is done, especially without any (or to come) good reason for that.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Closures in macros
Am 02.05.2011 23:14, schrieb David Nolen: The relevant clojure-dev thread. http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907ebca8ef6e11 It's not clear whether the core team and the various contributors are interested in supporting the behavior you want. It's also not clear whether the issue is matter of the difficulty of a good implementation or simply disinterest. Thanks for that link. I would really like to hear (read) a statement of one member of the core team. Some of the limitations: 1. (defmacro x [] `(let [a# ~(atom 0)])) 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) All three calls fail, (x) and (y) and (z). I see no plausible reason why it *should* be that way. Instead this is useful and idiomatic lisp. Normally I wanted to write: `(~(get @loggers level @logger) ~(get *level-name* level) ~domain ~msg ~e) The first get will see if for the given “level” there is a level specific log function. If not it will fall back to the default logger “logger”. So, “loggers” is a mapping from level to closures and “logger” is a closure. Those closures are functions that take 4 args: the log level, a domain, a message and an exception. Now I have to write instead (let [l (get @loggers level @logger) f (gensym logger)] (intern 'mylib.log f l) `(~f ~(get *level-name* level) ~domain ~msg ~e)) which is plain ugly. I need to artificially invent a name, pollute the NS of my logging lib and probably create less efficient code, because a lookup of my gensymed ~f will be required at runtime. Would be great if this could be fixed easily enough to get included in a (near) future version. Regards, André -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
which is the location for the latest data.finger-tree?
Hello everybody, Can somebody tell me as to which is the location for the current version of data.finger-tree .. the one I found via google was git://github.com/clojure/data.finger-tree.git 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
Re: which is the location for the latest data.finger-tree?
Yes, that is the latest source. One JAR has been released to the Maven Central Repository: http://repo2.maven.org/maven2/org/clojure/data.finger-tree/0.0.1/ -Stuart S clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: resultset-seq
IMHO c.j.j/resultset-seq should perform something like the following:
;; i want my columns as strings exactly how they are in the db
(resultset-seq rs)
(resultset-seq rs identity)
;; i want my columns as lower-case keywords
(resultset-seq rs (comp keyword lower-case))
;; i want my columns as upper-case symbols
(resultset-seq rs (comp symbol upper-case))
With the existing c.c/resultset-seq, I found myself converting the
keys back to strings in order to pass those results to some existing
Java code and templates for further processing. Most of the time the
lower-cased keyword keys were just fine.
Just my $0.02
Allen
On Tue, May 3, 2011 at 4:54 PM, Sean Corfield seancorfi...@gmail.com wrote:
Since this thread from October focused on clojure.core/resultset-seq,
I thought I'd bump it again in the context of the (new)
clojure.java.jdbc library (formerly clojure.contrib.sql).
In order to support naming strategies, c.j.j uses an internal,
modified copy of resultset-seq that allows you to control the way SQL
entity names are converted to keywords. The default is still
clojure.string/lower-case but you can override the behavior for calls
to c.j.j. Naming strategies also allow you to control how keywords are
converted to SQL entity names within c.j.j.
I'm undecided on whether to expose this function (it's currently
clojure.java.jdbc.internal/resultset-seq*) as part of the public API
for c.j.j. In favor of exposing it: it would provide a way to get the
behavior most people in this thread seem to want. Against exposing it:
potential confusion with the version in clojure.core?
This is the only decision I want to tie up before declaring a 0.0.1
release of c.j.j (and moving on to other requested enhancements for
0.0.2).
If anyone has any input...?
Sean
On Fri, Oct 15, 2010 at 2:04 PM, Laurent PETIT laurent.pe...@gmail.com
wrote:
2010/10/15 Mark Engelberg mark.engelb...@gmail.com
On Fri, Oct 15, 2010 at 1:49 AM, David Powell djpow...@djpowell.net
wrote:
I'm in favour of down-casing - at least by default. Some processing is
going to happen anyway, as column names might contain spaces, which
wouldn't
be allowed in keywords.
--
Dave
One of the more significant nuisances in Clojure/Java interop is that
if you use some sort of wrapper library which converts Clojure things
to Java, and then converts from Java back to Clojure, you often end up
with something different than you started. Anywhere we can ameliorate
this, we should.
For example, if I create a table using clojure.contrib.sql, where the
column names are things like :numberOfApples, and then I load in a
bunch of maps of the form {:numberOfApples 2}, {:numberOfApples 5},
and so on, then when I fetch them out of the database, I really need
them to be {:numberOfApples 2}, etc. so that I can compare them with
the original maps used to fill the database to begin with.
Right now, I get back {:numberofapples 2}. Yes, SQL is usually case
insensitive, but Clojure is not, so everything breaks down if you
don't get back the maps in the form you started with. Since SQL
typically *stores* the column names internally in mixed case (even
though it ignores the case for querying purposes), you might as well
retrieve them in mixed case so it matches the form you started with.
Why would I write my column names using mixed case? Because I once
tried using :number-of-apples to match Clojure's conventions, but got
burned by a number of third-party tools gagging on the hyphens.
I guess most of the time column names are written with
names_separated_by_underscores, but anyway, it seems indeed weird that such
downcase is done, especially without any (or to come) good reason for that.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
On Tue, May 3, 2011 at 11:34 AM, Chas Emerick cemer...@snowtide.com wrote: I've previously linked[1] to my preview of Clojure Atlas – my attempt at producing a more useful, more tractable medium for understanding programming languages and the libraries that go along with them – so I won't repeat that material here. I did think I'd let the list know that Clojure Atlas is now available publicly however: http://clojureatlas.com It's a very cool way to visualize the Clojure world and to explore what's available. One thing I found - which would definitely stop me paying for it as-is - I get lost when I drill down: there's no way to navigate 'back' to what I was looking at and no sense of history (like a crumb trail). Messing around with the demo I just realized I can use the browser back button / hot key but that feels clunky - being able to navigate more easily with keyboard shortcuts within the atlas itself would make it a lot nicer to use. Perhaps left arrow / right arrow to go back / forward thru the direct history and up arrow / down arrow to jump up and down the hierarchy? It doesn't appear to include any of the contrib libraries (I know that's a mammoth task for 1.2.0). Do you plan to include the new contrib libraries in 1.3.0 since they seem more integrated now? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Any wisdom in the math speed of different clojure libraries?
Anything implemented with multimethods (contrib.generic) will be slow compared to primitives and Java methods invoked on primitives. Also try out the better primitive math ops in the 1.3.0-alphas. -Stuart clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Declarative Data Models
No. Clojure template (which I wrote) is a backwards way of doing macros. It happens to be useful in clojure.test, but nowhere else. -Stuart S clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Atlas now available (an experimental visualization of the Clojure language standard library)
On Tue, May 3, 2011 at 3:06 PM, Sean Corfield seancorfi...@gmail.com wrote: It doesn't appear to include any of the contrib libraries (I know that's a mammoth task for 1.2.0). Do you plan to include the new contrib libraries in 1.3.0 since they seem more integrated now? I also could not find: try/catch/finally/throw, do, if, quote... Are these known missing special forms? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Monadic implementation of the Shunting-yard algorithm
On Tuesday, 3 May 2011 15:02:02 UTC-4, odyssomay wrote: I wrote a simple implementation: http://gist.github.com/953966https://gist.github.com/953966 (only supports operators) It's not very elegant (I don't know how to use fnparse..), but it is functional. What it does is find out what the next element in the operator stack and the out stack should be, and then recursively update the stacks and output the finished out stack. As I said I don't know how to use fnparse and therefore I couldn't really understand your code. Either way I hope that this code helps in some way.. ;) This is great, hadn't thought about using a protocol for this! I'll improve both versions to be able to compare them on equal ground and to see how they cope with adding more features. Although in the end, I think the recursive one will be faster while the monadic one will be more composable, Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Monadic implementation of the Shunting-yard algorithm
One small question, how would you modify your version to output s-expressions? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Closures in macros
On May 3, 5:22 pm, André Thieme splendidl...@googlemail.com wrote: Some of the limitations: 1. (defmacro x [] `(let [a# ~(atom 0)])) 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) All three calls fail, (x) and (y) and (z). I see no plausible reason why it *should* be that way. I do - because most of the time, embedding an object in code is accidental, caused by messing up the quoting and unquoting. I would prefer that evaling something that cannot be produced by the reader be an error. I can see that in some cases, having eval pass unexpected types through unchanged can be useful, but I think it would be much more common for it to result in hard-to-debug errors, especially for beginning macro writers. - Chris Perkins -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
On May 3, 2011, at 6:06 PM, Sean Corfield wrote: It's a very cool way to visualize the Clojure world and to explore what's available. One thing I found - which would definitely stop me paying for it as-is - I get lost when I drill down: there's no way to navigate 'back' to what I was looking at and no sense of history (like a crumb trail). Messing around with the demo I just realized I can use the browser back button / hot key but that feels clunky - being able to navigate more easily with keyboard shortcuts within the atlas itself would make it a lot nicer to use. Perhaps left arrow / right arrow to go back / forward thru the direct history and up arrow / down arrow to jump up and down the hierarchy? That's interesting; I very intentionally built in proper support for browser back/forward actions (as you discovered), thinking that that would be a good local maxima in terms of history navigation. FWIW, click-and-hold on the back or forward buttons in your browser will give you the breadcrumbs you're looking for. I'm not entirely convinced that left/right shortcuts would make sense — that would simply map to back/forward in the browser, which already have keyboard shortcuts. I'll think about it for a bit. I'd like to plumb at this up/down notion a bit. Perhaps it's not clear, but the ontology is not a hierarchy – there absolutely are cycles in its graph. For example: http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure.core/isa? Which way is up (or down) from isa? here? It doesn't appear to include any of the contrib libraries (I know that's a mammoth task for 1.2.0). Do you plan to include the new contrib libraries in 1.3.0 since they seem more integrated now? I hope that Clojure Atlas will include contrib libraries in the future, though I can't imagine I'll be building the ontologies for them. As you say, 1.2.0 contrib is large, but new contrib is likely to get much, much larger (presumably larger than the standard library) since contributing to it is far easier than classic contrb. I'm thinking about various ways to allow for community-constructed ontologies for various libraries, including contrib of all versions. - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
On May 3, 2011, at 6:29 PM, Sean Corfield wrote: On Tue, May 3, 2011 at 3:06 PM, Sean Corfield seancorfi...@gmail.com wrote: It doesn't appear to include any of the contrib libraries (I know that's a mammoth task for 1.2.0). Do you plan to include the new contrib libraries in 1.3.0 since they seem more integrated now? I also could not find: try/catch/finally/throw, do, if, quote... Are these known missing special forms? Indeed; all of the special forms in the ontology right now are linked from: http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#concept/special-forms As I say at http://www.clojureatlas.com/#status, I'm far from done. :-) BTW, thanks for the earlier feedback, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
ALT-[LEFT|RIGHT] ARROW - nav back/forward I was very pleased to have proper browsing history support - great way to do breadcrumbs. P.S. When I started learning clojure a year ago, one of the biggest pain points was not having a resource like this. Dynamic languages, in general, and clojure, in particular, lack the self-documenting relational ontology that static language jocks take for granted. It's difficult to quickly find relationships (e.g. find all the functions that operate on ISeq or Seqable); having half of Clojure implemented in Clojure and the other half in Java doesn't make it easy to automate this navigation with tools either. Major kudos on this. On May 3, 4:39 pm, Chas Emerick cemer...@snowtide.com wrote: On May 3, 2011, at 6:06 PM, Sean Corfield wrote: It's a very cool way to visualize the Clojure world and to explore what's available. One thing I found - which would definitely stop me paying for it as-is - I get lost when I drill down: there's no way to navigate 'back' to what I was looking at and no sense of history (like a crumb trail). Messing around with the demo I just realized I can use the browser back button / hot key but that feels clunky - being able to navigate more easily with keyboard shortcuts within the atlas itself would make it a lot nicer to use. Perhaps left arrow / right arrow to go back / forward thru the direct history and up arrow / down arrow to jump up and down the hierarchy? That's interesting; I very intentionally built in proper support for browser back/forward actions (as you discovered), thinking that that would be a good local maxima in terms of history navigation. FWIW, click-and-hold on the back or forward buttons in your browser will give you the breadcrumbs you're looking for. I'm not entirely convinced that left/right shortcuts would make sense — that would simply map to back/forward in the browser, which already have keyboard shortcuts. I'll think about it for a bit. I'd like to plumb at this up/down notion a bit. Perhaps it's not clear, but the ontology is not a hierarchy – there absolutely are cycles in its graph. For example: http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure... Which way is up (or down) from isa? here? It doesn't appear to include any of the contrib libraries (I know that's a mammoth task for 1.2.0). Do you plan to include the new contrib libraries in 1.3.0 since they seem more integrated now? I hope that Clojure Atlas will include contrib libraries in the future, though I can't imagine I'll be building the ontologies for them. As you say, 1.2.0 contrib is large, but new contrib is likely to get much, much larger (presumably larger than the standard library) since contributing to it is far easier than classic contrb. I'm thinking about various ways to allow for community-constructed ontologies for various libraries, including contrib of all versions. - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Optimizing my function for performance
This is related to my multi-level bucketing problem which I am starting new thread. The code is at: https://gist.github.com/952861 I am referring to the sum-by function which was provided by fellow clojurer in this group. It choked when I passed in data of size one million - meaning I didn't run out of memory but it took a very long time. Quoting below are two functions from my code: (def data (take 100 (repeatedly get-rec))) ;get aggregate values for list of attributes (defn sum-by [data attrs] (let [aggregated (group-by (apply juxt attrs) data)] (zipmap (keys aggregated) (map #(reduce + (map :mv %)) (vals aggregated) ;invoke sum-by (sum-by data [:attr1 :attr2]) Are there any obvious performance optimizations (e.g. transient, etc) that can be performed so that the function can perform better and consume less memory? In general what are the things to watch out for when writing functions such as these so as not to get poor performance with very large data sets. Thanks for your help. -- Shoeb -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Monadic implementation of the Shunting-yard algorithm
I've refactored your code into this: https://gist.github.com/954579 On Tuesday, 3 May 2011 15:02:02 UTC-4, odyssomay wrote: I wrote a simple implementation: http://gist.github.com/953966https://gist.github.com/953966 (only supports operators) It's not very elegant (I don't know how to use fnparse..), but it is functional. What it does is find out what the next element in the operator stack and the out stack should be, and then recursively update the stacks and output the finished out stack. As I said I don't know how to use fnparse and therefore I couldn't really understand your code. Either way I hope that this code helps in some way.. ;) Jonathan On Tue, May 3, 2011 at 2:23 AM, Nicolas Buduroi nbud...@gmail.com wrote: Hi, I'm working on my parsing skills using fnparse 2.2.7 and have written the following implementation of the Shunting-yard algorithm: https://gist.github.com/952607 I plan to make a lightning talk about monadic parser at the next Bonjure meeting and I'd like to hear what people here think about that implementation first. It is more imperative that I would like, but that is the nature of this algorithm I think. Would a non-monadic implementation would be better in some ways? How would you make this code more flexible, faster and/or cleaner? Is there a more functional way of writing it? Thanks in advance for any comments! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com 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 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 Atlas now available (an experimental visualization of the Clojure language standard library)
On Tue, May 3, 2011 at 4:39 PM, Chas Emerick cemer...@snowtide.com wrote: That's interesting; I very intentionally built in proper support for browser back/forward actions (as you discovered), thinking that that would be a good local maxima in terms of history navigation. I guess I could get used to splat-[ / splat-] as the hot keys for that (RockMelt on Mac OS X). FWIW, click-and-hold on the back or forward buttons in your browser will give you the breadcrumbs you're looking for. Hmm... that means taking the mouse out of the atlas and interacting with the chrome of its surroundings... I'd like to plumb at this up/down notion a bit. Perhaps it's not clear, but the ontology is not a hierarchy – there absolutely are cycles in its graph. For example: http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure.core/isa? Which way is up (or down) from isa? here? It was more relative to the browser history. I start at Clojure, I go off exploring, I find myself on some node with no obvious direct edge to something I was looking at before. If I could hit 'up' and go back in the history to the last thing connected to what I'm focused on... Maybe I just need to spend more time with it and just get used to the way it works now... As you say, 1.2.0 contrib is large, but new contrib is likely to get much, much larger (presumably larger than the standard library) since contributing to it is far easier than classic contrb. Really? I thought new contrib was more tightly controlled and subject to more Clojure/core approval. Mind you, we had ~60 old contrib libraries and we already have close to 30 new contrib libraries so you may well be right... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
ANN: Java dependency injection in Clojure
Hi, being tired of wandering through a few thousand lines of XML Spring bean definitions, I finally wrote a library to start moving away from Spring/XML. It's definitively nicer doing dependency injection/auto-wiring using Clojure. This is part of our global effort here to confine Java as much as possible to lower layers. Lacking imagination (or being lazy ?), I called it boing. The source code is available at https://github.com/lprefontaine/Boing and the Wiki there describes its scope and capabilities. It's a 1.0 version. It should make it to prod beginning of this summer. The jar is on Clojars ([org.clojars.lprefontaine/boing 1.0] in leiningen). It may be of interest to people having mixed environments and potentially to some using external Java libraries. It's much more dynamic than XML and significantly shorter. Look at the examples folder. Comments are welcomed. The TODO list is not yet published but we see a few things we want to add to it especially in the area of resource management and some optimizations. Code wise I think it's not too horrible given that I had to squeeze this in my already ultra-tight schedule in the last three weeks or so. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
