Fork me on GitHub
#clojure-spec
<
2016-08-19
>
lvh04:08:40

What’s the standard tactic for taming optionally recursive data structures? E.g. I have a foo that may also contain a foo under ::child; sampling the generator takes a long time because it generates huge foos

gfredericks13:08:50

huge foos because of the recursion?

lvh13:08:28

Realistically the number of recursions for real data is like, uh, 1. Most applications won’t do the recursion beyond that 1 level, but some might. Generating “deep” trees is fine and a useful test, but I’d prefer to have it generate wider trees instead (because now generation is taking a while). I’m not super sure yet if it’s actually taking a while or if it’s just CIDER’s repl view that’s super slow or both.

sparkofreason16:08:40

Having a similar issue, trying to control size of a tree. I don't think *recursion-limit* is working for me. Exercising the spec below sometimes gives results that violate the recursion limit, or even generate a stack overflow.

sparkofreason17:08:39

Seems a lot better behaved if I redefine as follows. Not sure if this is expected:

sparkofreason17:08:39

At least I'm not getting stack overflow errors with this case, though trees appear to sometimes be fairly deep regardless of *recursion-limit*, but maybe that's what the docs mean by it being a "soft limit".

bbrinck18:08:08

What do I need to require to use exercise-fn? With clojurescript 1.9.225 and test.check 0.9.0 I get the following error: #object[Error Error: Var clojure.test.check.generators/->Generator does not exist, clojure.test.check.generators never required]. This is in a namespace where I've required [cljs.spec :as s :include-macros true], [cljs.spec.test :as st :include-macros true] and [clojure.test.check.generators :as gen :include-macros true].

lvh23:08:28

alexmiller: I have not; messing with a global dynamic var seems inappropriate, I want to affect this specific recursiveness

alexmiller23:08:18

@lvh do it in a bindings