This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-13
Channels
- # aleph (2)
- # announcements (1)
- # beginners (133)
- # cider (29)
- # cljdoc (9)
- # cljs-dev (2)
- # cljsjs (3)
- # cljsrn (1)
- # clojure (146)
- # clojure-dev (26)
- # clojure-europe (3)
- # clojure-italy (26)
- # clojure-japan (6)
- # clojure-nl (76)
- # clojure-spec (4)
- # clojure-uk (42)
- # clojurescript (17)
- # cursive (43)
- # datascript (1)
- # datomic (28)
- # emacs (4)
- # figwheel-main (13)
- # fulcro (26)
- # hyperfiddle (2)
- # jobs (9)
- # jobs-discuss (6)
- # leiningen (1)
- # mount (5)
- # onyx (8)
- # pathom (5)
- # pedestal (2)
- # re-frame (52)
- # reagent (21)
- # reitit (58)
- # ring-swagger (24)
- # shadow-cljs (95)
- # sql (14)
- # test-check (10)
- # yada (18)
I find it tricky to quickly find the cause when I get “clojure.lang.ExceptionInfo: Couldn’t satisfy such-that predicate after 100 tries. {}” back from generators. I can find it using binary search but is there a better technique for debugging these generator errors?
@steveb8n is this a (gen/such-that ...)
that you wrote yourself, or that spec wrote for you?
@gfredericks using gens from specs (I hardly ever use such-that gens). To me this is the hardest part of using generators so any tricks (or context data in the error) would help
@steveb8n there's a ticket somewhere describing that problem I think -- I added extra optional args to gen/such-that
so that spec could add explanatory information to exceptions, but I don't believe that's been taken advantage of by spec.
and in any case it's only released in the alpha versions 😕
someday I should just give up and release whatever's on master so at least there's not that problem anymore
hah, I thought this might be the case. I also thought that providing useful debug data would be tricky since specs can vary wildly. in lieu of that, how do you hunt these down? binary search (with knowledge of the specs to guide you) or some other cleverness?
I haven't personally used spec a lot
I think knowing that s/and
is the most likely culprit is usually helpful
and thinking about generation whenever you write s/and
in the first place