This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-04
Channels
- # adventofcode (100)
- # announcements (7)
- # architecture (1)
- # aws (14)
- # beginners (209)
- # calva (30)
- # cider (5)
- # cljdoc (2)
- # cljs-dev (37)
- # cljsrn (2)
- # clojure (133)
- # clojure-dev (20)
- # clojure-finland (1)
- # clojure-italy (10)
- # clojure-nl (19)
- # clojure-spec (56)
- # clojure-uk (49)
- # clojurescript (57)
- # clojurex (8)
- # core-async (2)
- # core-logic (1)
- # cursive (38)
- # data-science (19)
- # datomic (28)
- # devcards (3)
- # duct (8)
- # emacs (28)
- # figwheel (1)
- # figwheel-main (31)
- # fulcro (2)
- # jobs (1)
- # kaocha (1)
- # klipse (2)
- # mount (6)
- # nrepl (43)
- # off-topic (20)
- # pathom (3)
- # pedestal (1)
- # re-frame (15)
- # ring-swagger (1)
- # shadow-cljs (47)
- # spacemacs (19)
- # sql (20)
- # tools-deps (58)
- # unrepl (13)
- # vim (5)
Well, not in spec
Maybe there is in test.check
Don't have any continuous stat distributions
You could make them using fmap from something we do have
Unclear what kind of shrinking and growth you'd want in many cases
I think it is fairly straightforward to take a uniform random number generator for a float in the range [0, 1] and turn it into a generator for any distribution that has a function whose CDF you know how to evaluate. This page has what it claims is a very accurate approximation of the normal distribution CDF: https://web.archive.org/web/20151030215612/http://home.online.no/~pjacklam/notes/invnorm/#Pseudo_code_for_rational_approximation
I haven't checked out their implementation but kixi stats lib claims to implement this and many other distributions: https://github.com/MastodonC/kixi.stats
Will the decomplecting of schema/structure from selections/context be there in 1.11, or will it get in earlier?
@jaihindh.reddy The whole point of clojure.spec
being developed and delivered as a separate library is that it is no longer tied to specific Clojure versions.
While that is true, spec
does come in the clojure jar if I'm not mistaken, hence my doubt.
no, it does not
it’s a dependency, which you can independently update
we’ve updated spec two or three times since 1.9 for example
but it’s likely to be in a different namespace so will be a little trickier to use - we’ve spent some time thinking through that, and probably will require some more
Is there some valid-or-explain
function that I can easily use in my function's {:pre [(valid-or-explain ::spec %)]}
context?
Having s/valid?
in there as suggested in the guide is nice, but if I cannot see what it is complaining about, it does not help much... 😞
s/assert
gotta be careful using s/assert
in pre/post-conditions because if a nil input is valid, it'll return it (nil), causing the pre/post-condition to fail
@urzds if you want this behavior in pre/post-conditions it should be very easy to write a small function that does it
Well :pre
/ :post
only take effect if *assert*
is true...
Yes, but the same caveat essentially applies -- you don't get the check in all cases.
Your point about nil
is a good one -- I hadn't thought about that.
If you want the check always performed, write it as code in the body of the function. If s/assert
works for you (not nil
values, (s/check-asserts true)
has been run), that's probably a reasonable approach -- otherwise you'll have to write your own variant of s/assert
. Or perhaps write an fspec
for the function and instrument
it?
What would be a good way to check whether a collection contains certain elements? I.e. I have [{:name "a"}{:name "b"}{:name "c"}]
and I want to ensure that the collection always contains at least one element with :name "a"
and one with :name "b"
.
(Also note: The element's maps contain more keys than just :name
, so I cannot use :distinct
.)
Would it be reasonable to change the structure to a map where name moves up to keys?
I don’t assume it is reasonable. Just asking if it is.
Was thinking about that initially, but I want to expose the data structure using GraphQL, and that can afaik only query for predefined keys.
I’ve run into that recently :)
maybe something like this for your uniqueness constraint, and easy to add your other constraint
(s/def ::names
(s/and (s/coll-of (s/keys :req-un [::name]))
#(apply distinct? (map :name %))))
(s/explain ::names [{:name "a"} {:name "b"}])
(s/explain ::names [{:name "a"} {:name "a"}])
@taylor: (s/and #(some (fn [x] (= (:name x) "a")) %) #(some (fn [x] (= (:name x) "b")) %))
?
(s/def ::names
(s/and (s/coll-of (s/keys :req-un [::name]))
#(let [names (map :name %)]
(and (apply distinct? (map :name %))
(clojure.set/superset? (set names) #{"a" "b"})))))
here's another way, not necessarily any better thoughand you may prefer to break each condition into its own predicate like your first example
the explain
output for invalid inputs will likely be easier to understand if the predicates are separated
i.e. if they're all combined the explain
output isn't going to tell you exactly which condition failed
coll-of has a :distinct option fyi
oh, I guess you’re a level off of that