New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Software Developer (natural language processing, deep semantic search) at SEMPRIA http://functionaljobs.com/jobs/8711-software-developer-natural-language-processing-deep-semantic-search-at-sempria Cheers, Sean Murphy FunctionalJobs.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/d/optout.
Re: citing Clojure and EDN?
Jony Hudson jonyepsi...@gmail.com writes: On Thursday, 15 May 2014 14:58:50 UTC+1, Phillip Lord wrote: Again, based on the dubious ID that an DOI makes things citable. A URL is already citable! Well, there's no shortage of broken links out there to suggest that people have trouble keeping content associated with stable URLs. The main value of DOI, IMHO, is they're an explicit commitment to make something persistently available - just what you want for citations. Actually, they don't. I've broken quite a few DOIs in my time. What they offer is the guarantee that a DOI will not be handed out twice. So, you avoid the situation where a domain name is unregistered, someone else buys it, and the links are replaced with porn. Now, there is an explicit commitment from crossref (one of the nine bodies that hands out DOIs) over the way that the DOI resolves and what is resolves to. But the strength of this commitment comes from a social and legal agreement, not a technological one. So, URIs such as http://www.w3.org/TR/html401/ offer the same guarantee of stability. Indeed, the display standard for representing DOIs is that is represented as a URI. So URIs are not intrinsincally unstable. And the W3C URL has the *big* advantage that it does not require a two-step resolution. So, the URI that you see in your browser is the URI that you use. With a DOI, the URI is a passing, ephemeral thing. DOIs are treated as some sort of magic -- figshare use the make data citable tagline largely on the basis of hey, it's got a DOI; I find this over-simplistic. DOIs have their place, but it is not everywhere, and they are not automatically better than a URI. Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] ring-auth middleware for protecting sessions
On 05/18/2014 09:25 AM, James Reeves wrote: I don't want to seem like I'm badgering you. You have a lot of sound ideas. But I don't think we should be trying to work around insecure designs; we should be making it easier for people to design things securely. In terms of /specific/ things wrong that I've yet to mention: the middleware you have won't work for all session stores; only session stores that create a new session if a key is not found. Ideally session stores should reject session IDs that don't exist, rather than construct new ones. - James After reading this thread I would like to make a couple of quick points. I think that ring-auth is a step in the right direction and has the right end goals in mind. To cut past the tension a bit I think that what James is trying to say is let's try to make this less confusing and work within the constraints of the current system. This really isn't a bad idea. In fact, it is usually the way to succeed as an add-on to a library. I understand all of the original points made by Brendan and agree with almost all of them. That being said, I would encourage a little more work here to try and blend just a bit more. I am happy to take this off list and start a more productive discussion on how with a smaller group if there's interest. - Aaron On 18 May 2014 14:06, Brendan Younger brendan.youn...@gmail.com mailto:brendan.youn...@gmail.com wrote: On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote: On 18 May 2014 00:09, Brendan Younger brendan...@gmail.com wrote: For anyone else following along at home, I'll just re-iterate the benefits of using ring-auth versus trying to write your routes /just right/ to avoid the myriad security issues listed at OWASP. - If you initiate a session with a user over HTTP and later on that user logs in over HTTPS but you don't change the session id in the cookie, then everyone at the coffee shop has access to the authenticated session. Ring-auth protects you from this. This is true, but I don't think we should be aiming to protect people from doing the wrong thing, so much as stop them from doing it in the first place. You seem to be aiming this middleware at people concerned about security, but not so concerned as to follow best practice. I'm a little baffled by this use-case. On the contrary, I'm protecting the user from oversights or bugs in the webapp. Saying that there would be no security issues if only everyone wrote perfect software is a tautology. - If you use a CSRF middleware, but at any time leak the session id cookie over HTTP, then your CSRF protection is broken. Ring-auth protects you from this. CSRF protection doesn't matter if your session is compromised. CSRF is a mechanism for sending a HTTP POST with the user's session ID. If you already have the session ID, there's very few reasons why you'd bother with CSRF. - If you ever send your CSRF token over HTTP, then the entire coffee shop can entice the user to Click here now! and send money to their off-shore account. Ring-auth helps you avoid sending the CSRF token in the clear. Hm? How? There doesn't appear to be anything in your code that looks for the CSRF token embedded in the response body. Because the :csrf-token is only present in the :auth-session, you can be sure that if your code has access to the :csrf-token, then it's communicating over HTTPS with the user. I could not use ring-anti-forgery here because there is no provision to place the token in anything except :session. - If you get a request over HTTP which should have gone over HTTPS and respond with an error, but don't immediately delete the session, then everyone at the coffee shop has seen the authenticated session id (assuming you forgot to set Secure). Ring-auth protects you from this. Again, I don't understand the use-case for this. Setting the secure flag on the session cookie is the clearly the better option. I'm having trouble seeing how you'd present this in your project's README. - If a user closes their browser on a public computer but forgets to sign off, the next user can go back to the site, and hopefully the browser has cached the cookie giving them access to the first user's account. Ring-auth will help prevent this as soon as the Cache-Control header is set. A session idle-timeout isn't necessarily a bad
Re: [ANN] ring-auth middleware for protecting sessions
On 05/18/2014 09:25 AM, James Reeves wrote: I don't want to seem like I'm badgering you. You have a lot of sound ideas. But I don't think we should be trying to work around insecure designs; we should be making it easier for people to design things securely. In terms of /specific/ things wrong that I've yet to mention: the middleware you have won't work for all session stores; only session stores that create a new session if a key is not found. Ideally session stores should reject session IDs that don't exist, rather than construct new ones. - James After reading this thread I would like to make a couple of quick points. I think that ring-auth is a step in the right direction and has the right end goals in mind. To cut past the tension a bit I think that what James is trying to say is let's try to make this less confusing and work within the constraints of the current system. This really isn't a bad idea. In fact, it is usually the way to succeed as an add-on to a library. I understand all of the original points made by Brendan and agree with almost all of them. That being said, I would encourage a little more work here to try and blend just a bit more. I am happy to take this off list and start a more productive discussion on how with a smaller group if there's interest. - Aaron On 18 May 2014 14:06, Brendan Younger brendan.youn...@gmail.com mailto:brendan.youn...@gmail.com wrote: On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote: On 18 May 2014 00:09, Brendan Younger brendan...@gmail.com wrote: For anyone else following along at home, I'll just re-iterate the benefits of using ring-auth versus trying to write your routes /just right/ to avoid the myriad security issues listed at OWASP. - If you initiate a session with a user over HTTP and later on that user logs in over HTTPS but you don't change the session id in the cookie, then everyone at the coffee shop has access to the authenticated session. Ring-auth protects you from this. This is true, but I don't think we should be aiming to protect people from doing the wrong thing, so much as stop them from doing it in the first place. You seem to be aiming this middleware at people concerned about security, but not so concerned as to follow best practice. I'm a little baffled by this use-case. On the contrary, I'm protecting the user from oversights or bugs in the webapp. Saying that there would be no security issues if only everyone wrote perfect software is a tautology. - If you use a CSRF middleware, but at any time leak the session id cookie over HTTP, then your CSRF protection is broken. Ring-auth protects you from this. CSRF protection doesn't matter if your session is compromised. CSRF is a mechanism for sending a HTTP POST with the user's session ID. If you already have the session ID, there's very few reasons why you'd bother with CSRF. - If you ever send your CSRF token over HTTP, then the entire coffee shop can entice the user to Click here now! and send money to their off-shore account. Ring-auth helps you avoid sending the CSRF token in the clear. Hm? How? There doesn't appear to be anything in your code that looks for the CSRF token embedded in the response body. Because the :csrf-token is only present in the :auth-session, you can be sure that if your code has access to the :csrf-token, then it's communicating over HTTPS with the user. I could not use ring-anti-forgery here because there is no provision to place the token in anything except :session. - If you get a request over HTTP which should have gone over HTTPS and respond with an error, but don't immediately delete the session, then everyone at the coffee shop has seen the authenticated session id (assuming you forgot to set Secure). Ring-auth protects you from this. Again, I don't understand the use-case for this. Setting the secure flag on the session cookie is the clearly the better option. I'm having trouble seeing how you'd present this in your project's README. - If a user closes their browser on a public computer but forgets to sign off, the next user can go back to the site, and hopefully the browser has cached the cookie giving them access to the first user's account. Ring-auth will help prevent this as soon as the Cache-Control header is set. A session idle-timeout isn't necessarily a bad
Joy of Clojure example not working
Hi guys, I am working through the pre-release second edition of Joy of
Clojure's section on multi-methods (section 9.2.~ : pg. 313), and am
getting different outputs from what they have printed in the book. I could
just skip over it, but I really want to understand this stuff. Could
someone tell me how to get the *(compile-cmd osx) *call at the end of the
code to produce the expected output: */usr/bin/gcc *? I have commented
out redundancy and moved a couple of lines for readability. Thanks in
advance!
J
(ns joy.udp
(:refer-clojure :exclude [get]))
(defn beget [this proto]
(assoc this ::prototype proto))
(defn get [m k]
(when m
(if-let [[_ v] (find m k)]
v
(recur (::prototype m) k
(def put assoc)
;;; compiler
(defmulti compiler :os)
(defmethod compiler ::unix [m] (get m :c-compiler))
(defmethod compiler ::osx [m] (get m :llvm-compiler))
(def clone (partial beget {}))
(def unix {:os ::unix, :c-compiler cc, :home /home, :dev /dev})
(def osx (- (clone unix)
(put :os ::osx)
(put :llvm-compiler clang)
(put :home /Users)))
;;; home
(defmulti home :os)
(defmethod home ::unix [m] (get m :home))
(defmethod home ::bsd [m] /home)
;; the error on the call to (home osx) is contingent upon toggling the
following lines.
;(derive ::osx ::unix)
;(derive ::osx ::bsd)
(prefer-method home ::unix ::bsd)
;(remove-method home ::bsd)
(derive (make-hierarchy) ::osx ::unix)
;;; compile-cmd
(defmulti compile-cmd (juxt :os compiler))
(defmethod compile-cmd [::osx gcc] [m]
(str /usr/bin/ (get m :c-compiler)))
(defmethod compile-cmd :default [m]
(str Unsure where to locate (get m :c-compiler)))
;;
(home osx)
;= java.lang.IllegalArgumentException: No method in multimethod 'home' for
dispatch value: :joy.udp/osx …
;; Should be: ;= /Users
(compile-cmd osx)
;= Unsure where to locate cc
;; Should be: ;= /usr/bin/gcc
(compile-cmd unix)
;= Unsure where to locate cc
;; this is the expected output
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Joy of Clojure example not working
It looks like it expects the keyword :osx, not the symbol osx. Could
that be the issue?
On 19 May 2014 16:39, gamma235 jesseluisd...@gmail.com wrote:
Hi guys, I am working through the pre-release second edition of Joy of
Clojure's section on multi-methods (section 9.2.~ : pg. 313), and am getting
different outputs from what they have printed in the book. I could just skip
over it, but I really want to understand this stuff. Could someone tell me
how to get the (compile-cmd osx) call at the end of the code to produce the
expected output: /usr/bin/gcc ? I have commented out redundancy and moved
a couple of lines for readability. Thanks in advance!
J
(ns joy.udp
(:refer-clojure :exclude [get]))
(defn beget [this proto]
(assoc this ::prototype proto))
(defn get [m k]
(when m
(if-let [[_ v] (find m k)]
v
(recur (::prototype m) k
(def put assoc)
;;; compiler
(defmulti compiler :os)
(defmethod compiler ::unix [m] (get m :c-compiler))
(defmethod compiler ::osx [m] (get m :llvm-compiler))
(def clone (partial beget {}))
(def unix {:os ::unix, :c-compiler cc, :home /home, :dev /dev})
(def osx (- (clone unix)
(put :os ::osx)
(put :llvm-compiler clang)
(put :home /Users)))
;;; home
(defmulti home :os)
(defmethod home ::unix [m] (get m :home))
(defmethod home ::bsd [m] /home)
;; the error on the call to (home osx) is contingent upon toggling the
following lines.
;(derive ::osx ::unix)
;(derive ::osx ::bsd)
(prefer-method home ::unix ::bsd)
;(remove-method home ::bsd)
(derive (make-hierarchy) ::osx ::unix)
;;; compile-cmd
(defmulti compile-cmd (juxt :os compiler))
(defmethod compile-cmd [::osx gcc] [m]
(str /usr/bin/ (get m :c-compiler)))
(defmethod compile-cmd :default [m]
(str Unsure where to locate (get m :c-compiler)))
;;
(home osx)
;= java.lang.IllegalArgumentException: No method in multimethod 'home'
for dispatch value: :joy.udp/osx …
;; Should be: ;= /Users
(compile-cmd osx)
;= Unsure where to locate cc
;; Should be: ;= /usr/bin/gcc
(compile-cmd unix)
;= Unsure where to locate cc
;; this is the expected output
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Robert K. Day
robert@merton.oxon.org
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/d/optout.
Re: Joy of Clojure example not working
It looks like it expects the keyword :osx, not the symbol osx. Could
that be the issue?
Thanks for the suggestion, but when I try that instead, I get this error:
java.lang.IllegalArgumentException: No method in multimethod 'compiler' for
dispatch value: null
I kind of feel it might be a typo in the compile-cmd function, cause
instead of a sybol it is listing a vector with a name-spaced symbol and a
string: * [::osx gcc]*. I think this form might have to do something with
juxt in *(defmulti compile-cmd (juxt :os compiler)) *.
But I admit that I don't really understand what is going on here, as the
book doesn't go all that far in explaining juxt, using keys as functions
and how it relates to the defmethod syntax taking a vector in the beginning.
J
On Monday, May 19, 2014 10:44:12 PM UTC+9, Rob Day wrote:
It looks like it expects the keyword :osx, not the symbol osx. Could
that be the issue?
On 19 May 2014 16:39, gamma235 jessel...@gmail.com javascript: wrote:
Hi guys, I am working through the pre-release second edition of Joy of
Clojure's section on multi-methods (section 9.2.~ : pg. 313), and am
getting
different outputs from what they have printed in the book. I could just
skip
over it, but I really want to understand this stuff. Could someone tell
me
how to get the (compile-cmd osx) call at the end of the code to produce
the
expected output: /usr/bin/gcc ? I have commented out redundancy and
moved
a couple of lines for readability. Thanks in advance!
J
(ns joy.udp
(:refer-clojure :exclude [get]))
(defn beget [this proto]
(assoc this ::prototype proto))
(defn get [m k]
(when m
(if-let [[_ v] (find m k)]
v
(recur (::prototype m) k
(def put assoc)
;;; compiler
(defmulti compiler :os)
(defmethod compiler ::unix [m] (get m :c-compiler))
(defmethod compiler ::osx [m] (get m :llvm-compiler))
(def clone (partial beget {}))
(def unix {:os ::unix, :c-compiler cc, :home /home, :dev /dev})
(def osx (- (clone unix)
(put :os ::osx)
(put :llvm-compiler clang)
(put :home /Users)))
;;; home
(defmulti home :os)
(defmethod home ::unix [m] (get m :home))
(defmethod home ::bsd [m] /home)
;; the error on the call to (home osx) is contingent upon toggling the
following lines.
;(derive ::osx ::unix)
;(derive ::osx ::bsd)
(prefer-method home ::unix ::bsd)
;(remove-method home ::bsd)
(derive (make-hierarchy) ::osx ::unix)
;;; compile-cmd
(defmulti compile-cmd (juxt :os compiler))
(defmethod compile-cmd [::osx gcc] [m]
(str /usr/bin/ (get m :c-compiler)))
(defmethod compile-cmd :default [m]
(str Unsure where to locate (get m :c-compiler)))
;;
(home osx)
;= java.lang.IllegalArgumentException: No method in multimethod 'home'
for dispatch value: :joy.udp/osx …
;; Should be: ;= /Users
(compile-cmd osx)
;= Unsure where to locate cc
;; Should be: ;= /usr/bin/gcc
(compile-cmd unix)
;= Unsure where to locate cc
;; this is the expected output
--
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/d/optout.
--
Robert K. Day
rober...@merton.oxon.org javascript:
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/d/optout.
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
On May 16, 2014, at 8:49 PM, Julian juliangam...@gmail.com wrote: A quick shoutout to the Clojure Community - thanks for the way you've all contributed to make my life (mentally) richer. James Reeves (author of Compojure and many other wonderful libraries) made this interesting comment on Hacker News: Clojure has libraries that implement monads, but these aren't often used for threading state. I can't quite place my finger on why, but in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell. Clojure tends to view mutability as a concurrency problem, and the tools it provides to deal with mutability, such as atoms, refs, agents, channels and so forth, are not mechanisms to avoid mutation, as to provide various guarantees that restrict it in some fashion. It might be that in the cases where I'd use a state monad in Haskell, in Clojure I might instead use an atom. They're in no way equivalent, but they have some overlapping use-cases. https://news.ycombinator.com/item?id=7751424 My question is - have other Clojure/Haskell programmers had this experience? (ie I rarely find myself reaching for something like the state monad). I'm interested to hear if so, and why. I'm perhaps an atypical specimen (and I'm not what I'd call an expert Haskell programmer) but... I've written a fairly substantial prototype in Haskell (maybe 25k sloc, whatever that means) that made heavy use of the state monad. I've re-written the same application in Clojure and it never, even once, occurred to me to use the state monad. As James Reeves pointed out, Clojure programmers normally use atoms or refs to manage this kind of state. Looking at my two code bases you'd notice that the state monad would have been replaced in Clojure by a bunch of refs and atoms. If the state had been less complex and the application less concurrent I'd have used a single atom. In Haskell you'd not be able to use this technique nearly as frequently, if at all, and certainly not in the same way. Please excuse the imprecision in the following... In Haskell, all IO is marked in the type signatures, and so if you want to perform any IO you have to carry the IO monad with you (IO appears in your type signature) into all 'sub' computations. The IO monad exists at the top level of your program, and so must be 'carried' all the way from the top level, you can't just suddenly start using IO deep within some computation. And this is exactly what you want in Haskell -- it's a *good* thing. In Clojure you can perform IO wherever you wish, and in Clojure this is exactly what you want, and is also a *good* thing. Haskell's STM transactions can be thought of as a form of IO action (like reading a file is an IO action) that modify refs (there are no atoms in Haskell, only refs). A transaction must be started in the IO monad and then, like IO, the STM monad is 'carried' in type signatures through all intervening computations that could take part in the transaction. The STM type/monad 'blocks' the IO type/monad (you can't do other IO actions if you might take part in an STM transaction (IO action), this is an effect of, and enforced by, Haskell's type system (i.e. it's a compilation not a runtime error)). In Clojure the STM isn't part of the IO system, and you can start or take part in a transaction anywhere you want to, even nest dosyncs within a single transaction, and intermingle transactional code with IO (no matter how bad an idea that is). That's a lot of talk to get to the point that using the STM has an insignificant impact on the structure of your Clojure programs, while in Haskell the impact is huge (of course, it's possible to argue that that's a *good* thing). In Haskell the state monad is pretty flexible, well supported by the language, and allows you to sidestep a lot of this impact (for one thing, you can introduce it anywhere). In Clojure the state monad would buy you nothing (in my opinion) while using it would have an impact on your programs structure. In Haskell there are forces pushing you to use the state monad, while in Clojure there are forces pushing you away from the state monad. In my opinion. I've 'simplified' my explanation, and obscured some of the actual issues/powers/advantages of Haskell's type system. For example, I hand-wavingly using the phrase 'you can/can't introduce...' -- it isn't quite like that, but that's the effect, so, I think, close enough for this discussion. As an aside, a Clojure programmer might get a feel for what Haskell's state monad is like by considering the - and - macros. Within the - macro you start by defining your initial state then applying a sequence of operations to an updated state. You don't have to mention the state in your code again. The functions called in the - and - macros have either their first or last argument 'receiving' the state and returns the updated
Re: Advice on data structure communication and awareness
Hi Mike! You might talk to Zack at CapClug. The session before the one you
attended he walked through two small Clojure projects, with and without
Prismatic schema.
On Saturday, May 17, 2014 2:22:51 PM UTC, Mike Fikes wrote:
I've never used a dynamically-typed language and an issue I've encountered
with Clojure is a difficulty with readily seeing the data structures
being consumed or returned by functions I'm writing, especially when I come
back to them several days later and if those structures get to be somewhat
nested or otherwise complex.
As a small concrete example, lets say that I currently have a function
that accepts data that looks like {:a A :b B} and, at some point I
change the internals of the function to instead operate on data that looks
like [[:a A] [:b B]].
I could see the docstring communicating that the initial implementation of
the function accepts a map, and then perhaps it boils down to finding
suitable language to describe the structure in the revised implementation
(sequence of pairs, relation, or some other language suitable to the
abstraction).
I suppose this is no different than the documentation aspect that
generics provided in Java when we went from raw types like List to
ListString, but, of course, generics can get unwieldy rather quickly with
things like ListMapString,SetInteger.
Does there exist idiomatic language that developers employ in their
docstrings to quickly convey this kind of info? I see that the docstrings
for clojure.core are fairly readable, but they tend to operate on very
simple data structures.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/d/optout.
Re: [ANN] ring-auth middleware for protecting sessions
Agreed, let's take this off-list. If anyone else wants in on the discussion, feel free to email myself, James, or Aaron. Brendan On Monday, May 19, 2014 9:07:24 AM UTC-4, abedra wrote: On 05/18/2014 09:25 AM, James Reeves wrote: I don't want to seem like I'm badgering you. You have a lot of sound ideas. But I don't think we should be trying to work around insecure designs; we should be making it easier for people to design things securely. In terms of *specific* things wrong that I've yet to mention: the middleware you have won't work for all session stores; only session stores that create a new session if a key is not found. Ideally session stores should reject session IDs that don't exist, rather than construct new ones. - James After reading this thread I would like to make a couple of quick points. I think that ring-auth is a step in the right direction and has the right end goals in mind. To cut past the tension a bit I think that what James is trying to say is let's try to make this less confusing and work within the constraints of the current system. This really isn't a bad idea. In fact, it is usually the way to succeed as an add-on to a library. I understand all of the original points made by Brendan and agree with almost all of them. That being said, I would encourage a little more work here to try and blend just a bit more. I am happy to take this off list and start a more productive discussion on how with a smaller group if there's interest. - Aaron On 18 May 2014 14:06, Brendan Younger brendan...@gmail.com javascript:wrote: On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote: On 18 May 2014 00:09, Brendan Younger brendan...@gmail.com wrote: For anyone else following along at home, I'll just re-iterate the benefits of using ring-auth versus trying to write your routes *just right* to avoid the myriad security issues listed at OWASP. - If you initiate a session with a user over HTTP and later on that user logs in over HTTPS but you don't change the session id in the cookie, then everyone at the coffee shop has access to the authenticated session. Ring-auth protects you from this. This is true, but I don't think we should be aiming to protect people from doing the wrong thing, so much as stop them from doing it in the first place. You seem to be aiming this middleware at people concerned about security, but not so concerned as to follow best practice. I'm a little baffled by this use-case. On the contrary, I'm protecting the user from oversights or bugs in the webapp. Saying that there would be no security issues if only everyone wrote perfect software is a tautology. - If you use a CSRF middleware, but at any time leak the session id cookie over HTTP, then your CSRF protection is broken. Ring-auth protects you from this. CSRF protection doesn't matter if your session is compromised. CSRF is a mechanism for sending a HTTP POST with the user's session ID. If you already have the session ID, there's very few reasons why you'd bother with CSRF. - If you ever send your CSRF token over HTTP, then the entire coffee shop can entice the user to Click here now! and send money to their off-shore account. Ring-auth helps you avoid sending the CSRF token in the clear. Hm? How? There doesn't appear to be anything in your code that looks for the CSRF token embedded in the response body. Because the :csrf-token is only present in the :auth-session, you can be sure that if your code has access to the :csrf-token, then it's communicating over HTTPS with the user. I could not use ring-anti-forgery here because there is no provision to place the token in anything except :session. - If you get a request over HTTP which should have gone over HTTPS and respond with an error, but don't immediately delete the session, then everyone at the coffee shop has seen the authenticated session id (assuming you forgot to set Secure). Ring-auth protects you from this. Again, I don't understand the use-case for this. Setting the secure flag on the session cookie is the clearly the better option. I'm having trouble seeing how you'd present this in your project's README. - If a user closes their browser on a public computer but forgets to sign off, the next user can go back to the site, and hopefully the browser has cached the cookie giving them access to the first user's account. Ring-auth will help prevent this as soon as the Cache-Control header is set. A session idle-timeout isn't necessarily a bad idea, though again this could be implemented as middleware on top of the existing session middleware. I'm not sure what bearing the Cache-Control header has in this case. The Cache-Control header instructs proxies and the like to not cache the Set-Cookie header. See
Re: Joy of Clojure example not working
The second edition of Joy of Clojure, MEAP v10 shows the same error and
progressive solution about half way down pdf-page 318 in section 9.2.4.
On Monday, May 19, 2014 6:39:26 AM UTC-7, gamma235 wrote:
Hi guys, I am working through the pre-release second edition of Joy of
Clojure's section on multi-methods (section 9.2.~ : pg. 313), and am
getting different outputs from what they have printed in the book. I could
just skip over it, but I really want to understand this stuff. Could
someone tell me how to get the *(compile-cmd osx) *call at the end of the
code to produce the expected output: */usr/bin/gcc *? I have commented
out redundancy and moved a couple of lines for readability. Thanks in
advance!
J
(ns joy.udp
(:refer-clojure :exclude [get]))
(defn beget [this proto]
(assoc this ::prototype proto))
(defn get [m k]
(when m
(if-let [[_ v] (find m k)]
v
(recur (::prototype m) k
(def put assoc)
;;; compiler
(defmulti compiler :os)
(defmethod compiler ::unix [m] (get m :c-compiler))
(defmethod compiler ::osx [m] (get m :llvm-compiler))
(def clone (partial beget {}))
(def unix {:os ::unix, :c-compiler cc, :home /home, :dev /dev})
(def osx (- (clone unix)
(put :os ::osx)
(put :llvm-compiler clang)
(put :home /Users)))
;;; home
(defmulti home :os)
(defmethod home ::unix [m] (get m :home))
(defmethod home ::bsd [m] /home)
;; the error on the call to (home osx) is contingent upon toggling the
following lines.
;(derive ::osx ::unix)
;(derive ::osx ::bsd)
(prefer-method home ::unix ::bsd)
;(remove-method home ::bsd)
(derive (make-hierarchy) ::osx ::unix)
;;; compile-cmd
(defmulti compile-cmd (juxt :os compiler))
(defmethod compile-cmd [::osx gcc] [m]
(str /usr/bin/ (get m :c-compiler)))
(defmethod compile-cmd :default [m]
(str Unsure where to locate (get m :c-compiler)))
;;
(home osx)
;= java.lang.IllegalArgumentException: No method in multimethod 'home'
for dispatch value: :joy.udp/osx …
;; Should be: ;= /Users
(compile-cmd osx)
;= Unsure where to locate cc
;; Should be: ;= /usr/bin/gcc
(compile-cmd unix)
;= Unsure where to locate cc
;; this is the expected output
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Best way to pass parameters?
Hi,
I'm building a webservice, have 2 layers: webservice and database.
Webservice layer receives e.g. a product, to add to the database:
{:id 1 :name phone :price 100}
Database layer has a method to insert the product, insert-product.
I could do 1):
(defn insert-product [params])
or 2):
(defn insert-product [id name price])
or 3):
(defn insert-product [{:keys [id name price]})
I tend to prefer 2) because it's safer than 1) and will allow me to add
type check later, don't think this is possible with 3). It doesn't feel
very idiomatic though and makes me feel like I might be thinking in
Java...
I also want make possible to change the keys before inserting in the
database, where 2) and 3) are better than 1).
Is 2) the best option? Is there any reason to use 3) instead? Or is there
maybe a different, better way?
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
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/d/optout.
Re: Best way to pass parameters?
I'd prefer to combine #1 with a validation layer, similar to prismatic's
schema but with a few tweaks. Something* that filtered the param keys
based on the allowed columns and ensured the values were sane. Then,
hopefully write generic sql helper fns to create the parameterized SET stmt
string: id=?, name=?, price=? without needing to explicitly destructure
them.
Lots of good discussion on keyword
args:
https://groups.google.com/forum/#!searchin/clojure/keyword$20parameters%7Csort:date/clojure/yzLCZh-GiQ8/hypLf32IsigJ
*I'll publish that lib as soon as priorities allow it.
On Monday, May 19, 2014 12:07:15 PM UTC-5, Ivan Schuetz wrote:
Hi,
I'm building a webservice, have 2 layers: webservice and database.
Webservice layer receives e.g. a product, to add to the database:
{:id 1 :name phone :price 100}
Database layer has a method to insert the product, insert-product.
I could do 1):
(defn insert-product [params])
or 2):
(defn insert-product [id name price])
or 3):
(defn insert-product [{:keys [id name price]})
I tend to prefer 2) because it's safer than 1) and will allow me to add
type check later, don't think this is possible with 3). It doesn't feel
very idiomatic though and makes me feel like I might be thinking in
Java...
I also want make possible to change the keys before inserting in the
database, where 2) and 3) are better than 1).
Is 2) the best option? Is there any reason to use 3) instead? Or is there
maybe a different, better way?
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
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/d/optout.
passing commands to a running server
I'm sure I've seen a thread on this, but can't find it now. Is there a common pattern for sending management commands to a running server via cli? E.g. if foo starts my ring server, I need something like foo -x twiddle to send twiddle to the running process. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
I wouldn't say that I *often* find myself reaching for monads, or the state monad in particular, but I certainly have found them useful on occasion (and would have sometimes refrained from using them where I'd naturally lean to doing so solely to avoid creating an dependency). For instance, whenever there's a couple of functions that return either a success value or an error message that have to be threaded together---an error monad to do the plumbing makes this a lot nicer. We've got a library at ReadyForZero for walking though json and xml structures and doing transformations based on the values found there, or a bit of configuration, using a combined reader-writer-state monad, and a bunch of code that uses it. The state that's held is actually just a zipper into the structure, the configuration at this point is only a keyword, and the writer log holds reports of unexpected values. This could all be done with other machinery---pass the zipper around directly (or hold it in an atom), pass the log around directly (or hold it in an atom), use a dynamic variable + binding for the configuration (since the reader monad amounts to that anyway). However, I think the monadic code is easier to work with, partly because nothing does need to be managed or passed around explicitly (so it's easier to put together lots of little pieces), and partly because it enables the use of generic tools. Also, traversing the the structures has a fairly imperative feel---go here, go there, do this transformation---with occasional variable binding, and the macro for monadic computations the monad library we're using provides makes expressing that fairly convenient. (Though I may be biased, since I wrote it.) It's true that there doesn't seem to be much need for introducing a monad library and using the state monad if you *only* had the state monad, since Clojure has other ways to deal with mutation (incidentally, I don't think it's true to say that Haskell only has refs, not atoms; there are functions to modify IORefs, which live outside the STM system, atomically). On Fri, May 16, 2014 at 5:49 PM, Julian juliangam...@gmail.com wrote: A quick shoutout to the Clojure Community - thanks for the way you've all contributed to make my life (mentally) richer. James Reeves (author of Compojure and many other wonderful libraries) made this interesting comment on Hacker News: Clojure has libraries that implement monads, but these aren't often used for threading state. I can't quite place my finger on why, but in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell. Clojure tends to view mutability as a concurrency problem, and the tools it provides to deal with mutability, such as atoms, refs, agents, channels and so forth, are not mechanisms to avoid mutation, as to provide various guarantees that restrict it in some fashion. It might be that in the cases where I'd use a state monad in Haskell, in Clojure I might instead use an atom. They're in no way equivalent, but they have some overlapping use-cases. https://news.ycombinator.com/item?id=7751424 My question is - have other Clojure/Haskell programmers had this experience? (ie I rarely find myself reaching for something like the state monad). I'm interested to hear if so, and why. JG PS If this post is unhelpful, could be worded better - please let me know. I'm asking out of curiosity, not with intent to troll. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
On Mon, May 19, 2014 at 7:48 AM, Bob Hutchison hutch-li...@recursive.cawrote: Haskell's STM transactions can be thought of as a form of IO action (like reading a file is an IO action) that modify refs (there are no atoms in Haskell, only refs). A transaction must be started in the IO monad and then, like IO, the STM monad is 'carried' in type signatures through all intervening computations that could take part in the transaction. The STM type/monad 'blocks' the IO type/monad (you can't do other IO actions if you might take part in an STM transaction (IO action), this is an effect of, and enforced by, Haskell's type system (i.e. it's a compilation not a runtime error)). In Clojure the STM isn't part of the IO system, and you can start or take part in a transaction anywhere you want to, even nest dosyncs within a single transaction, and intermingle transactional code with IO (no matter how bad an idea that is). You can use regular IO in an STM action with unsafeUItoSTM: http://hackage.haskell.org/package/base-4.7.0.0/docs/GHC-Conc-Sync.html#v:unsafeIOToSTM. IMO it's advantageous that you have to explicitly say that you want to do IO inside a transaction, given that (in general) you probably shouldn't be doing it. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Best way to pass parameters?
Not an answer to your question, but you may want to check out:
Datomic: The fully transactional, cloud-ready, immutable
database.http://www.datomic.com/
On Monday, May 19, 2014 10:07:15 AM UTC-7, Ivan Schuetz wrote:
Hi,
I'm building a webservice, have 2 layers: webservice and database.
Webservice layer receives e.g. a product, to add to the database:
{:id 1 :name phone :price 100}
Database layer has a method to insert the product, insert-product.
I could do 1):
(defn insert-product [params])
or 2):
(defn insert-product [id name price])
or 3):
(defn insert-product [{:keys [id name price]})
I tend to prefer 2) because it's safer than 1) and will allow me to add
type check later, don't think this is possible with 3). It doesn't feel
very idiomatic though and makes me feel like I might be thinking in
Java...
I also want make possible to change the keys before inserting in the
database, where 2) and 3) are better than 1).
Is 2) the best option? Is there any reason to use 3) instead? Or is there
maybe a different, better way?
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
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/d/optout.
ArithmeticException from unchecked-add
I didn't expect this one. See the illustrative sequence below. Should I be reporting this as a bug, or re-read the docs? ; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3) user (require '[clojure.stacktrace :as st]) user (unchecked-add (Long/MAX_VALUE) (Long/MAX_VALUE) ) -2 user (unchecked-add ^long(Long/MAX_VALUE) ^long(Long/MAX_VALUE) ) -2 user (unchecked-add ^Long(Long/MAX_VALUE) ^Long(Long/MAX_VALUE) ) ArithmeticException integer overflow clojure.lang.Numbers.throwIntOverflow (Numbers.java:1424) user (st/e) java.lang.ArithmeticException: integer overflow at clojure.lang.Numbers.throwIntOverflow (Numbers.java:1424) clojure.lang.Numbers.add (Numbers.java:1723) clojure.lang.Numbers$LongOps.add (Numbers.java:447) clojure.lang.Numbers.add (Numbers.java:126) clojure.lang.Numbers.unchecked_add (Numbers.java:1671) user$eval2514.invoke (form-init3948440390155694364.clj:1) clojure.lang.Compiler.eval (Compiler.java:6703) clojure.lang.Compiler.eval (Compiler.java:) nil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/d/optout.
Re: Re-evaluating recuring go blocks
Great! I've used alts! before with control channels which is definitely useful as well. Timothy, can you elaborate a little? I'm still a little unclear when channels are garbage collected. It it an issue to leave channels open after you've stopped using them? I always feel a little strange constantly creating new channels to replace callbacks, blocking on their output, and then wondering whether or not I need to worry about closing them. If a channel falls out of scope is it garbage collected? How do go blocks affect scoping? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
On May 19, 2014, at 1:44 PM, Ben Wolfson wolf...@gmail.com wrote: I wouldn't say that I *often* find myself reaching for monads, or the state monad in particular, but I certainly have found them useful on occasion (and would have sometimes refrained from using them where I'd naturally lean to doing so solely to avoid creating an dependency). For instance, whenever there's a couple of functions that return either a success value or an error message that have to be threaded together---an error monad to do the plumbing makes this a lot nicer. I badly miss the Maybe and Either monads, but would want the syntactic support Haskell provides (which I can't see will ever be available in Clojure) We've got a library at ReadyForZero for walking though json and xml structures and doing transformations based on the values found there, or a bit of configuration, using a combined reader-writer-state monad, and a bunch of code that uses it. The state that's held is actually just a zipper into the structure, the configuration at this point is only a keyword, and the writer log holds reports of unexpected values. This could all be done with other machinery---pass the zipper around directly (or hold it in an atom), pass the log around directly (or hold it in an atom), use a dynamic variable + binding for the configuration (since the reader monad amounts to that anyway). However, I think the monadic code is easier to work with, partly because nothing does need to be managed or passed around explicitly (so it's easier to put together lots of little pieces), and partly because it enables the use of generic tools. Also, traversing the the structures has a fairly imperative feel---go here, go there, do this transformation---with occasional variable binding, and the macro for monadic computations the monad library we're using provides makes expressing that fairly convenient. (Though I may be biased, since I wrote it.) It's true that there doesn't seem to be much need for introducing a monad library and using the state monad if you *only* had the state monad, since Clojure has other ways to deal with mutation (incidentally, I don't think it's true to say that Haskell only has refs, not atoms; there are functions to modify IORefs, which live outside the STM system, atomically). Which is why I didn't call them atoms :-) There's also a ref in the ST monad (which is a bells-and-whistles state monad that has fallen into a bit of disuse since the IO monad appeared) On Fri, May 16, 2014 at 5:49 PM, Julian juliangam...@gmail.com wrote: A quick shoutout to the Clojure Community - thanks for the way you've all contributed to make my life (mentally) richer. James Reeves (author of Compojure and many other wonderful libraries) made this interesting comment on Hacker News: Clojure has libraries that implement monads, but these aren't often used for threading state. I can't quite place my finger on why, but in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell. Clojure tends to view mutability as a concurrency problem, and the tools it provides to deal with mutability, such as atoms, refs, agents, channels and so forth, are not mechanisms to avoid mutation, as to provide various guarantees that restrict it in some fashion. It might be that in the cases where I'd use a state monad in Haskell, in Clojure I might instead use an atom. They're in no way equivalent, but they have some overlapping use-cases. https://news.ycombinator.com/item?id=7751424 My question is - have other Clojure/Haskell programmers had this experience? (ie I rarely find myself reaching for something like the state monad). I'm interested to hear if so, and why. JG PS If this post is unhelpful, could be worded better - please let me know. I'm asking out of curiosity, not with intent to troll. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed
Re: Re-evaluating recuring go blocks
Channels are not tied to anything, so once your code stops referencing them, they are garbage collected. Go blocks are actually nothing more than pretty callbacks that are attached to channels. So if a go is waiting for a put or a take from a channel, it will be GC'd with the channel. I could go into the details here, but I'll say it this way: if a channel could ever have a value again, it will not be GC'd if there's no possible way for the channel to receive a value, then it will be GC'd at some point. For example: (dotimes [x 100] (let [c (chan)] (dotimes [x 10] (go (! c) Here, all these gos will be GC'd they are parked on the channel, but the channel can never give them a value, so once the channel is GC'd all the gos will as well. You can (ab)use this by simply re-defining your channels when you want to throw away new state. The new channel will replace the old, and that channel will be GC'd along with all the GOs that are waiting on it. Now, this is all a bit different if you use the (thread) macro. In that case threads are not GC'd (since the OS is holding on to them) so you'll need to shut those down on your own. Hopefully this helps. Timothy On Mon, May 19, 2014 at 12:23 PM, Dylan Butman dbut...@gmail.com wrote: Great! I've used alts! before with control channels which is definitely useful as well. Timothy, can you elaborate a little? I'm still a little unclear when channels are garbage collected. It it an issue to leave channels open after you've stopped using them? I always feel a little strange constantly creating new channels to replace callbacks, blocking on their output, and then wondering whether or not I need to worry about closing them. If a channel falls out of scope is it garbage collected? How do go blocks affect scoping? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout. -- “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/d/optout.
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
On May 19, 2014, at 1:50 PM, Ben Wolfson wolf...@gmail.com wrote: On Mon, May 19, 2014 at 7:48 AM, Bob Hutchison hutch-li...@recursive.ca wrote: Haskell's STM transactions can be thought of as a form of IO action (like reading a file is an IO action) that modify refs (there are no atoms in Haskell, only refs). A transaction must be started in the IO monad and then, like IO, the STM monad is 'carried' in type signatures through all intervening computations that could take part in the transaction. The STM type/monad 'blocks' the IO type/monad (you can't do other IO actions if you might take part in an STM transaction (IO action), this is an effect of, and enforced by, Haskell's type system (i.e. it's a compilation not a runtime error)). In Clojure the STM isn't part of the IO system, and you can start or take part in a transaction anywhere you want to, even nest dosyncs within a single transaction, and intermingle transactional code with IO (no matter how bad an idea that is). You can use regular IO in an STM action with unsafeUItoSTM: http://hackage.haskell.org/package/base-4.7.0.0/docs/GHC-Conc-Sync.html#v:unsafeIOToSTM. IMO it's advantageous that you have to explicitly say that you want to do IO inside a transaction, given that (in general) you probably shouldn't be doing it. You're right. I didn't want to bring that up though. It's well named. I used the various unsafe* functions regularly while debugging, and even then only for writing to the console. I would be *very* *very* reluctant to use any of them in production, and certainly not intentionally design something that required their use. So, for the purposes of this discussion, I figured I'd just pretend they didn't exist. Cheers, Bob -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
On Mon, May 19, 2014 at 11:28 AM, Bob Hutchison hutch-li...@recursive.cawrote: On May 19, 2014, at 1:44 PM, Ben Wolfson wolf...@gmail.com wrote: I wouldn't say that I *often* find myself reaching for monads, or the state monad in particular, but I certainly have found them useful on occasion (and would have sometimes refrained from using them where I'd naturally lean to doing so solely to avoid creating an dependency). For instance, whenever there's a couple of functions that return either a success value or an error message that have to be threaded together---an error monad to do the plumbing makes this a lot nicer. I badly miss the Maybe and Either monads, but would want the syntactic support Haskell provides (which I can't see will ever be available in Clojure) I've been pretty happy with: https://github.com/bwo/monads/blob/master/src/monads/core.clj#L65 We've got a library at ReadyForZero for walking though json and xml structures and doing transformations based on the values found there, or a bit of configuration, using a combined reader-writer-state monad, and a bunch of code that uses it. The state that's held is actually just a zipper into the structure, the configuration at this point is only a keyword, and the writer log holds reports of unexpected values. This could all be done with other machinery---pass the zipper around directly (or hold it in an atom), pass the log around directly (or hold it in an atom), use a dynamic variable + binding for the configuration (since the reader monad amounts to that anyway). However, I think the monadic code is easier to work with, partly because nothing does need to be managed or passed around explicitly (so it's easier to put together lots of little pieces), and partly because it enables the use of generic tools. Also, traversing the the structures has a fairly imperative feel---go here, go there, do this transformation---with occasional variable binding, and the macro for monadic computations the monad library we're using provides makes expressing that fairly convenient. (Though I may be biased, since I wrote it.) It's true that there doesn't seem to be much need for introducing a monad library and using the state monad if you *only* had the state monad, since Clojure has other ways to deal with mutation (incidentally, I don't think it's true to say that Haskell only has refs, not atoms; there are functions to modify IORefs, which live outside the STM system, atomically). Which is why I didn't call them atoms :-) There's also a ref in the ST monad (which is a bells-and-whistles state monad that has fallen into a bit of disuse since the IO monad appeared) Well, my point was that IORefs seem to provide in Haskell what atoms provide in Clojure. The refs in ST don't do the the same work because the existential type parameter keeps them from being shared across distinct runST invocations. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re-evaluating recuring go blocks
Yea that's very helpful. When you say the channel can never give them a value, is that because the channel is no longer in scope? So (def c (chan)) (dotimes [x 10] (go (! c))) would not be GC'd until the entire namespace is reevaluated? Would redefining c here cause the 10 GOs to be GC'd? I feel like I've done this before and ended up with duplicated actions... On May 19, 2014, at 2:36 PM, Timothy Baldridge wrote: Channels are not tied to anything, so once your code stops referencing them, they are garbage collected. Go blocks are actually nothing more than pretty callbacks that are attached to channels. So if a go is waiting for a put or a take from a channel, it will be GC'd with the channel. I could go into the details here, but I'll say it this way: if a channel could ever have a value again, it will not be GC'd if there's no possible way for the channel to receive a value, then it will be GC'd at some point. For example: (dotimes [x 100] (let [c (chan)] (dotimes [x 10] (go (! c) Here, all these gos will be GC'd they are parked on the channel, but the channel can never give them a value, so once the channel is GC'd all the gos will as well. You can (ab)use this by simply re-defining your channels when you want to throw away new state. The new channel will replace the old, and that channel will be GC'd along with all the GOs that are waiting on it. Now, this is all a bit different if you use the (thread) macro. In that case threads are not GC'd (since the OS is holding on to them) so you'll need to shut those down on your own. Hopefully this helps. Timothy On Mon, May 19, 2014 at 12:23 PM, Dylan Butman dbut...@gmail.com wrote: Great! I've used alts! before with control channels which is definitely useful as well. Timothy, can you elaborate a little? I'm still a little unclear when channels are garbage collected. It it an issue to leave channels open after you've stopped using them? I always feel a little strange constantly creating new channels to replace callbacks, blocking on their output, and then wondering whether or not I need to worry about closing them. If a channel falls out of scope is it garbage collected? How do go blocks affect scoping? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout. -- “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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xGWfw0O9kbU/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ArithmeticException from unchecked-add
On May 19, 2014, at 2:17 PM, Greg D gregoire.da...@gmail.com wrote: user (unchecked-add ^Long(Long/MAX_VALUE) ^Long(Long/MAX_VALUE) ) ArithmeticException integer overflow clojure.lang.Numbers.throwIntOverflow (Numbers.java:1424) The docs for unchecked-add (http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/unchecked-add) only cover the case of both arguments being primitive longs. Calling with other argument types invokes behavior that is not currently documented. That may be intentional to allow the behavior to change in the future, or it may be an oversight in which case the docs could be improved to document the intended behavior for more argument types. Regarding the current implementation, there is code to handle the case of calling unchecked-add with two Long arguments. In that case, unchecked_add behaves the same way as + does and throws the overflow exception. --Steve -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell
On May 19, 2014, at 2:45 PM, Ben Wolfson wolf...@gmail.com wrote: On Mon, May 19, 2014 at 11:28 AM, Bob Hutchison hutch-li...@recursive.ca wrote: I badly miss the Maybe and Either monads, but would want the syntactic support Haskell provides (which I can't see will ever be available in Clojure) I've been pretty happy with: https://github.com/bwo/monads/blob/master/src/monads/core.clj#L65 Hmm. I'm going to have to take another look at that. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/d/optout.
Unable to find final method in superclass
Hi All, I’m trying to work with NIO in Java 7, and I’m not able to access methods that are declared in the super class. (.getPath (java.nio.file.FileSystems/getDefault) /) The above code throws the following Exception: Exception in thread main java.lang.IllegalArgumentException: No matching method found: getPath for class sun.nio.fs.MacOSXFileSystem, compiling:(/private/var/folders/7t/hd4k0hbn4zx6hvdlhhglncwwnr07sd/T/form-init118501231724308669.clj:1:141) at clojure.lang.Compiler.load(Compiler.java:7142) at clojure.lang.Compiler.loadFile(Compiler.java:7086) at clojure.main$load_script.invoke(main.clj:274) at clojure.main$init_opt.invoke(main.clj:279) at clojure.main$initialize.invoke(main.clj:307) at clojure.main$null_opt.invoke(main.clj:342) at clojure.main$main.doInvoke(main.clj:420) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:383) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.Var.applyTo(Var.java:700) at clojure.main.main(main.java:37) Caused by: java.lang.IllegalArgumentException: No matching method found: getPath for class sun.nio.fs.MacOSXFileSystem at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:53) at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28) at filecollector.core$_main.doInvoke(core.clj:33) at clojure.lang.RestFn.invoke(RestFn.java:397) at clojure.lang.Var.invoke(Var.java:375) at user$eval5$fn__7.invoke(form-init118501231724308669.clj:1) at user$eval5.invoke(form-init118501231724308669.clj:1) at clojure.lang.Compiler.eval(Compiler.java:6703) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.load(Compiler.java:7130) ... 11 more This seems to be related to the following JIRA CLJ-1243http://dev.clojure.org/jira/browse/CLJ-1243 Any thoughts on how to proceed? Thanks, Pradeep -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: Joy of Clojure example not working
I actually just wanna know why I need to use derive so many times. Isn't there a core function/macro where I can derive and set hierarchy all at once? I'm just looking for a more efficient way. My bad for not stating that more clearly in the original post. The real problem though is the last two calls to compile-cmd. I've been messing with it for a couple of days so any help there would be well appreciated. Thanks J -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: Joy of Clojure example not working
I actually just wanna know why I need to use derive so many times. Isn't there a core function/macro where I can derive and set hierarchy all at once? I'm just looking for a more efficient way. My bad for not stating that more clearly in the original post. The real problem though is the last two calls to compile-cmd. I've been messing with it for a couple of days so any help there would be well appreciated. Thanks J -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: Unable to find final method in superclass
Hi Pradeep, The exception you are seeing happens when clojure can't find the correct method; this is often due to an arity mismatch, as is the case here. .getPath expects two arguments: a String followed by a String array. Java makes the variadic parameter seem optional, but in clojure it must explicitly be there. passing nil will get you an npe, but (.getPath (java.nio.file.FileSystems/getDefault) / (make-array String 0)) should work. You could make yourself a convenience function if you're going to call it a lot. Hope that helps you out Paul On Monday, May 19, 2014 4:58:53 PM UTC-6, Pradeep Gollakota wrote: Hi All, I’m trying to work with NIO in Java 7, and I’m not able to access methods that are declared in the super class. (.getPath (java.nio.file.FileSystems/getDefault) /) The above code throws the following Exception: Exception in thread main java.lang.IllegalArgumentException: No matching method found: getPath for class sun.nio.fs.MacOSXFileSystem, compiling:(/private/var/folders/7t/hd4k0hbn4zx6hvdlhhglncwwnr07sd/T/form-init118501231724308669.clj:1:141) at clojure.lang.Compiler.load(Compiler.java:7142) at clojure.lang.Compiler.loadFile(Compiler.java:7086) at clojure.main$load_script.invoke(main.clj:274) at clojure.main$init_opt.invoke(main.clj:279) at clojure.main$initialize.invoke(main.clj:307) at clojure.main$null_opt.invoke(main.clj:342) at clojure.main$main.doInvoke(main.clj:420) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:383) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.Var.applyTo(Var.java:700) at clojure.main.main(main.java:37) Caused by: java.lang.IllegalArgumentException: No matching method found: getPath for class sun.nio.fs.MacOSXFileSystem at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:53) at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28) at filecollector.core$_main.doInvoke(core.clj:33) at clojure.lang.RestFn.invoke(RestFn.java:397) at clojure.lang.Var.invoke(Var.java:375) at user$eval5$fn__7.invoke(form-init118501231724308669.clj:1) at user$eval5.invoke(form-init118501231724308669.clj:1) at clojure.lang.Compiler.eval(Compiler.java:6703) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.load(Compiler.java:7130) ... 11 more This seems to be related to the following JIRA CLJ-1243http://dev.clojure.org/jira/browse/CLJ-1243 Any thoughts on how to proceed? Thanks, Pradeep -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Error using core.async version of into
Hi,
With the following project file:
(defproject p1 0.1.0-SNAPSHOT
:description Project One
:url http://acme.com;
:license {:name Eclipse Public License :url
http://www.eclipse.org/legal/epl-v10.html}
:dependencies [[org.clojure/clojure 1.6.0]
[org.clojure/core.async 0.1.303.0-886421-alpha]]
:main p1.core)
..and starting an associated repl, I see (into) failing thus:
$ lein repl
WARNING: reduce already refers to: #'clojure.core/reduce in namespace:
p1.core, being replaced by: #'clojure.core.async/reduce
WARNING: take already refers to: #'clojure.core/take in namespace: p1.core,
being replaced by: #'clojure.core.async/take
WARNING: map already refers to: #'clojure.core/map in namespace: p1.core,
being replaced by: #'clojure.core.async/map
WARNING: into already refers to: #'clojure.core/into in namespace: p1.core,
being replaced by: #'clojure.core.async/into
WARNING: partition already refers to: #'clojure.core/partition in
namespace: p1.core, being replaced by: #'clojure.core.async/partition
WARNING: merge already refers to: #'clojure.core/merge in namespace:
p1.core, being replaced by: #'clojure.core.async/merge
WARNING: partition-by already refers to: #'clojure.core/partition-by in
namespace: p1.core, being replaced by: #'clojure.core.async/partition-by
nREPL server started on port 60959 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.6.0
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
p1.core= (into [:a] (list :b :c))
#ManyToManyChannel
clojure.core.async.impl.channels.ManyToManyChannel@4cc28666
#IllegalArgumentException java.lang.IllegalArgumentException: No
implementation of method: :take! of protocol:
#'clojure.core.async.impl.protocols/ReadPort found for class:
clojure.lang.PersistentList
p1.core=
I can work-around using: (apply vector :q (list :a :b)), but why is the
(into) failing? Thanks.
Craig
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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/d/optout.
