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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com 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 mimmo.cose...@gmail.com 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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com 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 mimmo.cose...@gmail.com 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
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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe
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 xumingming64398...@gmail.com 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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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
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 mimmo.cose...@gmail.comwrote:
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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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
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 king...@gmail.com 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 markus.mas...@gmail.comwrote: 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 markus...@gmail.comjavascript: 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 fat...@googlemail.comwrote: 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)) (#core$_PLUS_ clojure.core$_PLUS_@11dfc8a0 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 (the actual + function 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 mefo...@gmail.com wrote: RuntimeException EvalReader not allowed when *read-eval* is false. The problem is that the second eval gets (the actual + function 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 mefo...@gmail.com wrote: RuntimeException EvalReader not allowed when *read-eval* is false. The problem is that the second eval gets (the actual + function 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
mimmo.cose...@gmail.comwrote:
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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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.comjavascript:_e({}, 'cvml',
'clojure@googlegroups.com');
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
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 (the actual + function 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 gary.verhae...@gmail.com 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 mimmo.cose...@gmail.com
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 xumingming64398...@gmail.com 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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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
Re: *read-eval* vulnerability
On 30 January 2013 23:32, Chas Emerick c...@cemerick.com 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 (the actual + function 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 michal.marc...@gmail.com wrote: On 30 January 2013 23:32, Chas Emerick c...@cemerick.com 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 (the actual + function 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 mimmo.cose...@gmail.com 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 gary.verhae...@gmail.com
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 mimmo.cose...@gmail.com
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 xumingming64398...@gmail.com
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 mimmo.cose...@gmail.com 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 xumingming64398...@gmail.com
Re: abysmal multicore performance, especially on AMD processors
Wm. Josiah Erikson wmjos...@gmail.com 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 with a
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 sampson.jo...@googlemail.com: 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.
