You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current world, building a spec file will perform the following:
compiling the problem spec and test spec classes against <tcframe/spec.hpp>, PLUS
compiling all common features not actually related to specs such as local grading,
into a single executable.
This is not efficient, as the more non-spec features tcframe has, the longer the compilation time and the larger the executable object file will be.
We should split tcframe into two components: spec and runner, as follows:
Spec
This is the (minimal) set of header-only files required for a spec file, by including <tcframe/spec.hpp>.
Building a spec file will produce two objects:
Executable spec program, that must be able to perform the following operations:
Given a test group and test case number, generate the test case and print into a file, or report if the test case does not satisfy its subtask constraints.
Given a test case output file, determine if it parsable according to the output format.
A spec.yml file, that contains all the metadata, such as the evaluation style (batch/interactive), time limit etc.
That's it. Everything else should be handled by the next component: runner.
Runner
This is the actual executable program that is capable of performing the current tcframe functionalities, by internally making use of the spec executable and metadata file as described above. This can be a completely different program with different language (e.g. Python). Or may be just the current C++ code, refactored.
Cons: users may need to compile the runner program (but just once) before building a spec file, but this should be a fair tradeoff.
The text was updated successfully, but these errors were encountered:
In the current world, building a spec file will perform the following:
<tcframe/spec.hpp>
, PLUSinto a single executable.
This is not efficient, as the more non-spec features tcframe has, the longer the compilation time and the larger the executable object file will be.
We should split tcframe into two components: spec and runner, as follows:
Spec
This is the (minimal) set of header-only files required for a spec file, by including
<tcframe/spec.hpp>
.Building a spec file will produce two objects:
Executable spec program, that must be able to perform the following operations:
A
spec.yml
file, that contains all the metadata, such as the evaluation style (batch/interactive), time limit etc.That's it. Everything else should be handled by the next component: runner.
Runner
This is the actual executable program that is capable of performing the current tcframe functionalities, by internally making use of the spec executable and metadata file as described above. This can be a completely different program with different language (e.g. Python). Or may be just the current C++ code, refactored.
Cons: users may need to compile the runner program (but just once) before building a spec file, but this should be a fair tradeoff.
The text was updated successfully, but these errors were encountered: