we replace its spec.
>
> (stest/instrument `do-y
> {:stub #{`do-y}
>:spec {`do-y (s/fspec
> :args (s/cat :y-er (s/with-gen ::y
>(fn [] y-gen)))
.alpha{:path [:y-er], :form :spec-ex.core/y, :failure
> :no-gen}
>
> ;; However, we *can* stub `do-y` if we replace its spec.
>
> (stest/instrument `do-y
> {:stub #{`do-y}
>:spec {`do-y (s/fspec
> :args (s/cat :y-er (s/
::y
(fn [] y-gen}})
;; => [spec-ex.core/do-y]
There is a ticket open[ (CLJ-2095[1]) regarding using overrides s/gen with
custom generators. Is this a case where this applies? I can imagine that it
could be. Not overriding something tha
appears there is no way to do the same for a custom predicate
>> function. I see that the generators for predicate functions testing for
>> core primitives are hard-coded in the private
>> clojure.spec.gen\gen-builtins. Curious why this isn't extensible, since it
>&
rsday, December 8, 2016 at 10:56:29 AM UTC-6, Dave Dixon wrote:
>
> Though one can obviously attach a custom generator to a keyword-named
> spec, it appears there is no way to do the same for a custom predicate
> function. I see that the generators for predicate functions testing for
Though one can obviously attach a custom generator to a keyword-named spec,
it appears there is no way to do the same for a custom predicate function.
I see that the generators for predicate functions testing for core
primitives are hard-coded in the private clojure.spec.gen\gen-builtins
screencast-customizing-generators
using gen/fmap and gen/bind which is probably the best way to build
something like this.
As an example, if you need to test on a graph of nodes, your model might
consist of first creating random nodes, then generating random edges
between the nodes (rather tha
Thanks - the start of that thread was indeed interesting, but it quickly
changed course towards a discussion on whether Spec should check function
outputs. Rich hinted at exactly the kind of in-depth discussion I wanted to
find — but much too briefly...
--
You received this message because yo
s of type F.
>
> It is trivial to have Spec generate completely random nodes to test
> functions that can ignore the business rules. However, other functions do
> depend on the business rules, and for those it is necessary to somewhat
> "guide" the generators towards random
al to have Spec generate completely random nodes to test
functions that can ignore the business rules. However, other functions do
depend on the business rules, and for those it is necessary to somewhat
"guide" the generators towards random-but-compliant output. And here I'm
s
Ah, I missed thatthank you very much!
--
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 unsubs
at 3:17:19 PM UTC+11, J.-F. Rompre wrote:
>
> I am trying to learn clojure.spec and tried my hand at a spec for a
> fizzbuzz function.
> For some strange reason, generators created for it fail the same spec
> during clojure.spec/exercise-fn !
>
> Stranger, this happens onl
I am trying to learn clojure.spec and tried my hand at a spec for a
fizzbuzz function.
For some strange reason, generators created for it fail the same spec
during clojure.spec/exercise-fn !
Stranger, this happens only if the same function is first instrumented
using clojure.spec.stest
Is there a reason why some clojure.test.check generators are excluded from
clojure.spec.gen lazy primitives?
https://github.com/clojure/clojure/blob/1f25347a7b219488d5d9f8d17b04f2cc7828b30e/src/clj/clojure/spec/gen.clj#L114
The nat generator as one example is missing.
Best regards,
Joe N
I've added a new section to the clojure.spec guide for generators.
Certainly doesn't cover everything yet but hope it helps!
http://clojure.org/guides/spec#_generators
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post
We've released schema-generators 0.1.0, which includes ClojureScript
support via cljc:
https://github.com/plumatic/schema-generators
This library allows you to generate test data from most plumatic/schemas
out of the box, as well as automatically "complete" partial datums -- whi
>
> But the plan is to merge it into the core Boot project at some point (once
> we get a bit more feedback on boot-new itself and its templates and
> generators) to knock off any rough edges.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://
boot-new itself and its templates and generators) to
knock off any rough edges.
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
--
You received this message because
nk
On Saturday, February 13, 2016 at 2:21:18 PM UTC-8, Sean Corfield wrote:
>
> What / Where?
> Boot new — a task to produce new projects from Boot and/or Leiningen
> templates!
> boot-new 0.4.0 — https://github.com/seancorfield/boot-new
>
> Updates?
> Now supports generators to a
What / Where?
Boot new — a task to produce new projects from Boot and/or Leiningen templates!
boot-new 0.4.0 — https://github.com/seancorfield/boot-new
Updates?
Now supports generators to add / modify code in the current project!
Add a new namespace with: boot new –g ns=foo.bar.quux
Add a new
Thanks. That looks useful.
On Jul 30, 2015 6:14 AM, "Mikera" wrote:
> See:
>
> https://github.com/clojure/test.check/commit/d4883873df73717629272d0ab71619d7e58c9c9e
>
> On Wednesday, 29 July 2015 23:31:14 UTC+8, Mayank Jain wrote:
>>
>> Nice. Any updates on this?
>> Is this a good idea?
>>
>> On
See:
https://github.com/clojure/test.check/commit/d4883873df73717629272d0ab71619d7e58c9c9e
On Wednesday, 29 July 2015 23:31:14 UTC+8, Mayank Jain wrote:
>
> Nice. Any updates on this?
> Is this a good idea?
>
> On Friday, May 15, 2015 at 12:13:06 PM UTC+5:30, Mikera wrote:
>>
>> Hi all,
>>
>> I am
Nice. Any updates on this?
Is this a good idea?
On Friday, May 15, 2015 at 12:13:06 PM UTC+5:30, Mikera wrote:
>
> Hi all,
>
> I am doing some generative testing with test.check and need a way to
> control the growth rate of data structures (the regular linear growth
> quickly makes the computat
Hi all,
I am doing some generative testing with test.check and need a way to
control the growth rate of data structures (the regular linear growth
quickly makes the computations too large for meaningful testing usage). I
came up with the following solution to do this:
(defn gen-resize
"Crea
: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 <http://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
You can to use gen/fmap to build up generators. Here's an example:
;; generates a millisecond using gen/choose, then maps that to a time
instance using my u/ms-to-time function.
(def result-gen
(->> (gen/choose 0 u/max-time)
(gen/fmap u/ms-to-time)))
;; Generates EITHER
Hi there,
I'm trying to get my head wrapped around test.check
<https://github.com/clojure/test.check/>. My current stumbling block is
custom generators. Of course I've combed through the docs
<https://github.com/clojure/test.check/blob/master/doc/intro.md#record-generators
On Saturday, June 7, 2014 7:09:53 PM UTC-5, Alexander Hudek wrote:
>
> Keep in mind that there could be accuracy reasons why you might want to
> use multiple random number generators (aka multiple streams). See the
> section "Single Versus Multiple Streams" here:
>
Keep in mind that there could be accuracy reasons why you might want to use
multiple random number generators (aka multiple streams). See the section
"Single Versus Multiple Streams" here:
http://www.cse.msu.edu/~cse808/CSIM_Notes03/cse808/html_c/16random.htm
Also, the built in j
On Friday, June 6, 2014 10:33:04 PM UTC-5, Mars0i wrote:
>
> On Friday, June 6, 2014 2:26:25 PM UTC-5, Linus Ericsson wrote:
>>
>> Here I assume that the incoming calls to agents aren't guaranteed to
>> strictly ordered among different agents, even though the agents reside in
>> one of two thre
Wow. Linus, thanks for the very detailed answer.
It sounds as your view is that there's no problem with the logic of my
proposed solution, but it seems wasteful to create 100 RNGs, when I don't
actually need to have so many of them. Your solutions provide ways to get
the same result without m
Thanks Lee. It looks like this could be useful.
On Friday, June 6, 2014 4:19:11 PM UTC-5, Lee wrote:
>
>
> I don't know if this will be helpful in your application, or even if it's
> the best approach for our own work (or if java 1.7 provides a simpler
> approach?), but FWIW one of my projects
Gotcha. By all means then, hack away. ;-)
--
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 unsubs
Gary, I fully acknowledge that there are many ways to create lazy sequences
that are much more elegant and efficient. However, as I mentioned, I'm very
fascinated by generators in Python, and I mostly wanted to toy around with
how to implement it in Clojure. Also, as I mentioned, for begi
I don't know if this will be helpful in your application, or even if it's the
best approach for our own work (or if java 1.7 provides a simpler approach?),
but FWIW one of my projects deals with the thread-local RNG issue via:
https://clojars.org/clj-random
-Lee
On Jun 6, 2014, at 12:28 PM,
(I think your stepwise problem is better to be solved without agents, see
below.)
I realized that the *rng* actually is conflated, it keeps both the state
for the random number generator AND the algorithm used for the random
number generation. This is usually not a problem, since the state-size an
On Friday, June 6, 2014 2:05:16 PM UTC-5, Gunnar Völkel wrote:
>
> In Java 7 you would use ThreadLocalRandom you said in another thread.
> Well, in Java 6 you already have ThreadLocal [1] and thus you are able to
> build a thread local Random yourself to keep Java 6 as minimum requirement.
>
> [1
In Java 7 you would use ThreadLocalRandom you said in another thread. Well,
in Java 6 you already have ThreadLocal [1] and thus you are able to build a
thread local Random yourself to keep Java 6 as minimum requirement.
[1]
http://docs.oracle.com/javase/6/docs/api/index.html?java/lang/ThreadLoc
One more point:
I would save the system-time-determined seed of the initial RNG to a file
(i.e. the RNG used to generate seeds for each Person's RNG). I believe
this will allow me to re-run a simulation with identical results, by
seeding the initial RNG with the seed saved from the previous si
I'm writing an agent-based simulation framework, in which agents are
Clojure records called Persons. There are 40-100 persons at present, but
conceivably the number could go up to 1000. In each timestep, Persons'
states are functionally updated by mapping update functions across the
collectio
://github.com/halgari/async-bench/blob/master/src/async_bench/core.clj#L64
WARNING: this uses unpublished APIs from core.async, use at your own risk.
Timothy
On Wed, Jun 4, 2014 at 9:43 AM, Gary Johnson wrote:
> What new features does this syntax provide over the existing infinite
> sequence gene
What new features does this syntax provide over the existing infinite
sequence generators?
- lazy-seq
- iterate
- repeat
- repeatedly
- range
I realize you provided a simple example for clarity, but perhaps you could
illustrate something more complex that couldn't be done with the
https://github.com/aengelberg/clj-generators
My all-time favorite feature of Python is "generators." It allows you to
write lazy sequences imperatively.
def infinite_range():
x = 1
while True:
yield x
x += 1
for i in infinite_range():
if (i > 5):
I'm fairly new to Clojure and this was a fun little exercise to try.
(def color-map (reduce #(assoc % (count %) %2) {} [:red :yellow :blue
:green :purple]))
color-map
=> {4 :purple, 3 :green, 2 :blue, 1 :yellow, 0 :red}
(defn random-repeating-map
([coll-map] (random-repeating-map coll-map col
true, he did say 'or something that would be as useful', but lazy-seqs are
more useful :-).
On Wed, Mar 26, 2014 at 4:08 PM, Ben Wolfson wrote:
> "cycle" isn't really the same thing, though, at least if the OP really
> does require (for some reason) something that can be called repeatedly and
>
"cycle" isn't really the same thing, though, at least if the OP really does
require (for some reason) something that can be called repeatedly and get a
different answer each time.
On Wed, Mar 26, 2014 at 1:05 PM, Gary Trakhman wrote:
> cycle - http://clojuredocs.org/clojure_core/clojure.core/cyc
If you really want something that can be called repeatedly and returns
something different each time (rather than just iterating through an
infinite sequence, which seems like it would be the more functional-ish
approach):
user> (defn cycle-gen [input]
(let [iter (atom (cycle input))]
cycle - http://clojuredocs.org/clojure_core/clojure.core/cycle
And generally, this class of functionality is called lazy-seqs.
On Wed, Mar 26, 2014 at 3:59 PM, Christopher Howard wrote:
> Hi. I'm still fairly new to Clojure. I was wondering: What's the
> easiest way to make a generator (or some
Hi. I'm still fairly new to Clojure. I was wondering: What's the
easiest way to make a generator (or something that would be as useful).
In one application, I need something that will return a different color
each time I call it - following a predefined list of colors, and
starting over again at th
I need to pull sequence ids from a db, which is a lot like using a
generator. I found this thread about generators:
https://groups.google.com/forum/?fromgroups=#!searchin/clojure/generator/clojure/IL_ONPb52-0/S_2p2-vjVCYJ
which suggests using seqs, like so:
(defn sines []
(cycle (map
51 matches
Mail list logo
