generate-alt-random-writes: use python random, allow setting a seed #251

sterni commented 2020年12月20日 14:53:37 +01:00

Using Python's own PRNG should make the code cleaner and allow for
reproducible stimulus files if that is desired via setting --seed (at
least for the same versions of the script, changing the kind and/or
order of the random calls will of course impact the output in the
future).

I did the following substitutions:

• rand.read(1)[0] % n and struct.unpack('@H', rand.read(2))[0] % n →
  random.randrange(n)
• rand.read(1)[0] → random.randrange(256)
• rand.read(n) → [random.randrange(256) for _ in range(n)]
  (better alternative would have been random.randbytes(n), but is only
  available for Python >= 3.9, switching to this in the future will
  impact output)
• list[rand.read(1) % len(list)] → random.choice(list)

Unfortunately since we loose the with blocks, the unified diff is pretty unreadable.

Using Python's own PRNG should make the code cleaner and allow for reproducible stimulus files if that is desired via setting --seed (at least for the same versions of the script, changing the kind and/or order of the random calls will of course impact the output in the future). I did the following substitutions: * `rand.read(1)[0] % n` and `struct.unpack('@H', rand.read(2))[0] % n` → `random.randrange(n)` * `rand.read(1)[0]` → `random.randrange(256)` * `rand.read(n)` → `[random.randrange(256) for _ in range(n)]` (better alternative would have been `random.randbytes(n)`, but is only available for Python >= 3.9, switching to this in the future will impact output) * `list[rand.read(1) % len(list)]` → `random.choice(list)` Unfortunately since we loose the `with` blocks, the unified diff is pretty unreadable.

dnkl commented 2020年12月20日 15:26:31 +01:00

The only downside I see is that this is noticably slower. But, I think that's ok. If it turns out to be too slow, we could always adjust the number of iterations.

The only downside I see is that this is noticably slower. But, I think that's ok. If it turns out to be too slow, we could always adjust the number of iterations.

sterni commented 2020年12月20日 15:29:16 +01:00

I've found an issue when running this inside the nix sandbox, maybe you can help me figuring out a workaround and the impact:

• random.randrange(0) raises an error
• height and width are apparently zero inside the nix build sandbox

Does that mean testing sixels is off the table for that?

I've found an issue when running this inside the nix sandbox, maybe you can help me figuring out a workaround and the impact: * `random.randrange(0)` raises an error * `height` and `width` are apparently zero inside the nix build sandbox Does that mean testing sixels is off the table for that?

dnkl commented 2020年12月20日 15:34:13 +01:00

Does that mean testing sixels is off the table for that?

No, because we don't have to pass actual values. The PGO helper binary uses a cell-width of 8px and a cell height of 15px. It also hardcodes the cols/rows to 135x67.

I think it would make sense to override width/height if --cols and --rows has been used (which you should do in a headless PGO build). I'll push a fix for that.

> Does that mean testing sixels is off the table for that? No, because we don't have to pass *actual* values. The PGO helper binary uses a cell-width of 8px and a cell height of 15px. It also hardcodes the cols/rows to 135x67. I think it would make sense to override width/height if `--cols` and `--rows` has been used (which you should do in a headless PGO build). I'll push a fix for that.

dnkl commented 2020年12月20日 15:37:42 +01:00

@sterni e9dea5bb9d

@sterni https://codeberg.org/dnkl/foot/commit/e9dea5bb9d25bf18ffc5884e13573f8f2caf7436