And now, in the alpha release branching gens *are* lazy, so gen calls on 
recursive specs are fast.

> On May 23, 2016, at 6:49 PM, Rich Hickey <richhic...@gmail.com> wrote:
> 
> Currently gens are not lazy, so entire tree is generated. This is because a) 
> test.check isn’t lazy either and b) we want errors when asking for gen, not 
> using it. But it is rough for recursive specs as you see.
> 
> For now you can limit the recursion depth to control the branching:
> 
> (binding [s/*recursion-limit* 3]
>  (time (s/gen ::a)))
> 
> 
>> On May 23, 2016, at 6:34 PM, Ambrose Bonnaire-Sergeant 
>> <abonnaireserge...@gmail.com> wrote:
>> 
>> I'm observing mutually recursive regex ops taking a long time to generate
>> test.check generators. Is this expected?
>> 
>> (s/def ::a (s/nilable (s/cat :a ::a
>>                             :b ::b
>>                             :c ::c)))
>> (s/def ::b (s/nilable (s/cat :a ::a
>>                             :b ::b
>>                             :c ::c)))
>> (s/def ::c (s/nilable (s/cat :a ::a
>>                             :b ::b
>>                             :c ::c)))
>> 
>> (time (s/gen ::a))
>> ;"Elapsed time: 3993.431793 msecs"
>> nil
>> 
>> Thanks,
>> Ambrose
>> 
>> 
>> On Mon, May 23, 2016 at 6:12 PM, Nicola Mometto <brobro...@gmail.com> wrote:
>> Looks like it is, in the meanwhile this patch should fix it: 
>> http://sprunge.us/XTiA
>> 
>> 
>>> On 23 May 2016, at 23:03, Nicola Mometto <brobro...@gmail.com> wrote:
>>> 
>>> Possibly CLJ-1544 related?
>>> 
>>>> On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant 
>>>> <abonnaireserge...@gmail.com> wrote:
>>>> 
>>>> I'm having trouble calling `s/gen`, might be some sort of AOT compilation 
>>>> error.
>>>> (I'm guessing this line has something to do with it).
>>>> 
>>>> I'm using the latest master-SNAPSHOT.
>>>> 
>>>> (ns gen-load.core
>>>> (:require [clojure.spec :as s]))
>>>> 
>>>> (s/gen integer?)
>>>> ;CompilerException java.lang.NoClassDefFoundError: 
>>>> clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1)
>>>> 
>>>> Thanks,
>>>> Ambrose
>>>> 
>>>> On Mon, May 23, 2016 at 5:33 PM, Ambrose Bonnaire-Sergeant 
>>>> <abonnaireserge...@gmail.com> wrote:
>>>> I see, thanks.
>>>> 
>>>> On Mon, May 23, 2016 at 5:29 PM, Rich Hickey <richhic...@gmail.com> wrote:
>>>> fdef will not add doc metadata (see rationale re: not putting more stuff 
>>>> in the namespaces/vars), but specs will be present when you call ‘doc’. 
>>>> That doc enhancement was in a push later in the afternoon.
>>>> 
>>>> https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9
>>>> 
>>>>> On May 23, 2016, at 5:26 PM, Ambrose Bonnaire-Sergeant 
>>>>> <abonnaireserge...@gmail.com> wrote:
>>>>> 
>>>>> Thanks Rich+team, this is awesome.
>>>>> 
>>>>> Instrumented vars via `fdef` do not seem to add :doc metadata yet
>>>>> (which is advertised in the docstring for `fdef`).
>>>>> 
>>>>> Am I missing something?
>>>>> 
>>>>> Thanks,
>>>>> Ambrose
>>>>> 
>>>>> On Mon, May 23, 2016 at 5:20 PM, Andrey Grin <andrey.g...@gmail.com> 
>>>>> wrote:
>>>>> Thank you. Yes, it seems that for recursion I can use the same approach. 
>>>>> As for inheritance currently I just include all parent attributes in 
>>>>> every child schema. As for spec definition multi-spec, as I understand 
>>>>> it, requires "defmethod" for every class which is probably a problem for 
>>>>> my case since all inheritance hierarchies are also determined at 
>>>>> run-time. I will need to find some approach that is both dynamic and 
>>>>> supports precise error messages in case validation fails.
>>>>> 
>>>>> 
>>>>> Am Montag, 23. Mai 2016 22:38:24 UTC+2 schrieb Alex Miller:
>>>>> I think you could apply the same idea - use a regular translation between 
>>>>> Java class and registered name and then always refer to the registered 
>>>>> name.
>>>>> 
>>>>> There are probably multiple approaches to modeling inheritance, so hard 
>>>>> to recommend something without knowing more. In general, attributes 
>>>>> coming from super classes can be modeled using the parent attribute name. 
>>>>> And I would recommend looking into multi-spec for doing validation of a 
>>>>> number of "types" that could be flowing into the same location by 
>>>>> leveraging a multimethod that conditionally provides the spec to use.
>>>>> 
>>>>> On Monday, May 23, 2016 at 3:09:46 PM UTC-5, Andrey Grin wrote:
>>>>> Thanks, Alex. I've taken random example from plumatic.schema wiki to 
>>>>> quickly illustrate the question. In my actual use case I dynamically 
>>>>> generate schemas based on hundreds of model Java classes (beans) with 
>>>>> mutual references so I need recursion (and also some way to model 
>>>>> inheritance, that was is achieved with "conditional" in plumatic). Will 
>>>>> try to implement the same with spec.
>>>>> 
>>>>> 
>>>>> --
>>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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.
> 

-- 
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.

Reply via email to