This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # architecture (1)
- # babashka (52)
- # beginners (228)
- # calva (1)
- # chlorine-clover (31)
- # cider (9)
- # clj-kondo (16)
- # cljs-dev (25)
- # cljsrn (21)
- # clojure (116)
- # clojure-argentina (8)
- # clojure-europe (18)
- # clojure-france (17)
- # clojure-germany (1)
- # clojure-nl (5)
- # clojure-spec (49)
- # clojure-uk (63)
- # clojurescript (59)
- # community-development (14)
- # conjure (89)
- # core-matrix (1)
- # cursive (18)
- # data-science (1)
- # datomic (27)
- # exercism (4)
- # figwheel-main (5)
- # fulcro (38)
- # ghostwheel (8)
- # graalvm (5)
- # hoplon (2)
- # jobs-discuss (17)
- # juxt (1)
- # lambdaisland (5)
- # luminus (1)
- # lumo (9)
- # malli (7)
- # off-topic (32)
- # planck (24)
- # re-frame (14)
- # reagent (14)
- # reitit (14)
- # rum (23)
- # shadow-cljs (80)
- # spacemacs (2)
- # sql (6)
- # unrepl (1)
- # xtdb (2)
I often test my specs in the REPL by doing something like
(clojure.test.check.generators/generate (clojure.spec.alpha/gen ::foo)). Sometimes I mess up the spec such that the generator can't generate a value from my spec, and I get
Couldn't satisfy such-that predicate after 100 tries.. Is there an easier way to debug cases like this than process of elimination? If the spec is fairly large, it's can be pretty time-consuming and difficult to find the offending spec. The exception and the stack trace aren't of much help.
https://github.com/thheller/shadow-cljs/issues/508#issuecomment-565021177 YAY. so i can use conjure finaly
somebody needs to write up a summary of what the such-that error means for spec users
I don't think so. There's a feature added to such-that that enables spec to give better errors, but that was never implemented in spec
I did a little spike of it a while back but it was less obvious than I expected
no, kind of been dormant recently but we'll be back to it soon I hope
such-that -- about the only thing I've found that helps avoid that is relentlessly running
s/exercise on each spec as I write it, so that I trip over a "Couldn't satisfy" error at the earliest possible point and therefore have a really small surface of possibilities to investigate/debug. It's not perfect but it helps me, and it fits naturally in with a very tight RDD workflow that has you evaluating every piece of code as you write it.
Hey Everyone, I would love your input on my SO question: https://stackoverflow.com/q/61234691/59439
they both ultimately call the same function so I would expect perf to be pretty similar right now. we have considered fast-pathing a separate valid? path in spec 2 though and I would expect that to be the faster option.
the big differences are that a) with valid?, you can fail fast and b) with explain, you have to track a lot of additional info and accumulate it for reporting
Isn't it sort of obvious what specs might throw such-that errors? The ones that use s/and with second condition rejecting most values from the set specified by first condition?
Yes, it's often obvious, but not always, if the spec is large. An error message that points to the location where it originates would certainly be helpful. Anyway, I think the approach @U04V70XH6 proposed is the way to go for the time being.
I think it's a good idea to avoid using the word "obvious" in this kind of context. Spec is pretty complicated, and people come to it from a variety of backgrounds.
And I'm thinking if would be possible to use property based testing in order to see if it's reducing properly
s/fspec is the tool provided, but it's often more trouble than it's worth when using gen
spec is not particularly useful for checking functions as args in a deep way
out of curiosity, is there anything that can do that? Sounds like something that I call the halting problem?
@U0VQ4N5EE there are several property-based testing tools that can do this, they generate functions that satisfy the function's type
valid? is a good idea. Any other new ideas for Spec2? New syntax for fn specs still wip?
too many ideas :) fn specs dormant atm, working on other stuff, but we'll get back to it
Is this a known bug?
(s/def ::foo (s/with-gen #(string? %) #(s/gen string?))) (s/form ::foo) => :clojure.spec.alpha/unknown
This appears to be an ok workaround:
(s/form (s/spec #(string? %) :gen #(s/gen string?))) => (clojure.core/fn [%] (clojure.core/string? %))