This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-19
Channels
- # aws (2)
- # beginners (135)
- # boot (20)
- # chestnut (7)
- # cider (18)
- # clara (5)
- # cljs-dev (50)
- # cljsrn (30)
- # clojure (252)
- # clojure-italy (9)
- # clojure-losangeles (5)
- # clojure-russia (8)
- # clojure-spec (33)
- # clojure-uk (5)
- # clojurescript (32)
- # clr (4)
- # cursive (5)
- # data-science (1)
- # datascript (1)
- # datomic (40)
- # emacs (1)
- # fulcro (18)
- # graphql (11)
- # hoplon (3)
- # lein-figwheel (2)
- # lumo (47)
- # off-topic (2)
- # om-next (3)
- # onyx (10)
- # pedestal (22)
- # protorepl (6)
- # re-frame (7)
- # reagent (38)
- # ring (1)
- # ring-swagger (5)
- # rum (3)
- # spacemacs (19)
- # specter (5)
- # vim (13)
- # yada (16)
why does this result in the function to be called several times?
(s/valid? (s/fspec :args (s/cat))
(fn []
(println 'foo)))
21 times in fact
I think it's quickchecking your function to make sure it matches the spec
ok, is there any way to say that it’s fine if the function throws an exception?
because:
(s/valid? (s/fspec :args (s/cat))
(fn []
(throw (ex-info "foo"))))
no, exceptions should be … exceptional
Congrats on the 1.9 beta release! I'm just wondering how much of clojure is planned to be specced? I'm guessing it's just the macros - or are there plans to spec clojure core functions as well?
tbd both from a short-term and long-term perspective
there are several categories of fns that can’t currently be instrumented (protocols, multimethods, primitive fns, inline fns) so that limits some things
I’ve worked on others and I think it is valuable to have them. it is also pretty tricky to spec some of them, esp the higher order stuff
yeah that makes sense
so "everything" - probably out of scope - but there are plans over the long term to spec what would be useful, including the functions
I would hesitantly say yes as there are also performance things to be aware of when you load a large number of specs
right now, the core.specs.alpha has only macro specs in it and that’s loaded implicitly on first macro expansion
I think for fns, we may want to put those in a separate ns that you explicitly load if you want to instrument core
ah I see that makes sense
since core.specs.alpha is a separate lib, this is something that can evolve and be released in between clojure releases too. so if it doesn’t get done for 1.9 ga, can still make progress before the next major release
Thanks alex
@danieleneal I have almost everything spec'd in clojure.java.jdbc
and run the test suite with it instrument
d -- it's quite an overhead. When I get to my desk I can get numbers.
So I have rough numbers now: clojure.java.jdbc
has about 600 assertions. Against 1.8 it takes about 30 seconds (about 14 seconds "real" time). Against 1.9 with instrumentation it takes about 100 seconds (about 70 seconds "real" time). @danieleneal /cc @alexmiller
what does it take on 1.9 without instrumentation? :)
comparing apples to orange juice there
Let me just comment out the instrument
call to check that...
Pretty much identical. 1.8 looks a hair faster but I'd have to run the test suite a lot more times to be certain.
And the 30/100 seconds above is "user" (cpu) time. The "real" time is elapsed.
Yeah, jdbc was heavy for me, when instrumenting as well. Much, much heavier than all of our intrumenting combined.
@jeaye It has specs for all the public API and JDBC stuff tends to get called a lot in DB-centric apps 🙂 If you think it's doing something suspect in its specs that causes undue performance overhead, let me know.
hello folks! is there somewhere a wrapper for passing spec keys directly to generate? I mean without the extra nested call to s/gen
, ideally (somewhere/generate :my-ns/key)
?
@richiardiandrea exercise?
boot.user=> (s/def ::foo integer?)
:boot.user/foo
boot.user=> (s/exercise ::foo 1)
([0 0])
@seancorfield Will do. I did end up looking, when I saw how long it was taking, and the specs seemed sane to me. It might be worth digging deeper, to see why these specific specs are taking so long. If I had to guess, it's the extensive usage of s/or
and s/cat
with s/*
, wheras just about every spec we have is a s/keys
or a clojure.core predicate.
Good point. I might look at refactoring the specs to make them more efficient...