This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-21
Channels
- # beginners (5)
- # boot (15)
- # capetown (1)
- # chestnut (2)
- # cljs-dev (9)
- # cljsjs (3)
- # cljsrn (1)
- # clojure (190)
- # clojure-brasil (2)
- # clojure-greece (14)
- # clojure-italy (3)
- # clojure-poland (8)
- # clojure-romania (1)
- # clojure-russia (2)
- # clojure-serbia (3)
- # clojure-spec (38)
- # clojure-uk (98)
- # clojure-ukraine (2)
- # clojurescript (65)
- # clojurex (1)
- # core-async (16)
- # cursive (16)
- # datomic (3)
- # defnpodcast (7)
- # emacs (11)
- # funcool (2)
- # hoplon (16)
- # jobs (1)
- # leiningen (4)
- # lumo (9)
- # off-topic (2)
- # om (1)
- # other-languages (1)
- # protorepl (1)
- # re-frame (50)
- # reagent (16)
- # reitit (32)
- # remote-jobs (1)
- # rum (1)
- # shadow-cljs (73)
- # spacemacs (36)
- # specter (21)
- # sql (6)
- # unrepl (107)
- # untangled (4)
@hiredman yea, that makes sense. unfortunately wasn't my problem but i figured it out anyway (something unrelated)
the error message i was getting from spec was unintelligible but i just massaged the code, fixed any issues i saw via manual inspection and it eventually went away
narrowed it down to instrument
actually doing more than I figured it would. looks like it exercises the instrumented with some values that the user itself isn't passing in. this was a bit surprising to say the least
kept trying to find where the ((nil))
value was coming from in my code/ how that was even possible etc etc
@johanatan If you instrument
a higher-order function -- one that takes a function as an argument -- then it will use generative testing, as I understand it.
with coll-of, is there a way to say: this collection ca be empty, but it can't be nil i.e. [] is okay, but nil is NOT okay
@mpenet: yeah, thanks, I should have run that test, turns out bug was elsewhere and I was misattributing it
@seancorfield it was a higher-order function in this case. any idea the reasoning behind using generative testing for this case? is it just a 'hack' since the function inputs cannot be inspected to a level of detail necessary for verification?
I thought that was explained in the Spec Guide on the web site @johanatan? I certainly wouldn't say it was a 'hack'. It seems perfectly reasonable to me. How else would you verify that a function you're passing as an argument conforms to its spec in this situation?
I personally wished it was like this, now I almost always spec hof as ifn? for instrumentation because of this, which makes it a bit useless
@seancorfield it probably is explained but i haven't read the guide from beginning to end so could've missed it. well, yea, in a dynamic language this probably can't be done (except perhaps by inserting metadata onto anonymous functions at their definition sites and then reading it back out at the spec check sites [which now that I mention it, does sound like a better way if it would be possible to impl])
[but by 'hack' i meant, an unfortunate edge where the abstraction leaks due to limitations of the underlying system being modified]
@johanatan Not quite.
I’m validating on (s/or :fn fn? :keyword keyword? :spec s/spec?)
is there a neater way?
I'm doing some GUI layout, and I can write a spec of :assert that the sum of the width of the elemes of this vector is <= width of the screen
@triss Do you want to validate that something is a registered spec or that it looks like it could be a spec?
For the former, you could use #(try (s/get-spec %) true (catch Exception _))
That would be false for predicate functions tho'...
...but it would validate that you actually had a named, registered spec (keyword).
(so I guess you'd still want (s/or :fn fn? :spec #(try ...))
?)
I’m gonna have to scratch my head for a bit about what I want to match on really… I want anything that woks as the first argument for s/valid?
you can’t actually spec most of the functions in spec without creating an infinite recursion when instrumented
Based on the docstring for s/valid?
, it doesn't look like there's a spec registered for it.
The source shows it calls specize
on its spec
argument and that in turn is
(defn- specize
([s] (c/or (spec? s) (specize* s)))
([s form] (c/or (spec? s) (specize* s form))))
at which point you'll have to dig in the source for specize*