I am not understanding here.

On 5/18/26 14:42, Shiro Kawai wrote:
 > The saved state cannot stay in the build tree, as it is completely
 > cleaned or freshly check out before each new test. [...]
> It is much easier if the seed(s) are written into test files and
> commited to the repo.

What stopping you from committing the serialized state as test data? If
you need it to reproduce behavior, then it's no different than
committing something like an example script to test for compiler bugs,
or an example document to test for parser bugs.

If one really wanted to have the seed in the actual test script, then
many algorithms have short enough seeds to be reasonably embedded in a
source file. For example, I ran `(write (random-port-state
(make-random-port)))` with the sample implementation. I get the
following out:

     #u8(73 50 30 230 10 135 184 200 41 134 184 204 39 36 250 177 243
231 148 216 214 177 91 34 35 171 97 253 214 2 76 73)

I can write that state into a Scheme code file, as it is just a constant.

Saving and restoring state is implementation-specific, but that is not a
problem: a generic seed like "7" would generate different sequences on
different implementations. You can use a specific algorithm by importing
`(srfi 271 determinized xoshiro256++)` (or other).

-- Peter McGoron