This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-25
Channels
- # 100-days-of-code (3)
- # beginners (80)
- # cider (53)
- # cljdoc (9)
- # cljs-dev (66)
- # cljsrn (6)
- # clojure (108)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (9)
- # clojure-losangeles (2)
- # clojure-nl (4)
- # clojure-spec (40)
- # clojure-uk (46)
- # clojurescript (60)
- # cursive (119)
- # datomic (28)
- # emacs (10)
- # events (1)
- # figwheel-main (21)
- # fulcro (16)
- # hyperfiddle (10)
- # immutant (2)
- # leiningen (1)
- # liberator (5)
- # nyc (1)
- # off-topic (36)
- # onyx (4)
- # pedestal (52)
- # portkey (5)
- # re-frame (11)
- # reagent (11)
- # shadow-cljs (46)
- # sql (1)
- # unrepl (2)
For a cat
spec, the in
refers to the to the position of the bad data before conformance
but for a keys*
spec, it seems to refer to the position of the bad data after conformance.
Why is it different? https://gist.github.com/bhb/a7ba32e6965bebecc94020f10751ec58
I wonder if it's because of this https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/alpha.clj#L1787
>takes the same arguments as spec/keys and returns a regex op that matches sequences of key/values, converts them into a map, and conforms that map
Ah, thanks! Although that explains the mechanism of why the two are different, I’m still not sure on the reasoning 😉
same but that's out of my depth 🙂 I only noticed the keys*
impl. would seem to cause this behavior
I suppose it may be just to make the final conform step easier, when the input has already been conformed to a map :man-shrugging:
Yeah, maybe! The downside is that when I want to locate the source of the bad data, the in
value is inconsistent in it’s format. In particular, it’s hard to make a custom printer like Expound be able to locate the bad data
Hm if I define a spec, it requires that components are already defined. So if I have mutually recursive spec, do I just define one of the components at the top with bogus spec?
I've run into this issue before with a recursive spec, and I think it involved a call to s/spec
inside the recursive spec definition
I’m not sure what you mean by it requiring that components are already defined. Certainly something recursive like this works fine:
(s/def ::json
(s/or :string string?
:list ::json-list
:map ::json-map))
(s/def ::json-list
(s/coll-of ::json :kind vector?))
(s/def ::json-map
(s/map-of ::json ::json))
note that in some cases it doesn't work in cljs. e.g.: https://github.com/metosin/reitit/issues/127
Hello folks I am having a hard time reading this spec error, I think I need some help in understanding what is wrong:
#### [{:spec #object[cljs.spec.alpha.t_cljs$spec$alpha23581], :clojure.test.check/ret {:shrunk {:total-nodes-visited 0, :depth 0, :pass? false, :result #error {:message Call to #'lambda.response/error-map did not conform to spec:
val: "Invalid body" fails at: [:args] predicate: (cat :message string? :data (? (nilable map?)))
:cljs.spec.alpha/spec #object[cljs.spec.alpha.t_cljs$spec$alpha23551]
:cljs.spec.alpha/value "Invalid body"
:cljs.spec.alpha/args "Invalid body"
:cljs.spec.alpha/failure :instrument
, :data {:cljs.spec.alpha/problems [{:path [:args], :pred (cljs.spec.alpha/cat :message cljs.core/string? :data (cljs.spec.alpha/? (cljs.spec.alpha/nilable cljs.core/map?))), :val Invalid body, :via [], :in []}], :cljs.spec.alpha/spec #object[cljs.spec.alpha.t_cljs$spec$alpha23551], :cljs.spec.alpha/value Invalid body, :cljs.spec.alpha/args Invalid body, :cljs.spec.alpha/failure :instrument}}, :result-data {:clojure.test.check.properties/error #error {:message Call to #'lambda.response/error-map did not conform to spec:
that spec looks like it may be for a variadic function, so maybe this is related https://dev.clojure.org/jira/browse/CLJS-2793
Let me see if that's the issue
Well it seems like things are working with just a non-variadic function, however I am not sure my bug is related to the above
Yep it is relate, I can reproduce it.
val: "Invalid body" fails at: [:args] predicate: (cat :message string? :data (? (nilable map?)))
{:path [:args], :pred (cljs.spec.alpha/cat :message cljs.core/string? :data (cljs.spec.alpha/? (cljs.spec.alpha/nilable cljs.core/map?)))
This is saying that the args (i guess ur function args)
are being given the value Invalid body
and failing your spec
https://clojuredocs.org/clojure.spec.alpha/cat Tbh I don’t really understand how this works
@richiardiandrea sorry i’m not much help haha
that predicate is supposed to match one arguments as string and optionally a data field
(s/fdef error-map
:args (s/cat :message string? :data (s/? (s/nilable map?)))
:ret :tools.lambda.response/error-map)
it was [message & [data]]
it could be related to that JIRA I mentioned above about CLJS, instrumentations, and variadic functions
Yep left a comment there, I can reproduce it here...