Re: Overflowing (count ...)
Making count return a correct long or BigInt value in such cases would be a significant change, given that Java's int is used for the return value for many count() and countFrom() methods sprinkled around Clojure's source code. I've created a ticket CLJ-1229 and attached a patch that causes count to throw an ArithmeticException if the sequence contains more than Integer/MAX_VALUE elements. I don't know if such a patch is acceptable to the Clojure/core team or not, but we may find out. http://dev.clojure.org/jira/browse/CLJ-1229 Andy On Sun, Jul 7, 2013 at 5:13 PM, John Jacobsen eigenhom...@gmail.com wrote: Was unsure whether to post to clojure or clojure-dev, but here goes. I was surprised to learn today that count silently overflows to negative numbers: jenome.core (time (count (range (*' 1000 1000 1000 3 Elapsed time: 375225.663 msecs -1294967296 jenome.core I can easily get around this with my own (non-overflowing) count function, but would it make sense for count throw an ArithmeticException on overflow, with *unchecked-math* set to false (as it is in my case)? Curiously, John -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Varspotting: spotting Clojure Vars for fun and profit!
...and here comes 0.0.2 with non-buggy Var counts: Varspotting report for built-in namespaces: === | Spotter | Var count | |--+---| | Public | 844 | | Unbound | 6 | | Dynamic |39 | | Proper functions | 670 | | Macros |99 | | Non-fn IFns |17 | | Dynamic proper functions | 6 | Cheers, Michał On 9 July 2013 07:38, Michał Marczyk michal.marc...@gmail.com wrote: Hi, Inspired by this Stack Overflow question: Roughly how many functions are in the Clojure core libraries? http://stackoverflow.com/questions/17524906/roughly-how-many-functions-are-in-the-clojure-core-libraries I have released Varspotting, a Leiningen plugin and library for summarizing Var counts. Perhaps the default report on Clojure Vars (1.5.1) will best serve to illustrate the purpose: Varspotting report for clojure.core: | Spotter | Var count | |--+---| | Public | 591 | | Unbound | 2 | | Dynamic |11 | | Proper functions | 475 | | Macros |76 | | Non-fn IFns | 6 | | Dynamic proper functions | 1 | Varspotting report for built-in namespaces: === | Spotter | Var count | |--+---| | Public | 831 | | Unbound | 6 | | Dynamic |39 | | Proper functions | 658 | | Macros |98 | | Non-fn IFns |17 | | Dynamic proper functions | 6 | You can have Varspotting print the above in your terminal if you add [varspotting 0.0.1] to :plugins in your ~/.lein/profiles.clj and say lein varspotting (inside or outside of a project)! Add a list of namespace names as arguments to lein varspotting to obtain a report on those namespaces. The source is available at https://github.com/michalmarczyk/varspotting Custom reports can be generated as well. To this end, varspotting.core includes what I hope is a fairly extensive collection of docstrings; the README points out the key Vars. Cheers, Michał -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.jdbc - (sql/where ...) with multiple values (i.e. 'x in (1,2,3')
Thanks both.
On 9 July 2013 01:55, James Ferguson jferguson2@gmail.com wrote:
On Monday, July 8, 2013 5:28:07 PM UTC-4, Colin Yates wrote:
Using the latest release of java.jdbc, does anybody know how I can
construct a where clause when I want to check if the value is one of many
values?
For example, if I have a filter {:age [1 2 3 4]} then (sql/where filter)
causes an error: Wrong data type: java.lang.**NumberFormatException:
For input string: [1 2 3 4].
Any idea how to do this in clojure.java.jdbc?
I've been using http://sqlkorma.com/ for CRUD. A query with your filter
would be
(select tablename
(where {:age [in [1 2 3 4]]}))
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/7A_HAAISvEk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: group-by replacement when an item has many groups?
Thanks Y.Kohyama - it does.
On 9 July 2013 03:00, Yoshinori Kohyama yykohy...@gmail.com wrote:
Hi Colin,
One more solution, with example data in the process commented
*(let [f #(range 1 (inc %))*
* coll '(1 2 3)]*
* (-*
**(for [*x coll*; x = 1, 2, 3
* y *(*f x*)]* *; y = 1 (where x = 1),
**; 1, 2(where x = 2),
**; 1, 2, 3 (where x = 3)
* *[*y x*])**; [y, x] = [1, 1], [1, 2], [2, 2], [1, 3], [2,
3], [3, 3]
**(reduce * *; for example where
* *(fn [*a *[*y x*]]* *; a = {1 [1 2 3], 2 [2]}, [y x] = [2 3]
**; = (a y []) = [2]
**;(conj ... x) = [2 3]
*(assoc a y (conj (a y []) x)))*
* *{})))* *;(assoc a y ...) = {1 [1 2 3], 2 [2 3]}
Hope this helps.
Y.Kohyama
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/AkKuHVNPIq4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Applying function on a vector of tags to extract content from xml
Yes, I do mean to return anonymous function, I want to be able to map it over the vector of tags, ie. (map f [:title :venue_name]) and to get this (#(zf/xml1- % :title zf/text) #(zf/xml1- % :venue_name zf/text) ) On Monday, July 8, 2013 9:33:40 PM UTC+2, Jeremy Heiler wrote: On July 8, 2013 at 5:39:14 AM, Vesna Petkovic (vesna.p...@gmail.comjavascript:) wrote: (defn func [ tags](#(zf/xml1- (xml-zipper tags) % zf/text))) As the exception states, you are passing 0 arguments to a function that doesn't accept 0 arguments. The name of the function datamodel$func$fn narrows it down to an anonymous function defined in the func function. Why does that function not allow 0 arguments? It's because it requires one argument, per the % inside it. Then it is invoked with no arguments. Do you mean to return the anonymous function instead of invoking it? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure interpreters?
My post The Environment as a Value might be of interest to you. https://groups.google.com/forum/#!searchin/clojure-dev/immutable$20environment/clojure-dev/S8BawG7nzJA/qfCd7hn67aoJ It contains a lot of similar ideas. An important point is that you don't necessarily need an interpreter to get the benefits of an immutable isolated environment: this can still be fully compiled. In terms of state mutations, they key point is that you need some form of dependency graph: if you update one var, this can then trigger a recompilation of dependent vars to get you to a consistent new state. This also solves the problem of circular references as a by-product. It was a cool idea, but nobody seemed very interested at the time :-( On Tuesday, 9 July 2013 00:55:18 UTC+1, kovasb wrote: I believe a reify-able clojure interpreter would be useful and interesting. For instance, for debugging, partial evaluation, environment capture / manipulation, and a variety of tasks that currently require resetting the environment just to see the behavior of code. I imagine this being mostly useful at the repl, for exploring the behavior of programs, and for temporarily changing the meaning of pieces of programs without digging into source code. Anyone with me? Does such a thing already exist? My basic design idea is to have a protocol IClojure that implements the primitives necessary to bootstrap clojure.core. IClojure would be implemented by a concrete datatype. State mutations would correspond to returning new instances of the datatype. Basically, this would be a clojure interpreter as immutable data. So you can fabricate an interpreter with the state that you need, and keep reusing it as you debug your other code. One aspect I'm not clear on is platform isolation. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure interpreters?
2013/7/9 Mikera mike.r.anderson...@gmail.com: My post The Environment as a Value might be of interest to you. https://groups.google.com/forum/#!searchin/clojure-dev/immutable$20environment/clojure-dev/S8BawG7nzJA/qfCd7hn67aoJ It contains a lot of similar ideas. An important point is that you don't necessarily need an interpreter to get the benefits of an immutable isolated environment: this can still be fully compiled. Modulo side effects such as: - classloading of new fns : not a real problem, but the limit of the PermGen maybe - Protocols / Types recompilation: this may be a problem ? (unless the whole compilation happens in a different classloader ?) In terms of state mutations, they key point is that you need some form of dependency graph: if you update one var, this can then trigger a recompilation of dependent vars to get you to a consistent new state. This also solves the problem of circular references as a by-product. It was a cool idea, but nobody seemed very interested at the time :-( On Tuesday, 9 July 2013 00:55:18 UTC+1, kovasb wrote: I believe a reify-able clojure interpreter would be useful and interesting. For instance, for debugging, partial evaluation, environment capture / manipulation, and a variety of tasks that currently require resetting the environment just to see the behavior of code. I imagine this being mostly useful at the repl, for exploring the behavior of programs, and for temporarily changing the meaning of pieces of programs without digging into source code. Anyone with me? Does such a thing already exist? My basic design idea is to have a protocol IClojure that implements the primitives necessary to bootstrap clojure.core. IClojure would be implemented by a concrete datatype. State mutations would correspond to returning new instances of the datatype. Basically, this would be a clojure interpreter as immutable data. So you can fabricate an interpreter with the state that you need, and keep reusing it as you debug your other code. One aspect I'm not clear on is platform isolation. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.jdbc - (sql/where ...) with multiple values (i.e. 'x in (1,2,3')
Just an idle musing - I think DSLs (in general) are really powerful when
you can declare them in your application. However, whenever I have to
programatically construct them (constructing them based on JSON from the UI
for example) I find it is often easier to just use build up the SQL
directly.
Given Clojure's excellent 'structural manipulation' and 'pretty much
everything is structure' capabilities maybe that is no longer the case.
The transformation from JSON to sqlkorma for example will be almost
entirely be structural changes. In other languages you don't have that, you
tend to need to build up state through method calls.
End of musing.
On Tuesday, 9 July 2013 01:55:54 UTC+1, James Ferguson wrote:
On Monday, July 8, 2013 5:28:07 PM UTC-4, Colin Yates wrote:
Using the latest release of java.jdbc, does anybody know how I can
construct a where clause when I want to check if the value is one of many
values?
For example, if I have a filter {:age [1 2 3 4]} then (sql/where filter)
causes an error: Wrong data type: java.lang.NumberFormatException: For
input string: [1 2 3 4].
Any idea how to do this in clojure.java.jdbc?
I've been using http://sqlkorma.com/ for CRUD. A query with your filter
would be
(select tablename
(where {:age [in [1 2 3 4]]}))
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure interpreters?
On Tuesday, 9 July 2013 13:52:59 UTC+5:30, Mikera wrote: My post The Environment as a Value might be of interest to you. https://groups.google.com/forum/#!searchin/clojure-dev/immutable$20environment/clojure-dev/S8BawG7nzJA/qfCd7hn67aoJ It contains a lot of similar ideas. An important point is that you don't necessarily need an interpreter to get the benefits of an immutable isolated environment: this can still be fully compiled. In terms of state mutations, they key point is that you need some form of dependency graph: if you update one var, this can then trigger a recompilation of dependent vars to get you to a consistent new state. This also solves the problem of circular references as a by-product. It was a cool idea, but nobody seemed very interested at the time :-( I did notice the post earlier. It looked very interesting indeed. It appeared to me the proposal was for Clojure proper and I wasn't sure about the performance implications. Nevertheless, Mikera's ideas in the post are quite eloquent. Shantanu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Livemark-mode
An Emacs-mode for live-ish display of a markdown-buffer in a webbrowser. Nothing terrible usefull, but it could serve as a small example for people looking to write Emacs-modes that communicate with Clojure. https://github.com/bonega/livemark-mode -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure: Elegance vs. Performance?
Hello everyone! It's great to be here with all you fellow Clojurians. Just so you know, this is my first post on this group, so don't shoot me if it's terrible ;) As background, I've been working through SICP and have been loving Scheme. It's almost breathtaking how elegant and clean the code can be (I had some moments like xkcd goes off abou http://xkcd.com/224/t). Of course, though Scheme is beautiful and simple, everyone knows that it's not especially practical, in general. I love the Lisp paradigms but I'm not really a fan of CL so I did some looking around and stumbled upon Clojure. It seems that Clojure really has a lot going for it between shockingly easy concurrency support and Java interop, among other things. But one thing that's been bothering me is that it seems like to optimize performance in Clojure, you have to sacrifice some elegance. *Example 1: Tail-call recursion* *Scheme* One example would be tail-call recursion. For instance, normally in Scheme I'd naively implement an iterative exponent function like this: (define (expt x n) (cond ((= 0 n) 1) ((= 1 n) x) (else (expt (* x x) (- n 1) Pure. Simple. Beautiful. (Not that I'm the best Scheme programmer ever, but to me it looks beautiful, and it conforms well to the base of the problem. You get the point.) *Clojure* Of course, tail-call recursion is not possible with JVM, so Clojure uses a * recur* macro in place of direct recursive function calling. It avoids blowing the stack as quickly but it's still not 100% mathematically pure in the way Scheme tends to be. An added gripe is that the* else *form within *cond *in Clojure uses a keyword, *:else*, instead of the more consistent parenthetical form used in Scheme. I suppose that's to make it less Lispy. But it just ends up making it a little less elegant. *Example 2: Type casting* * * Some have said that Clojure can be somewhat slow (as with all Lisps). I'm not sure how true this is, but I stumbled on an example on John Lawrence Aspden's bloghttp://www.learningclojure.com/2013/02/clojure-is-fast-is-clojure-still-fast.html. He wrote a program to implement Euler's method like so: *First Solution* (defn f [t y] (- t y)) (defn solveit [t0 y0 h its] (if ( its 0) (let [t1 (+ t0 h) y1 (+ y0 (* h (f t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its])) He points out that if this was an assembly language program that worked the way you'd expect, each loop would take 7 cycles. So he tests it for Clojure. The result? On his netbook with Clojure 1.4: 2400 cycles. As he says, We're looking at a slowdown of about 300 times over what we could probably achieve coding in assembler or in C with a good optimizing compiler. That's not surprising, I suppose, but it's still a little disheartening. After all, you want your language to be fast, right? Well, after a few iterations, he manages to reduce the cycles way down - all the way down, in fact, to 37, which is quite a feat. Like so: *Final Solution* (defn solveit-4 [t0 y0 h its] (let [zero (long 0)] (loop [t0 (double t0) y0 (double y0) h (double h) its (long its)] (if ( its zero) (let [t1 (+ t0 h) y1 (+ y0 (* h (- t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its] But the thing is, between the *recur *macro, explicit typecasting, and the *loop* construct, yes, you have a very significant performance increase, but it the code's gotten bigger, much less readable, and much less elegant. *The bottom line* * * My idea, which is probably very naive, but one which I'm curious about, is: *Is it possible to have some sort of set of automatic-optimizing macros that work on Clojure code to preserve elegance while maximizing performance?* * * In theory, it would be kind of an abstraction layer. There would be one file that would store the code that gets read and another output file that stores the code that actually gets evaluated by the REPL, and a set of macros to optimize the front-end, abstracted file into the output, nuts-and-bolts file to be evaluated by the REPL. Probably this would be a very intensive process - I don't know. But maybe it's worth the trouble after all to save a ton of programmer-hours by increasing readability. Thoughts? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more
Re: Clojure: Elegance vs. Performance?
Honestly, if you're only doing self-recursion, what makes the recur special form so inelegant? And the loop special form isn't very far removed from the Scheme's named let, where you do something like (let loop ((v1 init1) (v2 init2)) ... (loop)) I agree that it's not so nice that recur can *only* be used for self-recursion and that there's no generalized tail call elimination, but the cited examples don't depend on that anyway. Also I note that the reduction of 2400 to 37 cycles took all of two additional lines and a couple of type annotations (which is really not unexpected), so---again, personally---it seems like much less readable and much less elegant are fairly exaggerated. On Tue, Jul 9, 2013 at 8:11 AM, Alexander Gunnarson alexandergunnar...@gmail.com wrote: Hello everyone! It's great to be here with all you fellow Clojurians. Just so you know, this is my first post on this group, so don't shoot me if it's terrible ;) As background, I've been working through SICP and have been loving Scheme. It's almost breathtaking how elegant and clean the code can be (I had some moments like xkcd goes off abou http://xkcd.com/224/t). Of course, though Scheme is beautiful and simple, everyone knows that it's not especially practical, in general. I love the Lisp paradigms but I'm not really a fan of CL so I did some looking around and stumbled upon Clojure. It seems that Clojure really has a lot going for it between shockingly easy concurrency support and Java interop, among other things. But one thing that's been bothering me is that it seems like to optimize performance in Clojure, you have to sacrifice some elegance. *Example 1: Tail-call recursion* *Scheme* One example would be tail-call recursion. For instance, normally in Scheme I'd naively implement an iterative exponent function like this: (define (expt x n) (cond ((= 0 n) 1) ((= 1 n) x) (else (expt (* x x) (- n 1) Pure. Simple. Beautiful. (Not that I'm the best Scheme programmer ever, but to me it looks beautiful, and it conforms well to the base of the problem. You get the point.) *Clojure* Of course, tail-call recursion is not possible with JVM, so Clojure uses a *recur* macro in place of direct recursive function calling. It avoids blowing the stack as quickly but it's still not 100% mathematically pure in the way Scheme tends to be. An added gripe is that the* else *form within *cond *in Clojure uses a keyword, *:else*, instead of the more consistent parenthetical form used in Scheme. I suppose that's to make it less Lispy. But it just ends up making it a little less elegant. *Example 2: Type casting* * * Some have said that Clojure can be somewhat slow (as with all Lisps). I'm not sure how true this is, but I stumbled on an example on John Lawrence Aspden's bloghttp://www.learningclojure.com/2013/02/clojure-is-fast-is-clojure-still-fast.html. He wrote a program to implement Euler's method like so: *First Solution* (defn f [t y] (- t y)) (defn solveit [t0 y0 h its] (if ( its 0) (let [t1 (+ t0 h) y1 (+ y0 (* h (f t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its])) He points out that if this was an assembly language program that worked the way you'd expect, each loop would take 7 cycles. So he tests it for Clojure. The result? On his netbook with Clojure 1.4: 2400 cycles. As he says, We're looking at a slowdown of about 300 times over what we could probably achieve coding in assembler or in C with a good optimizing compiler. That's not surprising, I suppose, but it's still a little disheartening. After all, you want your language to be fast, right? Well, after a few iterations, he manages to reduce the cycles way down - all the way down, in fact, to 37, which is quite a feat. Like so: *Final Solution* (defn solveit-4 [t0 y0 h its] (let [zero (long 0)] (loop [t0 (double t0) y0 (double y0) h (double h) its (long its)] (if ( its zero) (let [t1 (+ t0 h) y1 (+ y0 (* h (- t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its] But the thing is, between the *recur *macro, explicit typecasting, and the *loop* construct, yes, you have a very significant performance increase, but it the code's gotten bigger, much less readable, and much less elegant. *The bottom line* * * My idea, which is probably very naive, but one which I'm curious about, is: *Is it possible to have some sort of set of automatic-optimizing macros that work on Clojure code to preserve elegance while maximizing performance?* * * In theory, it would be kind of an abstraction layer. There would be one file that would store the code that gets read and another output file that stores the code that actually gets evaluated by the REPL, and a set of macros to optimize the front-end, abstracted file into the output, nuts-and-bolts file to be evaluated by
Re: Clojure: Elegance vs. Performance?
On 9 July 2013 16:11, Alexander Gunnarson alexandergunnar...@gmail.comwrote: An added gripe is that the* else *form within *cond *in Clojure uses a keyword, *:else*, instead of the more consistent parenthetical form used in Scheme. I suppose that's to make it less Lispy. But it just ends up making it a little less elegant. The :else keyword is used because it's a truthy value, not because the cond form assigns any special syntax to it. In this case, I'd argue that the Clojure cond form is more consistent than Scheme's, because it has no special syntax for dealing with else conditions. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
Perhaps I didn't choose my examples in a very illustrative way. It was meant to be a general approach. There are probably several other examples where the need for performance causes elegance to suffer, but I'm drawing a blank right now because I'm not a Clojure expert. As I familiarize myself with the language I'll be able to cite more varied examples. Thanks for your feedback. I see your point with the *:else* keyword. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
The thing that should be mentioned, is that we're talking about some pretty insane performance optimizations for a dynamic language. Let's take something like Python for example. All ints are boxed, all the time. If you want to optimize your code, you drop to C (or Cython) so you end up re-writing your performance critical code. Clojure stands on some pretty unique ground in being one of the few dynamic languages out there that allow you to specify types to improve performance in some specific situations. In short, how would you get this level of performance from scheme? Optimization and code clarity are very often at odds. And expressiveness often comes at the cost of performance. Timothy On Tue, Jul 9, 2013 at 9:51 AM, Alexander Gunnarson alexandergunnar...@gmail.com wrote: Perhaps I didn't choose my examples in a very illustrative way. It was meant to be a general approach. There are probably several other examples where the need for performance causes elegance to suffer, but I'm drawing a blank right now because I'm not a Clojure expert. As I familiarize myself with the language I'll be able to cite more varied examples. Thanks for your feedback. I see your point with the *:else* keyword. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Pedestal-app Tutorial has been released
Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
O, Yeah! Thanks! On Tuesday, July 9, 2013 6:03:58 PM UTC+2, Ryan Neufeld wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On 9 July 2013 16:11, Alexander Gunnarson alexandergunnar...@gmail.comwrote: *Example 1: Tail-call recursion* *Scheme* One example would be tail-call recursion. For instance, normally in Scheme I'd naively implement an iterative exponent function like this: (define (expt x n) (cond ((= 0 n) 1) ((= 1 n) x) (else (expt (* x x) (- n 1) Pure. Simple. Beautiful. (Not that I'm the best Scheme programmer ever, but to me it looks beautiful, and it conforms well to the base of the problem. You get the point.) This is not implementing expt as it is usually known, it looks more like repeated squaring to me. Ray. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On Tue, Jul 9, 2013 at 9:14 AM, Ray Miller r...@1729.org.uk wrote: Pure. Simple. Beautiful. (Not that I'm the best Scheme programmer ever, but to me it looks beautiful, and it conforms well to the base of the problem. You get the point.) This is not implementing expt as it is usually known, it looks more like repeated squaring to me. Agreed. There's a certain irony that the OP declares the code pure, simple, and beautiful, when it isn't correct code. Seems to me that if you can't tell at a glance what a 3-line program is doing, there's something wrong :) --Mark -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
Having gone through the tutorial from end to end (before it's release), I can't recommend it enough. If you have any curiosity about dataflow web programming and/or pedestal-app, give yourself a day to go through this. Awesome work Brenton! On Tuesday, July 9, 2013 12:03:58 PM UTC-4, Ryan Neufeld wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
This is not implementing expt as it is usually known, it looks more like repeated squaring to me. Agreed. There's a certain irony that the OP declares the code pure, simple, and beautiful, when it isn't correct code. Seems to me that if you can't tell at a glance what a 3-line program is doing, there's something wrong :) True. There are much better/more efficient implementations like: (define (even? n) (= (remainder n 2) 0)) (define (fast-expt b n) (cond ((= n 0) 1) ((even? n) (square (fast-expt b (/ n 2 ;even O(log(n)) (else (* b(fast-expt b (- n 1)) ;odd O(n) Sorry for the apparently awful examples in the original post. :/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On Tue, Jul 9, 2013 at 8:11 AM, Alexander Gunnarson alexandergunnar...@gmail.com wrote: My idea, which is probably very naive, but one which I'm curious about, is: *Is it possible to have some sort of set of automatic-optimizing macros that work on Clojure code to preserve elegance while maximizing performance?* * * In theory, it would be kind of an abstraction layer. There would be one file that would store the code that gets read and another output file that stores the code that actually gets evaluated by the REPL, and a set of macros to optimize the front-end, abstracted file into the output, nuts-and-bolts file to be evaluated by the REPL. Probably this would be a very intensive process - I don't know. But maybe it's worth the trouble after all to save a ton of programmer-hours by increasing readability. I think you're probably underestimating the scope of what the Clojure compiler already does. Arguably, it already is an auto-optimizing process that works on Clojure code to preserve elegance while maximing performance. For the most part, Clojure programmers seem to be satisfied with dropping down to Java when the Clojure code gets too low-level to be elegant (although I think many would disagree that your examples have reached the level of inelegance). Still, there's probably room for something that targets the performance gap between Clojure and Java. I'm interested in an assembly-like DSL that could be easily interwoven with Clojure code, something like: http://www.rebol.com/docs/rebcode.html Zach Tellman recently released a library that does something like that: https://github.com/ztellman/primitive-math So far, the vast majority of Clojure performance improvements have focused on making it easier to work with primitive numbers (in loops and as function inputs), because Java's boxed numerics is what usually kills performance. I've only found these improvements marginally useful because I find that most numbers eventually end up in a Clojure data structure, where they become boxed. For me, the most useful thing would be an ability to drop down and do fast pointer manipulation and other mutable work, without having to go all the way to Java. Going in the other direction, I'd be interested in mechanisms that made it easier to write recursive code without having to worry about stack overflow. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On Tue, Jul 9, 2013 at 9:29 AM, Alexander Gunnarson alexandergunnar...@gmail.com wrote: This is not implementing expt as it is usually known, it looks more like repeated squaring to me. Agreed. There's a certain irony that the OP declares the code pure, simple, and beautiful, when it isn't correct code. Seems to me that if you can't tell at a glance what a 3-line program is doing, there's something wrong :) True. There are much better/more efficient implementations like: Your expt code wasn't inefficient; it didn't produce the correct result. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
First of all, great post and a lot of great points. I feel your pain, because I also find myself struggling a lot to make idiomatic code fast in Clojure. Often I end up being forced to use some pretty ugly tricks to get the performance I need. Sometimes I just end up coding inner loops in Java - this often ends up easier to maintain than a big pile of loop/recurs, macro magic, type hints and/or obscure casting tricks which is what you typically need to get the maximum performance in Clojure. I definitely think there is scope for some extra optimisation techniques. It's a big and complex topic though, and requires people to get down and dirty with the compiler. I think the big wins would be things like: a) More type checking/inference (to eliminate the need for type hints and casts in many circumstances) b) Targeted optimisations for common functional patterns c) Smarter inlining of small functions d) Ability to produce type-specialised versions of functions Some of this could, I think, be implemented in an optimisation phase that performs macro-like transformations. I think this would be similar to the abstraction layer that you describe. On Tuesday, 9 July 2013 16:11:58 UTC+1, Alexander Gunnarson wrote: Hello everyone! It's great to be here with all you fellow Clojurians. Just so you know, this is my first post on this group, so don't shoot me if it's terrible ;) As background, I've been working through SICP and have been loving Scheme. It's almost breathtaking how elegant and clean the code can be (I had some moments like xkcd goes off abou http://xkcd.com/224/t). Of course, though Scheme is beautiful and simple, everyone knows that it's not especially practical, in general. I love the Lisp paradigms but I'm not really a fan of CL so I did some looking around and stumbled upon Clojure. It seems that Clojure really has a lot going for it between shockingly easy concurrency support and Java interop, among other things. But one thing that's been bothering me is that it seems like to optimize performance in Clojure, you have to sacrifice some elegance. *Example 1: Tail-call recursion* *Scheme* One example would be tail-call recursion. For instance, normally in Scheme I'd naively implement an iterative exponent function like this: (define (expt x n) (cond ((= 0 n) 1) ((= 1 n) x) (else (expt (* x x) (- n 1) Pure. Simple. Beautiful. (Not that I'm the best Scheme programmer ever, but to me it looks beautiful, and it conforms well to the base of the problem. You get the point.) *Clojure* Of course, tail-call recursion is not possible with JVM, so Clojure uses a *recur* macro in place of direct recursive function calling. It avoids blowing the stack as quickly but it's still not 100% mathematically pure in the way Scheme tends to be. An added gripe is that the* else *form within *cond *in Clojure uses a keyword, *:else*, instead of the more consistent parenthetical form used in Scheme. I suppose that's to make it less Lispy. But it just ends up making it a little less elegant. *Example 2: Type casting* * * Some have said that Clojure can be somewhat slow (as with all Lisps). I'm not sure how true this is, but I stumbled on an example on John Lawrence Aspden's bloghttp://www.learningclojure.com/2013/02/clojure-is-fast-is-clojure-still-fast.html. He wrote a program to implement Euler's method like so: *First Solution* (defn f [t y] (- t y)) (defn solveit [t0 y0 h its] (if ( its 0) (let [t1 (+ t0 h) y1 (+ y0 (* h (f t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its])) He points out that if this was an assembly language program that worked the way you'd expect, each loop would take 7 cycles. So he tests it for Clojure. The result? On his netbook with Clojure 1.4: 2400 cycles. As he says, We're looking at a slowdown of about 300 times over what we could probably achieve coding in assembler or in C with a good optimizing compiler. That's not surprising, I suppose, but it's still a little disheartening. After all, you want your language to be fast, right? Well, after a few iterations, he manages to reduce the cycles way down - all the way down, in fact, to 37, which is quite a feat. Like so: *Final Solution* (defn solveit-4 [t0 y0 h its] (let [zero (long 0)] (loop [t0 (double t0) y0 (double y0) h (double h) its (long its)] (if ( its zero) (let [t1 (+ t0 h) y1 (+ y0 (* h (- t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its] But the thing is, between the *recur *macro, explicit typecasting, and the *loop* construct, yes, you have a very significant performance increase, but it the code's gotten bigger, much less readable, and much less elegant. *The bottom line* * * My idea, which is probably very naive, but one which I'm curious about, is: *Is it
Re: [ANN] Pedestal-app Tutorial has been released
Thanks. Will check it out and share my feedback. On Jul 9, 2013 9:34 PM, Ryan Neufeld r...@thinkrelevance.com wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
2013/7/9 Ryan Neufeld r...@thinkrelevance.com I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. Ryan, Good to see more documentation for Pedestal! I have a bit of feedback. Maybe it's just me being really dumb but I was confused about where to find the actual tutorial. At some point I thought I need to run the two apps to see any content. It turned out to be in the wiki: https://github.com/pedestal/app-tutorial/wiki but I may be a good idea to make that a bit more obvious in the README at the top. The announcement could have linked to the wiki page as well. Thanks, -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN Cassaforte 1.0 final is released
Cassaforte [1] is a small, feature complete Clojure client for Apache Cassandra build around CQL 3. Cassaforte is finally 1.0. Since the last RC, there was one AOT compilation issue resolved, making the most recent version 1.0.1. To learn more about Cassaforte, see our 1.0 release notes: http://blog.clojurewerkz.org/blog/2013/07/09/cassaforte-1-dot-0-1-is-released/ The ClojureWerkz team would like to thank Max Penet for helping us shape up what Cassaforte is, making an excellent CQL DSL library available and supporting us in general, even though we were making a competitor to his own Cassandra client ;) Give Cassaforte a try. It makes working with Cassandra from Clojure a breeze. 1. http://clojurecassandra.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
Good point... it was rather a sloppily done example. If I wanted to do an iterative solution, I could have written: (define (expt x n) (define (iter x1 n1 result) (cond ((= 0 n1) 1) ((= 1 n1) result) (else (iter x1 (- n1 1) (* x1 result) (iter x n x)) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
Mikera, you hit on exactly what I was trying to say. Great post. I wonder what the feasibility would be to do what you and I are suggesting... It seems like it would take a while to get implemented, if it ever were implemented. Heaven knows I don't want to get down and dirty with the compiler like you say. At least not with the Clojure one (getting down and dirty with the Scheme compiler is coming up next in my SICP tour :D ). -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] java.jdbc documentation has moved!
Extended documentation on java.jdbc is now available on clojure-doc.org: http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html This opens up contributions to the community at large so I hope to see plenty of activity as folks send PRs for their favorite hints, tips, and tricks with this library. I seeded that new section with updated versions of what was previously in java.jdbc's Github repo and have already expanded some sections. Lots more documentation will follow in due (I promise!). The files in the docs folder of java.jdbc's Github repo have been removed to avoid confusion since they will be out of date going forward. Q for Tom Faulhaber: is there a standard autodoc way to add a URL for related documentation to the ns in a library? I've added the new URL as text in the ns docstring but if there's a way to generate a proper hyperlink on clojure.github.com/java.jdbc that would seem preferable. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
I was expecting a tutorial, and now we get this. Speechless. Thank you very much, I'll work through it! Il giorno martedì 9 luglio 2013 18:03:58 UTC+2, Ryan Neufeld ha scritto: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: how to create in-memory hsqldb database via java.jdbc
Feel free to submit PRs to improve the documentation at:
http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html
On Mon, Jul 8, 2013 at 9:22 AM, Colin Yates colin.ya...@gmail.com wrote:
Found it - typically - messed around for hours, then post, the find it.
The answer is to use something like 'mem:XYZ' for the subname.
The clue was checking in
https://github.com/clojure/java.jdbc/blob/dd3c05b940b9a9c7a739247e2508ea6a5d55df65/src/main/clojure/clojure/java/jdbc.clj#L416
and seeing how it actually constructs the URL then checking the expected URL
in http://hsqldb.org/doc/guide/ch01.html#N101CA.
To be explicit, clojure java.jdbc wasn't doing anything wrong it was my
mistake in thinking 'mem' was enough for hsqldb.
Sorry for the noise and hopes this help the next clueless newb :)
On Monday, 8 July 2013 15:16:44 UTC+1, Colin Yates wrote:
Hi,
I am using clojure.java.jdbc with HSQLDB, but I cannot figure out how to
create an in-memory database. Whatever I try defaults to a file based
instance, so:
(def hsql-db {:classname org.hsqldb.jdbcDriver :subprotocol hsqldb
:subname memory}) creates a file called memory.log etc. in my current
working directory. Whatever I put in the :subname is used as the filename.
I have tried mem with the same effect.
Any pointers? Google and the java.jdbc documentation aren't helping...
Thanks,
Col
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On Tuesday, 9 July 2013 17:31:21 UTC+1, puzzler wrote: On Tue, Jul 9, 2013 at 8:11 AM, Alexander Gunnarson alexander...@gmail.com javascript: wrote: My idea, which is probably very naive, but one which I'm curious about, is: *Is it possible to have some sort of set of automatic-optimizing macros that work on Clojure code to preserve elegance while maximizing performance?* * * In theory, it would be kind of an abstraction layer. There would be one file that would store the code that gets read and another output file that stores the code that actually gets evaluated by the REPL, and a set of macros to optimize the front-end, abstracted file into the output, nuts-and-bolts file to be evaluated by the REPL. Probably this would be a very intensive process - I don't know. But maybe it's worth the trouble after all to save a ton of programmer-hours by increasing readability. I think you're probably underestimating the scope of what the Clojure compiler already does. Arguably, it already is an auto-optimizing process that works on Clojure code to preserve elegance while maximing performance. The Clojure Compiler is fine, but it doesn't really do much in the way of optimisation yet. It mainly just emits bog-standard bytecode corresponding to the (macro-expanded) Clojure source. The good news is that the JVM JIT is exceptionally good at micro-optimisation and this still results in pretty decent performance. The bad news is that we are missing a lot of opportunities to do optimisations that the JVM JIT can't possibly do (because it doesn't know anything about the higher level structure and assumptions in the code). I think we should aspire to improve the compiler further: we should encourage ideas and discussions about how to improve it. I'd personally love to see Clojure match Java/Scala in performance for idiomatic code, but we are still currently some way off. For the most part, Clojure programmers seem to be satisfied with dropping down to Java when the Clojure code gets too low-level to be elegant (although I think many would disagree that your examples have reached the level of inelegance). Still, there's probably room for something that targets the performance gap between Clojure and Java. I'm interested in an assembly-like DSL that could be easily interwoven with Clojure code, something like: http://www.rebol.com/docs/rebcode.html Zach Tellman recently released a library that does something like that: https://github.com/ztellman/primitive-math So far, the vast majority of Clojure performance improvements have focused on making it easier to work with primitive numbers (in loops and as function inputs), because Java's boxed numerics is what usually kills performance. I've only found these improvements marginally useful because I find that most numbers eventually end up in a Clojure data structure, where they become boxed. That's one of the reasons why we are building core.matrix :-) For me, the most useful thing would be an ability to drop down and do fast pointer manipulation and other mutable work, without having to go all the way to Java. Yeah, I've always wanted this too. Especially for mutable local counters / accumulators. I'd love to be able to do something like: (let [^:mutable a 0 , ^:mutable b 0] (dotimes [i 1000] (set! a (+ a (foo i))) (set! b (+ b (bar i ... more stuff with a and b) This should compile down to something that performs the same as the equivalent loop in Java. Of course, it would be even better if the following could compile down to the same optimised loop: (reduce (fn [[a b] i] [(+ a (foo i)) (+ b (bar i))]) [0 0] (range 1000)) But currently. the Clojure reduce version is around 20-50x slower vs. equivalent Java code. Going in the other direction, I'd be interested in mechanisms that made it easier to write recursive code without having to worry about stack overflow. A reasonably simple optimisation would be to automatically identify self-recursion in tail position and convert it directly to recur. I think that's possibly the kind of optimisation pass that the OP was suggesting. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.jdbc - (sql/where ...) with multiple values (i.e. 'x in (1,2,3')
clojure.java.jdbc.sql is a deliberately minimal DSL - Justin Kramer's
HoneySQL is what I recommend for more expressive SQL construction
(that's the official recommendation based on discussions Justin and
I had about java.jdbc and HoneySQL at Clojure/conj 2012).
Sean
On Mon, Jul 8, 2013 at 5:47 PM, Jeremy Heiler jeremyhei...@gmail.com wrote:
On July 8, 2013 at 5:28:13 PM, Colin Yates (colin.ya...@gmail.com) wrote:
Using the latest release of java.jdbc, does anybody know how I can construct
a where clause when I want to check if the value is one of many values?
For example, if I have a filter {:age [1 2 3 4]} then (sql/where filter)
causes an error: Wrong data type: java.lang.NumberFormatException: For
input string: [1 2 3 4].
Any idea how to do this in clojure.java.jdbc?
It doesn't look like `where` supports OR or IN at the moment.
https://github.com/clojure/java.jdbc/blob/f9ecadd03c1c2e01f107155b03061ac0b20f976c/src/main/clojure/clojure/java/jdbc/sql.clj#L292
Perhaps you can look at honeysql for a more sophisticated DSL?
https://github.com/jkk/honeysql
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
A reasonably simple optimisation would be to automatically identify self-recursion in tail position and convert it directly to recur. I think that's possibly the kind of optimisation pass that the OP was suggesting. That's exactly the kind of thing I was thinking about with recur. If you can take the trouble to write a macro for tail-call optimization, you can take the trouble to write a macro to do what you're describing. So what's the status on further enhancements to the Clojure compiler? Is there anyone working on improving it, not just maintaining it (besides adding core.matrix, which is different)? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On Tue, Jul 9, 2013 at 10:28 AM, Mikera mike.r.anderson...@gmail.comwrote: A reasonably simple optimisation would be to automatically identify self-recursion in tail position and convert it directly to recur. I think that's possibly the kind of optimisation pass that the OP was suggesting. One thing that would be neat, if feasible, would be to make it possible to do tail call elimination in situations where you can't currently use recur because there's already a target established---if you have something like (defn foo [...] (loop [...] (if some-condition (recur ...) (foo ... where you can't use recur for the call to foo, even though it's in tail position, because the recur target is the loop expression. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] java.jdbc documentation has moved!
2013/7/9 Sean Corfield seancorfi...@gmail.com This opens up contributions to the community at large so I hope to see plenty of activity as folks send PRs for their favorite hints, tips, and tricks with this library. Where to send pull requests: http://github.com/clojuredocs/guides I'm personally very happy that clojure.java.jdbc is now open for doc contributions from people without paper Clojure CA on file. SQL databases are not going away any time soon and having an easy to use, well documented Clojure library for them should be of top importance to the community (if you ask me). -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
Hi Pedestallions, as all the others I have been waiting for this tutorial too. Is there a motivation why you decide to not taking into account any progressive enhancement techniques? Should we assume that progressive enhancement is dead? I just went throw this article http://jakearchibald.com/2013/progressive-enhancement-still-important/ which seems to say that progressive enhancement is like the rock'n roll: it's here to stay. Anyway, great piece of work! My best Mimmo On Jul 9, 2013, at 7:25 PM, Manuel Paccagnella wrote: I was expecting a tutorial, and now we get this. Speechless. Thank you very much, I'll work through it! Il giorno martedì 9 luglio 2013 18:03:58 UTC+2, Ryan Neufeld ha scritto: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
The TCO macro already exists: https://github.com/cjfrisz/clojure-tco On Tue, Jul 9, 2013 at 1:39 PM, Ben Wolfson wolf...@gmail.com wrote: On Tue, Jul 9, 2013 at 10:28 AM, Mikera mike.r.anderson...@gmail.comwrote: A reasonably simple optimisation would be to automatically identify self-recursion in tail position and convert it directly to recur. I think that's possibly the kind of optimisation pass that the OP was suggesting. One thing that would be neat, if feasible, would be to make it possible to do tail call elimination in situations where you can't currently use recur because there's already a target established---if you have something like (defn foo [...] (loop [...] (if some-condition (recur ...) (foo ... where you can't use recur for the call to foo, even though it's in tail position, because the recur target is the loop expression. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clj-wamp 1.0.0-rc1 is released
Glad to hear! Let me know if you run into any rough spots. Over the next few weeks I plan to do some more thorough profiling/load testing for any tuning that could be done before a final 1.0.0 release. On Monday, July 8, 2013 9:09:50 PM UTC-4, Jason Gilman wrote: Thanks for the awesome library. I've been using it for a couple weeks now and it's been really easy to use. I appreciate the great documentation. On Monday, July 8, 2013 11:54:00 AM UTC-4, Christopher Martin wrote: clj-wamp: WAMP WebSocket subprotocol for HTTP Kit. New release of clj-wamp *1.0.0-rc1* includes: - Feature: WAMP-CRA (Challenge Response Authentication). - Feature: WebSocket subprotocol and origin header validation in an optional response handler (`with-channel-validation`). - Dependency update: [http-kit 2.1.5] for bugfix #68 Loop of Close frames https://github.com/http-kit/http-kit/issues/68. The tutorial has been updated with a new section on WAMP-CRA usage: http://cljwamp.us/tutorial#wampcra Clojars: [clj-wamp 1.0.0-rc1] Repo: https://github.com/cgmartin/clj-wamp Cheers, ~Christopher Martin http://cljwamp.us -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ClassCastException in APersistentVector.doEquiv with custom implementation of IPersistentVector
Hello, Suppose I have a byte array representing an array of integers: $ clojure-repl Clojure 1.5.1 user= (def v (let [a (byte-array (map byte [0 0 0 1 0 2 0 3]))] (reify clojure.lang.IPersistentVector clojure.lang.Seqable (seq [_] (for [i (range 0 (alength a) 2)] (bit-or (bit-shift-left (aget a i) 8) (aget a (inc i #'user/v user= (println v) [0 1 2 3] nil user= (= [0 1 2 3] v) ClassCastException user$fn$reify__2 cannot be cast to java.util.Collection clojure.lang.APersistentVector.doEquiv (APersistentVector.java:88) This is because doEquiv assumes that an instance of IPersistentVector also is an instance of Collection. While that may be true for standard Clojure data structures, this may not necessarily be the case for custom implementations. Am I really the first one to attempt something like that? Am I not supposed to write custom implementations of standard interfaces? Should that bug be raised in JIRA? Thanks, Vincent -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ClassCastException in APersistentVector.doEquiv with custom implementation of IPersistentVector
From the lack of extending java's Collection in IPersistentVector or associated interfaces, it seems like the intent is for every implementation to extend (proxy) APersistentVector. Is that sufficient for what you're trying to do? None of the methods in there are final. On Tue, Jul 9, 2013 at 2:32 PM, Vincent vhenneb...@gmail.com wrote: Hello, Suppose I have a byte array representing an array of integers: $ clojure-repl Clojure 1.5.1 user= (def v (let [a (byte-array (map byte [0 0 0 1 0 2 0 3]))] (reify clojure.lang.IPersistentVector clojure.lang.Seqable (seq [_] (for [i (range 0 (alength a) 2)] (bit-or (bit-shift-left (aget a i) 8) (aget a (inc i #'user/v user= (println v) [0 1 2 3] nil user= (= [0 1 2 3] v) ClassCastException user$fn$reify__2 cannot be cast to java.util.Collection clojure.lang.APersistentVector.doEquiv (APersistentVector.java:88) This is because doEquiv assumes that an instance of IPersistentVector also is an instance of Collection. While that may be true for standard Clojure data structures, this may not necessarily be the case for custom implementations. Am I really the first one to attempt something like that? Am I not supposed to write custom implementations of standard interfaces? Should that bug be raised in JIRA? Thanks, Vincent -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On Tue, Jul 9, 2013 at 10:46 AM, Gary Trakhman gary.trakh...@gmail.comwrote: The TCO macro already exists: https://github.com/cjfrisz/clojure-tco That is super cool. I feel compelled to observe that using a continuation monad run by a trampoline also allows for tail call elimination: user= (require '[monads.cont :as c] '[monads.core :refer [= return]]) nil user= (declare od?) #'user/od? user= (defn evn? [x] (if (zero? x) (return true) (od? (dec x #'user/evn? user= (defn od? [x] (if (zero? x) (return false) (= (return nil) (fn [_] (evn? (dec x)) #'user/od? user= (c/run-cont (evn? 500)) true But the result is about 2x slower than what the clojure-tco macro produces (around 600ms vs around 300ms, for me). -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
Hi Pedestal Team, this is great. Thank you very much! Roman On Tuesday, July 9, 2013 6:03:58 PM UTC+2, Ryan Neufeld wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure interpreters?
On Tue, Jul 9, 2013 at 1:22 AM, Mikera mike.r.anderson...@gmail.com wrote: My post The Environment as a Value might be of interest to you. https://groups.google.com/forum/#!searchin/clojure-dev/immutable$20environment/clojure-dev/S8BawG7nzJA/qfCd7hn67aoJ It contains a lot of similar ideas. An important point is that you don't necessarily need an interpreter to get the benefits of an immutable isolated environment: this can still be fully compiled. Ah yes, I remember that post. Here is my take: It would be easier to do this first as an interpreter. There's just fewer problems to solve that way. Most importantly, its possible to bypass all JVM-implementation-detail-related issues, at least for pure Clojure code. For instance, in an interpreter, deftype/defrecord don't need to generate java classes. My idea is a little different though. An interpretive environment can do things that a compiled one cannot. For instance, runtime errors can return literal code snippets, rather than class names / line numbers. Or, you can a la carte assign new interpretations to functions and classes you do not control. You can also change the semantics of the language itself, to support things like partial evaluation. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure interpreters?
On Mon, Jul 8, 2013 at 8:58 PM, Shantanu Kumar kumar.shant...@gmail.comwrote: An interpreter would be great! I attempted a different approach, which simply evaluates an S-expression with a user-specified environment (collection of maps), here: https://github.com/kumarshantanu/quiddity Thanks for the pointer! This is the kind of thing I was hoping to find, and look at. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure interpreters?
An issue with an interpreter is keeping semantics in sync with canonical clojure. Unfortunately, since 'Clojure' is a superset of java's semantics, it's possible to have different behavior with regards to classloading and such. Environment-as-a-value means decoupling vars and such from being globally accessible, which implies they need to be implemented as sort of a dependency-injection system with lookup detached from java classes, yet lots of implementation details of clojure rely on java-isms. One effort in this direction is immutant: http://immutant.org/news/2012/05/18/runtime-isolation/ Just something else to think about. The result might be closer to clojurescript than clojure (which I'd also be interested in, I'm thinking clojure on android-java without all the class overhead. Clojurescript and phonegap is more limited.) On Tue, Jul 9, 2013 at 2:53 PM, kovas boguta kovas.bog...@gmail.com wrote: On Tue, Jul 9, 2013 at 1:22 AM, Mikera mike.r.anderson...@gmail.comwrote: My post The Environment as a Value might be of interest to you. https://groups.google.com/forum/#!searchin/clojure-dev/immutable$20environment/clojure-dev/S8BawG7nzJA/qfCd7hn67aoJ It contains a lot of similar ideas. An important point is that you don't necessarily need an interpreter to get the benefits of an immutable isolated environment: this can still be fully compiled. Ah yes, I remember that post. Here is my take: It would be easier to do this first as an interpreter. There's just fewer problems to solve that way. Most importantly, its possible to bypass all JVM-implementation-detail-related issues, at least for pure Clojure code. For instance, in an interpreter, deftype/defrecord don't need to generate java classes. My idea is a little different though. An interpretive environment can do things that a compiled one cannot. For instance, runtime errors can return literal code snippets, rather than class names / line numbers. Or, you can a la carte assign new interpretations to functions and classes you do not control. You can also change the semantics of the language itself, to support things like partial evaluation. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any suggestions for configuration solution in Clojure or Java world?
I'm using rather trivial solution: store config in Clojure file (as a hash), here's what my config bootstrap looks like: https://github.com/ifesdjeen/utils/blob/master/src/com/ifesdjeen/utils/config.clj lg, Alex http//twitter.com/ifesdjeen http://clojurewerkz.org/ On June 18, 2013 at 4:51:22 AM, Mingqi Shao (ms...@tripadvisor.com) wrote: Josh, thank your suggestions. I glanced Carica found look very simple (I hate complex) and nice. Could you share your practices how to deal with difference environments, dev and online? thanks On Tue, Jun 18, 2013 at 1:08 AM, josh rotenberg joshrotenb...@gmail.com wrote: I like carica for configuration: https://github.com/sonian/carica I switched a project over from the typesafe config package (with my own very thin Clojure wrapper around it) to carica and found it really nice to work with. Josh -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
Maybe the Shen programming language could be of interest to you. http://shenlanguage.org/ It's a portable functional typed dialect of Lisp. Looks quite elegant to me, and it targets Clojure, amongst other languages. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
edn-format parsers (eg, Common Lisp)?
I'm intrigued by edn (extensible data notation), as described here: https://github.com/edn-format/edn It seems cleaner and more expressive than JSON, so I'm looking into using it for a current project. However, I haven't seen a summary of parser and/or generator implementations for this format. I'm particularly interested in finding an edn parser for Common Lisp. If anyone has something of this nature, please post a note to the list (or contact me offline). If I get some useful responses, I'll put together a wiki page. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Is this idiomatic for a recurring function?
Hi, I'm new to clojure and I'd like to know if this is the best/idiomatic way of solving this particular task: I have a list of strings of variable length, and I want to find the position or index number of the list whose cumulative size from the head of the list matches a given target number. For example, if this is the list: (def my-list '(abc x00b nanana zoot)) Then the index for a cumulative target length of 10 is 2, since: (count (nth my-list 0)) - 3 : cumulative size = 3 (count (nth my-list 1)) - 4 : cumulative size = 7 (count (nth my-list 2)) - 6 : cumulative size = 13 -- 10 is less than 13 Here's how I wrote the function: (defn get-length-match [my-list target-length counted-length ind] (let [current-len (count (first my-list))] (if (= counted-length target-length) ind (recur (rest my-list) target-length (+ counted-length current-len) (inc ind) Ideally, I'd want the counted-length and ind parameters to be optional, defaulting to 0 and -1 respectively, but I wasn't sure if clojure allows for it (trying to define defaults for those in the function gave me a compiler error). So while the function works as intended, I wanted to find out if it could be improved or made more idiomatic? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: edn-format parsers (eg, Common Lisp)?
Perhaps you've not seen this: https://github.com/edn-format/edn/wiki/Implementations (But there's no CL implementation listed there.) //Ben On Tuesday, July 9, 2013, Rich Morin wrote: I'm intrigued by edn (extensible data notation), as described here: https://github.com/edn-format/edn It seems cleaner and more expressive than JSON, so I'm looking into using it for a current project. However, I haven't seen a summary of parser and/or generator implementations for this format. I'm particularly interested in finding an edn parser for Common Lisp. If anyone has something of this nature, please post a note to the list (or contact me offline). If I get some useful responses, I'll put together a wiki page. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com javascript:; http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.comjavascript:; Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com javascript:; For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is this idiomatic for a recurring function?
On Tue, Jul 9, 2013 at 1:22 PM, Denis Papathanasiou denis.papathanas...@gmail.com wrote: (defn get-length-match [my-list target-length counted-length ind] (let [current-len (count (first my-list))] (if (= counted-length target-length) ind (recur (rest my-list) target-length (+ counted-length current-len) (inc ind) Ideally, I'd want the counted-length and ind parameters to be optional, defaulting to 0 and -1 respectively, but I wasn't sure if clojure allows for it (trying to define defaults for those in the function gave me a compiler error). What you're looking for is: (defn get-length-match [my-list target-length] (loop [my-list my-list, counted-length 0, ind -1] ...)) In your recur, you can now omit target-length, but the rest of the code stays the same. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On 9 July 2013 19:39, Ben Wolfson wolf...@gmail.com wrote: One thing that would be neat, if feasible, would be to make it possible to do tail call elimination in situations where you can't currently use recur because there's already a target established---if you have something like [...] I agree, that's long been on my wish list, although what I had in mind was support for naming loop (with an optional symbolic name right after 'loop) and a separate recur-to form for recurring to such named loops (with recur always working for the innermost loop, whether named or not). I've implemented a proof of concept in ClojureScript, available here if you'd like to take it for a spin: https://github.com/michalmarczyk/clojurescript/tree/recur-to Actual commit: https://github.com/michalmarczyk/clojurescript/commit/feba0a078138da08d584a67e671415fc403fa093 I've posted about it to the dev group, linking to Ben's message above: https://groups.google.com/d/msg/clojure-dev/imtbY1uqpIc/8DWLw8Ymf4IJ Cheers, Michał -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
Mimmo, Our focus has definitely been on exploring new ideas; supporting progressive enhancement has not been a focus of ours. Given the nature of the kinds of applications we're building in Pedestal today (extremely rich and collaborative ClojureScript applications) I don't see many avenues to add this support in the near term. One could certainly write progressive HTML templates, but as soon as we cross into the boundary of system behavior things get a little hairy - I get the impression it is an all or nothing affair. Did you have any thoughts about how pedestal-app could better support progressive enhancement? -- Ryan Neufeld On Jul 9, 2013, at 1:41 PM, Giacomo Cosenza mimmo.cose...@gmail.com wrote: Hi Pedestallions, as all the others I have been waiting for this tutorial too. Is there a motivation why you decide to not taking into account any progressive enhancement techniques? Should we assume that progressive enhancement is dead? I just went throw this article http://jakearchibald.com/2013/progressive-enhancement-still-important/ which seems to say that progressive enhancement is like the rock'n roll: it's here to stay. Anyway, great piece of work! My best Mimmo On Jul 9, 2013, at 7:25 PM, Manuel Paccagnella wrote: I was expecting a tutorial, and now we get this. Speechless. Thank you very much, I'll work through it! Il giorno martedì 9 luglio 2013 18:03:58 UTC+2, Ryan Neufeld ha scritto: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups pedestal-users group. To unsubscribe from this group and stop receiving emails from it, send an email to pedestal-users+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/pedestal-users. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
On 9 July 2013 17:11, Alexander Gunnarson alexandergunnar...@gmail.com wrote: Final Solution (defn solveit-4 [t0 y0 h its] (let [zero (long 0)] (loop [t0 (double t0) y0 (double y0) h (double h) its (long its)] (if ( its zero) (let [t1 (+ t0 h) y1 (+ y0 (* h (- t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its] Functions of up to four arguments can take primitives directly: (defn solveit [^double t0 ^double y0 ^double h ^long its] ...) Also, the hinting of 0 with long should not be necessary, as it's currently the default for an integer literal (without an N signifying bigint at the end). I'm not going to benchmark now, but the original version with hints added in the parameter vector as above should perform just like solveit-4. Cheers, Michał -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Doc about auto-namespaced keywords (e.g. ::user)?
Hi all, while reading the documentation for friend, I stumbled upon auto-namespaced keywords -- how can I find more doc about them? I'm trying to use friend within a luminus templated webapp, and lein ring server returns this error when I use ::user: CompilerException: java.lang.RuntimeException: Invalid token: ::users/user, compiling:(kickhub/routes/auth.clj:141:37) Thanks in advance for any pointer! -- Bastien -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is this idiomatic for a recurring function?
Hi, and thanks for your reply. On Tuesday, July 9, 2013 4:41:36 PM UTC-4, puzzler wrote What you're looking for is: (defn get-length-match [my-list target-length] (loop [my-list my-list, counted-length 0, ind -1] ...)) In your recur, you can now omit target-length, but the rest of the code stays the same. So I should use loop together with recur? Does the recur at that point recursively call the function, or does it refer to the loop? Based on the docs, I think it's the latter, but it's not entirely clear. Also, in clojure is loop preferable to iteration by recursion as I had it originally? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is this idiomatic for a recurring function?
Just for fun, a version without loop, : (def my-list '(abc x00b nanana zoot)) (defn length-match [my-list target-length] (first (keep-indexed (fn [idx len] (when (= len target-length) idx)) (reductions + (map count my-list) (length-match my-list 10) ; = 2 or the strictly equivalent threaded version: (def my-list '(abc x00b nanana zoot)) (defn length-match [my-list target-length] (- my-list (map count) (reductions +) (keep-indexed (fn [idx len] (when ( len target-length) idx))) first)) (length-match my-list 10) 2 HTH -- Laurent 2013/7/9 Mark Engelberg mark.engelb...@gmail.com: On Tue, Jul 9, 2013 at 1:22 PM, Denis Papathanasiou denis.papathanas...@gmail.com wrote: (defn get-length-match [my-list target-length counted-length ind] (let [current-len (count (first my-list))] (if (= counted-length target-length) ind (recur (rest my-list) target-length (+ counted-length current-len) (inc ind) Ideally, I'd want the counted-length and ind parameters to be optional, defaulting to 0 and -1 respectively, but I wasn't sure if clojure allows for it (trying to define defaults for those in the function gave me a compiler error). What you're looking for is: (defn get-length-match [my-list target-length] (loop [my-list my-list, counted-length 0, ind -1] ...)) In your recur, you can now omit target-length, but the rest of the code stays the same. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is this idiomatic for a recurring function?
Besides, there's a bug in your implementation if target-length is bigger that the total cumulative length : it will neer terminate With the hof version I suggested, it just gracefully returns nil :-D 2013/7/9 Laurent PETIT laurent.pe...@gmail.com: Just for fun, a version without loop, : (def my-list '(abc x00b nanana zoot)) (defn length-match [my-list target-length] (first (keep-indexed (fn [idx len] (when (= len target-length) idx)) (reductions + (map count my-list) (length-match my-list 10) ; = 2 or the strictly equivalent threaded version: (def my-list '(abc x00b nanana zoot)) (defn length-match [my-list target-length] (- my-list (map count) (reductions +) (keep-indexed (fn [idx len] (when ( len target-length) idx))) first)) (length-match my-list 10) 2 HTH -- Laurent 2013/7/9 Mark Engelberg mark.engelb...@gmail.com: On Tue, Jul 9, 2013 at 1:22 PM, Denis Papathanasiou denis.papathanas...@gmail.com wrote: (defn get-length-match [my-list target-length counted-length ind] (let [current-len (count (first my-list))] (if (= counted-length target-length) ind (recur (rest my-list) target-length (+ counted-length current-len) (inc ind) Ideally, I'd want the counted-length and ind parameters to be optional, defaulting to 0 and -1 respectively, but I wasn't sure if clojure allows for it (trying to define defaults for those in the function gave me a compiler error). What you're looking for is: (defn get-length-match [my-list target-length] (loop [my-list my-list, counted-length 0, ind -1] ...)) In your recur, you can now omit target-length, but the rest of the code stays the same. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is this idiomatic for a recurring function?
For comparison's sake, here's a version made with higher order functions. HOF based functions are usually considered more idiomatic Clojurehttp://www.ehrdclj.org/files/27-March-2013-cgrand-YAGNI.pdfthan (loop-)recur ones. However, I've found that performance wise loop-recur ones often win. (defn length-index [coll target-length] (- coll (map-indexed (fn [idx, word] [idx (count word)])) (reductions (fn [[acc_idx acc_len] [idx len]] [idx (+ acc_len len)]) [0 0] ) (filterv (fn [[idx cum_len]] (= cum_len target-length)) ) ffirst)) On Tuesday, July 9, 2013 11:18:29 PM UTC+2, Denis Papathanasiou wrote: Hi, and thanks for your reply. On Tuesday, July 9, 2013 4:41:36 PM UTC-4, puzzler wrote What you're looking for is: (defn get-length-match [my-list target-length] (loop [my-list my-list, counted-length 0, ind -1] ...)) In your recur, you can now omit target-length, but the rest of the code stays the same. So I should use loop together with recur? Does the recur at that point recursively call the function, or does it refer to the loop? Based on the docs, I think it's the latter, but it's not entirely clear. Also, in clojure is loop preferable to iteration by recursion as I had it originally? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is this idiomatic for a recurring function?
So I should use loop together with recur? Does the recur at that point recursively call the function, or does it refer to the loop? Yes, it refers to the loop. The loop form is usually used to 'hide away' additional parameters that are needed in the loop itself, but not in the function call itself. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
Hy Rayan, On Jul 9, 2013, at 11:01 PM, Ryan Neufeld r...@thinkrelevance.com wrote: Mimmo, Our focus has definitely been on exploring new ideas; supporting progressive enhancement has not been a focus of ours. Given the nature of the kinds of applications we're building in Pedestal today (extremely rich and collaborative ClojureScript applications) I don't see many avenues to add this support in the near term. One could certainly write progressive HTML templates, but as soon as we cross into the boundary of system behavior things get a little hairy - I get the impression it is an all or nothing affair. Sure, I understand. The trend is speaking by itself. Did you have any thoughts about how pedestal-app could better support progressive enhancement? Probably by working on homogenising Enlive/Enfocus (and hiccups/hiccup) we could share the same codebase to serve both the client-side and the server-side. To me HTML transformation and DOM manipulation are almost the same beast and I really do not understand why we call it transformation on the HTML side and manipulation on the client-side. DOM is HTML plus a much more rich set of events (but there are events on the server-side too, if we interpret rest verbs as events). In Enlive and Enfocus we have almost the same selectors and the same transformations/manipulation. Enfocus is close to be Enlive + Domina Events + Effects, but the base is almost the same. I'm just thinking about keep this wonderful unifying language to share as mach as possible codebase. Imagine the same codebase that serve a full animates DOM but even a plain HTML page, just with less dynamism. My best mimmo -- Ryan Neufeld On Jul 9, 2013, at 1:41 PM, Giacomo Cosenza mimmo.cose...@gmail.com wrote: Hi Pedestallions, as all the others I have been waiting for this tutorial too. Is there a motivation why you decide to not taking into account any progressive enhancement techniques? Should we assume that progressive enhancement is dead? I just went throw this article http://jakearchibald.com/2013/progressive-enhancement-still-important/ which seems to say that progressive enhancement is like the rock'n roll: it's here to stay. Anyway, great piece of work! My best Mimmo On Jul 9, 2013, at 7:25 PM, Manuel Paccagnella wrote: I was expecting a tutorial, and now we get this. Speechless. Thank you very much, I'll work through it! Il giorno martedì 9 luglio 2013 18:03:58 UTC+2, Ryan Neufeld ha scritto: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups pedestal-users group. To unsubscribe from this group and stop receiving emails from it, send an email to pedestal-users+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/pedestal-users. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: edn-format parsers (eg, Common Lisp)?
On Jul 9, 2013, at 13:37, Ben Smith-Mannschott wrote: Perhaps you've not seen this: https://github.com/edn-format/edn/wiki/Implementations (But there's no CL implementation listed there.) Yep; I had missed that. Thanks! -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
core.async pub/sub
Hey, I'm doing some core.async tests and want to create a basic pub/sub model. Messages are ! on one channel and ! to many others. (deftest ^:wip async-test2 (let [subscribers (atom []) events (chan 100)] (go (loop [] (when-let [ev (! events)] (doseq [c @subscribers] (alt! [[c ev]] :sent :default nil ;; could force unsubscribe c? )) (recur (let [s1 (chan 1) s2 (chan 100) r1 (atom []) r2 (atom [])] (swap! subscribers conj s1 s2) ;; simulated slow reader (go (loop [] (when-let [ev (! s1)] (swap! r1 conj ev) (! (timeout 10)) (recur ;; good reader (go (loop [] (when-let [ev (! s2)] (swap! r2 conj ev) (recur (!! (go (loop [i 0] (when ( i 100) (! events i) (recur (inc i)) (close! events) (Thread/sleep 25) (pprint @r1) (pprint @r2)) )) In this example the s1 subscriber will loose almost all messages since he cannot keep up (and buffer is too small). I choose to alt!/:default to drop messages, since I don't want any subscriber to block others. How do you guys deal with slow-readers? I don't really have a specific problem but I wonder if there are any plans for some built-in pub/sub mechanisms for core.async. Seems like a very common pattern. Anyways, core.async is nice! Cheers, /thomas -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
Hi Mikera, For your mutable var loop example, I think with-local-vars should do what you want. It would be fantastic if the Clojure compiler could optimise these cases better, especially common higher-order use cases (like stream fusion). Unfortunately what always seems to kill the possibility is the fact that functions calls have to be indirected through vars. In the end those that want more performance will always have to sacrifice a little dynamicity (dynamicness? dynamism?) it seems. Cheers, Colin On 10 July 2013 05:28, Mikera mike.r.anderson...@gmail.com wrote: On Tuesday, 9 July 2013 17:31:21 UTC+1, puzzler wrote: On Tue, Jul 9, 2013 at 8:11 AM, Alexander Gunnarson alexander...@gmail.com wrote: My idea, which is probably very naive, but one which I'm curious about, is: *Is it possible to have some sort of set of automatic-optimizing macros that work on Clojure code to preserve elegance while maximizing performance?* * * In theory, it would be kind of an abstraction layer. There would be one file that would store the code that gets read and another output file that stores the code that actually gets evaluated by the REPL, and a set of macros to optimize the front-end, abstracted file into the output, nuts-and-bolts file to be evaluated by the REPL. Probably this would be a very intensive process - I don't know. But maybe it's worth the trouble after all to save a ton of programmer-hours by increasing readability. I think you're probably underestimating the scope of what the Clojure compiler already does. Arguably, it already is an auto-optimizing process that works on Clojure code to preserve elegance while maximing performance. The Clojure Compiler is fine, but it doesn't really do much in the way of optimisation yet. It mainly just emits bog-standard bytecode corresponding to the (macro-expanded) Clojure source. The good news is that the JVM JIT is exceptionally good at micro-optimisation and this still results in pretty decent performance. The bad news is that we are missing a lot of opportunities to do optimisations that the JVM JIT can't possibly do (because it doesn't know anything about the higher level structure and assumptions in the code). I think we should aspire to improve the compiler further: we should encourage ideas and discussions about how to improve it. I'd personally love to see Clojure match Java/Scala in performance for idiomatic code, but we are still currently some way off. For the most part, Clojure programmers seem to be satisfied with dropping down to Java when the Clojure code gets too low-level to be elegant (although I think many would disagree that your examples have reached the level of inelegance). Still, there's probably room for something that targets the performance gap between Clojure and Java. I'm interested in an assembly-like DSL that could be easily interwoven with Clojure code, something like: http://www.rebol.com/docs/**rebcode.htmlhttp://www.rebol.com/docs/rebcode.html Zach Tellman recently released a library that does something like that: https://github.com/ztellman/**primitive-mathhttps://github.com/ztellman/primitive-math So far, the vast majority of Clojure performance improvements have focused on making it easier to work with primitive numbers (in loops and as function inputs), because Java's boxed numerics is what usually kills performance. I've only found these improvements marginally useful because I find that most numbers eventually end up in a Clojure data structure, where they become boxed. That's one of the reasons why we are building core.matrix :-) For me, the most useful thing would be an ability to drop down and do fast pointer manipulation and other mutable work, without having to go all the way to Java. Yeah, I've always wanted this too. Especially for mutable local counters / accumulators. I'd love to be able to do something like: (let [^:mutable a 0 , ^:mutable b 0] (dotimes [i 1000] (set! a (+ a (foo i))) (set! b (+ b (bar i ... more stuff with a and b) This should compile down to something that performs the same as the equivalent loop in Java. Of course, it would be even better if the following could compile down to the same optimised loop: (reduce (fn [[a b] i] [(+ a (foo i)) (+ b (bar i))]) [0 0] (range 1000)) But currently. the Clojure reduce version is around 20-50x slower vs. equivalent Java code. Going in the other direction, I'd be interested in mechanisms that made it easier to write recursive code without having to worry about stack overflow. A reasonably simple optimisation would be to automatically identify self-recursion in tail position and convert it directly to recur. I think that's possibly the kind of optimisation pass that the OP was suggesting. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group,
Re: [ANN] Pedestal-app Tutorial has been released
Whoa, for anyone interested in learning pedestal-app or dataflow web programming, it would feel incredibly wrong to _not_ dive into this tutorial! Thanks Ryan and other contributors, and thanks Relevance! Now, regarding the Getting Started page, it suggests we start from the lein new pedestal-app template. That said, it also (very slightly) suggests we clone checkout v2.0.0 of app-tutorial to start from there. (Especially if we keep in mind that at the root of the Wiki, it's written that if we skip steps, we should not forget to checkout the appropriate previous step's tag. But of course this most certainly only applies to people skipping steps.) From my current understanding, there is no need to clone checkout anything if you're willing to work your way through each step of the tutorial. I suggest you make this bit much more explicit. That said, if you prefer this kind of comment inside of a GitHub issue, let me oblige myself on a single word of yours. - And thank you again! On Tuesday, July 9, 2013 12:03:58 PM UTC-4, Ryan Neufeld wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: testselector
At work I noticed that every once in a while we'd forget to add test selectors to our tests, which means that they may not get executed by CI. To prevent this I wrote testselector as a way to periodically check that all deftests have one of the expected metadatas present. It is really simple to use with leiningen: lein run -m testselector.checker . [:unit :integration :end-to-end] ;; = [#'testselector.checker-test/a-test-without-metadata] or from the command-line: (require '[testselector.checker :as checker]) (checker/check #/apps/my-app/ [:unit :integration :end-to-end]) https://github.com/runa-dev/testselector -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
There definitely isn't a *need* to clone or checkout steps, but it certainly doesn't hurt to have a clean slate at each stage (especially considering at this time pedestal-app errors can be kind of opaque–we're working on that). WRT GitHub issues vs. Mailing lists – it's my personal preference to do things over GitHub. Thanks for checking it out. -- Ryan Neufeld On Jul 9, 2013, at 10:19 PM, danieljom...@gmail.com wrote: Whoa, for anyone interested in learning pedestal-app or dataflow web programming, it would feel incredibly wrong to _not_ dive into this tutorial! Thanks Ryan and other contributors, and thanks Relevance! Now, regarding the Getting Started page, it suggests we start from the lein new pedestal-app template. That said, it also (very slightly) suggests we clone checkout v2.0.0 of app-tutorial to start from there. (Especially if we keep in mind that at the root of the Wiki, it's written that if we skip steps, we should not forget to checkout the appropriate previous step's tag. But of course this most certainly only applies to people skipping steps.) From my current understanding, there is no need to clone checkout anything if you're willing to work your way through each step of the tutorial. I suggest you make this bit much more explicit. That said, if you prefer this kind of comment inside of a GitHub issue, let me oblige myself on a single word of yours. - And thank you again! On Tuesday, July 9, 2013 12:03:58 PM UTC-4, Ryan Neufeld wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- You received this message because you are subscribed to the Google Groups pedestal-users group. To unsubscribe from this group and stop receiving emails from it, send an email to pedestal-users+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/pedestal-users. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Pedestal-app Tutorial has been released
This is so cool! Brenton and Ryan, thanks so much for taking the time to write this. On Tuesday, July 9, 2013 12:03:58 PM UTC-4, Ryan Neufeld wrote: Hey there, Clojurians/Pedestallions! I'm pleased to announce the release of a comprehensive tutorial for pedestal-app: http://bit.ly/pedestal-app-tutorial. In this tutorial we finally *dive deep* into the guts of pedestal-app and build a distributed multiplayer game using pedestal-app. Major kudos to @brentonashworth for all his hard work on the pedestal-app tutorial. Enjoy! -- Ryan Neufeld -- Ryan Neufeld -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Vertigo: fast, idiomatic C-style structs
Last year, I gave a talk at the Conj on my attempt to write an AI for the board game Go. Two things I discovered is that it was hard to get predictable performance, but even once I made sure I had all the right type hints, there was still a lot of room at the bottom for performance improvements. Towards the end [1], I mentioned a few ideas for improvements, one of which was simply using ByteBuffers rather than objects to host the data. This would remove all the levels of indirection, giving much better cache coherency, and also allow for fast unsynchronized mutability when the situation called for it. So, ten months and several supporting libraries [2] [3] later, here it is: https://github.com/ztellman/vertigo At a high level, this library is useful whenever your datatype has a fixed layout and is used more than once. Depending on your type, it will give you moderate to large memory savings, and if you're willing to forgo some of core library in favor of Vertigo's operators, you can get significant performance gains on batch operations. And, in the cases where performance doesn't matter, it will behave exactly like any other Clojure data structure. I want to point out that something like this would be more or less impossible in Java; reading from an offset in a ByteBuffer without the compile-time inference and validation provided by this library would be pointlessly risky. There's not a lot of low-level Clojure libraries, but there's an increasing amount of production usage where people are using Clojure for performance-sensitive work. I'm looking forward to seeing what people do with Vertigo and libraries like it. Zach [1] http://www.youtube.com/watch?feature=player_detailpagev=v5dYE0CMmHQ#t=1828s [2] https://github.com/ztellman/primitive-math [3] https://github.com/ztellman/byte-streams -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure: Elegance vs. Performance?
I've just released Vertigo [1], which I describe in this thread: https://groups.google.com/forum/#!topic/clojure/BayfuaqMzvs. I suspect this has some bearing on the conversation. Zach [1] https://github.com/ztellman/vertigo On Tuesday, July 9, 2013 8:11:58 AM UTC-7, Alexander Gunnarson wrote: Hello everyone! It's great to be here with all you fellow Clojurians. Just so you know, this is my first post on this group, so don't shoot me if it's terrible ;) As background, I've been working through SICP and have been loving Scheme. It's almost breathtaking how elegant and clean the code can be (I had some moments like xkcd goes off abou http://xkcd.com/224/t). Of course, though Scheme is beautiful and simple, everyone knows that it's not especially practical, in general. I love the Lisp paradigms but I'm not really a fan of CL so I did some looking around and stumbled upon Clojure. It seems that Clojure really has a lot going for it between shockingly easy concurrency support and Java interop, among other things. But one thing that's been bothering me is that it seems like to optimize performance in Clojure, you have to sacrifice some elegance. *Example 1: Tail-call recursion* *Scheme* One example would be tail-call recursion. For instance, normally in Scheme I'd naively implement an iterative exponent function like this: (define (expt x n) (cond ((= 0 n) 1) ((= 1 n) x) (else (expt (* x x) (- n 1) Pure. Simple. Beautiful. (Not that I'm the best Scheme programmer ever, but to me it looks beautiful, and it conforms well to the base of the problem. You get the point.) *Clojure* Of course, tail-call recursion is not possible with JVM, so Clojure uses a *recur* macro in place of direct recursive function calling. It avoids blowing the stack as quickly but it's still not 100% mathematically pure in the way Scheme tends to be. An added gripe is that the* else *form within *cond *in Clojure uses a keyword, *:else*, instead of the more consistent parenthetical form used in Scheme. I suppose that's to make it less Lispy. But it just ends up making it a little less elegant. *Example 2: Type casting* * * Some have said that Clojure can be somewhat slow (as with all Lisps). I'm not sure how true this is, but I stumbled on an example on John Lawrence Aspden's bloghttp://www.learningclojure.com/2013/02/clojure-is-fast-is-clojure-still-fast.html. He wrote a program to implement Euler's method like so: *First Solution* (defn f [t y] (- t y)) (defn solveit [t0 y0 h its] (if ( its 0) (let [t1 (+ t0 h) y1 (+ y0 (* h (f t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its])) He points out that if this was an assembly language program that worked the way you'd expect, each loop would take 7 cycles. So he tests it for Clojure. The result? On his netbook with Clojure 1.4: 2400 cycles. As he says, We're looking at a slowdown of about 300 times over what we could probably achieve coding in assembler or in C with a good optimizing compiler. That's not surprising, I suppose, but it's still a little disheartening. After all, you want your language to be fast, right? Well, after a few iterations, he manages to reduce the cycles way down - all the way down, in fact, to 37, which is quite a feat. Like so: *Final Solution* (defn solveit-4 [t0 y0 h its] (let [zero (long 0)] (loop [t0 (double t0) y0 (double y0) h (double h) its (long its)] (if ( its zero) (let [t1 (+ t0 h) y1 (+ y0 (* h (- t0 y0)))] (recur t1 y1 h (dec its))) [t0 y0 h its] But the thing is, between the *recur *macro, explicit typecasting, and the *loop* construct, yes, you have a very significant performance increase, but it the code's gotten bigger, much less readable, and much less elegant. *The bottom line* * * My idea, which is probably very naive, but one which I'm curious about, is: *Is it possible to have some sort of set of automatic-optimizing macros that work on Clojure code to preserve elegance while maximizing performance?* * * In theory, it would be kind of an abstraction layer. There would be one file that would store the code that gets read and another output file that stores the code that actually gets evaluated by the REPL, and a set of macros to optimize the front-end, abstracted file into the output, nuts-and-bolts file to be evaluated by the REPL. Probably this would be a very intensive process - I don't know. But maybe it's worth the trouble after all to save a ton of programmer-hours by increasing readability. Thoughts? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To
matrix: masked arrays
Is there any way to do masked arrays (like numpy) with core.matrix, or another lib? I need to be able to, for example, compute a mean while skipping nan values, which is easily done with masked arrays. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] java.jdbc documentation has moved!
Thanks man!... I rely heavily on this library. On Tue, Jul 9, 2013 at 8:39 PM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/7/9 Sean Corfield seancorfi...@gmail.com This opens up contributions to the community at large so I hope to see plenty of activity as folks send PRs for their favorite hints, tips, and tricks with this library. Where to send pull requests: http://github.com/clojuredocs/guides I'm personally very happy that clojure.java.jdbc is now open for doc contributions from people without paper Clojure CA on file. SQL databases are not going away any time soon and having an easy to use, well documented Clojure library for them should be of top importance to the community (if you ask me). -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Varspotting: spotting Clojure Vars for fun and profit!
Neat! Maybe also add it to the listing at https://github.com/technomancy/leiningen/wiki/Plugins. -- John On Tuesday, July 9, 2013 3:11:16 AM UTC-4, Michał Marczyk wrote: ...and here comes 0.0.2 with non-buggy Var counts: Varspotting report for built-in namespaces: === | Spotter | Var count | |--+---| | Public | 844 | | Unbound | 6 | | Dynamic |39 | | Proper functions | 670 | | Macros |99 | | Non-fn IFns |17 | | Dynamic proper functions | 6 | Cheers, Michał On 9 July 2013 07:38, Michał Marczyk michal@gmail.com javascript: wrote: Hi, Inspired by this Stack Overflow question: Roughly how many functions are in the Clojure core libraries? http://stackoverflow.com/questions/17524906/roughly-how-many-functions-are-in-the-clojure-core-libraries I have released Varspotting, a Leiningen plugin and library for summarizing Var counts. Perhaps the default report on Clojure Vars (1.5.1) will best serve to illustrate the purpose: Varspotting report for clojure.core: | Spotter | Var count | |--+---| | Public | 591 | | Unbound | 2 | | Dynamic |11 | | Proper functions | 475 | | Macros |76 | | Non-fn IFns | 6 | | Dynamic proper functions | 1 | Varspotting report for built-in namespaces: === | Spotter | Var count | |--+---| | Public | 831 | | Unbound | 6 | | Dynamic |39 | | Proper functions | 658 | | Macros |98 | | Non-fn IFns |17 | | Dynamic proper functions | 6 | You can have Varspotting print the above in your terminal if you add [varspotting 0.0.1] to :plugins in your ~/.lein/profiles.clj and say lein varspotting (inside or outside of a project)! Add a list of namespace names as arguments to lein varspotting to obtain a report on those namespaces. The source is available at https://github.com/michalmarczyk/varspotting Custom reports can be generated as well. To this end, varspotting.core includes what I hope is a fairly extensive collection of docstrings; the README points out the key Vars. Cheers, Michał -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Doc about auto-namespaced keywords (e.g. ::user)?
On Tuesday, July 9, 2013 4:57:19 PM UTC-4, Bastien Guerry wrote: Hi all, while reading the documentation for friend, I stumbled upon auto-namespaced keywords -- how can I find more doc about them? Hi Bastian, They're mentioned in http://clojure.org/reader, though that doesn't say anything about why or in what cases you'd use them. -- John -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
lein injections across namespace changes
I have a profiles.clj that looks like this:
{:user
{:dependencies [[org.clojure/tools.nrepl 0.2.3]]
:injections [(use 'clojure.repl)
(use 'clojure.pprint)
(use 'clojure.java.javadoc)]}}
And the repl behaves like this:
; nREPL 0.1.8-preview
user *(doc list)*
-
clojure.core/list
([ items])
Creates a new list containing the items.
nil
user *(ns foo)*
nil
foo *(doc list)*
CompilerException java.lang.RuntimeException: Unable to resolve symbol: doc
in this context, compiling:(NO_SOURCE_PATH:1:1)
Which is very frustrating. Is there a way to keep those namespaces refer-ed
even after I change namespace in the repl? My google-fu has failed me.
I'm using Clojure 1.5.1, emacs 24, lein 2.2, and nrepl.el 0.1.8-preview.
- Russell
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: lein injections across namespace changes
I agree, this has also bothered me for a while. It would be really nice if
the injections would repeat whenever you change namespace.
On Tue, Jul 9, 2013 at 10:41 PM, Russell Mull russell.m...@gmail.comwrote:
I have a profiles.clj that looks like this:
{:user
{:dependencies [[org.clojure/tools.nrepl 0.2.3]]
:injections [(use 'clojure.repl)
(use 'clojure.pprint)
(use 'clojure.java.javadoc)]}}
And the repl behaves like this:
; nREPL 0.1.8-preview
user *(doc list)*
-
clojure.core/list
([ items])
Creates a new list containing the items.
nil
user *(ns foo)*
nil
foo *(doc list)*
CompilerException java.lang.RuntimeException: Unable to resolve symbol:
doc in this context, compiling:(NO_SOURCE_PATH:1:1)
Which is very frustrating. Is there a way to keep those namespaces
refer-ed even after I change namespace in the repl? My google-fu has failed
me.
I'm using Clojure 1.5.1, emacs 24, lein 2.2, and nrepl.el 0.1.8-preview.
- Russell
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN Cassaforte 1.0 final is released
Congratulation on the release! I am glad we found ways to cooperate through libraries, and all the discussions sparked good ideas, so in the end it was well worth it. On Tuesday, July 9, 2013 7:05:59 PM UTC+2, Michael Klishin wrote: Cassaforte [1] is a small, feature complete Clojure client for Apache Cassandra build around CQL 3. Cassaforte is finally 1.0. Since the last RC, there was one AOT compilation issue resolved, making the most recent version 1.0.1. To learn more about Cassaforte, see our 1.0 release notes: http://blog.clojurewerkz.org/blog/2013/07/09/cassaforte-1-dot-0-1-is-released/ The ClojureWerkz team would like to thank Max Penet for helping us shape up what Cassaforte is, making an excellent CQL DSL library available and supporting us in general, even though we were making a competitor to his own Cassandra client ;) Give Cassaforte a try. It makes working with Cassandra from Clojure a breeze. 1. http://clojurecassandra.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Varspotting: spotting Clojure Vars for fun and profit!
On 10 July 2013 06:53, John Gabriele jmg3...@gmail.com wrote: Maybe also add it to the listing at https://github.com/technomancy/leiningen/wiki/Plugins. Good point, thanks! Added now. Cheers, Michał -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
