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.
