Valentin Chaboche

I just started working on a project where I'd like to have that kind of feature for generators. I'll let you know If I come up with something usable for...

I totally agree with you too (especially with the generator names). Also, should we remove the module `Gen` and access it directly with `QCheck2.*` just like we had with `arbitrary`?...

I think I can extract one example pretty easily. One co-worker wrote a Merkle Tree or something, it shouldn't have too much dependency with our project.

> I think I can extract one example pretty easily. One co-worker wrote a Merkle Tree or something, it shouldn't have too much dependency with our project. Well, you shouldn't...

I'd propose to not require #191 for the first release. I currently have the time to solve multiple issues in that list, but, unfortunately I don't think I can right...

> As I wrote elsewhere I think only #188 is required before a release (from my POV) Required yes maybe. It will work for QCheck2, but it's a bit unfortunate...

> Any updates on this? Is there something a new contributor could help with? > > So far I am a happy user of `qcheck` (thanks!) and recently ran into...

> Have you tried running Coverage report with bisect_ppx #206 to see how bad it is? sweat_smile It's not that bad! A checkout to a commit 6 months ago would...

I think `qcheck` and `qcheck2` are fine when we only derive one thing. When #191 is done, what would the plugin `qcheck` derives? We could have the library version as...

> Would it make sense for `[@@deriving qcheck]` to also produce an arbitrary object in addition to gen + shrinker? Well, yes we can. However, there are two solutions: *...