Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract runner functionalities out from spec header files #152

Open
fushar opened this issue Jul 16, 2017 · 0 comments
Open

Extract runner functionalities out from spec header files #152

fushar opened this issue Jul 16, 2017 · 0 comments

Comments

@fushar
Copy link
Member

fushar commented Jul 16, 2017

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:

  1. 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.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant