The judging system will compile submissions with all the following options. In some cases, it may need to add additional flags to specify the path of the produced binary (e.g. -o ... for C/C++).
Each exists as an alias on the team machines:
| Language | Implementation | Command | Alias |
|---|---|---|---|
| C | gcc 12.2.0 | gcc -x c -g -O2 -std=gnu11 -static -pipe "$@" -lm | mygcc |
| C++ | g++ 12.2.0 | g++ -x c++ -g -O2 -std=gnu++20 -static -pipe "$@" | myg++ |
| Java | OpenJDK 17 | javac -encoding UTF-8 -sourcepath . -d . "$@" | myjavac |
taskset -c 0 java -Dfile.encoding=UTF-8 -XX:+UseSerialGC -Xss128m -Xms1856m -Xmx1856m "$@" | myjava | ||
| Note: 1856m is the task's memory limit (2GB) minus 192MB. | |||
| Kotlin | Kotlin 1.9.25 | kotlinc -d . "$@" | mykotlinc |
taskset -c 0 kotlin -Dfile.encoding=UTF-8 -J-XX:+UseSerialGC -J-Xss128m -J-Xms1856m -J-Xmx1856m "$@" | mykotlin | ||
| Note: 1856m is the task's memory limit (2GB) minus 192MB. | |||
| Python | pypy3 7.3.11 | pypy3 "$@" | mypython3 |
Compilation and execution as described above will take place in a “sandbox” on dedicated judging machines. The sandbox will allocate 2GB of memory; the entire program, including its runtime environment, must execute within this memory limit. For interpreted languages (Java, Python, and Kotlin) the runtime environment includes the interpreter (that is, the JVM for Java/Kotlin and the Python interpreter for Python).
The sandbox memory allocation size will be the same for all languages and all contest problems. For Java and Kotlin, the above commands show the stack size and heap size settings which will be used when the program is run in the sandbox.
The software configuration for judge machines is also based on an Debian 12 64bit machine with exactly the same software version as the team software above.
Submissions will be evaluated automatically unless something unexpected happens (system crash, error in a test case, etc.).
Verdicts are given in the following order:
The following errors can be raised on a submission. The verdict returned is the one for the first test case where the submission has failed. The verdicts are as follows, in order of priority:
Note that there is no "presentation-error" verdict: errors in the output format are treated as wrong answers. DOMjudge does allow a reasonable amount of extra whitespaces but we don't advice to expect this in your solution.
The problem set will be provided on paper (one copy per contestant), and also in PDF files on the judge system (allowing you to copy and paste the sample inputs and outputs). We may also provide an archive of the sample inputs and outputs to be used directly.
To test interactive problems, you can do it manually (you play the role of the judge in the terminal), or automatically with mkfifo and pipe.
Once you have written code to solve a problem, you can submit it to the contest control system for evaluation. Each team will be automatically logged into the contest control system. You can submit using the web interface, by opening a web browser and using the provided links/bookmarks, or you can submit by command line using the submit program. (If you use the submit program, make sure that the file that you wish to submit has the correct name, e.g., a.cpp, because submit uses this to determine automatically for which problem you are submitting.)
In the SWERC 2024 practice session, you needed to submit your solutions with the prefix `practice_` in the filename. But in the main contest, this is fixed and works with the single letter filenames as described above.
To use the submit program you should create the file ~/.netrc with the following content:
machine swerc.vps.tecnico.ulisboa.pt login team?????? password ??????????
If a contestant has an issue with the problem set (e.g., it is ambiguous or incorrect), they can ask a question to the judges using the clarification request mechanism of DOMjudge. Usually, the judges will either decline to answer or issue a general clarification to all teams to clarify the meaning of the problem set or fix the error.
If a contestant has a technical issue with the team workstation (hardware malfunction, computer crash, etc.), they should ask a volunteer in their room for help.
Neither the judges nor the volunteers will answer any requests for technical support, e.g., debugging your code, understanding a compiler error, etc.
During the contest, teams will have the possibility to request printouts, e.g., of their code. These printouts will be delivered by volunteers. Printouts can be requested within reason, i.e., as long as the requested quantities do not negatively impact contest operations.
You can print using the local printing system. To print a document on the default printer from the command line you can use one of the following commands:
a2ps source_code_filenameenscript source_code_filenamelpr filenameWe recommend to take care when reading large instances.
scanf than cin OR use std::ios::sync_with_stdio(false);sys.stdin.readline than inputBufferedReader than Scanner(System.in)