Fork me on GitHub
#clojure-spec
<
2016-12-03
>
bbloom00:12:53

s/merge makes me so happy.

bbloom00:12:08

being able to just mix in key sets for various stages of the pipeline

bbloom00:12:09

beautiful.

bbloom01:12:00

the go type system has “struct embedding” which i fell in love with when working in go - lets you accomplish something similar by merging struct fields

bbloom18:12:21

i’m not quite sure yet i grok the every vs coll-of, or every-kv vs map-of stuff yet

bbloom18:12:51

is the general idea to use coll-of and map-of by default and only switch to every if your specs are too slow and you don’t need conformance

bbloom18:12:46

also - i’m now running in to a situtation where a spec is not-conforming and it’s just consuming a ton of memory producing the explanation data

arohner19:12:27

@bbloom I haven’t run into that situation, but that’s my guess

bbloom19:12:21

yeah, i get the feeling explain needs to become lazy somehow - not necessarily with thunks, but maybe with something like a that you can ask it to expand further

bbloom19:12:41

hmm, yeah - i have a structure with LOTS of structural sharing and a ton of redundant data - not unlike the clojurescript ast

bbloom19:12:14

and explain is starting to become non-useful due to the shear volume of output

bbloom19:12:32

and seemingly exponential time to return

bbloom19:12:36

or print or whatever

bbloom19:12:43

not quite able to pin down a reproduction yet

Alex Miller (Clojure team)21:12:52

You can set a custom explain printer if that becomes useful

Alex Miller (Clojure team)21:12:31

Just setting print-length will affect the default one though

Alex Miller (Clojure team)21:12:26

Re your collection question, yes that's a good first approximation

bbloom21:12:55

re: print-length - cool! thanks.

Alex Miller (Clojure team)21:12:02

You can also set coll-check-limit to further tweak what every and every-kv check

bbloom21:12:37

suuuuuppper nit-picky feedback:

bbloom21:12:10

if that first-approximation is true, that you should default to coll-of or map-of, then it seems like the more informative doc-strings should be on those, rather than every and every-kv

bbloom21:12:28

feel free to totally ignore i even said that 😛

Alex Miller (Clojure team)21:12:12

Rich always thought people should default the other way

Alex Miller (Clojure team)21:12:26

But in general most people seem to disagree :)

bbloom21:12:26

preferring the sampling kind?

bbloom21:12:45

hm, i was going back and forth on it in my head

bbloom21:12:04

seeming like sampling is the right thing if the specs are not intended to be used for contract-style checks

bbloom21:12:13

which seems true

bbloom21:12:25

but it feels wrong to get non-determinstic behavior by default

Alex Miller (Clojure team)21:12:29

I would actually prefer that the doc for both covered all the details, but you know

Alex Miller (Clojure team)21:12:51

Rich isn't big on duplication like that

bbloom21:12:52

the slippery slope of excessive doc strings - i like the short strings

Alex Miller (Clojure team)21:12:19

I have a spec reference page in the works for the docs which will help too

bbloom21:12:28

i wish the see also was metadata tho, so the cross referencing was more automatic

bbloom21:12:36

and maybe even let you see-also a spec

bbloom21:12:49

so like the options that are specified could be generated from common doc strings

Alex Miller (Clojure team)21:12:58

If wishes were fishes something something

bbloom21:12:28

heh, indeed - the simple strings are generally fine

Alex Miller (Clojure team)21:12:44

Later, shutting down for takeoff

bbloom21:12:46

aaaaannny way, i guess i’ll lean on the sampling ones & see how that feels

bbloom21:12:54

cya, have a good flight

paytonrules21:12:45

How do you spec a multi-method? Multi-spec seems like it should do it, but it only talks about spec’ing a hash with types. More specifically I have the following - but it never validates the :box parameter.

(s/fdef colliding?
  :args (s/cat :invader map? :box ::box/box)
  :ret boolean?)

(defmulti colliding? :character)

(defmethod colliding? ::small [invader box]

Alex Miller (Clojure team)22:12:05

Probably fixable but I haven't looked at it yet

paytonrules22:12:24

Kinda shocked - I had assumed it was me the whole time.

paytonrules22:12:29

Might wanna make it clearer in the docs that it’s not supported. All I could find was some confusion on multi-spec.

paytonrules22:12:38

Thanks for the help tho!

Alex Miller (Clojure team)22:12:14

Yeah, multimethod, protocols, primitive typed fns, and inlined fns will not work right now

Alex Miller (Clojure team)22:12:10

Inlined and protocols are probably not easily fixable

bbloom22:12:14

user=> (binding [s/recursion-limit 1 s/coll-error-limit 1 s/coll-check-limit 1] (clojure.test/run-tests ‘ambiparse.calc-test)) That normally returns in ~1 second, but when instrumented, it seems to be infinitely looping. jstack says: https://gist.github.com/brandonbloom/dfa559f81ad1b6d0980c120d86a2e18e

bbloom22:12:22

something seems to not be respecting the limits

bbloom22:12:40

or i’m missing a limit

bbloom22:12:19

amusingly, i’m working on a parser, soooo i’m running in to exactly the same kinds of infinite loop problems in the program i’m trying to debug 😉

derwolfe22:12:51

Hi - I'm experimenting with spec and am getting an error that I'm not understanding

RuntimeException Var clojure.test.check.generators/large-integer is not on the classpath  clojure.spec.gen/dynaload (gen.clj:21)
. Any tip as to what could be the problem? This is happening when I'm trying to exercise a simple spec I've written.

bbloom23:12:28

looking at the spec impl, it seems like there isn’t on spec checking level/depth - which might be what i want/need, not sure tho

Alex Miller (Clojure team)23:12:11

It's entirely possible some spec impl is not respecting the limit

Alex Miller (Clojure team)23:12:32

@derwolfe: you need test.check on your classpath