Wondering if there's a precise definition of :in and :at within the context of clojure.spec failures:

...
             in: [:lines 1]
             at: [:lines]
...

Is there a recommended way of debugging built-in spec generators? I have a large graph spec in which all leaf nodes are clojure.core functions like any?, string?, boolean?, etc. and all collections are either sequential collections or maps with only optional keys, though some keys are recursive. It halts when generating data, eventually erroring (I think it runs out of memory).

> though some keys are recursive

(s/def ::foo (s/or :my-non-recursive #{:a}  :my-recursive (s/coll-of ::foo)))

(binding [s/*recursion-limit* 2]
  (s/exercise ::foo))
;=> some data

(binding [s/*recursion-limit* 10]
  (s/exercise ::foo))
;=> OutOfMemoryError GC overhead limit exceeded  clojure.lang.PersistentVector$ChunkedSeq.next (PersistentVector.java:422)

default is 4

however, s/*recursion-limit* requires recursive specs to have a non-recursive branch available to be able to stop at the limit. but you will probably get StackOverflow much earlier, if you "explicitly" omit nonrecursive branch:

(s/def ::foo (s/coll-of ::foo))
(binding [s/*recursion-limit* 10]
  (s/exercise ::foo))
;=> CompilerException java.lang.StackOverflowError, compiling:(... .clj:691:1) 

@misha Hmm, I hadn't considered that it would halt before reaching the s/*recursion-limit*. I assumed that since all keys are optional it would choose a non-recursive option. I'll try messing around with s/*recursion-limit* and see what happens. Thanks

you might get surprised how often limit=4 runs out of memory

try limit=1 and see how deep of a structure s/exercise returns, to at least somewhat calibrate your intuition

Hi there, I have a small project to transform one xml format into another (call them fmt-a and fmt-b). I thought Clojure Spec might be useful to define the shape of the data at each stage of the transformation and check the transformation works correctly for expected inputs. Then I found spec-tools and it's transformers, so I thought I'd investigate that. Although I noted that although it supports JSON it doesn't seem to support XML yet. Anyway this was going to be my approach with spec-tools: 1. parse fmt-a-xml from xml file 2. transform fmt-a-xml-data (i.e. parsed {:tag :attributes :content structure}) to fmt-a (i.e. {:fmt-a-key some-val}) 3. transform fmt-a to fmt-b (i.e. {:fmt-b-key some-val}) 4. transform fmt-b to fmt-b-xml-data (i.e. {:tag :attributes :content structure}) 5. format fmt-b-xml-data to xml file Does this sound sensible? I'm not sure how to achieve all of the above with spec-tools, but I was going to start experimenting with step 3, the core data transformation. note: there's no xml schema available for fmt-a or fmt-b, if that matters.