Ragnar Groot Koerkamp

Alternative: Allow `{seed:1,2,3,10-20}`. It's shorter and can be done inline, and gives more control over the seed values being used. But also, the fact that `count: N` takes a separate...

Hmm; the problem with 'inline' numbering is that that wouldn't work if testcases aren't already numbered in the first place. For named cases you'd have to do `random-1`, `random-2`, or...

Ohh, interesting idea. **Some context** Currently we allow `{seed}` and `{seed:}`, and the entire thing is replace by an integer hash of *the entire* generate command. (This way, `gen.py {seed}...

Hmm, one issue with the zipping is that for longer lists the correspondence between elements becomes unclear, especially if the numbers don't have the same length. We could do something...

- Yes, `count:` should require `{seed}`. - I'm really not a fan of the dictionary syntax `vars: [{n:1}, {n:2}, {n:3}, ..]` is so verbose compared to `vars: n: [1,2,3, ...]`,...

Oops random misclick. Especially since arguments are usually positional it's nice to have them self-documenting and use {n} I think. But not naming them does make things simpler. We could...

1. I think dropping the `--samples` part of `-f --samples` is OK and we can simply warn when this happens. If you care about specific sample output you can hardcode/copy...

Fixed in #348. Just `bt generate` will now overwrite everything and move old/unwanted files to `/tmp` so they can be recovered if needed.

I'm wondering if we can/should combine the two tables into one: existing: `Running ` new: ` ` could be merged to ` ` Only when there are >>100 cases that...

Screenshot for context