This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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)))
ok, is there any way to say that it’s fine if the function throws an exception?
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?
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
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
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
@danieleneal I have almost everything spec'd in
clojure.java.jdbc and run the test suite with it
instrumentd -- 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
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.
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
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/*, wheras just about every spec we have is a
s/keys or a clojure.core predicate.