This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-14
Channels
- # admin-announcements (2)
- # beginners (8)
- # boot (75)
- # clara (2)
- # cljs-dev (3)
- # cljsjs (39)
- # cljsrn (1)
- # clojure (75)
- # clojure-brasil (3)
- # clojure-dusseldorf (13)
- # clojure-gamedev (1)
- # clojure-mexico (1)
- # clojure-quebec (5)
- # clojure-russia (30)
- # clojure-sg (3)
- # clojure-spec (25)
- # clojure-uk (65)
- # clojurescript (36)
- # core-async (1)
- # cursive (15)
- # data-science (6)
- # datomic (38)
- # devcards (29)
- # editors (1)
- # emacs (11)
- # funcool (6)
- # hoplon (43)
- # immutant (48)
- # lambdaisland (2)
- # leiningen (9)
- # mental-health (4)
- # mount (1)
- # numerical-computing (1)
- # off-topic (4)
- # om (19)
- # onyx (1)
- # pedestal (1)
- # proton (1)
- # re-frame (21)
- # reagent (1)
- # specter (8)
- # sql (3)
- # testing (14)
- # untangled (9)
- # yada (31)
Hi. Is there a way to use spec to generate maps with "dependent" properties. For example, suppose my map spec requires than both :a and š contain strings that have to be the same length?
That should be - Is there a way to use spec to generate maps with "dependent" properties. For example, suppose my map spec requires than both :a
and :b
contain strings that have to be the same length?
@mjmeintjes: Well, you can use s/and
to restrict what a spec generates but that might not be the easiest way to make the generator work...
Hmm, perhaps it's OK after all:
boot.user> (require '[clojure.spec :as s])
nil
boot.user> (s/def ::a string?)
:boot.user/a
boot.user> (s/def ::b string?)
:boot.user/b
boot.user> (s/def ::foo (s/and (s/keys :req [::a ::b]) #(= (count (::a %)) (count (::b %)))))
:boot.user/foo
boot.user> (s/exercise ::foo)
([#:boot.user{:a "", :b ""} #:boot.user{:a "", :b ""}] [#:boot.user{:a "z", :b "S"} #:boot.user{:a "z", :b "S"}] [#:boot.user{:a "GF", :b "y8"} #:boot.user{:a "GF", :b "y8"}] [#:boot.user{:a "c5kf9D7nt88PhP2zRiIj", :b "Ax9Ua1vd561LvuWZ0o5r"} #:boot.user{:a "c5kf9D7nt88PhP2zRiIj", :b "Ax9Ua1vd561LvuWZ0o5r"}] [#:boot.user{:a "", :b ""} #:boot.user{:a "", :b ""}] [#:boot.user{:a "yaLME3MI4uSh0", :b "FIxs99gp43jSe"} #:boot.user{:a "yaLME3MI4uSh0", :b "FIxs99gp43jSe"}] [#:boot.user{:a "9", :b "3"} #:boot.user{:a "9", :b "3"}] [#:boot.user{:a "f7nOvuwZ30U000f", :b "3enZpUsZXP9ZVX1"} #:boot.user{:a "f7nOvuwZ30U000f", :b "3enZpUsZXP9ZVX1"}] [#:boot.user{:a "8aDmY08S8Q", :b "rHFcc5rAN9"} #:boot.user{:a "8aDmY08S8Q", :b "rHFcc5rAN9"}] [#:boot.user{:a "Ds8zm6", :b "yM0N6p"} #:boot.user{:a "Ds8zm6", :b "yM0N6p"}])
@seancorfield: Great, thanks! Looks promising, I'll investigate further.
After converting some property-based tests to use specās generators, I noticed that some of the tests became much slower. Investigation reveals that the growth characteristics of specās generators can be quite different from those of test.check. Hereās an example:
In most cases I doubt the difference would be very noticeable, but in my case two such generated integer values were being used as the dimensions of a two-dimensional matrix structure, so the size really blew up quickly.
I can see a rationale for making the growth a little steeper than the test.check version, but this seems a bit severe. š
I would say, in this case where the amount of data you test is N-squared based on random generated values, you probably want a custom generator that heavily restricts those dimension values?
How big, realistically, is a matrix you would be handling?
Oh, sure ā¦ Iāve done exactly that, now. Just wondering whether this is an appropriate default.
Given the actual behavior over 1000 iterations, youād run into problems even if the amount of data was linear wrt the integer value.
And given that the visible symptom is just āmy test run seems to just stallā itās a bit confusing.
(Oh, and ā¦ my first attempt at constraining the generator was just to slap a #(< % 25)
predicate on there, and then I got sporadic "Couldn't satisfy such-that predicate after 100 triesā failures. Which was easy enough to fix, but still leads me to think that the generator growth is just too fast.)
what is the justification of having spec in separate namespaces than the actual functions?
@tmtwd: per my earlier comment https://clojurians.slack.com/archives/clojure-spec/p1468450981002667
What happened to instrument-ns
in alpha10? Not possible anymore?
Ah, awesome.
Ah, Iāve figured out whatās going on with the growth rate of (s/gen pos-int?)
mentioned above: some of the generators for built-in predicates use test.check functions that ignore the size guidance. This means (I think) that they wonāt shrink properly when an error is found: https://github.com/clojure/clojure/blob/d920ada9fab7e9b8342d28d8295a600a814c1d8a/src/clj/clojure/spec/gen.clj#L128-L185
@alexmiller: Iād love to hear your thinking on this when you get a chance. Discussion starts at https://clojurians.slack.com/archives/clojure-spec/p1468507432002694