Re: Refactoring tools

[Akhil Wali]

A fairly new project for refactoring Clojure is clj-refactor.el.
Not too much functionality yet, but supplements clojure-refactoring pretty
well.
clj-refactor.el will later interop with nRepl, or that's the plan I heard.

That aside (and I know I'm being redundant), refactoring any Lisp is a snap
with paredit-mode.
It doesn't do stuff like renaming a function or exracting a var, but I've
had some success in making these operations as interactive functions.



On Thu, Mar 21, 2013 at 8:11 AM, Devin Walters  wrote:

> Yeah it sort of bums me out that clojure-refactoring has been in the ditch.
>
> There are a number of tasks to get this back into a good state. The plan
> right now is to take tests (which were mostly failing and using outdated
> dependencies) from the old-test directory and get them passing under Midje.
> Then, get it to play nicely with nrepl and update any elisp that needs
> updating to bring back the clojure-refactoring minor mode.
>
> If anyone wants to help resurrect this project:
> https://github.com/devn/clojure-refactoring/tree/clojure-1.5 your help
> would be appreciated. I created a new branch and started bringing old
> failing tests over. Feel free to drop me a pull request. Big, sweeping
> commits and tiny typo commits are both equally welcome.
>
> On Wednesday, March 20, 2013 at 8:22 PM, Dave Kincaid wrote:
>
> Thanks. It looks like nothing has happened on that in a year and it
> appears to require slime/swank. But it's a start I guess if there isn't
> anything else.
>
> On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) wrote:
>
>  I don't think much has happened with it recently, but I used to use
> https://github.com/joodie/**clojure-refactoring
> .
>
> --
> '(Devin Walters)
> Sent from my Motorola RAZR V3 (Matte Black)
>
> On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote:
>
> I'm wondering if there are any refactoring tools around for working with
> Clojure projects in Emacs. There seems to be all kinds of other tools
> except for refactoring. I'm really looking for simple things like ways to
> easily rename variables, functions, namespaces, etc. That seems to be the
> most common thing I'm trying to do. Are there any tools out there to make
> it easier?
>
> Thanks,
>
> Dave
>
> --
> --
> 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.
>
>
>
>
>  --
> --
> 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.
>
>
>



-- 
Akhil Wali

# http://github.com/darth10 
# http://darth10.github.com

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from t

ClassNotFoundException when using fetch RPC from cljs

[Steve Buikhuizen]

I'm building a single-page app ( started before Pedestal was announced 
sadly ) and I'm using the fetch library to support RPC from client -> JVM 
server.

I'm seeing a very strange behaviour. I've defined a view-model ns (full of 
defrecords) for the client data. This has worked well - the client can read 
and write records over the wire.

Except there's one situation where it does not work. If the client sends a 
record to the server and the server has not previously sent at least one 
instance of that defrecord type to the client then I see a 
ClassNotFoundException. As soon as I read one instance from the server 
(using fetch) then the problem goes away.

This means that the first users of new JVMs will experience this error - 
not great for elastic computing.

I've tried:
1/ aot compiling the namespace
2/ reading and writing dummy view-model instances in the namespace on load
3/ importing and requiring all classes in the ns where I to the read-string

None of these seem to work.

Does anybody have an understanding of the read-string class-loading 
behaviour that would explain this? Any suggestion would be much appreciated.

Steve

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Refactoring tools

[Devin Walters]

Yeah it sort of bums me out that clojure-refactoring has been in the ditch.

There are a number of tasks to get this back into a good state. The plan right 
now is to take tests (which were mostly failing and using outdated 
dependencies) from the old-test directory and get them passing under Midje. 
Then, get it to play nicely with nrepl and update any elisp that needs updating 
to bring back the clojure-refactoring minor mode.

If anyone wants to help resurrect this project: 
https://github.com/devn/clojure-refactoring/tree/clojure-1.5 your help would be 
appreciated. I created a new branch and started bringing old failing tests 
over. Feel free to drop me a pull request. Big, sweeping commits and tiny typo 
commits are both equally welcome. 

On Wednesday, March 20, 2013 at 8:22 PM, Dave Kincaid wrote:

> Thanks. It looks like nothing has happened on that in a year and it appears 
> to require slime/swank. But it's a start I guess if there isn't anything else.
> 
> On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) wrote:
> > I don't think much has happened with it recently, but I used to use 
> > https://github.com/joodie/clojure-refactoring.
> > 
> > -- 
> > '(Devin Walters)
> > Sent from my Motorola RAZR V3 (Matte Black)
> > 
> > 
> > On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote:
> > 
> > > I'm wondering if there are any refactoring tools around for working with 
> > > Clojure projects in Emacs. There seems to be all kinds of other tools 
> > > except for refactoring. I'm really looking for simple things like ways to 
> > > easily rename variables, functions, namespaces, etc. That seems to be the 
> > > most common thing I'm trying to do. Are there any tools out there to make 
> > > it easier?
> > > 
> > > Thanks,
> > > 
> > > Dave 
> > > 
> > > -- 
> > > -- 
> > > 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 (javascript:)
> > > Note that posts from new members are moderated - please be patient with 
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+u...@googlegroups.com (javascript:)
> > > For more options, visit this group at
> > > http://groups.google.com/group/clojure?hl=en
> > > --- 
> > > You received this message because you are subscribed to the Google Groups 
> > > "Clojure" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to clojure+u...@googlegroups.com (javascript:).
> > > For more options, visit https://groups.google.com/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 
> (mailto: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 
> (mailto: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 
> (mailto: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: Refactoring tools

[Dave Kincaid]

Thanks. It looks like nothing has happened on that in a year and it appears 
to require slime/swank. But it's a start I guess if there isn't anything 
else.

On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) wrote:
>
>  I don't think much has happened with it recently, but I used to use 
> https://github.com/joodie/clojure-refactoring.
>
> -- 
> '(Devin Walters)
> Sent from my Motorola RAZR V3 (Matte Black)
>
> On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote:
>
> I'm wondering if there are any refactoring tools around for working with 
> Clojure projects in Emacs. There seems to be all kinds of other tools 
> except for refactoring. I'm really looking for simple things like ways to 
> easily rename variables, functions, namespaces, etc. That seems to be the 
> most common thing I'm trying to do. Are there any tools out there to make 
> it easier?
>
> Thanks,
>
> Dave
>
> -- 
> -- 
> 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: Refactoring tools

[Devin Walters]

I don't think much has happened with it recently, but I used to use 
https://github.com/joodie/clojure-refactoring.

-- 
'(Devin Walters)
Sent from my Motorola RAZR V3 (Matte Black)


On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote:

> I'm wondering if there are any refactoring tools around for working with 
> Clojure projects in Emacs. There seems to be all kinds of other tools except 
> for refactoring. I'm really looking for simple things like ways to easily 
> rename variables, functions, namespaces, etc. That seems to be the most 
> common thing I'm trying to do. Are there any tools out there to make it 
> easier?
> 
> Thanks,
> 
> Dave 
> 
> -- 
> -- 
> 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 
> (mailto: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 
> (mailto: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 
> (mailto: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.

Refactoring tools

[Dave Kincaid]

I'm wondering if there are any refactoring tools around for working with 
Clojure projects in Emacs. There seems to be all kinds of other tools 
except for refactoring. I'm really looking for simple things like ways to 
easily rename variables, functions, namespaces, etc. That seems to be the 
most common thing I'm trying to do. Are there any tools out there to make 
it easier?

Thanks,

Dave

-- 
-- 
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 Monger 1.5.0-rc1

[Michael Klishin]

Monger [1] is a Clojure MongoDB driver for a more civilized age: easy to
use, documented,
fast and with batteries included.

Release notes:
http://blog.clojurewerkz.org/blog/2013/03/21/monger-1-dot-5-0-rc1-is-released/

1. http://clojuremongodb.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: Simulant, a library for simulation testing

[Stuart Halloway]

Wiki/repo:   https://github.com/Datomic/simulant/wiki
Clojars:   https://clojars.org/com.datomic/simulant
Presentations:
https://github.com/stuarthalloway/presentations/wiki/Simulation-Testing

Enjoy!

Stu

-- 
-- 
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.

[James Reeves]

On 20 March 2013 16:41, Marko Topolnik  wrote:

> On Wednesday, March 20, 2013 4:34:32 PM UTC+1, James Reeves wrote:
>
>>
>> If validation happens "all around", that implies there is no one function
>> that can test whether a value of data is valid for a given data store. This
>> strikes me as a somewhat shaky foundation for a system.
>>
>
> The idea is that all validation functions share the same contract to call
> the appropriate *add-failure* function that registers the validation
> result.
>

I don't see why that would be necessary. Why not put all the validation
logic in one place?


>  There may be instances where it makes sense to use exceptions as a
>> control flow mechanism, but I wonder whether it wouldn't be better to use
>> something like CPS in those instances.
>>
>
> I can't picture how such a mechanism would work, and what benefit it would
> bring over the exceptions mechanism. CPS in Clojure means trampolining,
> which is quite an unwieldy, and I'd say "cheap" tack-on. A validating
> function would then be supposed to return a common, globally-defined
> "continuation", in fact just a simple function, that would redirect the
> flow towards the validation failure-handling case.
>

I wasn't thinking of validation when I suggested CPS, because I don't see a
need for any unusual control flow when validating data.

- James

-- 
-- 
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: naming your project "clojure" with "lein new clojure" gives problems

[Michael Klishin]

2013/3/21 Kẏra 

> This is definitely a bug. I just ran into this problem and was not able to
> decipher the error messages, and digging up this thread wasn't too easy
> either.


It was improved in Leiningen 2.1: it refuses to create projects named
"clojure" and only use *jure names if
you force it with an ENV variable.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: naming your project "clojure" with "lein new clojure" gives problems

[Kẏra]

This is definitely a bug. I just ran into this problem and was not able to 
decipher the error messages, and digging up this thread wasn't too easy 
either. 

On Friday, April 27, 2012 2:17:56 AM UTC-4, Sean Neilan wrote:
>
> I agree. That would be helpful.
>
> On Fri, Apr 27, 2012 at 1:12 AM, Sean Corfield 
> 
> > wrote:
>
>> It used to be that lein new would not allow you to create projects
>> with "jure" in the name. I guess that restriction has disappeared,
>> which is unfortunate since it would have prevented the problem you ran
>> into...
>>
>> On Thu, Apr 26, 2012 at 10:57 PM, Sean Neilan 
>> > 
>> wrote:
>> > Hello Lisperati,
>> >
>> > Naming your project "clojure" is a bad idea because doing
>> > seans-macaroni-book:BigNumberNames seanneilan$ lein  new clojure
>> > Created new project in:
>> > /Users/seanneilan/BucketsOfNantucket/BigNumberNames/clojure
>> > Look over project.clj and start coding in clojure/core.clj
>> > seans-macaroni-book:BigNumberNames seanneilan$ cd clojure
>> > will give you problems...
>> > seans-macaroni-book:clojure seanneilan$ lein repl
>> > Copying 1 file to
>> > /Users/seanneilan/BucketsOfNantucket/BigNumberNames/clojure/lib
>> > Exception in thread "main" java.lang.ExceptionInInitializerError
>> >  at clojure.main.(main.java:20)
>> > Caused by: java.lang.IllegalStateException: Attempting to call unbound 
>> fn:
>> > #'clojure.core/refer
>> >  at clojure.lang.Var$Unbound.throwArity(Var.java:43)
>> >  at clojure.lang.AFn.invoke(AFn.java:39)
>> >  at clojure.lang.Var.invoke(Var.java:401)
>> >  at clojure.lang.RT.doInit(RT.java:447)
>> >  at clojure.lang.RT.(RT.java:316)
>> >  ... 1 more
>>
>> --
>> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Morph 0.2.0, state+error-handling with pure functions

[Ben Wolfson]

On Wed, Mar 20, 2013 at 1:16 PM, coltnz  wrote:
> So thats at least four clojure monad libraries I know of. This one,
> https://github.com/bwo/monads, https://github.com/jduey/protocol-monads and
> the original (?) https://github.com/clojure/algo.monads.
>
> Anyone care to comment on the differences beyond use of protocols or not?
> Pick me a winner...

I'm going to actually "officially" announce the second one listed
soonish and will have some comments on approach, differences, etc.
then.

One thing that I think is worth pointing out is that both morph and
algo.monads violate the monad laws occasionally: morph does for both
Either and Maybe, and algo.monads does for Maybe.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: nested map destructuring

[John D. Hume]

On Tue, Mar 19, 2013 at 2:58 PM, Jim - FooBar();  wrote:
> awsome!...the full thing actually is {{:keys [w1 w2 w3]} :weights u
> :uni-probs b :bi-probs t :tri-probs}

You might also consider
{:keys [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.

Re: Wrong clojure version depending on lein dependencies (was: ANN: Clojure 1.5)

[Nelson Morris]

In lein 2.1 using `lein deps :tree` will print out any version ranges
it finds. Hopefully this helps with when noticing similar dependency
issues.

On Sat, Mar 2, 2013 at 5:42 PM, Nelson Morris  wrote:
> On Sat, Mar 2, 2013 at 4:17 PM, Frank Siebenlist
>  wrote:
>>> ...
>>> The chain causing problems for you is:
>>>
>>> [clj-ns-browser "1.3.0"] -> [seesaw "1.4.2"] -> [j18n "1.0.1"] ->
>>> [org.clojure/clojure "[1.2,1.5)"]
>>>
>>> The last one there allows clojure below 1.5, which includes -RC17.  As
>>> soon as you bump to to 1.5 it ignores the "soft" version in your
>>> :dependencies, and chooses one in the range based on your other
>>> dependencies.
>>>
>>> You should just need the :exclusion in clj-ns-browser.
>>>
>>> -
>>> Nelson Morris
>>
>> As i'm responsible for the clj-ns-browser release...
>> And although the dependency issue seems another 2 levels down, can i specify 
>> anything differently in my project file to prevent this?
>
> You could add the a similar exclusion for org.clojure/clojure in the
> seesaw dependency declaration, but I'd just wait for the next seesaw
> release which will handle it.
>
>>
>> Or is this a bug in leiningen's dependency resolution?
>>
>
> Unfortunately it's behaviour defined by maven.  In order to be
> compatible lein has to do the same thing.
>
> I've written up a few things about version ranges at
> http://nelsonmorris.net/2012/07/31/do-not-use-version-ranges-in-project-clj.html
> and in some other mailing list threads.  The confusion about what can
> happen with dependencies led me to make
> https://github.com/xeqi/lein-pedantic, which is helpful for some
> cases.  In addition, I hope to get some easier debugging for this case
> into lein itself; issues at:
> https://github.com/technomancy/leiningen/issues/734 and
> https://github.com/cemerick/pomegranate/issues/54

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Morph 0.2.0, state+error-handling with pure functions

[coltnz]

So thats at least four clojure monad libraries I know of. This 
one, https://github.com/bwo/monads, 
https://github.com/jduey/protocol-monads and the original 
(?) https://github.com/clojure/algo.monads.

Anyone care to comment on the differences beyond use of protocols or not? 
Pick me a winner...

cheers
Colin


On Thursday, March 21, 2013 5:25:19 AM UTC+13, Armando Blancas wrote:
>
> Release 0.2.0 of the Morph library comes with a couple of fixes and some 
> enhancements:
>
> https://github.com/blancas/morph
>
> Safe error-handling with non-global, shared data is now even easier:
> https://github.com/blancas/morph/wiki/Simpler-State-with-Error-Handling
>
> Documentation and samples: https://github.com/blancas/morph/wiki
> The docs include a Codox API Reference and a change log.
> For feedback, bug reports, etc.: 
> https://github.com/blancas/morph/issues?page=1&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: Exception propagation design in Clojure web APIs.

[Cedric Greevey]

It will if you use set! to update the binding.


On Wed, Mar 20, 2013 at 1:00 PM, Marko Topolnik wrote:

> On Wednesday, March 20, 2013 5:51:59 PM UTC+1, Julien Dreux wrote:
>
>> Thank you all for your answers,
>>
>> I like Marko's approach.
>>
>> What I had in mind, related to OP's post, would be a middleware that does
>>> (binding [*validation-failures* []]
>>>(handler req)
>>>(do-something-about *validation-failures*))
>>> There would be a global function, such as *add-failure*, which would *
>>> conj* a new failure to the vector.
>>
>>
>> Being a Clojure novice I had no idea that this was a possibility and it
>> sounds like a better approach than exception throwing. Is this something
>> similar to the way lib-noir does it? https://github.com/noir-**
>> clojure/lib-noir/blob/master/**src/noir/validation.cljsee
>>  the set-error fn.
>>
>
> Hm, that's really it, quite precisely; I wasn't aware of it. Seeing it now
> I realize that in my example I made the mistake of forgetting to wrap the
> failure vector inside an atom. Without that it won't work.
>
> -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: nested map destructuring

[Alan Thompson]

Nice explanation!   --Alan

On Tue, Mar 19, 2013 at 1:09 PM, Jim - FooBar(); wrote:

>   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.
>
>
>

-- 
-- 
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: Map destructuring variations in Pedestal

[Alan Malloy]

Yes. Apparently you can put whatever garbage you want into the `:or` map: 
each local is looked up in that map to see if it has a default, but nobody 
ever checks to see if there are unused keys in the defaults map. So `:or 
{::type :jety}` has no impact at all on the generated code: there is no 
local named `::jetty` (of course, since that would be an illegal name for a 
local).

On Tuesday, March 19, 2013 11:19:27 PM UTC-7, Sean Corfield wrote:
>
> 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 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. 
> > 
> > 
>
>
>
> -- 
> 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.

Re: Exception propagation design in Clojure web APIs.

[Julien Dreux]

Would there be a way of combining this approach with the use of 
preconditions in clojure?

E.g.

(defn create-user [user]
  {:pre validation/user? user}
  (db/insert! user))


On Wednesday, March 20, 2013 1:00:23 PM UTC-4, Marko Topolnik wrote:
>
> On Wednesday, March 20, 2013 5:51:59 PM UTC+1, Julien Dreux wrote:
>
>> Thank you all for your answers, 
>>
>> I like Marko's approach. 
>>
>> What I had in mind, related to OP's post, would be a middleware that does
>>> (binding [*validation-failures* []] 
>>>(handler req) 
>>>(do-something-about *validation-failures*))
>>> There would be a global function, such as *add-failure*, which would *
>>> conj* a new failure to the vector.
>>
>>
>> Being a Clojure novice I had no idea that this was a possibility and it 
>> sounds like a better approach than exception throwing. Is this something 
>> similar to the way lib-noir does it? 
>> https://github.com/noir-clojure/lib-noir/blob/master/src/noir/validation.cljsee
>>  the set-error fn. 
>>
>
> Hm, that's really it, quite precisely; I wasn't aware of it. Seeing it now 
> I realize that in my example I made the mistake of forgetting to wrap the 
> failure vector inside an atom. Without that it won't work. 
>
> -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: Beginners question - emacs & compiling tests

[tyaakow]

As Marko has said, this was answered on stackoverflow.
But I appreciate your answers, and the discussion is a joy to read.
Cheers!!

-- 
-- 
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.

[Marko Topolnik]

On Wednesday, March 20, 2013 5:51:59 PM UTC+1, Julien Dreux wrote:

> Thank you all for your answers, 
>
> I like Marko's approach. 
>
> What I had in mind, related to OP's post, would be a middleware that does
>> (binding [*validation-failures* []] 
>>(handler req) 
>>(do-something-about *validation-failures*))
>> There would be a global function, such as *add-failure*, which would *
>> conj* a new failure to the vector.
>
>
> Being a Clojure novice I had no idea that this was a possibility and it 
> sounds like a better approach than exception throwing. Is this something 
> similar to the way lib-noir does it? 
> https://github.com/noir-clojure/lib-noir/blob/master/src/noir/validation.cljsee
>  the set-error fn. 
>

Hm, that's really it, quite precisely; I wasn't aware of it. Seeing it now 
I realize that in my example I made the mistake of forgetting to wrap the 
failure vector inside an atom. Without that it won't work. 

-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: Exception propagation design in Clojure web APIs.

[Marko Topolnik]

> I would still code my own library because I am learning clojure at the 
> moment. 
> Question: how is it possible to guarantee that the *failure-list* or 
> *error-list* is only available to the current request. Is that one of the 
> properties of :dynamic?
>

Yes, that's built-in: with (binding ...) you establish a *thread-local* binding 
that is not visible from other threads = request handlers.

-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: Exception propagation design in Clojure web APIs.

[Julien Dreux]

Thank you all for your answers, 

I like Marko's approach. 

What I had in mind, related to OP's post, would be a middleware that does
> (binding [*validation-failures* []] 
>(handler req) 
>(do-something-about *validation-failures*))
> There would be a global function, such as *add-failure*, which would *conj
> * a new failure to the vector.


Being a Clojure novice I had no idea that this was a possibility and it 
sounds like a better approach than exception throwing. Is this something 
similar to the way lib-noir does 
it? 
https://github.com/noir-clojure/lib-noir/blob/master/src/noir/validation.clj 
see the set-error fn. 

I would still code my own library because I am learning clojure at the 
moment. 
Question: how is it possible to guarantee that the *failure-list* or 
*error-list* is only available to the current request. Is that one of the 
properties of :dynamic?

On Wednesday, March 20, 2013 8:24:48 AM UTC-4, Marko Topolnik wrote:
>
> On Wednesday, March 20, 2013 1:06:54 PM UTC+1, Dave Sann wrote:
>
>> Marko, do you have a good example of doing what you say?
>>
>
> What I had in mind, related to OP's post, would be a middleware that does
>
> (binding [*validation-failures* []] 
>(handler req) 
>(do-something-about *validation-failures*))
>
> There would be a global function, such as *add-failure*, which would *conj
> * a new failure to the vector.
>
> -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.

[ANN] Leiningen 2.1.0 released

[Phil Hagelberg]

Greetings, hackers.

Last night I pushed out version 2.1.0 of Leiningen! Here are some
highlights from the release:

• Running `lein deps :tree` will now warn you whenever any of your
  dependencies declare version ranges. Transitive version ranges have
  been a common source of confusion[1] for a long time, so I'm happy to
  see this get out.

• Add support for `:eval-in :nrepl` which allows Leiningen to run tasks
  in an already-running project JVM rather than launching a new one.
  This can significantly speed up task runs at the expense of keeping
  around state in between task runs. See the wiki[2] for a further
  explanation and other things you can do to speed things up.

• Windows users can get lein.bat to self-install without curl now as
  long as they have PowerShell installed. The batch file has also had a
  number of bug fixes.

• New `update-in` higher-order task allows for arbitrary project map
  transformations on the command-line a la `clojure.core/update-in`.

• There is now a GPG guide (`lein help gpg`), and the error messages you
  get when GPG is not installed or a keypair is not found are much better.

• Classifiers for jars can now be specified.

And more at https://github.com/technomancy/leiningen/blob/master/NEWS.md

We had lots of contributors step up to make this release happen, but I'd
especially like to thank Jean Niklas L'orange (hyPiRion) and Nelson
Morris (xeqi) this time around.

If you manually downloaded the `lein` script, you should be able to
upgrade with `lein upgrade 2.1.0`. There was a bug where plain `lein
upgrade` won't get you the latest, so watch out for that.

If you haven't filled out the 2013 Leiningen user survey it would be
great if you could take a couple moments to do so at
https://lein-survey-2013.herokuapp.com.

As always, issues may be reported on the GitHub issue tracker[3].

thanks,
Phil

[1] - 
http://nelsonmorris.net/2012/07/31/do-not-use-version-ranges-in-project-clj.html

[2] - https://github.com/technomancy/leiningen/wiki/Faster

[3] - https://github.com/technomancy/leiningen/issues

-- 
-- 
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

[Toby Crawley]

I've exposed findResource and findResources in ImmutantClassLoader, and
this change is available in incremental build 803 or newer[1]. Give that
a try and let us know if it doesn't work for you.

- Toby

[1]:http://immutant.org/builds/

Tatu Tarvainen writes:

> 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.
>
> -- 


-- 
Toby Crawley
http://immutant.org | http://torquebox.org

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Exception propagation design in Clojure web APIs.

[Marko Topolnik]

On Wednesday, March 20, 2013 4:34:32 PM UTC+1, James Reeves wrote:

> On 20 March 2013 08:36, Marko Topolnik 
> > wrote:
>
>> If you responsibly keep to the "good parts", exceptions could be the way 
>> to go. Validation is one example where I love them because it happens all 
>> around, but validation failures are all handled uniformly.
>>
>
> If validation happens "all around", that implies there is no one function 
> that can test whether a value of data is valid for a given data store. This 
> strikes me as a somewhat shaky foundation for a system.
>

The idea is that all validation functions share the same contract to call 
the appropriate *add-failure* function that registers the validation result.
 

> There may be instances where it makes sense to use exceptions as a control 
> flow mechanism, but I wonder whether it wouldn't be better to use something 
> like CPS in those instances.
>

I can't picture how such a mechanism would work, and what benefit it would 
bring over the exceptions mechanism. CPS in Clojure means trampolining, 
which is quite an unwieldy, and I'd say "cheap" tack-on. A validating 
function would then be supposed to return a common, globally-defined 
"continuation", in fact just a simple function, that would redirect the 
flow towards the validation failure-handling case.

-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.

ANN: Morph 0.2.0, state+error-handling with pure functions

[Armando Blancas]

Release 0.2.0 of the Morph library comes with a couple of fixes and some 
enhancements:

https://github.com/blancas/morph

Safe error-handling with non-global, shared data is now even easier:
https://github.com/blancas/morph/wiki/Simpler-State-with-Error-Handling

Documentation and samples: https://github.com/blancas/morph/wiki
The docs include a Codox API Reference and a change log.
For feedback, bug reports, 
etc.: https://github.com/blancas/morph/issues?page=1&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: Clojure - CLR - JS - Visual Studio Extension

[dmiller]

core.logic should be trivial to port to ClojureCLR.
Based on a quick scan, a few changes to JVM lib calls, mostly .write => 
.Write, a few type hints, UUID => GUID.
Could be done in short order.

This would be an easy example to play with a common source for  Clojure(JVM 
| CLR).

-David


On Tuesday, March 19, 2013 5:24:34 PM UTC-5, Martin Jul wrote:
>
>
>> 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: Exception propagation design in Clojure web APIs.

[James Reeves]

On 20 March 2013 08:36, Marko Topolnik  wrote:

> If you responsibly keep to the "good parts", exceptions could be the way
> to go. Validation is one example where I love them because it happens all
> around, but validation failures are all handled uniformly.
>

If validation happens "all around", that implies there is no one function
that can test whether a value of data is valid for a given data store. This
strikes me as a somewhat shaky foundation for a system.

There may be instances where it makes sense to use exceptions as a control
flow mechanism, but I wonder whether it wouldn't be better to use something
like CPS in those instances.

- James

-- 
-- 
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.

[Ben Wolfson]

On Wed, Mar 20, 2013 at 1:14 AM, Christian Sperandio
 wrote:
> Use exceptions for control flow makes the developer's work easier but not
> the one of reader. In other terms the maintenance may become more difficult
> for the reason given by John.
>
> And I think when exceptions are used for control flow, the original
> exception meaning is forgotten: Exceptions should inform about exceptional
> errors that shouldn't happen (code implementation error, network issues,
> disk failure,...). It's the opposite of user data checking :)

Exceptions are escape continuations; they should (modulo things like
"finally" if present) go directly to the nearest dynamically enclosing
handler. The fact that they have the name "exception" is unfortunate,
because it leads to purely nominal conceptions of when they should be
employed (i.e., in "exceptional situations"). That may have in fact
been the intention when they were introduced, but it's hard for me to
see why that's relevant. Oleg Kiselyov's implementation of generators
for ocaml is based on exceptions:
https://github.iu.edu/sabry/PPYield/blob/master/simple_gen.ml (as I
believe is the delimcc library, under the hood); it seems silly to
argue that since he makes *routine* use of exceptions, his
implementation is flawed.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Exception propagation design in Clojure web APIs.

[Dave Sann]

Ok, but how do you take account of different processing (or non processing) 
needs in the handler (chain) given that something is awry half way down?

(note that in my case the handler is not pure - the validation precedes the 
need for a state change. The state change should occur if the validation 
passes and must not if it fails. I can't validate in advance because that 
would lead to a race condition).

On Wednesday, 20 March 2013 23:24:48 UTC+11, Marko Topolnik wrote:
>
> On Wednesday, March 20, 2013 1:06:54 PM UTC+1, Dave Sann wrote:
>
>> Marko, do you have a good example of doing what you say?
>>
>
> What I had in mind, related to OP's post, would be a middleware that does
>
> (binding [*validation-failures* []] 
>(handler req) 
>(do-something-about *validation-failures*))
>
> There would be a global function, such as *add-failure*, which would *conj
> * a new failure to the vector.
>
> -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: Exception propagation design in Clojure web APIs.

[Marko Topolnik]

On Wednesday, March 20, 2013 1:06:54 PM UTC+1, Dave Sann wrote:

> Marko, do you have a good example of doing what you say?
>

What I had in mind, related to OP's post, would be a middleware that does

(binding [*validation-failures* []] 
   (handler req) 
   (do-something-about *validation-failures*))

There would be a global function, such as *add-failure*, which would *conj* a 
new failure to the vector.

-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.

Clojure in Medellín / Colombia

[Rick Beerendonk]

I was wondering if there are Clojure users in Medellín. A user group maybe?

-- 
-- 
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.

[Dave Sann]

Interesting.

Validation is the case I am thinking of - but it might also apply to any 
situation where you offer a different path of control - i.e. not stepping 
back up the stack. That's why I mentioned CPS. That's also (maybe) why true 
tail calls would be useful.

The mention of binding dynamic vars is interesting and I will look at this. 
It still leaves the question of how/when to pass control to actually manage 
or respond to the validation error. I have generally kept away from dynamic 
vars to date because I don't have a good feel for when and where they are 
and are not a good choice. This would be a great area for a blog post - or 
clojure docs doco -  if anyone who has used them extensively can offer a 
good view of pros and cons, whens and when nots :)

Marko, do you have a good example of doing what you say?

The reasons given for not using Exceptions are still not really convincing 
to me (yet). Although I do accept that some things may become more 
difficult to manage if you don't take care in what you do. This is 
generally true. I just see Exceptions as a way of managing control with 
pros and cons, not an anti pattern.

Maybe a more general question is what alternative control flows are 
available - which are possible but not available - and which are good for 
which situations.

Apologies to the original questioner for changing the focus of the recent 
posts.

Dave


On Wednesday, 20 March 2013 19:36:46 UTC+11, Marko Topolnik wrote:
>
> Exceptions are a perfect tool for flow control, if used judiciously. The 
> typical criticism revolves around their incompetent usage, and a more 
> general criticism can be made against a mechanism that is subverted all too 
> easily.
>
> If you responsibly keep to the "good parts", exceptions could be the way 
> to go. Validation is one example where I love them because it happens all 
> around, but validation failures are all handled uniformly.
>
> However, I would also urge you to explore other approaches, such as having 
> a dynamically-bound variable that collects all the validation failures, 
> which will potentially give you better diagnostics than the fail-fast 
> behavior of validation excptions.
>
> -marko
>
> On Wednesday, March 20, 2013 2:24:12 AM UTC+1, 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 

Re: Beginners question - emacs & compiling tests

[Stefan Kamphausen]

On Wednesday, March 20, 2013 10:44:15 AM UTC+1, Marko Topolnik wrote:
>
>
> Because you usually don't want to wait the eternity it takes to compile 
> and load absolutely everything. Even loading just the main namespace can be 
> painfully slow, even if your project is just a few lines, due to the 
> hugeness of the whole dependency tree.
>
>
Sounds like my method of work is different :-)

Stefan 

-- 
-- 
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

[Marko Topolnik]

On Wednesday, March 20, 2013 10:39:34 AM UTC+1, Stefan Kamphausen wrote:

>
> To it seems obvious, that I want my complete project loaded and waiting 
> for my new changes, when I launch a REPL.  Maybe that's a leftover from my 
> Common Lisp days?  Why would I want to hit C-c C-k every time I open one of 
> the files in my project?
>

Because you usually don't want to wait the eternity it takes to compile and 
load absolutely everything. Even loading just the main namespace can be 
painfully slow, even if your project is just a few lines, due to the 
hugeness of the whole dependency tree.

-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: Beginners question - emacs & compiling tests

[Stefan Kamphausen]

Hi,


On Wednesday, March 20, 2013 9:44:19 AM UTC+1, Marko Topolnik wrote:
>
> This problem was cross-posted over here from 
> StackOverflow,
>  
> where it has already been marked as solved.


oh, sorry, didn't know that.
 

>
> BTW where do you encounter your problem? Inside emacs, with nrepl.el?
>

Yes.
 

> Because nrepl.el doesn't automatically compile anything; if you start the 
> repl with *lein repl*,
>


This is what I ususally do.  Then connect using M-x nrepl.  Sometimes I 
quickly launch the JVM using M-x nrepl-jack-in which makes no difference.


it will get compiled by the built-in repl client, and the effects will be 
> observed within emacs. This is more of a side-effect than by-design.
>


To it seems obvious, that I want my complete project loaded and waiting for 
my new changes, when I launch a REPL.  Maybe that's a leftover from my 
Common Lisp days?  Why would I want to hit C-c C-k every time I open one of 
the files in my project?
 


> If you, however, start with *lein repl :headless*, nothing happens (this 
> will improve with Leiningen 2.1).
>

Never used that.
 


Cheers,
Stefan

-- 
-- 
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

[Marko Topolnik]

This problem was cross-posted over here from 
StackOverflow,
 
where it has already been marked as solved.

BTW where do you encounter your problem? Inside emacs, with nrepl.el? 
Because nrepl.el doesn't automatically compile anything; if you start the 
repl with *lein repl*, it will get compiled by the built-in repl client, 
and the effects will be observed within emacs. This is more of a 
side-effect than by-design.

If you, however, start with *lein repl :headless*, nothing happens (this 
will improve with Leiningen 2.1).

For any of this to work you need a *:main ...* or *:repl-options {:init ns 
...}* declaration in project.clj.

Finally, only the indicated main namespace (and its dependencies) will be 
loaded; the test namespace will once again stay unloaded because the main 
code doesn't depend on the test code.

-marko


On Wednesday, March 20, 2013 9:28:52 AM UTC+1, Stefan Kamphausen wrote:
>
> If you have a valid ns-form and still encounter that error, it may help to 
> compile the file once using C-c C-k.  I still need to do that (sometimes?) 
> when I open a file in Emacs although I'd thought, that the complete project 
> should have been loaded at REPL start. After that compilation of single 
> tests (e.g. using C-M-x) should be working.
>
> Best,
> Stefan
>

-- 
-- 
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.

[Marko Topolnik]

Exceptions are a perfect tool for flow control, if used judiciously. The 
typical criticism revolves around their incompetent usage, and a more 
general criticism can be made against a mechanism that is subverted all too 
easily.

If you responsibly keep to the "good parts", exceptions could be the way to 
go. Validation is one example where I love them because it happens all 
around, but validation failures are all handled uniformly.

However, I would also urge you to explore other approaches, such as having 
a dynamically-bound variable that collects all the validation failures, 
which will potentially give you better diagnostics than the fail-fast 
behavior of validation excptions.

-marko

On Wednesday, March 20, 2013 2:24:12 AM UTC+1, 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.
>>>  
>>>  
>>>
>>
>>

-- 
-- 

Re: Beginners question - emacs & compiling tests

[Stefan Kamphausen]

If you have a valid ns-form and still encounter that error, it may help to 
compile the file once using C-c C-k.  I still need to do that (sometimes?) 
when I open a file in Emacs although I'd thought, that the complete project 
should have been loaded at REPL start. After that compilation of single 
tests (e.g. using C-M-x) should be working.

Best,
Stefan

-- 
-- 
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.

[Christian Sperandio]

Use exceptions for control flow makes the developer's work easier but not 
the one of reader. In other terms the maintenance may become more difficult 
for the reason given by John.

And I think when exceptions are used for control flow, the original 
exception meaning is forgotten: Exceptions should inform about exceptional 
errors that shouldn't happen (code implementation error, network issues, 
disk failure,...). It's the opposite of user data checking :)



-- 
-- 
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.