Fork me on GitHub
Oliver George01:12:31

Hi Alex, I’m super excited about the new spec. Just trying to moderate my expectations… Do you think it will be a complex port to clojurescript? From memory the first version took a while (months?) to come out.

Alex Miller (Clojure team)01:12:27

I think there were a couple tricky parts to the cljs port in gen/instrument/check - I suspect those tricky bits aren't going to change, at least in the tricky parts. And I think the increased clarity around symbols vs objects is probably likely to make the cljs code larger but simpler

Alex Miller (Clojure team)01:12:35

so I don't see any reason it should be particularly hard, but there is a lot of internal structural change, enough that if it were me doing it, I'd probably start fresh and pull from the old code as needed

Alex Miller (Clojure team)01:12:54

that said, we're not done yet :)

Oliver George01:12:50

While I’ve got you can I ask about the idea of including specs in defn. Do you think we will see :args and :ret keys added to the pre/post condition map?

Alex Miller (Clojure team)03:12:22

Haven’t looked at that yet

Alex Miller (Clojure team)03:12:18

Ret and fn specs are likely going to change a lot

Oliver George03:12:02

Fair enough. Thanks.


I am trying without success to generate clj-time dates using specs in clj-time.spec . (s/exercise ::spec/date-time) always returns dates close to January 1rst 2011 by a few millis. The spec in the lib is using:

(spec/def ::past-and-future (spec/int-in (to-long (date-time 2011 1 1 00 00 00))
                                         (to-long (date-time 2030 12 31 23 59 59))))
or simplified
(s/exercise (s/int-in 1293840000000 1924991999000))
which always returns numbers close to 1293840000000. Under the hood, it looks like (gen/large-integer* {:min 1293840000000 :max 1924991999000}) . When I run this directly, I have the same issue. Is there a way to generate dates that are more spread from 2011 to 2030?


are you sure that it doesn't start near 2011, then move away progressively? @gariepyalex


if you sample more values


You are right. With more samples some are different. Still, most date are very close to the minimum value. This is expected behavior? If I want something else, I need to write a custom generator?


This is expected.


there's a control -- I don't have a link handy, but see the test.check wiki I think


@gariepyalex the expected behavior of large-integer is that many values are close to 0


So any date/time generator naively implemented with large-integer will have the sort of behavior you're describing


There's no datetime generator that doesn't privilege some span of time


> From > gen/sample starts with very small sizes in the same way that the quick-check function does. This can be misleading to users who don’t expect that and take the first ten results from gen/sample to be representative of the distribution of a generator. Using gen/generate with an explicit size argument can be a better way of learning about the distribution of a generator. Thanks @ghadi and @gfredericks!