New generate

[mzuenni]

304

[mzuenni]

@mpsijm i tried to start the rewriting but for me the parsing of the yaml and the actual generation is to entangled and confusing, do you want to rewrite it from scratch or do you have a better understanding?

To make stuff easier the config should only be used if generator.yaml exists and not try to understand what we currently call unlisted testcases i.e. mostly ignore the data dir... Therefore, i changed bt stat to count the actual files in the data dir not the content of the generator.yaml

[RagnarGrootKoerkamp]

The 'problem' with bt stat not including generators.yaml content is that this requires (re)generating all testcases for an entire contest even if you just want to have a quick overview of how much is done everywhere. I use this quite a lot in fact since I usually care about progress for most problems but don't work on all of them (or at least don't have the latest version of testdata everywhere).

[RagnarGrootKoerkamp]

What exactly would you like to clean up / rewrite in generate.py? If things are working now I don't think it's super useful to spend time simplifying it. (I do agree it's complicated, and if you think that prevents making progress on it that's a valid reason.)

[mzuenni]

My main problem with the current code is that stuff is not cleanly separated (or I just understand it wrong). What I would want is a ParsedConfig object which stores data and only parses it for errors and a generate function that manages the content of data based on the ParsedConfig object

The ParsedConfig should have functions and fields like this:

1. a parse constructor
2. a default submission
3. a visualizer
4. a list of generators
5. a list of testcase rules
6. a list of includes for testcases
7. a write function
8. ...?

The generate function should then:

1. build all programmes (parallel)
2. generate all directories (sequential)
3. generate everything in the tmp/data/ dir (parallel)
4. match files in the cache with files in data (sequential)
5. move unmatched files to tmp/trash (sequential)
6. move missing files to data (sequential)
7. add symlinks for includes (sequential)

So my main goal is that generator.yaml parsing should be completely independent of the data folder. And this should also hopefully make it easier to add the count attribute or any other?

Additionally, I would hope that something like this is then possible:

1. read the config into the internal format
2. add a new testcase rule to the corresponding field
3. call the write function to add it to the yaml

Does this sound plausible? @RagnarGrootKoerkamp @mpsijm

[mzuenni]

ok, I hope we can reuse a lot of code that is already there... we only need to untangle parsing the yaml from generating the files... (right now generate --add does not work correctly... for some reason known_testcases is empty?)

[RagnarGrootKoerkamp]

woop woop, first 200 lines gone! I suppose this was an easy bit :sweat_smile:

[mzuenni]

yes... and maybe even some new bugs :)

[mzuenni]

I hope this is working now (we may still want to rewrite stuff at some point...) can someone check? @RagnarGrootKoerkamp @mpsijm

[RagnarGrootKoerkamp]

If CI works and you tried some commands locally that's good enough. I'm not in the mood to check in detail and we can fix whatever comes up later

[mzuenni]

One open question is: What exactly should happen if we call bt generate with a set of testcases...

[RagnarGrootKoerkamp]

Ideally: Files corresponding to these cases are touched and nothing else.

(Throwing away all unknown cases could also be OK, but preferably not I'd say.)