This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-07
Channels
- # announcements (3)
- # beginners (124)
- # calva (60)
- # cider (81)
- # cljs-dev (65)
- # cljsrn (1)
- # clojure (268)
- # clojure-dusseldorf (2)
- # clojure-europe (3)
- # clojure-italy (9)
- # clojure-losangeles (1)
- # clojure-nl (22)
- # clojure-russia (3)
- # clojure-spec (24)
- # clojure-uk (34)
- # clojurescript (72)
- # code-reviews (8)
- # cursive (20)
- # datomic (32)
- # fulcro (49)
- # jobs (1)
- # jobs-discuss (15)
- # juxt (10)
- # lein-figwheel (10)
- # nrepl (4)
- # off-topic (37)
- # overtone (1)
- # portkey (2)
- # protorepl (8)
- # random (1)
- # re-frame (1)
- # reagent (43)
- # reitit (8)
- # ring (16)
- # ring-swagger (2)
- # rum (6)
- # shadow-cljs (63)
- # specter (2)
- # testing (32)
- # tools-deps (32)
- # unrepl (1)
- # vim (3)
Is there a way to limit the size of the a map generated from (gen/generate (s/gen map?))
?
no, but you can use something like (s/map-of any? any? :gen-max 5)
is there a better way of making a transducer spec than ifn?
?
e.g. this works, but it shouldn’t:
(s/conform (:ret (s/get-spec `map)) [1 2 3])
[:transducer [1 2 3]]
I’ve looked at it, and generally I’d say no
this is well outside the sweet spot for spec
I'm seeing strange behavior when running clojure.spec.test.alpha/check
on an fdef
'ed function. I have a prn
as the first line in my function that prints out the size of the args. When the generative tests first start running, I get print statements out rapidly. After running for a few seconds, the print statements slow down to once every second. After 10-20s more, they speed up again. This goes on for about 10 mins until check
returns. At first I thought it was due to test.check generating large maps so I changed the :args
in my fdef
to use (s/map-of any? any? :gen-max 5)
. Then I thought it was a JVM memory issue but (.maxMemory (Runtime/getRuntime))
says the JVM has over 7gb available. I haven't seen this behavior with spec check
before. Any ideas on what could cause this?
sounds awfully like GC churn to me
do you have an fspec anywhere?
you can add -verbose:gc to watch the gc
you could isolate just the gen on the args if you suspect that it’s it
something like
(gen/sample (s/gen (:args (s/get-spec `foo))) 1000)
Generating the args like you have there takes about 30s. I'll add the gc flag to see if it sheds any light.
Added the gc flag. I get a message that looks like this [GC (Allocation Failure) 2477246K->1068161K(3133952K), 0.1575999 secs]
printed out every second or so.
This is what the output with the -verbose:gc flag looks like https://pastebin.com/raw/XCxMykgq. The numbers are the count
on the two args this function takes.
I have a map like:
{::kind :bool
::default true}
that, given a different ::kind
, might need a different predicate for ::default
. E.g.:
{::kind :string
::default "foo"}
What's the best way to model this in spec? I thought multi-specs would work, but I'm still struggling with the fact that the name of the spec I pass into s/keys needs to match the key, which makes overloading ::default
difficult@lilactown I've done this with s/or
specs