-
Notifications
You must be signed in to change notification settings - Fork 70
[EN] 2. Configuration file
Author can set custom rules regarding their problem by adding some information in package configuration file. There are several properties supported by currently used package format -- sinolpack. In order to apply, rules have to be included in the file config.yml located in the package's main directory.
All custom rules are listed below:
| Rule | Short description |
|---|---|
| title | Full name of the problem |
| title_lang | Full name of the problem in specific language |
| time_limit/s | Time limits for the problem's tests |
| memory_limit/s | Memory limits for the problem's tests |
| override_limits | Test limits override per language |
| points | How the points are dealt among test groups |
| extra_compilation_files | Additional compilation files |
For more information about the specific rule, please refer to the sections below.
A problem's name can be defined using the title key. Its value becomes the full name of the problem.
If it's absent from the config, attempt will be made to obtain the title from the task statement. If it fails, the problem will be called by its short name.
In our case the title field will look like this:
title: TreeA problem's name translation can be defined using the title_<language_id> key. Its value becomes the full name when user picks language version of the site. Currently supported language ids are stored in settings.py file. Beware! Language identificator is its short version (pl, en), not a full one. It can differ between SIO instances, but typically at least Polish and English site's version will be supported.
The problem's name is not translated when different language version of the site is requested.
In our case Polish version of the title would be specified like this:
title_pl: DrzewoEach submission is tested against multiple test cases. Test case checks not only the validity of the output, but also solution's time and memory efficiency. If the submission doesn't print the answer within the time limit, it receives TIME LIMIT EXCEEDED status. If program allocates more memory than allowed by the memory limit, it receives MEMORY LIMIT EXCEEDED status.
Time limits can be set using the time_limit key. Time limit should be given in milliseconds.
Default time limit is set to 10 seconds.
If we want to set the time limit to 1s, we will write:
time_limit: 1000Memory limits can be set using memory_limit key. Memory limit should be given in kilobytes.
Default memory limit is set to 66000kB.
If we want to set the memory limit to 256MB, we will write:
memory_limit: 262144If we want to be more specific (e.g. set a separate time limit for a certain test group or even a certain test), we can include additional keys: time_limits and memory_limits. For example, if we'd like the time limit for the second group to be greater than for the rest of our tests, except for the test 2a, we will write:
time_limit: 1000
time_limits:
2: 5000
2a: 1000Sometimes we wish that limits are different per a submission language -- e.g. solutions coded in Python are slower and consume more memory, so we can loosen requirements for them. In such situation, we can override time and memory limits using key override_limits. In this section, given language key (like py or cpp) we specify desired behaviour. Global and group limits can be overriden.
For example, adding at the end of config:
override_tests:
py:
time_limit: 2000
memory_limits:
1: 20000
3: 10000would change time limit for Python submissions to 2 seconds, and for memory limits, test groups 1 and 3 would have recpectively 20000 and 10000 kiB memory limits. Other, not overriden groups, would remain with default limits.
In order to define a maximum score for each test group use the scores key. Then, to each group's number assign an integer defining a maximum possible score that can be obtained for passing this group. The scores do not need to add up to 100. You shouldn't define a score for the group 0. Once you decide to use the scores key, you have to define values for every test group in the package.
If the configuration file does not contain the scores key, scores will be assigned to each group automatically. Each test group will be assigned a roughly similar number of points. The last test groups (i.e. those with highest numbers) may receive a slightly larger maximum score if the default maximum score of 100 cannot be divided evenly between the groups.
If we want to give 30 points for a submission passing first group and 70 points for second group, we will write:
scores:
1: 30
2: 70In order to link extra files (look at Package with library tutorial) use the key extra_compilation_files.
No extra files will be linked.
A working configuration file for our problem can be found at tre/config.yml.