This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-01
Channels
- # admin-announcements (8)
- # arachne (11)
- # beginners (17)
- # boot (64)
- # cider (26)
- # cljs-dev (7)
- # cljsrn (1)
- # clojure (115)
- # clojure-belgium (2)
- # clojure-dusseldorf (15)
- # clojure-poland (15)
- # clojure-russia (62)
- # clojure-spec (86)
- # clojure-uk (208)
- # clojurescript (36)
- # cursive (4)
- # datavis (11)
- # datomic (44)
- # editors (9)
- # hoplon (21)
- # jobs (4)
- # mount (21)
- # off-topic (3)
- # om (113)
- # onyx (65)
- # parinfer (2)
- # perun (3)
- # proton (6)
- # re-frame (29)
- # reagent (20)
- # yada (3)
@lvh I was pondering having an "experimental" namespace, so we could probably start it there (c.g.schpec.expermental.json-schema)
schpec depending on chuck is fine and probably inevitable
@lvh: @gfredericks: Sorry, just seen the messages above about JSON Schema / spec... curious what you're doing exactly, it sounds interesting and useful!
I started to dump utils I am using in our projects in https://github.com/mpenet/spex, I might make a couple of PR if there's an agreed "spec utils" project in the works (and interest)
should be possible for a subset of specs presumably
@dominicm: Trickier, but like gfredericks said possible for some subset of specs; the biggest problem is that you presumably need to statically determine what a particular spec pred means, and then see how much of that you can express in JSON Schema
it’s not going to be very nice json schema (probably larger, decent amount of duplication) but as long as you treat it like a compilation product and don’t care about bidirectional access that seems fine
the fact the predicates are stored as symbols that can't be reliably mapped to vars seems problematic for doing this kind of thing robustly
a symbol is a namespace qualified value too though right? 'clojure.core/int
Not necessarily
The mapping from symbols to vars is entirely relative to the current namespace setup
You can setup your namespace so that clojure.core/int
resolves to something entirely different
But in any case I think spec would only store int?
generally
surely a macro could resolve it to its bound value though by inspecting ns-map etc... though
yes, you could set up your namespace so that int? redirects to something else, but spec does store the ns
@lvh: @seancorfield -- I just had occasion to write a spec for bigints, and was surprised to discover that (int? (bigint 1))
returns false
. So I went with:
(s/def ::bigint (s/with-gen #(instance? clojure.lang.BigInt %)
(fn [] (gen/fmap #(bigint %) (s/gen int?)))))
Just as an FYI followup.int? has to be fixed-precision. integer? just has to represent an integer, I guess. So I may be able to simplify that 🙂
Yes indeed, this works:
(s/def ::bigint (s/with-gen integer?
(fn [] (gen/fmap #(bigint %) (s/gen int?)))))
@eggsyntax: and why doesn’t (s/def ::bigint (s/and integer? (s/conformer bigint)))
work for you?
(all I changed from my original suggestion was to use integer?
instead of int?
there)
I guess the question is should (s/conform ::bigint 1)
be 1N
or :clojure.spec/invalid
?
Yeah, good question. For my purposes, sure. But I could imagine going the other way in another context.
Your predicate — #(instance? clojure.lang.BigInt %)
— is not the same as integer?
tho’. Your predicate rejects 1
. That was my question.
(and (s/exercise integer?)
doesn’t seem to generate bigints in my quick tests)
clojure.spec
encourages us to be spec
ific 🙂
w.r.t. generating bigints, I ran into a bug once that didn't surface until the bigints were larger than Double/MAX_VALUE
which makes it interesting to consider how large of a bigint a general bigint generator should test by default
presumably at least bigger than Long/MAX_VALUE
but Double/MAX_VALUE is quite large
@gfredericks: I thought some of the automatic tests were around max/min values?
you're asking about default generator behavior?
test.check doesn't have anything like that currently besides favoring small numbers
and nan/infinity
I'm not sure what the best way to do that is
e.g., if Double/MAX_VALUE should be tested frequently, does that mean the value right below it should be too? or just make that one special? and should it be easy to "shrink" to Double/MAX_VALUE from something more random? or should we always shrink downward?
@gfredericks: I don’t know if you saw the discussion I started a couple of weeks ago about the growth rate on the default spec generators … but the conclusion was that we definitely need integer generators for sizes (that grow slowly and have reasonable bounds) and generators for values used in mathematical functions (that grow rapidly and as large as they can get). Those already exist in test.check (although they’re not labeled/documented for those uses) but you have to jump through more hoops to get sensible bounds in spec.
I think I saw that, yeah
I wish I could just rename a bunch of generators
A docstring overhaul could be good at least
@gfredericks: You probably weren't considering supporting goog.math.Integer
s, but if you were you might be interested to know that multiplication is broken for them
https://github.com/google/closure-library/issues/703
xcthulhu: ha, I fixed a couple division bugs in that class a while back
I've definitely thought about Integer but I'm not sure how it ought to fit since it's pretty 2nd class in the cljs arithmetic world
could definitely add some stuff in test.chuck for it though
Well... they don't work... when I need bigintegers I use SJCL and am generally disappointed.
what doesn't work?
that might be a recent bug
I did a bunch of property-based testing on Integer in https://github.com/gfredericks/exact
which is where I ran into the division bugs
so either I tested on an earlier version w/ the mult bugs or else they're hard to find
Cool maybe I should port the modular inverse code I wrote since it makes great tests.
I'll probably take a look at it; I've already been through their contribution process
This is a cool library btw. Would you ever want an is-prime?
function? Miller-Rabin is rather fast provided you accept the generalized Riemann hypothesis is true.
well you should probably call it probable-prime?
then; but I'm not opposed to a namespace for number theory stuff if you find that useful
@gfredericks: Yeah, I think for test.check a documentation update is fine … the right generators are there, it’s just not obvious to a newcomer how different those two use cases are.
yeah; communicating how sizing works in general is kind of difficult
hello. i want to have something like
:nav {:bla 1
:foo [{:ok true
:sure 0}]}
how would i do the s/def
on that?Is there a way in clojure.spec to specify xor of schemas? JSON Schema has it. Specifically, there’s a way to say that something must match all these schemas, or at least one of them, or exactly one of them (the latter being the xor I’m talking about).
also, what happens if i have a key like :ok
in some other place, and its a string there? how do i s/def
that..?
@lvh: add that to schpec
is there a way for a pred that fails to communicate something about why it failed? specifically, i’m implementing xor as described above (aka one-of), I’d like to say the name of the spec that failed the pred
Specifically the predicate itself? For a spec it's just (s/explain ::the-spec failing-input)