Re: [ANN] Clojure 1.8.0-RC1 is now available

[Leon Grapenthin]

Does this mean putting it in the arglist always works and there is rarely a 
practical reason to do anything else?

On Thursday, November 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote:
>
> It.. depends :(
>
> If your type hint is a *primitive* then you want to put it in the arglist. 
> If you put it in the Var, the best case scenario is that you'll get either 
> reflection warnings or boxed maths, and the worst case scenario is a 
> Compiler/bytecode error.
>
> If your type hint is an array type hint (^objects, ^ints ..) you want to 
> put it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).
>
> If your type hint is a non primitive class, you want to put it in the Var 
> or in the arglist as a fully qualified symbol (not necessary anymore since 
> 1.8)
>
> If your type hint is a string representing a class, you can safely put it 
> in either place.
>
> On 12 Nov 2015, at 19:28, Michael Blume  
> wrote:
>
> Sorry, I'm confused now -- is the appropriate place to give a return type 
> hint for a function the arg list and not the function name? I've always 
> seen the function name hinted.
>
> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  > wrote:
>
>> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>>
>> On 12 Nov 2015, at 19:14, Nicola Mometto  
>> wrote:
>>
>>
>> Depends on how you look at it.
>> From my point of view, both examples are using an otherwise valid type 
>> hint, at an invalid location, and in both cases the emitted code is 
>> nonsensical.
>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>> with a compile time error, this one should too.
>>
>>
>> On 12 Nov 2015, at 16:47, Alex Miller  
>> wrote:
>>
>> Neither is acceptable, so I either misunderstand or disagree with your 
>> question. :) 
>>
>> The code below is an invalid type hint at that location. Are you maybe 
>> saying this should throw an error on definition?
>>
>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>> Which now throws an error.
>>
>>
>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>>
>>> This is :rettag in action.
>>> Any reason why this error should be acceptable while the CLJ-1846 one 
>>> isn't?
>>>
>>> On 12 Nov 2015, at 12:55, Alex Miller >> > wrote:
>>>
>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>> double function object. You really want:
>>>
>>> (defn timespi ^double [^double x] (* x 3.14))
>>>
>>>
>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebo...@gmail.com 
>>>  wrote:

 Hello,

 the following stops executing on 1.8.0-rc1 or current master-head 
 (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
 for CLJ-1846):

 [/Users/reborg]$ repl
 Clojure 1.8.0-master-SNAPSHOT
 user=> (defn ^double timespi [^double x] (* x 3.14))
 #'user/timespi
 user=> (timespi 2)
 AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
 is abstract  user/timespi (NO_SOURCE_FILE:-1)

 It works if you enable direct linking (or if you use 1.7.0).

 Renzo

>>>
>> -- 
>> 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/d/optout.
>>
>>
>>
>>
>> -- 
>> 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/d/optout.
>>
>
> -- 
> 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 
> 

Re: Help with idiomatic clojure.

[Brian]

Thanks Colin, Thanks Erik
Exactly what I was looking for.

I've updated the gist with Colin's suggestion and a bit of destructuring.
If this project gets any bigger I will definitely look at vlad
 and Prismatic Schema
.

BDF.

On Thu, Nov 12, 2015 at 12:02 PM, Erik Assum  wrote:

> There is also https://github.com/logaan/vlad which helps with validation.
>
> Erik.
> --
> i farta
>
> Den 12. nov. 2015 kl. 17.12 skrev Colin Yates :
>
> A nicer equivalent form would be:
>
> (cond-> []
>   this-error? (conj “It failed with this error”)
>   that-error? (conj “It failed with that error”))
>
> However, purely for validation there are a few utilities out there
> already. Checkout the ‘Validation’ section on
> http://www.clojure-toolbox.com
>
> Also, in terms of enforcing contracts - Prismatic Schema is highly
> recommended but hard to ‘englishify’ the errors. Failures are considered
> API failures rather than happy-case failures.
>
> On 12 Nov 2015, at 16:09, Brian Forester  wrote:
>
> I'm writing a very small REST application in clojure using compojure and 
> ring.  One problem is that I don't have anyone who can review my work or 
> provide feedback.
>
>
> I've written a small function to validate a simple JSON request.  I'm 
> validating the three values that are in the post and collecting the errors 
> for return.
>
> The core mechanic I've used
>
>  (swap! errors str "'grepString' must not be null or empty.\n"))
>
> does not seem to be a very idiomatic clojure way to solve this simple problem.
>
>
> https://gist.github.com/BDF/8e61daf8fe8b602a248a
>
>
> Any feedback is appreciated.
>
> BDF.
>
>
>
>
> --
> 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/d/optout.
>
>
> --
> 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/d/optout.
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

*mostly* works, and since 1.8 only.
The issue pre 1.8 is that since metadata on arglist is not evaluated, the type 
hint wasn't a fully qualified classname, forcing the user namespaces to import 
that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))
(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))
(.method (foo/foo))


> On 12 Nov 2015, at 19:49, Leon Grapenthin  wrote:
> 
> Does this mean putting it in the arglist always works and there is rarely a 
> practical reason to do anything else?
> 
> On Thursday, November 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote:
> It.. depends :(
> 
> If your type hint is a *primitive* then you want to put it in the arglist. If 
> you put it in the Var, the best case scenario is that you'll get either 
> reflection warnings or boxed maths, and the worst case scenario is a 
> Compiler/bytecode error.
> 
> If your type hint is an array type hint (^objects, ^ints ..) you want to put 
> it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).
> 
> If your type hint is a non primitive class, you want to put it in the Var or 
> in the arglist as a fully qualified symbol (not necessary anymore since 1.8)
> 
> If your type hint is a string representing a class, you can safely put it in 
> either place.
> 
>> On 12 Nov 2015, at 19:28, Michael Blume  
>> wrote:
>> 
>> Sorry, I'm confused now -- is the appropriate place to give a return type 
>> hint for a function the arg list and not the function name? I've always seen 
>> the function name hinted.
>> 
>> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto > > wrote:
>> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>> 
>>> On 12 Nov 2015, at 19:14, Nicola Mometto  
>>> wrote:
>>> 
>>> 
>>> Depends on how you look at it.
>>> From my point of view, both examples are using an otherwise valid type 
>>> hint, at an invalid location, and in both cases the emitted code is 
>>> nonsensical.
>>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>>> with a compile time error, this one should too.
>>> 
>>> 
 On 12 Nov 2015, at 16:47, Alex Miller  
 wrote:
 
 Neither is acceptable, so I either misunderstand or disagree with your 
 question. :) 
 
 The code below is an invalid type hint at that location. Are you maybe 
 saying this should throw an error on definition?
 
 CLJ-1846 is instead a valid type hint that is in conflict with the call. 
 Which now throws an error.
 
 
 On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
 This is :rettag in action.
 Any reason why this error should be acceptable while the CLJ-1846 one 
 isn't?
 
> On 12 Nov 2015, at 12:55, Alex Miller  > wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebo...@gmail.com 
>  wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
> is abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
 
 
 -- 
 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/d/optout 
 .
>>> 
>> 
>> 
>> -- 
>> 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 

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

It.. depends :(

If your type hint is a *primitive* then you want to put it in the arglist. If 
you put it in the Var, the best case scenario is that you'll get either 
reflection warnings or boxed maths, and the worst case scenario is a 
Compiler/bytecode error.

If your type hint is an array type hint (^objects, ^ints ..) you want to put it 
in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).

If your type hint is a non primitive class, you want to put it in the Var or in 
the arglist as a fully qualified symbol (not necessary anymore since 1.8)

If your type hint is a string representing a class, you can safely put it in 
either place.

> On 12 Nov 2015, at 19:28, Michael Blume  wrote:
> 
> Sorry, I'm confused now -- is the appropriate place to give a return type 
> hint for a function the arg list and not the function name? I've always seen 
> the function name hinted.
> 
> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  > wrote:
> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
> 
>> On 12 Nov 2015, at 19:14, Nicola Mometto > > wrote:
>> 
>> 
>> Depends on how you look at it.
>> From my point of view, both examples are using an otherwise valid type hint, 
>> at an invalid location, and in both cases the emitted code is nonsensical.
>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>> with a compile time error, this one should too.
>> 
>> 
>>> On 12 Nov 2015, at 16:47, Alex Miller >> > wrote:
>>> 
>>> Neither is acceptable, so I either misunderstand or disagree with your 
>>> question. :) 
>>> 
>>> The code below is an invalid type hint at that location. Are you maybe 
>>> saying this should throw an error on definition?
>>> 
>>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>>> Which now throws an error.
>>> 
>>> 
>>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>> This is :rettag in action.
>>> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
>>> 
 On 12 Nov 2015, at 12:55, Alex Miller > wrote:
 
 That's not a valid type hint. Var meta is evaluated, in this case to the 
 double function object. You really want:
 
 (defn timespi ^double [^double x] (* x 3.14))
 
 
 On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
  wrote:
 Hello,
 
 the following stops executing on 1.8.0-rc1 or current master-head 
 (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
 CLJ-1846):
 
 [/Users/reborg]$ repl
 Clojure 1.8.0-master-SNAPSHOT
 user=> (defn ^double timespi [^double x] (* x 3.14))
 #'user/timespi
 user=> (timespi 2)
 AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
 abstract  user/timespi (NO_SOURCE_FILE:-1)
 
 It works if you enable direct linking (or if you use 1.7.0).
 
 Renzo
>>> 
>>> 
>>> -- 
>>> 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/d/optout 
>>> .
>> 
> 
> 
> -- 
> 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 

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Sean Corfield]

Nicola Mometto wrote on Thursday, November 12, 2015 at 11:52 AM:
*mostly* works, and since 1.8 only.
The issue pre 1.8 is that since metadata on arglist is not evaluated, the type 
hint wasn't a fully qualified classname, forcing the user namespaces to import 
that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))
(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))
(.method (foo/foo))

Ah, thank you for the explanation! I’d run into that and couldn’t really 
understand why it was failing!

Sean


-- 
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/d/optout.

Re: Help with idiomatic clojure.

[Colin Yates]

One other minor point (if (seq some-sequence) true false) is preferred by some 
(I won’t say more idiomatic) than (if (empty? some-sequence) true false). Also, 
in no-errors branch you probably want to return status: 200?


> On 12 Nov 2015, at 19:44, Brian  wrote:
> 
> Thanks Colin, Thanks Erik
> Exactly what I was looking for.
> 
> I've updated the gist with Colin's suggestion and a bit of destructuring. 
> If this project gets any bigger I will definitely look at vlad 
>  and Prismatic Schema 
> .
> 
> BDF.
> 
> On Thu, Nov 12, 2015 at 12:02 PM, Erik Assum  > wrote:
> There is also https://github.com/logaan/vlad  
> which helps with validation. 
> 
> Erik. 
> -- 
> i farta
> 
> Den 12. nov. 2015 kl. 17.12 skrev Colin Yates  >:
> 
>> A nicer equivalent form would be:
>> 
>> (cond-> []
>>   this-error? (conj “It failed with this error”)
>>   that-error? (conj “It failed with that error”))
>> 
>> However, purely for validation there are a few utilities out there already. 
>> Checkout the ‘Validation’ section on http://www.clojure-toolbox.com 
>> 
>> 
>> Also, in terms of enforcing contracts - Prismatic Schema is highly 
>> recommended but hard to ‘englishify’ the errors. Failures are considered API 
>> failures rather than happy-case failures.
>> 
>>> On 12 Nov 2015, at 16:09, Brian Forester >> > wrote:
>>> 
>>> I'm writing a very small REST application in clojure using compojure and 
>>> ring.  One problem is that I don't have anyone who can review my work or 
>>> provide feedback.
>>> 
>>> I've written a small function to validate a simple JSON request.  I'm 
>>> validating the three values that are in the post and collecting the errors 
>>> for return.
>>> The core mechanic I've used
>>>  (swap! errors str "'grepString' must not be null or empty.\n"))
>>> does not seem to be a very idiomatic clojure way to solve this simple 
>>> problem.
>>> 
>>> https://gist.github.com/BDF/8e61daf8fe8b602a248a 
>>> 
>>> 
>>> Any feedback is appreciated.
>>> BDF.
>>> 
>>> 
>>> 
>>> -- 
>>> 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/d/optout 
>>> .
>> 
>> 
>> -- 
>> 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/d/optout 
>> .
> 
> 
> -- 
> 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 

Re: Pareto's Clojure

[Sayth Renshaw]

Thank you Eric that does really look like you have nailed a good core of 
clojure. Thank you also for providing the references I really think it will 
help.

Excited to see how many solutions I can make using these. 

Sayth

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[reborgml]

Hello,

the following stops executing on 1.8.0-rc1 or current master-head 
(9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
for CLJ-1846):

[/Users/reborg]$ repl
Clojure 1.8.0-master-SNAPSHOT
user=> (defn ^double timespi [^double x] (* x 3.14))
#'user/timespi
user=> (timespi 2)
AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
abstract  user/timespi (NO_SOURCE_FILE:-1)

It works if you enable direct linking (or if you use 1.7.0).

Renzo

On Tuesday, 10 November 2015 17:30:47 UTC, Alex Miller wrote:
>
> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
>

-- 
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/d/optout.

Re: Help with idiomatic clojure.

[Chris Murphy]

I think true and false should be swapped around, because seq and empty? 
are opposites, seq meaning it is not empty.


On 13/11/2015 8:08 AM, Colin Yates wrote:
One other minor point (if (seq some-sequence) true false) is preferred 
by some (I won’t say more idiomatic) than (if (empty? some-sequence) 
true false). Also, in no-errors branch you probably want to return 
status: 200?



On 12 Nov 2015, at 19:44, Brian > wrote:


Thanks Colin, Thanks Erik
Exactly what I was looking for.

I've updated the gist with Colin's suggestion and a bit of 
destructuring.
If this project gets any bigger I will definitely look at vlad 
 and Prismatic Schema 
.


BDF.

On Thu, Nov 12, 2015 at 12:02 PM, Erik Assum > wrote:


There is also https://github.com/logaan/vlad which helps with
validation.

Erik.
-- 
i farta


Den 12. nov. 2015 kl. 17.12 skrev Colin Yates
>:


A nicer equivalent form would be:

(cond-> []
  this-error? (conj “It failed with this error”)
  that-error? (conj “It failed with that error”))

However, purely for validation there are a few utilities out
there already. Checkout the ‘Validation’ section on
http://www.clojure-toolbox.com 

Also, in terms of enforcing contracts - Prismatic Schema is
highly recommended but hard to ‘englishify’ the errors. Failures
are considered API failures rather than happy-case failures.


On 12 Nov 2015, at 16:09, Brian Forester
> wrote:

I'm writing a very small REST application in clojure using
compojure and ring. One problem is that I don't have anyone who
can review my work or provide feedback.
I've written a small function to validate a simple JSON request.  I'm 
validating the three values that are in the post and collecting the errors for 
return.
The core mechanic I've used
(swap!errors str "'grepString' must not be null or empty.\n"))
does not seem to be a very idiomatic clojure way to solve this simple 
problem.
https://gist.github.com/BDF/8e61daf8fe8b602a248a
Any feedback is appreciated.
BDF.

-- 
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/d/optout.



-- 
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/d/optout.


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

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

That's not a valid type hint. Var meta is evaluated, in this case to the 
double function object. You really want:

(defn timespi ^double [^double x] (* x 3.14))


On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
wrote:
>
> Hello,
>
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
> for CLJ-1846):
>
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
>
> It works if you enable direct linking (or if you use 1.7.0).
>
> Renzo
>

-- 
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/d/optout.

Re: [ANN] Let's make clojure.org better!

[Leon Grapenthin]

I'd like to say that as a Clojure programmer I really like the current 
page.  

The reference documentation is an excellent resource. It does not answer 
all questions, but it answers the most critical ones very concisely and I 
hope that you intend to keep it like that.

If one thing about the page could be done better it is its appearance 
towards people who heard about Clojure the first time and want to learn 
more about it.

I think I learned about Clojure back ago when researching something Lisp 
related and in that context listened to a Rich Hickey talk. I thought: He 
created a programming language? It must either be insanely great or 
idealistic but unpractical. I went to the clojure.org website and thought: 
Oh, so he created the website for it as well (I think that is not true but 
that is what I thought), concluded that the language can't be very popular 
and probably does not have many users. It immediately ranked lower on the 
list of languages I wanted to try out. That was around 2012. The page 
failed to make me want to try out Clojure immediately mostly because it 
didn't make me trust in it on first sight. Listing high profile companies 
that are using Clojure might help.

If I remember correctly, it was a few weeks later when out of curiosity I 
opened the Youtube video "Clojure for Lisp programmers" that made me want 
to try out Clojure. There is also one "Clojure for Java programmers" and 
"Clojure Data structures" on ClojureTV. I think these should be put on the 
front page and be one click away. A 5 minute tutorial, probably with an 
in-browser REPL like tryclj.com should also be one click away. On a side 
note, "Clojure data structures" could be redone for the web as audience and 
enhanced with some visualization directed towards people who have no idea 
how immutable DS in a Lisp "feel". 

Kind regards,
 Leon.





On Thursday, November 12, 2015 at 11:58:41 AM UTC+1, Nando Breiter wrote:
>
> Expanding on the content idea for new-comers *to Clojure*, like me, (but 
> not necessarily to programming in general), I've found the approachs taken 
> by Living Clojure and PurelyFunctional.tv to be really helpful. Both Carin 
> Meier and Eric Normand (for example) take a relatively shallow angle of 
> attack and yet maintain an engaging pace, focusing on key areas of the 
> language. They lay out a *path* to learn, and invite the new-comer to 
> follow along. Not everyone might need tutoring like this, but judging from 
> the recommendations I've seen, others seem to appreciate it.
>
> The Getting Started page is currently a list of resources. That's 
> certainly needed. But it can take someone new to Clojure a considerable 
> amount of time to dive into all of it. And it's easy to get bogged down. 
> While there may be value in letting folks sort it out and slog through it 
> all for themselves, there's no learning path laid out on the website. Hence 
> I think a dedicated page or section named, for instance, "How to learn 
> Clojure" might be helpful. 
>
> What should go in this section? Content that would help someone having at 
> least some difficulty learning Clojure. Content that would help them sort 
> out how to approach learning the language. Content that would help them 
> prioritize which resources to use at which level.
>
>
>
>
>
>
>
> Aria Media Sagl
> Via Rompada 40
> 6987 Caslano
> Switzerland
>
> +41 (0)91 600 9601
> +41 (0)76 303 4477 cell
> skype: ariamedia
>
> On Wed, Nov 11, 2015 at 9:24 PM, Harrison Maseko  > wrote:
>
>> Content idea: Would be nice to have a section for new-comers to 
>> programming, introducing them to programming through Clojure. All of the 
>> existing Clojure books that I know of are aimed at those with intermediate 
>> to advanced programming skills in Clojure or another language. The content 
>> and learning gradient in those books can be steep and could put off a 
>> beginner. Although Clojure is such an advanced language, I think it's 
>> possible to implant programming concepts in a complete beginner by using a 
>> subset of Clojure. But maybe the the clojure.org Website is not the 
>> right place for that?
>> Thanks,
>> H
>>
>>
>> On Tuesday, November 10, 2015 at 5:57:45 PM UTC+2, Alex Miller wrote:
>>>
>>> Hi Hildeberto,
>>>
>>> I built spikes of the site in a number of technologies like Cryogen, 
>>> Stasis, Sphinx, Asciidoctor, and some of the other Ruby-based static 
>>> generators as well. In the end, I found that JBake was the best match for 
>>> our goals at this time. The site build architecture has been decided and 
>>> we're not interested in revisiting that at this time. At some point down 
>>> the road, based on experience and tool evolution, we may take another look, 
>>> but not soon. 
>>>
>>> Cryogen is a great tool and I would recommend it to others. One problem 
>>> I had with it was its flexibility with respect to the url structure. I 
>>> actually think for the purposes of creating a blog etc that is a 

Re: [ANN] Let's make clojure.org better!

[Nando Breiter]

Expanding on the content idea for new-comers *to Clojure*, like me, (but
not necessarily to programming in general), I've found the approachs taken
by Living Clojure and PurelyFunctional.tv to be really helpful. Both Carin
Meier and Eric Normand (for example) take a relatively shallow angle of
attack and yet maintain an engaging pace, focusing on key areas of the
language. They lay out a *path* to learn, and invite the new-comer to
follow along. Not everyone might need tutoring like this, but judging from
the recommendations I've seen, others seem to appreciate it.

The Getting Started page is currently a list of resources. That's certainly
needed. But it can take someone new to Clojure a considerable amount of
time to dive into all of it. And it's easy to get bogged down. While there
may be value in letting folks sort it out and slog through it all for
themselves, there's no learning path laid out on the website. Hence I think
a dedicated page or section named, for instance, "How to learn Clojure"
might be helpful.

What should go in this section? Content that would help someone having at
least some difficulty learning Clojure. Content that would help them sort
out how to approach learning the language. Content that would help them
prioritize which resources to use at which level.







Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

On Wed, Nov 11, 2015 at 9:24 PM, Harrison Maseko  wrote:

> Content idea: Would be nice to have a section for new-comers to
> programming, introducing them to programming through Clojure. All of the
> existing Clojure books that I know of are aimed at those with intermediate
> to advanced programming skills in Clojure or another language. The content
> and learning gradient in those books can be steep and could put off a
> beginner. Although Clojure is such an advanced language, I think it's
> possible to implant programming concepts in a complete beginner by using a
> subset of Clojure. But maybe the the clojure.org Website is not the right
> place for that?
> Thanks,
> H
>
>
> On Tuesday, November 10, 2015 at 5:57:45 PM UTC+2, Alex Miller wrote:
>>
>> Hi Hildeberto,
>>
>> I built spikes of the site in a number of technologies like Cryogen,
>> Stasis, Sphinx, Asciidoctor, and some of the other Ruby-based static
>> generators as well. In the end, I found that JBake was the best match for
>> our goals at this time. The site build architecture has been decided and
>> we're not interested in revisiting that at this time. At some point down
>> the road, based on experience and tool evolution, we may take another look,
>> but not soon.
>>
>> Cryogen is a great tool and I would recommend it to others. One problem I
>> had with it was its flexibility with respect to the url structure. I
>> actually think for the purposes of creating a blog etc that is a dimension
>> that is good to remove, but it was a downside for our use.
>>
>> We are working with a designer on the site look and feel and at some
>> point that will be visible. At the point where that is visible, I expect
>> there will be some evolution on front page, navigation structure, etc and
>> would be happy to get feedback on that.
>>
>> Right now, we are primarily looking for content ideas and would love
>> thoughts on that. Or if there is interest in enhancing existing pages, I
>> would also like to talk about those.
>>
>> Thanks,
>> Alex
>>
>>
>>
>> On Tuesday, November 10, 2015 at 9:41:40 AM UTC-6, Hildeberto Mendonça
>> wrote:
>>>
>>> That's a great initiative! Thanks! But I'm just sad to see JBake instead
>>> of Cryogen (https://github.com/cryogen-project/cryogen-core) which is
>>> written in Clojure :-( Can we send a pull request replacing JBake by
>>> Cryogen or is JBake a final decision?
>>>
>>> --
>>> Hildeberto Mendonça, Ph.D
>>> Blog: http://www.hildeberto.com
>>> Twitter: https://twitter.com/htmfilho
>>>
>> --
> 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/d/optout.
>

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

[ANN] clj-fakes 0.3.0 - an isolation framework for Clojure and ClojureScript

[Yuri Govorushchenko]

Hi! This is the first public release of my lib for mocking and stubbing in 
unit tests, I would greatly appreciate any feedback.

GitHub: https://github.com/metametadata/clj-fakes
Documentation: http://metametadata.github.io/clj-fakes/

*Features*
   
   - All test doubles are named "fakes" to simplify terminology
   - Fakes can be created for:
  - protocol and Java interface instances
  - functions
   - "Nice" and "strict" protocol fakes are supported
   - Monkey patching is supported to fake implicit dependencies
   - Self-testing: automatically checks for unused fakes
   - Test runner agnostic
   - Arrange-Act-Assert style testing

*Example of creating a mock object*

(defprotocol AnimalProtocol
  (speak [this name])); ...

(deftest example
  (f/with-fakes
; create fake instance of specified protocol
(let [cow (f/reify-fake p/AnimalProtocol
; ask framework to record method calls
(speak :recorded-fake))]
  ; call method on fake object
  (p/speak cow "Bob")

  ; assert that method was called with specified args
  (is (f/method-was-called p/speak cow ["Bob"])

-- 
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/d/optout.

Re: JDBC Rollbacks and Exceptions

[Andy Chambers]

On Friday, October 30, 2015 at 5:22:40 PM UTC-7, Sean Corfield wrote:
>
> Could you provide a bit more context?
>
> We’re using clojure.java.jdbc very heavily in production and we don’t see 
> any problems with exceptions.
>

Hi Sean,

I threw up an example repo demonstrating the type of test I'd like to be 
able to write somehow. Maybe I'm just
trying to test something that should be tested in other ways.

https://github.com/cddr/jdbc-demo

Cheers,
Andy

-- 
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/d/optout.

Re: JDBC Rollbacks and Exceptions

[Andrey Antukh]

If I understand it properly, this is a expected behavior in most databases.
The common way for solve this, is wrapping the expected to fail code in a
sub-transaction (or savepoint in database words). If that code fails, the
sub-transaction will be aborted, but the main transaction will continue to
be alive. With this approach you not need a complete rollback of the
transaction (and no connection reset).

The main problem here is that as far as I know, clojure.java.jdbc does not
has support for subtransactions. If you nest transactions, the nested
transactions does nothing and everything is joined in one unique main
transaction.

Without aims to do spam, it there alternatives to clojure.java.jdbc that
already supports sub-transactions/savepoints [1] and [2] among other
transaction strategies.

[1]: https://github.com/funcool/suricatta
[2]: https://github.com/funcool/clojure.jdbc

Andrey

On Fri, Nov 13, 2015 at 8:49 AM, Andy Chambers 
wrote:

> On Friday, October 30, 2015 at 5:22:40 PM UTC-7, Sean Corfield wrote:
>>
>> Could you provide a bit more context?
>>
>> We’re using clojure.java.jdbc very heavily in production and we don’t
>> see any problems with exceptions.
>>
>
> Hi Sean,
>
> I threw up an example repo demonstrating the type of test I'd like to be
> able to write somehow. Maybe I'm just
> trying to test something that should be tested in other ways.
>
> https://github.com/cddr/jdbc-demo
>
> Cheers,
> Andy
>
> --
> 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/d/optout.
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz

-- 
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/d/optout.

Re: [ANN] 0.3.0 HugSQL release

[Curtis Summers]

Colin,

I've added an issue to explore composable features for a future HugSQL
release:

https://github.com/layerware/hugsql/issues/12

All ideas welcome!  Thanks!

On Wed, Nov 11, 2015 at 11:40 PM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:

> Fantastic release Curtis. This is an awesome work!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/1vezOq3Ro78/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: Style, Efficiency, and updating nested structure

[Dave Tenny]

Thanks for the replies, as always lots of interesting ways to do it in
clojure.  No zipper sugestions?

For my own take, I happen to like the last suggestion (Gareth's) the most I
think, of the ones offered so far.  It has a lispy elegance and is still
relatively efficient in traversals and memory allocation, compared to some
solutions (particular with a revision to the merge-roles implementation to
eliminate all the set creation, see next sentence).

Some of you rewrote the problem a bit.  For example, the 'merge-roles'
conversion to sets is very expensive, especially since I know that the
input in my original problem isn't going to offer duplicate project rules
for a given project ID.

On efficiency in general, it is perhaps a generational thing that people
say "don't prematurely optimize" so often and then cons up intermediate
objects with wild abandon.  And while a well crafted stop and copy garbage
collector can be have negligable GC time given sufficient memory free
space, allocations are still not free even in the best case, not to mention
the time to build the object being allocated (like hashing/comparing all
the values in a set).

I'd like to suggest that there is a difference between premature
optimization and avoiding flagrantly inefficient code.
If you code so that you routinely copy sequences and nested data structures
without a care, then in a serious/large system
your performance will have death by a thousand cuts.  The big O matters, at
least in some applications.

As indicated in this problem, the input is coming from a database, i.e. a
potentially large record source. My bias is that per-record processing is
always best kept to a minimum.  So inverting maps, copying sequences,
creating sets and such _*for every record*_ is just a big "nope" for me.
 And that doesn't even consider what went into the retrieval of the records
from clojure.java.jdbc/query, where every record comes back as a map unless
you do something to prevent it.

Meanwhile there were good suggestions for both abstraction and efficiency
here, thanks.  I often forget about lazy-seq and have a tendency to lean
toward loop/recur, probably from too many years using Common Lisp.  And of
course elimination of the mutable change detection hack is good too.So
nice to see the different ways people tackle the problem.


On Wed, Nov 11, 2015 at 10:02 PM, Gareth Clapperton 
wrote:

> Hey Daves
>
> I too like the map idea (and using sets for roles for that matter). But
> sticking with collections, I might do something like this
>
> (defn upsert
>   "Updates or inserts v into coll"
>   [key-fn update-fn v coll]
>   (let [k(key-fn v)]
> (letfn [(step [v [x & xs]]
>   (lazy-seq
> (cond
>   (nil? x) (when v [v])
>   (and (some? v) (= (key-fn x) k)) (cons (update-fn x v)
> (step nil xs))
>   :default (consx
>  (step  v  xs)]
>   (step v coll
>
> (defn merge-roles [p1 {:keys [project_roles] :as p2}]
>   (update-in p1 [:project_roles] #(vec (clojure.set/union (set %) (set
> project_roles)
>
> (upsert :project_id merge-roles prj-role prj-roles)
>
> Gareth
>
>
> On Wednesday, November 11, 2015 at 4:25:51 PM UTC-5, Dave Tenny wrote:
>>
>> A colleague and I are debating various things clojure as we were
>> exploring alternative ways to solve a problem.
>>
>> Here's the description of the problem that a particular function is
>> trying to solve, and the first implementation of it.
>>
>> (defn update-roles
>>   "Given a vector of maps of the form {:project_id N :project_name S
>> :project_roles [...roles...]}
>>   if there is already a map for the indicated project id/name, add
>> new-role to it and returned
>>   a copy the updated input vector, otherwise return a vector with a new
>> map entry for the newly found
>>   project and initial role.  This function is basically aggregating
>> tuples from the database."
>>   [projects project-id project-name new-role]
>>   (let [updated? (atom nil)
>>
>> projects* (mapv (fn [m]
>>   (if (= (:project_id m) project-id)
>> (do (reset! updated? true)
>> (assoc m :project_roles (conj (:project_roles
>> m) new-role)))
>> m))
>> projects)]
>> (if @updated?
>>   projects*
>>   (conj projects {:project_id project-id :project_name project-name 
>> :project_roles
>> [new-role]}
>>
>>
>> ;; (update-roles [{:project_id 1 :project_name "One" :project_roles [:own
>> ]}] 2 "Two" :edit)
>> ;; => [{:project_id 1, :project_name "One", :project_roles [:own]} 
>> {:project_id
>> 2, :project_name "Two", :project_roles [:edit]}]
>> ;; (update-roles [{:project_id 1 :project_name "One" :project_roles [:own
>> ]}] 1 "Two" :edit)
>> ;; => [{:project_id 1, :project_name "One", :project_roles 

Re: Style, Efficiency, and updating nested structure

[Erik Assum]

I would like to argue that your code has to be pretty inefficient if it's 
creating a bigger performance impact than fetching from the database. 

Erik. 
-- 
i farta

> Den 12. nov. 2015 kl. 15.36 skrev Dave Tenny :
> 
> Thanks for the replies, as always lots of interesting ways to do it in 
> clojure.  No zipper sugestions?
> 
> For my own take, I happen to like the last suggestion (Gareth's) the most I 
> think, of the ones offered so far.  It has a lispy elegance and is still 
> relatively efficient in traversals and memory allocation, compared to some 
> solutions (particular with a revision to the merge-roles implementation to 
> eliminate all the set creation, see next sentence).
> 
> Some of you rewrote the problem a bit.  For example, the 'merge-roles' 
> conversion to sets is very expensive, especially since I know that the input 
> in my original problem isn't going to offer duplicate project rules for a 
> given project ID.
> 
> On efficiency in general, it is perhaps a generational thing that people say 
> "don't prematurely optimize" so often and then cons up intermediate objects 
> with wild abandon.  And while a well crafted stop and copy garbage collector 
> can be have negligable GC time given sufficient memory free space, 
> allocations are still not free even in the best case, not to mention the time 
> to build the object being allocated (like hashing/comparing all the values in 
> a set).
> 
> I'd like to suggest that there is a difference between premature optimization 
> and avoiding flagrantly inefficient code.
> If you code so that you routinely copy sequences and nested data structures 
> without a care, then in a serious/large system
> your performance will have death by a thousand cuts.  The big O matters, at 
> least in some applications.
> 
> As indicated in this problem, the input is coming from a database, i.e. a 
> potentially large record source. My bias is that per-record processing is 
> always best kept to a minimum.  So inverting maps, copying sequences, 
> creating sets and such _for every record_ is just a big "nope" for me.And 
> that doesn't even consider what went into the retrieval of the records from 
> clojure.java.jdbc/query, where every record comes back as a map unless you do 
> something to prevent it.
> 
> Meanwhile there were good suggestions for both abstraction and efficiency 
> here, thanks.  I often forget about lazy-seq and have a tendency to lean 
> toward loop/recur, probably from too many years using Common Lisp.  And of 
> course elimination of the mutable change detection hack is good too.So 
> nice to see the different ways people tackle the problem.
> 
> 
>> On Wed, Nov 11, 2015 at 10:02 PM, Gareth Clapperton  
>> wrote:
>> Hey Daves
>> 
>> I too like the map idea (and using sets for roles for that matter). But 
>> sticking with collections, I might do something like this
>> 
>> (defn upsert 
>>   "Updates or inserts v into coll"
>>   [key-fn update-fn v coll]
>>   (let [k(key-fn v)]  
>> (letfn [(step [v [x & xs]]
>>   (lazy-seq
>> (cond
>>   (nil? x) (when v [v])
>>   (and (some? v) (= (key-fn x) k)) (cons (update-fn x v) 
>> (step nil xs))
>>   :default (consx
>> (step  v  xs)]
>>   (step v coll
>>   
>> (defn merge-roles [p1 {:keys [project_roles] :as p2}]
>>   (update-in p1 [:project_roles] #(vec (clojure.set/union (set %) (set 
>> project_roles)
>> 
>> (upsert :project_id merge-roles prj-role prj-roles)
>> 
>> Gareth
>> 
>> 
>>> On Wednesday, November 11, 2015 at 4:25:51 PM UTC-5, Dave Tenny wrote:
>>> A colleague and I are debating various things clojure as we were exploring 
>>> alternative ways to solve a problem.
>>> 
>>> Here's the description of the problem that a particular function is trying 
>>> to solve, and the first implementation of it.
>>> 
>>> (defn update-roles 
>>>   "Given a vector of maps of the form {:project_id N :project_name S 
>>> :project_roles [...roles...]}
>>>   if there is already a map for the indicated project id/name, add new-role 
>>> to it and returned
>>>   a copy the updated input vector, otherwise return a vector with a new map 
>>> entry for the newly found
>>>   project and initial role.  This function is basically aggregating tuples 
>>> from the database."
>>>   [projects project-id project-name new-role]
>>>   (let [updated? (atom nil)
>>> 
>>> projects* (mapv (fn [m] 
>>>   (if (= (:project_id m) project-id)
>>> (do (reset! updated? true)
>>> (assoc m :project_roles (conj 
>>> (:project_roles m) new-role)))
>>> m))
>>> projects)]
>>> (if @updated?
>>>   projects*
>>>   (conj projects {:project_id project-id :project_name 

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Depends on how you look at it.
>From my point of view, both examples are using an otherwise valid type hint, 
>at an invalid location, and in both cases the emitted code is nonsensical.
So I'd say that if the decision for the CLJ-1846 issue was to handle that with 
a compile time error, this one should too.


> On 12 Nov 2015, at 16:47, Alex Miller  wrote:
> 
> Neither is acceptable, so I either misunderstand or disagree with your 
> question. :) 
> 
> The code below is an invalid type hint at that location. Are you maybe saying 
> this should throw an error on definition?
> 
> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
> Which now throws an error.
> 
> 
> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
> This is :rettag in action.
> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
> 
>> On 12 Nov 2015, at 12:55, Alex Miller > > wrote:
>> 
>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>> double function object. You really want:
>> 
>> (defn timespi ^double [^double x] (* x 3.14))
>> 
>> 
>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>>  wrote:
>> Hello,
>> 
>> the following stops executing on 1.8.0-rc1 or current master-head 
>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>> CLJ-1846):
>> 
>> [/Users/reborg]$ repl
>> Clojure 1.8.0-master-SNAPSHOT
>> user=> (defn ^double timespi [^double x] (* x 3.14))
>> #'user/timespi
>> user=> (timespi 2)
>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>> 
>> It works if you enable direct linking (or if you use 1.7.0).
>> 
>> Renzo
> 
> 
> -- 
> 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/d/optout 
> .

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8

> On 12 Nov 2015, at 19:14, Nicola Mometto  wrote:
> 
> 
> Depends on how you look at it.
> From my point of view, both examples are using an otherwise valid type hint, 
> at an invalid location, and in both cases the emitted code is nonsensical.
> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
> with a compile time error, this one should too.
> 
> 
>> On 12 Nov 2015, at 16:47, Alex Miller > > wrote:
>> 
>> Neither is acceptable, so I either misunderstand or disagree with your 
>> question. :) 
>> 
>> The code below is an invalid type hint at that location. Are you maybe 
>> saying this should throw an error on definition?
>> 
>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>> Which now throws an error.
>> 
>> 
>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>> This is :rettag in action.
>> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
>> 
>>> On 12 Nov 2015, at 12:55, Alex Miller >> > wrote:
>>> 
>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>> double function object. You really want:
>>> 
>>> (defn timespi ^double [^double x] (* x 3.14))
>>> 
>>> 
>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>>>  wrote:
>>> Hello,
>>> 
>>> the following stops executing on 1.8.0-rc1 or current master-head 
>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>>> CLJ-1846):
>>> 
>>> [/Users/reborg]$ repl
>>> Clojure 1.8.0-master-SNAPSHOT
>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>> #'user/timespi
>>> user=> (timespi 2)
>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>>> 
>>> It works if you enable direct linking (or if you use 1.7.0).
>>> 
>>> Renzo
>> 
>> 
>> -- 
>> 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/d/optout 
>> .
> 

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Michael Blume]

Sorry, I'm confused now -- is the appropriate place to give a return type
hint for a function the arg list and not the function name? I've always
seen the function name hinted.

On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  wrote:

> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>
> On 12 Nov 2015, at 19:14, Nicola Mometto  wrote:
>
>
> Depends on how you look at it.
> From my point of view, both examples are using an otherwise valid type
> hint, at an invalid location, and in both cases the emitted code is
> nonsensical.
> So I'd say that if the decision for the CLJ-1846 issue was to handle that
> with a compile time error, this one should too.
>
>
> On 12 Nov 2015, at 16:47, Alex Miller  wrote:
>
> Neither is acceptable, so I either misunderstand or disagree with your
> question. :)
>
> The code below is an invalid type hint at that location. Are you maybe
> saying this should throw an error on definition?
>
> CLJ-1846 is instead a valid type hint that is in conflict with the call.
> Which now throws an error.
>
>
> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>
>> This is :rettag in action.
>> Any reason why this error should be acceptable while the CLJ-1846 one
>> isn't?
>>
>> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
>>
>> That's not a valid type hint. Var meta is evaluated, in this case to the
>> double function object. You really want:
>>
>> (defn timespi ^double [^double x] (* x 3.14))
>>
>>
>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com
>> wrote:
>>>
>>> Hello,
>>>
>>> the following stops executing on 1.8.0-rc1 or current master-head
>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix
>>> for CLJ-1846):
>>>
>>> [/Users/reborg]$ repl
>>> Clojure 1.8.0-master-SNAPSHOT
>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>> #'user/timespi
>>> user=> (timespi 2)
>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object;
>>> is abstract  user/timespi (NO_SOURCE_FILE:-1)
>>>
>>> It works if you enable direct linking (or if you use 1.7.0).
>>>
>>> Renzo
>>>
>>
> --
> 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/d/optout.
>
>
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

[ANN] Onyx 0.8.0: Automatic State Management

[Michael Drogalis]

We're pleased to release Onyx version 0.8.0, which brings with it 
primitives for
automatic state management, failure recovery, windowed computations, and 
triggers.

Onyx is a scalable, distributed, fault tolerant, high performance data 
processing platform
for handling batch and streaming workloads. It's written purely in Clojure, 
and consequently
supports idiomatic Clojure programs on top of it.

Read about the 
release: 
http://michaeldrogalis.github.io/jekyll/update/2015/11/12/Onyx-0.8.0-Automatic-State-Management.html
GitHub: https://github.com/onyx-platform/onyx

Thanks to everyone involved in this release! It was a big one!

-- 
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/d/optout.

aatree release 0.5.1--Bugs fixed!

[William la Forge]

The aatree project provides fully compatible alternatives to Clojure 
sorted-map, sorted-set and vector, with several extensions:
  - AAVector supports add/drop at any point using addn and dropn.
  - AAMap and AASet implement Reversible, Counted, Indexed and Sorted
  - CountedSequence implements Counted and do not use synchronized.
  - Lazy deserialization/reserialization provides ridiculously fast 
deserialize/update/reserialize processing typical of disk access.
  - Virtual Structures that can be larger than memory.

New in Release 0.5.2:

   - Bugs introduced in release 0.5.1 have been fixed.

https://github.com/laforge49/aatree#readme

On Clojars: https://clojars.org/aatree

Please feel free to comment on this project. Your participation would be 
most welcome.

-- 
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/d/optout.

Re: Help with idiomatic clojure.

[Erik Assum]

There is also https://github.com/logaan/vlad which helps with validation. 

Erik. 
-- 
i farta

> Den 12. nov. 2015 kl. 17.12 skrev Colin Yates :
> 
> A nicer equivalent form would be:
> 
> (cond-> []
>   this-error? (conj “It failed with this error”)
>   that-error? (conj “It failed with that error”))
> 
> However, purely for validation there are a few utilities out there already. 
> Checkout the ‘Validation’ section on http://www.clojure-toolbox.com
> 
> Also, in terms of enforcing contracts - Prismatic Schema is highly 
> recommended but hard to ‘englishify’ the errors. Failures are considered API 
> failures rather than happy-case failures.
> 
>> On 12 Nov 2015, at 16:09, Brian Forester  wrote:
>> 
>> I'm writing a very small REST application in clojure using compojure and 
>> ring.  One problem is that I don't have anyone who can review my work or 
>> provide feedback.
>> 
>> I've written a small function to validate a simple JSON request.  I'm 
>> validating the three values that are in the post and collecting the errors 
>> for return.
>> The core mechanic I've used
>>  (swap! errors str "'grepString' must not be null or empty.\n"))
>> does not seem to be a very idiomatic clojure way to solve this simple 
>> problem.
>> 
>> https://gist.github.com/BDF/8e61daf8fe8b602a248a
>> 
>> Any feedback is appreciated.
>> BDF.
>> 
>> 
>> 
>> -- 
>> 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/d/optout.
> 
> -- 
> 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/d/optout.

-- 
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/d/optout.

Help with idiomatic clojure.

[Brian Forester]

I'm writing a very small REST application in clojure using compojure and ring.  
One problem is that I don't have anyone who can review my work or provide 
feedback.


I've written a small function to validate a simple JSON request.  I'm 
validating the three values that are in the post and collecting the errors for 
return.

The core mechanic I've used

 (swap! errors str "'grepString' must not be null or empty.\n"))

does not seem to be a very idiomatic clojure way to solve this simple problem.


https://gist.github.com/BDF/8e61daf8fe8b602a248a


Any feedback is appreciated.

BDF.



-- 
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/d/optout.

Re: Help with idiomatic clojure.

[Colin Yates]

A nicer equivalent form would be:

(cond-> []
  this-error? (conj “It failed with this error”)
  that-error? (conj “It failed with that error”))

However, purely for validation there are a few utilities out there already. 
Checkout the ‘Validation’ section on http://www.clojure-toolbox.com 


Also, in terms of enforcing contracts - Prismatic Schema is highly recommended 
but hard to ‘englishify’ the errors. Failures are considered API failures 
rather than happy-case failures.

> On 12 Nov 2015, at 16:09, Brian Forester  wrote:
> 
> I'm writing a very small REST application in clojure using compojure and 
> ring.  One problem is that I don't have anyone who can review my work or 
> provide feedback.
> 
> I've written a small function to validate a simple JSON request.  I'm 
> validating the three values that are in the post and collecting the errors 
> for return.
> The core mechanic I've used
>  (swap! errors str "'grepString' must not be null or empty.\n"))
> does not seem to be a very idiomatic clojure way to solve this simple problem.
> 
> https://gist.github.com/BDF/8e61daf8fe8b602a248a
> 
> Any feedback is appreciated.
> BDF.
> 
> 
> 
> -- 
> 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/d/optout 
> .

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Given the number of bytecode/type hinting issues we've seen caused by direct 
linking and the lack of real benchmarks demonstrating its benefits, I'm also 
wondering what's the rationale between including it in the current release.


> On 10 Nov 2015, at 18:15, Ghadi Shayban  wrote:
> 
> Two points of feedback:
> 
> 
> 1) One of the reason tuples were disabled was that they polluted dispatch 
> paths.  Shouldn't we make sure that they are completely inactive?
> 
>Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still use 
> them.
> 
> 2) I get the rationale behind direct linking, but I'm lacking evidence that 
> the benefits are achieved.
> 
> 
> 
> 
> On Tuesday, November 10, 2015 at 12:30:47 PM UTC-5, Alex Miller wrote:
> Clojure 1.8.0-RC1 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
> 
> Try it via
> Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1 
> 
> Leiningen: [org.clojure/clojure "1.8.0-RC1"]
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md 
> .
> CLJ-1845  Make clojure.core/load 
> dynamic so it can be redef'ed even with direct linking
> 
> 
> -- 
> 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/d/optout 
> .

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

This is :rettag in action.
Any reason why this error should be acceptable while the CLJ-1846 one isn't?

> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
> 
> -- 
> 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/d/optout 
> .

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Renzo Borgatti]

Thanks Alex, I’ve missed the wrong type hint in that line. Now 1.8 is even 
telling me!

Cheers
Renzo

> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
> 
> -- 
> 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/d/optout.

-- 
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/d/optout.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

Neither is acceptable, so I either misunderstand or disagree with your 
question. :) 

The code below is an invalid type hint at that location. Are you maybe 
saying this should throw an error on definition?

CLJ-1846 is instead a valid type hint that is in conflict with the call. 
Which now throws an error.


On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>
> This is :rettag in action.
> Any reason why this error should be acceptable while the CLJ-1846 one 
> isn't?
>
> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
>
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
>
> (defn timespi ^double [^double x] (* x 3.14))
>
>
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
> wrote:
>>
>> Hello,
>>
>> the following stops executing on 1.8.0-rc1 or current master-head 
>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
>> for CLJ-1846):
>>
>> [/Users/reborg]$ repl
>> Clojure 1.8.0-master-SNAPSHOT
>> user=> (defn ^double timespi [^double x] (* x 3.14))
>> #'user/timespi
>> user=> (timespi 2)
>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
>> is abstract  user/timespi (NO_SOURCE_FILE:-1)
>>
>> It works if you enable direct linking (or if you use 1.7.0).
>>
>> Renzo
>>
>

-- 
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/d/optout.

Re: Help with idiomatic clojure.

[Alex Baranosky]

The main thing to note is to not use atoms for things like this. Colin's
cond-> approach is a good idea.

On Thu, Nov 12, 2015 at 4:08 PM, Colin Yates  wrote:

> One other minor point (if (seq some-sequence) true false) is preferred by
> some (I won’t say more idiomatic) than (if (empty? some-sequence) true
> false). Also, in no-errors branch you probably want to return status: 200?
>
>
> On 12 Nov 2015, at 19:44, Brian  wrote:
>
> Thanks Colin, Thanks Erik
> Exactly what I was looking for.
>
> I've updated the gist with Colin's suggestion and a bit of destructuring.
> If this project gets any bigger I will definitely look at vlad
>  and Prismatic Schema
> .
>
> BDF.
>
> On Thu, Nov 12, 2015 at 12:02 PM, Erik Assum  wrote:
>
>> There is also https://github.com/logaan/vlad which helps with
>> validation.
>>
>> Erik.
>> --
>> i farta
>>
>> Den 12. nov. 2015 kl. 17.12 skrev Colin Yates :
>>
>> A nicer equivalent form would be:
>>
>> (cond-> []
>>   this-error? (conj “It failed with this error”)
>>   that-error? (conj “It failed with that error”))
>>
>> However, purely for validation there are a few utilities out there
>> already. Checkout the ‘Validation’ section on
>> http://www.clojure-toolbox.com
>>
>> Also, in terms of enforcing contracts - Prismatic Schema is highly
>> recommended but hard to ‘englishify’ the errors. Failures are considered
>> API failures rather than happy-case failures.
>>
>> On 12 Nov 2015, at 16:09, Brian Forester 
>> wrote:
>>
>> I'm writing a very small REST application in clojure using compojure and 
>> ring.  One problem is that I don't have anyone who can review my work or 
>> provide feedback.
>>
>>
>> I've written a small function to validate a simple JSON request.  I'm 
>> validating the three values that are in the post and collecting the errors 
>> for return.
>>
>> The core mechanic I've used
>>
>>  (swap! errors str "'grepString' must not be null or empty.\n"))
>>
>> does not seem to be a very idiomatic clojure way to solve this simple 
>> problem.
>>
>>
>> https://gist.github.com/BDF/8e61daf8fe8b602a248a
>>
>>
>> Any feedback is appreciated.
>>
>> BDF.
>>
>>
>>
>>
>> --
>> 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/d/optout.
>>
>>
>>
>> --
>> 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/d/optout.
>>
>>
>> --
>> 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/d/optout.
>>
>
>
> --
> 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