- User Since
- Oct 17 2018, 3:58 AM (27 w, 1 d)
Thu, Apr 18
Unwanted phabsend on that one (decidedly prematurate, sorry).
Wed, Apr 17
I believe to have addressed your immediate concerns.
As I've tried to make clear in the changeset description, this is still work in progress.
Tue, Apr 16
Mon, Apr 15
What I would probably do is still implement the Rust part with multiple structs but then wrap it in an enum for the python API.
@kevincox, thanks for the review, updated version available.
@kevincox Thanks for the reviews !
@pulkit, thanks, abandoned this one.
Fri, Apr 12
Oops sorry, this one has already been queued by @pulkit (sent it by email, but it was still a draft in my stack).
Thu, Apr 11
Mon, Apr 8
Mar 15 2019
I thought of "closure" as well, but I fear it has too many possible meanings, "transitive closure" being one of them in that context (certainly related, but not the same thing), and of course the closures in functional programming.
Mar 6 2019
Feb 21 2019
Feb 15 2019
Feb 13 2019
Feb 12 2019
@yuja I'm trying to find a compromise between our points of view : I'd like very much it to be run automatically (hence an integration test), and you want to be parametrizable. So, I'm pushing a version that has these two properties, working with env variables, since command-line arguments are already used by the testing framework. Hope it'll suit you, if it doesn't, I'll put it in examples and find a way to run it anyway
Feb 5 2019
@yuja we don't need a seed to reproduce: failed examples contain all the information (that's a difference with the Python version)
Feb 4 2019
@yuja now that 4.9 is out, I'm getting back to this.
Jan 25 2019
Jan 16 2019
@yuja the doc you're linking is about integration tests, so it wouldn't apply to these tests which are really unitary in my mind. Usually the main difference would be the access to the private constructs that the integration tests can't perform, but it's true that most of these implementations are public anyway.