-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot use Rng methods on Gen
when implementing Arbitrary
#279
Comments
Seems related to #267 |
Yes. The plan is to make a seed available, and then you should be able to materialize any RNG from that. |
This really hurts the ability to write good Arbitrary impls for complicated data. I'm sure there are lots of examples, but my use case can be reduced to just a vector of vectors, If the issue with |
Is there a known plan to make this work that would be followed by a first time contributor? |
Perhaps a bit hacky, but the workaround I ended up using was:
|
...and switch the 32-bit integer parser to just exhaustive checking. (More on that later.) Why move away from QuickCheck? 1. The maintainer appears to have little interest in actually maintaining it. BurntSushi/quickcheck#315 2. Its API is incredibly inefficient, especially on failure, and it's far too rigid for my needs. For one, I need something looser than `Arbitrary: Clone` so things like `std::io::Error` can be generated more easily. Also, with larger structures, efficiency will directly correlate to faster test runs. Also, I've run into the limitations of not being able to access the underlying random number generator far too many times to count, as I frequently need to generate random values within ranges, among other things. - BurntSushi/quickcheck#279 - BurntSushi/quickcheck#312 - BurntSushi/quickcheck#320 - BurntSushi/quickcheck#267 3. It correctly limits generated `Vec` and `String` length, but it doesn't similarly enforce limits on test length. 4. There's numerous open issues in it that I've addressed, in some cases by better core design. To name a few particularly bad ones: - Misuse of runtime bounds in `Duration` generation, `SystemTime` generation able to panic for unrelated reasons: BurntSushi/quickcheck#321 - Incorrect generation of `SystemTime`: BurntSushi/quickcheck#321 - Unbounded float shrinkers: BurntSushi/quickcheck#295 - Avoiding pointless debug string building: BurntSushi/quickcheck#303 - Signed shrinker shrinks to the most negative value, leading to occasional internal panics: BurntSushi/quickcheck#301 There's still some room for improvement, like switching away from a recursive loop: BurntSushi/quickcheck#285. But, this is good enough for my use cases right now. And this code base is structured such that such a change is *much* easier to do. (It's also considerably simpler.) As for the integer parser change, I found a way to re-structure it so I could perform true exhaustive testing on it. Every code path has every combination of inputs tested, except for memory space as a whole. This gives me enough confidence that I can ditch the randomized property checking for it.
I noticed when trying to update a project to
quickcheck
1.x, thatGen
is now an opaque struct and users implementingArbitrary
can only useGen::choose
to get randomness. This isn't sufficient in some usecases, which were previously served by usingGen
'sRng
methods: for instance, in uutils'factor
I need to draw integers from large ranges known at runtime, to generate integers of known factorization:(Technically, I could repeatedly use
gen.choose(&[0, 1])
to draw individual, random bits, but this would be beyond silly)The text was updated successfully, but these errors were encountered: