Belgian JUG (BeJUG) looking for a speaker for a 2013 evening session on Clojure. Anyone interested ?
Hi All, The BeJUG would like to organize a evening session on Clojure in 2013 We're looking for a speaker living/working in Belgium or willing to travel (accommodation can be organized). Anyone interested ? Many Thanks in advance for the replies. Daniel De Luca BeJUG, Devoxx Steering Member -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
the semantic of if-let macro
Hi all, I'm a little bit confused about the semantic of if-let macro. Suppose to call it as follows with map destructoring: (if-let [{key1 :key1} {:key2 "a string"}] true false)) It returns true. But, (let [{key1 :key1} {:key2 "a string"}] (if key1 true false)) returns false. The macro expansion of the former explains why (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) returns (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] true) false)) the consequence, IMHO, is that I would never suggest to use map restructuring inside and if-let binding, because the syntax let me think the result its the opposite of its semantic, Am I completely wrong? mimmo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: the semantic of if-let macro
>From the expansion we can see that if-let determine the result based on the second param, in your case: {:key2 "a string"}, not the local binding you assumed(key1), and I think it is reasonable, for example, if we have the following code: (if-let [{key1 key2} {:key2 "a string"}] true false)) Should if-let determine the result based on key1? key2? IMO {key1 key2} in a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then the result is true. On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: >Hi all, >I'm a little bit confused about the semantic of if-let macro. > >Suppose to call it as follows with map destructoring: > >(if-let [{key1 :key1} {:key2 "a string"}] > true > false)) > >It returns true. > >But, > >(let [{key1 :key1} {:key2 "a string"}] > (if key1 > true > false)) > >returns false. > > >The macro expansion of the former explains why > >(macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) > >returns >(clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if >temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] >true) false)) > >the consequence, IMHO, is that I would never suggest to use map >restructuring inside and if-let binding, because the syntax let me think >the result its the opposite of its semantic, > >Am I completely wrong? > >mimmo > > >-- >-- >You received this message because you are subscribed to the Google >Groups "Clojure" group. >To post to this group, send email to clojure@googlegroups.com >Note that posts from new members are moderated - please be patient with >your first post. >To unsubscribe from 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: the semantic of if-let macro
Uhm, I do not agree. Suppose tha you have a function returning a map of errors (a valip validator lib real case) like the following {:email ["Email can't be empty"] :password ["Password can't be empty"]} If I want to select just the email errors I would write something like that (if-let [{errors :email} (function-returning-error email password)] true false) Reading the above code you're led to believe that if there are email errors, errors local binding will be true. Instead, it returns true even if the are no email errors but there are password errors and you never get the false branch. An if you want to catch password errors you would write something like (if-let [{errors :password} (function-returning-errors email password)] true false) In either case you never get the false branch when function-returning-errors return an error which is not the one you're looking for Mimmo On Jan 30, 2013, at 10:05 AM, James Xu wrote: > From the expansion we can see that if-let determine the result based on > the second param, in your case: {:key2 "a string"}, not the local binding > you assumed(key1), and > I think it is reasonable, for example, if we have the following code: > > (if-let [{key1 key2} {:key2 "a string"}] > true > false)) > > > Should if-let determine the result based on key1? key2? IMO {key1 key2} in > a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then the > result is true. > > > > On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: > >> Hi all, >> I'm a little bit confused about the semantic of if-let macro. >> >> Suppose to call it as follows with map destructoring: >> >> (if-let [{key1 :key1} {:key2 "a string"}] >> true >> false)) >> >> It returns true. >> >> But, >> >> (let [{key1 :key1} {:key2 "a string"}] >> (if key1 >> true >> false)) >> >> returns false. >> >> >> The macro expansion of the former explains why >> >> (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) >> >> returns >> (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if >> temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] >> true) false)) >> >> the consequence, IMHO, is that I would never suggest to use map >> restructuring inside and if-let binding, because the syntax let me think >> the result its the opposite of its semantic, >> >> Am I completely wrong? >> >> mimmo >> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from 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: the semantic of if-let macro
ah, compare > (if-let [{errors :email} (function-returning-error email password)] >true >false) with (let [{errors :email) (function-returning-errros email password)] (if errors true false)) I'm not saying that if-let is wrong, I'm saying I would never use in such a case (i.e. restructuring), because it led me think wrong. mimmo On Jan 30, 2013, at 10:23 AM, Mimmo Cosenza wrote: > Uhm, I do not agree. > > Suppose tha you have a function returning a map of errors (a valip validator > lib real case) like the following > > {:email ["Email can't be empty"] :password ["Password can't be empty"]} > > If I want to select just the email errors I would write something like that > > (if-let [{errors :email} (function-returning-error email password)] >true >false) > > Reading the above code you're led to believe that if there are email errors, > errors local binding will be true. Instead, it returns true even if the are > no email errors but there are password errors and you never get the false > branch. > > An if you want to catch password errors you would write something like > > (if-let [{errors :password} (function-returning-errors email password)] >true >false) > > In either case you never get the false branch when function-returning-errors > return an error which is not the one you're looking for > > Mimmo > > > On Jan 30, 2013, at 10:05 AM, James Xu wrote: > >> From the expansion we can see that if-let determine the result based on >> the second param, in your case: {:key2 "a string"}, not the local binding >> you assumed(key1), and >> I think it is reasonable, for example, if we have the following code: >> >> (if-let [{key1 key2} {:key2 "a string"}] >> true >> false)) >> >> >> Should if-let determine the result based on key1? key2? IMO {key1 key2} in >> a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then the >> result is true. >> >> >> >> On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: >> >>> Hi all, >>> I'm a little bit confused about the semantic of if-let macro. >>> >>> Suppose to call it as follows with map destructoring: >>> >>> (if-let [{key1 :key1} {:key2 "a string"}] >>> true >>> false)) >>> >>> It returns true. >>> >>> But, >>> >>> (let [{key1 :key1} {:key2 "a string"}] >>> (if key1 >>> true >>> false)) >>> >>> returns false. >>> >>> >>> The macro expansion of the former explains why >>> >>> (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) >>> >>> returns >>> (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if >>> temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] >>> true) false)) >>> >>> the consequence, IMHO, is that I would never suggest to use map >>> restructuring inside and if-let binding, because the syntax let me think >>> the result its the opposite of its semantic, >>> >>> Am I completely wrong? >>> >>> mimmo >>> >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from 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 Gro
Re: the semantic of if-let macro
Agree with you that it is very misleading when using map-destructure in if-let, the same applies to sequential-destructure: user=> (if-let [[_ x] [1 nil]] true false) true On 13-1-30 下午5:23, "Mimmo Cosenza" wrote: >Uhm, I do not agree. > >Suppose tha you have a function returning a map of errors (a valip >validator lib real case) like the following > >{:email ["Email can't be empty"] :password ["Password can't be empty"]} > >If I want to select just the email errors I would write something like >that > >(if-let [{errors :email} (function-returning-error email password)] >true >false) > >Reading the above code you're led to believe that if there are email >errors, errors local binding will be true. Instead, it returns true even >if the are no email errors but there are password errors and you never >get the false branch. > >An if you want to catch password errors you would write something like > >(if-let [{errors :password} (function-returning-errors email password)] >true >false) > >In either case you never get the false branch when >function-returning-errors return an error which is not the one you're >looking for > > Mimmo > > >On Jan 30, 2013, at 10:05 AM, James Xu >wrote: > >> From the expansion we can see that if-let determine the result based on >> the second param, in your case: {:key2 "a string"}, not the local >>binding >> you assumed(key1), and >> I think it is reasonable, for example, if we have the following code: >> >> (if-let [{key1 key2} {:key2 "a string"}] >> true >> false)) >> >> >> Should if-let determine the result based on key1? key2? IMO {key1 key2} >>in >> a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then >>the >> result is true. >> >> >> >> On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: >> >>> Hi all, >>> I'm a little bit confused about the semantic of if-let macro. >>> >>> Suppose to call it as follows with map destructoring: >>> >>> (if-let [{key1 :key1} {:key2 "a string"}] >>> true >>> false)) >>> >>> It returns true. >>> >>> But, >>> >>> (let [{key1 :key1} {:key2 "a string"}] >>> (if key1 >>> true >>> false)) >>> >>> returns false. >>> >>> >>> The macro expansion of the former explains why >>> >>> (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) >>> >>> returns >>> (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if >>> temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] >>> true) false)) >>> >>> the consequence, IMHO, is that I would never suggest to use map >>> restructuring inside and if-let binding, because the syntax let me >>>think >>> the result its the opposite of its semantic, >>> >>> Am I completely wrong? >>> >>> mimmo >>> >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from 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/
Re: the semantic of if-let macro
that means never use if-let with sequential destructoring, which brings me to say: never use if-let, because I don't' like to remember such thing while coding and then become crazy to catch my error because of a misleading language feature. mimmo On Jan 30, 2013, at 10:32 AM, James Xu wrote: > Agree with you that it is very misleading when using map-destructure in > if-let, the same applies to sequential-destructure: > > user=> (if-let [[_ x] [1 nil]] true false) > true > > > > On 13-1-30 下午5:23, "Mimmo Cosenza" wrote: > >> Uhm, I do not agree. >> >> Suppose tha you have a function returning a map of errors (a valip >> validator lib real case) like the following >> >> {:email ["Email can't be empty"] :password ["Password can't be empty"]} >> >> If I want to select just the email errors I would write something like >> that >> >> (if-let [{errors :email} (function-returning-error email password)] >> true >> false) >> >> Reading the above code you're led to believe that if there are email >> errors, errors local binding will be true. Instead, it returns true even >> if the are no email errors but there are password errors and you never >> get the false branch. >> >> An if you want to catch password errors you would write something like >> >> (if-let [{errors :password} (function-returning-errors email password)] >> true >> false) >> >> In either case you never get the false branch when >> function-returning-errors return an error which is not the one you're >> looking for >> >> Mimmo >> >> >> On Jan 30, 2013, at 10:05 AM, James Xu >> wrote: >> >>> From the expansion we can see that if-let determine the result based on >>> the second param, in your case: {:key2 "a string"}, not the local >>> binding >>> you assumed(key1), and >>> I think it is reasonable, for example, if we have the following code: >>> >>> (if-let [{key1 key2} {:key2 "a string"}] >>> true >>> false)) >>> >>> >>> Should if-let determine the result based on key1? key2? IMO {key1 key2} >>> in >>> a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then >>> the >>> result is true. >>> >>> >>> >>> On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: >>> Hi all, I'm a little bit confused about the semantic of if-let macro. Suppose to call it as follows with map destructoring: (if-let [{key1 :key1} {:key2 "a string"}] true false)) It returns true. But, (let [{key1 :key1} {:key2 "a string"}] (if key1 true false)) returns false. The macro expansion of the former explains why (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) returns (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] true) false)) the consequence, IMHO, is that I would never suggest to use map restructuring inside and if-let binding, because the syntax let me think the result its the opposite of its semantic, Am I completely wrong? mimmo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
MPI and Clojure
MPI does buffer copying when sending. Since Clojure doesn't modify data there is an optimization that could be made to skip this copy. Has anyone looked at MPI for Clojure with this optimization? Tim Daly d...@axiom-developer.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/groups/opt_out.
Nilsafe operators from clojure.core.contrib fail when not referred
The expression (clojure.core.incubator/-?> 1 identity identity) fails with Unable to resolve symbol: -?> in this context unless -?> is referred into the local namespace. Why it fails is clear: (macroexpand-1 `(clojure.core.incubator/-?> 1 identity identity)) outputs (-?> (-?> 1 clojure.core/identity) clojure.core/identity) It expands to unqualified symbols. This is because the *defnilsafe* macro uses ~'~nil-safe-name in its expansion so no syntax-quoting occurs. A solution would be to define it as (defmacro defnilsafe [docstring non-safe-name nil-safe-name simple-nil-safe-name] `(defmacro ~simple-nil-safe-name ~docstring {:arglists '([~'x ~'form] [~'x ~'form ~'& ~'forms])} ([x# form#] `(let [~'i# ~x#] (when-not (nil? ~'i#) (~~non-safe-name ~'i# ~form# ([x# form# & more#] `(~~nil-safe-name (~~nil-safe-name ~x# ~form#) ~@more# and invoke with (defnilsafe "...doc..." `-> `-?> -?>) I didn't find a more direct way to move between qualified and unqualified symbols. In normal use this weakness is not a major problem, but it becomes one when trying to use the nilsafe operators in macros, in eval'd forms, etc. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: the semantic of if-let macro
I find it helpful to view if-let as a minor variation on if, with the only difference being that you choose to bind the results of the test-expression to some name(s). if-let doesn't care about the values bound to the variables named in binding-target (which might be an arbitrarily complex destructuring). If that's not what you want, then if-let isn't the right tool for the job. (if test-expression expression-evaluated-when-test-expression-is-truthy expression-evaluated-otherwise) is similar to (if-let [ binding-target test-expression ] expression-evaluated-when-test-expression-is-truthy expression-evaluated-otherwise) expands to roughly this, except that test-expression is evaluated only once: (if test-expression (let [binding-target test-expression] expression-evaluated-when-test-expression-is-truthy) expression-evaluated-otherwise) It took me a little while to understand that this is how it worked when I began with clojure, but it seems pretty natural now. if-let is really simple-minded. don't over-think it. // ben On Wed, Jan 30, 2013 at 10:42 AM, Mimmo Cosenza wrote: > that means never use if-let with sequential destructoring, which brings me > to say: never use if-let, because I don't' like to remember such thing > while coding and then become crazy to catch my error because of a > misleading language feature. > > mimmo > > > On Jan 30, 2013, at 10:32 AM, James Xu > wrote: > > > Agree with you that it is very misleading when using map-destructure in > > if-let, the same applies to sequential-destructure: > > > > user=> (if-let [[_ x] [1 nil]] true false) > > true > > > > > > > > On 13-1-30 下午5:23, "Mimmo Cosenza" wrote: > > > >> Uhm, I do not agree. > >> > >> Suppose tha you have a function returning a map of errors (a valip > >> validator lib real case) like the following > >> > >> {:email ["Email can't be empty"] :password ["Password can't be empty"]} > >> > >> If I want to select just the email errors I would write something like > >> that > >> > >> (if-let [{errors :email} (function-returning-error email password)] > >> true > >> false) > >> > >> Reading the above code you're led to believe that if there are email > >> errors, errors local binding will be true. Instead, it returns true even > >> if the are no email errors but there are password errors and you never > >> get the false branch. > >> > >> An if you want to catch password errors you would write something like > >> > >> (if-let [{errors :password} (function-returning-errors email password)] > >> true > >> false) > >> > >> In either case you never get the false branch when > >> function-returning-errors return an error which is not the one you're > >> looking for > >> > >> Mimmo > >> > >> > >> On Jan 30, 2013, at 10:05 AM, James Xu > >> wrote: > >> > >>> From the expansion we can see that if-let determine the result based on > >>> the second param, in your case: {:key2 "a string"}, not the local > >>> binding > >>> you assumed(key1), and > >>> I think it is reasonable, for example, if we have the following code: > >>> > >>> (if-let [{key1 key2} {:key2 "a string"}] > >>> true > >>> false)) > >>> > >>> > >>> Should if-let determine the result based on key1? key2? IMO {key1 key2} > >>> in > >>> a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then > >>> the > >>> result is true. > >>> > >>> > >>> > >>> On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: > >>> > Hi all, > I'm a little bit confused about the semantic of if-let macro. > > Suppose to call it as follows with map destructoring: > > (if-let [{key1 :key1} {:key2 "a string"}] > true > false)) > > It returns true. > > But, > > (let [{key1 :key1} {:key2 "a string"}] > (if key1 > true > false)) > > returns false. > > > The macro expansion of the former explains why > > (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) > > returns > (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if > temp__3971__auto__ (clojure.core/let [{key1 :key1} temp__3971__auto__] > true) false)) > > the consequence, IMHO, is that I would never suggest to use map > restructuring inside and if-let binding, because the syntax let me > think > the result its the opposite of its semantic, > > Am I completely wrong? > > mimmo > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient > with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- >
Re: *read-eval* vulnerability
This isn't what you are asking, but I wanted to make a comment that there is a proposed patch to Clojure attached to ticket CLJ-904 that adds warnings to read and read-string about how their behavior depends upon the value of *read-eval*: http://dev.clojure.org/jira/browse/CLJ-904 Also, one of the examples for read on ClojureDocs.org defines a 'read-from-file-safely' function showing how to avoid eval behavior: http://clojuredocs.org/clojure_core/clojure.core/read Andy On Jan 29, 2013, at 11:02 PM, Takahiro Hozumi wrote: > As more and more projects are using edn format for config, > communication and etc, I think that default value of *read-eval*, > which is true, is source of vulnerability such as recently reported > ring issue [1]. > And I don't understand why read-string depends on *read-eval* instead > of argument. > I believe optional argument is more preferable. > What do you think? > > [1] Ring 1.0.3 / 1.1.7 released to fix security flaw > https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124 -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] nrepl.el 0.1.6 released
Thanks for your great work on this! On Tue, Jan 29, 2013 at 9:07 PM, Tim King wrote: > I am pleased to announce that nrepl.el v0.1.6 has been released, and is > now available on marmalade. > > Preview versions of the next release are available on Melpa. > See the Readme on github (https://github.com/kingtim/nrepl.el) for > installation and usage instructions. > > Notable changes since our last release: > - Ported SLIME macroexpansion mode (see README for full documentation) > - Updated macroexpansion to use pprint with code-dispatch > - Eldoc argument highlighting > - Simplify popup buffer quit/restore using `quit-window'. > - Add nrepl-disconnected-hook and disable nrepl when disconnected. > - Emit server log output at bottom of *nrepl-server* buffer. (Brian Rowe) > - Reset nrepl-buffer-ns on nrepl-restart. Fixes issue #187. > - Implement nrepl-mode as a derived mode. (Bozhidar Batsov) > - fix #194 - stacktrace buffer was not respecting nrepl-popup-stacktraces > (Bozhidar Batsov) > - Get key bindings documentation into the minor mode descriptions (Ivan > Necas) > - Fix message formatting for results containing "%" (fixes issue #195). > - Fix NPE in nrepl-jump (issue #124). (cola-zero) > - Fix nrepl to work with fish shell (issue #192). (Dario Bertini) > - Adjusted the javadoc keybinding and mentioned it in the README. > (Bozhidar Batsov) > - made the TAB command in the nrepl-mode buffers configurable (Bozhidar > Batsov) > - Added convenience function to report the version of nREPL in use. (fogus) > - Fix issue #163 - exclude ns from nrepl-load-file. > - Ignore "killed" and "hangup" events in sentinel (Chris Bilson) > - Shift-Home and Shift-Ctrl-a in repl, which select just the user input > when on the input line. (Ivan Kozik) > - Clear the correct region when replacing the input line. (Ivan Kozik) > - Fix issue #146. Include "@" in nrepl-input-complete-p. > - Handle stdout messages that arrive after status "done" > - Various and sundry bug fixes and documentation additions and updates. > > Many thanks to all the contributed their time and energy by > reporting issues, submitting patches and testing out bug fixes and features. > > Enjoy! > > Cheers, > Tim > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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: *read-eval* vulnerability
This is exactly the thread that I meant to start a couple of weeks ago. Thanks for giving me the kick in the pants, Takahiro. :-) What brought the issue to the fore for me: * a greatly increased interest in security issues due to my own work's requirements * the most recent arbitrary code execution issues that the Rails community has had to weather * Building and maintaining Friend (http://github.com/cemerick/friend) has gradually brought me into contact with a handful of suitably experienced people that have done security reviews (none formal or published, BTW) of the Clojure web stack. In each of the three times I've been fortunate to discuss those reviews with their instigators, the first thing that comes up is *read-eval*. Perhaps not surprising — we've all known that its default is an open barn door. The sole thread I could dig up that discusses this is http://groups.google.com/group/clojure/browse_frm/thread/1bd6b66b51406ec9?tvc=1, where the common refrain is simply "you should bind *read-eval* to false when reading data from unknown sources". Despite this not being news, recent events and certain changes in my foci have made it a newly-important issue, at least to me. Takahiro is exactly right that the growing usage of Clojure data / edn as a common serialization format for e.g. web service APIs makes the default of *read-eval* very, very relevant; IMO, despite any concerns re: breaking existing code. On that front, *read-eval* affects only the #= construction, a facility that is, IIRC, purposefully undocumented. This lack of documentation is good insofar as few people have used #=, but it has also left undocumented an implementation detail of the reader that ships with a dangerous default (see http://dev.clojure.org/jira/browse/CLJ-904). The advice and necessity to tighten up *read-eval* as "good practice" is a design fault. There are things that authors of certain key Clojure libraries can do to fix this up as a side effect of using those libraries, but it would obviously be ideal for Clojure/core to address the policy proactively. Otherwise, I'm certain that a time will come when people not steeped in Clojure arcana will be deploying vulnerable applications and services. Unfortunately, I suspect that time has long since arrived...we just don't (yet?) have the eyeballs and juice that the Rails community has to produce controversy. Cheers, - Chas On Jan 30, 2013, at 2:02 AM, Takahiro Hozumi wrote: > As more and more projects are using edn format for config, > communication and etc, I think that default value of *read-eval*, > which is true, is source of vulnerability such as recently reported > ring issue [1]. > And I don't understand why read-string depends on *read-eval* instead > of argument. > I believe optional argument is more preferable. > What do you think? > > [1] Ring 1.0.3 / 1.1.7 released to fix security flaw > https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124 > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: *read-eval* vulnerability
The most simple thing would be to change the default value of *read-eval* to false... Marek On Wednesday, January 30, 2013 8:02:54 AM UTC+1, Takahiro Hozumi wrote: > > As more and more projects are using edn format for config, > communication and etc, I think that default value of *read-eval*, > which is true, is source of vulnerability such as recently reported > ring issue [1]. > And I don't understand why read-string depends on *read-eval* instead > of argument. > I believe optional argument is more preferable. > What do you think? > > [1] Ring 1.0.3 / 1.1.7 released to fix security flaw > > https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124 > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
On Wed, Jan 30, 2013 at 10:18 AM, Marek Šrank wrote: > The most simple thing would be to change the default value of *read-eval* > to false... > > Understanding that this may break existing code (how much?), I think it would reflect well on the community to make decisions to improve safety and security, especially with respect to defaults like this. Avoiding surprises after deployment is a virtue in my option. +1 Regards, Kyle Burton -- Twitter: @kyleburton Github: https://github.com/kyleburton Blog: http://asymmetrical-view.com/ Fun: http://snapclean.me/ -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
I like the idea of setting the default to false. This potentially does break some code, but perhaps it breaks unknowingly insecure code - which is a pretty big bonus. I'd love it if I upgraded to a new release of Clojure and my app toppled down because of my own shortsightedness. An additional idea is to add an optional second argument to read-string, which does the binding for you. Regards, Paul On Wednesday, January 30, 2013 7:25:46 AM UTC-8, Kyle Burton wrote: > > > On Wed, Jan 30, 2013 at 10:18 AM, Marek Šrank > > > wrote: > >> The most simple thing would be to change the default value of *read-eval* >> to false... >> >> > Understanding that this may break existing code (how much?), I think it > would reflect well on the community to make decisions to improve safety and > security, especially with respect to defaults like this. Avoiding > surprises after deployment is a virtue in my option. > > +1 > > Regards, > > Kyle Burton > > -- > Twitter: @kyleburton > Github: https://github.com/kyleburton > Blog: http://asymmetrical-view.com/ > Fun: http://snapclean.me/ > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: screencast: friend and creating a login form
Fantastic job! I wish something like this had been available when I built my first website with Friend. I ended up rolling my own workflows after giving up on tracking all the internals of interactive-form. ~Gary On Tuesday, January 29, 2013 3:55:13 PM UTC-5, Nelson Morris wrote: > > I've released a screencast on friend and using its interactive-form > workflow to create a login form. > http://www.clojurewebdevelopment.com/videos/friend-interactive-form > > I've got more in various stages of completion, so I'd be interested in > hearing feedback. > > Thanks, > Nelson Morris > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] nrepl.el 0.1.6 released
Huzzah! The uphill climb continues apace! On Tuesday, January 29, 2013 10:07:54 PM UTC-5, Tim King wrote: > > I am pleased to announce that nrepl.el v0.1.6 has been released, and is > now available on marmalade. > > Preview versions of the next release are available on Melpa. > See the Readme on github (https://github.com/kingtim/nrepl.el) for > installation and usage instructions. > > Notable changes since our last release: > - Ported SLIME macroexpansion mode (see README for full documentation) > - Updated macroexpansion to use pprint with code-dispatch > - Eldoc argument highlighting > - Simplify popup buffer quit/restore using `quit-window'. > - Add nrepl-disconnected-hook and disable nrepl when disconnected. > - Emit server log output at bottom of *nrepl-server* buffer. (Brian Rowe) > - Reset nrepl-buffer-ns on nrepl-restart. Fixes issue #187. > - Implement nrepl-mode as a derived mode. (Bozhidar Batsov) > - fix #194 - stacktrace buffer was not respecting nrepl-popup-stacktraces > (Bozhidar Batsov) > - Get key bindings documentation into the minor mode descriptions (Ivan > Necas) > - Fix message formatting for results containing "%" (fixes issue #195). > - Fix NPE in nrepl-jump (issue #124). (cola-zero) > - Fix nrepl to work with fish shell (issue #192). (Dario Bertini) > - Adjusted the javadoc keybinding and mentioned it in the README. > (Bozhidar Batsov) > - made the TAB command in the nrepl-mode buffers configurable (Bozhidar > Batsov) > - Added convenience function to report the version of nREPL in use. (fogus) > - Fix issue #163 - exclude ns from nrepl-load-file. > - Ignore "killed" and "hangup" events in sentinel (Chris Bilson) > - Shift-Home and Shift-Ctrl-a in repl, which select just the user input > when on the input line. (Ivan Kozik) > - Clear the correct region when replacing the input line. (Ivan Kozik) > - Fix issue #146. Include "@" in nrepl-input-complete-p. > - Handle stdout messages that arrive after status "done" > - Various and sundry bug fixes and documentation additions and updates. > > Many thanks to all the contributed their time and energy by > reporting issues, submitting patches and testing out bug fixes and features. > > Enjoy! > > Cheers, > Tim > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
No doseq inside finally?
Is there a reason why this isn't allowed? user> (try nil (finally (doseq [x (range 10)] (println x CompilerException java.lang.UnsupportedOperationException: Cannot recur from catch/finally, compiling:(NO_SOURCE_PATH:1) Is this some JVM restriction? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Job - Clojure web developer
After seeing the recent Clojure QA job postings, I thought it appropriate to post our web developer position: http://blog.diligenceengine.com/clojure-web-developer This is located in Toronto and is more of a junior position in terms of compensation (but happy to talk on this). Remote work is not out of the question, though local is preferred. We use Clojure in all parts of our technology stack, as well as few other languages. Feel free to contact me if you have questions. Alex -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
On Wed, Jan 30, 2013 at 1:02 AM, Takahiro Hozumi wrote: > As more and more projects are using edn format for config, > communication and etc, I think that default value of *read-eval*, > which is true, is source of vulnerability such as recently reported > ring issue [1]. > Slight diversion here - what is the approved and safe way to read data from an untrusted source? I had a task this week which required data to to be read via an API. I wanted to use clojure data/EDN, and ended up with three primary issues: 1 - *read-eval*, which I bound to false 2 - data literals - I don't know which data literals are truly safe from an external source. I rebound *data-readers* to make sure only the system readers were around, which I assume are thought to be safe 3 - read-string only reads one expression, silently ignoring additional characters. I assume I could solve this using read and checking for additional items and raising an error if more expressions were received than expected In the end, I re-implemented this API using JSON, where there are no safety issues parsing data. This is an unfortunate decision, and I'd like to enable the clojure data version. I'm just not sure whether or not using read/read-string is intended to be a safe reader in the long term. If it's not, maybe we need a set of functions that are blessed for use with untrusted data? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
Out of curiosity, I made a patch to Clojure that causes the default value of *read-eval* to be false instead of true, to see if any of the tests pass, and to let other people try it out in case it breaks things that would be surprising and/or disruptive. It is attached to this new ticket: http://dev.clojure.org/jira/browse/CLJ-1153 I found this behavior from one of the unit tests included with Clojure. Does it surprise anyone, or look like it would break something important? % java -cp clojure.jar clojure.main Clojure 1.5.0-master-SNAPSHOT user=> '(list + 1 2 3) (list + 1 2 3) user=> (eval '(list + 1 2 3)) (# 1 2 3) user=> (eval (eval '(list + 1 2 3))) RuntimeException EvalReader not allowed when *read-eval* is false. clojure.lang.Util.runtimeException (Util.java:219) The last expression evaluates to 6 when *read-eval* is true, with no exception. Andy On Jan 30, 2013, at 7:04 AM, Chas Emerick wrote: > This is exactly the thread that I meant to start a couple of weeks ago. > Thanks for giving me the kick in the pants, Takahiro. :-) > > What brought the issue to the fore for me: > > * a greatly increased interest in security issues due to my own work's > requirements > * the most recent arbitrary code execution issues that the Rails community > has had to weather > * Building and maintaining Friend (http://github.com/cemerick/friend) has > gradually brought me into contact with a handful of suitably experienced > people that have done security reviews (none formal or published, BTW) of the > Clojure web stack. > > In each of the three times I've been fortunate to discuss those reviews with > their instigators, the first thing that comes up is *read-eval*. Perhaps not > surprising — we've all known that its default is an open barn door. The sole > thread I could dig up that discusses this is > http://groups.google.com/group/clojure/browse_frm/thread/1bd6b66b51406ec9?tvc=1, > where the common refrain is simply "you should bind *read-eval* to false > when reading data from unknown sources". Despite this not being news, recent > events and certain changes in my foci have made it a newly-important issue, > at least to me. > > Takahiro is exactly right that the growing usage of Clojure data / edn as a > common serialization format for e.g. web service APIs makes the default of > *read-eval* very, very relevant; IMO, despite any concerns re: breaking > existing code. On that front, *read-eval* affects only the #= construction, > a facility that is, IIRC, purposefully undocumented. This lack of > documentation is good insofar as few people have used #=, but it has also > left undocumented an implementation detail of the reader that ships with a > dangerous default (see http://dev.clojure.org/jira/browse/CLJ-904). > > The advice and necessity to tighten up *read-eval* as "good practice" is a > design fault. There are things that authors of certain key Clojure libraries > can do to fix this up as a side effect of using those libraries, but it would > obviously be ideal for Clojure/core to address the policy proactively. > Otherwise, I'm certain that a time will come when people not steeped in > Clojure arcana will be deploying vulnerable applications and services. > Unfortunately, I suspect that time has long since arrived...we just don't > (yet?) have the eyeballs and juice that the Rails community has to produce > controversy. > > Cheers, > > - Chas > > On Jan 30, 2013, at 2:02 AM, Takahiro Hozumi wrote: > >> As more and more projects are using edn format for config, >> communication and etc, I think that default value of *read-eval*, >> which is true, is source of vulnerability such as recently reported >> ring issue [1]. >> And I don't understand why read-string depends on *read-eval* instead >> of argument. >> I believe optional argument is more preferable. >> What do you think? >> >> [1] Ring 1.0.3 / 1.1.7 released to fix security flaw >> https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124 -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: No doseq inside finally?
Bug fixed in the forthcoming Clojure 1.5: http://dev.clojure.org/jira/browse/CLJ-667 % java -cp clojure.jar clojure.main Clojure 1.5.0-master-SNAPSHOT user=> (try nil (finally (doseq [x (range 10)] (println x 0 1 2 3 4 5 6 7 8 9 nil Andy On Jan 30, 2013, at 8:42 AM, nick rothwell wrote: > Is there a reason why this isn't allowed? > > user> (try nil (finally (doseq [x (range 10)] (println x > CompilerException java.lang.UnsupportedOperationException: Cannot recur from > catch/finally, compiling:(NO_SOURCE_PATH:1) > > Is this some JVM restriction? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
> RuntimeException EvalReader not allowed when *read-eval* is false. The problem is that the second eval gets ( 1 2 3) which invokes the right pathway triggering the exception. You can trigger the same exception by: (binding [*read-eval* false] (eval (list + 1 2 3))) People are not sending actual functions across the wire, so the only way to trigger this is to do some kind of pre-processing of symbols to functions or perhaps: (binding [*read-eval* false] (eval '(eval (quote (+ 1 2 3) ;;=> 6 Whoops! Maybe setting *read-eval* to false is not enough. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
"Java.next: The Java.next languages"
Some folks here might find this series interesting: Java.next: The Java.next languages Leveraging Groovy, Scala, and Clojure in an increasingly polyglot world Neal Ford, Director / Software Architect / Meme Wrangler, ThoughtWorks Inc. Summary: This article launches a new developerWorks series by Neal Ford that performs a deep comparison of three next-generation JVM languages: Groovy, Scala, and Clojure. In this initial installment, find out what you'll gain from understanding their similarities and differences — whether or not you choose to keep using Java™ as your main programming language for now. http://www.ibm.com/developerworks/library/j-jn1/ -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: *read-eval* vulnerability
Although let me say that I agree with false being the default. I'm not saying that is a bad idea, only that we need to be careful if evaling what comes over... but I guess that is obvious and if not then we get what we deserve. ;-) On Wed, Jan 30, 2013 at 12:23 PM, Michael Fogus wrote: >> RuntimeException EvalReader not allowed when *read-eval* is false. > > The problem is that the second eval gets ( 1 2 > 3) which invokes the right pathway triggering the exception. You can > trigger the same exception by: > > (binding [*read-eval* false] (eval (list + 1 2 3))) > > People are not sending actual functions across the wire, so the only > way to trigger this is to do some kind of pre-processing of symbols to > functions or perhaps: > > (binding [*read-eval* false] (eval '(eval (quote (+ 1 2 3) > ;;=> 6 > > Whoops! > > Maybe setting *read-eval* to false is not enough. -- -- http://blog.fogus.me -- http://github.com/fogus -- -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
Kyle R. Burton writes: > Understanding that this may break existing code (how much?), I think it > would reflect well on the community to make decisions to improve safety and > security, especially with respect to defaults like this. Avoiding > surprises after deployment is a virtue in my option. Considering that *read-eval* is undocumented, I think that makes for a much stronger case for changing its behaviour. Code that relies on *read-eval* defaulting to true is relying on an undocumented implementation detail, so breakage surrounding it should not be terribly surprising. If the default is not changed for whatever reason (which I believe would be a bad decision, but whatever) then at the very least it should be documented. Having a potential source of fatal exploits which can only be protected against by tribal knowledge is a really unfortunate situation. -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/groups/opt_out.
Re: *read-eval* vulnerability
I think the objective is to make read, read-string, etc. safe. Explicit use of eval is what it is...short of sandboxing, you're opting into all that eval implies. - Chas Michael Fogus wrote: >> RuntimeException EvalReader not allowed when *read-eval* is false. > >The problem is that the second eval gets ( 1 2 >3) which invokes the right pathway triggering the exception. You can >trigger the same exception by: > >(binding [*read-eval* false] (eval (list + 1 2 3))) > >People are not sending actual functions across the wire, so the only >way to trigger this is to do some kind of pre-processing of symbols to >functions or perhaps: > >(binding [*read-eval* false] (eval '(eval (quote (+ 1 2 3) >;;=> 6 > >Whoops! > >Maybe setting *read-eval* to false is not enough. > >-- >-- >You received this message because you are subscribed to the Google >Groups "Clojure" group. >To post to this group, send email to clojure@googlegroups.com >Note that posts from new members are moderated - please be patient with >your first post. >To unsubscribe from 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: *read-eval* vulnerability
I would prefer that *read-eval* default to false. In this case, security is more important than backwards compatibility. However, I want to point out that there is an issue with backwards compatibility, especially for users of *print-dup* (default false). In many cases, with *print-dup* true, the printed representation will use the "#=" notation, which is readable only if *read-eval* is true. If your code is binding *print-dup*, you probably should be binding *read-eval* explicitly, not depending on the default. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Nilsafe operators from clojure.core.contrib fail when not referred
In Clojure 1.5 pre-releases, there's a new macro called some-> . The source looks like it would work fine in earlier versions of Clojure. At this point, I don't think it's a good idea to keep slightly different versions in contrib. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: the semantic of if-let macro
If-let does the right thing. What would your intuition expect for (if-let [{a :a b :b} {:a 1 :b nil}] true false) For your particular use-case, what you want is more along the lines of (if-let [errors (:password (fn-returning-errors))] ...) On Wednesday, January 30, 2013, Ben Smith-Mannschott wrote: > I find it helpful to view if-let as a minor variation on if, with the only > difference being that you choose to bind the results of the test-expression > to some name(s). if-let doesn't care about the values bound to the > variables named in binding-target (which might be an arbitrarily complex > destructuring). If that's not what you want, then if-let isn't the right > tool for the job. > > (if test-expression > expression-evaluated-when-test-expression-is-truthy > expression-evaluated-otherwise) > > is similar to > > (if-let [ binding-target test-expression ] > expression-evaluated-when-test-expression-is-truthy > expression-evaluated-otherwise) > > expands to roughly this, except that test-expression is evaluated only > once: > > (if test-expression > (let [binding-target test-expression] > expression-evaluated-when-test-expression-is-truthy) > expression-evaluated-otherwise) > > It took me a little while to understand that this is how it worked when I > began with clojure, but it seems pretty natural now. if-let is really > simple-minded. don't over-think it. > > // ben > > > On Wed, Jan 30, 2013 at 10:42 AM, Mimmo Cosenza > wrote: > > that means never use if-let with sequential destructoring, which brings me > to say: never use if-let, because I don't' like to remember such thing > while coding and then become crazy to catch my error because of a > misleading language feature. > > mimmo > > > On Jan 30, 2013, at 10:32 AM, James Xu > wrote: > > > Agree with you that it is very misleading when using map-destructure in > > if-let, the same applies to sequential-destructure: > > > > user=> (if-let [[_ x] [1 nil]] true false) > > true > > > > > > > > On 13-1-30 下午5:23, "Mimmo Cosenza" wrote: > > > >> Uhm, I do not agree. > >> > >> Suppose tha you have a function returning a map of errors (a valip > >> validator lib real case) like the following > >> > >> {:email ["Email can't be empty"] :password ["Password can't be empty"]} > >> > >> If I want to select just the email errors I would write something like > >> that > >> > >> (if-let [{errors :email} (function-returning-error email password)] > >> true > >> false) > >> > >> Reading the above code you're led to believe that if there are email > >> errors, errors local binding will be true. Instead, it returns true even > >> if the are no email errors but there are password errors and you never > >> get the false branch. > >> > >> An if you want to catch password errors you would write something like > >> > >> (if-let [{errors :password} (function-returning-errors email password)] > >> true > >> false) > >> > >> In either case you never get the false branch when > >> function-returning-errors return an error which is not the one you're > >> looking for > >> > >> Mimmo > >> > >> > >> On Jan 30, 2013, at 10:05 AM, James Xu > >> wrote: > >> > >>> From the expansion we can see that if-let determine the result based on > >>> the second param, in your case: {:key2 "a string"}, not the local > >>> binding > >>> you assumed(key1), and > >>> I think it is reasonable, for example, if we have the following code: > >>> > >>> (if-let [{key1 key2} {:key2 "a string"}] > >>> true > >>> false)) > >>> > >>> > >>> Should if-let determine the result based on key1? key2? IMO {key1 key2} > >>> in > >>> a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then > >>> the > >>> result is true. > >>> > >>> > >>> > >>> On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: > >>> > Hi all, > I'm a little bit confused about the semantic of if-let macro. > > Suppose to call it as follows with map destructoring: > > (if-let [{key1 :key1} {:key2 "a string"}] > true > false)) > > It returns true. > > But, > > (let [{key1 :key1} {:key2 "a string"}] > (if key1 > true > false)) > > returns false. > > > The macro expansion of the former explains why > > (macroexpand-1 '(if-let [{key1 :key1} {:key2 "a string"}] true false)) > > returns > (clojure.core/let [temp__3971__auto__ {:key2 "a string"}] (if > >> > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to > clojure@googlegroups.com 'clojure@googlegroups.com');> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com 'clojure%2bunsubscr...@googlegroups.com');> > For more options, visit this group at > http://groups.google.com/group/clojur
Re: Nilsafe operators from clojure.core.contrib fail when not referred
Good point; too late to fix them now that they are about to be deprecated. On Wednesday, January 30, 2013 8:33:12 PM UTC+1, miner wrote: > > In Clojure 1.5 pre-releases, there's a new macro called some-> . The > source looks like it would work fine in earlier versions of Clojure. At > this point, I don't think it's a good idea to keep slightly different > versions in contrib. > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
GSOC 2013 projects?
Hey folks, Even though it hasn't been announced yet, I was wondering about project ideas for this year's GSOC. I was looking at a few projects from last year, which seemed pretty interesting. Is there any official list btw? *I'm rather enthusiastic about taking part this summer :D* (cheers) Omer -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: *read-eval* vulnerability
On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote: >> RuntimeException EvalReader not allowed when *read-eval* is false. > > The problem is that the second eval gets ( 1 2 > 3) which invokes the right pathway triggering the exception. You can > trigger the same exception by: > > (binding [*read-eval* false] (eval (list + 1 2 3))) Re-reading this, I'm clearly not grokking something here. Maybe I'm having a slow afternoon; send help. :-P This obviously ends up running through EvalReader — but why? How is LispReader ever involved at all? Thanks, - Chas -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: the semantic of if-let macro
Perhaps I've been a little bit rude with if-let, but I really do not see how (if-let [{erros :email} (function-returning-errors email password)] true false) is not misleading. I now that the tested value is the one returning from the function call and not the value assigned to errors local, but exactly this is misleading in reading the code. What I'm saying is that in such a case (i.e. if-let + sequence destructoring) you're just coding wrong. I'm not say that if-let is wrong. So I prefer not to use if-let when I'm restructuring because I could easily create a subtle bug. I don't like complexity when is not needed. You already have the if-let limitation in the number of locals you can use. Now you have this subtle behaviour to pay attention to. If I now that something is dangerous I prefer to stay a little bit apart from it. Mimmo On Jan 30, 2013, at 8:51 PM, Gary Verhaegen wrote: > If-let does the right thing. What would your intuition expect for > > (if-let [{a :a b :b} {:a 1 :b nil}] > true > false) > > For your particular use-case, what you want is more along the lines of > > (if-let [errors (:password (fn-returning-errors))] > ...) > > On Wednesday, January 30, 2013, Ben Smith-Mannschott wrote: > I find it helpful to view if-let as a minor variation on if, with the only > difference being that you choose to bind the results of the test-expression > to some name(s). if-let doesn't care about the values bound to the variables > named in binding-target (which might be an arbitrarily complex > destructuring). If that's not what you want, then if-let isn't the right tool > for the job. > > (if test-expression > expression-evaluated-when-test-expression-is-truthy > expression-evaluated-otherwise) > > is similar to > > (if-let [ binding-target test-expression ] > expression-evaluated-when-test-expression-is-truthy > expression-evaluated-otherwise) > > expands to roughly this, except that test-expression is evaluated only once: > > (if test-expression > (let [binding-target test-expression] > expression-evaluated-when-test-expression-is-truthy) > expression-evaluated-otherwise) > > It took me a little while to understand that this is how it worked when I > began with clojure, but it seems pretty natural now. if-let is really > simple-minded. don't over-think it. > > // ben > > > On Wed, Jan 30, 2013 at 10:42 AM, Mimmo Cosenza > wrote: > that means never use if-let with sequential destructoring, which brings me to > say: never use if-let, because I don't' like to remember such thing while > coding and then become crazy to catch my error because of a misleading > language feature. > > mimmo > > > On Jan 30, 2013, at 10:32 AM, James Xu wrote: > > > Agree with you that it is very misleading when using map-destructure in > > if-let, the same applies to sequential-destructure: > > > > user=> (if-let [[_ x] [1 nil]] true false) > > true > > > > > > > > On 13-1-30 下午5:23, "Mimmo Cosenza" wrote: > > > >> Uhm, I do not agree. > >> > >> Suppose tha you have a function returning a map of errors (a valip > >> validator lib real case) like the following > >> > >> {:email ["Email can't be empty"] :password ["Password can't be empty"]} > >> > >> If I want to select just the email errors I would write something like > >> that > >> > >> (if-let [{errors :email} (function-returning-error email password)] > >> true > >> false) > >> > >> Reading the above code you're led to believe that if there are email > >> errors, errors local binding will be true. Instead, it returns true even > >> if the are no email errors but there are password errors and you never > >> get the false branch. > >> > >> An if you want to catch password errors you would write something like > >> > >> (if-let [{errors :password} (function-returning-errors email password)] > >> true > >> false) > >> > >> In either case you never get the false branch when > >> function-returning-errors return an error which is not the one you're > >> looking for > >> > >> Mimmo > >> > >> > >> On Jan 30, 2013, at 10:05 AM, James Xu > >> wrote: > >> > >>> From the expansion we can see that if-let determine the result based on > >>> the second param, in your case: {:key2 "a string"}, not the local > >>> binding > >>> you assumed(key1), and > >>> I think it is reasonable, for example, if we have the following code: > >>> > >>> (if-let [{key1 key2} {:key2 "a string"}] > >>> true > >>> false)) > >>> > >>> > >>> Should if-let determine the result based on key1? key2? IMO {key1 key2} > >>> in > >>> a whole is more reaonable. And {key1 key2} == {:key2 "a string"}, then > >>> the > >>> result is true. > >>> > >>> > >>> > >>> On 13-1-30 下午4:51, "Mimmo Cosenza" wrote: > >>> > Hi all, > I'm a little bit confused about the semantic of if-let macro. > > Suppose to call it as follows with map destructoring: > > (if-let [{key1 :key1} {:key2 "a string"}
Re: *read-eval* vulnerability
On 30 January 2013 23:32, Chas Emerick wrote: > On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote: > >>> RuntimeException EvalReader not allowed when *read-eval* is false. >> >> The problem is that the second eval gets ( 1 2 >> 3) which invokes the right pathway triggering the exception. You can >> trigger the same exception by: >> >> (binding [*read-eval* false] (eval (list + 1 2 3))) > > Re-reading this, I'm clearly not grokking something here. Maybe I'm having a > slow afternoon; send help. :-P > > This obviously ends up running through EvalReader — but why? How is > LispReader ever involved at all? I believe the story goes like so: The eval call here compiles a list of a function object and three numbers. The function object gets compiled to code which effectively calls readString on "#=(clojure.core$_PLUS_. )". (It so happens that print-dup knows how to handle functions; if it didn't, an exception would be thrown during compilation with the message "Can't embed object in code, maybe print-dup not defined: ...".) When the compiled code is executed, readString gets called to reconstruct the function, and since *read-eval* is false, this fails. +1 to setting *read-eval* to false by default, by the way. Cheers, Michał > > Thanks, > > - Chas > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > 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: *read-eval* vulnerability
PS. The relevant part of Compiler.java is the emitValue method of ObjExpr (or grep for readStringMethod -- I believe this is its only use in the compiler). On 30 January 2013 23:59, Michał Marczyk wrote: > On 30 January 2013 23:32, Chas Emerick wrote: >> On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote: >> RuntimeException EvalReader not allowed when *read-eval* is false. >>> >>> The problem is that the second eval gets ( 1 2 >>> 3) which invokes the right pathway triggering the exception. You can >>> trigger the same exception by: >>> >>> (binding [*read-eval* false] (eval (list + 1 2 3))) >> >> Re-reading this, I'm clearly not grokking something here. Maybe I'm having >> a slow afternoon; send help. :-P >> >> This obviously ends up running through EvalReader — but why? How is >> LispReader ever involved at all? > > I believe the story goes like so: > > The eval call here compiles a list of a function object and three > numbers. The function object gets compiled to code which effectively > calls readString on "#=(clojure.core$_PLUS_. )". (It so happens that > print-dup knows how to handle functions; if it didn't, an exception > would be thrown during compilation with the message "Can't embed > object in code, maybe print-dup not defined: ...".) When the compiled > code is executed, readString gets called to reconstruct the function, > and since *read-eval* is false, this fails. > > +1 to setting *read-eval* to false by default, by the way. > > Cheers, > Michał > >> >> Thanks, >> >> - Chas >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> 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: the semantic of if-let macro
Interesting to see this interpretation of if-let... I'd always read it as "if the condition is truthy then let the binding be the condition and evaluate the first expression else just evaluate the second expression". Since the binding could create multiple named values (in general), I'm not sure how 'if' could be applied to the binding(s) rather than the whole condition, but now that you've posted this, I can see some potential for confusion when folks first encounter if-let... Presumably the same confusion could arise for when-let? FWIW, the docstring for if-let says "If test is true, evaluates then with binding-form bound to the value of test, if not, yields else" (and when-let is similarly worded) so that seems pretty clear that the condition (as a whole) is test and only if it is truthy is the binding done for just the first arm of the if... On Wed, Jan 30, 2013 at 2:47 PM, Mimmo Cosenza wrote: > Perhaps I've been a little bit rude with if-let, but I really do not see how > > (if-let [{erros :email} (function-returning-errors email password)] > true > false) > > is not misleading. I now that the tested value is the one returning from the > function call and not the value assigned to errors local, but exactly this > is misleading in reading the code. > > What I'm saying is that in such a case (i.e. if-let + sequence > destructoring) you're just coding wrong. I'm not say that if-let is wrong. > So I prefer not to use if-let when I'm restructuring because I could easily > create a subtle bug. > > I don't like complexity when is not needed. You already have the if-let > limitation in the number of locals you can use. Now you have this subtle > behaviour to pay attention to. If I now that something is dangerous I > prefer to stay a little bit apart from it. > > Mimmo > > On Jan 30, 2013, at 8:51 PM, Gary Verhaegen > wrote: > > If-let does the right thing. What would your intuition expect for > > (if-let [{a :a b :b} {:a 1 :b nil}] > true > false) > > For your particular use-case, what you want is more along the lines of > > (if-let [errors (:password (fn-returning-errors))] > ...) > > On Wednesday, January 30, 2013, Ben Smith-Mannschott wrote: >> >> I find it helpful to view if-let as a minor variation on if, with the only >> difference being that you choose to bind the results of the test-expression >> to some name(s). if-let doesn't care about the values bound to the variables >> named in binding-target (which might be an arbitrarily complex >> destructuring). If that's not what you want, then if-let isn't the right >> tool for the job. >> >> (if test-expression >> expression-evaluated-when-test-expression-is-truthy >> expression-evaluated-otherwise) >> >> is similar to >> >> (if-let [ binding-target test-expression ] >> expression-evaluated-when-test-expression-is-truthy >> expression-evaluated-otherwise) >> >> expands to roughly this, except that test-expression is evaluated only >> once: >> >> (if test-expression >> (let [binding-target test-expression] >> expression-evaluated-when-test-expression-is-truthy) >> expression-evaluated-otherwise) >> >> It took me a little while to understand that this is how it worked when I >> began with clojure, but it seems pretty natural now. if-let is really >> simple-minded. don't over-think it. >> >> // ben >> >> >> On Wed, Jan 30, 2013 at 10:42 AM, Mimmo Cosenza >> wrote: >> >> that means never use if-let with sequential destructoring, which brings me >> to say: never use if-let, because I don't' like to remember such thing while >> coding and then become crazy to catch my error because of a misleading >> language feature. >> >> mimmo >> >> >> On Jan 30, 2013, at 10:32 AM, James Xu >> wrote: >> >> > Agree with you that it is very misleading when using map-destructure in >> > if-let, the same applies to sequential-destructure: >> > >> > user=> (if-let [[_ x] [1 nil]] true false) >> > true >> > >> > >> > >> > On 13-1-30 下午5:23, "Mimmo Cosenza" wrote: >> > >> >> Uhm, I do not agree. >> >> >> >> Suppose tha you have a function returning a map of errors (a valip >> >> validator lib real case) like the following >> >> >> >> {:email ["Email can't be empty"] :password ["Password can't be empty"]} >> >> >> >> If I want to select just the email errors I would write something like >> >> that >> >> >> >> (if-let [{errors :email} (function-returning-error email password)] >> >> true >> >> false) >> >> >> >> Reading the above code you're led to believe that if there are email >> >> errors, errors local binding will be true. Instead, it returns true >> >> even >> >> if the are no email errors but there are password errors and you never >> >> get the false branch. >> >> >> >> An if you want to catch password errors you would write something like >> >> >> >> (if-let [{errors :password} (function-returning-errors email password)] >> >> true >> >> false) >> >> >> >> In either case you never get the false branch when >> >> function-
Re: abysmal multicore performance, especially on AMD processors
"Wm. Josiah Erikson" writes: > Am I reading this right that this is actually a Java problem, and not > clojure-specific? Wouldn't the rest of the Java community have noticed > this? Or maybe massive parallelism in this particular way isn't > something commonly done with Java in the industry? > > Thanks for the patches though - it's nice to see some improvement... > I'll be fascinated to see how this turns out in the end. Have we found > a large Java bug? Apologies for my very-slow reply here. I keep thinking that I’ll have more time to look into this issue, and keep having other things requiring my attention. And on top of that, I’ve temporarily lost the many-way AMD system I was using as a test-bed. I very much want to see if I can get my hands on an Intel system to compare to. My AMD system is in theory 32-way – two physical CPUs, each with 16 cores. However, Linux reports (via /proc/cpuinfo) the cores in groups of 8 (“cpu cores : 8” etc). And something very strange happens when extending parallelism beyond 8-way... I ran several experiments using a version of your whole-application benchmark I modified to control the level of parallelism. At parallelism 9+, the real time it takes to complete the benchmark hardly budges, but the user/CPU time increases linearly with the level of parallelism! As far as I can tell, multi-processor AMD *is* a NUMA architecture, which might potentially explain things. But enabling the JVM NUMA options doesn’t seem to affect the benchmark. I think next steps are two-fold: (1) examine parallelism vs real & CPU time on an Intel system, and (2) attempt to reproduce the observed behavior in pure Java. I’m keeping my fingers crossed that I’ll have some time to look at this more soon, but I’m honestly not very hopeful. In the mean time, I hope you’ve managed to exploit multi-process parallelism to run more efficiently? -Marshall -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: abysmal multicore performance, especially on AMD processors
FYI we had a bit of a discussion about this at a meetup in Amherst MA yesterday, and while I'm not sufficiently on top of the JVM or system issues to have briefed everyone on all of the details there has been a little of followup since the discussion, including results of some different experiments by Chas Emerick, at: http://www.meetup.com/Functional-Programming-Connoisseurs/messages/boards/thread/30946382 -Lee On Jan 30, 2013, at 8:39 PM, Marshall Bockrath-Vandegrift wrote: > > Apologies for my very-slow reply here. I keep thinking that I’ll have > more time to look into this issue, and keep having other things > requiring my attention. And on top of that, I’ve temporarily lost the > many-way AMD system I was using as a test-bed. > > I very much want to see if I can get my hands on an Intel system to > compare to. My AMD system is in theory 32-way – two physical CPUs, each > with 16 cores. However, Linux reports (via /proc/cpuinfo) the cores in > groups of 8 (“cpu cores : 8” etc). And something very strange happens > when extending parallelism beyond 8-way... I ran several experiments > using a version of your whole-application benchmark I modified to > control the level of parallelism. At parallelism 9+, the real time it > takes to complete the benchmark hardly budges, but the user/CPU time > increases linearly with the level of parallelism! As far as I can tell, > multi-processor AMD *is* a NUMA architecture, which might potentially > explain things. But enabling the JVM NUMA options doesn’t seem to > affect the benchmark. > > I think next steps are two-fold: (1) examine parallelism vs real & CPU > time on an Intel system, and (2) attempt to reproduce the observed > behavior in pure Java. I’m keeping my fingers crossed that I’ll have > some time to look at this more soon, but I’m honestly not very hopeful. > > In the mean time, I hope you’ve managed to exploit multi-process > parallelism to run more efficiently? > > -Marshall -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: abysmal multicore performance, especially on AMD processors
Josiah mentioned requesting a free trial of the ZIng JVM. Did you ever get access to that, and were able to try your code running on that? Again, I have no direct experience with their product to guarantee you better results -- just that I've heard good things about their ability to handle concurrent workloads with different GC than most JVMs. Andy On Jan 30, 2013, at 6:20 PM, Lee Spector wrote: > > FYI we had a bit of a discussion about this at a meetup in Amherst MA > yesterday, and while I'm not sufficiently on top of the JVM or system issues > to have briefed everyone on all of the details there has been a little of > followup since the discussion, including results of some different > experiments by Chas Emerick, at: > http://www.meetup.com/Functional-Programming-Connoisseurs/messages/boards/thread/30946382 > > -Lee > > On Jan 30, 2013, at 8:39 PM, Marshall Bockrath-Vandegrift wrote: >> >> Apologies for my very-slow reply here. I keep thinking that I’ll have >> more time to look into this issue, and keep having other things >> requiring my attention. And on top of that, I’ve temporarily lost the >> many-way AMD system I was using as a test-bed. >> >> I very much want to see if I can get my hands on an Intel system to >> compare to. My AMD system is in theory 32-way – two physical CPUs, each >> with 16 cores. However, Linux reports (via /proc/cpuinfo) the cores in >> groups of 8 (“cpu cores : 8” etc). And something very strange happens >> when extending parallelism beyond 8-way... I ran several experiments >> using a version of your whole-application benchmark I modified to >> control the level of parallelism. At parallelism 9+, the real time it >> takes to complete the benchmark hardly budges, but the user/CPU time >> increases linearly with the level of parallelism! As far as I can tell, >> multi-processor AMD *is* a NUMA architecture, which might potentially >> explain things. But enabling the JVM NUMA options doesn’t seem to >> affect the benchmark. >> >> I think next steps are two-fold: (1) examine parallelism vs real & CPU >> time on an Intel system, and (2) attempt to reproduce the observed >> behavior in pure Java. I’m keeping my fingers crossed that I’ll have >> some time to look at this more soon, but I’m honestly not very hopeful. >> >> In the mean time, I hope you’ve managed to exploit multi-process >> parallelism to run more efficiently? >> >> -Marshall -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Installing Clojure on Windows 7
On Thursday, January 24, 2013 12:56:59 PM UTC-5, sampso...@googlemail.com wrote: > > Apparently installing a development environment for Clojure on Windows 7 > is very difficult. What is the best way, that has a chance that it might > work? > INSTRUCTIONS FOR WINDOWS 7 TO INSTALL CLOJURE - LEININGEN - ECLIPSE - COUNTERCLOCKWISE 30 January 2013 I am a newbie. Maybe my ignorant perspective will be helpful to others on Windows 7. Maybe someone more astute than I will incorporate some of the following into something more canonic. Some of this is from other sources, but ultimately appeared to get me a Hello World on Console window. Note that, before the following, many other attempts were made and, though I tried to remove everything, not sure I did. It is possible that leftover resources from a previous attempt when added to the steps below resulted in final success. Don't give up. Nothing crashed for me, but no kidding, back up files on your computer to an external hard drive. Also suggest you create a restore point, so if things don't work you may be able to restore your system to its previous state (automatically uninstalling software). Click: Windows Start Menu Icon (lower right of screen) Control Panel System System Protection Create Give the Restore Point a name. Wait for the Restore Point to be created. Click Close Click OK. If things fail and you want to start fresh, you can return to System Protection to attempt to restore the system to its previous state. In order to successfully install ANYTHING in the Program Files folder (64 bit) of Windows 7. If you are installing 32 bit then Program Files (x86). These are the folders, respectively that such programs seem to want to be in) I: TURN OFF USER ACCOUNT CONTROL Open User Account Control Settings by clicking the Start button Picture of the Start button, and then clicking Control Panel. In the search box, type uac, and then click Change User Account Control settings. Do one of the following: To turn off UAC, move the slider to the Never notify position, and then click OK. Administrator permission required If you're prompted for an administrator password or confirmation, type the password or provide confirmation. You will need to restart your computer for UAC to be turned off. DISABLE YOUR FIREWALL. LATER, AFTER EVERYTHING IS INSTALLED, TURN USER ACCOUNT CONTROL AND YOUR FIREWALL BACK ON. I INSTALLED 64 BIT JAVA 7 (NOT the EE version. And on a computer capable of running 64 bit). Don't remember where I got it from but try here: http://www.oracle.com/technetwork/java/javase/downloads/index.html INSTALLED IT TO THE PROGRAM FILES FOLDER ON MY HARD DRIVE. I INSTALLED 64 BIT ECLIPSE. FROM http://www.eclipse.org/downloads/ To the Right of Eclipse IDE for Java Developers, 150 MB (I did not select the Eclipse Java EE version) I clicked to download 64 Bit. I DOWNLOADED IT TO THE PROGRAM FOLDER ON MY HARD DRIVE. It reportedly includes Git. Unzipped and installed it right there in the Program Folder. The first time Eclipse is run, it will ask you for a location on your disk where Eclipse will put its metadata and create new projects by default. I placed that in my local UserName Folder within the User Folder. Installed Counterclockwise also known as CCW (a Clojure plugin for Eclipse) In the Help Menu select Install new software… Paste the following Counterclockwise url in the “Work with:” textbox: http://ccw.cgrand.net/updatesite/ , Hit Enter [[[---Name repository; Click next; Click next; Accept] Select counterclockwise, verify the “Contact all update sites during …” chekbox is checked, click next, accept licence, etc., restart Eclipse I floundered around and found Java Perspective (not Java Browser), but you may try, as another instructed: "Go to menu Window > Reset Perspective ... this will reset the way the views are layout, and also place correctly the views contributed by Counterclockwise (the Namespace Browser view, placed "behind" the code outline view)" Now you would think it would be enough to just set pathway to a single folder and let the system find things in subfolders. That might be slow. Not sure if it would work. I set many Pathways. Not sure what is really necessary but things seem to work. Good way to copy a pathway is to navigate to inside the folder in Windows Explorer. Click just to the right of the pathway in the title bar to highlight the entire path and press Ctrl C to copy. Navigate to the inside of the .eclipse folder, and copy the name of the pathway to the .eclipse folder C:\Users\MyComputerUserName\.eclipse Paste it into a text editor and add a backslash to make it look like C:\Users\MyComputerUserName\.eclipse\ (read somewhere the backslash was necessary) While you're at it, you may add other pathways. Navigate to inside the .lein folder and add that in your text editor. Separate the 2 pathways wi
Re: Installing Clojure on Windows 7
I use eclipse with the counterclockwise plugin. Till now I had no problems with Vista,7 & 8. Am 24.01.2013 18:57 schrieb : > Apparently installing a development environment for Clojure on Windows 7 > is very difficult. What is the best way, that has a chance that it might > work? > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: screencast: friend and creating a login form
Definitely agree that it'd have helped when I was first starting to use friend. I spent a lot of time reading his source. If you plan on doing more about friend it'd definitely be good to show how to authorize a specific user rather than just at the role level, as well as something about how to redirect after logging in use ::redirect-on-auth?. Both those things took me a while to figure out. Keep it up, I'm look forward to seeing more of them. On Tuesday, January 29, 2013 2:55:13 PM UTC-6, Nelson Morris wrote: > > I've released a screencast on friend and using its interactive-form > workflow to create a login form. > http://www.clojurewebdevelopment.com/videos/friend-interactive-form > > I've got more in various stages of completion, so I'd be interested in > hearing feedback. > > Thanks, > Nelson Morris > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: the semantic of if-let macro
On Wednesday, January 30, 2013 8:51:47 PM UTC+1, Gary Verhaegen wrote: > For your particular use-case, what you want is more along the lines of > > (if-let [errors (:password (fn-returning-errors))] > ...) > yes, precisely! mimmo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: the semantic of if-let macro
On Thursday, January 31, 2013 1:49:40 AM UTC+1, Sean Corfield wrote: > but now that you've posted this, I > can see some potential for confusion when folks first encounter > if-let... Presumably the same confusion could arise for when-let? > yes, this is the confusion that you can incur in. mimmo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.