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
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))
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))
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
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
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
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
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 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
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
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,
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
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
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*,
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
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
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
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
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
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
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].
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:
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
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
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
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
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.
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
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*
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
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
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,
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)
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:
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
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
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:
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
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
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
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
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 -
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
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
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
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.
46 matches
Mail list logo
