This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-30
Channels
- # announcements (14)
- # aws (2)
- # beginners (167)
- # calva (25)
- # cider (124)
- # cljs-dev (2)
- # cljsrn (7)
- # clojars (2)
- # clojure (113)
- # clojure-europe (2)
- # clojure-italy (6)
- # clojure-spec (30)
- # clojure-uk (90)
- # clojurescript (20)
- # code-reviews (16)
- # cursive (28)
- # data-science (2)
- # datomic (89)
- # duct (97)
- # emacs (4)
- # figwheel-main (12)
- # fulcro (37)
- # graphql (3)
- # java (3)
- # jobs (2)
- # juxt (3)
- # kaocha (37)
- # leiningen (2)
- # luminus (2)
- # off-topic (30)
- # onyx (2)
- # pathom (3)
- # qlkit (1)
- # re-frame (7)
- # reagent (2)
- # reitit (62)
- # remote-jobs (9)
- # shadow-cljs (26)
- # tools-deps (19)
- # vim (1)
- # yada (8)
Hi! clojure.spec.test.alpha/check silently ignores symbols which are not "checkable". This seems counter-intuitive to me because I'd expect it to fail when I call check on a symbol and the symbol does not have an associated spec (e.g. it is misspelled).
the definition of check looks like this:
(defn check ([] (check (checkable-syms))) ([sym-or-syms] (check sym-or-syms nil)) ([sym-or-syms opts] (->> (collectionize sym-or-syms) (filter (checkable-syms opts)) (pmap #(check-1 (sym->check-map %) opts)))))
it seems to me that the (filter (checkable-syms opts)) might better go to the no-arg variant
does this make sense?
File a jira
ok, tnx!
Hi, is there any good way to xform spec’s :problems
into something that could make sense for a human over a json api?
I suppose it depends on how technical the user is, but you could potentially use Expound here.
The default options might be too noisy (they include the specs), but this can be changed easily. You can also customize the messages in some cases. Let me know if you want help with configuring expound or just need some sample code for your use case.
tks, I basically want to convert the spec’s :problems
into something more tractable for a human
is there a rationalization why aliased specs can't be overwritten in spec1?
(s/def :user/foo string?)
(s/def :user/bar :user/foo) ;;alias
(s/exercise :user/bar 1 {:user/bar #(s/gen #{"quux"})}) ;;=> (["" ""])
(s/exercise :user/bar 1 {:user/foo #(s/gen #{"quux"})}) ;;=> (["quux" "quux"])
(s/def :user/bar string?) ;;not alias
(s/exercise :user/bar 1 {:user/bar #(s/gen #{"quux"})}) ;;=> (["quux" "quux"])
Can I somehow decouple gen-override call site from the knowledge of spec (not) being an alias?Sticking generator on the spec at s/def
time works, but I'd like to avoid nailing generator to spec.
Override for alias with custom generator works though:
(s/def :user/foo string?)
(s/def :user/bar (s/with-gen :user/foo #(s/gen #{"bar"})))
(s/exercise :user/bar 1)
=> (["bar" "bar"])
(s/exercise :user/bar 1 {:user/bar #(s/gen #{"quux"})})
=> (["quux" "quux"])
it’s a bug
there’s a ticket for it
hard to say right now
I think I actually fixed it already in spec 2, but I haven’t tested it explicitly
but no release of spec 2 yet