I've looked at this a bit too. As you mention you can use *print-length* and *print-level* to affect this and that does work. I looked into setting these inside spec to some fixed value but that would take away control from the user. I didn't look at creating new dyn vars specifically for this, but perhaps that would be worth doing.
As of alpha12 though you can also swap the explain printer so you could do this yourself: (set! s/*explain-out* #(binding [*print-length* 3] (s/explain-printer %))) user=> (s/explain (s/coll-of int? :count 1) (range 100)) val: (0 1 2 ...) fails predicate: (= 1 (count %)) On Wednesday, September 14, 2016 at 7:38:31 AM UTC-5, Setzer22 wrote: > > Since I couldn't find a more appropiate channel to submit issues such as > this one (no github issue tracker and JIRA seems to be only for > contributors), I'm submitting it to the mailing list. > > I find myself most of the time using core.spec for big (but still > displayable) data structures. They usually take 3 or 4 pages (screens) when > fully printed. > > Whenever one of those data structures is involved in a spec error (due to > the function receiving it being instrumented), the log becomes mostly > unreadable because of the value being printed taking such a considerable > amount of space. > > I'm aware I can set a dynamic binding for *print-length* and *print-level* > variables in clojure.core to (probably, haven't tested it yet) configure > those parameters, but there are some nuances that come with that > workaround. For example, one should then re-redefine *print-level* or > *print-length* variables in their program whenever they want to print > something with a different output level. That's why I can see some value in > adding specific core.spec/*print-level* and core.spec/*print-length* > (amongst others, maybe?) to manually tune the width and depth of the data > structures printed by core.spec whenever it's reporting an error. The > default values for those should reflect the current behavior. That would > offer a very simple alternative for those cases where the value structure > really doesn't matter. > > Also I think many would benefit of a variable similar to *e, which would > hold the last core.spec instrumentation error (in its data form, not as a > string) in order to analyse it further. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
