This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-21
Channels
- # aleph (2)
- # announcements (2)
- # babashka (10)
- # beginners (117)
- # calva (11)
- # cider (19)
- # clj-kondo (27)
- # cljs-dev (24)
- # cljsjs (1)
- # clojure (73)
- # clojure-europe (3)
- # clojure-italy (2)
- # clojure-nl (47)
- # clojure-spec (23)
- # clojure-uk (28)
- # clojurescript (71)
- # cursive (7)
- # data-science (17)
- # datascript (1)
- # datomic (7)
- # duct (23)
- # emacs (23)
- # fulcro (6)
- # graalvm (41)
- # jobs (2)
- # luminus (1)
- # malli (1)
- # off-topic (151)
- # pathom (1)
- # portkey (10)
- # re-frame (12)
- # reitit (17)
- # shadow-cljs (158)
- # spacemacs (14)
- # sql (8)
- # tools-deps (17)
- # xtdb (9)
Hey folks, can you help me to understand why I can't gen/generate
or gen/sample
:
(def email-regex #"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,63}$")
(spec/def ::email-type (spec/and string? #(re-matches email-regex %)))
(spec/def ::uuid int?)
(spec/def ::first-name string?)
(spec/def ::last-name string?)
(spec/def ::email ::email-type)
(spec/def ::phone #"^\d{12}$")
(spec/def ::person (spec/keys :req [::first-name ::last-name ::email]
:opt [::phone]))
(gen/generate (spec/gen ::person))
Error:
Show: Project-Only All
Hide: Clojure Java REPL Tooling Duplicates (13 frames hidden)
1. Unhandled clojure.lang.ExceptionInfo
Couldn't satisfy such-that predicate after 100 tries.
{:pred #function[clojure.spec.alpha/gensub/fn--1876],
:gen
{:gen #function[clojure.test.check.generators/such-that/fn--40141]},
:max-tries 100}
If the predicate is too hard to er fufill? based on random string input, don't you usually just create a generator for those complicated predicates?
So then I think for the email, its just as simple as, the string generator can't create a random entry that matches your regex
which makes sense right? as even after 100 times its going to be difficult to randomly create an email i think haha
After trying to exercise each attribute, it appears that ::phone
and ::email-type
can't be exercised
@quieterkali Use https://clojuredocs.org/clojure.spec.alpha/with-gen to provide alternative generators
Also useful for composing generators: https://clojure.github.io/test.check/clojure.test.check.generators.html
https://github.com/gfredericks/test.chuck has a generator for regex strings that I've found very useful.
I am trialling offloading some extra logic onto s/or
and would like some collective opinion, if y'all were so kind.
Suppose I have a spec defined like this:
(s/or :x :x/item
:y :y/item)
Now suppose I add x1
and want to combine it with x
at some point; so let's say I start making the semantic distinction between what this thing is and what it can be combined into:
(s/or [:additive :x] :x/item
[:additive :x1] :x1/item
[:multiplicative :y] :y/item)
Now, suppose further that I want to encode the order in which the respective operation should be defined. Now I'm thinking it would be really useful to be a bit more descriptive in my tags, so why not use a map?
(s/or {:type :additive
:operand-type :x
:precedence 1}
:x/item
{:type :additive
:operand-type :x1
:precedence 2}
:x1/item
{:type :multiplicative
:operand-type :y}
:y/item)
Now I'm thinking, should I simply add this via a conformer, keeping the tags simple (and thus transforming them at a higher level elsewhere in the spec) or do I keep this?
This might all seem like a contrived example - and it is, because my use case isn't algebraic operations, but rather data merging, and thus it's really important to define what order each data types should be merged in, and what the parent type is, so that the correct merge strategy is applied.
My question is - am I really using s/or
in a way I shouldn't be or would you still consider this ok?