recodex-wiki/Runtime-Environments.md

Runtime Environments

This page contains notes about using various runtime environments in ReCodEx as well as their internal usage inside isolate sandbox. At present ReCodEx supports

• C
• C++
• C#
• Data-only
• Go
• Haskell
• Java (OpenJDK)
• JavaScript (Node.js)
• Pascal
• PHP (CLI apps)
• Prolog (SWI)
• Python 3
• Rust
• Scala
• Groovy
• Kotlin
• Shell

Exercises may be configured for multiple environments, so the student may choose the language for the solution. However, Data-only, Haskell, and Prolog have somewhat unique configurations, therefore an exercise must use such environment exclusively.

Some languages does not have uniquely identified entry point (like main() routine in C/C++, for instance). For these languages, we have defined entry point -- file which is used as application bootstrap or main compilation unit. Namely, entry point is present in Haskell, JavaScript, PHP, Python, and Rust. The entry point may be specified in the exercise configuration (pointing to a file provided by the author), or left unspecified. In such case, the student may choose the entry point in case more than one file is submitted.

C#

The C# solutions are executed with the help of wrapper code. This code searches for main method in submitted source codes. There has to be only one class containing main method, otherwise error will be thrown. The name of the file containing wrapper code is ReCodEx_Csharp_Wrapper.cs and it contains namespace CodEx with class Wrapper, so be aware of filename and class collisions.

In C# language there are none of the handy functions to operate with textual inputs like scanf in C. Therefore for every C# build in ReCodEx there is Reader library included to make life of C# programmers easier. Please note that library is suppose to work only with ASCII files and some difficulties can be observed with modern Unicode (UTF-8) encodings. The Reader library is located in ReCodEx_Csharp_Reader.cs library contains namespace CodEx with class Reader, be aware of filename and class collisions.

Data-only

Data-only environment expects the students to submit only data files (i.e., anything). The exercise provides judge which in fact takes the place of tested solution and performs the verification of the data. The judge must be always present and it has very similar interface of the custom judges in other environments. The only difference is that the judge does not receive a name of the tested file on the command line (since many files may have been submitted). Therefore, it gets only custom arguments (from the exercise configuration) on the command line and it must find the files on its own (both submitted and extra files are loaded to current working directory when the judge is executed).

Go

The solutions of Go has to be located only in one package, the standard main executable package. ReCodEx uses flat folder structure of submitted solution, therefore separate Go packages cannot be used. Multiple files are fine as long as they contain the same package.

Java

By default, we use a script that looks for a class with a main method and executes it for running Java programs. There has to be only one class containing main method, otherwise error will be observed. The executed script is named javarun.java and can be found in the utils repository. In tested solutions we use its byte-compiled counterpart javarun.class, so be aware of name collisions.

Pascal

Pascal is a bit obsolete, nevertheless, we still support it. Pascal compilation holds one pitfall as the student may submit multiple *.pas files. Only one of these files may be a project, other must be units. Current Free Pascal Compiler expects to get only the project file on the command line and it finds and compiles units automatically. Unfortunately, we do not know, which file is which since all files are submitted together, so we pass all files to the compiler. This works correctly, except for one thing -- some unit files may be compiled multiple times which means that if there is a compilation error or warning, it may appear in the compilation log multiple times.

Python

We use a wrapper script that translates exceptions to error codes. This script can be found in the utils repository. The file is named runner.py during execution of solutions, so be aware of filename collisions.

Due to a Python bug, the interpreter requires the $HOME variable to be set to something. Otherwise, it tries to look up the UID used by Isolate in /etc/passwd and fails. Setting HOME=/box seems to work.

Python is currently installed with pip packages for TensorFlow support, so it can be used as an environment for deep learning assignments. This may change in the future.

Scala

Scala source codes are compiled to class files with scalac compiler and then executed with scala runtime, which takes care of executing JVM with scala dependencies. Like Java, even Scala uses our javarun wrapper executor which finds main method and executes it.

Groovy

Groovy source codes are compiled to class files with groovyc compiler and then executed with java runtime, with addition of groovy-all.jar standard dependency. Like Java, Groovy uses our javarun wrapper executor which finds main method and executes it.

Internally Groovy is executed with java JDK runtime and standard Groovy library is added to the execution. The standard library is called groovy-all.jar and has to reside in /opt/groovy/lib/groovy-all.jar unless the solution will not be executable. If Groovy standard library is not provided the execution will probably fail on loading of some of the Groovy specific classes.

Kotlin

Kotlin source codes are compiled to class files with kotlinc compiler and then executed with java runtime, with addition of Kotlin libraries as dependencies. Like Java, Kotlin uses our javarun wrapper executor which finds main method and executes it.

Internally Kotlin is executed with java JDK runtime and standard Kotlin libraries are added to the execution. Added libraries are kotlin-stdlib.jar and kotlin-reflect.jar. These libraries has to reside in /opt/kotlin/lib/ unless the solution will not be executable. If Kotlin dependencies are not provided the execution will probably fail on loading of some of the Kotlin specific classes.