Skip to content

YamlImporter

Jump to bottom Edit New page
Stefano Maggiolo edited this page Dec 20, 2012 · 8 revisions

YamlImporter and YamlReimporter are two tools provided by CMS to ease the import of contests and tasks in the database. In this page we will describe the format supported by these tools.

Contest

A contest is stored inside a directory, whose name will be the short name of the contest.

The directory will contain a contest.yaml file and, for each task, a directory and another YAML file.

contest.yaml has to be encoded in UTF-8, and it must contain an associative array with the following values:

  • nome_breve The short name of the contest, e.g. "ioi2011day1". It must be same as the name of the directory of the contest.

  • nome The full name of the contest, e.g. "23rd International Olympiad in Informatics, day 1".

  • token_initial (optional, defaults to 10000) The initial number of tokens available, or None to completely disable the tokens.

  • token_max (optional, defaults to None) The maximum number in any given time, or None not to enforce this limitation.

  • token_total (optional, defaults to None) The maximum number that can be used in the whole contest, or None not to enforce this limitation.

  • token_min_interval (optional, defaults to None) The minimum interval in seconds between two uses of a token, or None not to enforce this limitation.

  • token_gen_time (optional, defaults to None) and token_gen_number (optional, defaults to None) Every token_gen_time minutes from the beginning of the contest we generate token_gen_number tokens for each user, or we do not if either is None.

  • inizio and fine (optional, default to 0) The UNIX timestamps of the begin and the end of the contest.

  • utenti The list of users of the contest.

    • username and password The credentials to log in the ContestWebServer.
    • ip (optional, defaults to 0.0.0.0) The IP address from which the user is expected to log in. A value of 0.0.0.0 means there's no specific IP address assigned to the user. If "ip_lock" is set to true in the configuration file, a log in attempt from a different IP address will be ignored.
    • nome and cognome (optional, default to empty string and username respectively) The first and last name of the user.
    • fake (optional, defaults to False) Whether the user is hidden or not. Hidden users will not appear in the rankings and, if "block_hidden_users" is set to true in the configuration file, they won't be able to log in.

  • problemi The list of short names of the tasks, in the order they will appear in the contest.

Tasks

A task whose short name is short_name needs a file short_name.yaml and a directory short_name.

short_name.yaml should contain the following values:

  • nome_breve The short name of the task, e.g. "garden" or "crocodile". It must be same as the name of the YAML file and the directory of the task.
  • nome The full name of the task, e.g. "Tropical Garden" or "Crocodile's Underground City".
  • timeout and memlimit The time and memory limits for the execution on a single testcase.
  • n_input The number of testcases.
  • score_type (optional, defaults to Sum) The name of one of the ScoreType modules. You can find them in /cms/grading/scoretypes.
  • score_parameters (optional, defaults to 100.0 / n_input) A JSON-encoded string, describing the parameters used to initialize the ScoreType.
  • risultati (optional, defaults to empty list) A list containing the indexes of the testcases whose outcome is public (i.e. the user does not need to play a token to see it).
  • token_initial, token_max, token_total, token_min_interval, token_gen_time and token_gen_number (optional, default to 2, 10, None, None, 30 and 2 respectively) Their meaning is described in the Contest section. These rules do not override the ones specified by the contest but they "cumulate": a token is given, can be played, etc... only if both the per-task and per-contest rules allow it.

The task statement should be a PDF document, placed in testo/testo.pdf inside the task's directory.

The input and output files should be placed inside the input and output directories (inside the task's directory), and they should contain files called input%d*.txt* and output%d*.txt* with %d substituted by every number from zero, included, to n_input, excluded.

Task types

There are different task types. At the moment the ones supported by YamlImporter are Batch (with whitediff), Batch (with comparator) and Communication. YamlImporter will choose among these options based on the files it finds inside the task's directory.

  • Batch (with whitediff) does not need any particular file, so it will be used as a "fallback" option in case YamlImporter does not recognize any other task type. In this task type, the solution submitted by the user will be tested on each input in the input directory. The solution will have to read its input from input.txt and output its result in output.txt. The result will then be compared with the "official" output (the one in the output directory) using a white diff. If they match then the solution earns full score on that testcase, otherwise no score at all.

  • Batch (with comparator) needs an executable file to be placed in cor/correttore. This type is very similar to the one above, except that a custom comparator is used to evaluate the user's output, instead of a white diff. The comparator will receive three command line arguments: the filenames where the input, the official output and the output of the user's submitted program are located. It will output on stdout the outcome of the evaluation (a float ranging from 0.0 to 1.0) and on stderr a message (for example "Accepted", "Wrong answer", "Invalid output", "Expected X, found Y", ecc...).

  • Communication needs an executable file to be placed in cor/manager and source files for each supported language to be placed in sol/stub.%s, with %s substituted by the extension for the language ("pas", "c", "cpp", ...). This task type sees two independent and parallel running programs communicating with each other. The first one, the manager, is provided by CMS while the other is obtained by compiling the program submitted by the user together with the stub for the corresponding language. Both program receive two command line arguments: the filenames of an input and an output pipe. These pipes are used for the programs to communicate. In addition, the grader has access to the input.txt and output.txt files (again taken from the input and output directories). The grader is supposed to read the data in the input file and the output file (if needed), to send part of it to the other program using the pipes (if needed), to answer some queries that the other program may "ask" him using the pipes (if needed) and, when it decides that the other program has completed or failed the task assigned to it, it should write the outcome on stdout (again, a float ranging from 0.0 to 1.0) and a message on stderr. The output file provided to the manager is actually an "input file", since the manager has no point in writing something on it (it would have no effect on the evaluation).

Add a custom footer
Add a custom sidebar
Clone this wiki locally