@alexmiller sorry, meaning that spec would, e.g., require test.check >= 0.10.0

you made a comment a few weeks back that implied that wouldn't be acceptable

@misha 🙂 Thanks. Im just concerned about the name explosion when composing up the tree

@gfredericks I wouldn’t make a range version but we could certainly bump the requirement

the difference between those two things is whether a max version is specified?

I just don’t like version ranges

No one likes version ranges 🙂

The only people that like version ranges are people that haven’t used them :)

👍 thanks

I'm looking to do some visualization of specs and by default would think using the reader would be the most straight forward way to consume/read the specs. Is there a better way? A library perhaps that produces a higher level representation? Thoughts?

@kahunamoore I have not used this tool, and not sure if it is what you are looking for, but it sounds at least related: https://github.com/jebberjeb/specviz

Learned about it from Stuart Halloway's talk "REPL driven development": https://github.com/matthiasn/talk-transcripts/blob/master/Halloway_Stuart/REPLDrivenDevelopment.md

Oh, I didn't know there was a transcript of that! Cool!

yesterday I helped a coworker spec some financial calc functions, then we immediately found some bugs by checking them 👏

aside: will the default generator for number? predicate generate all/most numeric types (like ratios)?

doesn’t seem like it generates ratios

Would it make sense if Spec could aid in producing human readable errors? https://gist.github.com/borkdude/89799a764a89af5c0be1a5745be58b4d

@borkdude related: https://dev.clojure.org/jira/browse/CLJ-2115

the above obviously does not work

I could use this and digg into the meta, but I’d prefer not to

what problem are you trying to solve?

I output form-controllers based on the type of a specification. So for simple spec definitions like (spec/def ::placeholder string?) I can output a textfield because I know it’s a string with (type the-def), but for definitions that use with-gen; type returns nil

@hkjels Can you talk more about how you determine the type in the simple case? Are you inspecting the spec itself, or an example generated value?

Also, that generator above doesn’t generate valid values: (fn? nil) is false

If you want a “maybe-fn”, perhaps s/nilable would help?

he’s returning (constantly nil), which is a function

ah

doh

I feel like you should still be driving from the spec, not the generator

yeah, not sure how though

(you should also be using ifn?, not fn? btw)

Agreed, @hkjels if I were trying to generate forms based on the spec, I’d look at introspecting the specs using s/form. Obviously it’s be hard with all possible specs

but if you have a subset of forms in your app, you could reasonably inspect them and generate the cases that interest you

well in this case, s/form doesn’t currently work on predicates

(pending patch to fix that)

ahh, nice

But s/form returns something sensible for ::placeholder, yes?

And ::maybe-fn

You could parse those (probably using specs!!) and then build cases based off that

you could use spec specs for that :) (CLJ-2112)

ftw

🙂

🙂

here you see what I’m trying to achieve for all kinds of elements

it currently works for buttons, since there’s no atoms etc in use

Ohh, shoot. I got to run

@andy.fingerhut Thanks! I remember reading/hearing about it but Google failed me - too many spec tutorials, docs and other misses.

ohh, that nonconforming is just some cruft left there from trial and error

@hkjels would (spec/* (s/alt string? ::hiccup)) work?

Need to label the branches @gfredericks ^

yeah that sounds truthful