Clojurians Log v2

This is somewhat different for shadow-cljs, right?

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.

https://github.com/thheller/shadow-cljs/issues/508#issuecomment-565021177 YAY. so i can use conjure finaly

should've paid attention, it's been MONTHS

thanks flowthing! : )

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?

(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

s/was never/has not yet been/

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

no changes for this yet

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 ?

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

well, nope.

It’s pretty much the same, you’d specify the preloads in your build defined in shadow-cljs.edn

https://shadow-cljs.github.io/docs/UsersGuide.html#_preloads

Actually yeah, it’s under a different key

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.

Hey Everyone, I would love your input on my SO question: https://stackoverflow.com/q/61234691/59439

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?

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.

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.

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

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?

*be

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?

Got it, thanks!

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

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

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

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

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

Yes

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??

Yep

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