Why not clojure support raw string?

[Promise.]

Just like r"" or r""" """ in python.

r"""{"doc":"This is a JSON string."}"""

-- 
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: Why not clojure support raw string?

[Andy Fingerhut]

Clojure does not have Python's triple-quoted strings, that is true.  Why?
They have only come up a few times before in discussion on this Google
group, and Rich Hickey has not participated in them that I have seen, so
most likely he may simply not see much advantage to having them in the
language, vs. possible backwards-compatibility issues that might arise if
they were added.

One of the main uses of raw string literals in Python is to avoid having to
use two consecutive backslashes to get on backslash in a string, which is
most useful in regular expressions, where backslashes are quite common.
Clojure has regex literals with the syntax #"\d+" which have that feature
of Python raw string literals.

Andy

On Mon, Feb 19, 2018 at 10:46 PM, Promise.  wrote:

> Just like r"" or r""" """ in python.
>
> r"""{"doc":"This is a JSON string."}"""
>
> --
> 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.

s/valid? does not tell me if the data is valid as supplied

[Jan Rychter]

I've been using spec for a while now, in a reasonably large code base (>30k 
lines of Clojure and ClojureScript) and there is an issue that bit me 
several times.

I use conformers for coercing data that is *almost* what I need, usually 
when reading from JSON (RethinkDB). Common conformers are keyword and set. 
And it works really well, except for one problem: there is no way to know 
if data has been conformed or not.

Calling s/valid? will tell me if the data is valid *if it has been 
conformed*. But what if it hasn't? Can I use the data? Is it "valid" 
according to the spec I wrote?

This is a very real problem: I've spent considerable time chasing bugs 
where there was a code path which did not call s/conform. The data passed 
all validations done with valid? and the bug manifested itself far down the 
road, where something expected a keyword instead of a string, or a set 
instead of a vector.

Here is a specific minimal example demonstrating what I'm talking about:

(ns spectest
  (:require [clojure.spec.alpha :as s]))

(s/def ::test-spec (s/and (s/conformer keyword) keyword?))

(s/conform ::test-spec "a") ;; :a
(s/valid? ::test-spec "a") ;; true

I expected the last valid? to return false, because my code does not expect 
a string, it expects a keyword, according to the spec.

I might be missing something, but I would much rather see valid? tell me if 
the data is valid for use (as supplied) and have a separate 
valid-when-conformed? which tells me if the data is, well, valid when 
conformed. It seems to me that the current valid? that does two things is 
confusing and not very useful for contracts.

At the very least I'd really like to see a function that tells me if the 
data is valid *as supplied*, as this is the function that I'd want to use 
when enforcing contracts everywhere in my code.

Alternatively, I could stop using conformers altogether, and write explicit 
data conversion functions. That might not be a bad idea, but it seems other 
people started using conformers, too, so eventually I'll hit the same 
problem again.

--J.

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

Re: [ANN] com.walmartlabs/dyn-edn 0.1.0

[Alan Thompson]

Looks very useful.  One suggestion:  the example might be easier to read if
you included the values of the env vars, and clarified the way you specify
default values:

{:connection-pool
  {:user-name #dyn/prop [DB_USER "accountsuser"]  ; default value
"accountsuser"
   :user-pw #dyn/prop DB_PW   ; no default value
   :url  #dyn/join ["jdbc:postgresql://"
   #dyn/prop [DB_HOST "localhost"]
   ":"
   #dyn/prop [DB_PORT "5432"]
   "/accounts"]}
 :web-server
  {:port #dyn/long #dyn/prop "WEB_PORT"}}


with  environment variables:

# DB_USER 
DB_PW=change-me
DB_HOST=db.example.org
# DB_PORT 
WEB_PORT=8192


yields:

{:connection-pool
  {:user-name "accountsuser"
   :user-pw "change-me"
   :url  "jdbc:postgresql://db.example.org:5432/accounts"]}
 :web-server
  {:port 8192}}






On Fri, Feb 16, 2018 at 2:20 PM, Howard Lewis Ship  wrote:

>
> com.walmartlabs/dyn-edn 0.1.0
>
> Tiny library to allow dynamic data when parsing EDN; useful for
> configuration files.
>
> https://github.com/hlship/dyn-edn
>
> For example:
>
> {:connection-pool
>   {:user-name #dyn/prop [DB_USER "accountsuser"]
>:user-pw #dyn/prop DB_PW
>:url  #dyn/join ["jdbc:postgresql://"
>#dyn/prop [DB_HOST "localhost"]
>":"
>#dyn/prop [DB_PORT "5432"]
>"/accounts"]}
>  :web-server
>   {:port #dyn/long #dyn/prop "WEB_PORT"}}
>
>
> can use environment variables to reduce down to:
>
>
> {:connection-pool
>   {:user-name "accountsuser"
>:user-pw "change-me"
>:url  "jdbc:postgresql://db.example.org:5432/accounts"]}
>  :web-server
>   {:port 8192}}
>
>
> --
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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: s/valid? does not tell me if the data is valid as supplied

[Alex Miller]

This is exactly why we recommend that you not use conformers for coercion. 
Conformers were added primarily as a tool for building custom composite 
spec types (for example, we used it to build keys* from keys).

This is a common need though and I would be happier if spec did more to 
help you solve it in a way that minimized repetition and maximized the use 
of existing specs. I'm still thinking through what that would mean exactly. 
It's challenging right now to plug externally without rebuilding a 
significant part of spec, so that's obviously not ideal.

Ideally, you would be able to say the things that are important here:

- the spec of the incoming data (strings or whatever - JSON sourced is the 
major use case)
- the spec of the data I desire
- the coercion functions that can move from one to the other (there are 
probably a small number of these that are widely reused)
- some way to coerce+validate or coerce+conform

Building coercion into a single spec itself instead leads to the problem of 
not being able to know what the source data actually was, and that's really 
at odds with the spec philosophy and the notion of bidirectional conforming.


On Tuesday, February 20, 2018 at 4:41:38 AM UTC-6, Jan Rychter wrote:
>
> I've been using spec for a while now, in a reasonably large code base 
> (>30k lines of Clojure and ClojureScript) and there is an issue that bit me 
> several times.
>
> I use conformers for coercing data that is *almost* what I need, usually 
> when reading from JSON (RethinkDB). Common conformers are keyword and set. 
> And it works really well, except for one problem: there is no way to know 
> if data has been conformed or not.
>
> Calling s/valid? will tell me if the data is valid *if it has been 
> conformed*. But what if it hasn't? Can I use the data? Is it "valid" 
> according to the spec I wrote?
>
> This is a very real problem: I've spent considerable time chasing bugs 
> where there was a code path which did not call s/conform. The data passed 
> all validations done with valid? and the bug manifested itself far down the 
> road, where something expected a keyword instead of a string, or a set 
> instead of a vector.
>
> Here is a specific minimal example demonstrating what I'm talking about:
>
> (ns spectest
>   (:require [clojure.spec.alpha :as s]))
>
> (s/def ::test-spec (s/and (s/conformer keyword) keyword?))
>
> (s/conform ::test-spec "a") ;; :a
> (s/valid? ::test-spec "a") ;; true
>
> I expected the last valid? to return false, because my code does not 
> expect a string, it expects a keyword, according to the spec.
>
> I might be missing something, but I would much rather see valid? tell me 
> if the data is valid for use (as supplied) and have a separate 
> valid-when-conformed? which tells me if the data is, well, valid when 
> conformed. It seems to me that the current valid? that does two things is 
> confusing and not very useful for contracts.
>
> At the very least I'd really like to see a function that tells me if the 
> data is valid *as supplied*, as this is the function that I'd want to use 
> when enforcing contracts everywhere in my code.
>
> Alternatively, I could stop using conformers altogether, and write 
> explicit data conversion functions. That might not be a bad idea, but it 
> seems other people started using conformers, too, so eventually I'll hit 
> the same problem again.
>
> --J.
>
>

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

Re: [ANN] test-runner, a test runner for projects using Clojure Deps

['Avi Flax' via Clojure]

On Friday, 16 February 2018 09:47:30 UTC-5, Luke VanderHart wrote:
>
> The goal is to have a full featured, standardized test runner on a project 
> using basic Clojure Deps, without needing to introduce Boot or Leiningen 
> just for that.
>

This is great to see — I’ll give it a try — thanks!


Principal Engineer @ Funding Circle
Our mission: To build a better financial world
We’re hiring! http://app.jobvite.com/m?34fSyjwx

-- 


Our Mission: To build a better financial world

Unless specifically indicated, this e-mail is not an offer to sell or a 
solicitation of any investment products or other financial product or 
service, an official confirmation of any transaction, or an official 
statement of Funding Circle USA.  This e-mail is meant only for the 
intended recipient of this transmission, and contains trade secret 
and strictly confidential information belonging to the sender. It is 
unlawful for unauthorized individuals to review, use, copy, disclose, or 
disseminate confidential information. If you have received this e-mail in 
error, please notify the sender immediately by telephone at (415) 
813-5245 or by return email and promptly delete this message from your 
system.

-- 
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] test-runner, a test runner for projects using Clojure Deps

[Eli Naeher]

I love this, and have set it up in our latest project alongside Lein.

I've noticed a delay (~60s) after the tests finish and the results are
reported before the process exits. I'm wondering if there's a missing
call to shutdown-agents somewhere. Adding it to a shutdown hook doesn't
seem to have any effect. With lein test there is no similar delay.
Thanks,
-Eli


On Fri, Feb 16, 2018, at 9:47 AM, Luke VanderHart wrote:
> The goal is to have a full featured, standardized test runner on a
> project using basic Clojure Deps, without needing to introduce Boot or
> Leiningen just for that.> 
> https://github.com/cognitect-labs/test-runner
> 
> Feedback, bugfixes and PRs 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.

-- 
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: s/valid? does not tell me if the data is valid as supplied

[Erik Assum]

FWIW, I’ve been using https://github.com/metosin/spec-tools
on a couple of projects lately, which helps nicely with
conformance and coercion. The main devs are very helpful on #ring-swagger on 
the Clojurians slack. 

Alex, how does spec-tools measure up to your thoughts on conformance/coercion?

Erik. 
-- 
i farta

> 20. feb. 2018 kl. 16:53 skrev Alex Miller :
> 
> This is exactly why we recommend that you not use conformers for coercion. 
> Conformers were added primarily as a tool for building custom composite spec 
> types (for example, we used it to build keys* from keys).
> 
> This is a common need though and I would be happier if spec did more to help 
> you solve it in a way that minimized repetition and maximized the use of 
> existing specs. I'm still thinking through what that would mean exactly. It's 
> challenging right now to plug externally without rebuilding a significant 
> part of spec, so that's obviously not ideal.
> 
> Ideally, you would be able to say the things that are important here:
> 
> - the spec of the incoming data (strings or whatever - JSON sourced is the 
> major use case)
> - the spec of the data I desire
> - the coercion functions that can move from one to the other (there are 
> probably a small number of these that are widely reused)
> - some way to coerce+validate or coerce+conform
> 
> Building coercion into a single spec itself instead leads to the problem of 
> not being able to know what the source data actually was, and that's really 
> at odds with the spec philosophy and the notion of bidirectional conforming.
> 
> 
>> On Tuesday, February 20, 2018 at 4:41:38 AM UTC-6, Jan Rychter wrote:
>> I've been using spec for a while now, in a reasonably large code base (>30k 
>> lines of Clojure and ClojureScript) and there is an issue that bit me 
>> several times.
>> 
>> I use conformers for coercing data that is *almost* what I need, usually 
>> when reading from JSON (RethinkDB). Common conformers are keyword and set. 
>> And it works really well, except for one problem: there is no way to know if 
>> data has been conformed or not.
>> 
>> Calling s/valid? will tell me if the data is valid *if it has been 
>> conformed*. But what if it hasn't? Can I use the data? Is it "valid" 
>> according to the spec I wrote?
>> 
>> This is a very real problem: I've spent considerable time chasing bugs where 
>> there was a code path which did not call s/conform. The data passed all 
>> validations done with valid? and the bug manifested itself far down the 
>> road, where something expected a keyword instead of a string, or a set 
>> instead of a vector.
>> 
>> Here is a specific minimal example demonstrating what I'm talking about:
>> 
>> (ns spectest
>>   (:require [clojure.spec.alpha :as s]))
>> 
>> (s/def ::test-spec (s/and (s/conformer keyword) keyword?))
>> 
>> (s/conform ::test-spec "a") ;; :a
>> (s/valid? ::test-spec "a") ;; true
>> 
>> I expected the last valid? to return false, because my code does not expect 
>> a string, it expects a keyword, according to the spec.
>> 
>> I might be missing something, but I would much rather see valid? tell me if 
>> the data is valid for use (as supplied) and have a separate 
>> valid-when-conformed? which tells me if the data is, well, valid when 
>> conformed. It seems to me that the current valid? that does two things is 
>> confusing and not very useful for contracts.
>> 
>> At the very least I'd really like to see a function that tells me if the 
>> data is valid *as supplied*, as this is the function that I'd want to use 
>> when enforcing contracts everywhere in my code.
>> 
>> Alternatively, I could stop using conformers altogether, and write explicit 
>> data conversion functions. That might not be a bad idea, but it seems other 
>> people started using conformers, too, so eventually I'll hit the same 
>> problem again.
>> 
>> --J.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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.go

Re: s/valid? does not tell me if the data is valid as supplied

[Alex Miller]

On Tuesday, February 20, 2018 at 10:28:12 AM UTC-6, Erik Assum wrote:
>
> FWIW, I’ve been using https://github.com/metosin/spec-tools
> on a couple of projects lately, which helps nicely with
> conformance and coercion. The main devs are very helpful on #ring-swagger 
> on the Clojurians slack. 
>
> Alex, how does spec-tools measure up to your thoughts on 
> conformance/coercion?
>

spec-tools combines specs for your desired *output* with a coercion 
function, making the spec of the actual data implicit. I feel like this 
conflates too many things and obscures the actual input data value, which 
is the same problem the original poster had. Also, spec-tools introduces 
the notion of "type". spec intentionally avoids creating a new vocabulary 
of special words like this and in all cases relies on predicates or things 
mapped to predicates instead. I'm not a fan of this approach and I don't 
like the idea in CLJ-2116 much either - I think it's pretty unlikely this 
is where we will end up.

In general, I think a lot of the functionality in spec-tools either uses 
implementation internals that are almost certain to break as spec evolves 
or is at odds with the philosophies of spec as stated 
in https://clojure.org/about/spec (like the type vocabulary thing).

I do see the problems driving this, and I agree there is a gap to be filled 
here though. 

-- 
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] test-runner, a test runner for projects using Clojure Deps

[Luke VanderHart]

You're very likely correct about shutdown-agents, I don't think I happened 
to fire up any agents in my test code. I'll try to reproduce as soon as I 
get a chance.

On Tuesday, February 20, 2018 at 11:25:01 AM UTC-5, Eli Naeher wrote:
>
> I love this, and have set it up in our latest project alongside Lein.
>
> I've noticed a delay (~60s) after the tests finish and the results are 
> reported before the process exits. I'm wondering if there's a missing call 
> to shutdown-agents somewhere. Adding it to a shutdown hook doesn't seem to 
> have any effect. With lein test there is no similar delay.
>
> Thanks,
> -Eli
>
>
> On Fri, Feb 16, 2018, at 9:47 AM, Luke VanderHart wrote:
>
> The goal is to have a full featured, standardized test runner on a project 
> using basic Clojure Deps, without needing to introduce Boot or Leiningen 
> just for that.
>
> https://github.com/cognitect-labs/test-runner
>
> Feedback, bugfixes and PRs 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.
>
>
>

-- 
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: s/valid? does not tell me if the data is valid as supplied

[Erik Assum]

Out of curiosity, are you at liberty to discuss how Cognitect solves the 
problem of validating/coercing values at the edges of the application when you 
(Cognitect) are doing consulting?

Erik. 
-- 
i farta

> 20. feb. 2018 kl. 18:05 skrev Alex Miller :
> 
> I do see the problems driving this, and I agree there is a gap to be filled 
> here though. 

-- 
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: s/valid? does not tell me if the data is valid as supplied

[Alex Miller]

On Tuesday, February 20, 2018 at 11:24:19 AM UTC-6, Erik Assum wrote:
>
> Out of curiosity, are you at liberty to discuss how Cognitect solves the 
> problem of validating/coercing values at the edges of the application when 
> you (Cognitect) are doing consulting? 


I'm not involved with those typically and I'm not familiar with their 
information sharing agreements, so I can't personally speak to that. 
Certainly you can transform, then validate with spec as one option.

-- 
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: s/valid? does not tell me if the data is valid as supplied

[Sean Corfield]

Calling s/valid? will tell me if the data is valid *if it has been conformed*. 
But what if it hasn't? Can I use the data? Is it "valid" according to the spec 
I wrote?

If your spec includes coercions, you have inherently made the “is valid?” 
question include the coercion. Your ::test-spec accepts anything that can be 
used as the argument to keyword. This is why Cognitect keep recommending people 
do not do this. And I’m jumping into this thread because we _do_ include 
coercions in some of our specs at work… we’ve been heavy users of spec since 
the early alpha builds and we ran those alphas in production. But we are very 
conscious about our specs that coerce: we know and accept that they will work 
on “any string that can be coerced to ”. If we specifically want 
to check whether some data is  we use a different spec.

We do this for parameters in our REST API, for long, double, Boolean, date, etc 
– we have two specs for each: one that is a spec for the target type in the 
domain model (which in these cases is just defined as the appropriate built-in 
predicate), and one that is a spec for the API level (which accepts either the 
target type or a string that can be coerced to the target type). Then we use 
the appropriate spec at the appropriate “level” in our application.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Jan 
Rychter 
Sent: Tuesday, February 20, 2018 2:41:38 AM
To: Clojure
Subject: s/valid? does not tell me if the data is valid as supplied

I've been using spec for a while now, in a reasonably large code base (>30k 
lines of Clojure and ClojureScript) and there is an issue that bit me several 
times.

I use conformers for coercing data that is *almost* what I need, usually when 
reading from JSON (RethinkDB). Common conformers are keyword and set. And it 
works really well, except for one problem: there is no way to know if data has 
been conformed or not.

Calling s/valid? will tell me if the data is valid *if it has been conformed*. 
But what if it hasn't? Can I use the data? Is it "valid" according to the spec 
I wrote?

This is a very real problem: I've spent considerable time chasing bugs where 
there was a code path which did not call s/conform. The data passed all 
validations done with valid? and the bug manifested itself far down the road, 
where something expected a keyword instead of a string, or a set instead of a 
vector.

Here is a specific minimal example demonstrating what I'm talking about:

(ns spectest
  (:require [clojure.spec.alpha :as s]))

(s/def ::test-spec (s/and (s/conformer keyword) keyword?))

(s/conform ::test-spec "a") ;; :a
(s/valid? ::test-spec "a") ;; true

I expected the last valid? to return false, because my code does not expect a 
string, it expects a keyword, according to the spec.

I might be missing something, but I would much rather see valid? tell me if the 
data is valid for use (as supplied) and have a separate valid-when-conformed? 
which tells me if the data is, well, valid when conformed. It seems to me that 
the current valid? that does two things is confusing and not very useful for 
contracts.

At the very least I'd really like to see a function that tells me if the data 
is valid *as supplied*, as this is the function that I'd want to use when 
enforcing contracts everywhere in my code.

Alternatively, I could stop using conformers altogether, and write explicit 
data conversion functions. That might not be a bad idea, but it seems other 
people started using conformers, too, so eventually I'll hit the same problem 
again.

--J.


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

Key Lesson: Building CloudRepo With Clojure

[Chris Shellenbarger]

I struggled for a long time with Clojure and experiencing some of the power 
that I had heard about form others.  I realize now that it was because I 
had been so ingrained in the OO paradigm that I wasn't coding in the way 
that Clojure wanted me to.

Anyway, I've since overcome that and now that I've realized how to model 
'Data as the API' and design systems as flows of data, I have experienced a 
lot of the power of Clojure.

I wrote a post that shares what I've learned - figured it might help 
someone else down the line if they have similar struggles:

https://medium.com/@chris.shellenbarger/key-lesson-building-cloudrepo-with-clojure-99bc1c1c405e


Thanks,
Chris

-- 
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] test-runner, a test runner for projects using Clojure Deps

[Robert Levy]

Just out of curiosity, are there any plans to provide similar tooling
consistent with this for ClojureScript unit tests via Clojure Deps?

On Tue, Feb 20, 2018 at 9:10 AM, Luke VanderHart 
wrote:

> You're very likely correct about shutdown-agents, I don't think I happened
> to fire up any agents in my test code. I'll try to reproduce as soon as I
> get a chance.
>
>
> On Tuesday, February 20, 2018 at 11:25:01 AM UTC-5, Eli Naeher wrote:
>>
>> I love this, and have set it up in our latest project alongside Lein.
>>
>> I've noticed a delay (~60s) after the tests finish and the results are
>> reported before the process exits. I'm wondering if there's a missing call
>> to shutdown-agents somewhere. Adding it to a shutdown hook doesn't seem to
>> have any effect. With lein test there is no similar delay.
>>
>> Thanks,
>> -Eli
>>
>>
>> On Fri, Feb 16, 2018, at 9:47 AM, Luke VanderHart wrote:
>>
>> The goal is to have a full featured, standardized test runner on a
>> project using basic Clojure Deps, without needing to introduce Boot or
>> Leiningen just for that.
>>
>> https://github.com/cognitect-labs/test-runner
>>
>> Feedback, bugfixes and PRs 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.
>>
>>
>> --
> 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: s/valid? does not tell me if the data is valid as supplied

[Tommi Reiman]

tiistai 20. helmikuuta 2018 19.05.55 UTC+2 Alex Miller kirjoitti:
>
>
> On Tuesday, February 20, 2018 at 10:28:12 AM UTC-6, Erik Assum wrote:
>>
>> FWIW, I’ve been using https://github.com/metosin/spec-tools
>> on a couple of projects lately, which helps nicely with
>> conformance and coercion. The main devs are very helpful on #ring-swagger 
>> on the Clojurians slack. 
>>
>> Alex, how does spec-tools measure up to your thoughts on 
>> conformance/coercion?
>>
>
> spec-tools combines specs for your desired *output* with a coercion 
> function, making the spec of the actual data implicit. I feel like this 
> conflates too many things and obscures the actual input data value, which 
> is the same problem the original poster had. Also, spec-tools introduces 
> the notion of "type". spec intentionally avoids creating a new vocabulary 
> of special words like this and in all cases relies on predicates or things 
> mapped to predicates instead. I'm not a fan of this approach and I don't 
> like the idea in CLJ-2116 much either - I think it's pretty unlikely this 
> is where we will end up.
>

I'm guilty of most parts of spec-tools and the CLJ-2116, so some comments.

Spec-tools was built because there was a real-life problem (coercion) and 
spec didn't cover it. This was summer 2016 and there is still no official 
solution for this.

New vocabulary, e.g. "type": everything besides coercion (json-schema 
mappings, form-resolution etc.) is already mapped directly to predicates 
and so could the coercion. Maybe we'll change that in next version. There 
will anyway be support to spec local configuration (for both coercion & 
spec transformation) via spec data: 
https://github.com/metosin/spec-tools/issues/96.

In general, I think a lot of the functionality in spec-tools either uses 
> implementation internals that are almost certain to break as spec evolves 
> or is at odds with the philosophies of spec as stated in 
> https://clojure.org/about/spec (like the type vocabulary thing).
>

Hmmm... I know that data-specs use the functional (non-documented) version 
of the spec macros. They most likely will break at some point (but they are 
private in spec-tools too), but I guess the "functional specs" are anyway 
coming, so same things should be possible to do in the future, via just 
documented apis?

There are lot of regression, and some progression tests 

 too 
in spec-tools.

I do see the problems driving this, and I agree there is a gap to be filled 
> here though. 
>

This is good. 

There is also https://dev.clojure.org/jira/browse/CLJ-2251 by me, which 
would be my top1 wish for spec: one open `s/walk*` (replacing `s/conform*` 
and `s/unform*`) for specs and supporting different use cases: Would solve 
Jan's issues supporting just "validate", would bring first-class fast 
coercion (instead of current conform+unform is slow) and if it would be 
open, the support libs (like spec-tools) could extend by reusing the core, 
not by copying/rewriting.

Could you comment on that Alex?

Two-way coercion would be nice, but I think one-way coercion is ok too, 
much better than no coercion :) for JSON, Jackson can already write our 
Clojure back to JSON really fast, having a spec-transformation from 
clojure->JSON would be much slower anyway.

-- 
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] test-runner, a test runner for projects using Clojure Deps

['Avi Flax' via Clojure]

On Tuesday, 20 February 2018 12:10:01 UTC-5, Luke VanderHart wrote:
>
> You're very likely correct about shutdown-agents, I don't think I happened 
> to fire up any agents in my test code. I'll try to reproduce as soon as I 
> get a chance.
>

FWIW, I’m seeing the same delay, and my project doesn’t use agents — at 
least, my project’s code doesn’t. I added a dummy test that calls 
(shutdown-agents) and that removed the delay, so I guess one of my 
dependencies is starting an agent; I have no idea which.


Principal Engineer @ Funding Circle
Our mission: To build a better financial world
We’re hiring! http://app.jobvite.com/m?34fSyjwx

-- 


Our Mission: To build a better financial world

Unless specifically indicated, this e-mail is not an offer to sell or a 
solicitation of any investment products or other financial product or 
service, an official confirmation of any transaction, or an official 
statement of Funding Circle USA.  This e-mail is meant only for the 
intended recipient of this transmission, and contains trade secret 
and strictly confidential information belonging to the sender. It is 
unlawful for unauthorized individuals to review, use, copy, disclose, or 
disseminate confidential information. If you have received this e-mail in 
error, please notify the sender immediately by telephone at (415) 
813-5245 or by return email and promptly delete this message from your 
system.

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