This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-09
Channels
- # adventofcode (187)
- # aws (1)
- # aws-lambda (1)
- # beginners (162)
- # boot (64)
- # cljs-dev (6)
- # cljsjs (2)
- # cljsrn (32)
- # clojure (357)
- # clojure-greece (1)
- # clojure-korea (4)
- # clojure-russia (63)
- # clojure-sanfrancisco (3)
- # clojure-spec (91)
- # clojure-uk (63)
- # clojurescript (74)
- # clojurex (10)
- # code-reviews (55)
- # core-async (4)
- # core-typed (1)
- # cursive (17)
- # datascript (36)
- # datomic (43)
- # devcards (4)
- # dirac (3)
- # emacs (59)
- # hoplon (286)
- # jobs-discuss (399)
- # luminus (4)
- # mount (9)
- # off-topic (30)
- # onyx (53)
- # protorepl (3)
- # re-frame (88)
- # reagent (4)
- # spacemacs (1)
- # specter (14)
- # untangled (1)
- # vim (42)
Hi, could someone help me understand why in the above code generating ::engine-variable takes a split of a second and test/check runs forever until hitting a GC overhead ?
I even tried
(binding [s/*recursion-limit* 1]
(stest/check `convert {:num-tests 1 :max-size 1}))
I'd like a constraint that only allows one branch of an or
in a derived spec. Is this possible? Here is an example of what I'm trying to do.
(s/def ::an-int-or-string (s/or :int int? :string string?))
(s/def ::my-map (s/keys :req [::an-int-or-string]))
(s/def ::my-map-string (s/and ::my-map
#(string? (::an-int-or-string %))))
am I awful thinking about writing an (with-ns ...)
macro that does create-ns + in-ns + restore proper ns once out of scope ?
getting tired of writing super verbose specs preceeded by (alias baz (create-ns 'foo.bar.baz))
you could get e.g. (do (in-ns 'foo) ::foo)
to work with reader hackery but no way to get (with-ns 'foo ::foo)
to work w/o introducing placeholder objects & resolve aliases at compile time
Well I might give it a try once I am done with the giant schema -> spec port I am into atm. Sounds fun nonetheless
@alexmiller Are you a good person to report suggested stdlib macro specs to? If so, I submit http://dev.clojure.org/jira/browse/CLJ-207 for consideration ā I just got bitten by that; was expecting :let
in the first position to work (kinda feel it should anyway, but OK ā if it doesnāt the error message could be a lot more descriptive, and that seems like the kind of thing spec can help with here, plus youāre probably already speccing what for looks like)
jira is a good person to report suggestions to :)
Iād file a new enhancement ticket
and point to this one
requesting a spec for for
I am trying to validate data after edn/parse-string, the field above doesn't validate with the predicate #{true false} even though (s/valid? ::boolean (java.lang.Boolean. "true"))
does
:edit actually it does not for "false", only for "true"
that is so wierd I add a test/check working before and now it throws an exception cider.nrepl.middleware.test$report cannot be cast to clojure.lang.MultiFn
. I tried :monkeypatch-clojure-test false
in lein profile but it doesn't change anything
if I try to run the test right after jacking-in I get the error, if I recompile only the test one or more time and run it it works, if I recompile the whole namespace I get the error even if I make it work once before
Ok I found the problem I had to explicitely require [clojure.test.check] in my test namespace
@yenda note that in Clojure we use only the canonical Boolean/TRUE and Boolean/FALSE for true/false values so you should never call the Boolean constructor. This is in particular a problem with false as the non-canonical false value will be treated as true (although youāll see subtle weirdnesses with the non-canonical true value too).
(false? (Boolean. āfalseā)) ;; false
(false? (Boolean/FALSE)) ;; true
itās pretty subtle and can definitely be a gotcha in certain Java serialization / interop cases
boot.user=> (s/def :a/test-map (s/map-of :a/key :a/val))
:a/test-map
boot.user=> (s/def :a/key keyword?)
:a/key
boot.user=> (s/def :a/val (s/or :str string? :int int?))
:a/val
boot.user=> (s/unform :a/test-map (s/conform :a/test-map {:x "a", :y 1}))
{:x [:str "a"], :y [:int 1]}
that should work, but it is buggy
I actually wrote a patch for it this morning
Is there a way to introspect the generated samples for fspecs? Iām trying to see what sort of stuff it comes up with now to see if itās worth coming up with a more specific (and ideally: faster to generate) spec
(s/def ::variant
(s/fspec
:args (s/cat :input string?)
:ret (s/coll-of string?)))
(s/fdef
comp*
:args (s/cat :vs (s/+ ::variant))
:ret ::variant)
So Iām guessing coming up with lots of ::variants, and then checking if a bunch of combinations of them is still a variantā¦ well, thatās going to be expensive š Iām not sure if I should just run the generative tests extremely sparingly, or work on producing faster ones (e.g. by helping the generator generate realistic variants faster ā I have a bunch laying around anyway...)
you might try changing the :ret spec to (s/coll-of string? :gen-max 3)
to see if that helps
no, but lots of ways to create custom gens
I guessed :)
Iām having some modelling trouble with spec.
Letās say Iāve spec-ed a map :child/entity
:
(s/def :child/entity (s/keys :req [:child/name]))
I want to have functions that only operate on stored versions of this entity, so I create a stricter version of the spec:
(s/def :child/stored-entity (s/merge :child/entity (s/keys :req [:child/id])))
This is working pretty good! I can write specs for stored and unstored entities (or both!). The trouble starts when I add a parent entity:
(s/def :parent/entity (s/keys :req [:parent/children]))
(s/def :parent/stored-entity (s/merge :parent/entity (s/keys :req [:parent/id])))
The :parent/stored-entity
spec is incomplete. I canāt specify that its children are required to be :child/stored-entity
s.If I use a different key for a :parent/stored-entities
children, it means that functions written to work with :parent/entity
s wonāt work with the :parent/stored-entity
, which is a Bad Thingā¢.
well in this case, youād probably need stored-entity to be built from scratch rather than by restricting entity
sometimes I feel like the right answer to these kinds of questions is to re-think the modeling approach though
Iām open to remodelling š. Iām not sure how I could re-write :parent/stored-entity
to solve this.
I guess I would ask whether you really need to differentiate stored/unstored
I think I do. There are some functions that would need to ensure the entity is already on disk. An update-parent-in-place
function would need it for example.
spec lacks parameterized abstractions / generics / whatever - trying to encode that invariant is unlikely to work out - i recall some discussion of alternatives at some point in this room
could you have ::parent/children and ::parent/stored where the stored key contains a map of children ids to a stored boolean?
yeah, try to model it openly where you can accrete data by adding more keys w/o āchangingā the thing
it will be easier to reason about and youāll gain new features you didnāt even expect to have
for what itās worth, i think āparameterized specsā may be useful, but iām tempted to say weāre better off without them for as long as we can get away with it - if not forever
Alternately, consider a separate predicate that checks whether all things are storeable
That can be combined with the information