Re: Map destructuring variations in Pedestal
Pretty sure it's just a typo / bug. I think it should read:
{servlet ::servlet
type ::type
:or {type :jetty}
:as service-map}
On Tue, Mar 19, 2013 at 10:09 PM, Matching Socks wrote:
> I'm puzzled by two :or syntaxes that are used in io.pedestal.service.http,
> from [io.pedestal/pedestal.service "0.1.1-SNAPSHOT"], which is where
> following along with the Getting Started got me.
>
> In one place, it pairs :or with a map whose keys are symbols being bound in
> the outer form:
>
> {routes ::routes
> file-path ::file-path
> resource-path ::resource-path
> method-param-name ::method-param-name
> :or {file-path nil
> resource-path "public"
> method-param-name :_method}
> :as service-map}
>
> A little farther down, it pairs :or with a map whose key is a key from the
> map being destructured:
>
> {servlet ::servlet
> type ::type
> :or {::type :jetty}
> :as service-map}
>
> In a tiny experiment, I don't see the second way working. But the compiler
> does not emit any message. Is there something subtle going on?
>
> helloworld.server=> (defn a [{x :X y :Y :or {y 3}}] (vector x y))
> #'helloworld.server/a
> helloworld.server=> (a {:X 7})
> [7 3]
> helloworld.server=> (defn a' [{x :X y :Y :or {:Y 3}}] (vector x y))
> #'helloworld.server/a'
> helloworld.server=> (a' {:X 7})
> [7 nil]
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Map destructuring variations in Pedestal
I'm puzzled by two :or syntaxes that are used in io.pedestal.service.http,
from [io.pedestal/pedestal.service "0.1.1-SNAPSHOT"], which is where
following along with the Getting Started got me.
In one place, it pairs :or with a map whose keys are symbols being bound in
the outer form:
{routes ::routes
file-path ::file-path
resource-path ::resource-path
method-param-name ::method-param-name
:or {file-path nil
resource-path "public"
method-param-name :_method}
:as service-map}
A little farther down, it pairs :or with a map whose key is a key from the
map being destructured:
{servlet ::servlet
type ::type
:or {::type :jetty}
:as service-map}
In a tiny experiment, I don't see the second way working. But the compiler
does not emit any message. Is there something subtle going on?
helloworld.server=> (defn a [{x :X y :Y :or {y 3}}] (vector x y))
#'helloworld.server/a
helloworld.server=> (a {:X 7})
[7 3]
helloworld.server=> (defn a' [{x :X y :Y :or {:Y 3}}] (vector x y))
#'helloworld.server/a'
helloworld.server=> (a' {:X 7})
[7 nil]
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Exception propagation design in Clojure web APIs.
One argument against using exceptions for commonplace occurrences (like
invalid user input) is that the structure of the code may make it difficult
to see where those things can pop up, which can lead to misunderstanding
and introduction of bugs.
Even with Java's checked exceptions, where a certain method may be declared
to throw a custom ValidationException or whatever, you can't see from the
calling code which methods can throw one. You have to go look at the
signatures of all called methods looking for them. (Or more likely you
comment out the catch clause and see which calls your IDE underlines in
red.) Using standard control-flow constructs make branch-points explicit.
On Mar 19, 2013 8:26 PM, "Dave Sann" wrote:
> That should have been "why is 1 preferable over 2"...
>
>
> On Wednesday, 20 March 2013 12:24:12 UTC+11, Dave Sann wrote:
>>
>> I am interested in this view that exceptions are an anti pattern. I have
>> heard it voiced before.
>>
>> I am not sure that I understand why.
>>
>> As I see it you have a choices:
>>
>> 1. Handle in the result - and test this result repeatedly all the way
>> back to the caller
>> 2. Handle "out of band" - Throw an exception, allow the stack to unwind
>> and catch where it matters
>>
>> [And maybe - but I am not very knowledgeable on this and it won't work
>> today on the JVM anyway
>> 3. Use continuation passing style with TCO to shortcut the return to
>> follow an exception path]
>>
>> So, ignoring 3.
>>
>> Why is 2 preferable over 1? There are certainly pros and cons.
>>
>> Dave
>>
>>
>> On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
>>>
>>> I'd argue that using exceptions for control flow is something of an
>>> anti-pattern, even in Java.
>>>
>>> In this case a better mechanism might be to use polymorphism. For
>>> instance:
>>>
>>> (defprotocol Validatable
>>> (validation-errors [x] "Return the validation errors for x."))
>>>
>>> (defn valid? [x]
>>> (empty? (validation-errors x)))
>>>
>>> Then you can define a general function to validate and store that item
>>> in a database:
>>>
>>> (defn store-valid [db x]
>>> (if (valid? x)
>>> (store db x)
>>> (validation-error-response x)))
>>>
>>> - James
>>>
>>>
>>> On 19 March 2013 16:43, Julien Dreux wrote:
>>>
Hi all,
Coming from a Java background, I am having a hard time understanding
how validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName)**;
} else if (...) {
throw new EmailAlreadyInUseException(u.**getEmail());
}
}
/** Endpoint method, catches & formats the exceptions thrown by the db
method. **/
@POST("/api/user/create")
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions
to responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to
write tons of if/else statements for validation handling. Exception were
just thrown from anywhere, bubbling back up to inital call, and if not
handled in the endpoint method, a specialized class mapped them into a
proper response. The exceptions contained all the information needed to
generate 'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors ["error 1" "error 2" ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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
Group
Re: Exception propagation design in Clojure web APIs.
That should have been "why is 1 preferable over 2"...
On Wednesday, 20 March 2013 12:24:12 UTC+11, Dave Sann wrote:
>
> I am interested in this view that exceptions are an anti pattern. I have
> heard it voiced before.
>
> I am not sure that I understand why.
>
> As I see it you have a choices:
>
> 1. Handle in the result - and test this result repeatedly all the way
> back to the caller
> 2. Handle "out of band" - Throw an exception, allow the stack to unwind
> and catch where it matters
>
> [And maybe - but I am not very knowledgeable on this and it won't work
> today on the JVM anyway
> 3. Use continuation passing style with TCO to shortcut the return to
> follow an exception path]
>
> So, ignoring 3.
>
> Why is 2 preferable over 1? There are certainly pros and cons.
>
> Dave
>
>
> On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
>>
>> I'd argue that using exceptions for control flow is something of an
>> anti-pattern, even in Java.
>>
>> In this case a better mechanism might be to use polymorphism. For
>> instance:
>>
>> (defprotocol Validatable
>> (validation-errors [x] "Return the validation errors for x."))
>>
>> (defn valid? [x]
>> (empty? (validation-errors x)))
>>
>> Then you can define a general function to validate and store that item in
>> a database:
>>
>> (defn store-valid [db x]
>> (if (valid? x)
>> (store db x)
>> (validation-error-response x)))
>>
>> - James
>>
>>
>> On 19 March 2013 16:43, Julien Dreux wrote:
>>
>>> Hi all,
>>>
>>> Coming from a Java background, I am having a hard time understanding how
>>> validation error propagation should work in clojure web APIs.
>>>
>>> To be clear, this is similar to how my Java web service would be setup:
>>>
>>> /** Method that validates the model, accesses the DB. If something went
>>> wrong, throw an exception */
>>> public void validateAndCreateUser(User u) throws ValidationException,
>>> EmailAlreadyInUseException, ... {
>>> ...
>>> if(...) {
>>> throw new ValidationException(fieldName);
>>> } else if (...) {
>>> throw new EmailAlreadyInUseException(u.getEmail());
>>> }
>>> }
>>>
>>> /** Endpoint method, catches & formats the exceptions thrown by the db
>>> method. **/
>>> @POST("/api/user/create")
>>> public Response createUser (User u) {
>>> ..
>>> try{
>>> validateAndCreateUser(u);
>>> return Response.ok();
>>> } catch (Exception e) {
>>> return generateExceptionResponse(e); //Method that maps exceptions
>>> to responses.
>>> }
>>> }
>>>
>>> For all of Java's clunkiness, this had the benefit of not having to
>>> write tons of if/else statements for validation handling. Exception were
>>> just thrown from anywhere, bubbling back up to inital call, and if not
>>> handled in the endpoint method, a specialized class mapped them into a
>>> proper response. The exceptions contained all the information needed to
>>> generate 'rich' error messages back to the client.
>>>
>>> Being a Clojure newbie, I wonder what a good pattern is for a similar
>>> situation. So far, I have a method that validates models based on a schema,
>>> that returns
>>>
>>> {:success true}
>>>
>>> or
>>>
>>> {:success false :errors ["error 1" "error 2" ...]}
>>>
>>> But I don't know how to avoid having to write if/else conditions of the
>>> sort in each function between my endpoint and db functions.
>>>
>>> (if (validation :success)
>>> (follow-normal-path)
>>> (handle-validation-errors validation))
>>>
>>>
>>> Any guidance appreciated.
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@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, vi
Re: Exception propagation design in Clojure web APIs.
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way back
to the caller
2. Handle "out of band" - Throw an exception, allow the stack to unwind and
catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
>
> I'd argue that using exceptions for control flow is something of an
> anti-pattern, even in Java.
>
> In this case a better mechanism might be to use polymorphism. For instance:
>
> (defprotocol Validatable
> (validation-errors [x] "Return the validation errors for x."))
>
> (defn valid? [x]
> (empty? (validation-errors x)))
>
> Then you can define a general function to validate and store that item in
> a database:
>
> (defn store-valid [db x]
> (if (valid? x)
> (store db x)
> (validation-error-response x)))
>
> - James
>
>
> On 19 March 2013 16:43, Julien Dreux >wrote:
>
>> Hi all,
>>
>> Coming from a Java background, I am having a hard time understanding how
>> validation error propagation should work in clojure web APIs.
>>
>> To be clear, this is similar to how my Java web service would be setup:
>>
>> /** Method that validates the model, accesses the DB. If something went
>> wrong, throw an exception */
>> public void validateAndCreateUser(User u) throws ValidationException,
>> EmailAlreadyInUseException, ... {
>> ...
>> if(...) {
>> throw new ValidationException(fieldName);
>> } else if (...) {
>> throw new EmailAlreadyInUseException(u.getEmail());
>> }
>> }
>>
>> /** Endpoint method, catches & formats the exceptions thrown by the db
>> method. **/
>> @POST("/api/user/create")
>> public Response createUser (User u) {
>> ..
>> try{
>> validateAndCreateUser(u);
>> return Response.ok();
>> } catch (Exception e) {
>> return generateExceptionResponse(e); //Method that maps exceptions to
>> responses.
>> }
>> }
>>
>> For all of Java's clunkiness, this had the benefit of not having to write
>> tons of if/else statements for validation handling. Exception were just
>> thrown from anywhere, bubbling back up to inital call, and if not handled
>> in the endpoint method, a specialized class mapped them into a proper
>> response. The exceptions contained all the information needed to generate
>> 'rich' error messages back to the client.
>>
>> Being a Clojure newbie, I wonder what a good pattern is for a similar
>> situation. So far, I have a method that validates models based on a schema,
>> that returns
>>
>> {:success true}
>>
>> or
>>
>> {:success false :errors ["error 1" "error 2" ...]}
>>
>> But I don't know how to avoid having to write if/else conditions of the
>> sort in each function between my endpoint and db functions.
>>
>> (if (validation :success)
>> (follow-normal-path)
>> (handle-validation-errors validation))
>>
>>
>> Any guidance appreciated.
>>
>> Cheers,
>>
>> Julien
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: Exception propagation design in Clojure web APIs.
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way back
to the caller
2. Handle "out of band" - Throw an exception, allow the stack to unwind and
catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
>
> I'd argue that using exceptions for control flow is something of an
> anti-pattern, even in Java.
>
> In this case a better mechanism might be to use polymorphism. For instance:
>
> (defprotocol Validatable
> (validation-errors [x] "Return the validation errors for x."))
>
> (defn valid? [x]
> (empty? (validation-errors x)))
>
> Then you can define a general function to validate and store that item in
> a database:
>
> (defn store-valid [db x]
> (if (valid? x)
> (store db x)
> (validation-error-response x)))
>
> - James
>
>
> On 19 March 2013 16:43, Julien Dreux >wrote:
>
>> Hi all,
>>
>> Coming from a Java background, I am having a hard time understanding how
>> validation error propagation should work in clojure web APIs.
>>
>> To be clear, this is similar to how my Java web service would be setup:
>>
>> /** Method that validates the model, accesses the DB. If something went
>> wrong, throw an exception */
>> public void validateAndCreateUser(User u) throws ValidationException,
>> EmailAlreadyInUseException, ... {
>> ...
>> if(...) {
>> throw new ValidationException(fieldName);
>> } else if (...) {
>> throw new EmailAlreadyInUseException(u.getEmail());
>> }
>> }
>>
>> /** Endpoint method, catches & formats the exceptions thrown by the db
>> method. **/
>> @POST("/api/user/create")
>> public Response createUser (User u) {
>> ..
>> try{
>> validateAndCreateUser(u);
>> return Response.ok();
>> } catch (Exception e) {
>> return generateExceptionResponse(e); //Method that maps exceptions to
>> responses.
>> }
>> }
>>
>> For all of Java's clunkiness, this had the benefit of not having to write
>> tons of if/else statements for validation handling. Exception were just
>> thrown from anywhere, bubbling back up to inital call, and if not handled
>> in the endpoint method, a specialized class mapped them into a proper
>> response. The exceptions contained all the information needed to generate
>> 'rich' error messages back to the client.
>>
>> Being a Clojure newbie, I wonder what a good pattern is for a similar
>> situation. So far, I have a method that validates models based on a schema,
>> that returns
>>
>> {:success true}
>>
>> or
>>
>> {:success false :errors ["error 1" "error 2" ...]}
>>
>> But I don't know how to avoid having to write if/else conditions of the
>> sort in each function between my endpoint and db functions.
>>
>> (if (validation :success)
>> (follow-normal-path)
>> (handle-validation-errors validation))
>>
>>
>> Any guidance appreciated.
>>
>> Cheers,
>>
>> Julien
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: Beginners question - emacs & compiling tests
On Tue, Mar 19, 2013 at 3:02 PM, John D. Hume wrote: > It looks like you're missing (ns ...) forms at the top of each file. > That tutorial doesn't show them, but lein would have generated them > for you when it generated the project. The key element is that your > test file should have a (:use clojure.test) in the (ns) form, which is > what allows you to use clojure.test/deftest without > namespace-qualification. I had this same issue when working through the tutorial. The text makes it sound like you should replace the entire contents of the test file, but that's not the case -- you just need to replace the (deftest ...) form. (I ended up having to generate the project tree under a slightly different name to get a good copy of the file back.) good luck. j. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Exception propagation design in Clojure web APIs.
Hi I don't have much time to write a comprehensive answer, but if you want
to follow the control via exceptions route, there's nothing preventing you
from doing so.
You can (throw (ex-info msg map)), and then write a ring middle ware to
handle exceptions globally, for instance.
HTH,
Laurent
Hi all,
Coming from a Java background, I am having a hard time understanding how
validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches & formats the exceptions thrown by the db
method. **/
@POST("/api/user/create")
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions to
responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to write
tons of if/else statements for validation handling. Exception were just
thrown from anywhere, bubbling back up to inital call, and if not handled
in the endpoint method, a specialized class mapped them into a proper
response. The exceptions contained all the information needed to generate
'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors ["error 1" "error 2" ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
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: Exception propagation design in Clojure web APIs.
I'd argue that using exceptions for control flow is something of an
anti-pattern, even in Java.
In this case a better mechanism might be to use polymorphism. For instance:
(defprotocol Validatable
(validation-errors [x] "Return the validation errors for x."))
(defn valid? [x]
(empty? (validation-errors x)))
Then you can define a general function to validate and store that item in a
database:
(defn store-valid [db x]
(if (valid? x)
(store db x)
(validation-error-response x)))
- James
On 19 March 2013 16:43, Julien Dreux wrote:
> Hi all,
>
> Coming from a Java background, I am having a hard time understanding how
> validation error propagation should work in clojure web APIs.
>
> To be clear, this is similar to how my Java web service would be setup:
>
> /** Method that validates the model, accesses the DB. If something went
> wrong, throw an exception */
> public void validateAndCreateUser(User u) throws ValidationException,
> EmailAlreadyInUseException, ... {
> ...
> if(...) {
> throw new ValidationException(fieldName);
> } else if (...) {
> throw new EmailAlreadyInUseException(u.getEmail());
> }
> }
>
> /** Endpoint method, catches & formats the exceptions thrown by the db
> method. **/
> @POST("/api/user/create")
> public Response createUser (User u) {
> ..
> try{
> validateAndCreateUser(u);
> return Response.ok();
> } catch (Exception e) {
> return generateExceptionResponse(e); //Method that maps exceptions to
> responses.
> }
> }
>
> For all of Java's clunkiness, this had the benefit of not having to write
> tons of if/else statements for validation handling. Exception were just
> thrown from anywhere, bubbling back up to inital call, and if not handled
> in the endpoint method, a specialized class mapped them into a proper
> response. The exceptions contained all the information needed to generate
> 'rich' error messages back to the client.
>
> Being a Clojure newbie, I wonder what a good pattern is for a similar
> situation. So far, I have a method that validates models based on a schema,
> that returns
>
> {:success true}
>
> or
>
> {:success false :errors ["error 1" "error 2" ...]}
>
> But I don't know how to avoid having to write if/else conditions of the
> sort in each function between my endpoint and db functions.
>
> (if (validation :success)
> (follow-normal-path)
> (handle-validation-errors validation))
>
>
> Any guidance appreciated.
>
> Cheers,
>
> Julien
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure - CLR - JS - Visual Studio Extension
> > > I have made experiments with compiling ClojureScript to .NET code using the Microsoft.JScript JavaScript compiler and for a Hello World application it had a few hiccups in relation to compiling the Google closure-library (the use of future reserved keywords like "require" and "namespace" for variables/functions). I don't think getting ClojureScript to compile on the CLR it is insurmountable, but some work is needed. My end goal is to have core.logic accessible from .NET code, either by running the ClojureScript version on .NET or by porting it to Clojure CLR. If you would be wonderful if you would help. Cheers, Martin -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Beginners question - emacs & compiling tests
It looks like you're missing (ns ...) forms at the top of each file.
That tutorial doesn't show them, but lein would have generated them
for you when it generated the project. The key element is that your
test file should have a (:use clojure.test) in the (ns) form, which is
what allows you to use clojure.test/deftest without
namespace-qualification.
On Tue, Mar 19, 2013 at 2:12 PM, tyaakow wrote:
> I'm going through clojure & emacs tutorial from clojure-doc.org, and
> when compiling
> the test as suggested, i get following output in emacs nrepl:
>
>
> clojure.lang.Compiler$CompilerException:
> java.lang.RuntimeException: Unable to resolve symbol: deftest in this
> context, compiling:(/home/jakov/dev/PROJECTS/clojure/test2/test/test2/
> core_test.clj:1)
> Compiler.java:6281 clojure.lang.Compiler.analyze
> Compiler.java:6223 clojure.lang.Compiler.analyze
> Compiler.java:3497 clojure.lang.Compiler
> $InvokeExpr.parse
> Compiler.java:6457 clojure.lang.Compiler.analyzeSeq
> Compiler.java:6262 clojure.lang.Compiler.analyze
> Compiler.java:6223 clojure.lang.Compiler.analyze
> Compiler.java:6515 clojure.lang.Compiler.eval
> Compiler.java:6952 clojure.lang.Compiler.load
> Compiler.java:6912 clojure.lang.Compiler.loadFile
> RT.java:307 clojure.lang.RT$3.invoke
>NO_SOURCE_FILE:1 user/eval42
> Compiler.java:6511 clojure.lang.Compiler.eval
> Compiler.java:6477 clojure.lang.Compiler.eval
> core.clj:2797 clojure.core/eval
>main.clj:245 clojure.main/repl[fn]
>main.clj:266 clojure.main/repl[fn]
>main.clj:266 clojure.main/repl
>RestFn.java:1096 clojure.lang.RestFn.invoke
> interruptible_eval.clj:56
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>AFn.java:159 clojure.lang.AFn.applyToHelper
>AFn.java:151 clojure.lang.AFn.applyTo
>core.clj:601 clojure.core/apply
> core.clj:1771 clojure.core/with-bindings*
> RestFn.java:425 clojure.lang.RestFn.invoke
> interruptible_eval.clj:41
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:171
> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-
> eval[fn]
> core.clj:2278 clojure.core/comp[fn]
> interruptible_eval.clj:138
> clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
> AFn.java:24 clojure.lang.AFn.run
> ThreadPoolExecutor.java:895
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> ThreadPoolExecutor.java:918
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> Thread.java:662 java.lang.Thread.run
> Caused by: java.lang.RuntimeException: Unable to resolve symbol:
> deftest in this context
> Util.java:170 clojure.lang.Util.runtimeException
> Compiler.java:6766 clojure.lang.Compiler.resolveIn
> Compiler.java:6710 clojure.lang.Compiler.resolve
> Compiler.java:6671
> clojure.lang.Compiler.analyzeSymbol
> Compiler.java:6244 clojure.lang.Compiler.analyze
>
> To me, it seems like this line is crucial in the nrepl error output:
>
> Caused by: java.lang.RuntimeException: Unable to resolve symbol:
> deftest in this context
>
> Anyway, i am really a clojure & emacs noob, and I dont have much clue
> here.
> All the emacs slime clojure stuff is installed, `leiningen2` is
> installed, java is oracle java 1.6, emacs is emacs 24, and when I run
> lein test in projects directory, it goes without errors.
>
> Can anyone help me?
>
>
> My core_test.clj file:
>
> (deftest pairs-of-values
>(let [args ["--server" "localhost"
>"--port" "8080"
>"--environment" "production"]]
> (is (= {:server "localhost"
> :port "8080"
> :environment "production"}
> (parse-args args)
>
> My core.clj file:
>
> (defn parse-args [args]
> {})
>
> --
> --
> 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
Re: what are some stack sizes that people use?
That's hilarious :)
As I said, there's usually not much need to increase stack sizes..
On Tuesday, March 19, 2013 4:09:37 PM UTC+1, larry google groups wrote:
>
> Ah, I figured out at least part of what was happening. I have a web app,
> with Ring and Jetty and Compojure, and I have a form where people can
> upload images. The Ring has middleware that lets the uploaded images appear
> as a map with a pointer to a File:
>
> {:size 3874, :tempfile # /var/folders/kr/pgx6tzks6kg48hgdnj1f7dt8gn/T/ring-multipart-6398198897870847417.tmp>,
>
> :content-type "image/png", :filename "sponsored_by_pink.png"}{:size 0,
> :tempfile # /var/folders/kr/pgx6tzks6kg48hgdnj1f7dt8gn/T/ring-multipart-1255729774892979983.tmp>,
>
> :content-type "application/octet-stream", :filename ""}
>
> The map is then stored in a var called "interactions". I had another page
> where I took everything in "interactions" and gave it to cli-yaml and
> dumped that to the screen. Up till now I've been dealing with plain text
> that gets input via HTML forms, and there were no problems. But now, when I
> upload a file, and cli-yaml tries to serialize that, it runs into some
> understandable problems.
>
>
>
>
> On Monday, March 18, 2013 3:03:32 PM UTC-4, larry google groups wrote:
>>
>>
>> > Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit
>> JVMs on
>> > Linux (and Windows), and 1024kB for 64bit JVMs.
>>
>> Thank you for that. So I guess I could double those numbers and see if
>> that helps? -ss: 2048kb ?
>>
>>
>>
>>
>>
>>
>> On Monday, March 18, 2013 3:02:22 PM UTC-4, larry google groups wrote:
>>>
>>> > However, stack overflows are usually a good indication of problematic
>>> / faulty
>>> > recursive algorithms. Increasing the stacksize usually only alleviates
>>> some symptoms for
>>> > a bit. Increasing the stacksize is something that only rarely needs to
>>> be done, usually
>>> > when relying on an external library that has problems with stacksize.
>>> Always try
>>> > to troubleshoot code you can alter first.
>>>
>>>
>>> I appreciate that. Nothing change in my code except the amount of data
>>> in the var that was being given to clj-yaml. Possibly clj-yaml recurses too
>>> much.
>>>
>>>
>>>
>>>
>>>
>>> On Monday, March 18, 2013 1:05:00 PM UTC-4, Niels van Klaveren wrote:
Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit
JVMs on Linux (and Windows), and 1024kB for 64bit JVMs.
However, stack overflows are usually a good indication of problematic /
faulty recursive algorithms. Increasing the stacksize usually only
alleviates some symptoms for a bit. Increasing the stacksize is something
that only rarely needs to be done, usually when relying on an external
library that has problems with stacksize. Always try to troubleshoot code
you can alter first.
On Monday, March 18, 2013 4:15:00 PM UTC+1, larry google groups wrote:
>
>
> I am a noob when it comes to the JVM, and actually I find the JVM to
> be the hardest thing to learn about Clojure.
>
> Problem: I was trying to serialize some data to YAML. I had this
> working for awhile, but then I added more data and I started getting
> StackOverflow as an error. I then decided to just take a subset of my
> data,
> but even the subset will some day grow too large. I did some searches on
> Google and apparently I need to increase the stack size of my JVM.
> However,
> I have no idea what values are considered large or too-large.
>
> I have a project built with Leiningen. I have been reading up on jvm
> options, and so far, in my project.clj file, I have:
>
> :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])
>
> The stack size option is "-ss"? A large value would be... uh, what?
> 2000? 5000? 1? Should I do:
>
> :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss:
> 5000"])
>
> ?
>
>
>
>
>
--
--
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.
Beginners question - emacs & compiling tests
I'm going through clojure & emacs tutorial from clojure-doc.org, and
when compiling
the test as suggested, i get following output in emacs nrepl:
clojure.lang.Compiler$CompilerException:
java.lang.RuntimeException: Unable to resolve symbol: deftest in this
context, compiling:(/home/jakov/dev/PROJECTS/clojure/test2/test/test2/
core_test.clj:1)
Compiler.java:6281 clojure.lang.Compiler.analyze
Compiler.java:6223 clojure.lang.Compiler.analyze
Compiler.java:3497 clojure.lang.Compiler
$InvokeExpr.parse
Compiler.java:6457 clojure.lang.Compiler.analyzeSeq
Compiler.java:6262 clojure.lang.Compiler.analyze
Compiler.java:6223 clojure.lang.Compiler.analyze
Compiler.java:6515 clojure.lang.Compiler.eval
Compiler.java:6952 clojure.lang.Compiler.load
Compiler.java:6912 clojure.lang.Compiler.loadFile
RT.java:307 clojure.lang.RT$3.invoke
NO_SOURCE_FILE:1 user/eval42
Compiler.java:6511 clojure.lang.Compiler.eval
Compiler.java:6477 clojure.lang.Compiler.eval
core.clj:2797 clojure.core/eval
main.clj:245 clojure.main/repl[fn]
main.clj:266 clojure.main/repl[fn]
main.clj:266 clojure.main/repl
RestFn.java:1096 clojure.lang.RestFn.invoke
interruptible_eval.clj:56
clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
AFn.java:159 clojure.lang.AFn.applyToHelper
AFn.java:151 clojure.lang.AFn.applyTo
core.clj:601 clojure.core/apply
core.clj:1771 clojure.core/with-bindings*
RestFn.java:425 clojure.lang.RestFn.invoke
interruptible_eval.clj:41
clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:171
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-
eval[fn]
core.clj:2278 clojure.core/comp[fn]
interruptible_eval.clj:138
clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
AFn.java:24 clojure.lang.AFn.run
ThreadPoolExecutor.java:895
java.util.concurrent.ThreadPoolExecutor$Worker.runTask
ThreadPoolExecutor.java:918
java.util.concurrent.ThreadPoolExecutor$Worker.run
Thread.java:662 java.lang.Thread.run
Caused by: java.lang.RuntimeException: Unable to resolve symbol:
deftest in this context
Util.java:170 clojure.lang.Util.runtimeException
Compiler.java:6766 clojure.lang.Compiler.resolveIn
Compiler.java:6710 clojure.lang.Compiler.resolve
Compiler.java:6671
clojure.lang.Compiler.analyzeSymbol
Compiler.java:6244 clojure.lang.Compiler.analyze
To me, it seems like this line is crucial in the nrepl error output:
Caused by: java.lang.RuntimeException: Unable to resolve symbol:
deftest in this context
Anyway, i am really a clojure & emacs noob, and I dont have much clue
here.
All the emacs slime clojure stuff is installed, `leiningen2` is
installed, java is oracle java 1.6, emacs is emacs 24, and when I run
lein test in projects directory, it goes without errors.
Can anyone help me?
My core_test.clj file:
(deftest pairs-of-values
(let [args ["--server" "localhost"
"--port" "8080"
"--environment" "production"]]
(is (= {:server "localhost"
:port "8080"
:environment "production"}
(parse-args args)
My core.clj file:
(defn parse-args [args]
{})
--
--
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: nested map destructuring
nice one...when thinking like there is literally no confusion.
thank you thank you thank you :)
Jim
On 19/03/13 20:05, Marko Topolnik wrote:
Think of it in layers, like this---layer 1:
{w :weigths, u :uni-probs, b :bi-probs, t :tri-probs}
Then, instead of an atomic w, recursively substitute another
destructuring form, which will destructure the value of that w (which
is also a map). This form is {:keys [w1 w2 w3]}. That gives you
complete layer 2:
{{:keys [w1 w2 w3]} :weigths, u :uni-probs, b :bi-probs, t :tri-probs}
On Tuesday, March 19, 2013 8:58:43 PM UTC+1, Jim foo.bar wrote:
On 19/03/13 19:49, Marko Topolnik wrote:
> {{:keys [w1 w2 w3]} :weights}
awsome!...the full thing actually is {{:keys [w1 w2 w3]} :weights u
:uni-probs b :bi-probs t :tri-probs}
I always get confused when the order changes like that...thanks for
unblocking me Marko :)
Jim
--
--
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: nested map destructuring
Think of it in layers, like this---layer 1:
{w :weigths, u :uni-probs, b :bi-probs, t :tri-probs}
Then, instead of an atomic w, recursively substitute another destructuring
form, which will destructure the value of that w (which is also a map).
This form is {:keys [w1 w2 w3]}. That gives you complete layer 2:
{{:keys [w1 w2 w3]} :weigths, u :uni-probs, b :bi-probs, t :tri-probs}
On Tuesday, March 19, 2013 8:58:43 PM UTC+1, Jim foo.bar wrote:
>
> On 19/03/13 19:49, Marko Topolnik wrote:
> > {{:keys [w1 w2 w3]} :weights}
>
> awsome!...the full thing actually is {{:keys [w1 w2 w3]} :weights u
> :uni-probs b :bi-probs t :tri-probs}
>
> I always get confused when the order changes like that...thanks for
> unblocking me Marko :)
>
> Jim
>
>
>
--
--
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: nested map destructuring
On 19/03/13 19:49, Marko Topolnik wrote:
{{:keys [w1 w2 w3]} :weights}
awsome!...the full thing actually is {{:keys [w1 w2 w3]} :weights u
:uni-probs b :bi-probs t :tri-probs}
I always get confused when the order changes like that...thanks for
unblocking me Marko :)
Jim
--
--
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: nested map destructuring
On Tuesday, March 19, 2013 8:39:26 PM UTC+1, Jim foo.bar wrote:
>
> Hello all,
>
> can anyone help me destructure the following map in order to access
> directly w1 w2 & w3 ? I've been trying for 20 minutes now! (how useless
> am I? :( )
>
> {:weights {:w1 0.2 :w2 0.3 :w3 0.5}
> :uni-probs {...} :bi-probs {...} :tri-probs {...}}
>
{{:keys [w1 w2 w3]} :weights}
--
--
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.
nested map destructuring
Hello all,
can anyone help me destructure the following map in order to access
directly w1 w2 & w3 ? I've been trying for 20 minutes now! (how useless
am I? :( )
{:weights {:w1 0.2 :w2 0.3 :w3 0.5}
:uni-probs {...} :bi-probs {...} :tri-probs {...}}
thanks,
Jim
--
--
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: Metadata evaluation
Since there seems to be interest in the exact mechanics:
For every special form there exists a subclass of Expr in the clojure
compiler, which represents the special form in the analysis result. Every
such class directly implements the behavior of the special form in terms of
compiler infrastructure. Namely a method .eval to evaluate a
runtime-compiled form and a method .emit to emit its bytecode.
def is represented as DefExpr. It does evaluation of its meta data here
https://github.com/clojure/clojure/blob/c77e5bd87dfb6ca55612c842ec5ed80ff6319866/src/jvm/clojure/lang/Compiler.java#L412
and here
https://github.com/clojure/clojure/blob/c77e5bd87dfb6ca55612c842ec5ed80ff6319866/src/jvm/clojure/lang/Compiler.java#L439
for regular operation and AOT respectively.
So there is something special about def (it's a special form, not a macro)
For the case of (meta ^{:foo "bar"} ["a" "vec"]) look up MetaExpr in the
compiler. That seems to be how values carrying metadata are handled.
hope that clears everything up
--
--
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.
Exception propagation design in Clojure web APIs.
Hi all,
Coming from a Java background, I am having a hard time understanding how
validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches & formats the exceptions thrown by the db
method. **/
@POST("/api/user/create")
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions to
responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to write
tons of if/else statements for validation handling. Exception were just
thrown from anywhere, bubbling back up to inital call, and if not handled
in the endpoint method, a specialized class mapped them into a proper
response. The exceptions contained all the information needed to generate
'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors ["error 1" "error 2" ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
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: Metadata evaluation
Ummm... Jean, I don't understand.
Recapitulation. As Herwig showed, the symbol has its metadata WITHOUT
evaluation:
user=> (meta (second (read-string "(def ^{:key (+ 1 1)} foo)")))
{:key (+ 1 1)}
"second", in the above expression, retrieves the symbol "foo", and reader
already set its metadata WITHOUT evaluation.
AFAIK, def is an special form (a built-in one? not a defined macro?), so,
it receives the symbol, foo, as is, without evaluating it, nor its
metadata, nothing more. No lisp evaluator yet.
Something inside def work, ACTIVELY get the symbol metadata, AND EVALUATES
it, and assign it to the var the def is defining. AFAIK, getting the
metadata of something, doesn't imply automatically its evaluation, as
Herwig example shows us.
This interpretation is aligned with:
http://clojure.org/special_forms
Any metadata on the symbol will be evaluated, and become metadata on the
var itself
that explicitly asserts that some evaluation will be conducted.
Am I right?
Angel "defandmetadata" Lopez :-)
On Tue, Mar 19, 2013 at 12:16 PM, Jean Niklas L'orange <
jeann...@hypirion.com> wrote:
>
>
> On Tuesday, March 19, 2013 11:49:45 AM UTC+1, ajlopez wrote:
>>
>> Thanks Jean!
>>
>> Yes, I did that test before my email.
>>
>> But my doubt is:
>>
>> What part is in charge of metadata evaluation?
>>
>
> As Herwig commented: The part which evaluates metadata is without doubt
> the lisp evaluator's work, the def macro does nothing magical here.
>
> A simple test to ensure that follows:
> (meta ^{:a (+ 1 1)} [:a :b])
> ;=> {:a 2}
>
> --
> --
> 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: Midje 1.5 released
On Mar 19, 2013, at 7:19 AM, Murtaza Husain wrote: > Brain I would also like to use it to test my cljs code, is that possible ? If https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure is up to date, it would be moderately hard and tedious to port Midje to Clojurescript. Does clojure.test work with Clojurescript? If I end up not taking a Real Job, I've been toying with writing a book that uses TDDing up a Midje-alike as its running example. Perhaps that should be done in Clojurescript. The (apparent) second-class status of macros might make that too painful for the reader / exercise-doer, though. Looking for employment as a Clojure programmer Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- 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: conflict using midje repl-tools
On Mar 19, 2013, at 8:47 AM, Murtaza Husain wrote: > I am having trouble using midje repl-tools. I am using the facts intermingled > in my source code. Can you give a transcript of the failure? I can't reproduce the problem. I have a project with this source: > (ns scratch.core > (:use scratch.core2) > (:use midje.sweet)) > > (defn core [] 88) > > (fact (+ (core) (core2)) => "this shows a failure") Here's what happens: > 638 $ lein repl > user=> (use 'scratch.core) > Run `(doc midje)` for Midje usage. > > FAIL at (core.clj:5) > Expected: "this shows a failure" > Actual: 121 > nil > user=> (use 'midje.repl) > Run `(doc midje-repl)` for descriptions of Midje repl functions. > nil > user=> (autotest) > > == > Loading (scratch.core2 scratch.core) > "core 2" > > FAIL at (core.clj:5) > Expected: "this shows a failure" > Actual: 121 > FAILURE: 1 check failed. > true > user=> Looking for employment as a Clojure programmer Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: Kern 0.6.1, a text-parsing library
I've pushed to Clojars the release 0.6.1 of Kern, a text-parsing library, with some fixes and enhancements. https://github.com/blancas/kern There's updated Codox API docs and a change log. Documentation and samples: https://github.com/blancas/kern/wiki For feedback, bug reports, etc.: https://github.com/blancas/kern/issues?state=open -- -- 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: Metadata evaluation
On Tuesday, March 19, 2013 11:49:45 AM UTC+1, ajlopez wrote:
>
> Thanks Jean!
>
> Yes, I did that test before my email.
>
> But my doubt is:
>
> What part is in charge of metadata evaluation?
>
As Herwig commented: The part which evaluates metadata is without doubt the
lisp evaluator's work, the def macro does nothing magical here.
A simple test to ensure that follows:
(meta ^{:a (+ 1 1)} [:a :b])
;=> {:a 2}
--
--
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: what are some stack sizes that people use?
Ah, I figured out at least part of what was happening. I have a web app,
with Ring and Jetty and Compojure, and I have a form where people can
upload images. The Ring has middleware that lets the uploaded images appear
as a map with a pointer to a File:
{:size 3874, :tempfile #,
:content-type "image/png", :filename "sponsored_by_pink.png"}{:size 0,
:tempfile #,
:content-type "application/octet-stream", :filename ""}
The map is then stored in a var called "interactions". I had another page
where I took everything in "interactions" and gave it to cli-yaml and
dumped that to the screen. Up till now I've been dealing with plain text
that gets input via HTML forms, and there were no problems. But now, when I
upload a file, and cli-yaml tries to serialize that, it runs into some
understandable problems.
On Monday, March 18, 2013 3:03:32 PM UTC-4, larry google groups wrote:
>
>
> > Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit
> JVMs on
> > Linux (and Windows), and 1024kB for 64bit JVMs.
>
> Thank you for that. So I guess I could double those numbers and see if
> that helps? -ss: 2048kb ?
>
>
>
>
>
>
> On Monday, March 18, 2013 3:02:22 PM UTC-4, larry google groups wrote:
>>
>> > However, stack overflows are usually a good indication of problematic /
>> faulty
>> > recursive algorithms. Increasing the stacksize usually only alleviates
>> some symptoms for
>> > a bit. Increasing the stacksize is something that only rarely needs to
>> be done, usually
>> > when relying on an external library that has problems with stacksize.
>> Always try
>> > to troubleshoot code you can alter first.
>>
>>
>> I appreciate that. Nothing change in my code except the amount of data in
>> the var that was being given to clj-yaml. Possibly clj-yaml recurses too
>> much.
>>
>>
>>
>>
>>
>> On Monday, March 18, 2013 1:05:00 PM UTC-4, Niels van Klaveren wrote:
>>>
>>> Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit
>>> JVMs on Linux (and Windows), and 1024kB for 64bit JVMs.
>>>
>>> However, stack overflows are usually a good indication of problematic /
>>> faulty recursive algorithms. Increasing the stacksize usually only
>>> alleviates some symptoms for a bit. Increasing the stacksize is something
>>> that only rarely needs to be done, usually when relying on an external
>>> library that has problems with stacksize. Always try to troubleshoot code
>>> you can alter first.
>>>
>>> On Monday, March 18, 2013 4:15:00 PM UTC+1, larry google groups wrote:
I am a noob when it comes to the JVM, and actually I find the JVM to be
the hardest thing to learn about Clojure.
Problem: I was trying to serialize some data to YAML. I had this
working for awhile, but then I added more data and I started getting
StackOverflow as an error. I then decided to just take a subset of my
data,
but even the subset will some day grow too large. I did some searches on
Google and apparently I need to increase the stack size of my JVM.
However,
I have no idea what values are considered large or too-large.
I have a project built with Leiningen. I have been reading up on jvm
options, and so far, in my project.clj file, I have:
:jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])
The stack size option is "-ss"? A large value would be... uh, what?
2000? 5000? 1? Should I do:
:jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss:
5000"])
?
--
--
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.
conflict using midje repl-tools
Hi, I am having trouble using midje repl-tools. I am using the facts intermingled in my source code. In my source file abc/core.clj file, I have included (:use [midje.sweet]). After I start my repl, when I type this - (use 'midje.repl), I get the following error - IllegalStateException => already refers to: #'midje.sweet/=> in namespace: abc.core So how do I intermingle facts in my src (not test/src) as well as use repl-tools (ex autotest) from the repl ? Thanks, Murtaza -- -- 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: Understanding vars
I remember finding out about it a few months ago. I don't know whether or not there is a jira ticket for it, I'll check out. If nobody can get a patch for this, I'll try and see if I can work out one in the next days Il giorno 19/mar/2013 09.02, "Mark Engelberg" ha scritto: > On Tue, Mar 19, 2013 at 12:57 AM, Bronsa wrote: > >> If I remember correctly, this is a bug due to the fact that constant >> empty literals are handled in a special way from the compiler. >> >> > Interesting. I see you are correct that the problem only occurs on > metadata attached to an empty literal. So does that mean this is a known > bug? > > -- > -- > 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: Midje 1.5 released
Brian thanks for the effort, its a wonderful framework ! Brain I would also like to use it to test my cljs code, is that possible ? On Tuesday, March 19, 2013 8:22:12 AM UTC+5:30, Evan Mezeske wrote: > > Thanks for your continued work on this, Brian. I can't wait to upgrade! > > On Monday, March 18, 2013 10:36:57 AM UTC-7, Brian Marick wrote: >> >> Midje is a test framework for Clojure that aims to be more readable than >> clojure.test and to allow styles of testing that clojure.test does not. >> >> 1.5 is the Enterprise Edition and Respect the Repl Release. >> >> Enterprise (integration with build servers) >> * Configuration files >> * Tests can be selected using their metadata >> * Plugin interface for customizing reporting >> >> Respect the Repl: >> * Although `lein midje` still works, the emphasis for non-batch >> use is on a set of repl tools. For example, you can autotest >> inside the repl, which is surprisingly better than running it at >> the command line. (You get both automatic rechecking of tests >> whose dependencies change and all the convenience of the repl >> prompt.) >> * There's a lot of in-repl documentation. For example, >> `(doc midje-repl)` brings up a list of the names, brief >> summaries, and common uses of all the repl tools. >> * Reporting of user errors is improved. (Some errors that >> previously produced confusing "I blew up" messages from Clojure >> now have their own checks that yield less confusing messages.) >> >> The user guide has been largely rewritten. >> >> https://github.com/marick/Midje >> >> User guide, including two tutorials (one specifically for clojure.test >> users): https://github.com/marick/Midje/wiki >> >> Change list: >> https://github.com/marick/Midje/wiki/What%27s-new-in-midje-1.5 >> >> >> Looking for employment as a Clojure programmer >> Latest book: /Functional Programming for the Object-Oriented Programmer/ >> https://leanpub.com/fp-oo >> >> -- -- 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: Immutant and ClojureScript
So, is that a bug in ClojureScript? > Does anybody have an idea for a workaround (I have little experience with > all of this, including classloaders)? > > > Stacktrace: > 23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1) Exception: > java.lang.IllegalArgumentException: No matching method found: findResources > for class org.immutant.core.ImmutantClassLoader > 23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1) >Reflector.java:53 clojure.lang.Reflector.invokeMatchingMethod > 23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1) >Reflector.java:28 clojure.lang.Reflector.invokeInstanceMethod > 23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1) > closure.clj:849 cljs.closure/get-upstream-deps* > I ran into this same error in another environment with a custom classloader. It seems to be related to Clojure's default classloader extending from URLClassLoader which has a public findResources method. The custom classloader in my case was extending the default Java ClassLoader (where the findResources method is protected). Changing the findResources in ImmutantClassLoader to public should fix it. -- -- 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: Metadata evaluation
The evaluation of meta data happens when the def form is evaluated:
user=> (meta (second (read-string "(def ^{:key (+ 1 1)} foo)")))
{:key (+ 1 1)}
vis a vis
user=> (meta (eval (read-string "(def ^{:key (+ 1 1)} foo)")))
{:ns #, :name foo, :file "NO_SOURCE_PATH", :line 1, :key 2}
The reader doesn't interact with the runtime, except for resolving the
current namespace in backtick `forms and and for reader tags and related
mechanisms.
A little experiment in clojure 1.5.1 showed, that during AOT compilation,
the meta data gets evaluated twice, but it is still evaluated when
require'ing the resulting class files.
2013/3/19 Angel Java Lopez
> Thanks Jean!
>
> Yes, I did that test before my email.
>
> But my doubt is:
>
> What part is in charge of metadata evaluation?
>
> From such test, I can't deduce if the metadata evaluation is made by the
> reader, or by the macro def.
>
> If the metadata evaluation is made by the reader, the symbol two will have
> {:a 2} as metadata, and then, the macro def get the metadata from the
> symbol and assign the var the def macro is defining.
>
> But the online docs maybe describe other way:
>
> "Any metadata on the symbol will be evaluated, and become metadata on the
> var itself."
>
> That is, the metadata ALREADY in symbol, is then EVALUATED by def special
> form.
>
> My context: I'm writing an interpreter of Clojure, in C#, to practice TDD,
> with behavior based on published doc, or core.clj, I'm not sure what is the
> expected behavior of the reader, metadata and special form.
>
> Maybe, the two options I described in my first email, are EQUIVALENT for
> all practical purpose, but I have the doubt, and I don't know how to write
> a clojure code that helps me to discover the current behavior
>
> Angel "Java" Lopez
> @ajlopez
>
> On Tue, Mar 19, 2013 at 7:35 AM, Jean Niklas L'orange <
> jeann...@hypirion.com> wrote:
>
>>
>>
>> On Tuesday, March 19, 2013 9:49:09 AM UTC+1, ajlopez wrote:
>>>
>>> Hi everyone!
>>
>>
>> Hi!
>>
>> The easiest thing to find out of this would be to check it out:
>>
>> (def ^{:a (+ 1 1)} two 2)
>> ;=> user/two
>> (meta #'two)
>> ;=> { :a 2}
>>
>> So indeed, the forms within metadata is evaluated.
>>
>> -- Jean Niklas L'orange
>>
>> --
>> --
>> 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: Metadata evaluation
On Tuesday, March 19, 2013 9:49:09 AM UTC+1, ajlopez wrote:
>
> Hi everyone!
Hi!
The easiest thing to find out of this would be to check it out:
(def ^{:a (+ 1 1)} two 2)
;=> user/two
(meta #'two)
;=> { :a 2}
So indeed, the forms within metadata is evaluated.
-- Jean Niklas L'orange
--
--
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: Understanding vars
On Tue, Mar 19, 2013 at 12:57 AM, Bronsa wrote: > If I remember correctly, this is a bug due to the fact that constant empty > literals are handled in a special way from the compiler. > > Interesting. I see you are correct that the problem only occurs on metadata attached to an empty literal. So does that mean this is a known bug? -- -- 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: Understanding vars
Indeed:
(def ecr (with-meta [1] {:amazing true}))
(def ^:const c ecr)
(meta ecr) -> {:amazing true}
(meta c) -> {:amazing true}
On Tuesday, March 19, 2013 8:57:28 AM UTC+1, Nicola Mometto wrote:
>
> If I remember correctly, this is a bug due to the fact that constant empty
> literals are handled in a special way from the compiler.
> Il giorno 19/mar/2013 08.49, "Marko Topolnik"
> >
> ha scritto:
>
>> The way speed is achieved for :const is that it is given the same
>>> treatment as Java's *compile-time constants*, so you're not even
>>> touching the var when you refer to it by name. Now, *meta* could be
>>> accepted as a special case, explicitly detected by the compiler, but that
>>> mechanism would once again be easily defeated. So I'd say it's not a bug,
>>> but a case of *you can't have your cake and eat it, too.*
>>>
>>
>> On second thought, I my be wrong since the meta is not on the var, but on
>> the map object itself. Maybe it really is just a bug due to which the
>> compiled-in value doesn't have metadata copied to it.
>>
>> -marko
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: contrib.monads doesn't compile?
--On 18 mars 2013 19:32:57 + "Jim - FooBar();" wrote: I just hit this and I thought I'd share... 2 min ago I specified clojure-contrib 1.2.0 as a dependency only to use 2 functions from the probabilities namespace. However that namepsace depends on the contrib.monads namespace which immediately throw this compiler error : The replacement for contrib.monads is algo.monads from the new modular clojure-contrib library. As for the probability namespace, it's not in the new contrib library, so you have to grab the source code for now. I'd be happy to migrate it as well, but it's not so clear where it should go. I could add it to algo.monads, but that's not really where I'd expect to find probability stuff. Konrad. -- -- 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: Understanding vars
If I remember correctly, this is a bug due to the fact that constant empty literals are handled in a special way from the compiler. Il giorno 19/mar/2013 08.49, "Marko Topolnik" ha scritto: > The way speed is achieved for :const is that it is given the same >> treatment as Java's *compile-time constants*, so you're not even >> touching the var when you refer to it by name. Now, *meta* could be >> accepted as a special case, explicitly detected by the compiler, but that >> mechanism would once again be easily defeated. So I'd say it's not a bug, >> but a case of *you can't have your cake and eat it, too.* >> > > On second thought, I my be wrong since the meta is not on the var, but on > the map object itself. Maybe it really is just a bug due to which the > compiled-in value doesn't have metadata copied to it. > > -marko > > > -- > -- > 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: Understanding vars
> > The way speed is achieved for :const is that it is given the same > treatment as Java's *compile-time constants*, so you're not even touching > the var when you refer to it by name. Now, *meta* could be accepted as a > special case, explicitly detected by the compiler, but that mechanism would > once again be easily defeated. So I'd say it's not a bug, but a case of *you > can't have your cake and eat it, too.* > On second thought, I my be wrong since the meta is not on the var, but on the map object itself. Maybe it really is just a bug due to which the compiled-in value doesn't have metadata copied to it. -marko -- -- 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: Understanding vars
On Tuesday, March 19, 2013 4:41:33 AM UTC+1, puzzler wrote:
> On Mon, Mar 18, 2013 at 8:31 PM, Kemar >wrote:
>
>> Explicitly derefing the var and calling meta on it works:
>>
>> (meta @#'c) -> {:amazing true}
>>
>> No idea as to why though...
>>
>
> Quirky. I assume that explicitly derefing the var defeats the speed
> benefits of ^:const, yes?
>
The way speed is achieved for :const is that it is given the same treatment
as Java's *compile-time constants*, so you're not even touching the var
when you refer to it by name. Now, *meta* could be accepted as a special
case, explicitly detected by the compiler, but that mechanism would once
again be easily defeated. So I'd say it's not a bug, but a case of *you
can't have your cake and eat it, too.*
*
*
-marko
--
--
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.
