Problem information

I adopted problem parsers from CHelper by Egor Kulikov. Chrome extension is also supported and it's very advisable to use it, because it works for more platforms than parsing by URL. Problems from some platforms aren't parsed even though the parser is present. I'm not sure whether it's my fault or bugs in the parsers. All the platforms I do care about seem to work, feel free to propose fixes for the ones that don't.

Problem description consists of the following fields. Some of them are modified only during problem creation or parsing, others can be configured at any time, because they aren't parsed or may be parsed incorrectly. In the brackets, you may find the field ID used in CMake configuration files, it's basically substituted with the value for the given problem.

• Problem ID (@problem_id@) - short problem ID, just one capital letter where possible.
• Full problem name (@problem_name@).
• Platform ID (@platform_id@) - short platform ID used by CHelper.
• Full platform name (@platform_name@) - can be configured in ACHelper.xml. If you delete an entry there, the platform won't be supported.
• Contest name (@contest_name@).
• Time limit (@time_limit@) - not parsed currently, so the default value from ACHelper.xml is used unless changed in the interface.
• Memory limit (@memory_limit@) - has no effect at the moment.
• Input file name (@input_file_name@) - empty for standard input.
• Output file name (@output_file_name@) - empty for standard output.
• Test type (@test_type@) - used to select the appropriate solution template, one of the following:
  • single test (@single@)
  • multi-test with the number of tests given at the start of the input (@multi_number@)
  • multi-test where tests are listed until the end of file (@multi_eof@)
• Interactive flag (@interactive@). Interactive problem can be tested only from the console, it's not launched automatically on samples because interactor is required.
• Custom checker flag (@custom_checker@) - in the case when default checker is not appropriate, a separate target is created where you can implement your own Testlib checker. Compile it before launching the tester. I don't expect this feature to be used during the contests, but it can be useful for problem preparation.
• Checker compiler options (@checker_compiler_options@) - for default checker, it specifies epsilon used for floating number comparison, and whether to use absolute or relative error (or the minimum of them).

Also, all the fields that are configurable on the problem tab have corresponding fields with _changed suffix (for example, time_limit_changed) that allow project regeneration only when necessary.