Problems - Importing and exporting - Sphere Engine documentation

Thanks to the built-in features of the Problem Editor (accessible through the Sphere Engine client panel), you can import and export programming problems. The export process results in the creation of a ZIP archive containing all information about the problem. The reverse operation of importing allows you to upload the problem in the form of a zip archive.

This article specifies the contents of the programming problem archive.

Example use cases of importing/exporting problems:

creating programming problems in the form of archives with a file format compatible with the Sphere Engine Problems module. This opens up additional opportunities related to automating the process of creating programming problems by independent authors (i.e., it is possible to specify the format in which the author of the problem should provide it so that it can be later easily embedded in the Sphere Engine Problems module),
the use of archives with problems for backup (including the ability of processing archives in your system),
migrating programming problems between different systems. It is worth noting that the Spoj system (a community website maintained by the Sphere Engine team) has a problem import/export mechanism that is fully compatible with the format used in the Sphere Engine Problems module.

Files structure

Programming problem archive should meet the following conditions:

The archive containing the programming problem is saved in the ZIP format,
All text files should be saved using UTF-8 encoding,
The structure of the config.xml file (see table below) should be compatible with the XML 1.0 format.

Name	Type	Content
resources	folder	resources used in the description of the problem (e.g., illustrations, sample data, source codes with solution templates)
config.xml	XML file	problem's parameters and additional information about the contents of the archive files (see example and specification)
masterjudge	source code	the source code of the master judge program
{code}.html	Markdown or HTML file	description of the problem
{n}.in	file (usually a text file)	input data of the n-th test case
{n}.out	file (usually a text file)	reference output data of the n-th test case
{n}.judge	source code	the source code of the judge used in the n-th test case
{n}.workspace.zip	ZIP archive	archive with additional files, which the program will have access to when running the n-th test case
{n}.meta.in	file (usually a text file)	metadata describing the input data of the n-th test case
{n}.meta.out	file (usually a text file)	metadata describing the output data of the n-th test case

The {n} notation used means a numeric parameter. Examples of file names compatible with this convention: 0.in, 3.out, 1.judge, etc. The numbering starts from zero.

The {code} notation used means the code of the problem. For example, for a problem with the code TEST, the name of the file with the problem's description is TEST.html.

Example config.xml file

<?xml version="1.0" encoding="UTF-8"?>
<Problem>
  <info>
    <code>PRIME1</code>
    <name>PRIME1</name>
    <from>Sphere Engine Problems</from>
    <xml_version>1</xml_version>
  </info>
  <config>
    <sc_limit>0</sc_limit>
    <resource />
    <assessment_type>max</assessment_type>
    <scenario>0</scenario>
    <checker>6</checker>
    <testable>1</testable>
    <seq>#0 #1</seq>
    <auxdata></auxdata>
    <input_as_file>0</input_as_file>
  </config>
  <body>
    <file>PRIME1.html</file>
    <dynamic>0</dynamic>
    <form>0</form>
  </body>
  <languages>
    <string>0</string>
  </languages>
  <masterjudge>
    <name>Generic masterjudge</name>
    <file>masterjudge</file>
    <lang>1</lang>
  </masterjudge>
  <datasets>
    <tc_0>
      <in>0.in</in>
      <out>0.out</out>
      <limit_time>1</limit_time>
      <limit_memory>0</limit_memory>
      <limit_thread />
      <limit_proc />
      <limit_output />
      <active>1</active>
      <judge>
        <name>Ignores extra whitespaces</name>
        <file>0.judge</file>
        <lang>1</lang>
      </judge>
      <workspace>0.workspace.zip</workspace>
      <in_meta>0.meta.in</in_meta>
      <out_meta>0.meta.out</out_meta>
    </tc_0>
    <tc_1>
      <in>1.in</in>
      <out>1.out</out>
      <limit_time>1</limit_time>
      <limit_memory>0</limit_memory>
      <limit_thread />
      <limit_proc />
      <limit_output />
      <active>1</active>
      <judge>
        <name>Ignores FP rounding up to 10^-6</name>
        <file>1.judge</file>
        <lang>1</lang>
      </judge>
      <workspace>1.workspace.zip</workspace>
      <in_meta>1.meta.in</in_meta>
      <out_meta>1.meta.out</out_meta>
    </tc_1>
  </datasets>
  <resources>
  <resource>
    <filename>diagram.pdf</filename>
  </resource>
  <resource>
    <filename>example.jpg</filename>
  </resource>
  </resources>
</Problem>

Description of the config.xml file structure

Field name	Description
Problem.info.code	problem's code
Problem.info.name	problem's name
Problem.info.from	origin of the archive; possible values are: `Sphere Engine Problems` or `Spoj`
Problem.info.xml_version	the version of the XML format of the `config.xml` file; supported versions: `1.0`
Problem.config.sc_limit legacy	unused field
Problem.config.resource legacy	unused field
Problem.config.assessment_type	the judging method determines how the problem should be evaluated; possible values: `min`, `max`, `bin`
Problem.config.scenario	method of running the problem; possible values: `0 = classic`, `1 = interactive`
Problem.config.checker	the field should have the value of `6`
Problem.config.testable	the field should have the value of `1`
Problem.config.seq legacy	list of test case identifiers in the following format: `#{n} #{m} #{k} (...)`, e.g., `#0 #3`
Problem.config.auxdata beta	auxiliary data passed to the master judge
Problem.config.input_as_file beta	should the input be interpreted as an archive (`ZIP` or `TAR.GZ`); possible values: `0 = no`, `1 = yes`
Problem.body.file	the name of the text file containing the description of the problem; recommended `{code}.html`
Problem.body.dynamic legacy	unused field
Problem.body.form legacy	unused field
Problem.languages.string legacy	list of available languages in a string format (e.g., `0`, `01`, `0110011`) where 1 means the language is on and `0` means the language is off; the position of the character in the string corresponds to the ID number of the given language (the items are numbered from zero)
Problem.languages.{ID} legacy	the presence of a parameter for a language with the given ID number means that the language is available for the problem; the parameter's value is the abbreviated name of a given programming language (see: languages)
Problem.masterjudge.name	name of the master judge
Problem.masterjudge.file	the name of the file that contains the master judge's source code; recommended `masterjudge`
Problem.masterjudge.lang	the ID number of the language used by the main judge (see: languages)
Problem.masterjudge.hash	the universal identifier of the master judge
Problem.resources[].resource.filename	the name of the file containing the given resource (e.g., illustration)
Parameters for test cases the parameter `{n}` in the field's name means the number of the test case (the numbering starts from zero), for example the field `Problem.datasets[].tc_4.judge.name` contains the name of the judge used in test case number 4
Problem.datasets[].tc_{n}.in	the name of the file that contains the input data; recommended `{n}.in`
Problem.datasets[].tc_{n}.out	the name of the file that contains the reference output data; recommended `{n}.out`
Problem.datasets[].tc_{n}.limit_time	execution time limit (seconds)
Problem.datasets[].tc_{n}.limit_memory	field reserved for future use (RAM limit)
Problem.datasets[].tc_{n}.limit_thread	field reserved for future use (threads limit)
Problem.datasets[].tc_{n}.limit_proc	field reserved for future use (processes limit)
Problem.datasets[].tc_{n}.limit_output	field reserved for future use (output data limit)
Problem.datasets[].tc_{n}.active	is the test case active; possible values: `1 = yes`, `0 = no`
Problem.datasets[].tc_{n}.judge.name	name of the judge
Problem.datasets[].tc_{n}.judge.file	the name of the file that contains the judge's source code; recommended `{n}.judge`
Problem.datasets[].tc_{n}.judge.lang	The ID number of the language used by the judge (see: languages)
Problem.datasets[].tc_{n}.judge.hash	universal identifier of the judge
Problem.datasets[].tc_{n}.workspace experimental	the name of the ZIP archive with additional files; recommended `{n}.workspace.zip`
Problem.datasets[].tc_{n}.in_meta experimental	the name of the file containing the metadata for the input file; recommended `{n}.meta.in`
Problem.datasets[].tc_{n}.out_meta experimental	the name of the file containing the metadata for the output file; recommended `{n}.meta.out`

Note:

files of resources used in the description of the problem must be located in the resources folder; the rest of the files should be in the main folder of the archive,
file names should not contain paths (i.e., input only the file name).