clojure 1.5 cheatsheet?
Hi, is there a clojure 1.5 cheatsheet somewhere, the last I could find was 1.4. Thanks, -- László Török -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure 1.5 cheatsheet?
http://jafingerhut.github.io kl. 11:38:41 UTC+2 mandag 24. juni 2013 skrev Las følgende: Hi, is there a clojure 1.5 cheatsheet somewhere, the last I could find was 1.4. Thanks, -- László Török -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: core.match 0.2.0-rc1
core.match 0.2.0-rc1 going out the door. ClojureScript support now up to date with Clojure. I've also changed the ClojureScript version to optimize for performance over code size as the code size issues are less problematic for ClojureScript than they are for the JVM. http://github.com/clojure/core.match/blob/master/CHANGES.md Please give it a try! David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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: Best practice for looping
Thanks a lot for tracing through my code! So, as I understand it, my loop/recur is correct, but I was not using map in a correct way within the vector functions. By the way, what is your (pst e*) line doing? Is that from a debugging library? I don't appear to have that in my clojure environment. Patrick On Friday, June 21, 2013 4:06:28 PM UTC-4, P Martin wrote: Hi, I am new to clojure and I am trying to reimplement some optimization code that uses gradient descent. I have attached the source to this post. My experience with gradient descent is in Matlab, which is procedural. When I run my function gradient-descent I supply step sizes and error values of 0.01, it runs correctly and gives me good results. However, if I decrease the error value below 0.001 it produces a stack overflow error. I get the same error if my step value goes down to 0.001. Is my looping mechanism correct and I am just having numerical limitations? Am I abusing loop/recur? Any suggestions/critiques would be great! Thanks, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: core.match 0.2.0-rc1
I've written up how core.match works here http://github.com/clojure/core.match/wiki/Understanding-the-algorithm Hopefully this is a bit more approachable than the Maranget paper :) On Mon, Jun 24, 2013 at 7:43 AM, David Nolen dnolen.li...@gmail.com wrote: core.match 0.2.0-rc1 going out the door. ClojureScript support now up to date with Clojure. I've also changed the ClojureScript version to optimize for performance over code size as the code size issues are less problematic for ClojureScript than they are for the JVM. http://github.com/clojure/core.match/blob/master/CHANGES.md Please give it a try! David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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: Best practice for looping
pst is printstacktrace, it's in the clojure.repl namespace and comes with clojure. Sometimes lein or something makes it available automatically, but if it isn't, you can (use 'clojure.repl) to get to it. http://clojure.github.io/clojure/clojure.repl-api.html#clojure.repl/pst Yes, switching to mapv (map into a vector) instead of map (lazy-seqs) prevents laziness from building up while keeping the same semantics. On Mon, Jun 24, 2013 at 9:03 AM, P Martin prof.pmarti...@gmail.com wrote: Thanks a lot for tracing through my code! So, as I understand it, my loop/recur is correct, but I was not using map in a correct way within the vector functions. By the way, what is your (pst e*) line doing? Is that from a debugging library? I don't appear to have that in my clojure environment. Patrick On Friday, June 21, 2013 4:06:28 PM UTC-4, P Martin wrote: Hi, I am new to clojure and I am trying to reimplement some optimization code that uses gradient descent. I have attached the source to this post. My experience with gradient descent is in Matlab, which is procedural. When I run my function gradient-descent I supply step sizes and error values of 0.01, it runs correctly and gives me good results. However, if I decrease the error value below 0.001 it produces a stack overflow error. I get the same error if my step value goes down to 0.001. Is my looping mechanism correct and I am just having numerical limitations? Am I abusing loop/recur? Any suggestions/critiques would be great! Thanks, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure 1.6 API: clojure.lang.IFn and clojure.api.API
Hi Stuart, ok, so my question is actually more about how to create some clojure Runtime, filling it with additional namespaces, i.e. more than just clojure.core. I just discovered the RT class which could be what I want ( though its not official API ?) I need to make clojure runtime avail. for an IDE plugin, thats the background here. What do you think of Using RT like that ? I mean instantiating a clojure environment by RT.doInit maybe I really dont need to have a REPL for this, as I just want to query for functions and vars via API Best, Joerg -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: core.match 0.2.0-rc1
Hey David,
I wanted to try core.match for a while and fiddled around a bit to see what
kind of code is generated by match, in doing so I found a potentially
dangerous bug.
See: https://gist.github.com/thheller/5850693#file-match-clj-L67
If a match has no :else clause an IllegalArgumentException is thrown and
(do-something) is called AGAIN instead of using the top-level let result.
This might cause problems in some apps. Also why not throw (ex-info
bad-match in line xyz of file.clj {:result value}).
I always wanted to try erlang style case-expressions in clojure and apart
from this bug core.match just might finally make me do some serious testing.
Cheers,
/thomas
On Monday, June 24, 2013 4:15:56 PM UTC+2, David Nolen wrote:
I've written up how core.match works here
http://github.com/clojure/core.match/wiki/Understanding-the-algorithm
Hopefully this is a bit more approachable than the Maranget paper :)
On Mon, Jun 24, 2013 at 7:43 AM, David Nolen dnolen...@gmail.comjavascript:
wrote:
core.match 0.2.0-rc1 going out the door. ClojureScript support now up to
date with Clojure. I've also changed the ClojureScript version to optimize
for performance over code size as the code size issues are less problematic
for ClojureScript than they are for the JVM.
http://github.com/clojure/core.match/blob/master/CHANGES.md
Please give it a try!
David
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To 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 : a WebSocket sub-protocol for HTTP Kit
Martin, Thanks for the kind feedback. I've written a tutorial (first draft) that covers some of the basics, and created a leiningen template for quick-starting a new HTTP-Kit/clj-wamp project: http://cljwamp.us/tutorial https://github.com/cgmartin/clj-wamp-template Cheers, ~Christopher Martin On Wednesday, June 19, 2013 1:44:15 AM UTC-4, martin_clausen wrote: Excellent job Christopher. The examples look great and so does the rest of the documentation. A tutorial or walk-through of one of the examples would be great. Cheers Martin On Tuesday, June 18, 2013 5:29:52 PM UTC+2, Christopher Martin wrote: Hi all, I've been working on a WebSocket project recently while learning Clojure, and thought I'd share my port of the WAMP spec (for use with HTTP Kit). WAMP is an open WebSocket subprotocol that provides two asynchronous messaging patterns: RPC http://wamp.ws/faq#rpc and PubSubhttp://wamp.ws/faq#pubsub . See the project README.md for installation usage instructions: https://github.com/cgmartin/clj-wamp An example site, with live chat and RPC demos, API docs: http://cljwamp.us Example site source: https://github.com/cgmartin/clj-wamp-example The code has stabilized enough to release as beta, but I'll warn you that it's still under development. Next up is to try integrating with Aleph, and port the JavaScript WAMP client to ClojureScript. Cheers, ~Christopher Martin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
putting 2-element colls into a map: works with vectors, but not with lists?
Why does `into` fail when the 2-element collections are lists and not
vectors? :
~~~
user= (into {} [[:a 1] [:b 2]])
{:a 1, :b 2}
user= (into {} ['(:a 1) '(:b 2)])
ClassCastException clojure.lang.Keyword cannot be cast to
java.util.Map$Entry clojure.lang.ATransientMap.conj (ATransientMap.java:44)
~~~
or even:
~~~
user= (conj {} [:a 1])
{:a 1}
user= (conj {} '(:a 1))
ClassCastException clojure.lang.Keyword cannot be cast to
java.util.Map$Entry clojure.lang.APersistentMap.cons
(APersistentMap.java:42)
~~~
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Best practice for looping
Great! Thanks so much for your help! On Monday, June 24, 2013 10:50:57 AM UTC-4, Gary Trakhman wrote: pst is printstacktrace, it's in the clojure.repl namespace and comes with clojure. Sometimes lein or something makes it available automatically, but if it isn't, you can (use 'clojure.repl) to get to it. http://clojure.github.io/clojure/clojure.repl-api.html#clojure.repl/pst Yes, switching to mapv (map into a vector) instead of map (lazy-seqs) prevents laziness from building up while keeping the same semantics. On Mon, Jun 24, 2013 at 9:03 AM, P Martin prof.pm...@gmail.comjavascript: wrote: Thanks a lot for tracing through my code! So, as I understand it, my loop/recur is correct, but I was not using map in a correct way within the vector functions. By the way, what is your (pst e*) line doing? Is that from a debugging library? I don't appear to have that in my clojure environment. Patrick On Friday, June 21, 2013 4:06:28 PM UTC-4, P Martin wrote: Hi, I am new to clojure and I am trying to reimplement some optimization code that uses gradient descent. I have attached the source to this post. My experience with gradient descent is in Matlab, which is procedural. When I run my function gradient-descent I supply step sizes and error values of 0.01, it runs correctly and gives me good results. However, if I decrease the error value below 0.001 it produces a stack overflow error. I get the same error if my step value goes down to 0.001. Is my looping mechanism correct and I am just having numerical limitations? Am I abusing loop/recur? Any suggestions/critiques would be great! Thanks, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ClojureScript] Re: ANN: core.match 0.2.0-rc1
Thanks for the report, fixed and 0.2.0-rc2 is going out.
Probably going to hold off on ex-info change, the behavior of match is the
same as `case` with respect to the no match exception.
David
On Mon, Jun 24, 2013 at 11:10 AM, Thomas Heller th.hel...@gmail.com wrote:
Hey David,
I wanted to try core.match for a while and fiddled around a bit to see
what kind of code is generated by match, in doing so I found a potentially
dangerous bug.
See: https://gist.github.com/thheller/5850693#file-match-clj-L67
If a match has no :else clause an IllegalArgumentException is thrown and
(do-something) is called AGAIN instead of using the top-level let result.
This might cause problems in some apps. Also why not throw (ex-info
bad-match in line xyz of file.clj {:result value}).
I always wanted to try erlang style case-expressions in clojure and apart
from this bug core.match just might finally make me do some serious testing.
Cheers,
/thomas
On Monday, June 24, 2013 4:15:56 PM UTC+2, David Nolen wrote:
I've written up how core.match works here http://github.com/**
clojure/core.match/wiki/**Understanding-the-algorithmhttp://github.com/clojure/core.match/wiki/Understanding-the-algorithm
Hopefully this is a bit more approachable than the Maranget paper :)
On Mon, Jun 24, 2013 at 7:43 AM, David Nolen dnolen...@gmail.com wrote:
core.match 0.2.0-rc1 going out the door. ClojureScript support now up to
date with Clojure. I've also changed the ClojureScript version to optimize
for performance over code size as the code size issues are less problematic
for ClojureScript than they are for the JVM.
http://github.com/clojure/**core.match/blob/master/**CHANGES.mdhttp://github.com/clojure/core.match/blob/master/CHANGES.md
Please give it a try!
David
--
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescr...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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.
Bitwise Operations in core.logic?
Hi, I've been exploring core.logic while working through The Reasoned Schemer and would like to be able to describe relationships between IP addresses and networks that they may or may not be a part of. It's straightforward to do this in Clojure because I can use bit-and on a network and a mask and on an IP and a mask. If the results are the same, then the IP is in the network. At least, that is how I understand it. Here's a predicate function that does this: (defn in-network? [address network netmask] (= (map bit-and network netmask) (map bit-and address netmask))) ;; 192.168.1.3 is in 192.168.1.0/24 (in-network? [192 168 1 3] [192 168 1 0] [255 255 255 0]) ;; true ;; but 192.168.100.3 isn't (in-network? [192 168 100 3] [192 168 1 0] [255 255 255 0]) ;; false It would be cool to be able to do this with core.logic so I could have a relationship like in-networko that could describe IPs and networks. I'm running into issues implementing this because lvars aren't supported by the bitwise operators from Clojure and I can't seem to find anything in core.logic that does what I need out of the box. The Reasoned Schemer describes a bunch of bitwise operations, but implementing them seems like it will involve a lot of work to turn the integers from an IP into lists of bits and back again. Is there a better way to do this? Any insight would be appreciated. Thanks in advance, Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Bitwise Operations in core.logic?
Yeah there's no good way to do this out of the box. You probably want to define some custom constraints - to perform well you might even need to go so far as to define a new constraint domain. Things are not at the point where I feel comfortably describing how this can be done as the details are likely to change in the near future. On Mon, Jun 24, 2013 at 12:01 PM, David Rocamora dro...@gmail.com wrote: Hi, I've been exploring core.logic while working through The Reasoned Schemer and would like to be able to describe relationships between IP addresses and networks that they may or may not be a part of. It's straightforward to do this in Clojure because I can use bit-and on a network and a mask and on an IP and a mask. If the results are the same, then the IP is in the network. At least, that is how I understand it. Here's a predicate function that does this: (defn in-network? [address network netmask] (= (map bit-and network netmask) (map bit-and address netmask))) ;; 192.168.1.3 is in 192.168.1.0/24 (in-network? [192 168 1 3] [192 168 1 0] [255 255 255 0]) ;; true ;; but 192.168.100.3 isn't (in-network? [192 168 100 3] [192 168 1 0] [255 255 255 0]) ;; false It would be cool to be able to do this with core.logic so I could have a relationship like in-networko that could describe IPs and networks. I'm running into issues implementing this because lvars aren't supported by the bitwise operators from Clojure and I can't seem to find anything in core.logic that does what I need out of the box. The Reasoned Schemer describes a bunch of bitwise operations, but implementing them seems like it will involve a lot of work to turn the integers from an IP into lists of bits and back again. Is there a better way to do this? Any insight would be appreciated. Thanks in advance, Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: putting 2-element colls into a map: works with vectors, but not with lists?
On Mon, Jun 24, 2013 at 8:49 AM, John Gabriele jmg3...@gmail.com wrote:
Why does `into` fail when the 2-element collections are lists and not
vectors? :
Because the implementation special cases vectors :)
It's the one place where a two element vector is treated like a
Map$Entry so that you are not forced to somehow create Map$Entry
instances for the key/value pairs.
There are some other quirks around that special casing - for example:
user= (conj {} {:a 1 :b 2})
{:b 2, :a 1}
user= (conj {} '([:a 1] [:b 2]))
ClassCastException clojure.lang.PersistentVector cannot be cast to
java.util.Map$Entry clojure.lang.APersistentMap.cons
(APersistentMap.java:42)
So conj on a map acts like a map-preserving concat since the second
argument can be a map, not just a new key/value pair to add, yet you
cannot conj a sequence of two-element vectors onto a map.
You can see here that maps contain MapEntry elements, not actual two
element vectors:
user= (first {:a 1})
[:a 1]
user= (type (first {:a 1}))
clojure.lang.MapEntry
user= (type [:a 1])
clojure.lang.PersistentVector
Things can get even stranger if you start doing interop between
Clojure and other languages that have slightly different map
implementations...
--
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 1.5 cheatsheet?
That link is also available near the top of http://clojure.org/cheatsheet(Download other versions with tooltips). There are a few things new in 1.5 on the latest version, but I haven't yet included any of the new reducers functions there yet. If anyone has a better suggestion for categorizing them, other than simply putting them all together into one category together, I am open to suggestions. Andy On Mon, Jun 24, 2013 at 3:18 AM, terjesb terj...@gmail.com wrote: http://jafingerhut.github.io kl. 11:38:41 UTC+2 mandag 24. juni 2013 skrev Las følgende: Hi, is there a clojure 1.5 cheatsheet somewhere, the last I could find was 1.4. Thanks, -- László Török -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure 1.6 API: clojure.lang.IFn and clojure.api.API
On 6/24/13 7:53 AM, Jörg Winter wrote: Hi Stuart, ok, so my question is actually more about how to create some clojure Runtime, filling it with additional namespaces, i.e. more than just clojure.core. I just discovered the RT class which could be what I want ( though its not official API ?) I need to make clojure runtime avail. for an IDE plugin, thats the background here. What do you think of Using RT like that ? I mean instantiating a clojure environment by RT.doInit maybe I really dont need to have a REPL for this, as I just want to query for functions and vars via API Best, Joerg the ticket http://dev.clojure.org/jira/browse/CLJ-1188 for API might be enlightening. it has some discussion and also links to the design wiki page. -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? signature.asc Description: OpenPGP digital signature
Re: Bitwise Operations in core.logic?
Cool. Thanks for the quick feedback (also thanks for core.logic). I'll continue experimenting. -Dave On Monday, June 24, 2013 12:14:14 PM UTC-4, David Nolen wrote: Yeah there's no good way to do this out of the box. You probably want to define some custom constraints - to perform well you might even need to go so far as to define a new constraint domain. Things are not at the point where I feel comfortably describing how this can be done as the details are likely to change in the near future. On Mon, Jun 24, 2013 at 12:01 PM, David Rocamora dro...@gmail.comjavascript: wrote: Hi, I've been exploring core.logic while working through The Reasoned Schemer and would like to be able to describe relationships between IP addresses and networks that they may or may not be a part of. It's straightforward to do this in Clojure because I can use bit-and on a network and a mask and on an IP and a mask. If the results are the same, then the IP is in the network. At least, that is how I understand it. Here's a predicate function that does this: (defn in-network? [address network netmask] (= (map bit-and network netmask) (map bit-and address netmask))) ;; 192.168.1.3 is in 192.168.1.0/24 (in-network? [192 168 1 3] [192 168 1 0] [255 255 255 0]) ;; true ;; but 192.168.100.3 isn't (in-network? [192 168 100 3] [192 168 1 0] [255 255 255 0]) ;; false It would be cool to be able to do this with core.logic so I could have a relationship like in-networko that could describe IPs and networks. I'm running into issues implementing this because lvars aren't supported by the bitwise operators from Clojure and I can't seem to find anything in core.logic that does what I need out of the box. The Reasoned Schemer describes a bunch of bitwise operations, but implementing them seems like it will involve a lot of work to turn the integers from an IP into lists of bits and back again. Is there a better way to do this? Any insight would be appreciated. Thanks in advance, Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: matching, assigning and branching in one form
The condp form is very nice and concise if you have multiple match clauses. If you are more generally just looking to perform a single match/assign/branch task, I'd recommend this little nugget of clojure wisdom: Forget ye not the hidden might of if-let. (if-let [[_ from to message] (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg)] (true-branch) (false-branch)) If you use an expression that returns a sequence with if-let, just wrap it in a call to seq, like so: (if-let [[a b c d] (seq (filter anything-good? some-coll))] (true-branch) (false-branch)) Happy hacking, ~Gary On Friday, June 21, 2013 11:43:50 AM UTC-4, Steven Arnold wrote: Hi, I am writing a simple IRC bot, pretty much just for fun, starting with a simple implementation originally posted by Nurullah Akkaya on his blog. It already does what it's supposed to, which is message a fortune from mod-fortune (shelling out) when someone asks it to. However, there's a bit of code I don't like. It looks like this: (cond (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg) (let [[_ from to message] (re-find #^:(.*?)!.*PRIVMSG (.*) :(.*) msg)] [...logic omitted...] What's happening is we're looking for a PRIVMSG, and if we find one, we scan the message again and pull out the chunks we're interested in, and use them in the logic part below. The problem is I don't like maintaining two regular expressions. I wish I could use it only once, and therefore change it only once if it needs to be modified. I'd prefer to see an expression that looks like this (for example): (cond (if-matched #^:(.*?)!.*PRIVMSG (.*) :(.*) msg [from to message] (true form) (optional false form))) The if-matched acts as a let block while pulling out groups and assigning to local variables at the same time. Also, it ignores the first match of re-find, which is the entire expression -- not generally useful to me. Maybe if-matched-groups would ignore the overall expression, and if-matched would include it. I suppose a macro might be the way to go to accomplish this, but I wonder if there are any Clojure tricks that could accomplish this short of a macro. Also, do any fellow Clojurians think a macro like this is a bad idea in general? Would you suggest taking a different tack to solve this problem? Thanks in advance! steven -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure 1.5 cheatsheet?
Thx, i saw that but the page says 1.3 and 1.4 :-) Sent from my phone On Jun 24, 2013 6:17 PM, Andy Fingerhut andy.finger...@gmail.com wrote: That link is also available near the top of http://clojure.org/cheatsheet(Download other versions with tooltips). There are a few things new in 1.5 on the latest version, but I haven't yet included any of the new reducers functions there yet. If anyone has a better suggestion for categorizing them, other than simply putting them all together into one category together, I am open to suggestions. Andy On Mon, Jun 24, 2013 at 3:18 AM, terjesb terj...@gmail.com wrote: http://jafingerhut.github.io kl. 11:38:41 UTC+2 mandag 24. juni 2013 skrev Las følgende: Hi, is there a clojure 1.5 cheatsheet somewhere, the last I could find was 1.4. Thanks, -- László Török -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ClojureScript] Re: ANN: core.match 0.2.0-rc1
That was quick, thanks.
One Question for vector matches, I was thinking of a 'case-ex macro which
basically copies the semantics of erlangs case-expressions.
eg.
(case-ex (db/find-object some-id)
[:ok object] object
[:error :not-found] default-object)
expands to
(match [(db/find-object some-id)]
[[:ok object]] object
[[:error :not-found]] default-object)
I loved case-ex in Erlang, not convinced its a good way to go in lisp-y
land but I miss them so I'm gonna try. Anyways, right now the result of the
function has to satisfy 'vector?, would it hurt any specs to test for
clojure.lang.Indexed/cljs.core.IIndexed?
I was thinking of combining case-ex with (tuple :ok object) instead of [:ok
object] as return values, but I haven't done any actual benchmarks if
special Tuple2,3,4 (then normal vector) classes would be useful
performance/memory-wise. Well, time will tell. Just an idea I had floating
around.
Cheers,
/thomas
On Monday, June 24, 2013 6:01:37 PM UTC+2, David Nolen wrote:
Thanks for the report, fixed and 0.2.0-rc2 is going out.
Probably going to hold off on ex-info change, the behavior of match is the
same as `case` with respect to the no match exception.
David
On Mon, Jun 24, 2013 at 11:10 AM, Thomas Heller
th.h...@gmail.comjavascript:
wrote:
Hey David,
I wanted to try core.match for a while and fiddled around a bit to see
what kind of code is generated by match, in doing so I found a potentially
dangerous bug.
See: https://gist.github.com/thheller/5850693#file-match-clj-L67
If a match has no :else clause an IllegalArgumentException is thrown and
(do-something) is called AGAIN instead of using the top-level let result.
This might cause problems in some apps. Also why not throw (ex-info
bad-match in line xyz of file.clj {:result value}).
I always wanted to try erlang style case-expressions in clojure and apart
from this bug core.match just might finally make me do some serious testing.
Cheers,
/thomas
On Monday, June 24, 2013 4:15:56 PM UTC+2, David Nolen wrote:
I've written up how core.match works here http://github.com/**
clojure/core.match/wiki/**Understanding-the-algorithmhttp://github.com/clojure/core.match/wiki/Understanding-the-algorithm
Hopefully this is a bit more approachable than the Maranget paper :)
On Mon, Jun 24, 2013 at 7:43 AM, David Nolen dnolen...@gmail.comwrote:
core.match 0.2.0-rc1 going out the door. ClojureScript support now up
to date with Clojure. I've also changed the ClojureScript version to
optimize for performance over code size as the code size issues are less
problematic for ClojureScript than they are for the JVM.
http://github.com/clojure/**core.match/blob/master/**CHANGES.mdhttp://github.com/clojure/core.match/blob/master/CHANGES.md
Please give it a try!
David
--
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojurescrip...@googlegroups.com javascript:.
To post to this group, send email to clojur...@googlegroups.comjavascript:
.
Visit this group at http://groups.google.com/group/clojurescript.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure 1.6 API: clojure.lang.IFn and clojure.api.API
Thanks Kevin, it's all clear now. Sent from my phone On Jun 24, 2013 6:38 PM, Kevin Downey redc...@gmail.com wrote: On 6/24/13 7:53 AM, Jörg Winter wrote: Hi Stuart, ok, so my question is actually more about how to create some clojure Runtime, filling it with additional namespaces, i.e. more than just clojure.core. I just discovered the RT class which could be what I want ( though its not official API ?) I need to make clojure runtime avail. for an IDE plugin, thats the background here. What do you think of Using RT like that ? I mean instantiating a clojure environment by RT.doInit maybe I really dont need to have a REPL for this, as I just want to query for functions and vars via API Best, Joerg the ticket http://dev.clojure.org/jira/browse/CLJ-1188 for API might be enlightening. it has some discussion and also links to the design wiki page. -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: cljson, for faster browser deserialization
Hi all, I'm pleased to announce the release of cljson 1.0.0, a Clojure and ClojureScript data serialization library designed for maximal Clojure data deserialization speed in the browser: https://github.com/tailrecursion/cljson. cljson was designed to take advantage of the native JSON parsing facilities most browsers provide. cljson provides clj-cljson and cljson-clj functions on both platforms. cljson-clj on ClojureScript is roughly 5-6x faster than cljs.reader/read-string, and cljson data is roughly 10% fatter on the wire than EDN. Thanks in advance for your feedback and contributions! Alan -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: cljson, for faster browser deserialization
Hey,
this looks pretty sweet! I stuck with EDN for now but its way too slow, so
I'm gonna give this a shot.
One thing: I'm don't think its the best idea to fall back to
*default-data-readers*, would you be open to adding a second argument to
'cljson-clj which takes a map specifying readers? eg. (cljson-clj
{:readers {my.ns/test my-reader-fn}} json-string), basically the same API
as clojure.edn/read?
Thanks,
/thomas
On Monday, June 24, 2013 7:23:26 PM UTC+2, Alan Dipert wrote:
Hi all,
I'm pleased to announce the release of cljson 1.0.0, a Clojure and
ClojureScript data serialization library designed for maximal Clojure data
deserialization speed in the browser:
https://github.com/tailrecursion/cljson. cljson was designed to take
advantage of the native JSON parsing facilities most browsers provide.
cljson provides clj-cljson and cljson-clj functions on both platforms.
cljson-clj on ClojureScript is roughly 5-6x faster than
cljs.reader/read-string, and cljson data is roughly 10% fatter on the wire
than EDN.
Thanks in advance for your feedback and contributions!
Alan
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: putting 2-element colls into a map: works with vectors, but not with lists?
On Monday, June 24, 2013 12:14:56 PM UTC-4, Sean Corfield wrote:
On Mon, Jun 24, 2013 at 8:49 AM, John Gabriele
jmg...@gmail.comjavascript:
wrote:
Why does `into` fail when the 2-element collections are lists and not
vectors? :
Because the implementation special cases vectors :)
It's the one place where a two element vector is treated like a
Map$Entry so that you are not forced to somehow create Map$Entry
instances for the key/value pairs.
There are some other quirks around that special casing - for example:
{snip}
Thanks, Sean!
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: putting 2-element colls into a map: works with vectors, but not with lists?
On Jun 24, 2013, at 11:14 , Sean Corfield seancorfi...@gmail.com wrote: On Mon, Jun 24, 2013 at 8:49 AM, John Gabriele jmg3...@gmail.com wrote: Why does `into` fail when the 2-element collections are lists and not vectors? : Because the implementation special cases vectors :) It's the one place where a two element vector is treated like a Map$Entry so that you are not forced to somehow create Map$Entry instances for the key/value pairs. Huh. I had assumed this would work with any 2-element collection, like destructuring. Why not? Performance reasons? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: cljson, for faster browser deserialization
Glad you enjoy! And yes, totally into the cljson-clj [map data] arity.
Alan
On Monday, June 24, 2013 1:50:00 PM UTC-4, Thomas Heller wrote:
Hey,
this looks pretty sweet! I stuck with EDN for now but its way too slow, so
I'm gonna give this a shot.
One thing: I'm don't think its the best idea to fall back to
*default-data-readers*, would you be open to adding a second argument to
'cljson-clj which takes a map specifying readers? eg. (cljson-clj
{:readers {my.ns/test my-reader-fn}} json-string), basically the same API
as clojure.edn/read?
Thanks,
/thomas
On Monday, June 24, 2013 7:23:26 PM UTC+2, Alan Dipert wrote:
Hi all,
I'm pleased to announce the release of cljson 1.0.0, a Clojure and
ClojureScript data serialization library designed for maximal Clojure data
deserialization speed in the browser:
https://github.com/tailrecursion/cljson. cljson was designed to take
advantage of the native JSON parsing facilities most browsers provide.
cljson provides clj-cljson and cljson-clj functions on both platforms.
cljson-clj on ClojureScript is roughly 5-6x faster than
cljs.reader/read-string, and cljson data is roughly 10% fatter on the wire
than EDN.
Thanks in advance for your feedback and contributions!
Alan
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Lazy seq race condition?
What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq race condition?
Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] lein-gnome 0.1.0
Useful tools for writing gnome extensions in cljs: -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] lein-gnome 0.1.0
(I fell afoul of the new gmail compose window) Useful tools for writing gnome extensions in cljs: https://github.com/jamii/lein-gnome As a side effect, allows injecting a cljs repl into gnome-shell. On 24 June 2013 23:02, Jamie Brandon ja...@scattered-thoughts.net wrote: Useful tools for writing gnome extensions in cljs: -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq race condition?
Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? (And given they can share tails, how would same one even be defined anyway?) On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto brobro...@gmail.com wrote: Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Unnecessary boxing with 1.5?
(defn foo [x y z] (let [x (long x) y (long y) z (long z)]) (loop [a false b (long 0)] (if a b (recur true (+ x (+ y z)) NO_SOURCE_PATH:1 recur arg for primitive local: b is not matching primitive, had: Object, needed: long Auto-boxing loop arg: b What the fuh? Binary + with primitive args is supposed to produce primitive output. The auto-promoting +' and ternary-plus + are the ones that are supposed to produce Object. What gives? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
1.5: Can't type hint a local with a primitive initializer error message gives wrong line number.
I got a Can't type hint a local with a primitive initializer triggered by the following fragment of a let binding vector: ^BigDecimal d0x (- x (:x rp)) ^BigDecimal d0y (- y (:y rp)) d0x2 (- (* d0x d0x) (* d0y d0y)) d0y2 (* 2M (* d0x d0y)) d0x3 (- (* d0x d0x2) (* d0y d0y2)) d0y3 (+ (* d0x d0y2) (* d0y d0x2)) ^BigDecimal dx (+ (- (* ax d0x) (* ay d0y)) (- (* bx d0x2) (* by d0y2)) (- (* cx d0x3) (* cy d0y3))) The error message incorrectly pointed to the start of the enclosing let form as the error location, but it was actually the line starting ^BigDecimal dx ... that it objected to, as evidenced by the removal of that particular type hint making the message go away. (The cause of the error was double contamination from ax, ay, bx, by, cx, and cy. A few (bigdec ...) wrappings earlier in the code made it go away.) By way of contrast, a reflection warning generated by a (with-precision m-log line was much more helpful -- the column number pointed at the start of the symbol m-log, and type-hinting m-log's prior declaration with ^Integer made that reflection warning go away. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq race condition?
Reading the LazySeq.java file should make this all clear, but yes, no race conditions. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 Synchronized methods basically lock the current instance of the object while the method runs, so it is impossible for two threads to execute the lazy seq fn at the same time. Timothy On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey cgree...@gmail.com wrote: Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? (And given they can share tails, how would same one even be defined anyway?) On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto brobro...@gmail.comwrote: Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lazy seq race condition?
I'm familiar with what synchronized Type foo (args) does -- my last question was more about what aspect of a lazy seq the object with the method corresponds to. Cons cell or similar subunit? I could read half of clojure.lang, learn how all the various types of seq (Cons, LazySeq, ChunkedSeq, etc...) work under the hood, and thereby eventually figure it out, but it's probably a lot fewer man-hours of work for me to ask someone who's already intimately familiar with that codebase and for him to answer... On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge tbaldri...@gmail.comwrote: Reading the LazySeq.java file should make this all clear, but yes, no race conditions. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 Synchronized methods basically lock the current instance of the object while the method runs, so it is impossible for two threads to execute the lazy seq fn at the same time. Timothy On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey cgree...@gmail.comwrote: Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? (And given they can share tails, how would same one even be defined anyway?) On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto brobro...@gmail.comwrote: Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this
Re: Lazy seq race condition?
It corresponds to the execution of the LazySeq fn. That fn will be called once and only once, the rest of the data in the object is immutable and side-effect free and therefore does not need to be synchronized. Timothy On Mon, Jun 24, 2013 at 8:51 PM, Cedric Greevey cgree...@gmail.com wrote: I'm familiar with what synchronized Type foo (args) does -- my last question was more about what aspect of a lazy seq the object with the method corresponds to. Cons cell or similar subunit? I could read half of clojure.lang, learn how all the various types of seq (Cons, LazySeq, ChunkedSeq, etc...) work under the hood, and thereby eventually figure it out, but it's probably a lot fewer man-hours of work for me to ask someone who's already intimately familiar with that codebase and for him to answer... On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge tbaldri...@gmail.comwrote: Reading the LazySeq.java file should make this all clear, but yes, no race conditions. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 Synchronized methods basically lock the current instance of the object while the method runs, so it is impossible for two threads to execute the lazy seq fn at the same time. Timothy On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey cgree...@gmail.comwrote: Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? (And given they can share tails, how would same one even be defined anyway?) On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto brobro...@gmail.comwrote: Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit
Re: Lazy seq race condition?
So, is the granularity that of seq realization -- individual [first rest] cells for (iterate inc 0), single chunks for (range), etc.? I'd appreciate a straight, direct, yes-or-no answer to that question. On Mon, Jun 24, 2013 at 11:03 PM, Timothy Baldridge tbaldri...@gmail.comwrote: It corresponds to the execution of the LazySeq fn. That fn will be called once and only once, the rest of the data in the object is immutable and side-effect free and therefore does not need to be synchronized. Timothy On Mon, Jun 24, 2013 at 8:51 PM, Cedric Greevey cgree...@gmail.comwrote: I'm familiar with what synchronized Type foo (args) does -- my last question was more about what aspect of a lazy seq the object with the method corresponds to. Cons cell or similar subunit? I could read half of clojure.lang, learn how all the various types of seq (Cons, LazySeq, ChunkedSeq, etc...) work under the hood, and thereby eventually figure it out, but it's probably a lot fewer man-hours of work for me to ask someone who's already intimately familiar with that codebase and for him to answer... On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge tbaldri...@gmail.com wrote: Reading the LazySeq.java file should make this all clear, but yes, no race conditions. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 Synchronized methods basically lock the current instance of the object while the method runs, so it is impossible for two threads to execute the lazy seq fn at the same time. Timothy On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey cgree...@gmail.comwrote: Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? (And given they can share tails, how would same one even be defined anyway?) On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto brobro...@gmail.comwrote: Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at
Re: [ANN] clj-wamp : a WebSocket sub-protocol for HTTP Kit
Good call. I agree the prefix shortening should be more noticeable since it's found throughout the examples. I've given it its own section now: http://cljwamp.us/tutorial#wampprefix Again, much thanks for the feedback! On Monday, June 24, 2013 1:51:25 PM UTC-4, martin_clausen wrote: That is a great tutorial Christopher. Really easy to follow. You might want link the use of CURI (should be CURIE right?) in your code example to the explanation of prefix shortening, as it is not readily apparent that these are linked(at least not to me). Martin On Mon, Jun 24, 2013 at 5:15 PM, Christopher Martin cgma...@gmail.comjavascript: wrote: Martin, Thanks for the kind feedback. I've written a tutorial (first draft) that covers some of the basics, and created a leiningen template for quick-starting a new HTTP-Kit/clj-wamp project: http://cljwamp.us/tutorial https://github.com/cgmartin/clj-wamp-template Cheers, ~Christopher Martin On Wednesday, June 19, 2013 1:44:15 AM UTC-4, martin_clausen wrote: Excellent job Christopher. The examples look great and so does the rest of the documentation. A tutorial or walk-through of one of the examples would be great. Cheers Martin On Tuesday, June 18, 2013 5:29:52 PM UTC+2, Christopher Martin wrote: Hi all, I've been working on a WebSocket project recently while learning Clojure, and thought I'd share my port of the WAMP spec (for use with HTTP Kit). WAMP is an open WebSocket subprotocol that provides two asynchronous messaging patterns: RPC and PubSub. See the project README.md for installation usage instructions: https://github.com/cgmartin/clj-wamp An example site, with live chat and RPC demos, API docs: http://cljwamp.us Example site source: https://github.com/cgmartin/clj-wamp-example The code has stabilized enough to release as beta, but I'll warn you that it's still under development. Next up is to try integrating with Aleph, and port the JavaScript WAMP client to ClojureScript. Cheers, ~Christopher Martin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 : a WebSocket sub-protocol for HTTP Kit
Nice work. How about adding this https://github.com/tavendo/AutobahnPython/tree/master/examples/wamp/authentication WAMP-CRA (WAMP Challenge Response Authentication)? On Tuesday, June 25, 2013 6:52:40 AM UTC+3, Christopher Martin wrote: Good call. I agree the prefix shortening should be more noticeable since it's found throughout the examples. I've given it its own section now: http://cljwamp.us/tutorial#wampprefix Again, much thanks for the feedback! On Monday, June 24, 2013 1:51:25 PM UTC-4, martin_clausen wrote: That is a great tutorial Christopher. Really easy to follow. You might want link the use of CURI (should be CURIE right?) in your code example to the explanation of prefix shortening, as it is not readily apparent that these are linked(at least not to me). Martin On Mon, Jun 24, 2013 at 5:15 PM, Christopher Martin cgma...@gmail.com wrote: Martin, Thanks for the kind feedback. I've written a tutorial (first draft) that covers some of the basics, and created a leiningen template for quick-starting a new HTTP-Kit/clj-wamp project: http://cljwamp.us/tutorial https://github.com/cgmartin/clj-wamp-template Cheers, ~Christopher Martin On Wednesday, June 19, 2013 1:44:15 AM UTC-4, martin_clausen wrote: Excellent job Christopher. The examples look great and so does the rest of the documentation. A tutorial or walk-through of one of the examples would be great. Cheers Martin On Tuesday, June 18, 2013 5:29:52 PM UTC+2, Christopher Martin wrote: Hi all, I've been working on a WebSocket project recently while learning Clojure, and thought I'd share my port of the WAMP spec (for use with HTTP Kit). WAMP is an open WebSocket subprotocol that provides two asynchronous messaging patterns: RPC and PubSub. See the project README.md for installation usage instructions: https://github.com/cgmartin/clj-wamp An example site, with live chat and RPC demos, API docs: http://cljwamp.us Example site source: https://github.com/cgmartin/clj-wamp-example The code has stabilized enough to release as beta, but I'll warn you that it's still under development. Next up is to try integrating with Aleph, and port the JavaScript WAMP client to ClojureScript. Cheers, ~Christopher Martin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq race condition?
The first 100 lines of LazySeq.java contain all the answers. Read it, and be enlightened. :-) And as a bonus, you'll better understand the language as a whole. Timothy On Mon, Jun 24, 2013 at 9:08 PM, Cedric Greevey cgree...@gmail.com wrote: So, is the granularity that of seq realization -- individual [first rest] cells for (iterate inc 0), single chunks for (range), etc.? I'd appreciate a straight, direct, yes-or-no answer to that question. On Mon, Jun 24, 2013 at 11:03 PM, Timothy Baldridge tbaldri...@gmail.comwrote: It corresponds to the execution of the LazySeq fn. That fn will be called once and only once, the rest of the data in the object is immutable and side-effect free and therefore does not need to be synchronized. Timothy On Mon, Jun 24, 2013 at 8:51 PM, Cedric Greevey cgree...@gmail.comwrote: I'm familiar with what synchronized Type foo (args) does -- my last question was more about what aspect of a lazy seq the object with the method corresponds to. Cons cell or similar subunit? I could read half of clojure.lang, learn how all the various types of seq (Cons, LazySeq, ChunkedSeq, etc...) work under the hood, and thereby eventually figure it out, but it's probably a lot fewer man-hours of work for me to ask someone who's already intimately familiar with that codebase and for him to answer... On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge tbaldri...@gmail.com wrote: Reading the LazySeq.java file should make this all clear, but yes, no race conditions. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 Synchronized methods basically lock the current instance of the object while the method runs, so it is impossible for two threads to execute the lazy seq fn at the same time. Timothy On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey cgree...@gmail.comwrote: Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? (And given they can share tails, how would same one even be defined anyway?) On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto brobro...@gmail.comwrote: Realizing a lazy-seq is done through a synchronized method see: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 No race conditions. Cedric Greevey writes: What, precisely, happens if two threads sharing a reference to a single lazy sequence try to realize the same element at the same time? If the sequence is completely pure and deterministic, so any attempt to realize a particular element will produce a single particular value consistently (unlike, say, (repeatedly rand) or a file-seq where relevant parts of the filesystem are being concurrently modified), is the worst-case scenario that the two threads will redundantly perform the same calculation, with no effect other than a minor hit to performance and, in particular, no effect on the program semantics? -- -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send
Re: [ANN] clj-wamp : a WebSocket sub-protocol for HTTP Kit
Thanks! I saw that too in the Autobahn docs. I'll add that source link to the GitHub issue I'm tracking for that feature @ https://github.com/cgmartin/clj-wamp/issues/3 On Tuesday, June 25, 2013 12:04:21 AM UTC-4, Juha Syrjälä wrote: Nice work. How about adding this https://github.com/tavendo/AutobahnPython/tree/master/examples/wamp/authentication WAMP-CRA (WAMP Challenge Response Authentication)? On Tuesday, June 25, 2013 6:52:40 AM UTC+3, Christopher Martin wrote: Good call. I agree the prefix shortening should be more noticeable since it's found throughout the examples. I've given it its own section now: http://cljwamp.us/tutorial#wampprefix Again, much thanks for the feedback! On Monday, June 24, 2013 1:51:25 PM UTC-4, martin_clausen wrote: That is a great tutorial Christopher. Really easy to follow. You might want link the use of CURI (should be CURIE right?) in your code example to the explanation of prefix shortening, as it is not readily apparent that these are linked(at least not to me). Martin On Mon, Jun 24, 2013 at 5:15 PM, Christopher Martin cgma...@gmail.com wrote: Martin, Thanks for the kind feedback. I've written a tutorial (first draft) that covers some of the basics, and created a leiningen template for quick-starting a new HTTP-Kit/clj-wamp project: http://cljwamp.us/tutorial https://github.com/cgmartin/clj-wamp-template Cheers, ~Christopher Martin On Wednesday, June 19, 2013 1:44:15 AM UTC-4, martin_clausen wrote: Excellent job Christopher. The examples look great and so does the rest of the documentation. A tutorial or walk-through of one of the examples would be great. Cheers Martin On Tuesday, June 18, 2013 5:29:52 PM UTC+2, Christopher Martin wrote: Hi all, I've been working on a WebSocket project recently while learning Clojure, and thought I'd share my port of the WAMP spec (for use with HTTP Kit). WAMP is an open WebSocket subprotocol that provides two asynchronous messaging patterns: RPC and PubSub. See the project README.md for installation usage instructions: https://github.com/cgmartin/clj-wamp An example site, with live chat and RPC demos, API docs: http://cljwamp.us Example site source: https://github.com/cgmartin/clj-wamp-example The code has stabilized enough to release as beta, but I'll warn you that it's still under development. Next up is to try integrating with Aleph, and port the JavaScript WAMP client to ClojureScript. Cheers, ~Christopher Martin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq race condition?
On Tue, Jun 25, 2013 at 12:12 AM, Timothy Baldridge tbaldri...@gmail.comwrote: On Mon, Jun 24, 2013 at 9:08 PM, Cedric Greevey cgree...@gmail.comwrote: So, is the granularity that of seq realization -- individual [first rest] cells for (iterate inc 0), single chunks for (range), etc.? I'd appreciate a straight, direct, yes-or-no answer to that question. The first 100 lines of LazySeq.java contain all the answers. Read it, [NUKE] Fail. Someone else want to give answering my question the ol' college try? I didn't originally think that it would be particularly hard, but the evidence is now suggesting otherwise. :) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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} clj-xmemacched release 0.2.2
An opensource memcached client for clojure wrapping xmemcachedhttp://code.google.com/p/xmemcached/.It released 0.2.2, added 'clj-json-transcoder' that encode/decode values using clojure.data.json. https://github.com/killme2008/clj-xmemcached -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Unnecessary boxing with 1.5?
You have what is likely an undesired right paren at the end of the let line, ending the scope of the let. Andy On Mon, Jun 24, 2013 at 4:32 PM, Cedric Greevey cgree...@gmail.com wrote: (defn foo [x y z] (let [x (long x) y (long y) z (long z)]) (loop [a false b (long 0)] (if a b (recur true (+ x (+ y z)) NO_SOURCE_PATH:1 recur arg for primitive local: b is not matching primitive, had: Object, needed: long Auto-boxing loop arg: b What the fuh? Binary + with primitive args is supposed to produce primitive output. The auto-promoting +' and ternary-plus + are the ones that are supposed to produce Object. What gives? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Unnecessary boxing with 1.5?
Huh. How did that happen? And why didn't my IDE indent the code differently, making the problem obvious? On Tue, Jun 25, 2013 at 12:48 AM, Andy Fingerhut andy.finger...@gmail.comwrote: You have what is likely an undesired right paren at the end of the let line, ending the scope of the let. Andy On Mon, Jun 24, 2013 at 4:32 PM, Cedric Greevey cgree...@gmail.comwrote: (defn foo [x y z] (let [x (long x) y (long y) z (long z)]) (loop [a false b (long 0)] (if a b (recur true (+ x (+ y z)) NO_SOURCE_PATH:1 recur arg for primitive local: b is not matching primitive, had: Object, needed: long Auto-boxing loop arg: b What the fuh? Binary + with primitive args is supposed to produce primitive output. The auto-promoting +' and ternary-plus + are the ones that are supposed to produce Object. What gives? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq race condition?
On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey cgree...@gmail.com wrote: Ah, thanks. The locking granularity is local to the cons cell (or analogue; first/rest pair) being realized, I hope? So one thread actually calculates an element and neither call returns until it's calculated, and then both promptly return the calculated value, but threads realizing other lazy seqs or crawling along earlier parts of the same one don't get blocked? This is correct, as far as I understand it. One will do the work, the other will block (awaiting a lock). The first will return, relinquishing the lock and allow the other to get the computed value too. The granularity could be anything from a single cons cell to the entire seq. In the following instance the evaluation of the thunk will yield the entire vector in one operation, which is synchronized. (The `println` is there to make clear when/how evaluation takes place.) (def lazily-initialized-vector (lazy-seq (mapv println (range 10))) What gets returned by the thunk is entirely dependent on the thunk. LazySeq just relies on being able to call `seq` on it. Presumably for fully lazy sequences it will generate one element at a time, and for chunked sequences it will generate one chunk at a time. (Just for the record, I don't have any particular knowledge of the Clojure internals, but I'm fairly confident in my speculation.) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
