This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-20
Channels
- # aleph (19)
- # aws-lambda (8)
- # bangalore-clj (1)
- # beginners (13)
- # boot (179)
- # cljs-dev (12)
- # cljsjs (2)
- # cljsrn (6)
- # clojure (174)
- # clojure-italy (14)
- # clojure-nl (2)
- # clojure-russia (172)
- # clojure-spec (29)
- # clojure-uk (22)
- # clojurebridge (10)
- # clojureremote (1)
- # clojurescript (79)
- # cursive (46)
- # data-science (1)
- # datascript (8)
- # datomic (18)
- # defnpodcast (2)
- # emacs (9)
- # events (6)
- # hoplon (11)
- # klipse (13)
- # lein-figwheel (1)
- # leiningen (1)
- # luminus (1)
- # lumo (88)
- # numerical-computing (1)
- # off-topic (24)
- # om (33)
- # onyx (58)
- # protorepl (8)
- # re-frame (10)
- # reagent (26)
- # ring (8)
- # ring-swagger (7)
- # rum (22)
- # spacemacs (25)
- # specter (5)
- # uncomplicate (37)
- # untangled (75)
- # vim (17)
- # yada (3)
I have a question regarding required keysets in combination with om.next or pull queries, where required attributes might be skipped. I have formulated my questions in the following gist: https://gist.github.com/alexanderkiel/81daedb133f7939d0c88ff28dd457442
Hi! I have ns with spec's. how to load all spec names from another ns?
I want to get list of def's from particular ns
I want to print on screen available specs
names
in order to do it I need to get list of spec names
@akiel wow! yeah, sure! thanks!!!
I found that some of my spec check were running slowly and causing timeouts. If you find the same thing happening, you can use the options to specify the number of tests you want to run.
(s.t/check `my-ns/my-func {:clojure.spec.test.check/opts {:num-tests 10}})
I hope this helps one of you.probably had more to do with the volume of data generated than the number of tests
@dacopare As @gfredericks said already: keep an eye on your generators. You can also overwrite them in tests or control them globally with something like :max-gen
in coll-of
.
@gfredericks: yes, the datastructures that are input and output are very large. Limiting the number of tests is the only way I can see to mitigate this.
@dacopare there are better ways. The :max-gen option mentioned above might do it, I'm not sure. Otherwise there is gen/scale to manipulate the size parameter that a generator sees
heya guys … i’m curious if there’s an idiom for nil-able keys in (s/keys …)
wrt other namespaces? what I want to do is something like this:
(ns entity-a)
(s/def ::entity-a (s/keys :req [::b]))
(s/def ::b (s/nilable :entity-b/entity-b)) <— probably wont work
…
(ns entity-b)
(s/def ::entity-b (s/keys .... (more stuff)))
1) seems redundant to have to define :req [::b]
, where ::b is defined locally but just points to another ns
2) ::b should be nilable only from a’s point of view … so I don’t want to put nilable down inside the spec of entity-b
…
so should this really just be
(s/def ::entity-a (s/keys :req [::b]))
(s/def ::b (s/or :nil nil :val :entity-b/entity-b)
?@lwhorton did you consider making the key optional instead of making the value nilable?
i did, but in this particular case the domain is really shoddy. i don’t have time to go refactoring (yet), so entity-a can have the key, but the value might be nil. I suppose that leads to another question - is it more common to just ignore such cases with an opt key, or to capture all possible nil states?
I don't know if there's any sense of what's more common with spec yet
one of spec's core ideas is that the meaning of a key is the same everywhere, which is why you're having to define a different key
which I imagine implies that somewhere you'll have code that translates something to that new key. and if that's the case, then it shouldn't be much more difficult to instead remove the key when the value is nil
good point. or we could just have a proper domain model thought out without monkey patching and quick fixes 😉. thanks @gfredericks
If I have a fn with 2 arguments that are related for correct operation (it’s a fn-var and an argument name), can I use clojure.spec.test/check
to check it, or should I write a more traditional clojure.test.check prop?
depends on if you want to make that relationship part of the arg spec or not
via s/and
probably
I’m not sure I understand the suggestion; if I do something like (s/and ... is-a-valid-arg-name?)
I still need to know the value of the method (and random strings are extremely unlikely to be arg names) — is there something else I’m missing?
in that case you'd need to add a custom generator too
There's no way to use clojure.spec/or
or clojure.spec/multi-spec
to do what lvh wants here?
@gfredericks just one that applies to the entire arg spec. Makes sense. Thanks 🙂