Fork me on GitHub

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.


'test in the REPL' means you type it in?


Well, I evaluate the forms in my editor, but yeah.


are you by chance using neovim and shadowcljs?


Cursive, but I have dabbled with Conjure a bit.


should've paid attention, it's been MONTHS


thanks flowthing! : )


well, nope.


somebody needs to write up a summary of what the such-that error means for spec users


@gfredericks It looks like @flowthing knows what it means. The question is: is there an easier way to find it than manual searching?

🎯 4

(I’m curious your answer to that as well.)


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

✔️ 8
Alex Miller (Clojure team)13:04:19

s/was never/has not yet been/

✔️ 20
💯 4

I was uncertain whether these situation with spec2 was similar or not

Alex Miller (Clojure team)13:04:12

no changes for this yet

Alex Miller (Clojure team)13:04:29

I did a little spike of it a while back but it was less obvious than I expected


sorry to ask again: any eta for spec2 ?

Alex Miller (Clojure team)13:04:29

no, kind of been dormant recently but we'll be back to it soon I hope

😱 4

Re: 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.

👍 4
Frank Henard17:04:37

Hey Everyone, I would love your input on my SO question:

Alex Miller (Clojure team)18:04:46

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.

Frank Henard19:04:05

Got it, thanks!

Alex Miller (Clojure team)19:04:57

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

👍 8

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.


Could be possible to use spec to validate lambda expressions?


I mean, I'm building a lambda calculus reducer


And I'm thinking if would be possible to use property based testing in order to see if it's reducing properly


But I never used spec and I don't know (yet) if that would be possible

Alex Miller (Clojure team)18:04:47

s/fspec is the tool provided, but it's often more trouble than it's worth when using gen


Do you mean than it doesn't ve of any value building such a thing?

Alex Miller (Clojure team)18:04:34

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


Then I misunderstood what functions as args in a deep way means, sorry.


fast-path to valid? is a good idea. Any other new ideas for Spec2? New syntax for fn specs still wip?

Alex Miller (Clojure team)21:04:18

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

Alex Miller (Clojure team)21:04:50

Not going to be fixed, but not an issue in spec 2


This appears to be an ok workaround:

(s/form (s/spec #(string? %) :gen #(s/gen string?)))
=> (clojure.core/fn [%] (clojure.core/string? %))


@kenny Why use #(string? %) instead of just string??


For demonstrating the bug, nothing else 🙂


Ah, so it works just fine with string??


I encountered this with a spec defined with a #(re-find ...)