This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-18
Channels
- # admin-announcements (1)
- # beginners (4)
- # boot (18)
- # cider (4)
- # cljsrn (17)
- # clojure (77)
- # clojure-austin (6)
- # clojure-greece (6)
- # clojure-spec (81)
- # clojure-uk (6)
- # clojurescript (32)
- # code-art (2)
- # core-async (12)
- # cursive (1)
- # datomic (1)
- # emacs (15)
- # funcool (1)
- # hoplon (108)
- # om (9)
- # onyx (83)
- # planck (1)
- # re-frame (3)
- # reagent (4)
- # specter (6)
- # spirituality-ethics (4)
- # yada (9)
I noticed (s/exercice number?)
can generate some NaN
entries on cljs
, is that by design?
So conform-spec
as described above can apparently be implemented quite easily via (defn conform-spec [s] (s/and (s/conformer #(s/unform s %)) s))
But it would probably be more valuable if a spec could give a spec of what its conform* returns
Is there a changelog for Spec? I’m looking at some of the recent commits to cljs.spec, and see that the docs have been updated. But would be great to know if there was another place to reference to see the updates.
The more I learn about Spec, the more I think it is going to be regarded one of the essential Clojure features, on par with immutable data. For instance, I found out about conformer
, and not ten minutes later had the beginning of a solution that I’ve never had for parsing JSON enums in a sane way. I shared this on #C03S1L9DN, but interested in getting feedback if I’m going at this the wrong way:
A question about spec and generators, is it able to generate data from a spec directly or does it generate data and test it against the spec? As an example I suppose that a generator for string will only generate strings, but what if you have some slightly more complicated predicates like strings with the length 3? Will it understand to only generate strings with the length three? I guess this would need some way of inverting an if statement, which sounds difficult. The main question in hence: How ”smart” can the generator be?
Well it's not magic :)
If you have (s/and string? #(= (count %) 3)) the and generator generates based on the first pred, then filters based on the subsequent ones
So it will generate random strings and keep those that are length 3
That's probably a restrictive enough filter that you'll need to supply a custom generator
@wildermuthn: I list incremental changes for each release in the announcement notes in the Clojure mailing list
@wildermuthn: not clear to me what you're asking about with conformers above
@alexmiller: s/every has a tiny typo in it causing this:
user=> (s/valid? (s/every #{:foo}) [:foo :foo])
true
user=> (s/valid? (s/every #{:foo}) 42)
true ;; incorrect
What is wrong with the following ?
(defn add []
"a")
(s/fdef add
:ret int?)
(s/instrument #'add)
(add) ;;=> "a"
Also is there a constraint on the order of things ?
Can I s/fdef
before defn
-ing a function ? Can I s/instrument-all
when I want ?
For now you have to use the functions from the clojure.spec.test
namespace like check-var
Thanks I will dig into it. Those can do "normal" testing as well right ? ie. not generative testing
So it looks like clojure.spec.test
is only for generative testing, I still have to use whatever I was using if I want to explicitly give input arguments to the tested function (ex. for things too hard to generate). Correct ?
nha: sounds right
FYI, I’m reliably reproducing the ’no such var encore/bytes?’ thing that @seancorfield reported the other day
There's an updated Encore that fixes that. Some interaction with cljx / do / defn in that case - and conflicting with a (new) core function.
But I also eliminated every single dependency conflict and that solved the other, similar problems I had after that.
So I'm not sure what the root cause is at this point.
@arohner: if two functions have the same fspec, wouldn’t they just be the same function? (or your fspec contains no interesting properties?)
seems like you’d want to reuse a spec for args and result, but a different spec for the property relating args to results
we’ve got specs for data and specs for functions which contain arg spec, return spec, and relation spec, but we don’t have a spec for args + return (signature?) without relation
@arohner: how could you verify that it’s a fn of type X -> Y in a language that doesn’t do type declaration?
Is it sufficient to hand it an X, designate whatever comes out as Y, and then go from there?
hello everyone! wondering if anybody knows of a clean way to define the spec for a map and its keys without having to repeat the list of keys again for the map spec
my first attempt was something like this:
(def style-keys
[
(s/def ::padding ::dimen-spec)
(s/def ::padding-left ::dimen-spec)
(s/def ::padding-right ::dimen-spec)
(s/def ::padding-top ::dimen-spec)
(s/def ::padding-bottom ::dimen-spec)])
(s/def ::style (s/keys :opt style-keys))
however, s/keys doesn't seem to like having :opt passed as a symbol (presumably since it's a macro)
this version compiles and works fine
(s/def ::padding ::dimen-spec)
(s/def ::padding-left ::dimen-spec)
(s/def ::padding-right ::dimen-spec)
(s/def ::padding-top ::dimen-spec)
(s/def ::padding-bottom ::dimen-spec)
(s/def ::style (s/keys :opt [::padding ::padding-left ::padding-right ::padding-top ::padding-bottom]))
however, every time I add a new key, I have to update two different places (which I'd ideally like to avoid in this case, since there'd be a lot of keys)
zpinter: i’m far from an expert (i haven’t tried spec properly yet) but i think you can just use s/and, right?
the recommendation from #C03S1L9DN was to make my own macro, which seems like a good approach, just wondering there was anything built-in
but yeah, i’d guess making your own macro is the way to go - but depending on what you’re doing, the redundancy might make sense in order to allow decomposition later
for example, you may want to limit the styles on some thing to only color related styles or only spacing styles or what not
so you’d do (s/def ::padding…, (s/def ::padding-left ... and then group those with s/and to form ::padded