That's right

s/def updates the registry so that needs to occur before you can use the spec

how do you wrap a function that returns values to be used as gen that don't depend and randomisation at test.check level (it's an external lib that already does this (sentence generation))

I know I can (gen/fmap (fn [_] (some-lib/foo)) (gen/any)) but that seems a bit too convoluted

gen/return ?

I don't think so gen/return will always return the same value

The fact that foo doesn't rely on test.checks notions of randomness is actually a problem (as it can't play in growing, shrinking, or creating reproducible results)

I know it's a bit "dirty"

But I think you could also use gen/bind to do this

bind is from generator to generator, I am not sure this works too

Yeah, I'm thinking of it as a gen

I am not sure I understand, you have an example?

I guess its not any better than what you had with fmap

I mean you could directly satisfy the test.check requirements to be a generator

I think it's just a record with a function field

Something like that

yep I saw that too, but it's almost the same as the fmap solution in the end

it's a 2 arg func

doesn't feel right to use it either, the "make-gen" function is private for instance

Well you're starting from the position of doing something you shouldn't :)

true

So it's going to feel wrong whatever you do

it's probably not an uncommon need tho

First time I've seen it asked

but I can live with the "hack" for now

Since you're not going to use the value, I'd pick a simpler generator than any?

If you're doing the fmap one

right

boolean?

good idea

or even (gen/return nil)

but it doesn't make much diff

Yeah

😄

is there a way to increase "randomness" of num generators in test.gen?

it's often just +-1

well, I guess it's just a matter of gen size actually

nevermind

Does anyone have any tips on how to use clojure.spec/keys on Datomic entities? Looking for a workaround for the following http://dev.clojure.org/jira/browse/CLJ-2041

I don't know that there is a solution to 2041 btw

currently hurting us bad, since we work with entities all over, treating them as maps

The lighter weight lookup interfaces do not have a way to iterate over entries which keys needs to do

I know this has been discussed re Datomic but I'm not sure where things will end up

right, also guess conform would call assoc as well

is there a spec equivalent of annotating types using the s/defn, etc. macros in schema with :- and all that?

or do i just use fdef

also, so the name of a spec is a key that corresponds to what it must be called in a map, but also is just the name of a thing if you’re using it not in a map?

so how do i spec a map where the keys are strings?

use conformer

@liamd s/keys requires keyword keys for validating maps. if you don't have keyword keys, you'll need to use map-of, coll-of, custom predicates etc

and yes, use fdef

one of my dependencies is broken ""call to clojure.core/defn did not conform to spec""

is there a way to disable spec checks?

Most of the libraries "broken" by recent spec versions have already released new versions. What is breaking?

a few different deps, i'm trying to upgrade them now, i'll let you know if it's still broken

also fyi the error mesasge makes it very hard to know who the culprit is

This page lists the known ones: http://dev.clojure.org/display/design/Errors+found+with+core+specs

(and what releases have fixes)

I would have expected the error to fairly clearly indicate the source file containing the illegal defn?

Monger...

Current version is 3.1.0

The problem is the format of :or [auto-connect-retry true] which should be :or {auto-connect-retry true}

Looks like it was reported in early June and fixed in mid-August https://github.com/michaelklishin/monger/issues/142

So, yeah, you’ll need a newer version of Monger than 3.0.2 @jasonjckn

kk, thanks sean

I updated http://dev.clojure.org/display/design/Errors+found+with+core+specs to show 3.1.0 contains the fix for Monger 3.0.2’s breakage.