@gfredericks I’m using test.chuck, but can’t get my head around this. How do I generate two dates - one always smaller than the second?

I’m using test.chuck.generators/datetime

@ag fmap+sort, such-that+not=

are you saying I should generate many, sort and then grab first two?

makes sense

No

Generate exactly two using tuple or vector

Then fmap and filter that

filter? what filter for?

The filter is to make sure they're not equal

("filter" meaning such-that)

oh, right… thanks!

or generate one date and a quantity and add the quantity to the date

For the record, problem that I had yesterday was actually due to using set (#{}) in :req/:opt for s/keys:

user> (s/exercise (s/keys :req #{:lol/id2} :opt #{:lol/id}))
ExceptionInfo Couldn't satisfy such-that predicate after 100 tries.  clojure.core/ex-info (core.clj:4725)
user> (s/exercise (s/keys :req [:lol/id2] :opt [:lol/id]))
([#:lol{:id2 0} #:lol{:id2 0}] [#:lol{:id2 0} #:lol{:id2 0}]…

the s/keys generator also obeys :req and :opt, so generates maps that have only :req keys, which is neat 🙂

another thing, I’m tinkering with generating specs from a source outside code (database schema), and doing something like this:

user> (let [k :lol/id]
        (s/def k int?))
user/k

which is not actually what I wanted, so I’m working around it by doing this:

user> (let [k :lol/id]
        (eval `(s/def ~k int?)))
:lol/id

Which seems a bit odd. Am I missing something or is the idea that specs are defined firstly in Clojure code and not derived from outside sources?

I faced similar problem when I wanted to generate specs based on an sql db schema by inspection. In that case I generated clojure code.

The macro based API complicates things.

It must be possible to do. I'd love to see examples.

you can do that, or use eval

in the future there may be a lower-level function-based api, however it will not be able to automatically capture forms for explain reporting

lovely idea -> http://dev.clojure.org/jira/browse/CLJ-2112

that'd make the life of all the spec to <whatever-format> projects a lot easier

thumbed that one up, thanks @mpenet. Hacked around that just yesterday to get dynamic conformers “drop extra keys” & “fail on extra keys” working for map specs.

@mpenet has been in the plan from the beginning, but has been blocked behind the various form errors

It would be cool to use s/exercise to generate a sample structure for documentation, but I would need to tweak a few things: Make all keys required, ensure all collections have >= 1 element.

I realize this would probably be hacky, but any thoughts on how to do this?

I'd probably write a function doc-sample that has the special cases you described, calls itself recursively, and falls back on gen/generate when it doesn't know what to do

I’m writing a macro that is essentially a wrapper around defn, so I thought it would be cute to use defn‘s spec to conform for easy access to the args & body. it works on some, but not when the body of the macro is a map, because..

user> (s/conform :clojure.core.specs/defn-args
                 '(foo [bar] {:baz 42}))
{:name foo, :bs [:arity-1 {:args {:args [[:sym bar]]}, :prepost {:baz 42}}]}

oh man; does that mean defn is essentially unspecable?

I mean I guess you could rewrite it with an or

well I don’t think it’s un-specable, just that the conform result does not align with the semantics

that's presumably because the spec is ambiguous

and I don't think it should be

well yeah, I think the spec as written is a bug / oversight

yeah

i'd open a ticket about that

just hoping for a way around it

change the spec yourself 🙂

more work than I was hoping to do

I think it'd be a pretty simple tweaking of this bit here https://github.com/clojure/clojure/blob/c0326d2386dd1227f35f46f1c75a8f87e2e93076/src/clj/clojure/core/specs.clj#L76

you'd wrap the :prepost and :body in an or or alt or whatever, where the body uses + instead * in the branch with the prepost

yeah I agree

(s/def ::args+body
  (s/cat :args ::arg-list
         :rest (s/alt :body+attr (s/cat :prepost (s/? map?)
                                        :body (s/+ any?))
                      :body (s/* any?))))

this works

user=> (s/conform :clojure.core.specs/defn-args '(foo [bar] {:baz 42}))
{:name foo, :bs [:arity-1 {:args {:args [[:sym bar]]}, :rest [:body+attr {:body [{:baz 42}]}]}]}
user=> (s/conform :clojure.core.specs/defn-args '(foo [bar] {:baz 42} 1))
{:name foo, :bs [:arity-1 {:args {:args [[:sym bar]]}, :rest [:body+attr {:prepost {:baz 42}, :body [1]}]}]}

@bronsa no need for the s/? at that point, right?

what about (foo [bar])

that would go through the second branch

ah sorry, I read s/? and thought s/*

yeah no need for that s/? indeed

better name for :rest?

:body-or-body+prepost doesn't look too good :)

:body+ :body* :body' dunno too many names

seems like the spec should be named ::args+prepost+body and the :rest is ::prepost+body

further broken down into :prepost+body or :body

:?prepost+body -> :prepost+body/:body

:P

I guess an argument could be made that prepost is part of the body

given the original name of the spec that seems to be the direction they went

aight, I'll make a ticket + patch and just keep it as

(s/def ::args+body
  (s/cat :args ::arg-list
         :body (s/alt :prepost+body (s/cat :prepost map?
                                          :body (s/+ any?))
                     :body (s/* any?))))

thanks!

http://dev.clojure.org/jira/browse/CLJ-2114

hmm, maybe prepost should be stricter than just map?

the actual grammar for defn only accepts a map with :pre [fn*] :post fn

shrug

still an improvement ¯\(ツ)/¯

it does?

well

it ignores any other key

it looks to me like the only requirement is :pre's value is a collection

an throw at runtime if you don't provide [fn*] for :pre or fn for :post

I thought they were arbitrary expressions

arbitray predicates

i'm using fn to mean IFn instance

wait

no you're right I'm stupid

have you been using pre-post wrong for years and didn't notice because the functions are always truthy 😄

yes, absolutely

dynamic languages are a magic surprise

@gfredericks the few slack users that use the slack->irc bridge will know what we've been up to

we need to find them and silence them

glad I stopped using that when the threads feature was released

oh god I don't want to know how that looked

I think it just looked like regular messages

so I would've ended up unknowingly replying to thread messages in the main channel

lol

I can put up with all sorts of nonsense for the sake of technological idealism, but unknowingly looking like a crazy person is not one of them

one thing I really miss about the #clojure irc: slack makes me feel so much more guilty when I derail a conversation/channel into offtopic banter

only because threads exist? or because topics are more specific?

the latter I think