This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-07
Channels
- # adventofcode (38)
- # aleph (1)
- # bangalore-clj (3)
- # beginners (126)
- # boot (165)
- # boulder-clojurians (5)
- # cider (42)
- # cljsrn (11)
- # clojure (203)
- # clojure-greece (6)
- # clojure-hk (1)
- # clojure-italy (11)
- # clojure-new-zealand (1)
- # clojure-nl (1)
- # clojure-russia (112)
- # clojure-spec (86)
- # clojure-uk (176)
- # clojurescript (38)
- # code-reviews (2)
- # core-async (2)
- # cryogen (2)
- # cursive (16)
- # datascript (2)
- # datomic (80)
- # events (2)
- # garden (28)
- # hoplon (115)
- # jobs (1)
- # jobs-discuss (7)
- # klipse (50)
- # lein-figwheel (15)
- # liberator (17)
- # luminus (6)
- # off-topic (8)
- # om (31)
- # onyx (26)
- # parinfer (4)
- # planck (35)
- # protorepl (26)
- # quil (2)
- # re-frame (50)
- # reagent (21)
- # ring (5)
- # rum (2)
- # schema (1)
- # untangled (29)
- # vim (10)
- # yada (40)
@bbloom I fully expect someone will write a dev lib that provides an overinstrument
or whatever shortly after 1.9 is released
it’s not a big deal - it was just 1) surprising and 2) not convincingly justified, despite being unsurprisingly/welcomely accompanied by a rationale
Can someone tell me if I’m off here?
(s/def :gj/coordinates (s/with-gen
coll?
#(s/gen #{(point-gen)})))
(s/def :gjpt/type (s/with-gen string? #(s/gen #{"Point"})))
(s/def :gjls/coordinates (s/coll-of :gj/coordinates))
Produces
[-7.4052159604840995, 12.824879014110294, -195933.59674337224],
[-7.4052159604840995, 12.824879014110294, -195933.59674337224],
[-7.4052159604840995, 12.824879014110294, -195933.59674337224]
I would think that coll-of would call a spec multiple times that has a generator and would produce unique values each time
what is the line that produced the output?
what does point-gen do?
(defn point-gen
"Generates a valid SRID:4326 point"
[]
[(- (rand 360) 180)
(- (rand 180) 90)
(- (rand 200000) 200000)])
(s/def :gj/linestring (s/keys :req-un [:gjls/type :gjls/coordinates]))
you should never use a random-generating thing in your generator
when you do that, you rob test.check from being able to a) make reproducible results and b) shrink on error
any source of randomness should come from a generator
so something like
Ok, I’ll swap that with double-in
also with-gen
is only going to call the function once to get the generator, right? so this gets a generator for #{(point-gen)}
so it calls point-gen
just once and gets #{[some, random, values]}
and then just generates coords from that single-valued set.
or does the function argument get called every time it needs a generator?
yeah, you really want to use gen/fmap or gen/bind to do this kind of thing
your point-gen could be (s/gen (s/tuple (s/int-in -180 180) (s/int-in -90 90) (s/int-in -20000 0)))
something like that
Ok, thank you. I’ll do some refactoring
I’m trying to generate GeoJSON with spec
sounds fun :)
I’ll post to it when I’m done
Thanks again
@tetriscodes interesting 🙂
@tetriscodes I have done something similar as part of one of our internal projects (just for the subset used by twitter)
If you need to nest regexs, wrap the inner in s/spec to start a new nested sequential context
@alexmiller Ok, if I don’t need regexes, is there some other way I could spec a vector of one or possibly two different elements? (s/tuple boolean? (s/? map?))
did not work.
@jfntn the ::foo inside the map is not valid according to the spec you have defined for ::foo
(also, identity is not a valid retag function - you’d hit that with gen if you tried it)
same problem
the ::foo in the map is not a valid value for the ::foo multispec
ok so the problem is that the kw that registers the mspec is also present in the map, correct?
I've got the same spec returning false for s/valid? and "Success" for s/explain-str, for the same data, which I didn't expect to be possible. Is there an obvious reason this is occurring? Can someone point me to something in the docs?
@tomc shouldn’t ever happen. can’t say more without more info
@jfntn yes - s/keys will validate specs for all keys in the map
@alexmiller ok, let me verify it's not something on my end (which it almost certainly is) and if I can't figure it out I'll give you more info here. Thanks!
Turns out I had a call to s/keys that didn't conform to s/key's api. If only there were some way to prevent that type of thing 🙂
I have created specs for spec, but it’s somewhat problematic to actually use it without encountering an infinite loop of checking
that said, I’d be happy to see a jira for whatever problem you had as that’s something we could prevent in the code
Probably not worth it. I'm doing some whacky metaprogramming for reasons not worth getting into, and it resulted in me evaluating code like (s/keys :req-un [nil])
fair enough
Thinking about a spec api so that tooling can register listeners for fn spec failures.
to clarify what I'm talking about it would be nice if this spot fired an event https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/spec/test.cljs#L103
I would need something like this to reliably report spec errors in tooling like figwheel
in JS especially because its extremely difficult and fairly invasive to get any sort of reliable top level Exception handling
Is there an efficient way to ask for a string of specific length range? The obvious (s/def ::layout-row (s/and string? #(<= 8 (count %) 11)))
breaks such-that generation
@bhauman another thing to consider is there’s really no harm in patching that for custom tooling
@lvh you will need to dive into gen for that
Is there a way to figure out which spec failed to generate when I see:
java.util.concurrent.ExecutionException: clojure.lang.ExceptionInfo: Couldn't satisfy such-that predicate after 100 tries. {}
the problem here is that test.check doesn’t have a way to do so (or doesn’t in the version used by spec at least)
basically, spec builds a big composite generator and says gimme and gets back either a sample or a failure
I know Gary has been making some changes to make this better in test.check but I haven’t had time to look at them yet
and it’s possible that we can do better if we leveraged that
there is certainly no desire for that to be information free :)
And just do (t/is …)
and forget it’s lazy, and then only way later discover that the checks were just not running and I’ve had a bug all along
yeah, I’ve done that too :)
it is intentional that it’s lazy
unlikely we will add that
in general, the lifecycle and use of generative or check-based tests is much different than example-based clojure.test tests
I’m dubious that combining them in a single suite makes sense