**This page will hold the answers for Frequently Asked Questions.** ## Browser Issues First, make sure you are using a modern web browser, preferably Mozilla Firefox or Google Chrome. Although our objective is to support all modern browsers, rapid development prevents us from doing extensive testing across many platforms; hence, we are sticking with the aforementioned two browsers for now. Make sure you refresh your browser cache (`Ctrl+F5`) before logging in, especially if a new version has been deployed. The refresh will prevent older pieces of the application from lingering in your cache. This is just a precaution. Sometimes a component on a page does not refresh itself correctly. The application is a complex system of components and is still under development. If you make an action and do not see the results in a reasonable while, refresh the page. ## How to register into ReCodEx and what method should I use? ReCodEx provides multiple ways for a user to register and log in. Currently there are two options: a **local** ReCodEx account or an account bound to the **CAS** service. The preferred way of registration and authentication is using the CAS service and using a local account only in special circumstances. CAS authentication provides more features, such as automatic binding of users to **SIS** groups. ### I registered using a local account but I want to use also CAS and its advantages The system's login mechanism is prepared for this option. The only prerequisite is that your email address in the local account must be the same as the one in CAS. If this is the case, binding the accounts is quite easy, just log in using CAS and the system will automatically bind those two accounts. Also please note that when binding your local account your password will be cleared and if you want to use it further, you have to change it. ### I registered using a CAS account but I also want to use a local one User can create local account in the profile **Settings** page. In here if you are registered using external account and not local one, you should see **Create local account** button. After clicking on it local login _without_ password will be created. Next thing you have to set your password to newly created local login (Current password leave blank). ## C# Reader 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.cs](https://github.com/ReCodEx/utils/blob/master/runners/cs/Reader.cs) 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. ## Exit Codes For some particular languages ReCodEx provides mappings of exit codes from internal runners to messages. Full tables of codes can be found on [separate page](https://github.com/ReCodEx/wiki/wiki/Exit-Code-Mappings). ## Exercise vs. Assignment Exercise and assignment are two terms which are not the same and there are some differences. In general, **exercises** are templates for **assignments**. In more detail, exercises are algorithmic problems defined and configured by supervisors. Exercise contains test cases which executes solutions submitted by users and check their outputs against sample results. Configuration of an exercise also defines time and memory limits which the solution has to meet and scoring details which are used in the evaluation (assigning points for passed tests). Exercise itself cannot be solved by students and is displayed only to supervisors and administrators. If supervisor assigns an exercise to a group of students, an assignment is created from the exercise. Assignment can define some further details like number of points which can students gain or deadlines which should be met. But most importantly, an assignment is a full copy of the exercise. That means the assignment will not be modified when the configuration of the exercise is changed. This behavior was chosen to avoid unnecessary broken assignments in case the exercise is being edited (and possibly gets broken) by its author. When the assignment gets out of sync with its original exercise (because the exercise was edited), a informational panel is displayed to the supervisor on the assignment detail/edit page. This panel also hold a button, which allows the supervisor to overwrite current assignment data (text, configuration, limits, ...) with the current version of the exercise. ## As a supervisor I want to see more detailed logs of user submissions Before we start let us define **debug** vs. **normal** submissions. The results of a debug submission contain evaluation results, the execution log and the outputs of executed programs. And the results of a normal submission contain only the results needed for proper assignment of points (aka. evaluation results). With this being said, all submissions made by students for an assignment are normal and even submissions of reference exercise solutions are normal. As a supervisor you should be able to do something called resubmitting of a user solution; this feature should be available on every page of a particular submission. On resubmitting, debug outputs and execution log are turned on by default and can be found in the results archive. Please note that resubmitting all solutions for an assignment is just a normal submission without debug information. ## How to write Custom Judges ReCodEx provides a few initial judges programs. They are mostly adopted from CodEx and installed automatically with the worker component. Judging programs have to meet some requirements. Basic ones are inspired by standard `diff` application -- two mandatory positional parameters which have to be the files for comparison and exit code reflecting if the result is correct (0) or wrong (1). This interface lacks support for returning additional data by the judges, for example similarity of the two files calculated as the Levenshtein edit distance. To allow passing these additional values an extended judge interface can be implemented: - Parameters: There are two mandatory positional parameters which have to be files for comparison, first one is expected output, second one result from tested program - Results: - _comparison OK_ - exitcode: 0 - stdout: at the beginning of the output, there is a double value which should be quality percentage of the judged file, after that white character as a delimiter can be present and furthermore some text which will be accessible within web application - _comparison BAD_ - exitcode: 1 - stdout: might contain text which will be accessible within web application - _error during execution_ - exitcode: 2 - stderr: there should be description of error The additional double value is saved to the results file and can be used for score calculation in the frontend. If just the basic judge is used, the values are 1.0 for exit code 0 and 0.0 for exit code 1.