Fork me on GitHub
#clojure-spec
<
2019-12-12
>
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.

gariepyalex16:12:31

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?

ghadi16:12:00

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

ghadi16:12:11

if you sample more values

gariepyalex16:12:19

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?

ghadi16:12:17

This is expected.

ghadi16:12:32

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

gfredericks16:12:23

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

gfredericks16:12:00

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

gfredericks16:12:53

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

gariepyalex16:12:18

> From http://clojure.github.io/test.check/growth-and-shrinking.html > 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!