The allocation of machines to teams is random.
The team machines will be equipped either with an AZERTY keyboard or with a QWERTY keyboard, depending on the information provided by the team at registration (see the registration page for details about how to specify this). Teams are not permitted to bring their own keyboards, but may put stickers on the keyboard if they wish; see regulations.
Of course, no matter the physical layout of the keyboards, it is always possible to reconfigure them in software to a different layout (that does not match what is printed on the keyboard).
The software configuration of the team environment is described here. Note that we also provide an image of the environment (see below).
- GNOME 3
- vim/gvim 8.0.1453
- emacs 25.2.2
- gedit 3.28.1
- Kate 17.12.3
- geany 1.32
- atom 1.42.0 x64
- gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
- g++ (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
- openjdk version "11.0.4" 2019-07-16
- OpenJDK Runtime Environment (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3)
- OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3, mixed mode, sharing)
- Kotlin version 1.3.61 (JRE 11.0.4+11-post-Ubuntu-1ubuntu218.04.3)
- Python 3.6.1 (7.1.1+dfsg-1~ppa1~ubuntu18.04, Aug 09 2019, 16:05:55) [PyPy 7.1.1 with GCC 7.4.0] list of installed modules
- The CPython3 implementation will also be available in the contest environment but will not be used for judging
- No Python 2 support (see below)
- OCaml 4.05.0
- IntelliJ IDEA Community Edition 2019.2.3 Build #IC-192.6817.14
- PyCharm Community 2019.2.3 (Community Edition), Build #PC-192.6817.19
- Eclipse IDE for Java Developers (version 2019-09 R (4.13.0), build id 20190917-1200)
- Eclipse IDE for C/C++ Developers (version 2019-09 R (4.13.0), build id 20190917-1200)
- Eclipse IDE for Python Developers (version 2019-09 R (4.13.0), build id 20190917-1200)
- Visual Studio Code 1.41.1
- C/C++ extension by Microsoft, version 0.26.2
- Language Support for Java extension by Red Hat, version 0.55.1
- Python extension by Microsoft, version 2019.11.50794
- Apache NetBeans IDE 11.2
- Code::Blocks 16.01
- Debuggers: gdb, valgrind, ddd
- Browsers: Firefox, Chromium
The computers will not have any network access except to the judging system and to the reference documentation provided.
Unlike last year, and like the world finals, we no longer support the Python 2 programming language. We also no longer provide the Spyder IDE. Unlike the world finals, we will not provide the proprietary CLion IDE.
We provide an Open Virtualization Archive image of the contest environment, to be used with virtualization software such as Virtualbox. The contestant account has login "swerc" and password "swerc", and is opened automatically on startup. The administrative account has login "swercadmin" and password "swercadmin" and has sudoer rights. Unlike the actual image, no network restrictions are enforced in this image.
The judging system will compile submissions with the following options. Each exists as an alias on the team machines:
The following language features are not permitted in any of the contest languages:
- inline assembly code
- file I/O
- file management
- device management
- interprocess communication
- forking and execution of external commands
More generally, any system call other than memory management, reading from the standard input, writing to the standard output, and exception management, is forbidden.
Submissions using any of these features will be rejected, either automatically by the judging system, or manually by the judges.
Submissions will be judged on three machines, each having an Intel Xeon E5-2660 CPU (2.6 Ghz, 20 cores) and having between 256 GB and 512 GB of RAM.
The software configuration for judge machines is a Debian Linux Jessie 64bit virtual machine with exactly the same software version as the team software above.
The contest control system that will be used is DOMjudge, version 7.1.1.
Submissions will be evaluated automatically unless something unexpected happens (system crash, error in a test case, etc.).
Verdicts are given in the following order:
- Too-late: This verdict is given if the submission was made after the end of the contest. This verdict does not lead to a time penalty.
- Compiler-error: This verdict is given if the contest control system failed to compile the submission. Warnings are not treated as errors. This verdict does not lead to a time penalty. Details of compilation errors will not be shown by the judging system. If your code compiles correctly in the client environment but leads to a Compiler-error verdict on the judge, contestants should submit a clarification request to the judges.
- The submission is then evaluated on several secret test cases in some fixed order. Each test case is independent, i.e., the time limits, memory limits, etc., apply to each individual test case. If the submission fails to process correctly a test case, then evaluation stops and an error verdict is returned (see next list), and a penalty of 20 minutes is added for the problem (which are only counted against the team if the problem is eventually solved). If a submission is rejected, no information will be provided about the number of the test case(s) where the submission failed.
- Correct: If the evaluation process completes and the submission has returned the correct answer on each secret test case following all requirements, then the submission is accepted. Note that this verdict may still be overridden manually by judges.
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:
- Error verdicts where execution did not complete: the verdict returned will
be the one of the first error amongst:
- Output-limit: The submission produced too much output. (The precise output limit is not specified.)
- Run-error: The submission failed to execute properly on a test case (segmentation fault, divide by zero, exceeding the memory limit, etc.). Details of the error are not shown.
- Timelimit: The submission exceeded the time limit on one test case, which may indicate that your code went into an infinite loop or that the approach is not efficient enough. (The precise time limit is not specified, but the order of magnitude is of a few seconds.)
- Error verdicts where execution completed but did not produce the correct answer: the verdict returned will be the first matching verdict amongst:
- No-output: There is at least one test case where the submission executed correcly but did not produce any result; and on other test cases, it executed properly and produced the correct output.
- Wrong-answer: The submission executed properly on a test case but it did not produce the correct answer. Details are not specified.
Note that there is no "presentation-error" verdict: errors in output format are treated as wrong answers.
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.
Making a submission
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. (Make sure that the file that you
wish to submit has the correct name, e.g.,
submit uses this to
determine automatically for which problem you are submitting.)
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 the volunteer in their room for help.
Of course, 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 web interface or by command line using the
printout program. (Make sure that the file that you wish to submit
has the correct extension, because
printout uses this to determine
automatically which syntax highlighting to apply.)
Location and rooms
The contest facilities are at Télécom Paris, 19 place Marguerite Perey, 91120 Palaiseau. The main hall and canteen are at ground level. The main auditorium and coach facilities are at ground level or at first floor. The computer labs are at floors 1, 3, 4, 5. The banquet room at the banquet venue will be underground.
Requests for additional software
It will not be possible to request installation of additional software during
SWERC, except in case of unforeseen problems or when the software is very simple
to install (e.g., a simple
apt-get install command).
For this reason, if you would like specific software to be available on the contest computers, you should write firstname.lastname@example.org before December 10th and indicate us what you would like us to install. We do not guarantee that we will be able to respond to requests after this date.
If possible, please indicate your request as a package name for Debian: see the Debian package index.
To ensure that all candidates can prepare in the same way for the contest, we do not accept requests to install software which is not available for free under a DSFG-compliant open-source licence. This ensures that we can legally redistribute the contest environment (see above), to be used by all. We may refuse to install some additional software if we think it is not useful for the contest or potentially harmful, inconvenient to install for Debian Jessie, buggy, insecure, or exceedingly exotic.