Re: test.check generating hierarchy with relations
Typically you don't write test.check generators like this. You'll build up
a generator using the test.check generator combinators. You can see some
examples of this in the
documentation: https://github.com/clojure/test.check/blob/master/doc/intro.md.
Reid
On Wednesday, December 10, 2014 12:22:18 AM UTC-6, cliff wrote:
>
> Nico, what is the correct way to turn my function which generates the
> graph (using core.logic) into a generator?
>
>
> On Monday, 8 December 2014 09:04:14 UTC+2, cliff wrote:
>>
>> Hi
>>
>> I would like to test a function which recursively traverses the nodes in
>> a graph and collects them. For example,
>>
>> (def graph {1 [2 3 4]
>>2 [5 6 7]
>>6 [8 9]
>>10 [11 12 13]}
>>
>> my function is given a starting point say, 1 and should then traverse
>> each node which is reachable and return the set. In this case the result
>> should be:
>> #{3, 4, 5, 7, 8, 9}
>>
>> note: it does not return any elements reachable by 10.
>>
>> I would like to test this using test.check, but I would like to generate
>> test data which will exercise the traversal of the graph.
>>
>> I found a similar thread here:
>> https://groups.google.com/forum/#!topic/clojure/YWeT8BFc8k4
>>
>> But, I don't think the proposed solution would suit this use case. So, I
>> tried generating a graph with relations using core.logic
>>
>> (defn ->maps
>>>
>>> "take the output of run* and convert it into sequence of maps"
>>> [q]
>>> (let [r (->> q
>>>(partition 2)
>>>(map (fn [[k v]] {k (apply vector v)}))
>>>(apply merge))]
>>>r ))
>>> (defn gen-hierarchy
>>> "generate a related hierarchy"
>>> [size]
>>> (let [vars1 (->> (repeatedly 7 lvar) (into []))
>>> vars2 (->> (repeatedly 7 lvar) (into []))
>>> vars3 (->> (repeatedly 7 lvar) (into []))]
>>> (->>
>>> (run size [q]
>>> (fresh [?k1 ?k2 ?k3 ?v1 ?v2 ?v3 ?a]
>>> (fd/distinct vars1)
>>> (everyg #(fd/in % (fd/interval 1 9)) vars1)
>>> (fd/in ?k1 (fd/interval 1 9))
>>> (rembero ?k1 vars1 ?v1)
>>> (membero ?k2 ?v1)
>>> (fd/distinct vars2)
>>> (everyg #(fd/in % (fd/interval 1 9)) vars2)
>>> (rembero ?k2 vars2 ?v2)
>>> (membero ?k3 ?v2)
>>> (fd/distinct vars3)
>>> (everyg #(fd/in % (fd/interval 1 9)) vars3)
>>> (rembero ?k3 vars3 ?v3)
>>> (appendo [?k1 ?v1] [?k2 ?v2] ?a)
>>> (appendo ?a [?k3 ?v3] q)))
>>> (map ->maps
>>>
>>>
>> Hooking this into test.check. I tried the following:
>>
>> (defn gen-port-hierarchy []
>>> (gen/sized (fn [size]
>>>(gen/fmap #(gen-hierarchy %) (gen/return size)
>>> (gen/sample (gen/not-empty (gen-port-hierarchy)) 1)
>>
>>
>> Which does produce more or less what I'm after:
>>
>> (({6 [2 3 4 5 7 1], 3 [6 7 1 2 4 5], 1 [3 2 4 5 6 7]})
>> ({5 [1 2 3 4 6 7], 7 [5 3 4 6 1 2], 1 [7 2 3 4 5 6]}))
>>
>> However, when I try use this in a spec:
>>
>> (prop/for-all [bindings (gen/not-empty (gen-port-hierarchy))]
>>
>> (let [ ks (into #{} (keys bindings))] ...)
>>
>>
>> I seem to be getting back a LazySeq which then leads to a
>> ClassCastException:
>>
>> java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be
>> cast to java.util.Map$Entry
>>
>> Am I on the completely wrong path here?
>> Or have I incorrectly hooked this generator up with test.check?
>>
>> Any help would be very appreciated.
>>
>>
--
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.
Re: test.check slow shrinking
Short answer: Use a string generator that is much more likely to have collisions, and thus provoke your failure. Here's an example: (def small-strings (gen/sized (fn [s] (gen/resize (min s 2) (gen/not-empty gen/string-ascii) Longer answer: When using gen/bind, you create a nested shrink tree. When a test fails, and the shrinking process begins, the 'outer' generator is shrunk first. In your case, this means creating smaller matrices. After the smaller matrix is created, the inner generated is called again to create new random values with this smaller matrix. Since your test is unlikely to fail, it's quite likely that this shrunk test succeeds, and smaller matrices are not considered anymore. Since shrinking could not successfully shrink the outer generator, it begins to shrink the 'inner' generator. This is why you end up with a failing test case with a large matrix. Reid On Thursday, November 13, 2014 2:29:34 AM UTC-6, Lucas Bradstreet wrote: > > My thought process with that suggestion is that a shrink of the matrix > elements (not the size), will not require the samples and probes to be > regenerated. > > At some point I'll probably have to look into how the shrinking works. > > On 13 Nov 2014, at 06:18, Brian Craft > > wrote: > > I tried your idea of generating the size first, then passing it to the > matrix & vector generators. This does seem to work better. The shrunk cases > that return are actually worse, but so far it hasn't wedged itself, which > is a great improvement. They all return within a few seconds. I don't yet > understand the shrinking well enough to know why it's better. > > Example shrunk state: > > :samples ["0" "0" "0" "0" "0" "0" "0" "0" "0"], :probes ["0" "0" "0" "0" > "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" > "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" > "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" "0" > "0" "0" "0" "0"] > > (def gen-matrix-size > (gen/tuple gen/s-pos-int gen/s-pos-int)) > > (def gen-mostly-ints > (gen/frequency [[9 gen/int] [1 (gen/return Double/NaN)]])) > > (defn gen-matrix2 [x y] > (gen/vector (gen/vector gen-mostly-ints x) y)) > > (defn gen-names [n] > (gen/vector > (gen/such-that not-empty gen/string-alpha-numeric) > n)) > > (def gen-tsv2 > (gen/bind > gen-matrix-size > (fn [[x y]] > (gen/hash-map > :probes (gen-names x) > :samples (gen-names y) > :matrix (gen-matrix2 x y) > > > On Wednesday, November 12, 2014 12:47:37 PM UTC-8, Lucas Bradstreet wrote: >> >> I'm pretty sure I did encounter the performance problem you're talking >> about, but I killed it and re-ran until I hit cases that shrink quickly. >> I'm afraid I'm not much help with those, although I agree that the bad >> shrinking is probably related to the performance issues. >> >> On 13 Nov 2014, at 04:22, Brian Craft wrote: >> >> Interesting that you don't see a performance problem. What version did >> you try? I'm using 0.5.9. >> >> I just re-ran this example to make sure I wasn't imagining it. On the >> 11th run, it wedged, not returning, and burning a lot of cpu, presumably >> trying to shrink. >> >> It's a larger problem with the real test cases. One test ran for about >> eight hours yesterday before I killed it. Hard to tell what it's doing, and >> not sure what sort of times I should expect for shrinking larger test cases. >> >> >> On Wednesday, November 12, 2014 9:05:40 AM UTC-8, Lucas Bradstreet wrote: >>> >>> I've also had some tricky shrinking type issues with recursive >>> generators using bind. I had a play with your generators, using such-that >>> to reduce the row/column name length and also preventing some generator >>> shrinking by using no-shrink, but I didn't have much luck improving the >>> resulting shrinks (though the shrinks did finish in a timely fashion). >>> >>> You might have more luck if you generated an m x n matrix size >>> independently of the matrix itself and feed the size into the matrix >>> generator and the samples and probes generators. This may allow the matrix >>> size to be shrunk down more easily, while also shrinking the samples and >>> probes vectors without them having to be regenerated for ever new matrix >>> shrink (i.e. where the matrix size is maintained but the gen/int values >>> within it are shrunk). >>> >>> However, this is all guess work and conjecture, as I don't understand >>> the shrinking algorithm well enough, and I haven't tried my suggestion. >>> Also, modifying your generators in this way may make your model less >>> general if you wish to use it in other ways later. >>> >>> Cheers >>> >>> Lucas >>> >>> >>> >>> On 12 Nov 2014, at 02:43, Brian Craft wrote: >>> >>> Using test.check, I'm finding the shrinking to be very, very slow. >>> Running a hundred cases takes a few seconds, unless it hits an error, in >>> which case it takes 4
Re: Question about test.check, and knossos
Hey Andy, I've added a link to the API documentation [1]. And I'll update Codox for the next version of test.check, hopefully to be released shortly. [1] https://github.com/clojure/test.check/commit/200b77bbf24b67d2904dab4d4f5722badbe8b223 Reid On Thursday, October 23, 2014 11:44:54 PM UTC-5, Andy Chambers wrote: > > On Thursday, October 23, 2014 11:21:44 PM UTC-4, Andy Chambers wrote: >> >> On Thursday, October 23, 2014 9:23:36 PM UTC-4, tcrayford wrote: >>> >>> Hi Andy, All, >>> >>> I wrote a tool like this: https://github.com/tcrayford/laundromat >>> >>> it's super hacky, and the api is definitely in beta. I asked some folk >>> about reviewing this api, got little feedback, and figured it wasn't that >>> much of a wanted thing after all. I still use it internally, but it's >>> pretty bad at what it does right now. I'd love to hear if more folk are >>> interested or if anybody's interested in contributing. >>> >> >> Hi Tom, >> >> Your project looks interesting and I definitely think it has value. Where >> were you expecting feedback? When I have questions about a project like >> this, I'm never sure where to ask them. Stackoverflow? A github issue? >> Google groups? Anyway it looks pretty cool to my untrained eye but I'd be >> interested in hearing what Reid Draper or Kyle Kingsbury has to say about >> it. >> >> Do you mind me asking what made you decide to diverge from the original >> Erlang implementation? Also what makes it bad? I'd be interested in helping >> out if I can. >> > > Also, while I'm here talking about test.check, there's a couple of bugs > I'd like to report. > > * There's no link to the API docs in the README > * I did manage to find some docs here ( > http://clojure.github.io/test.check/) but there is no link to the source > like there is in the compojure codox documentation > > I tried to use JIRA after signing the CA but the secure signing page > doesn't seem to be working at the moment (screenshot attached). > > Cheers, > Andy > >> -- 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.
Re: Howto write test.check custom generators
Hey Tim,
When you write a property, like your `has-agroup`, there's no need to call
`gen/sample`. You can simply write: (prop/for-all [v my-generator] ...)
-Reid
On Sunday, August 10, 2014 6:04:21 PM UTC-5, frye wrote:
>
> Oook, this is starting to sink in.
>
> I've gotten a little farther, in that I can run quick-check with my custom
> generator. However, after a bunch of values had been generated, it fails on
> a NullPointerException. How can I know where the breakdown is happening?
>
> => (tc/quick-check 100 u/has-agroup)
> {:email , :last-name , :first-name , :username }
> {:email , :last-name , :first-name , :username 0}
> {:email , :last-name , :first-name Rq, :username 0}
> {:email 5D2, :last-name R4F, :first-name x, :username G0H}
> ...
> {:email 8KQgSr497EPw14X80oEbWC0, :last-name cdkLb8D5ol, :first-name
> 8DCOXz1U4S3JM641u5I7yPwQ, :username DADOk}
> {:email x, :last-name Qq3h07d6Cbs4, :first-name 6H6Enrwu, :username
> yf40SClLjJHp1ptbnx4I9xFbwI3}
> *NullPointerException clojure.test.check.generators/gen-bind/fn--18990
> (generators.clj:77)*
> bkell.bkell> (pst *e)
> NullPointerException
> clojure.test.check.generators/gen-bind/fn--18990
> (generators.clj:77)
> clojure.test.check.generators/gen-bind/fn--18990
> (generators.clj:79)
> clojure.test.check.generators/gen-bind/fn--18990
> (generators.clj:77)
> clojure.test.check.generators/gen-fmap/fn--18985
> (generators.clj:70)
> clojure.test.check.generators/call-gen (generators.clj:56)
> clojure.test.check/quick-check (check.clj:57)
> bkell.bkell/eval19267 (form-init7280611083923741467.clj:1)
> clojure.lang.Compiler.eval (Compiler.java:6703)
> clojure.lang.Compiler.eval (Compiler.java:)
> clojure.core/eval (core.clj:2927)
> clojure.main/repl/read-eval-print--6625/fn--6628 (main.clj:239)
> clojure.main/repl/read-eval-print--6625 (main.clj:239)
>
>
> This is my domain function:
>
> (defn *create-user*
> ([] (create {}))
> ([opts]
>(println opts)
>(let [sans-nils (apply merge (for [[k v]
> opts
> :when (not (nil? v))]
> {k v}))]
>
> (merge {:id (mu/generate-uuid)
> :username ""
> :password (crypto/base64 12)
> :first-name ""
> :last-name ""
> :email ""
> :country {}}
> sans-nils
>
>
> And these are my test functions.
>
> (def gend-user
> (gen/fmap *du/create-user*
> (gen/hash-map :username gen/string-alpha-numeric
> :first-name gen/string-alpha-numeric
> :last-name gen/string-alpha-numeric
> :email gen/string-alpha-numeric)))
>
> (def has-agroup
> (prop/for-all [v (gen/sample gend-user)]
> (-> v nil? not)))
>
>
>
> Tim Washington
> Interruptsoftware.com
>
>
> On Sun, Aug 10, 2014 at 3:02 PM, Sam Ritchie > wrote:
>
>> You can to use gen/fmap to build up generators. Here's an example:
>>
>>
--
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.
[ANN] test.check 0.5.9
I'm happy to announce the 0.5.9 release of clojure.test.check, a QuickCheck inspired property-based testing library [1]. As usual, you can view the release notes [2]. The biggest change is an improvement to writing recursive generators, which is documented here [3]. Happy testing, Reid [1] https://github.com/clojure/test.check [2] https://github.com/clojure/test.check/blob/v0.5.9/CHANGELOG.markdown [3] https://github.com/clojure/test.check/blob/65f4431cadaa3527d3509d1485409ccd12d5bff7/doc/intro.md#recursive-generators -- 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.
Re: clojure.test.check
Hi,
I've taken a stab at what I think you want:
(def gen-cache
(gen/fmap
#(reduce (fn [r m] (merge-with merge r m)) {} %)
(gen/vector (gen/fmap
(fn [o]
(let [{:keys [port instr] :as ord} o]
(assoc-in {} [port instr] ord)))
ord-gen
Instead of using `gen/sample` to create a sequence, I use `gen/vector`. And in
order to apply the `reduce` function, I use `gen/fmap`.
As an aside, I'm not sure how this is a multi-map. I was under the impression a
multi-map was simply a map that can store multiple values in the same key.
Reid
On Thursday, July 3, 2014 6:06:29 AM UTC-5, cig wrote:
>
> Hi
>
> I have been trying to build a test.check generator for a multi map,
> without much success.
> I have a generator which generates ordinary maps:
>
> (def ord-gen
> (gen/fmap (partial zipmap [:port :instr :qty])
> (gen/tuple (gen/not-empty gen/string-alpha-numeric)
>(gen/not-empty gen/string-alpha-numeric)
>(gen/frequency [[9 gen/pos-int] [1 gen/neg-int]]
>
> (gen/sample ord-gen 3)
> ;; => ({:qty 0, :instr "X4", :port "re"} {:qty 0, :instr "v", :port "8"}
> {:qty 1, :instr "3A", :port "7"})
>
> However, I would like to merge this sequence of individual maps into a
> multi-map of the form:
>
> {"re" { "X4" {:qty 0, :instr "X4", :port "re"}}, "8" { "v" {:qty 0, :instr
> "v", :port "8"}}, "7" { "3A" {:qty 1, :instr "3A", :port "7"}}}
>
> The closest I have gotten to achieving this is by realising the
> intermediate steps:
>
> (def gen-cache
> (->>
>(gen/fmap (fn [o]
>(let [{:keys [port instr] :as ord} o]
> (assoc-in {} [port instr] ord)))
> ord-gen)
>(gen/sample)
>(reduce (fn [r m] (merge-with merge r m)) {})
>(gen/return)))
>
>
> However, this returns the same value constantly (I am aware that, that is
> what gen/return is supposed to do, however, I can not get much else working
> for me). I would Ideally like to bind the ord-gen into the gen-cache
> generator. Any help would be very appreciated.
>
--
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.
Re: OOM problem with test.check
Hi Colin,
You've correctly followed the guide for writing recursive generators.
Trouble is, the guide (which I wrote) is wrong! I'll work on getting it
updated shortly, but in the interim, you can check out the detailed commit
message
here:
https://github.com/clojure/test.check/commit/2a2bd8f09a59391e7a0510291094c529ec3d922e,
which fixes this issue in test.check's built-in recursive generators.
Additionally, that commit offers a new convenience function for writing
your own recursive generators, without all of the current boilerplate. This
commit should be available on 0.5.9-SNAPSHOT, and should be a in a release
soon.
Reid
On Friday, June 20, 2014 12:18:21 PM UTC-5, Colin Fleming wrote:
>
> Hi all,
>
> I'm trying to use test.check to create random objects to test some
> serialisation code I'm having problems with. In the past, generative
> testing has worked really well for me for exactly this use case. However,
> I'm finding that I'm getting OutOfMemoryError when trying to test a lot of
> iterations:
>
> (defn object [size]
> (if (= 0 size)
> (gen/one-of
> [(gen/return nil)
>gen/boolean
>gen/string
>gen/keyword
>gen/nat])
> (let [new-size (quot size 2)
> next (gen/resize new-size (gen/sized object))]
> (gen/one-of
> [(gen/return nil)
> gen/boolean
> gen/string
> gen/keyword
> (gen/vector next)
> (gen/map next next)
> (gen/fmap set (gen/vector next))
> gen/nat]
>
> (def object-serializes
> (prop/for-all [v (gen/sized object)]
> (let [serialiser (ClojureSerialiser. {})
> byte-stream (ByteArrayOutputStream.)
> data-stream (DataOutputStream. byte-stream)
> _ (.serialise serialiser data-stream v)
> bytes (.toByteArray byte-stream)]
> (= v (.deserialise serialiser (DataInputStream.
> (ByteArrayInputStream. bytes)))
>
> (check/quick-check 500 object-serializes)
> java.lang.OutOfMemoryError: Java heap space
> Dumping heap to java_pid9895.hprof ...
> Heap dump file created [1976236588 bytes in 35.110 secs]
> OutOfMemoryError Java heap space
> clojure.test.check.rose-tree/permutations/iter--43--47 (rose_tree.clj:71)
>
> Looking at the heap dump in MAT, it looks like something internal to
> test.check is holding onto the head of a sequence:
>
> clojure.lang.PersistentVector
> + clojure.test.check.generators$sequence$fn__109$fn__110$fn__111
> | + clojure.test.check.generators$gen_bind$fn__149
>
> I assume this is something I'm doing wrong, but I have no idea what. Can
> anyone suggest anything?
>
> Thanks,
> Colin
>
--
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.
Re: [ANN] clojure.test.check 0.5.8
On May 15, 2014, at 2:08 PM, Steve Miner wrote: > I'm generating generators from schemas [1]. I have generators for all my > simple schemas -- "int" corresponds to gen/int, etc. The tougher case is > when I have to convert a conjunction of schema expressions into a generator. > For example, a schema (and int pos) specifies a positive integer, essentially > like testing (fn [x] (and (integer? x) (pos? x)). > > My current implementation finds some element of the AND that I can map to a > generator and uses such-that to filter against a predicate created from the > rest of the AND elements. > > A simple example does something like this... > > (make-generator '(and int pos odd)) > ---> (gen/such-that (make-predicate '(and pos odd)) (make-generator 'int)) > ---> (gen/such-that (fn [x] (and (pos? x) (odd? x))) gen/int) > > Of course, it would be better to use gen/s-pos-int. I'm thinking that I need > to look for a few common combinations of simple schemas, especially if > there's already a good generator for those cases. > > However, I still need to try to handle the general case, and it looks like > the such-that approach will have to be my fallback position. I'll probably > give the user the option of adding custom generators to match more > complicated schema expressions. Yes, I think you're thinking about this correctly. And in some cases, you may be better off just wasting some CPU cycles and using such-that, just like you are. It really depends on how complex you want your library to be. > > Now, if you could provide an efficient AND generator combinator, that would > solve all my problems. :-) I'll give this some thought :) > > It occurs to me that automatically deriving generators is something like > running a predicate backwards so maybe there's a way to do it with > core.logic, but I haven't tried to do that yet. Let me know how this goes. Reid -- 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.
Re: [ANN] clojure.test.check 0.5.8
Sorry you ran into an issue, Steve. I like your idea of including more information in the ex-info data. Is there a specific generator you're having trouble writing without such-that? In general, I've found that it's a code-smell if you need such-that to retry that many times. Happy to help explore other ways to write these generators. Best, Reid On Wednesday, May 14, 2014 12:13:14 PM UTC-5, miner wrote: > > > On May 14, 2014, at 10:44 AM, Reid Draper > > wrote: > > * Limit the number of retries for gen/such-that. A two-arity version > is > > provided if you need to retry more than 10 times. This should be a > > code-smell, though. > > I think the limit is a good idea, but it's an extra wrinkle and maybe too > tight. > > I had a such-that that failed due to the new limit. Unfortunately, the > error message didn't help much in tracking it down. I ended up changing > all my such-that calls to use a unique number of retries so I could figure > which one was failing. > > I suppose my situation is unusual in that I generate generators and tests > from schemas and data. The stack traces aren't very pretty when there are > errors. > > It might help if you added the 'pred' and 'tries' to the ex-info data in > such-that-helper. Might as well put something in the ex-info data. > > By the way, it turns out 25 was a sufficient number of retries for my > test. Works fine now. > > > Steve Miner > > -- 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.
[ANN] clojure.test.check 0.5.8
I'm please to announce clojure.test.check 0.5.8 [1], which is primarily a bugfix release. As usual, the release notes are available in the repository [2]. I've duplicated them here for convenience: * 0.5.8 * Limit the number of retries for gen/such-that. A two-arity version is provided if you need to retry more than 10 times. This should be a code-smell, though. * Return random seed used on test failure * Fix keyword generator to conform to reader specs * Correct documentation mentions of namespaces * Add more detailed contributing instructions * Internal: use a record internally for generators. This is meant to help convey the fact that generators are opaque * Extract rose-tree code into a separate namespace Please don't hesitate to reach out with any questions or issues. Reid [1] https://github.com/clojure/test.check/tree/v0.5.8 [2] https://github.com/clojure/test.check/blob/v0.5.8/CHANGELOG.markdown -- 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.
Re: clojure.test parameterized tests
Keep in mind too that since test.check/quick-check takes a property as an
argument, you can construct a property by simply closing over some
implementation. For example:
(defn make-prop
[impl]
(prop/for-all [...]
(= (impl ...) (other ...)))
And then test with different properties created with (make-prop ...).
Reid
On Friday, May 2, 2014 1:38:27 PM UTC-5, Brian Craft wrote:
>
> Wow, I never would have figured that out from the docs. Thanks.
>
> Just found a different problem with my solution: nested tests, as
> described in the docs, prevent the use of fixtures. You have to add
> test-ns-hook when using nested tests, and then fixtures aren't run.
>
> On Friday, May 2, 2014 11:05:56 AM UTC-7, Karsten Schmidt wrote:
>>
>> You can use the `testing` macro and wrap it in a function, which accepts
>> your type/protocol implementation or even individual protocol methods as
>> args. Example here:
>>
>> https://github.com/thi-ng/geom/blob/master/test/core.org#callable-contexts
>> On 2 May 2014 18:08, "Brian Craft" wrote:
>>
>>> Thanks. I did something similar. I have different implementations per
>>> db, so use a global *db* var:
>>>
>>> (ct/deftest run-tests
>>> (matrix1)) ; matrix1 tests against *db*
>>>
>>> (ct/deftest test-h2
>>> (binding [*db* (h2/create-db2 "test" {:subprotocol "h2:mem"})]
>>> (run-tests)))
>>>
>>> (defn test-ns-hook []
>>> (test-h2))
>>>
>>> Clumsy, but seems to be the only option.
>>>
>>> On Friday, May 2, 2014 8:29:23 AM UTC-7, Chris Price wrote:
I have been curious about this too. I was playing around with it a few
weeks ago and came up with this:
https://github.com/cprice404/clj-shared-test-sandbox/blob/
master/test/shared_tests_foo/core_test.clj
Which is pretty gross; it uses `binding` + a dynamic var in the shared
test namespace, and then it calls `clojure.test/run-tests` from inside of
a
`deftest`. I'm sure there's got to be a better way, but that was as far
as
I got in the small amount of time that I was able to spend on it.
On Thursday, May 1, 2014 5:58:51 PM UTC-7, Brian Craft wrote:
>
> I have a number of tests that I would like to run against different
> implementations of a protocol. In clojure.test there doesn't appear to be
> a
> way to parameterize a test over the implementations. Is there a good way
> to
> do this?
>
--
>>> 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.
Re: test.check, quickcheck concurrency
Hi Brian, clojure.test.check does not currently ship with any concurrency support. That being said, I've been working an implementation on Erlang's PULSE, which I hope to have usable in the next couple months [1][2]. John's talk touches on using state machines to test concurrent code, which is something I'd like to attack eventually, but don't have any concrete plans at the moment. Reid [1] https://groups.google.com/forum/#!topic/clojure-dev/GhG-PbKW_ew [2] http://www.cse.chalmers.se/~nicsma/papers/finding-race-conditions.pdf On Friday, March 28, 2014 11:48:20 PM UTC-5, Brian Craft wrote: > > Re: John Hughes' talk at clojure/west, at the end he did a fairly > incredible demo of testing concurrency. It doesn't look like this was > implemented in test.check (or I'm not finding it). Are there any plans? > -- 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.
Re: [GSoC] Proposal, question and possible call for menthor
I think #2 would be a great addition to test.check, and I'd be happy to be a mentor. Reid On Wednesday, March 19, 2014 3:49:30 PM UTC-5, Dmitry Groshev wrote: > > Hello, Clojurians! > > GSoC application deadline is dangerously close and it's time to fill an > application, at last. But here is a problem: I don't know what will be the > best for community. I have a few ideas and I will present them here to get > some feedback. Sorry for a bit late posting! > > First: this is the idea listed on Ideas Page [1], "Data Visualization > Components with Om / React.js". I would like to participate; in particular, > I'm very interested in building a decent graph rendering library. It seems > like there are a lot of JS libraries to draw graphs out there, but all of > them lack features that I needed one time or another: > -composable layouts/transformations, like in Gephi (you can run one > "transformation" after another there); > -"static" rendering without fancy animation of force-based layout; > -efficient handling of data changes (here is where React can be useful); > -ability to add user-defined forces. It's very useful when you have > special nodes that should be pulled to particular points. > Of course, this should be based on top of React's model, which adds an > interesting exploratory aspect to the project. > Mentor: I've tried to contact Kovas about this project, but wasn't > successful. I hope that was a mail quirk. > > Second: when I write Erlang, I enjoy PropEr (an Erlang property testing > library) a lot. Some time ago a similar system was created for Clojure > (test.check [2]). It's a decent property-based checker, but a couple of > things are still lacking: > -support for stateful system checking. This is called "statem" in PropEr > and described in [3]. It's based on modelling stateful system as FSM and > comparing behaviour of model and system under test. One of interesting > usages of "statem" in PropEr is to test external servers: for example, > properly-designed REST API can be modelled pretty easily by a FSM. > -support for automatic generator inference from type specifications (in > Clojure Prismatic's Schema can be used) [4]. Obviously, it makes using > property-testing a lot easier. > -support for generator statistics — what instances was generated, what was > the distribution of test sizes and so on. > In this project, if it will be selected, I will implement this three > features for test.check. I had very positive experience with PropEr and I > hope that this project can help more people start using property-based > testing. > Mentor: Reid Draper. I contacted him and he agreed to mentor the project. > > Third: arguably, one of the best plotting libraries around is R's ggplot > [5]. It was recently ported to Python, as well [6]. It's different from all > other libraries of the kind in that it implements a "grammar of graphics": > small pieces of reusable functionality that together constitute plots. Here > is an example: > > ggplot(mry, aes(x=year, y=number, group=rating)) + geom_line(aes(colour = > rating)) + scale_colour_gradient(low="red") # produces [7] > > This fits Clojure's ideology nicely. It can also be even better in Clojure > after a small modification of original ggplot design, which is replacing > "overloaded plus" style with plain vectors. This is a big project, but I > believe I can port this library to Clojure and ClojureScript in GSoC > timeframe. The majority of code will be the same, and because this will not > be a core.X project, I will be able to use cljx to share code. One of > spin-offs from this project will be a simple "dataframe-like" (think R or > Python's pandas [8]) data structure usable in both languages. > Mentor: there is no at this point. I will appreciate a lot if someone will > volunteer. > > This concludes the list of ideas. Please share your thoughts and let me > know, if you are able to mentor me on third project! I will fill an > application in 36 hours from now. > > [1]: http://dev.clojure.org/display/community/Project+Ideas > [2]: https://github.com/clojure/test.check > [3]: http://proper.softlab.ntua.gr/papers/eirini-thesis.pdf > [4]: http://proper.softlab.ntua.gr/papers/proper_types.pdf > [5]: http://ggplot2.org/ > [6]: https://pypi.python.org/pypi/ggplot > [7]: http://docs.ggplot2.org/current/geom_line-8.png > [8]: http://pandas.pydata.org/ > -- 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 tha
Re: [ANN] clojure.test.check (previously, simple-check)
Hey Andrew, Good question. tl;dr, change your test to: (tc/quick-check 100 prop1 :max-size 50) ;; and that should pass. Longer explanation: test.check's generators take two parameters, a random number generator, and an integer 'size'. During testing, the size starts at 0, and increases up to some fixed maximum. This is used to that the 'size' of the generated data increases as more and more tests pass. The rationale here is that you don't want your very first to generate a million-length vector, when, if there is a bug, its more than likely also present with 'smaller' data. As it turns out, with a complex generator like gen/any, a size of 100 (the default maximum) can generate very large, nested data-structures. This is explained in some detail in the documentation [1]. I've tried to make all of the built-in generators have sane defaults, but its appear like gen/any can still generate massive, nested structures with the default values. I'll look into a more sane default sizing strategy for this generator. As I mention in the tl;dr above, you can set the maximum 'size' used during testing. [1] https://github.com/clojure/test.check/blob/master/doc/intro.md#recursive-generators On Feb 28, 2014, at 3:41 AM, keeds wrote: > Hi Reid, > This is excellent. Just experimenting and trying to get my head around it. > Not sure if I'm doing any wrong or stupid!! If I test a function that relies > on Exception handling internally as I reach 100 tests it takes forever and > eventually blows the heap. > > Simple contrived example: > > (ns check > (:require [clojure.test.check :as tc] > [clojure.test.check.generators :as gen] > [clojure.test.check.properties :as prop] > )) > > (defn format1 [x] > (try > (->> (double x) > (format "%,.0f")) > (catch Exception e ""))) > > (def prop1 > (prop/for-all [v gen/any] > (string? (format1 v > > #_ (tc/quick-check 100 prop1) ;; blows heap > > Thanks, > Andrew > > On Thursday, 27 February 2014 17:22:44 UTC, Reid Draper wrote: > I'm happy to announce the first release of the newest Clojure contrib library: > test.check [1]. Previously named simple-check [1], test.check is a > property-based testing library, based on QuickCheck. The README has a guide > for > migrating from simple-check, as well as some getting-started documentation. > I'm > happy to answer any questions here as well. Or, stop by my Clojure/West talk > in > March. > > [1] https://github.com/clojure/test.check > [2] https://github.com/reiddraper/simple-check > > > -- > 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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/EPNoH4JEiVQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
[ANN] clojure.test.check (previously, simple-check)
I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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/groups/opt_out.
Re: simple-check gen/boolean Only Returning false
Thanks for reporting. This was introduced in 0.5.4, and I've pushed a fixed release as 0.5.6. On Saturday, January 25, 2014 7:50:19 PM UTC-6, Jean Niklas L'orange wrote: > > > > On Saturday, January 25, 2014 10:03:13 PM UTC+1, Michael Daines wrote: >> >> I decided to play with simple-check for the first time and was working >> through the examples on github. I noticed that all the values that use >> gen/boolean are returning false. I never get a true. >> >> At the extreme end, the following never returns when run in the repl: >> >> (gen/sample (gen/such-that true? (gen/list gen/boolean))) >> >> >> I'm using Clojure 1.5.1, simple-check 0.5.5, JVM 1.7.0_51, Ubuntu 13.04. >> > > Yeah, you're correct that this is an error in 0.5.5; I traced down the > cause and sent in an issue which can be found here: > https://github.com/reiddraper/simple-check/issues/54. > > You can downgrade to simple-check 0.5.3 in the meantime – that version has > not the bug you encountered. > > -- JN > -- -- 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/groups/opt_out.
Re: [ANN] simple-sheck - A QuickCheck inspired testing tool
On Jul 17, 2013, at 12:56 AM, Alex Baranosky wrote: > Hi Reid, > > I dig how nicely it integrates with clojure.test. Does simple-check > implement some form of shrinking? It does. The README has an example of the output when a property fails (and the input is shrunk), but it's also easy to just write a failing property and see it shrink yourself. Overall I'm quite proud of how well shrinking has been working in simple-check. Reid -- -- 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/groups/opt_out.
Re: [ANN] simple-sheck - A QuickCheck inspired testing tool
Derp, I fat-fingered my own library name in the subject :) On Tuesday, July 16, 2013 2:18:54 PM UTC-5, Reid Draper wrote: > > I'm happy to announce the first non-snapshot version (0.1.0) of > simple-check, a QuickCheck inspired testing tool: > https://github.com/reiddraper/simple-check. > > simple-check is a fairly faithful port of a subset of Haskell's > QuickCheck, with some additional inspiration from Erlang QuickCheck. With > simple-check, you write your tests as a property that holds true for all > input to your function. So, supposing you were testing the `reverse` > function, you might say: for all vectors V, the reverse of the reverse of V > is equal to V. Further, reversing V preserves it's count. simple-check will > then test your property with some number of random input. If the property > fails, simple-check will attempt to 'shrink' the input, finding smaller > input for which the test still fails, where 'smaller' is data-type > specific. More documentation is available in the README, and API > documentation: http://reiddraper.github.io/simple-check/. Enjoy, and > please don't hesitate with feedback, positive or negative. > > Reid > -- -- 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/groups/opt_out.
[ANN] simple-sheck - A QuickCheck inspired testing tool
I'm happy to announce the first non-snapshot version (0.1.0) of simple-check, a QuickCheck inspired testing tool: https://github.com/reiddraper/simple-check. simple-check is a fairly faithful port of a subset of Haskell's QuickCheck, with some additional inspiration from Erlang QuickCheck. With simple-check, you write your tests as a property that holds true for all input to your function. So, supposing you were testing the `reverse` function, you might say: for all vectors V, the reverse of the reverse of V is equal to V. Further, reversing V preserves it's count. simple-check will then test your property with some number of random input. If the property fails, simple-check will attempt to 'shrink' the input, finding smaller input for which the test still fails, where 'smaller' is data-type specific. More documentation is available in the README, and API documentation: http://reiddraper.github.io/simple-check/. Enjoy, and please don't hesitate with feedback, positive or negative. Reid -- -- 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/groups/opt_out.
Re: test.generative and data.generators
On Monday, July 15, 2013 9:41:03 AM UTC-5, Andreas Liljeqvist wrote: > > Hi, I have taken a look at simple-check. > > Seems promising, but I have a few reservations: > > I want to constrain the generation of two vectors to always have the same > number of elements as the other one. > From what I can understand simple-check always uses the same max-size in a > property and have no current means to control the min length. > This is doable today, but ensuring they stay the same length as each other during shrinking is not yet possible. simple-check will need to support overriding the shrink function for this to work. That's on my TODO list. I'll try and add some documentation for writing generators like this soon, but in the meantime, take a look at how the vector generator is implemented [1]. Your custom generator would just use `num-elements` twice, for each of the two vectors that need to be the same length. [1] https://github.com/reiddraper/simple-check/blob/bbd90a76d78f5cdf25b22d9eec9fc7eedf2c8d09/src/simple_check/generators.clj#L261-L262 > > Its kind of hard to inspect what values I am actually generating since the > generator functions return non-runnable functions. > (without any scaffolding). > This is what simple-check.generators/sample is for. Check out it's implementation to see how the generators are called. > > Really I think that data.generators would fit nicely into simple-check. > (I am not well-versed in the domain though...) > Yeah, I've been thinking about writing a little function that would lift data.generators generators into simple-check generators, but haven't gotten around to it yet. Should be pretty trivial though. > > I like the general feel of simple-check and shrinking rocks. > Awesome, thanks for checking it out. > > > > > On Mon, Jul 15, 2013 at 2:24 PM, Chas Emerick > > wrote: > >> Shrinking is a key requirement for me as well (1000-line-long data >> literals that produce a failure are better than nothing, but not quite as >> nice as its shrunken 40-character literal that provokes the same failure). >> You might be interested in simple-check, which is a "Clojure >> property-based testing tool inspired by QuickCheck", and so its support for >> shrinking is essential: >> >> https://github.com/reiddraper/simple-check/ >> >> I've been using it for some weeks now with good results. >> >> Cheers, >> >> - Chas >> >> On Jul 15, 2013, at 7:35 AM, Andreas Liljeqvist wrote: >> >> So, I find that what they provide are absolutely fantastic. >> But I don't see much action around them, are they considered maintained? >> >> Things on my wishlish: >> Shrinking of failing inputs. >> More readable reports. >> A couple of blogs or videos discussing them, I think that most people >> don't know what they are used for. >> >> -- >> -- >> 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/groups/opt_out. >> >> >> >> >> -- >> -- >> 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/groups/opt_out. >> >> >> > > -- -- 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 http
Re: core.logic program doesn't terminate
On Monday, March 26, 2012 5:19:30 PM UTC-4, David Nolen wrote: > > On Mon, Mar 26, 2012 at 5:10 PM, Reid Draper wrote: > >> Moving the unification of `c` to the top of the run form worked, thanks. >> Any thoughts on these questions, from the bottom of the gist: >> >> 1. How can I make the list of ingredients and cocktail names a set >> instead of a list (or at least a unique list)? >> > > You could write probably a helper relation with != that gives that > guarantee. Yet another thing that cKanren offers out of the box - > alldiff/fd. > > >> 2. Is there a better way to describe the problem to answer a question >> like, "what list of N ingredients makes the most different cocktails?" >> > > Some things are easier to solve in Clojure :) Tag each result with the > ingredients list - then use Clojure reduce one the results of run* to > determine which sets of ingredients products the most different cocktails. > > I'm sure there are other solutions - but the beauty of miniKanren is how > easily you can switch between paradigms at your convenience. > Does cKanren share this property? > > > David > -- 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
Re: core.logic program doesn't terminate
Moving the unification of `c` to the top of the run form worked, thanks. Any thoughts on these questions, from the bottom of the gist: 1. How can I make the list of ingredients and cocktail names a set instead of a list (or at least a unique list)? 2. Is there a better way to describe the problem to answer a question like, "what list of N ingredients makes the most different cocktails?" Thanks again. On Monday, March 26, 2012 3:07:19 PM UTC-4, David Nolen wrote: > > On Mon, Mar 26, 2012 at 2:49 PM, Reid Draper wrote: > >> >> >> On Sunday, March 25, 2012 11:07:33 PM UTC-4, David Nolen wrote: >>> >>> I'll try to take a closer look soon - but first, did you try unifying c >>> earlier? You have to be careful with recursive goals and fresh vars. >> >> This probably just shows my naivety, but what do you mean unifying c >> earlier? The order of forms in a `run` clause don't matter, right? >> > > They *mostly* don't. One unfortunate flaw in the miniKanren system is that > recursive calls generally need to come last. I suspect this problem will be > less common when we get to cKanren. > > David > -- 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
Re: core.logic program doesn't terminate
On Sunday, March 25, 2012 11:07:33 PM UTC-4, David Nolen wrote: > > I'll try to take a closer look soon - but first, did you try unifying c > earlier? You have to be careful with recursive goals and fresh vars. This probably just shows my naivety, but what do you mean unifying c earlier? The order of forms in a `run` clause don't matter, right? > > David > > On Sun, Mar 25, 2012 at 4:59 PM, Reid Draper wrote: > >> I've been playing around with core.logic and >> have written a few things that don't seem to >> terminate. My intuition says they should work, >> but I imagine I'm either making a simple >> mistake, or abusing something. >> >> I've written the question as a gist, >> for better formatting >> >> https://gist.github.com/2199463 >> >> I'd appreciate any feedback, or tips >> on how to debug issues like this. >> >> Thanks >> >> -- >> 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 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
core.logic program doesn't terminate
I've been playing around with core.logic and have written a few things that don't seem to terminate. My intuition says they should work, but I imagine I'm either making a simple mistake, or abusing something. I've written the question as a gist, for better formatting https://gist.github.com/2199463 I'd appreciate any feedback, or tips on how to debug issues like this. Thanks -- 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
