This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-13
Channels
- # aws-lambda (21)
- # beginners (8)
- # boot (67)
- # braveandtrue (2)
- # cider (12)
- # cljs-dev (38)
- # cljsjs (87)
- # cljsrn (11)
- # clojure (307)
- # clojure-austin (29)
- # clojure-finland (1)
- # clojure-italy (9)
- # clojure-russia (19)
- # clojure-spec (71)
- # clojure-uk (33)
- # clojurescript (109)
- # clojutre (1)
- # core-async (2)
- # cursive (24)
- # datomic (11)
- # devops (5)
- # ethereum (5)
- # figwheel (2)
- # hoplon (25)
- # ipfs (1)
- # jobs (1)
- # luminus (17)
- # off-topic (2)
- # om (38)
- # om-next (3)
- # onyx (166)
- # other-lisps (1)
- # proton (5)
- # re-frame (15)
- # reagent (45)
- # ring (2)
- # spacemacs (6)
- # specter (12)
- # untangled (58)
- # yada (23)
@bahulneel I'm working on upgrading a production project to Clojure 1.9 and spec right now, so I'll keep this channel informed of any new stuff I figure out with the clojure.test
integration.
Given that clojure.spec.test/check
takes a quoted symbol, I shouldn't even need a macro to accomplish what I want. A plain 'ol function should do the trick. đ
I'm having trouble getting clojure.spec.test/check
to run a non-default number of tests. From reading the docs and the code, it looks like I should be able to do this:
(stest/check 'kpcs.event.processor/schema-version {:num-tests 1})
But it always runs 1000 tests:
({:spec #object[clojure.spec$fspec_impl$reify__14244 0x7b0d682d "clojure.spec$fspec_impl$reify__14244@7b0d682d"],
:clojure.spec.test.check/ret {:result true, :num-tests 1000, :seed 1473765191336},
:sym kpcs.event.processor/schema-version})
Hrm... I realise that I'm dealing with a namespaced key. This doesn't work, either:
(stest/check 'kpcs.event.processor/schema-version {:clojure.test.check.stc/opts {:num-tests 1}})
OK, finally figured it out:
(stest/check 'kpcs.event.processor/schema-version {:clojure.spec.test.check/opts {:num-tests 1}})
({:spec #object[clojure.spec$fspec_impl$reify__14244 0x7b0d682d "clojure.spec$fspec_impl$reify__14244@7b0d682d"],
:clojure.spec.test.check/ret {:result true, :num-tests 1, :seed 1473765827766},
:sym kpcs.event.processor/schema-version})
Why does ::stc/opts
in the clojure.spec.test
namespace expand into :clojure.spec.test.check/opts
?
clojure.spec.test sets up an alias of âstc to âclojure.spec.test.check
the ::stc/opts just says to create a fully-qualified keyword using the local alias stc so that expands
@alexmiller Thanks for the explanation!
I think they both used to and fdef was relaxed
fspec prob should be too
if you file a jira enhancement weâll look at it
(in other words, I think no reason :)
(s/explain (s/fspec :args empty?) (fn [] nil))
Success!
=> nil
(s/valid? (s/fspec :args empty?) (fn [] nil))
=> false
just to be sure, thatâs the same thing @uwo said above right?
ok, Iâm agreeing thatâs wrong if it wasnât clear :)
yup just pointing out that itâs required now. in previous alphas :ret
was actually not required on fspec
, but in alpha12 that restriction is enforced
Is there a way to refer to a spec that is defined later in the same file? E.g. (s/def ::foo (s/with-gen ::bar ...)) ... (s/def ::bar ...)
?
I may be getting an unspecified behavior, where sometimes the spec is found and sometimes it isn't, resulting in conform
returning a tagged, conformed value and sometimes returning the untagged original value.
Granted, the second spec is more complex than in this example but the first is pretty much that.
clojurescript related question, Iâm working on a library which uses clojure.spec to describe a data structure using s/*
, the data structure can be used statically during compilation in macros, or during runtime in cljs.
all is nice and shiny on clj side[1], but on cljs side, I want native js arrays to be treated as collections for the purpose of speccing, but unfortunatly s/*
does not treat them such. Ended up writing custom predicates for native array case[2], just wondering if there is a better way to teach s/*
to walk native js arrays the same way as cljs vectors.
[1] https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/sdefs.clj
[2] https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/sdefs.cljs
@jannis I donât know of any issue with that. however, one of the perf changes in alpha12 means that one spec gets compiled into anotherâs definition (via delay) so when you change (re s/def) a spec at the repl, downstream specs need to be re-s/defâed as well
is there any chance you are seeing this behavior at the repl?
maybe when you made it âworkâ you just caused a new s/def that was needed
@esp1 I donât know of any change that would have altered this behavior in alpha12, but thatâs possible (or that it changed at some point during the alphas)
actually previously i was using tonskyâs future-spec port of spec to 1.8, so possibly it was something specific to that, not sure
@alexmiller: If I load the namespace that these specs are in I get it in the REPL. If I reload the same namespace, it disappears. And I get it when running tests outside the REPL (using boot test
).
I also get it when defining them in the REPL: https://gist.github.com/Jannis/d249d6d21e92f6bca7736c79eb008b49
This is alpha11 though. I can't use alpha12 at the moment because it fails requiring DataScript due to an invalid ns
expression in it.
I canât even run the first line of that with a bare alpha12 repl, not sure about earlier
I realize this is slimmed down, but I donât think you should expect to with-gen over a spec that doesnât exist yet
These specs are for a language that is recursive (think: Om Next query expressions). How would I include the recursive nature in the spec other than refering to the top-level spec in a part of it?
yeah, thatâs fine
Iâm talking about with-gen in particular
you can provide gen overrides separately too of course. gen with recursion is generally hard.
fns like instrument
take an override map
from name (or path) to generator
Ah, yes. So that would also work with clojure.spec.test/check
. I'd prefer to have all generators defined along with the actual spec so it's as reusable as possible (e.g. in combination with fdef
args in functions other people may write). I'll see what the best solution is. Thanks!
I'm trying to understand why nested calls s/cat
don't operate the way I expect - to illustrate:
cljs.user> (s/explain (s/cat :x number? :y number? :z number?) [0 0 0])
Success!
nil
cljs.user> (s/explain (s/cat :coords (s/cat :x number? :y number? :z number?)) [[0 0 0]])
In: [0] val: [0 0 0] fails at: [:coords :x] predicate: number?
nil
In my actual situation, I'm trying to reuse the inner s/cat
as both the return value of a fn, and an argument to another fn. Also, it does work the way I expect if I use (s/tuple number? number? number?)
, but I'd like to be able to conform it and get a map. Am I missing something?(s/explain (s/cat :coords (s/spec (s/cat :x number? :y number? :z number?))) [[0 0 0]])
=> Success!
@bhagany the regex operators assume concatenation by default, you need to wrap nested calls in s/spec
aha, thanks @seancorfield and @bfabry!
covered towards the bottom of this section http://clojure.org/guides/spec#_sequences
I'd read it, but I think I have not yet internalized that cat
is a regex operator. thanks again
any set of nested regex ops (`cat`, alt
, ?
, +
, *
, &
, keys*
) describes the structure of a single sequential context
which is just like regex on a string
strings are different in that a single character in a string canât also be a string (but that is true of elements in a Clojure sequential collection)
the video of dnolen's talk on parsing with derivatives / spec is up https://www.youtube.com/watch?v=FKiEsJiTMtI
@alexmiller: test.check already supports collections distinct by custom key-fns
E.g. gen/vector-distinct-by
@jmglov: http://github.com/gfredericks/schpec exists in case you don't want to bother managing a whole library for that function
Are there any conventions around where to put specs? In the namespace, in a special whatever.spec namespace, etc..
@wilkes "it depends" is the answer to that.
At World Singles, our specs are very data centric so they mostly live in their own namespace and we pull them into other namespaces as needed, and then our tests pull them in to instrument / check the code.
In clojure.java.jdbc all the fdefâs are in a separate namespace so the code still works with pre-1.9.0 versions of Clojure.
But if you know youâre only going to use 1.9.0 onward and youâre mostly specâing functions, rather than data, Iâd imagine it would be convenient to put fdefâs next to their defnâs in the same namespace.
@seancorfield Thanks, that helps. I was expecting this to be at least in flux until people have spent some time with specs in their projects.
Clojure itself is putting specs in clojure.core.specs