This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-22
Channels
- # aws-lambda (2)
- # beginners (195)
- # boot (47)
- # capetown (14)
- # cljs-dev (7)
- # cljsjs (1)
- # cljsrn (1)
- # clojure (103)
- # clojure-berlin (28)
- # clojure-dev (92)
- # clojure-dusseldorf (3)
- # clojure-finland (2)
- # clojure-germany (3)
- # clojure-italy (4)
- # clojure-russia (37)
- # clojure-spec (104)
- # clojure-uk (52)
- # clojured (2)
- # clojurescript (124)
- # community-development (7)
- # core-async (6)
- # cursive (41)
- # datomic (53)
- # dirac (2)
- # emacs (16)
- # hoplon (5)
- # jobs (3)
- # juxt (12)
- # lein-figwheel (6)
- # leiningen (15)
- # luminus (3)
- # off-topic (49)
- # om (5)
- # onyx (13)
- # overtone (27)
- # re-frame (7)
- # reagent (46)
- # ring (3)
- # ring-swagger (11)
- # spacemacs (2)
- # specter (40)
- # sql (6)
- # untangled (149)
- # vim (14)
hold on. gen-balance-update generates data based on the information of each individual item in the original vector i.e.: (gen-balance-update m)
k, modifying...
an equivalent approach would be to generate the whole map from gen-balance-update
, and then avoid doing the map
and assoc
on line 15
btw, has anyone encountered that - very often when I run (gen/generate)
in clojurescript it just kills the websocket repl
is it possible it's generating something Very Big?
there are certain combinations of generators that have unfortunate distributions where they are Not Too Big most of the time but occasionally Very Big
but I don't know anything about the cljs repl so I don't know if that's even a reasonable guess
it’s ok, not critical, at least right now for me. I have specs in .cljc files and that’s pretty nice
I would like it to be difficult to accidentally generate Very Large things, but unfortunately I don't think there's a good general solution for the existing pitfalls
@alexmiller Should I bring up my case earlier in a jira ticket? or is it something that should be discussed with Rich first. Happy to provide a patch if there's interest.
Starting to be quite happy with my custom 3-arity conformer: easy to selectively conform on runtime (json, string, fail-on-extra-keys, drop-extra-keys etc). Is this something that could go into clojure.spec itself? ping @alexmiller. If so, should I just write an issue/proposal of this into Jira? And the idea is allow separating “what” (the spec) from “how” (the conformer). e.g.
(s/def ::name string?)
(s/def ::gender keyword?)
(conform
(s/keys :req-un [::name ::gender])
{:name “Tommi”, :gender “male”, :weight 92}
(merge json-conformers strip-extra-keys-conformer))
; => {:name “Tommi”, :gender :male}
Requires some spec inspection, but the http://dev.clojure.org/jira/browse/CLJ-2112 should make it hack-free. Spec as Records would help even more here (could just add a custom new Protocol for this).as long as the final thing doesn't end up too far from what's in the ticket it'd be a decent solution
(there's also https://github.com/uswitch/speculate doing that, monkey patching spec along the way to reach its goals)
and 2112 could be a separate lib, but I would still need the 3-arity confrom for the specs. currently need to wrap all specs to make it work… https://github.com/metosin/spec-tools
well that was my question about getting help from the spec, would like to dissolve the hacks on our side.
speculate goes further in the monkeypatch'iness -> https://github.com/uswitch/speculate/blob/master/src/clojure/spec/override.clj
@mpenet ticket would be fine - important thing is a good problem statement
@alexmiller I'll try
@ikitommi I don't understand what you're proposing
a 3-arity conform that would a third argument, a callback which the Spec’s conform would call with the sepc and the value as arguments, the callback would return either a new conformer function of nil. If it returned, it would be used instead of the installed normal conformer.
It seems unlikely Rich would want to add that
But starting with a good problem is the way to win his heart :)
This is a solution, not a problem
Yes, that's ok, although I will close it if I don't think it's a problem we are trying to solve
I hope it's not too opaque: http://dev.clojure.org/jira/browse/CLJ-2115
I’ll take a look, thx
the proposal "only" covers the need to have more info for failures the rest is probably too specific to our stuff (even tho the example mentions it)
@mpenet it's unclear from the ticket, are you parsing strings with spec?
I want conform/valid to tell me if a spec value is a valid string representation of a "Query"
so it does parse under the hood, and right now (with our patch) conform returns the parsed AST
the important bit is about the need to preserve the metadata from the failure to extend what's returned by explain* later
Yeah, that'd be nice, imo. But it also seems that passing a parse tree into spec would get your around the problem.
treating Spec like a parser, is a good way to get yourself into trouble, in my experience.
the "parse" function returns either a valid ast or an ex-info, the ast is not consumed by spec in any way ( it's basically a (conformer #(try (parse s) (catch ExceptionInfo :clojure.spec/invalid))
)
the goal ultimately is to have our schemas (that contains these query string representations + tons of other stuff), validated by spec
Okay, finally managing to get my company to use spec! great stuff! Here's one thing we're stuggling to internalize - our public API uses json that isn't namespaced, and our internal spec's, obviously, use namespaced keys. Is there some way to say "this incoming data is of the same structure as the spec, but the keys are unqualified, so handle all the keys as though they are qualified to this namespace"?
Did you ever get an answer to this question, @U37NPE2H0?
or does one have to generate a spec-specific view of the data before passing it into a spec'd function -- essentially
(clojure.core.walk/prewalk #(keyword *desired-ns* %) data)
furthermore, I'm struggling to get my company to accept namespaced keys. They essentially view namespaced keys as an implementation detail of spec that should not be complected with our data model or public API. I think the big idea with spec is that namespacing keys is actually just a different way to represent data which spec has chosen to support and encourage. But without having enough experience using namespaces and qualified data, I'm pretty sympathetic to the "don't mix implementation details with data" argument.
:req-un?
If I understand correctly. I only tried to answer the first part of the question.
Hi, I have a small problem with spec that I would like to get some thoughts on. So the problem is spec name conflicts. Since s/keys couples key and spec names together conflicts can arise:
;; Pet
(s/def ::name string?) ;; CONFLICT
(s/def ::pet (s/keys :req-un [::name]))
;; Person
(s/def ::last string?)
(s/def ::first string?)
(s/def ::name (s/keys :req-un [::first ::last])) ;; CONFLICT
(s/def ::person (s/keys :req-un [::name ::animal]))
(s/valid? ::person {:name {:first "John"
:last "Smith"}
:pet {:name "Buddy"}})
How would your handle this without:
- Separating these into different files
- Combining the specs, e.g. with s/or(s/def :
Well, you can either use two different files, each having its own namespace, in which case ::name
will resolve to the namespace it's in, or, you can skip the auto-resolve ::
and just name them differently, in the same file:
(s/def :some.namespace/name string?)
(s/def :other.namespace/name number?)
@frerom@frerom sure, but you can do: (s/def :person/name ...) (s/def :pet/name ...)
Huh. So this is exactly what I want, but it doesn't seem to work in ClojureScript? All I get is
Assert failed: all keys must be namespace-qualified keywords
can you copy your code?
:person/name is a qualified keyword, I think you might have a typeo
I guess the risk with this solution is that because the spec doesn't have the namespace in the qualified keyword you might actually get spec name conflicts for different reasons? If :person/name is defined in difference files. So I should probably keep that in mind and not be too generic with the naming.
@joshjones Doing (s/def :person/name string?)
is a good idea until someone does the same.
Yes, what I would want to do (If I can make up syntax) is something like ::person/name
which expands to :my.namespace.person/name
(create-ns 'my.namespace.person)
(alias 'person 'my.namespace.person)
(s/def ::person/name string?)
(s/valid? ::person/name "fred") ;;true
::person/name
=> :my.namespace.person/name
@not-raspberry I agree, although nothing prevents anyone from naming any spec anything they want, including any namespace, so it's just making a potential problem less likely, not eliminating it, and assumes good behavior
@frerom right, the names of specs should be bounded to the problem at hand. So if I'm writing a compiler I may use :expr.if/condition while if I was writing a public facing api for a company I may use :com.mycomp.department.person/name
@jasonjckn macros or eval are your options, in that order normally.
@tbaldridge I agree
what’s the idiomatic way to write something that is essentially an enum of keywords?
I was looking for something like (s/enum :foo :bar)
but nothing like that exists; should I simply use (s/or :foo #(= :foo %) :bar #(= :bar %))
?
seems overly verbose, to say the least
@ddellacosta: #{:foo :bar :baz …}
@zane 😄 I feel dumb
thanks!