Fork me on GitHub
#clojure-spec
<
2020-04-15
>
flowthing09:04:40

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.

Aron12:04:44

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

flowthing12:04:35

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

Aron12:04:27

are you by chance using neovim and shadowcljs?

flowthing12:04:49

Cursive, but I have dabbled with Conjure a bit.

Aron12:04:30

should've paid attention, it's been MONTHS

Aron12:04:46

thanks flowthing! : )

Aron15:04:21

well, nope.

gfredericks12:04:55

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

potetm13:04:32

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

🎯 4
potetm13:04:51

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

gfredericks13:04:41

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
gfredericks13:04:42

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

mpenet13:04:50

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

32
😱 4
seancorfield17:04:51

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: https://stackoverflow.com/q/61234691/59439

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
vlaaad17:04:14

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?

flowthing06:04:55

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.

zane18:04:45

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.

bbuccianti18:04:22

Could be possible to use spec to validate lambda expressions?

bbuccianti18:04:41

I mean, I'm building a lambda calculus reducer

bbuccianti18:04:29

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

bbuccianti18:04:56

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

bbuccianti18:04:40

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

Aron19:04:57

out of curiosity, is there anything that can do that? Sounds like something that I call the halting problem?

nwjsmith19:04:46

@U0VQ4N5EE there are several property-based testing tools that can do this, they generate functions that satisfy the function's type

Aron19:04:59

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

ikitommi19:04:35

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

kenny21:04:23

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

4
kenny21:04:30

This appears to be an ok workaround:

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

seancorfield21:04:50

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

kenny21:04:18

For demonstrating the bug, nothing else 🙂

seancorfield22:04:50

Ah, so it works just fine with string??

kenny22:04:27

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