Thanks Beau and Alex, I ended up using a different namespace and got things done!
About chans: I was trying to use the spec mainly as a checker on test/dev. We have a system that communicates a lot via channels but we lose that extra check at those boundaries. Didn't think about the transducers, that complicates things. About the test timing: I've only instrumented one namespace and it has a some getter fns that are heavily used[1]. This may not be a typical scenario, because we test brute force AI and auto generate battles and play them to the end. But it's a heavy burden. Our travis build went from 9min to 47 min with that change. So we may need to re-organize the tests and don't instrument all the scenarios. [1] https://github.com/orionsbelt-battlegrounds/obb-rules/blob/9fa5da24a3844982ba51e17e9adfe49f2aeea445/src/obb_rules/unit.cljc On Fri, May 27, 2016 at 1:36 PM Alex Miller <a...@puredanger.com> wrote: > > > On Friday, May 27, 2016 at 2:36:56 AM UTC-5, Pedro Pereira Santos wrote: >> >> Hello, >> >> How can I differentiate between the same keyword, but with difference >> semantics? Example: >> > > If you have different semantics, you should use different keywords (either > different name or namespace). > > >> >> {:attack 100 >> :bonus {:attack {:category {:heavy 100}}}} >> >> I have: >> (s/def ::attack (s/and pos? #(<= 1 1000)) >> (s/def ::bonus (s/keys :req-un [::attack ; <--- >> >> Is there a way to do this? >> >> -- >> >> Another question: is there a way to spec a fn that handles channels? >> Something like: >> > > Nothing right now but we've talked about this some. You have to keep in > mind that channels also can have a transducer which means the read and > write ends of a channel might have different specs. Tim Baldridge pointed > out that you could use a map transducer that checked s/valid? on it's > inputs - that could be used at either the beginning and/or end of a > transducer chain. That's pretty brute force though and would add a lot of > overhead. > > >> >> (s/fdef some-fn >> :args (s/cat :ch (s/chan ::unq/model)) >> :ret (s/chan :unq/model)) >> >> -- >> >> And yet another: I have a game project with some test.check scenarios. >> The test run takes 8s without instrumenting and 22s with instrumentation, >> and this makes me think on starting to split tests in test suites. Is there >> something to handle this in clojure.test? >> > > That's the first timing report I've seen - pretty interesting! How many > fns do you have instrumented? clojure.test does not support this directly > but if you're using leiningen you can use their test selectors on how to do > this. > > >> >> Thanks! >> >> >> On Thu, May 26, 2016 at 7:00 PM Beau Fabry <imf...@gmail.com> wrote: >> >>> I'm in a similar position to you Wesley, I'm all for generative testing, >>> but sometimes I prefer not to spec out the full depth of the tree (ie some >>> input leaves with s/Any) and just turn on validation in staging and see >>> what happens. The cpu-time wasted there doesn't matter much to me. Looking >>> forward to seeing where things end up. Spec certainly seems really well >>> thought through. >>> >>> Aside: Great work on the docs Alex. Much much more comprehensive and >>> readable than is usually available for an alpha feature in *any* language. >>> >>> >>> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote: >>>> >>>> Thanks Rich, for this and your work in general. After 15 years of >>>> working with Java, it has been a real joy to find clojure (let's face it, >>>> that pun alone is pure gold!). >>>> >>>> I might try my hand at the macrology you describe as an exercise... >>>> everybody stand well back.... >>>> >>>> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote: >>>>> >>>>> If you name (register) your (sub)specs with s/def and you can reuse >>>>> them as much as you like. >>>>> >>>>> (s/def ::argi (s/cat :i integer?)) >>>>> (s/def ::fnii (s/fspec :args ::argi :ret integer?)) >>>>> (s/conform ::fnii +) >>>>> (s/valid? ::argi '(42)) >>>>> >>>>> However you are talking about calling ‘instrument’ so I don’t think >>>>> you are in the HOF case. So you shouldn’t be using fspec but fdef: >>>>> >>>>> (s/fdef fooi :args (s/cat :i integer?) :ret integer?) >>>>> >>>>> (defn fooi [i] >>>>> (let [spec (-> `fooi s/fn-specs :args)] >>>>> (assert (s/valid? spec (list i)) (s/explain-str spec (list i)))) >>>>> 42) >>>>> >>>>> (fooi "42") >>>>> user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i] >>>>> predicate: integer? >>>>> >>>>> Obviously some macrology could make this more succinct, as is being >>>>> discussed elsewhere. >>>>> >>>>> > On May 26, 2016, at 9:17 AM, Wesley Hall <wesle...@gmail.com> >>>>> wrote: >>>>> > >>>>> > spec is not a contract system. >>>>> > >>>>> > Forgive me for I am about to sin :). >>>>> > >>>>> > I have a little RPC framework that I use to do simple remoting >>>>> between clojurescript in the browser and ring based web services. I'm >>>>> currently using schema to validate arguments received from clients and >>>>> return appropriate exceptions upon non-conforming invocations. >>>>> > >>>>> > The idea of being able to perform generative testing against a >>>>> specification for these functions is really appealing but if I am using >>>>> generative testing to verify that my functions behave properly if invoked >>>>> as intended it does feel like there would be some benefit to ensuring that >>>>> the conditions under which the function has been tested are enforced at >>>>> runtime for those functions on the edges of my API. >>>>> > >>>>> > I'd definitely prefer a manual conformity check over instrumentation >>>>> in these cases, but it seems like an fspec cannot be used for this purpose >>>>> (from within the function itself). I'd rather not define my specs twice. >>>>> > >>>>> > Seems like I might be destined to make cheeky instrument calls after >>>>> each of these edge functions, in the same was the always-validate metadata >>>>> is used in schema. >>>>> > >>>>> > Do I have a desperate need to be convinced otherwise? :) >>>>> > >>>>> > -- >>>>> > You received this message because you are subscribed to the Google >>>>> > Groups "Clojure" group. >>>>> > To post to this group, send email to clo...@googlegroups.com >>>>> > Note that posts from new members are moderated - please be patient >>>>> with your first post. >>>>> > To unsubscribe from this group, send email to >>>>> > clojure+u...@googlegroups.com >>>>> > For more options, visit this group at >>>>> > http://groups.google.com/group/clojure?hl=en >>>>> > --- >>>>> > You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>> send an email to clojure+u...@googlegroups.com. >>>>> > For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
