Each team will be assigned a work area that includes a computer workstation, a small table desktop, and three chairs.
Each team will have a machine of its own to use during the contest. During the contest, contestants are to use the network only to submit contest problems or questions and get responses from the contest officials. Connecting to any other computer on the LAN or Internet, either before or during the contest, with telnet, FTP, Web browser, email, or any other network application is grounds for expulsion from the contest.
This year the Southern California Regional Contest will be using Fedora 30 as the host OS for the environment. We will be supplying Eclipse as the primary IDE, but will include Geany, vim, emacs and other standard command line editors.
In past contests there have been numerous requests to be able to save and take home your source code. Well this year you can! The contest will be providing one USB per team that you will be able to copy your code to and take with you at the end of the contest. This will not include the practice session. Please do NOT remove the USB drive until the end of the contest.
Lastly, the contest will use the web based judging environment called DOMJudge. Please download and read the Team Manual for information on how to use the DOMJudge interface.
If you have any questions about the Contest Environment, send them to <firstname.lastname@example.org> .
For more information regarding UNIX or the editors that will be available, see our Guide to UNIX and Editors.
The judges accept problem submissions only in the following programming languages.
|Python||Python standard release, no external libraries|
The execution time limits set for each problem will NOT be scaled based on the language. It is the contestants' responsibility to select the appropriate tool (language and algorithm) to produce correct output within the allotted time limits.
Programs will be compiled and linked using the Standard C++ Library included by default with g++.
Regional judges will accept solutions coded in Python 3.
For additional information on the editors, please see the Guide to UNIX and Editors.
|emacs||character based (emacs -nw) and mouse based (emacs)|
|vim||Vi IMproved, character based (vi, vim)|
Note: jed and pico are not supported.
After you have submitted a source file for judging, your submission will be run with one or several sets of input data and the results reviewed. It is the judges' intent never to reveal directly or indirectly the specific input data the judges use to test contestant programs. The judges will respond to your submission with one of the following messages. If a submission contains more than one type of error, the response will still contain only one message. The judges will report only the first error seen, which may not necessarily be the error that occurs first or most frequently in the output.
You have solved the problem.
The judges were unable to compile or link your program. Check whether
No expression or line number information will be returned to contestants.
Your program crashed during execution or an assertion failed. In the former case, the judges' response will also include a description of the signal received by the program, e.g., "Segmentation Fault." If an assertion failed, the message will state, "Assertion Failed." In neither case will expression, file, or line number information be returned to contestants.
Your program ran for more than the allotted CPU seconds.
Your program did not produce the expected results.
Although we do use robo-judge where possible, we verify every response before returning it to the team to ensure accurate, quality responses. The effect of this is that, depending on solution traffic and other factors, it may take longer to respond.