New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for .toml tests #3500
Conversation
This separates the file format and how to read it from how to apply a key/value to a TestSpec. This will allow us to reuse the same code when implementing a TOML parser later.
This includes build/txt-to-toml.py which did the rewrites, and can be used to rewrite other no-in-tree test spec files to toml. I didn't touch status or restarting tests yet. Restarting will be handled later. It turns out that I don't understand how status tests work.
@fdb-build ok to build |
@fdb-build ok to test. |
I ran
Which walks through the .txt and .toml versions of each test, and compares their unseed to assert that the TOML versions of the tests do the exact same thing that the .txt versions of the test did. There's a few mismatches:
Staring at the results, there's not that much that's actually different. In the TOML version, the workload RPC shows up a few milliseconds of sim time later. All of these tests use 0.1 or 0.8 in their testspec, which because I convert the TOML values back to a string, get sent across the wire as 0.1000000000001 or 0.80000000000004. Evan once commented that packet delays in Simulation are a function of packet size, so this change in string representation could explain the unseed change. The fact that most tests don't seem to exhibit this behavior also seems to support this theory. I can't seem to find the code in simulation that does a delay as a function of packet size though? |
@fdb-build test this please |
This is part 3 of #3459, which turned out to be better to do before part 2 of what I had outlined there.
This introduces a new dependency, toml11, into CMake, and then uses it to implement a TestSpec-equivalent TOML reader. I have no idea if I did this right, but the code compiles. 馃し. TOML has typed values, and TestSpec treats all values as strings. To make this change easier to do in pieces, all TOML values are currently turned back into strings, and then placed into the
TestSpec
struct. A later PR will look into carrying this typedness into the workload framework, so that type mismatches can be reported with toml11's superior error messages[1].The largest changes to note between what is in testspec files and what TOML accepts is that (1) strings must be quoted (and I'd suggest always using single quotes, because they don't do backslash escaping within them) (2) doubles need to be of the form
0.8
and not.8
. Aside from that, it's a mostly straightforward implementation. I've included the python script that I wrote to do the transformation of .txt into .toml, and it also pretty prints/applies a nice formatting to the result.I verified that TestHarness doesn't need any changes, so Joshua should still work. TestRunner also doesn't require changes, and
ctest
works as expected. Any other code that currently generates testspec files (e.g. Circus) should still work, as long as it outputs a file which ends in.txt
.Then when running the test, the output will look like:
Making getOption take a template parameter of the type in workloads will extend this error reporting to type mismatches between toml file and what the workload expects.
I was hoping to add a similar looking warning if global-level or test-level params are used at the wrong level, but that will be blocked on toml11#124.