This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-02
Channels
- # beginners (26)
- # bitcoin (1)
- # boot (9)
- # boot-dev (5)
- # cider (26)
- # cljs-dev (1)
- # clojure (190)
- # clojure-finland (1)
- # clojure-italy (42)
- # clojure-nl (20)
- # clojure-russia (3)
- # clojure-sanfrancisco (1)
- # clojure-serbia (1)
- # clojure-spec (50)
- # clojure-uk (16)
- # clojurescript (62)
- # core-async (4)
- # cryogen (1)
- # cursive (6)
- # datascript (1)
- # datomic (36)
- # duct (6)
- # editors (6)
- # emacs (14)
- # graphql (3)
- # leiningen (30)
- # off-topic (21)
- # om (7)
- # parinfer (13)
- # portkey (56)
- # re-frame (2)
- # reagent (2)
- # shadow-cljs (58)
- # vim (1)
- # yada (3)
do you really need number?
? or is something narrower like int?
appropriate?
it is a known issue right now that NaNs cause issues for certain generators and something we intend to fix
#(not (Double/isNaN %))
pred may be useful to filter too
yes, order matters as the first spec generates, then each subsequent one filters, so the order you suggest is probably good
hi I have , I guess a ‘phlisophical’ lol question about spec. Im working on a system that uses datomic, etc. So, I’d gone though and created a bunch of specs, now I’m building out datomic schemas, using my specs to name my attributes, etc. So of course, some of this isn’t especially DRY. I’m just wondering about creating my own (or using umlaut, etc) lightweight DSL that in turn gen’s datomic schemas, specs, etc. Is this the’right’ way or is starting from specs ‘better’, etc. Just wondering
@eoliphant We wrote a library to do this called Spectomic https://github.com/Provisdom/spectomic and have been using it successfully for about a year now.
some people have done this to various degrees
hard for me to say if they found that to be a win in the long run or not
@eoliphant Datomic schema is not the same as a spec. they do similar things - link behaviour to a name, but they are not the same thing (they create different behaviour). conflate them only if you are confident that in doing so, users of your new combined API understand the consequences of this clearly. semantically, they are different. i find i prefer a little extra typing, and having decoupled systems that use very well documented APIs.
my hobby project https://github.com/robert-stuttaford/bridge keeps them separate, and i don’t think it actually costs anything to do that
so i guess the question is, are you actually Repeating Yourself? 🙂
@triss yes: https://github.com/robert-stuttaford/bridge/blob/master/test/bridge/test/util.clj#L8-L27
oh, that’s a different question 🙂
So stest/check
returns a :clojure.test.check.clojure-test/trial
how do I tell clojure.test
to look out for it?
yeah that’s kind of the way I was leaning @robert-stuttaford
Hi everyone, new to the channel. Does anyone know of any articles on best practices /process to spec a pre-existing codebase? I know spec, but so far haven't used it much and I have a "not-small" cljs codebase that i want to start spec-ing, but not sure where/how to start...
like this you mean? https://clojure.org/guides/spec
if you have a map that is used a lot, write specs for the attributes
then write an s/fdef for a function that takes that map
if you want to know where to start, pick the most common/stable data you have
work outward from there
or pick the thing you trust the least and add constraints around it by making specs and using stest/instrument
if you get an instrument failure, you’ve learned something (either your data does things you didn’t anticipate, or something is wrong)
if the former, fix your spec. if the latter, fix your code.
if you have data transformation functions, write specs for the inputs and outputs and use stest/check
> or pick the thing you trust the least and add constraints around it by making specs and using stest/instrument ha ha, good one 🙂 i think i ll start there. thanks!
one very useful practice is to spec anything before you make changes. we have code from clojure 1.6 days that we do this to, and it really helps deal with stuff like regression testing, safe refactoring, etc
Hey folks, probably a noob question but am really struggling to find an answer via search (probably because of my lack of terminology):
If I define a spec using a non auto-resolved keyword (s/def :my/spec any?)
how do I use it if I've required that namespace in a separate namespace? I can't get a call to (s/valid? :my/spec 1)
to resolve nor does (s/valid? ::
the first should work
the latter is not valid
not a valid keyword that is
user=> (ns foo (:require [clojure.spec.alpha :as s]))
nil
foo=> (s/def :foo/thing int?)
:foo/thing
foo=> (ns bar (:require [clojure.spec.alpha :as s] foo))
nil
bar=> (s/valid? :foo/thing 10)
true
orz it works now. I think I must have had something else wrong in the file - thanks @alexmiller