3 ms·

I'm afraid that when dealing with nondeterminism, you do need to be perfect. If even one call is nondeterministic, you've corrupted your entire replay. This

I'm afraid that when dealing with nondeterminism, you *do* need to be perfect. If even one call is nondeterministic, you've corrupted your entire replay. This is a common challenge with e.g. RTS games, and it means we have to very carefully discover and avoid nondeterministic functions. For example, did you know that C#'s string's hash code calculation is nondeterministic across runs? The same can be said for any floating point calculations, iterating Rust's/Go's default hash maps, etc. Also, IME most interactions with GUI do have side effects, GUI apps tend to be very stateful.

Skinney 5y ago
> For example, did you know that C#'s string's hash code calculation is nondeterministic across runs? ... iterating Rust's/Go's default hash maps, etc. I do, but I also know that in Java, C#, Rust and Go it's well documented that you should not rely on the iteration order of the values in a hashmap or hash-based collection, which (at least in Go) is one of the reasons hash-iteration order is randomized across runs. If a bug is caused by this kind of nondeterminism, you're likely to catch the bug by replaying the history multiple times. In other words, if the history isn't perfect due to nondeterminism, the history is still useful in tracking down bugs because that nondetermism will be revealed over multiple replays.