-*- mode: text; mode: auto-fill -*-
$Id: NEWS 4645 2007-12-26 11:31:57Z cher $

Version 2.3.4 (r4646) (20071226)
================================
Sorry, no English version yet.

Version 2.3.3 (r4320) (20070825)
================================
Sorry, no English version yet.

Version 2.3.2 (r3929) (20070206)
================================
Many-many changes and improvements.
Information necessary for migration from version 2.2.* of the
ejudge system to the current version is in the `UPGRADE' file.

The current versions of 3rd-party programs and libraries are
supported:
	expat-2.0
	jdk-1.6
	httpd-2.2

configure
---------
CGI-programs are installed to the ${prefix}/libexec/ejudge/cgi-bin
directory by default instead of ${prefix}/cgi-bin. Thus you
might need to update symbolic links in the `cgi-bin' directory
of the HTTP server.

New option `--enable-new-server-socket' is supported. This
option allows specifying the default path to the `new-server'
control socket.

New options `--enable-ajax' is supported. This option enables
AJAX in the `new-server' program. The client part uses the Dojo
toolkit, which must be installed to the HTTP server (see
`UPGRADE'). Note, however, that AJAX development is in progress
and most features are not implemented yet.

New option `--with-mysql' is supported, which enables MySQL for
data storage. Note, however, that this feature currently is not
implemented.

New option `--enable-style-prefix' is supported, which enables
specifying the URL prefix for accessing ejudge HTML style files,
which are used in the HTML pages, generated by the `new-server'
program. The default value of this option is `/ejudge/',
i.e. the URL for accessing the style files looks like
HOST/ejudge/file. Thus the style files must be located in the
`ejudge' directory of the HTML Document root directory of the
HTTP-server. If the HTML style files should be located in some
user's home directory, the option's value may be set to to
/~USER/.

Many command line options of the `configure' script have default
values, which are as follows:
--enable-socket-path		/tmp/userlist-socket
--enable-super-serve-socket	/tmp/super-serve-socket
--enable-new-server-socket	/tmp/new-server-socket
--enable-contests-home-dir	/home/judges
--enable-conf-dir		/home/judges/data
--enable-cgi-conf-dir		../cgi-data
Thus, if the desired value of the command line option is the
same, as the default value, the option may be omitted.

On the x86_64-*linux* systems the libraries directory is
automatically set to ${exec_prefix}/lib64.

The Sun JDK 1.6.* is supported.

The `uudecode' program is no longer required for the ejudge
installation. A simplified version of the GNU uudecode program
is included in the ejudge source code.

contest.xml
-----------
New elements are added: <login_template>, <copyright_file>,
<priv_header_file>, <priv_footer_file>, <allowed_regions>,
<login_template_options>. These new elements are documented in
the Wiki-section of the http://www.ejudge.ru site.

New attributes are added to the <contest> element:
"new_managed", "assign_logins", "force_registration",
"disable_name", "enable_forgot_password", "exam_mode",
"disable_locale_change". The attributes are documented in the
Wiki-section of the http://www.ejudge.ru site.

ejudge.xml
----------
New elements are added: <plugin_dir>, <new_server_socket>,
<new_server_log>, <compile_servers>, <plugins>, <plugin>.

The following attributes are supported for the <plugin> element:
"name", "type", "load", "default".

serve.cfg
---------
New global configuration variables are added:
`disable_user_standings', `problem_navigation',
`appeal_deadline', `statement_dir', `description_file',
`disable_banner_page'.
`is_virtual' global configuration variable is added for the
replacement of `virtual' global configuration variable
(`virtual' is a keyword in C++, so it's better to avoid using it
as variable name in the source code). For backward
compatibility, `virtual' is declared as alias to `is_virtual'
global configuration variable.

New problem configuration variables are added:
`manual_checking', `examinator_num', `check_presentation',
`ignore_exit_code', `disable_user_submit',
`disable_submit_after_ok', `max_vm_size', `max_stack_size',
`max_data_size', `enable_language', `require', `statement_file',
`alternatives_file', `type', `alternative', `stand_attr'.
The `output_only' problem configuration variable is now just an
alias to the `type' problem configuration variable.

The following problem types are supported:
	standard
	output-only
	short-answer
        text-answer
	select-one
	select-many

New tester configuration variable `memory_limit_type' is added.
The variable may have the following values:
	default
	dos
	java

Support for memory limiting is reimplemented. Now the memory
limit is specified in the problem configuration variables
`max_vm_size', `max_stack_size' intead of tester configuration.
The tester configuration specifies how memory limiting should be
enforced (see `memory_limit_type' description above).

runs.log
--------
The submit information storage format is changed. One record now
occupies 128 bytes. Space for IPv6 addresses is allocated,
timestamps occupy 8 bytes each.

test.inf
--------
New configuration variables are supported:
	exit_code
	check_stderr

userlist.xml
------------
New elements are added: <region>, <birth_date>, <entry_date>,
<graduation_date>.

New attributes are added: "ssl", "role", "cnts_last_login",
"info_create", "recovery".

javac
-----
Java programs being submitted for testing are no longer required
to have the main class named `Main'. Arbitrary names for the
main class are supported.

new-server
----------
This is brand new program, which is an improved reimplementation
of the `serve' contest server. `new-server' supports many new
features missing in the `serve' program: all the contest are
managed by one process `new-serve' (so, there is no need for
`super-serve' program to start and stop contest servers on
demand), new HTML user interface is implemented. The `serve'
program is rendered obsolete and should not be used for new
contest.

To enable new server during contest settings editing by the
`serve-control' CGI program, enable "Use the new-server for this contest?"
instead of "Manage the contest server?".

New format conversion specifiers %Mr, %Ur are added for region
information from the user database.

The virtual OLYMPIAD contests are supported. The full testing of
the participant's submissions is performed immediately after the
virtual contest stops (when time expires or the participant
presses the "Stop contest" button).

The new commands are available for the contest administrator (as
compared to the old `serve' contest administration interface):
	"Clear displayed runs"
	"Ignore displayed runs"
	"Disqualify displayed runs"
	"Add new runs in CSV format"
	"Download runs"

Unprivileged users may request password restoration.

The AJAX interface is partially implemented in the unprivileged
users' HTML interface. Note, however, that the AJAX interface is
currently in development and most planned features are not
implemented.

Problem statements may be displayed in the HTML user interface.

Test-like problems (where one or several answers should be
chosen out of displayed) are supported.

new-client
----------
This is new program - CGI-client for the `new-server' contest
server. The `new-client' program (and its symbolic links:
`new-master', `new-judge', etc) replaces the old `team',
`master', `judge' CGI-programs.

The unprivileged HTML user interface is reimplemented.

The privileged HTML user interface is basically the same.
Certain user interface elements are reworked, and many new
commands are added.

libchecker
----------
The type for the character strings is changed from `unsigned
char' to `char' for better compatibility with C++ and gcc-4.1.

New data types for S-expressions are added.

New function `checker_read_buf_2' is added:
char *checker_read_buf_2(
	int ind,             // stream number for reading
	const char *name,    // the parameter name
	int eof_error_flag,  // 1, if EOF is presentation error
	char *sbuf,          // the fixed buffer address
	size_t ssz,          // the fixed buffer size
	char **pdbuf,        // the extendable buffer address
	size_t *pdsz);       // the extendable buffer size
The function reads one word from the specified input stream. The
word is a longest possible sequence of non-whitespace
characters. The word ends with whitespace character or EOF
marker, which are not the part of the word and remain in the
input stream. Before reading the word, whitespace in the input
is skipped.

The word is read into the fixed-size buffer or into the
extendable buffer, or into both. To specify reading into the
fixed-size buffer, non-zero values of `sbuf', `ssz' parameters
should be specified. To specify reading into the extendable
buffer, non-zero values of `pdbuf' and `pdsz' parameters should
be specified.

If only the fixed-size buffer parameters are specified, the word
is read into the fixed-size buffer. If the word is too large for
the fixed-size buffer, the checker is terminated with
"Presentation error" or "Check failed" error depending on the
input stream number.

If only the extendable buffer parameters are specified, the word
is read into the extendable buffer. Memory for the word is
allocated on heap, so it should be freed with `free' when the
buffer is no longer in use.

If both the fixed-size buffer and the extendable buffer
parameters are specified, the word is read into the fixed-size
buffer unless its size is greater than the buffer size. In the
latter case the word in read into the extendable buffer.

In any case the function returns the pointer to the beginning of
the buffer with the read word. If there is no word read because
of the end of file, and the `eof_error_flag' is 0, NULL is
returned.

New function `checker_read_file_f' is added:
void checker_read_file_f(
	FILE *f,         // input stream
	char **pbuf,     // buffer to read into
	size_t *psize);  // the file size
The function reads the file's content into memory. The binary
files are supported. After the file's content one '\0' byte is
added, so if the file is text file, its content in memory may be
manipulated with C string functions.

All functions `checker_read_team_*' are renamed to
`checker_read_out_*'. The old names are preserved for backward
compatibility. The `checker_team_eof' function is renamed to
`checker_out_eof', the `checker_team_close' function is renamed to
`checker_out_close'.

New function `checker_out_eoln' is added:
void checker_out_eoln(int lineno);
The function skips all whitespace except `\n' in the program
output file. If the next character is '\n' or EOF is reached,
the function returns successfully. The "Presentation error" is
diagnosted otherwise.

Reading of integer values from input streams is improved.
Integer overflow is handled correctly.

New functions checker_eq_{float,double,long_double}_abs are added:
int checker_eq_TYPE_abs(TYPE v1, TYPE v2, TYPE eps);
The functions compare two numbers of the specified
floating-point type using the specified absolute error. If the
numbers are equal (with the specified absolute error), 1 is
returned. Otherwise 0 is returned.

New function `checker_read_sexpr' is added:
checker_sexpr_t checker_read_sexpr(int ind);
The function parses the S-expression from the specified stream.

New function `checker_eq_sexpr' is added:
int checker_eq_sexpr(checker_sexpr_t l_corr, checker_sexpr_t l_out);
The function compares two S-expressions. The function returns 1,
if the two S-expressions are equal, and 0 otherwise.

New functions `checker_{koi8r,cp866,cp1251,iso,mac}_to_ucs2':
int checker_CHARSET_to_ucs2(int c);
The functions convert one character in the specified cyrillic
character set into the UCS2 character set.

New functions `checker_{koi8r,cp866,cp1251,iso,mac,utf8}_to_ucs2':
unsigned short *checker_CHARSET_to_ucs2_buf(
	const char *str,
	unsigned short* buf,
	size_t size);
The functions convert the character string `str' in the
specified charset CHARSET into the string in the UCS2 charset.
The length of the string `str' is specified explicitly in
parameter `size', i.e. it is possible to convert strings
containing NUL bytes. UCS4 codes greater 0xffff, which may
appear in UTF8 string, are not supported. The result buffer is
specified in the `buf' parameter. The result buffer `buf' should
have size atleast "sizeof(short) * size" bytes.
The function returns the pointer to the result, i.e. the value
of the `buf' parameter.

New function `checker_ucs2_tolower':
int checker_ucs2_tolower(int c);
The function lowercases character in UCS2 charset. Currently the
english and russian alphabets are only supported.

New function `checker_ucs2_tolower_buf':
unsigned short *checker_ucs2_tolower_buf(
	unsigned short *buf,
	size_t size);
The function lowercases the string in UCS2 charset. Currently the
english and russian alphabets are only supported. The `buf'
parameter specifies the string address, and `size' parameter
specifies its size.

New function `checker_strcmp_ucs2':
int checker_strcmp_ucs2(
	const unsigned short *s1,
	const unsigned short *s2);
The function compares two strings in UCS2 charset. The strings
must terminate with 0x0000 UCS2 character.

New function `checker_eq_str_rus_ucs2':
int checker_eq_str_rus_ucs2(
	const char *s1,
	const unsigned short *s2);
The function compares the `s1' string in one of the supported
russian byte charsets (koi8r, cp1251, cp866, iso, mac, utf8)
with the string `s2' in UCS2 charset. Because the exact charset
of the string `s1' is unknown, all possible variants are checked.

New function `checker_eq_str_rus_ucs2_nocase':
int checker_eq_str_rus_ucs2_nocase(
	const char *s1,
	const unsigned short *s2);
The function works like `checker_eq_str_rus_ucs2', but comparing
strings case-insensitively.

Standard checkers
-----------------
The standard checkers
cmp_{float,double,long_double}, cmp_{float,double,long_double}_seq
support the `ABSOLUTE' environment variable. If the `ABSOLUTE'
environment variable is set (to arbitrary value), the comparison
of two floating-point values is performed in absolute error mode
instead of relative error mode (see new functions checker_eq_TYPE_abs).

The standard checker `cmp_huge_int' compares arbitrarily long
numbers (without 1Mb limit).

New standard checker `cmp_sexpr' compares two S-expressions for
equality.

New standard checker `cmp_yesno' compares `Yes'/'No' answers. If
the program being tested outputs something different from Yes or
No (case-insensitive), "Presentation error" is reported. If the
program being tested outputs answer in different letter case,
also the "Presentation error" is reported.

compile
-------
The `compile' program works correctly in the daemon mode. The
program handles `SIGHUP' signal and restarts itself, so the
`SIGHUP' may be used to force re-reading of the configuration
files. The following new command line options are supported:
	-i	initialization mode. In this mode all the
	        necessary directories are created, then the
                `compile' terminates. The initialization mode is
                used during installation and setup of the ejudge
                system.
	-D	start in daemon mode
	-u UID	specify the user UID. May be used only if the
	        `compile' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-g GID	specify the group GID. May be used only if the
	        `compile' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-C DIR	change the current directory to `DIR'.

compile-control
---------------
A new program for controlling the `compile' program from the
command line. Especially useful, when the `compile' program is
started in daemon mode.
Usage:
	compile-control [stop|restart]

edit-userlist
-------------
During viewing the registered users new command `o' is
available, which may be used for copying the contest-specific
information of user from one contest to another.

ejudge-control
--------------
A new program for controlling the ejudge system as the whole
from the command line. The following command line options are
supported:
	-u UID	specify the user UID. May be used only if the
	        `ejudge-control' is invoked by the `root' user.
		May be useful in system startup sctipts.
	-g GID	specify the group GID. May be used only if the
	        `ejudge-control' is invoked by the `root' user.
		May be useful in system startup sctipts.
The following commands are supported:
	start	start all the ejudge daemons (userlist-server, 
		super-serve, compile, new-server, job-server).
	stop	terminate all the ejudge daemons

job-server
----------
The `sendmail' MTA is supported correctly.

The `SIGHUP' signal is handled correctly and causes the program restart.

New commands "stop" and "restart" are supported.

The following new command line options are supported:
	-u UID	specify the user UID. May be used only if the
	        `job-server' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-g GID	specify the group GID. May be used only if the
	        `job-server' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-C DIR	change the current directory to `DIR'.

super-serve
-----------
The following new commands are available during variant editing:
	"Clear variants"
	"Random variants"

Daemon mode is supported.

The following new command line options are supported:
	-D	start as daemon
	-u UID	specify the user UID. May be used only if the
	        `job-server' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-g GID	specify the group GID. May be used only if the
	        `job-server' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-C DIR	change the current directory to `DIR'.

job-server-control
------------------
New program to control the `job-server' program. Especially
useful when the latter runs in daemon mode. Usage:
	job-server-control [stop|restart]

new-server-control
------------------
New program to control the `new-server' program. Especially
useful when the latter runs in daemon mode. Usage:
	new-server-control [stop|restart]

new-server-cmd
--------------
New program to work with the new contest server `new-server'
from the command line. The `new-server-cmd' program works
similarly to the `serve-cmd' program. The following commands are
currently implemented in the `new-server-cmd' program:
	login
	team-login
	user-login
	observer-login
	examiner-login
	chief-examiner-login
	coordinator-login
	judge-login
	admin-login
	master-login
	logout
	write-xml-runs
	export-xml-runs
	dump-runs
	dump-problems
	soft-update-stand
	suspend-testing
	resume-testing
	judge-suspended-runs
	has-transient-runs
	team-run-status
	run-status
	dump-source
	team-dump-source
	dump-clar
	team-dump-clar
	get-contest-name
	get-contest-type
	submit-run
	team-submit-run
	import-xml-runs
	dump-runs
	dump-master-runs
	dump-report
	full-import-xml-runs
The following commands are not implemented, as compared to `serve-cmd':
	dump-team-report
	dump-standings
	dump-all-users

super-serve-control
------------------
New program to control the `super-serve' program. Especially
useful when the latter runs in daemon mode. Usage:
	super-serve-control [stop|restart]

userlist-server
---------------
Plugin support for storing the user information is implemented.
Currently the inly implemented data storage plugin is XML files
plugin. The MySQL plugin is in development.

The `sendmail' MTA is supported correctly.

The following new command line options are supported:
	-u UID	specify the user UID. May be used only if the
	        `userlist-server' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-g GID	specify the group GID. May be used only if the
	        `userlist-server' is started by the `root' user. The
                option is used during installation and setup of
                the ejudge system.
	-C DIR	change the current directory to `DIR'.

userlist-server-control
------------------
New program to control the `userlist-server' program. Especially
useful when the latter runs in daemon mode. Usage:
	userlist-server-control [stop|restart]

Version 2.3.1 (r3198) (20060705)
================================
The user database structure is changed. Now the majority of
user info fields are contest-specific. For example, the `name'
field (the user name) may be different for the same user (more
precisely, for the same login) in different contests. In the
previous versions all the user information fields are
contest-independent, so change of the `name' field for one
contest automatically changed the `name' of the user in all
other contests, even had finished long ago.

For backward compatibility with the accumulated user database
the existing information about users are considered as specific
to the special "default contest" (which has the indentifier as
0). This information is used, when no contest-specific
information is available for a particular contest. However, as
soon as an existing user (or an administrator) changes
information about the user in the contest, a copy of user
information fields is created and made contest-specific for this
contest, so only the data for the contest is changed, but the
default data is left intact.

Only `login', `e_mail' and `password' user-settable fields are
contest-independent. All other user-editable fields are
contest-specific.

The `read_only' field now means that the user information
cannot be changed for any contest, except the registration
password, which can still be changed.

A new `cnts_read_only' field is added, which means that the user
information cannot be changed by the user for the particular
contest, but the team password can still be changed.

Version 2.2.0 (20060609)
========================
No changes from 2.1.49. From this moment on the 2.2 branch only
bugs will be fixed. All new features will go to the 2.3 branch,
which became version 3.0.

Version 2.1.49 (20060609)
=========================

Add support for a new "programming language" - plain text files
(txt). This "language" allows submitting an ordinary text files
(for example, for output-only problems). The result of
"compilation" of a text file is a script, which works like
`false' command (i.e. does nothing and returns exit code 1). For
fine tuning of available languages for each problem the
`disable_language' language configuration variable may be used.

serve
-----
Additional information about contest times is output to the
XML run log files. The contest name is also output to the
external XML run log file.

Automatic generation of the XML run logs is supported for both
the internal and external run log formats. The interval of
automatic XML run log generation may be specified in the
`serve.cfg' configuration file. The new
`external_xml_update_time' global configuration variable allows
specifying the external XML run log generation interval in
seconds, and the `internal_xml_update_time' global configuration
variable allows specifying the internal XML run log generation
interval in seconds. The files have paths as follows:
<contest_home>/var/status/dir/external.xml
<contest_home>/var/status/dir/internal.xml

super-serve, serve-control
--------------------------
Editing of the global configuration variables
`external_xml_update_time'  `internal_xml_update_time' is
supported.

testlib
-------
The message text, which is written by the `quit' procedure is
directed to the standard error stream (ErrOutput). This is
useful for scoring checkers.

run
---
A bug is fixed, which caused solutions for DOS compilers not
working in the standard stream redirection mode, when the `run'
program is managed by the `super-serve' program.

serve
-----
A new kind of checkers - "scoring checkers" is supported. In
this kind of problems the score for the problem (or the score
for each test) is scored by the checker. Usually, the checker
gives its YES/NO verdict for each test, and the score is
specified in the problem settings. Now "scoring checker" may
score the test to arbitrary score ranging from 0 to maximal
score for this test.

The "scoring checker" mode is activated by the `scoring_checker'
new problem configuration variable. If this variable is set to
1, the problem/test score is evaluated by the checker.

In the KIROV/OLYMPIAD contests the "scoring checker" scores each
test individually, and the total score of a submit is equal to
the sum of scores for each test. In the MOSCOW contests the
problem score is equal to the score of the first failed test in
the test sequence (so, probably, the problem should have one
test).

A "scoring checker" should work as follows. The checker exit
code means as usually the checking result:
0       OK
4       PE
5       WA
All other exit codes are treated as "Check failed" condition.

If the verdict is OK, the test/problem is scored to the full
score (in case of MOSCOW contest, testing proceeds to the next
test).
If the verdict is PE, the test/problem is scored to 0.
If the verdict is WA, the standard output of the checker must
contain the only integer number: score for this test/problem.
If the standard output contains something else, than one integer
number and whitespace, this is treated as "Check failed"
condition. The number in the output file must be >= 0 and less
than the maximal score for the problem or test. In case of other
number the "Check failed" error is reported.

run
---
Problems with scoring checkers are supported.

super-serve, serve-control
--------------------------
Editing of the `scoring_checker' problem configuration variable
is supported.

Editing of the `disable_language' problem configuration variable
is supported.

run
---
"Score leaps" are supported for MOSCOW contests, i.e. some score
value may never be used for a problem. For example, some problem
has 10 tests, the maximum score is 2, and the solution is either
scored as 2 (all tests passed) or as 0 (otherwise), so score 1
is missing for the problem. In this case the `score_tests'
variable for this problem should be set as follows:
score_tests = "11"
This means, that the solution, which passed 10 tests should be
scored as 1, but such solution is (implicitly) scored as 2, so
the maximal score is chosen.
So the sequence of the test numbers forms nondecreasing sequence
(several consequent test numbers may be the same, in this case
the maximum score is chosen).

serve
-----
"Output-only" problems are supported, i.e. the problems where
the solution to the problem is the answer rather than the
problem source code. A new language configuration variable
`output_only' is added. This variable may be used even in
abstract problems and is properly inherited. The default value
is 0. If the variable is set to 1, the problem is considered as
an "output-only" problem. For "output-only" problems the
"compilation" and "run" stages are performed anyway, but
they operate quite differently (see below). For "output-only"
problems the "txt" (Plain text) language should be used.

compile
-------
"Output-only" problems are supported. In case of "output-only"
problem the "compilation" means copying the source file (the
answer file, actually) into the compilation result file. The
source language settings are ignored, since the compiler is not
started.

run
---
"Output-only" problems are supported. The "output-only" problem
must have the only test. The "execution" of an "output-only"
problem solution is copying of the "executable" (the answer
file, actually) to the output file. The output file is then
checked by the problem checker as usually.

super-serve, serve-control
--------------------------
Editing of the `output_only' problem configuration variable is
supported.

serve, master, judge
--------------------
When a message from judge is being composed before the contest
starts, the judge or administrator may specify, that this
message will be available to the participants only after the
contest start.

execute
-------
This is a new program for execution of the program being checked
from the command line. The `execute' program supports all kinds
of limitations (by time, by memory, by available operations),
which are supported by the ejudge.

libchecker
----------
The library is ported to the Win32 platform (using the gcc
compiler from the Cygwin). However, the library does not depend
on Cygwin libraries and the resulting .DLL and .LIB files may be
used by any Windows compiler. For the Cygwin and MinGW32
platforms the .a library is provided as well.

Version 2.1.48 (20060430)
=========================

contest.xml
-----------
A new <main_url> element is added. This element allows
specifying the main page URL for the contest. The element is
used in the initial registration e-mail letter, sent when a new
user has been registered. Example of use:
<main_url>http://acm.univ.ru/contests/acm2006</main_url>

A new "send_passwd_email" attribute is added to the <contest>
element. If this attribute is set to "yes" value, the initial
registration e-mail letter is sent to the user even if the
simplified registration is enabled.

ejudge.xml
----------
New elements <server_name>, <server_name_en>, <server_main_url>
are added. The <server_name> element allows specifying the
description of this server, where the ejudge system is
installed, for example:
<server_name>  </server_name>

The <server_name_en> element allows specifying the description
of the server in English. This element is used, when the English
language is choosen during registration. For example:
<server_name_en>The university contest server</server_name_an>

The <server_main_url> element allows specifying the main server
URL for the current ejudge installation. For example:
<server_main_url>http://acm.univ.ru/contests</server_main_url>

These elements are used when an e-mail with user's registration
data is sent to user after registration of a new user. The
elements are used in case, when no contest is specified during
registration. If the contest is specified, the contest.xml's
elements are used instead.

userlist-server
---------------
The standard templates for e-mail messages, sent upon successful
registration are changed. The new templates use the elements
<server_name>, <server_name_en>, <server_main_url> of the 
ejudge.xml configuration file and the elements <name>,
<name_en>, <main_url> of the contest.xml configuration file.

The "send_passwd_email" attribute of the contest.xml file is
supported.

userlist-server, edit-userlist
------------------------------
A new field `simple_registration' is added to the user
database. This field is set to "yes", if the user was registered
using the simplified registration procedure. The value of this
field may be changed using the `edit-userlist' program by the
administrator.

super-serve, serve-control
--------------------------
Editing of the <main_url> element and the "send_passwd_email"
attribute of the contest.xml file is supported.

team, serve
-----------
The binary files are shown correctly by the "View source" command.

serve
-----
A new `content_type' configuration variable is added to the
language section of the `serve.cfg' configuration file. If this
variable is set, the specified HTTP content type will be used
when the "Download source" command of the CGI programs `master'
or `judge', or when the "View source" command of the CGI program
`team' is executed. This configuration variable is useful for
languages with binary "sources". For example, if the "Microsoft
Word" language is enabled, the content type for this language
may be set as follows:
content_type = "application/msword"

The file name is set correctly for the downloaded sources even
the language is binary.

serve, compile
--------------
The maximal number of simultaneously supported programming
languages is increased to 100.

super-serve, serve-control
--------------------------
Editing of the `binary' and `content_type' language
configuration variables of the `serve.cfg' file is supported.

A bug which prevented editing of the `acm_run_penalty' field is
fixed.

ejudge-setup
------------
Editing of the initial values of the elements <server_name>,
<server_name_en>, <server_main_url> of the `ejudge.xml'
configuration file is supported.

Version 2.1.47 (20060419)
=========================

contest.xml
-----------
A new attribute `simple_registration' is added to the <contest>
element. If this attribute is set to the "yes" value, a simple
new user registration scheme is used for this contest. When a
new user account is being created for this contest by a
`register' CGI program, the e-mail step is omitted, the new user
password is shown immediately, so the user may proceed to the
next stage of the registration immediately.

super-serve, serve-control
--------------------------
Editing of the new `simple_registration' attribute of the
`contest.xml' file is supported.

Editing of the new `always_show_problems' global configuration
variable of the `serve.cfg' configuration file is supported.

Users, which have privilege bits set in the contest
configuration file are registered and made invisible in this
contest automatically.

When user capabilities are edited, 3 predefined set of
capabilities are available: "Observer", "Judge", "Master".

serve, team
-----------
New global configuration variable `always_show_problems' is
added to the `serve.cfg' configuration file. If this variable is
set 1, the link to the problem statements is available to the
participants in the `team' CGI program before the contest starts.

New problem configuration variable `acm_run_penalty' is added to
the `serve.cfg' configuration file. This variable is active only
in ACM and MOSCOW contests and allows changing of the failed
submission penalty. The standard value of this penalty for all
ACM contests is 20 minutes, and this is the default value for
`acm_run_penalty' configuration variable. For example, it is
possible to define the `acm_run_penalty' to 0 to disable
submission penalty at all. The `acm_run_penalty' variable may be
defined in the abstract problem and will be properly inherited
in the concrete problems.

register
--------
A simplified contest registration scheme is supported, if the
`simple_registration' attribute is set for the contest.

serve
-----
Several bugs in the problem summary table generation for the
KIROV contests are fixed.

ejudge-setup
------------
The command to start `serve' in the probe mode for the contest 1
is added to the end of the generated setup script.

super-serve, serve-control
--------------------------
Editing of the `test_sets' configuration variable is supported.

New standard checker `cmp_huge_int' is supported.

Several bugs in the "Check contest settings" command are fixed.

Editing of the `always_show_problems' global configuration
variable is supported.

Editing of the `acm_run_penalty' problem configuration variable
is supported.

userlist-server
---------------
A team member cannot be removed, if the team is marked as
read-only.

libchecker
----------
New functions `checker_in_eoln', `checker_team_eoln',
`checker_corr_eoln' are added. These functions check that the
corresponding input file contains the End-Of-Line character
(possibly after spaces) at the current position. All whitespace
characters and the \n itself is removed from the stream.

New standard checker `cmp_huge_int' is added. The checker
compares a number in the output file with the number in the
correct answer file. The maximal length of numbers is 1Mb.
Whitespace characters before the number, `+' sign, and the
leading zeros are ignored.

serve-cmd
---------
New commands team-dump-source, team-dump-clar,
team-run-status are added.
serve-cmd CONTEST-ID team-dump-source SESSION-FILE RUN-ID
        Outputs to the standard output the source code for
        submit RUN-ID. Viewing of the source code must be
        enabled for the contest, also the user must be the
        author of this submit.
serve-cmd CONTEST-ID team-run-status SESSION-FILE RUN-ID
        Outputs to the standard output the status of the submit
        RUN-ID. The user must be the author of this submit.
serve-cmd CONTEST-ID team-dump-clar SESSION-FILE CLAR-ID
        Outputs to the standard output the text of the
        clarification request CLAR-ID. The user must have
        permission to view this message.


Version 2.1.46 (20060319)
=========================

configure
---------
The `--with-g++' option is renamed to `--with-gpp', as the
`configure' script does not support `+' sign in option names.

serve
-----
Two new predicates are supported in the run filter expressions:
latest[(N)]
	Evaluates to TRUE, if there are no submits with the same
        used Id and the same problem having status "OK",
        "Partial solution" or "Accepted for testing" after the
        current submit or the N'th submit. The predicate is
        useful in OLYMPIAD contest for selecting the runs for
        full testing.
afterok[(N)]
	Evaluates to TRUE, if there is a submit with the same
        user Id and the same problem having status "OK" before
        the current submit of the N'th submit. The predicate is
        useful in ACM, KIROV, MOSCOW contests for selecting the
        submits which do not affect the current results, or vice
        versa, for selecting the submits, affecting the current
        results.

The "shadow" full testing is completely implemented for OLYMPIAD
contests. When the contest operates in `accepting' mode, the
contest administrator may fully test either a particular submit
(the "Full rejudge" command in the submit status change menu),
or fully test the selected set of submits (using the "Full
rejudge displayed runs" command). The selected submits are
tested on the complete set of tests rather than on the accepting
set of tests. The results of testing are available to the
contest administrator and the contest judges and are shown in
the privileged table of results. The fully tested submit need
not be retested after the contest is over. Thus, even during the
OLYMPIAD contest it is possible to accumulate the results, which
became final results as soon as the contest ends. During the
contest while the contest works in the `accepting' mode, the
participants have access only to the information about the
acceptance testing, even if the full information is already
available. The full information will be available to the
participants as soon as the contest is switched to the `testing'
mode.

The full "shadow" testing is performed with a lower priority,
than the acceptance testing, so the participants submits will be
processed for the acceptance testing as soon as possible.
However, the current version of the `ejudge' system does not
support testing on one test separately from the other tests,
i. e. a submit is fully tested on all the test before the
`ejudge' can proceed to the next submit. So, if the full testing
takes considerable time, this may create the queue of submits
for acceptance testing.

serve, master
-------------
Support for the "Full rejudge displayed runs" command is added
for the "shadow" full testing of the submits in the OLYMPIAD
contests in the `acceptance' mode.

run
---
Two new global configuration variables are added to the
`serve.cfg' configuration file: skip_accept_testing,
skip_full_testing. If the first variable is set to non-zero
value, the `run' program will ignore all acceptance testing
requests for the OLYMPIAD contests. If the second variable is
set, the `run' program will ignore all full testing requests for
the OLYMPIAD contests.

Requests are ignored correctly now. The ignored requests do not
cause infinite loop in the `run', if the affecting packets are
not removed from the spool directory. The `QUIT' packet (forced
quit) packet now has the highest priority. The `QUIT' packet is
written back to the spool directory, if the `run' program works
in unmanaged mode.

capexec, libdropcaps.so
-----------------------
Fixes for the 2.6.* Linux kernel.

serve, team
-----------
A new global configuration variable `disable_failed_test_view'
is added to the `serve.cfg' configuration file. If this variable
is set to 1, the failed test number is not shown on the
participant's personal page. This variable works only for ACM
and MOSCOW contests.

serve-control, super-serve
--------------------------
Editing of the new global configuration variable
`disable_failed_test_view' of the `serve.cfg' file is
supported.

Version 2.1.45 (20060121)
=========================

Installation manual is updated (INSTALL and INSTALL.RUS).

ejudge.xml
----------
New XML elements <job_server_log>, <job_server_spool>,
<job_server_work> are added to the `ejudge.xml' configuration
file. These elements are used by the new `job-server' program.
The elements may be omitted, their default values are built
using the <var_dir> element value as described below.
The <job_server_log> element allows setting the filename, which
will be used as the `job-server' program log file in the daemon
mode. If the `job-server' program is started in non-daemon mode,
the log file is not used and all messages are printed to the
standard error stream. If the <job_server_log> element is not
defined, the default value `$<var_dir>/job_server.log' is used,
where $<var_dir> is the value of the <var_dir> element in the
`ejudge.xml' file.
The <job_server_spool> element allows setting the directory for
the job queue of the `job-server' program. If the
<job_server_spool> element is not defined, the default value
$<var_dir>/jspool is used, where $<var_dir> is the value of the
<var_dir> element in the `ejudge.xml' file.
The <job_server_work> element allows setting the work directory
for the `job-server' program and invoked jobs. If the element
<job_server_work> is not defined, the default value
$<var_dir>/jwork is used, where $<var_dir> is the value of the
<var_dir> element in the `ejudge.xml' file.

contest.xml
-----------
Added support for the new elements <cf_notify_email>,
<clar_notify_email>, <daily_stat_email>. They are used by the
`serve' contest server for e-mail notifications of certain
contest events.
<cf_notify_email> allows specifying e-mail address (or
addresses), which will be used for e-mail notifications in case
when testing completes with CHECK_FAILED status.
<clar_notify_email> allows specifying e-mail address (or
addresses), which will be used for e-mail notifications when a
new clarification request appears.
<daily_stat_email> allows specifying e-mail address (or
addresses), which will be used for daily statistics.

userlist-server
---------------
A new field `date' is added to the user database to the contest
registration information. This field stores the date of the
registration for the contest.

libchecker
----------
The `checker_read_file_by_line' and
`checker_read_file_by_line_f' do not use the stack for temporary
buffer allocation. This allows reading large files into memory.

serve
-----
New problem configuration variable `enable_compilation' is added
to the `serve.cfg' configuration file. The variable works only
when the problem configuration variable `disable_testing' is
set. If the `enable_compilation' variable is set to 1, the
submissions for this problem are compiled, but not tested. If
compilation succeeds, the run gets the "Accepted for testing"
(RUN_ACCEPTED) status, otherwise the "Compilation error"
(RUN_COMPILE_ERR) is assigned.

E-mail notifications on CHECK_FAILED condition and on
clarification request condition are supported. The e-mail
addresses are defined by the <cf_notify_email> and
<clar_notify_email> elements correspondingly.

New global variable `contest_finish_time' of the `serve.cfg' is
added. This variable allows specifying the astronomical time for
contest finish, when the contest duration is unlimited.

Sending daily statistics by e-mail is supported. The e-mail
address is defined by the <daily_stat_email> element of the
`contest.xml' file.

The clarification database (clar.log) is now stored in the
binary format. When the `serve' starts, it recodes the
clarification database from the old format to the new format
automatically, if necessary. The new binary format supports IPv6
addresses, 64-bit time type and some other extensions.

When a clarification messages are viewed in the privileged
`master' and `judge' programs, the name of the privileged user,
who composed the reply to a user is displayed. This information
is not available to the participants.

super-serve
-----------
When the `serve.cfg' configuration file is generated for a
contest, if the Java support is activated, the LANG environment
variable is set to the "C" value for the Java programs, thus all
the regional settings are reset to the default values. This is
necessary in order to read and write the floating-point values
in the standard format.

Editing of the new elements <cf_notify_email>,
<clar_notify_email>, <daily_stat_email> of the `contest.xml'
file is supported.

Editing of the `contest_finish_time' global configuration
variable of the `serve.cfg' file is supported.

Editing of the `enable_compilation' problem configuration
variable of the `serve.cfg' file is supported.

run
---
If the checker program is terminated due to a time-out or due to
a fatal signal, or returns non-standard exit code, a diagnostic
message is appended to the output file of the checker program.

job-server
----------
This is a new program for executing background jobs from the
queue of low-priority jobs. The contest server `serve' or the
user server `userlist-server' may put a low-priority jobs into
the queue of the `job-server' program, if the job may be
executed not immediately, and the success status of the job is
ignored. For example, the `serve' program uses the `job-server'
program for sending e-mail notifications and daily statistics.

Currently, the `job-server' program supports only e-mail
sending. More functions (for example, sound playing or voice
notifications) may be added later. Then sound playing function
will be removed in the `run' program.

The `job-server' program supports `-D' option: the daemon mode.
In this mode the program switches to background and redirects
all the diagnostic messages to the log file.

job-server-cmd
--------------
A new program to control the low-priority job server
`job-server'. The current version of the program only supports
the e-mail sending command of the `job-server'.

job-server-cmd mail CHARSET SUBJ FROM TO TEXT
here CHARSET - character set of the message,
SUBJ - the message subject,
FROM - the destination address,
TO - the source address,
TEXT - the message text.
Note, that the message text must be passed as the command line
parameter.

Version 2.1.44 (20051207)
=========================
This version fixes minor bugs of the previous versions and adds
minor improvements.

libchecker
----------
The checker program now may omit setting of the NEED_INFO macro
in the program header. If this macro is not set, its default
value is 0.

The library may be safely linked to the checker programs, which
do not use the library actually. I.e. the command line
gcc checker.c -o checker -lchecker
works even if checker.c is an ordinary C program, not written
especially for the libchecker library.

A new function `fatal_read' is added to the library:
void fatal_read(int streamno, char const *format, ...);
This function prints a message given in the `format' parameter
(printf-like format specifier and extra parameters are
supported) and then terminate the checker either with the "Check
failed" error code (if the `streamno' parameter equals to 0 or
2), or with the "Presentation error" error code (if the
`streamno' parameter equals to 1). This function is useful in
the functions, which parse complex data structures to report an
error in the input data.

serve
-----
If the real time is less than CPU time in the participant's
testing protocol (this is possible, because the CPU time is
ceiled to the system timer period), the CPU time is shown
instead of the real time to avoid confusion.

A new command `SRV_CMD_SUBMIT_RUN_2' is supported for submitting
runs. In this command the problem and the programming language
are specified by their short names rather than their
identifiers. This command is useful when these identifiers are
unknown (see below the `team-submit-run' command of the
`serve-cmd' program).

serve, team
-----------
If the submit source code contains zero byte (i.e. instead of
the source code, for example, the executable file has been
sent), and the specified programming language does not allow
binary submits, error message about invalid file format is
displayed. In the previous versions the server just closed the
connection and the client printed meaningless "Unexpected EOF
from server" message.

serve-cmd
---------
All commands support the following command line options:
	--ip IP
		Allows specifying the IP-address, which will be
                passed to the server as the source IP-address.
		The default value is 127.0.0.1.
	--ssl
		Allows setting the secure connection (SSL) flag,
                which will be passed to the server. Note, that
                the flag is already set by default.
	--no-ssl
		Allows clearing the secure connection (SSL)
                flag, which will be passed to the server. The
                flag is set by default (see --ssl option).
	--session
		Specifies, that that session file parameter of
                the command line now specifies the session
                identifier instead of the session file,
                i.e. instead of the file name a 64-bit number in
                the hexadecimal notation is given. For `login'
                and `team-login' commands this option specifies,
                that session identifier to be printed to the
                standard output rather than written to the
                specified file.
These options may be given in any place of the command line
after the command. For example:
serve-cmd 1 login --ip 192.168.0.1 --no-ssl session user password

New commands `team-login', `team-logout', `team-submit-run' are
supported. All options described above are applicable to these
commands and thus will not be described explicitly.
serve-cmd CONTEST-ID team-login SESSION-FILE USER PASSWORD
	Unprivileged login as in the `team' CGI program. The
        specified user must have the right to participate in the
        specified contest (i.e. must be registered, must not be
        banned, etc). As a result a new session identifier is
        generated and written to the SESSION-FILE file (or
        printed to the standard output, if --session option is
        given). This session identifier must be used for further
        operations for this user.
serve-cmd CONTEST-ID team-logout SESSION-FILE
	Unprivileged login as in the `team' CGI program. The
        session identifier is destroyed. Unprivileged logout
        will not work for privileged login and vice versa.
serve-cmd CONTEST-ID team-submit-run SESSION-FILE PROBLEM LANGUAGE [SRC-FILE]
	Unprivileged submit. All restrictions for unprivileged
        submits (as in the `team' CGI program) are applicable.
	PROBLEM is the short name of the problem, LANGUAGE is
        the short name of the programming language, SRC-FILE is
        the file with the submit source code. This parameter may
        be omitted or may be specified as `-', then the source
        code is read from the standard input. If the submit is
        sent successfully, its identifier is printed to the
        standard output.

userlist-server
---------------
A new command `ULS_FIX_PASSWORD' is supported for password fixing.

edit-userlist
-------------
A new command "Fix password" is added to the `f' command group.
The command fixes the user password according to the new
password checking rules: if the contest password is set, this
password is copied to the register password. This command may be
applied to the selected participants in the list of users,
registered for the contest.

A new field "Team password" may be cleared using the `f' command
group and "Clear field" subcommand.

super-serve
-----------
Automatic compilation of checker programs written in C++ is
supported (thanks to Artem Melentev).

Version 2.1.43 (20051117)
=========================
The ejudge home page has moved. The new URL is
http://www.ejudge.ru.

The GCC compiler version 4.0.* is supported. If the 4.0.*
compiler is detected during configuration, -Wno-pointer-sign
compiler option is added to the compilation options. All
warnings on -O2 optimization level, except those suppressed by
-Wno-pointer-sign are eliminated.

The ejudge system has been ported to Linux/x86_64. Note, that
the lattest version of the Reuse library is required on this
platform.

fpc/testlib.pas
---------------
Fixed some bugs related to mishandling of the Unix-style
end-of-line characters (Victor Matyukhin).

delphi/testlib.pas
------------------
The latest version of the testlib from Andrew Stankevich is
merged.

contest.xml
-----------
Two new elements are supported: <user_name_comment> and
<allowed_languages>. The <user_name_comment> element allows
defining an arbitrary HTML text, which will be displayed in the
contest registration form near to the "User name" field. This
text may, for example, contain instructions for choosing a user
name to conform to the contest rules.

The <allowed_languages> allows defining the programming
languages and programming environments, which are available for
the users during registration to a contest. If this element is
not defined, a user may enter arbitrary text in the "Programming
language" field of the registration form. If this element is
defined, a user may only choose one or several programming
languages from the provided list. The <allowed_languages>
element must list all available programming language separating
them with a comma, for example:
<allowed_languages>Borland C/C++, Borland Pascal, Delphi</allowed_languages>

The DISABLE_MEMBER_DELETE contest flag is supported. If this
flag is set for a contest, the registration form will not have
"Delete" button for team members.

New elements are added: <users_table_format>, <users_table_format_en>,
<users_table_legend>, <users_table_legend_en>. These element
allow changing the view of the list of the registered users for
this contest. The <users_table_legend> and <users_table_legend_en>
allow defining the header row of the table. The elements define
text, which will be displayed in the header row in the columns
from the first to the second to the last. The first column is
always called "NN" (the serial number of a user in the list),
and the last column is always called "Status" (the registration
status for a user). The column texts are separated with "|"
character. For example:
<users_table_legend>Id|Team name|Institution|Faculty</users_table_legend>
defines the table with the rows "NN", "Id", "Team name",
"Institution", "Faculty", "Status". The <users_table_legend_en>
is used when the table is displayed in English (i.e. locale_id == 0),
element <users_table_legend> is used when the table is displayed
in the local language (locale_id != 0) (for example, Russian).
If the elements are undefined, the default table view is used.

The <users_table_format> and <users_table_format_en> elements
define information, which is displayed in the table of the
registered participants for each registered participant. The
values of the elements should use format conversion
specifications (see below). The column descriptions are
separated with "|". The first column of the table always contain
the serial number of the participant in the table, and the last
column always contain the registration status of the participant.
For example, the following specification
<users_table_format>%Ui|%Un|%Ut|%Uf</users_table_format>
defines the table view with 6 columns: the serial number in the
table, the participant's user id, the user name, the short form
of the institution name, the short form of the faculty name, the
registration status.  The <users_table_format_en> is used when
the table is displayed in English (i.e. locale_id == 0), element
<users_table_format> is used when the table is displayed in the
local language (locale_id != 0) (for example, Russian). If the
elements are undefined, the default table view is used.

The elements <users_table_format> and <users_table_legend> must
either be set both, or unset both, and if set they must describe
the same number of columns. The same rule applies to the
<users_table_format_en> and <users_table_legend_en> elements.
If this rule is violated, the default table view is used.
If the <users_table_format> is set, <users_table_format_en> may
left unset and vice versa. The default view is used for the
unset element.

serve
-----
New global configuration variable `users_on_page' is added to
the `serve.cfg' configuration file. If this variable is set to a
positive value, the contest result table will be split into
several HTML pages with the specified number of participants on
each page. The page splitting is supported for the KIROV and
MOSCOW contest scoring systems.

New global configuration variables `stand_fail_attr' and
`stand_trans_attr' are added to the `serve.cfg' configuration
file. These variables allows specifying the attributes for the
certain standing table cells. The `stand_fail_attr' variable
specifies the attributes for the cell, if the participant has
submits in the "Check failed" state for the corresponding
problem. The `stand_trans_attr' specifies the attributes for the
cell, if the participant has submits in the "Compiling...",
"Running...", or "Pending" state. The `stand_fail_attr' may be
used for indication of failures in the contest, and the
`stand_trans_attr' may be used for indication, that there are
submits being tested, so the standings table may change soon.

A new global configuration variable `stand_show_att_num' is
added to the `serve.cfg' configuration file. The variable works
in the KIROV and OLYMPIAD contests only. If this variable is set
to a non-zero positive value, the number of attempts is
displayed in the standings table for each participant and each
problem. If the problem is solved, the number of attempts before
the first success is displayed. If the problem is not solved,
the current number of attempts is displayed.

A new global configuration variable `stand_sort_by_solved' is
added to the `serve.cfg' configuration file. The variable works
in the KIROV and OLYMPIAD contests only. If the variable is set
to a non-zero positive value, the participants in the standings
table are sorted in the decreasing order of the number of the
solved problems, and then in the decreasing order of the score.
If this variable is not set, the participants are sorted in the
decreasing order of the score.

A new problem configuration variable `lang_time_adj' is added to
the `serve.cfg' configuration file. This variable allows
adjusting the time limit for the problem depending on the
programming language. The time limit adjustment specifies
adjustment in seconds and must be greater than 0 and less than
100 seconds. The `lang_time_adj' configuration variable may be
specified several times specifying adjustments for several
languages for the problem. Each time limit adjustments
specification has the following form:
LANG=ADJ
where LANG is the short name of the programming language, and
ADJ is the adjustment. For example,
lang_time_adj="dcc=1"
lang_time_adj="java=10"
specifies for some problem, that the time limit for Delphi
solutions is increased by 1 second, and the time limit for Java
solutions is increased by 10 seconds.

A new global configuration variable `disable_submit_after_ok' is
added to the `serve.cfg' configuration file. If this variable is
set to a non-zero positive value, the participants are
disallowed to submit an already solved problem. The solved
problems are not displayed in the list of problems, available
for submit.

A new problem configuration variable `skip_testing' is added to
the `serve.cfg' configuration file. If this variable is set to a
non-zero positive value, the `run' program will skip the
requests for testing a submit on this problem, however the
testing request will be avaible for other `run' programs. This
configuration variable may be used for load-balancing between
several `run' programs running on several testing computers.
Conditional compilation is usable in such situations, for
example:
[problem]
short_name = "Z"
@if host == "host1"
skip_testing
@endif
In this case the `run' program running on the "host1" computer
will ignore requests for testing problem "Z".

A new contest scoring system "Moscow" is supported. This scoring
system is a generalization of the ACM scoring system. As opposed
to the ACM, in the Moscow scoring system problems are scored in
arbitrary number of points >= 1. The ACM contest score all
problems at 1 point. In the Moscow scoring system submits are
tested up to to the first failed test, and depending on the
number of the tests passed the submit is scored to 0, 1, 2,
... N points. The maximal score for a problem is specified by
the `full_score' problem configuration variable. For each
problem with maximal score N points (N > 1), there must be the
`score_tests' problem configuration variable defined. This
variable must define N-1 integer positive number. The numbers
are separated with spaces. Each number in the list is a test
number, and the test numbers must form an increasing sequence.
The first number in the sequence must be >= 1, the last number
in the sequence must be less than the total number of tests for
this problem. The Kth number in this list specifies the number
of tests, which must be successfully passed by a submit in order
to give K points to the submit. For example, for the following
specification:
full_score = 5
score_tests = "10 20 30 40"
and the total number of tests 50 the following rules apply. If a
submit passes 0-9 first tests, it is given 0 points, if a submit
passes 10-19 first tests, it is given 1 point, 20-29 tests - 2
points, 30-39 tests - 3 points, 40-49 tests - 4 points, 50 tests
- 5 points.

New global configuration variables to controw the view of the
standings table are added to the `serve.cfg' configuration
file. The `stand_row_attr' global configuration variable allows
defining the row attributes of the table. These row attributes
are used when no other row attributes, defined by the
`stand_v_row_attr', `stand_r_row_attr', `stand_u_row_attr',
`stand_self_row_attr', `stand_contestant_status_attr'
configuration variables are applicable. This configuration
variable must be defined 5 or 6 times defining the array of 5 or
6 attributes. The array is used as follows:
stand_row_attr[0] - the attribute of the table header row;
stand_row_attr[1], stand_row_attr[2] - the attributes of the
even and odd rows correspondingly;
stand_row_attr[3], stand_row_attr[4] - the attributes of the
even and odd rows correspondingly; these two groups of
attributes are switched when the number of solved problems
change.
stand_row_attr[5] (if defined) - the attributes of the summary
rows of the standings table. The example for `stand_row_attr'
follows:
stand_row_attr = " bgcolor=\"#cccccc\" valign=\"top\""
stand_row_attr = " bgcolor=\"#eeffff\" valign=\"top\""
stand_row_attr = " bgcolor=\"#ddffff\" valign=\"top\""
stand_row_attr = " bgcolor=\"#ffeeff\" valign=\"top\""
stand_row_attr = " bgcolor=\"#ffddff\" valign=\"top\""
stand_row_attr = " bgcolor=\"#cccccc\" valign=\"top\""

For compatibility with the standings table view of the previous
versions of ejudge, if neither the `stand_table_attr', nor
the `stand_row_attr' global configuration variables are set, the
`stand_row_attr' variable is set to " border=\"1\"".

A new global configuration variable `stand_page_table_attr' is
added to the `serve.cfg' configuration file. This variable
allows specifying attributes of the page links table on the
standings pages, if the standings splitting (`users_on_page') is
enabled.

A new global configuration variable `stand_page_row_attr' is
added to the `serve.cfg' configuration file. This variable
allows specifying row attributes of the page links table, if the
standings splitting (`users_on_page') is enabled. The
`stand_page_row_attr' variables must be defined 4 times, forming
an array of 4 attributes. The array is used as follows:
stand_page_row_attr[0] - the attribute of the first row: page numbers,
stand_page_row_attr[1] - the attribute of the seconds row: place,
stand_page_row_attr[2] - the attribute of the third row: the
number of solved problems (the score for MOSCOW contests);
stand_page_row_attr[3] - the attribute of the fourth row: the
score for KIROV contests, the penalty for ACM, MOSCOW contests.
Example of usage:
stand_page_row_attr = " bgcolor=\"#ccddcc\" valign=\"top\" align=\"center\""
stand_page_row_attr = " bgcolor=\"#ccddcc\" valign=\"top\""
stand_page_row_attr = " bgcolor=\"#ccddcc\" valign=\"top\""
stand_page_row_attr = " bgcolor=\"#ccddcc\" valign=\"top\""

A new global configuration variable `stand_page_col_attr' is
added to the `serve.cfg' configuration file. This variable
allows specifying attributes of the page links table columns, if
the standings splitting is enabled (`users_on_page'). The
`stand_page_col_attr' variable must be defined 2 times, forming
an array of 2 attributes. The array is used as follows:
stand_page_col_attr[0] - the attribute of the first column (the
row names),
stand_page_col_attr[1] - the attribute of the other columns
(pages) of the table. Example of usage:
stand_page_col_attr = ""
stand_page_col_attr = " width=\"60\""

A new global configuration variable `stand_page_cur_attr' is
added to the `serve.cfg' configuration file. This variable
allows specifying the attribute of the "Page N of M." text,
which is displayed on the standings page when the standings
splitting is enabled (`users_on_page').

The running real time for each test is displayed on the
participant's testing protocol.

userlist
--------
Support for the `phone' field of the user and the member
information of the user database is changed. In the previous
version the <phone> was a nested element for the <phones>
element, but the <phones> element was not used and its editing
was not supported. Now the <phones> element is removed, <phone>
is a plain string, editing of the <phone> element is supported
by all the ejudge programs.

userlist-server
---------------
A bug with incorrect removal of cookies upon password change is
fixed.

Editing of the <phone> field is supported.

The authentification policy is changed for the `team'
CGI-program. Now, if the `disable_team_password' flag is set for
the contest, only the registration password (the
`register_password' field) is checked, and if the
`disable_team_password' flag is not set, only the team password
(the `team_password' field) is checked, and the registration
password is ignored. In the previous version the both passwords
were checked and any of two was accepted.

This change may result in incompatibilities with previous
versions: the participants will be unable to log in to a
contest, if the `disable_team_password' flag was set (or unset)
incorrectly for this contest. Only participants, which changed
their passwords using the `team' interface are affected. To
resolve this problem, the contest administrator should fix the
corresponding fields of the user information manually (for
example, by copying the team password to the registration
password using the `o' command of the `edit-userlist' program).

New commands for manipulation with user passwords are added:
generation of a random password and copying of one password into
another password. See 'o', 'y' commands of the `edit-userlist'
program.

register,userlist-server
------------------------
After registration of a new user, the email sending status is
checked. If e-mail sending failed, the user is notified and
asked to register again.

The `register' CGI program handles the new registration error
code and produces a diagnostic message.

super-serve
-----------
Support for contests with variant problems is improved. The link
to the variant table editing page is added to the contest
settings page header. The standard save buttons are added to the
top of the variant table editing page. A bug regarding incorrect
variant change is fixed.

serve-control, super-serve
--------------------------
Editing of the new elements of the XML contest configuration file
is supported: <user_name_comment>, <allowed_languages>,
DISABLE_MEMBER_DELETE.

Editing of the global configuration variable `users_on_page' is
supported.

Editing of the new XML contest configuration file elemens
<users_table_format>, <users_table_format_en>,
<users_table_legend>, <users_table_legend_en> is supported.

Editing of the new global configuration variable
`stand_show_att_num' is supported.

Editing of the new global configuration variable
`stand_sort_by_solved' is supported.

Editing of the new language configuration variable
`lang_time_adj' is supported. During editing all time
adjustments for all languages are written in one string and are
separated with spaces, for example:
dcc=1 java=10

Editing of the new global configuration variable
`disable_submit_after_ok' is supported.

Editing of the new global configuration variables
`stand_page_table_attr', `stand_page_cur_attr' is supported.

Editing of the new global configuration variables
`stand_row_attr', `stand_page_row_attr', `stand_page_col_attr'
is supported. The values of the variables must be written in one
string with spaces sepating the values. The values must be
enclosed in ", and the " character must be properly escaped
inside. 

A bug is fixed, when the first test was incorrectly removed if
the `super-serve' program had not enough permissions to write to
test files during execution of the "Check contest settings"
command.

When a new contest is created, the `serve.cfg' configuration
file is correctly put under version control.

run
---
A bug is fixed regarding support for standard checkers for
variant problems.

If the `run' program works in unmanaged mode, the forced QUIT
packed are ignored (these packets are written by the `serve'
program to the exchange directory as a result of the "Reload
server" command). In the previous version, the `run' aborted.

The run control packet contains a new field `time_limit_adj',
which contains the time limit adjustment for this run. This
field is handled by the `run' program. The time limit adjustment
must be > 0 and <= 100 (see also `lang_time_adj' variable).

register
--------
Editing of the `phone' field is supported in the registration
form. The new contest XML configuration elements
<user_name_comment>, <allowed_languages>, and
DISABLE_MEMBER_DELETE flag are supported. The registration form
is simplified due to removal of unused fields (show_email,
show_login, use_cookies_default).

edit-userlist
-------------
The `phone' field editing is supported.

A new command `t' (Toggle) is added to the users and contests
menus. This command toggles the selection flag for each line of
the menu (i.e. for each user or contest). If no line was
previously selected, all lines are selected as the result of
operation. A new command (`0') (Clear) is supported, which
clears all the selection flags.

Selection of several contests is supported. The selection
commands `:', `t', `0' are supported in the contests menus.

A user may be registered to a selected set of the contests with a
single operation. A selected set of users may be registered to a
selected set of the contests with a signle operation.

A new command `f' is added to the list of users, registered for
a contest menu. This command allows setting or resetting certain
user information fields. The following fields may be reset:
Read-only, Never-clean, Location. The following fields may be
set (to the `true' value): Read-only, Never-clean. The `t'
command may be applied either to a single user, or to a group of
users.

Two new commands `o' and `y' are supported in the user
information editing screen. These commands can be applied to
passwords:
  `o' - generate a new random password. The cursor must be
        located either on the registration password field, or on
        the team password field.
  `y' - copy the current password to another passord. If the
        cursor is located on the registration password, it is
        copied to the team password and vice versa, if the
        cursor is located on the team password, it is copied to
        the registration password.

users,userlist-server
---------------------
The new configuration elements <users_table_format>,
<users_table_format_en>, <users_table_legend>,
<users_table_legend_en> are supportd, so the view of the table
of the registered uses may be changed (see above).

The following format conversions are supported in the table
format specification:
%Ui	the user identifier (id)
%Un	the user name (name)
%Ul	the user login (login)
%Ue	the email address (email)
%Uz	the registration passwords (if not changed by the user)
%UZ	the team password (if not changed by the user)
%Uc	the city (city)
%UC	the city (English) (city_en)
%Uo	the country (country)
%UO	the country (English) (country_en)
%Ut	the abbreviation of the institution name (inst_short)
%UT	the abbreviation of the institution name (English) (inst_short_en)
%Uu	the institution (inst)
%UU	the institution (English) (inst_en)
%Uf	the abbreviation of the faculty name (fac_short)
%UF	the abbreviation of the faculty name (English) (fac_short_en)
%Ud	the faculty (fac)
%UD	the faculty (English) (fac_en)
%UL	the participant location (computer number) (location)
%Up	the printer for participant's solutions (printer_name)
%Uh	the participant's home page (homepage)
%UH	the phone (phone)
%UP	the programming languages (languages)

Also, using the format conversions %UM it is possible to print
the detailed information about the team members
%UMp	the information about the contestants
%UMr	the information about the reserves
%UMa	the information about the team advisors
%UMc	the information about the coaches
%UMg	the information about the guests
The member number is specified after the member type letter
using a decimal number starting from 1, for example
%UMp2 - the second contestant in the team, %UMc1 - the first
coach of the team.
Next, the field of the member info is specified:
f	the first name (firstname)
F	the first name (English) (firstname_en)
m	the middle name (middlename)
M	the middle name (English) (middlename_en)
s	the surname (surname)
S	the surname (English) (surname_en)
g	the group or the form (group)
G	the group or the form (English) (group_en)
e	email
h	the homepage (homepage)
o	the occupation (for coaches and advisors) (occupation)
O	the occupation (for coaches and advisors) (English) (occupation_en)
u	the institution (inst)
U	the institution (English) (inst_en)
t	the abbreviation of the institution name (inst_short)
T	the abbreviation of the institution name (English) (inst_short_en)
a	  (facshort)
A	  (English) (facshort_en)
d	the faculty (fac)
D	the faculty (English) (fac_en)
H	the phone
b	the status (student, school student, etc) (status)
B	the status (English) (status_en)
c	the course or grade number (grade)
C	the number of the participant in the team (number)
For example %UMp1s will be substituted with the surname of the
first participant in the team.

ejudge-setup
------------
When the `ejudge.xml' configuration file is generated, the
ejudge administrator is given the MASTER_LOGIN and the
JUDGE_LOGIN capability bits to be able to use the
`serve-control' CGI program.

Version 2.1.42 (20050930)
=========================
This version fixes some bugs if the installation process and
introduces some minor enhancements.

ejudge-setup
------------
The command of creation of the symlink to the serve-control CGI
program is added to the installation script generation code.

Makefile
--------
Handling of situation, when the localization utilities xgettext,
etc were not found during the ejudge configuration is improved.

userlist-server
---------------
All the user cookies are dropped when the password is changed.

super-serve,serve-control
-------------------------
Editing of the `checker_env' problem configuration variable is
supported.

The new standard checkers (see below) are supported.

When the content of the header and the footer files and the
start script is edited, it is automatically converted from the
DOS text format to the UNIX text format, because browsers send
the data in the DOS text format (i. e. with \r\n as line
terminators).

The `master' and `judge' CGI-programs are opened in a new
browser window when clicking on the corresponding links.

Editing of the `variant_num' problem configuration variable is
supported. Editing of the variant assingment table (variant map)
is supported. Checking of contest settings for variant problems
is supported.

libchecker
----------
New functions for comparing floating-point numbers are added.

int checker_eq_double(double v1, double v2, double eps);
int checker_eq_long_double(long double v1, long double v2, long double eps);
int checker_eq_float(float v1, float v2, float eps);

These functions compare two floating-point numbers v1 and v2 of
the corresponding types with the given precision eps. Special
values NaN, +Inf, -Inf are handled correctly. If the absolute
values of the numbers do not exceed 1, the absolute value of
their difference must be less than 2*eps, i.e.
|v1 - v2| < 2*eps. Else both numbers must have the same sign,
must have the exponents with difference <= 1, and then their
exponent are changed, so the both numbers fit into the [0,2)
interval, then the condition |v1 - v2| < 2*eps. Thus the eps
value determines how many matching decimal digits do the numbers
have.

Several new standard checkers are added:
cmp_float, cmp_double, cmp_long_double - compare the output of
the program being checked, which must be the only floating-point
number of the corresponding type, and the correct answers. The
floating-point comparison functions described above are used.
The eps parameter must be defined by the EPS environment
variable, which must be set using the `checker_env' problem
configuration variable.
cmp_bytes - compares the output of the program being checked and
the correct answer byte by byte.
cmp_int_seq, cmp_unsigned_int_seq, cmp_long_long_seq,
cmp_unsigned_long_long_seq - compare the sequence of the integer
numbers of the corresponding type in the output of the program
being tested and the correct answer. The checked output must
consist only of integer numbers separated with whitespace
characters. The total number of numbers and the numbers themself
in the output must match those in the correct answer.
cmp_double_seq, cmp_long_double_seq - compare the sequence of
the floating-point numbers of the corresponding type in the
output of the program being checked and in the correct answer.
The checked output must consist only of floating-point numbers
separated with whitespace characters. The total number of
numbers and the numbers themself in the output must match those
in the correct answer.

Version 2.1.41 (20050916)
=========================
This version fixes noticed bugs of the previous version and adds
some minor enhancements.

A new global configuration variable `cpu_bogomips' of the
`serve.cfg' file is added. The value of this variable is equal
to the processor speed, which is used to determine the time
limit for the problems. In the future this variable will be used
for automatic scaling of time-limits in case when the speed of
the testing computer processor differs significantly.

The processor's BogoMIPS value is available in the /proc/cpuinfo
file. When a new contest is created using the `serve-control'
CGI program, the `cpu_bogomips' variable is set automatically to
the speed of the server's processor.

team, master
------------
The "Problem status summary" table is printed on the team's
personal page. This table includes the current result of solving
and the gained score (if available) for each problem.

In the virtual contest mode the link to the problem statements
is removed from the team's table of contents at the top of the
page and moved to "Problem status summary" section. The link to
the problem statements is opened only when the virtual contest
is started by the team.

serve-control, super-serve
--------------------------
Noticed bugs in the contest settings editing code are fixed.

On the IP-address access list editing page the new operation of
copying existing IP-address access list from another contest or
another CGI program is supported.

Editing of the global variable `cpu_bogomips' is supported.

Editing of the problem variables `deadline', `start_date' is
supported.

Probe run of the `serve' contest server program is supported
(the "Do probe run" button on the "Contest details" page). The
`serve' output is then displayed on the HTML page. This feature
may be convenient for checking contest settings and debugging
serve.cfg configuration problems.

Adding of a new XML contest configuration file to the version
control system (VCS) is supported. In the previous version of
the ejudge the file should be added to the VCS manually.
Committing of the `serve.cfg' file to the version control system
is also supported, but this file has to be added to the VCS
manually.

Version 2.1.40 (20050902)
=========================
This version fixes several bugs of the previous versions.

Support for Version Control Systems (VCS) is implemented. When
an XML contest configuration file is changed by the
`serve-control' CGI-program, the updated file is committed to
the VCS. The directory with XML contest configuration files must
be under the VCS control. Two Version Control Systems are
supported: subversion and CVS. The VCS is detected automatically
depending on the name of the VCS directory: if in the contest
XML directory there exists `.svn' directory, subversion is used,
and if `CVS' directory exists, CVS is used.

Updated the link to the ejudge home page, which is always
printed on the bottom of ejudge-generated HTML pages. Now it is 
http://acm.msu.ru/ejudge.

New problem configuration variable `binary_input' is added to
the serve.cfg contest configuration file. If this variable is
set, the corresponding problem is assumed to have binary input
data, which are never automatically recoded. Automatic recoding
is possible if this configuration variable is not set in two
cases:
1) when an input file is being copied to the submitted program
working directory, if the corresponding tester has the `is_dos'
flag set. During copying unix-like line terminators \n are
replaced with dos-like line terminators \r\n.
2) when the "Check contest settings" command is performed in the
contest detailed information view page in the `serve-control'
CGI program. During this operation all \r characters are removed
from file, and \n is added to the end of file, if there was no
\n there.

The attribute "ssl" of the <ip> element is supported in the
`serve-control.xml' configuration file of the `serve-control'
CGI program. This attribute allows specifying whether the <ip>
element is applicable to HTTP connections, HTTPS connections, or
both. This attribute corresponds to the "ssl" attribute in the
contest.xml configuration file.

Version 2.1.39 (20050811)
=========================

Interactive editing of the contest settings and contest
configuration files is supported. Editing is performed using the
`serve-control' CGI program, which interacts with `super-serve'
contest manager, thus to enable contest editing both
`userlist-server' and `super-serve' programs must be running on
the server.

https protocol is fully supported. IP restriction rules of the
XML contest configuration file now allows specifying whether
this rule is applicable for https connections, http connections,
or both. Thus it is possible, for example, allow access from
limited number of IP-addresses using the http protocol and allow
access from arbitrary hosts using the https protocol.

Time limits with milliseconds precision are supported. The most
recent version of the reuse library (4.2.0) and special support
from the Linux kernel, as provided by the patch 2.4.31-cher2 are
required for this.

Support for detection of "Memory Limit Exceeded" testing error
is implemented. This error is detected, if the program being
tested attempts to increase its address space or stack size over
the limits, defined in the contest configuration file. Also the
most recent version of the reuse library (4.2.0) and special
support from the Linux kernel, as provided by the patch
2.4.31-cher2 are required for this.

contest.xml
-----------
A new attribute "ssl" is supported in the <ip> element. The
attribute may have the following values: "any" (default value,
if this attribute is omitted), "yes", "no". The attribute
defines the type of connection for this rule. If the attribute
is set to "yes", this rule applies only to https connections, if
the attribute is set to "no", the rule applies only to http
connections. The "any" value means, that the rule applies to all
types of connections.

Number "0" allowed as the IP-address. It means "any IP
address". For example, the following rules allow http
(nonencrypted) connections from the localhost only, but secure
https connections are allowed from arbitrary host.
<master_access default="deny">
  <ip allow="yes">127.</ip>
  <ip allow="yes" ssl="yes">0</ip>
</master_access>

The form "A.B.C.D/E" is allowed in the IP-address field of the
<ip> element. Here "E" is the number of bits in the network part
of the IP-address. This, "192.168.0." and "129.168.0.0/24" are
equivalent.

New capability bit EDIT_CONTEST is supported. If this bit is set
for a particular user, the user is allowed to edit contest
settings using the `serve-control' CGI program.

serve-control,super-serve
-------------------------
The `serve-control' contest management CGI-program and its
server part `super-serve' are basically completed. Its use is
now recommented for contest management. These programs also
support editing of contest configuration files (contest.xml,
serve.cfg) and creation of new contests from scratch and using
existing contests as template.

compile
-------
A memory leak is plugged, which occured each time, when a
compile request was processed.

The command line option `-E' (filtering the configuration file
through the external C preprocessor) is no longer supported.

serve,run
---------
The checksum (SHA1) of the test input data file and the correct
answer file for each test are stored in the run testing protocol
file. When these files are displayed the current checksum is
compared with the checksum as stored in the file, and the
warning is displayed in case of mismatch. The mismatch is
possible, for example, if the test data file or the correct
answer file were changed, but the submit was not rejudged.

edit-userlist
-------------
Selection/deselection of users is supported in the "View users"
screen. Selection/deselection is performed using ':' key. The
only command, which can be applied to the group of users is 'c'
command - registration of the selected users for a contest.

Mass creation of new users command is available in the "View
users" screen. The command is performed using the 'm' key.
A number of dialogs is then displayed. The dialogs are as
follows:
"Template for new logins?" - allows specifying a template for
the new logins. The template must contain the only %d format
specification (printf-style flag, width and precision
specification are allowed, e.g. %03d). This format specification
will be substituted with the number of the user.
"Template for passwords?" - allows specifying a template for the
passwords of the new users. The template must obey the same
rules, as new logins template.
"First number:" - the minimal number, which will be used in the
generated sequence of new logins and passwords.
"Last number:" - the maximal number, which will be used in the
generated sequence of new logins and passwords.
"Contest number:" - the contest number, on which all the newly
created users will be registered.

For example, if the login template is specified as "u2005%02d",
password template is specified as "pass%02d", the first number
is 1, and the last number is 50, then 50 new users will be
created with logins u200501...u200550 and passwords pass01...pass50.
The user id will be assigned for each user individually (the
first unused user id). Thus the user ids form increasing
sequence, but not necessarilly sequental.

ejudge-setup
------------
The element <super_serve_log> is defined in the generated
ejudge.xml file. This element is required for start of the
`super-serve' program.

serve
-----
New global configuration variable `stand_ignore_after' is
supported in the `serve.cfg' file. This variable allows setting
the date, after which the submits are not shown in the current
standings table. I.e. if a submit is received after the
specified data, it will be tested, the testing results will be
available for judges and the originator of this submit, but the
public version of the current standings table will not be
updated. The privileged current standings table will be, of
couse, updated. However, changes in statuses of submits before
this date will be reflected in the current standings table.
The data is specified in the standard format: 
YYYY/MM/DD HH:MM:SS

This variable is useful, if a contest should be opened for
additional unofficial submissions after the contest end to
allow participants to complete solutions of problems.

New global configuration variable `ignore_success_time' is
supported in the `serve.cfg' file. This variable works only in
the ACM contests. If this variable is set, the duration from the
start of the contest to the successful submit is not added
during calculation of penalty score for a problem. This variable
is useful for contests, where there is no partial solutions
(i.e. each problem is either solved, or not) and where the
contest duration is not meaningful.

serve-control,super-serve
-------------------------
New global configuration variable `secure_run' is supported in
the `serve.cfg' file. This variable is used only for interactive
editing of the contest configuration files with the
`serve-control' CGI-program. If this variable is set, the secure
execution of programs is enabled, and the generated `serve.cfg'
configuration file contains all necessary settings for the
Linux, Linux-shared and Java architectures.

serve,run
---------
New global configuration variable `enable_memory_limit_error' is
supported in the `serve.cfg' file. If this variable is set, the
support for detection of the "Memory Limit Exceeded" condition
is enabled for submits.

New tester configuration variable `enable_memory_limit_error' is
added. If this variable is set, the corresponding tester
supports detection of the "Memory Limit Exceeded" error during
testing. Not all testers may ever detect such error (for
example, DOS or Java may not). This variable should be set for
testers for the Linux and Linux-shared architectures (actually,
during initial contest setup using the `ejudge-setup' program,
or during editing of contest settings using `serve-control' CGI
program, this variable is set for these testers automatically). 
The variable must not be set for Java or DOS testers because the
corresponding virtual machines control the amount of allocated
memory using their own means.

Thus, detection of "Memory Limit Exceeded" error is activated
only if the `enable_memory_limit_error' global configuration
variable is set for the contest and only for testers for the
Linux and Linux-shared architectures (i. e. for gcc, g++, fpc,
dcc languages).

New problem configuration variable `time_limit_millis' is
added. This configuration variable allows setting of the problem
time limit with millisecond precision. If this variable is set,
the value of `time_limit' variable is ignored. Support for
millisecond time limits is works only if the latest (4.2.0)
version of the reuse library is used. If the linux kernel does
not support millisecond time limits, the reuse library will
emulate them using the standard second-precision time limits.

New problem configuration variable `check_cmd' is added. This
variable has exactly the same meaning as the the `check_cmd'
configuration variable of the tester section. This variable
allows specifying the template for the checker name for this
problem. Because in the current version of the ejudge the
checker does not depend on the architecture of the language
(e.g. submits on gcc, dcc and java are checked by the same
checker), the `check_cmd' variable was the same value for all
the testers, so it is reasonable to move it into the problem
section.

The `check_cmd' variable of the tester section is preserved for
compatibility, and has the priority over the `check_cmd'
variable of the problem section, however, its use is not
recommended, because editing of the contest configuration files
using the `serve-control' CGI program does not preserve
`check_cmd' variable in tester sections.

serve
-----
`-E' command line option is no longer supported. This option
allowed filtering the configuration file through external C
preprocessor. Now some sort of preprocessing is built-in, and
the external preprocessor is no longer needed.

Fixed a bug, when the audit record directory was created before
the directory in which it is located. Because of this the `serve'
program failed to start on a new contest.

run
---
`-E' command line option is no longer supported. This option
allowed filtering the configuration file through external C
preprocessor. Now some sort of preprocessing is built-in, and
the external preprocessor is no longer needed.

When the `run' program is started by the `super-serve' program,
the inactivity timeout is counted starting from the end of
testing of the program. In the previous versions, the inactivity
timeout was counted from the beginning of testing, and if
testing took too long (longer, than inactivity timeout), the
`run' program exited right after finishing testing of this
submit even if there are other submits in the run queue.

In the ACM contest mode it is no longer required, that the sum
of all test scores is less, than the full score for the
problem. Since the default problem score is 25, the default test
score is 1, if some problem had more, that 25 test, explicit
specification of the `full_score' or `test_score' configuration
variable was necessary in the problem specification section. Now
this hack is not required. However, in the KIROV and OLYMPIAD
contest the total score for all tests is still checked
against the full score for each problem.

serve
-----
A bug is fixed in handling of the "Reset Contest" command.
The bug was in the incorrect generation of the run database
file, after which the `serve' program refused to work with this
file.

serve,master
------------
Changing contest duration from limited to unlimited and back is
supported in the `master' CGI program. The unlimited duration is
specified as "0".

run
---
For each supported language LANG the version script LANG-version
is generated along with the compilation script LANG. For
example, for the gcc language, gcc and gcc-version scripts are
generated. The version script prints the version of its language
to the standard output. Also, each version script supports two
options:
-f	Print the language name and the language version to the
	standard output.
-p	Print the path to the compiler to the standard output.

master,judge,team,serve-control,register,users
----------------------------------------------
The https (secure http) protocol is supported. The web server
must be configured to support https, of course.

master,judge
------------
On the main page of the `master' CGI program the total number of
submits, which are currently being compiled or tested is
displayed.

The testing protocol viewing screen includes information about
real time elapsed for each test, if this information is
available in the XML testing protocol.

In the contests with full_archive mode enabled, if the checksum
of the input file or the correct answer file does not match the
checksum stored in the testing report file, a warning is
reported.

serve-cmd
---------
New commands are supported:
serve-cmd CONTEST-ID dump-problems SESSION-ID-FILE
	Prints information about the problems of the specified
	contest in the CSV format (fields are separated with ';').
	[0] - id
	[1] - short_name
	[2] - long_name
serve-cmd CONTEST-ID dump-standings SESSION-ID-FILE
	Prints the current standings table in the CSV-format.
	The full version of the standings table (available from
	`judge' or `master' CGI-programs for privileged users)
	is printed. This command is equivalent to the
	"Dump standings" command of the `master' CGI program.
serve-cmd CONTEST-ID dump-all-users SESSION-ID-FILE
	Prints the user database in the CSV format. The contest
	number is not used and may be arbitrary.
serve-cmd CONTEST-ID get-contest-name SESSION-ID-FILE
	Prints the name of the specified contest.
serve-cmd CONTEST-ID get-contest-type SESSION-ID-FILE
	Prints the type of the specified contest. One of the
	following strings is printed to the standard output:
	acm, kirov, olympiad.


testlib
-------
Added a testlib version for delphi/kylix. The fpc version of
testlib is now installed to ${prefix}/share/ejudge/testlib/fpc,
the delphi version is installed to ${prefix}/share/ejudge/testlib/delphi.
If support for the corresponding languages was enabled during
configuration of the ejudge system, the testlib files are
compiled during installation.

Path to the testlib library for the corresponding language is
passed in the command line of the compiler when "Check
contest settings" command of the `serve-control' CGI program is
performed. It means, that the testlib files are not required in
the checker directory of contests.

Version 2.1.38 (20050607)
=========================

libchecker
----------
The checker programs do not terminate with the "Check Failed"
error, if they are given more command line parameters, than are
required. The extra parameters are ignored. This enables use of
the standard checkers (for example, cmp_int) for checking
problems, which have tests with .inf files.

run,serve
---------
The interface between the `run' and the `serve' programs is
reworked again. The `run' program always generates the testing
protocol in the XML-based format. Generation of the
HTML-representation of the testing protocol is now performed by
the `serve' contest server. Because of this there is no need in
two separate protocols: master's and team's. Both may be
generated from the XML testing protocol. The XML testing
protocols are stored in the subdirectories of the
"${contest_root}/var/archive/xmlreport" directory. Backward
compatibility with previous versions of the ejudge is provided:
if for some submit there is no XML testing protocol, the plain
text or HTML testing protocols are used (generated by the
previous versions of the ejudge tools).

Because the `run' program always generate the testing protocol
in the XML format, the `html_report' global configuration
variable is no longer meaningful. This variable is preserved for
compatibility with previous versions, but its value is ignored.

Added possibility of storing the full program's output in the
contest archive. By default the input test data, the program's
output, the checker's output for each test are added directly to
the testing protocol. However, the maximal file size and the
maximal string length of such file are limited (see the
max_file_length and max_line_length global configuration
variables). If the actual file size is greater than the file
size limit, the file content is not added to the protocol, but a
short diagnostic message is added instead. This version of the
ejudge system supports `enable_full_archive' global
configuration variable. If this variable is set to 1, the output
of the program being tested is not limited. The output is stored
in a separate file rather than in the testing protocol. The
testing protocol does not contain neither input, nor output data
of the program being tested, with the exception of the command
line parameters, if such are provided. The program output and
the checker program output are stored in a separate file in a
special archive format, which is currently a custom format, not
compatible with any existing archiver. The archive contains some
file information and the file data compressed with the gzip
algorithm. The archive files are stored in subdirectories of the
"${contest_root}/var/archive/output" directory.

serve,master,judge,team
-----------------------
Since in the full archive mode the testing protocol does not
contain the input data and the output data, added the
possibility of viewing archive input and output files. The
output file, the standard error stream, the checker output for
each test are taken from the archive file. The input file, the
correct answer file (if provided for a problem), the info file
(if provided) are taken from the test directories for the
problem. It is possible, that the test directories contain
different tests from those used for actual testing (for example,
if the tests were updated from the time of testing). The current
version of the ejudge does not check correspondence between file
versions.

serve
-----
An audit log is kept for each submit. The audit log contains the
information about all operations with the current run. The audit
log is never overwritten or edited, new entries are only
appended to the end of the log. The audit log files are kept in
subdirectories of the "${contest_root}/var/archive/audit"
directory.

serve,master
------------
Viewing of the audit log is supported. In order for a user to
view audit log, the user must have the CONTROL_CONTEST bit set
for the current contest.

serve,master,judge,team
-----------------------
Support for the obsoleted session modes is removed. The
obsoleted session modes are login/password in the HTML form,
cookie, session id in the HTML form. These session modes are not
used for a long time, but were supported in the code. Their
removal considerably simplified the source code. The URLs are
also simplified, because the sid_mode CGI parameter is no longer
required.

userlist-server
---------------
The program does not crash on login of a user, which has no
password set (i.e. the `register_password' entry is completely
missing).

Version 2.1.37 (20050422)
=========================
This release fixes certain compilation problems on the Win32
platform, and some documentation bugs.

Added support for "bonuses" in the contests using the KIROV
scoring system. Bonus score is given to the players, who solved
the given problem first.

The directory structure of the serve<->compile and the
serve<->run spool directories is changed. The new structure is
not compatible to the directory structure of the previous
version of the ejudge system.

INSTALL,INSTALL.RUS
-------------------
All the new options of the configure script are described. Some
errors are fixed.

serve,compile,run,userlist-server,super-serve
---------------------------------------------
All the programs refuse to start if being run under the `root'
(uid 0) user. The previous versions of the ejudge did not
support running under root anyway, but did not report this properly.

configure
---------
The Mono (www.mono-project.com) framework is supported. The Mono
Project is a free implementation of the .NET framework for a
variety of platforms. The C# compiler (mcs) and Visual Basic
Compiler (mbas) are supported under the Mono framework. The two
new options of the configure script: --with-mcs and --with-mbas
may be used to specify paths to the corresponding compilers
explicitly.

Note, that the current version of the Mono framework does not
support security policies. Thus the programs in the MSIL
(i.e. compiled by mcs or mbas compilers) are started with all
the capabilities and permissions of the user, who started the
`run' program. Because of this use of these languages in
contests with untrusted participants is not secure and is not
recommended.

Checking of the `libcap' library and the
CAP_SYS_OPERATIONS-patched Linux kernel is improved. If a sample
program, which uses the libcap library and CAP_SYS_OPERATIONS
bit can be compiled, but the CAP_SYS_OPERATIONS bit is not
effective when this program is executed, the configure script
issues a warning after all the configure tests are done.

Fixed invalid setting of the CONF_HAS_LIBCAP macro in the
config.h. This macros was set to 1 always in the previous version.

The configure checks, that the operating system has the
`uudecode' program installed, and if this program is not
installed, a warning is issued after all the configure tests are
done.

ejudge-setup
------------
In the configuration .cfg files generated by the system the '#'
is used as comment character instead of ';'.

Added support for the C# and Visual Basic compilers using the
Mono framework - see the comment above. However, even if these
compilers are detected in the system, the serve.cfg
configuration file for the test contest 1 is generated with
these languages disabled for use, i.e. the language
configuration sections of these languages has "disabled = 1"
directive. In order to activate these languages one has to
change the serve.cfg configuration file manually.

The contest name in russian is replaced with the English "Test
contest" in order to avoid problems with non-koi8 charsets.

The ejudge install script, which is generated by the program
uses the name of the uudecode program as specified in the
config.h.

serve
-----
A new problem configuration variable `score_bonus' is supported
in the contest configuration file `serve.cfg'. This variable
allows specifying the bonus score given to successful solution
of the specified problem. The variable is only effective for the
contests using the KIROV score system. The value of the variable
is a sequence of integer numbers, which may be either positive,
or negative. The numbers are separated with whitespaces. For
example,
score_bonus = "10 5"
In this case bonus score is given for the solutions of the
corresponding problem according to the following rules:
  - the first full solution (i.e. the solution with the OK
    status) of this problem is given +10 points to the score
    given after all the penalty calculation);
  - the second full solution is given +5 points;
  - the third and the following solutions are given no bonus
    points.

The following runs are ignored in calculation of the number of
the full solution of some problem:
  - runs of those participants, who have already solved this
    problem. For example, if a participant gets +10 points for
    a full solution, the second full solution gets no bonus
    points at all and the second full solution is ignored in
    calculation of the full solution number.
  - runs with the `hidden' flag set. These runs normally are
    submitted by the privileged `judge' and `master' programs
    and thus are ignored.
  - runs of invisible or banned users. The invisible users are
    normally privileged users, which are not displayed in the
    contest standings.

serve
-----
A new `disable_sound' global configuration variable is added to
the server configuration file `serve.cfg'. If this variable is
set to 1, no sound notifications are produced during testing
even if the sound notifications are enabled in the configuration
file. This variable may be used in situations, when one instance
of the `run' program tests the runs of several different
contests simultaneously (for example, the main contest and the
parallel internet contest). For the main contest the sound
notifications are enabled, but for the internet contest they
should be disabled. In this case this variable should be set in
the configuration file of the internet contest.

Version 2.1.36 (20050402)
=========================
This version fixes several severe bugs in the `userlist-server'
and `serve' programs. Upgrade to this version is recommented.

The `compile' and `run' programs can again be built on the Win32
platform. The Cygwin suite is necessary for compiling on Win32,
however Cygwin DLLs are not required for further running of the
programs. Only Windows 2000 or above is supported. Windows 95,
98, ME are not supported.

For compilation on the Win32 platform the latest version of the
reuse library (4.0.1) is required. However, use of the latest
version is also recommented for the Linux version of the ejudge
system.

Many changes are introduced in handling of contests in the
OLYMPIAD scoring system mode.

serve
-----
Two new submit statuses are added to the run database: 
"Memory Limit" (RUN_MEM_LIMIT_ERR) and "Security Error"
(RUN_SECURITY_ERR). They are handled everywhere in the ejudge
system as like "Run-time error" (RUN_RUN_TIME_ERR) status. The
new statuses may be used for more precise specification of a
run-time error.

Although the new two statuses were added to the run database,
the `run' program currently does not support detection of these
erors. This due to impossibility of reliable detection of these
errors on Linux. The new statuses may be set only manually
during editing of the run database.

A new submit status "Pending" (RUN_PENDING) is added. This
status is set on a submit, if the submit has been received by
the serve program, but immediate testing of the submit is not
available due to some reasons. For example, immediate may be
disabled because of the problem or language configuration
variables `disable_testing' or `disable_auto_testing' are set,
or if testing was suspended in the contest by the "Suspend
testing" administrator command (available via `master' CGI
program). In the previous versions of the ejudge system, such a
submit got "Accepted for Testing" (RUN_ACCEPTED) status.
Unfortunately, the same RUN_ACCEPTED status is used for contests
in the OLYMPIAD scoring system during the preliminary testing
stage. So these two uses of the RUN_ACCEPTED status are
separated and the new RUN_PENDING status is introduced.

In the run filter expressions the new statuses are expressed as
follows:
PD	RUN_PENDING
ML	RUN_MEM_LIMIT_ERR
SE	RUN_SECURITY_ERR

compile
-------
The program may be built on the Win32 plaform (see above).
However, this version of the program did not yet get intensive
testing on Win32 platform, so the Win32 support should be
considered as being in alpha stage.

compile, serve
--------------
The format of the control packets, which are used to pass the
compile requests from the `serve' to the `compile' programs and
compile results from the `compile' to the `serve' is reworked.
Now the compile request and reply packets use binary formats.
Also the packets include timestamps, which are used for
reporting of verbose statistics of the testing of each submit.

configure
---------
The Win32 platform is supported (currently only Cygwin, but with
-mno-cygwin option, so the resulting binaries are Cygwin
independent).

edit-userlist
-------------
Added partial support for operations on a group of users. When
the list of users registered for some contest is viewed, it is
possible to select or deselect any user using the `:' command.
If several users are selected, the `r' command (change the
registration status), the 'd' command (delete the registration),
the 'i' command (change the invisibility status), the 'b'
command (change the ban status), the 'l' command (change the
lock status) are performed on all the selected users. If no one
user is selected, these command are performed on the current
user, as in the previous version.

A new command 'c' is supported during viewing users regisered
for some contest. This command allows registering one user or
several users for a different contest. The 'c' and the ':'
commands allows quick registration of all the participants of
some contest for another contest. This may be used, for example,
when a training session is prepared for all the participants of
some contest, or when a virtual contest based on some real
contest is prepared, etc.

serve
-----
Diagnostics of invalid filter expressions is improved. Now, if a
user uses invalid keyword, the whole keyword is reported as
invalid. For example, if a user uses `problem' instead of
`prob', a error about invalid keyword `problem' is reported
instead of reporting three errors about invalid characters 'l',
'e', and 'm'.

A serious bug is fixed, which manifested itself when invalid
filter expression was entered. In this case a block of heap
memory was allocated, which size was specified by an unitialized
variable, and this block was never freed. This bug may cause
abnormal termination of the serve program due to out of memory
condition and other subsequences.

serve
-----
Removed a limitation, that the total score gained for a submit
(i.e. testing score with all the additional factors like timing
penalties etc) could not exceed the full score of the problem as
specified by the `full_score' problem configuration variable.

The view of the current standings table is changed for contests
in the OLYMPIAD scoring system in the preliminary testing mode.
In this mode each of the preliminary tests is scored as 1 point
regardless of its score in the configuration file (usually, 0
points). The problem is marked as accepted (i.e. in bold font),
if it passes all the preliminary tests. The participants are
arranged according to the number of accepted problems, and then
according to the total score.

In the final testing mode of the OLYMPIAD contest the view of
the current standings table is not changed and is the same, as
the view of the table of the current standings in the KIROV
contest mode.

serve, team
-----------
The `team' CGI program also supports displaying the testing
protocol in HTML format (see the `html_report' global
configuration variable introduced in the previous version of the
ejudge system). Although only judge protocols can be generated
in the HTML format, a user views judge protocols, if the
`team_show_judge_report' configuration variable is set in the
contest configuration file.

run
---
The program can be built on the Win32 platform (see above),
however, the Win32 version did not get much testing, so the
Win32 support should be considered as being in alpha stage.

serve,run
---------
The control packet format, which is used to pass testing
requests from the `serve' to the `run' programs and testing
results from the `run' to the `serve' is reimplemented. Now the
packets use binary format. Moreover, the packets now include
several timestamp fields, which are used to report statistics
about testing of a submit.

run
---
The judge's testing protocol now includes timing statistics
about all stages of passing of the submit through all the
compilation and running stages. The astronomic time of starting
and finishing testing is reporting as well as duration of being
in the compile queue, compilation, being in the compile result
queue, being in the run queue, running. The statistics is
printed by the run program, so the duration of being in the run
result queue is not available.

serve, master, judge
--------------------
A new "Full rejudge" command is supported for the contests in
the OLYMPIAD scoring system in the preliminary testing mode.
This command performs full testing of the specified submit as if
the contest was in the final testing mode. The command may be
used, when the full judging of some submit (for example, some
judge's solution) is required in the accepting mode.

serve
-----
Error handling is improved for errors, which may appear during
receiving of a new submit from an ordinary or privileged user. 
If writing of the submit source code to the archive is failed
the submit is removed from the run database. This fixes a
long-standing bug, which manifested itself when there was no
space on the disk for writing a submit source code. In this case
the source code was lost, but an entry in the run database
remained and had the "Available" status.

A new field `judge_id' is added to the run database. This field
may take values from 0 to 65535. When a submit is sent to
judging or rejudging, the judging request is assigned an unique
judge_id, which is stored in the run database. When the `serve'
program receives a packet with compilation or testing results,
it checks the judge_id as specified in the packet agains the
judge_id as stored in the run database for this run. If the
judge_id do not match, the received packet is ignored.

This solves a problem when a submit being judged is rejudged.
In this case the older judge_id in the run database is replaced
with new judge_id, so the results of the older judging are
ignored. This could not be guaranteed in the previous versions
of the ejudge, because the older judging request could be
completed first and change the submit status to the one
specified in the run reply packet. The newer judging results
then were ignored.

The judge_id field occupies 2 bytes in the runlog entry
structure, so the total size of all the used fields is now 64
bytes, and there is no reserved space remaining in the runlog
entry. The size of the runlog entry is 64 bytes for a long time
from the ancient text format of the runlog. Thus any extension
of the runlog format will require major and incompatible change
of the runlog format (for example, using 128-bytes runlog
entries).

A new format conversion specifier `%M1' is added, which outputs
(as string) the value of the `extra1' field of the user
information entry. The `extra1' field is not available for
editing neither by ordinary user nor by the ejudge
administrator. The current version of the `userlist-server'
program uses this field when passes the information about the
users registered for a contest to the `serve' contest server of
this contest. The `userlist-server' program stores the value of
the `grade' field of the first participant of the team to the
`extra1' field. In the individual contests this field contains
the grade (year of study) of the contest participant. So, the
`%M1' format specifier may be used to report the grade of the
contest participant of the individual contest.

userlist-server
---------------
A bug of dereferencing the NULL pointer was fixed. The bug
manifested itself, when a new user was registered and no contest
was specified, i.e. URL without contest_id parameter was used.
For example, using the URL http://acm.msu.ru/cgi-bin/register
triggered this bug, but using the URL
http://acm.msu.ru/cgi-bin/register?contest_id=83 did not.
The bug was introduced in the previous version, when the
registration e-mail templates became supported.

super-serve
-----------
All the UNIX sockets, which are used to control the serve
programs of all the managed contests, that are created upon
start of the `super-serve' program, are deleted upon exit.

Version 2.1.35 (20050118)
=========================
This version fixes some minor bugs and adds some new features.

userlist-server
---------------
Empty passwords are allowed in the <password> and the
<team_password> elements of the XML user database. In the
previous version empty passwords caused the XML validation error,
and such user database could not be loaded.

However, empty passwords are normally not allowed. An attempt to
set an empty password (i.e. a password equal to the empty
string) using the `edit-userlist' program now causes the
"Invalid password" error. Empty passwords are also not allowed
when a user logging into the system.

serve
-----
New language configuration variables `disable_testing' and
`disable_auto_testing' of the `serve.cfg' contest configuration
file are added. These variable has the same semantics, as the
corresponding variables of the problem configuration section.
E.g. the `disable_testing' disables any testing of a submit in
the given language, and the `disable_auto_testing' prevents
automatic testing of a submit in the given language as soon as
the submit is accepted. Such submits receive the "Accepted for
testing" status and can be judged by an explicit judging command
later by the contest administrator.

serve
-----
A new problem configuration variable `disqualified_penalty' is
added to the `serve.cfg' contest configuration file. This
variable allows specifying a penalty for a disqualified run.
Starting from the current version of the ejudge system
disqualified runs are counted separately from ordinary runs and
also penalized separately. By default the value of the
`disqualified_penalty' configuration variable is equal to the
value of the `run_penalty', i.e. the disqualified runs are
penalized as ordinary runs.

This, in the current version of the ejudge system the total
score of a run in the KIROV or OLYMPIAD contest scoring system
is calculated using the following expression:
S = I * M - A * P + D + J - B * Q
The `S', `I', `M', `A', `P', `J' variables are described below.
The `B' is the total number of disqualified runs of the current
user for the current problem, `Q' is the penalilty for a
disqualified run as defined by the `disqualified_penalty'
problem configuration variable.

In the KIROV or OLYMPIAD contest score system the score
calculation formula in the "score" column is changed
accordingly. The full form of the formula is as follows:
S = I [ * M ] [ - A * P ] [ +/- D ] [ +/- J ] [ - B * Q ]
if M == 1, then the corresponding part of the formula is not
shown. The same rule applies for A * P == 0, D == 0, J == 0,
B * Q == 0.

Two fields are added to the run log in the CSV format as printed
by the
serve-cmd dump-master-runs
command line program:
          [27] disq_attempts
          [28] disq_penalty

serve
-----
The source code lines are numbered in the "View source" display
of a run in the `judge' or `master' CGI programs.

serve,master,judge
------------------
The "Reset button" of the runlog filter expression now resets
only the runlog filter expression and the number of the first
and the last submit number. The messages list view parameters
are no longer reset.

A new parameter added to the message view controls. This
parameter may be chosen using a pull-down menu available to the
left of the number of the first viewed clar. The parameter
allows choosing the messages view mode: either all the messages
are shown, or only unanswered messages are shown. The default
value for the `judge' CGI program is to view only unanswered
messages, and the default value for the `master' CGI program is
to view all the messages.

A new button "Reset filter" is added to reset the message list
view parameters. This button is located right to the "View"
button of the messages display.

contest.xml
-----------     
A new element <register_email_file> is added. This element
allows specifying a file with a registration e-mail letter
template. This e-mail letter is sent to a user after successful
registration. The value of the <register_email_file> element can
be either absolute path, or relative path. In the latter case
the absolute path is calculated relative to the contest
configuration files directory as specified by the values
<root_dir> or <conf_dir> elements. In the value of the
<register_email_file> element certain format specifiers are
allowed. For example, %Vl is substituted with the number of the
current language environment (0 - English, 1 - Russian). An
example of the element value is as follows:
<register_email_file>email_tmpl_%Vl.txt</register_email_file>
If the Russian is chosen as the interface language, the
`email_tmpl_1.txt' file in the conf directory (<root_dir>/conf)
will be used, and if the English is chosen as the interface
language, the `email_tmpl_0.txt' file is used. If the message
template file for the current language environment does not
exist, the template file for the language environment 0 is used,
and if this file does not exist, the default message template is
used in the current language environment. If the value of the
<register_email_file> is not set, the default message template
is always used.

Certain format specifiers are allowed in the text of the message
template. Such format specifiers are substituted with the values
of the new user. The valid format specifiers are listed below:
%Vu - the URL to complete the registration
%Vl - the language environment number (0 - English, 1 - Russian)
%Ul - the user login
%Ui - the user identifier
%Un - the user name (not set at this stage of registration)
%Ue - the e-mail specifyed by user during registration
%Uz - the automatically generated password for the user

An example of a registration message template is shown below:
--------
Hello,

Somebody (probably you) have specified this e-mail address (%Ue)
when registering an account on the Moscow Programming Contests
Server.

To confirm registration, you should enter the provided login
and password on the login page of the server at the
following url: %Vu.

Note, that if you do not do this in 24 hours from the moment
of sending this letter, registration will be void.

login:    %Ul
password: %Uz

Regards
The ejudge contest administration system
--------

serve-cmd,serve
---------------
A new command is implemented, which checks whether there are
runs in the stages of compilation or testing in the contest at
the current time. This command is currently available using the
`serve-cmd' program:
serve-cmd CONTEST-ID has-transient-runs SESSION-ID-FILE
If there are such runs, the program exit code is 2, and if there
are no such runs, the exit code is 0. Also the exit code of 1 is
produced in case of other execution error.

serve-cmd
---------
A few new commands of contest control from the command line are
implemented in the `serve-cmd' program.
serve-cmd CONTEST-ID suspend-testing SESSION-ID-FILE
	This command suspends testing of all new runs. The runs
        get "Accepted for testing" (RUN_ACCEPTED) state and are
        not compiled and tested automatically.
serve-cmd CONTEST-ID resume-testing SESSION-ID-FILE
	This command cancels the effect of the previous command,
        so all new runs will be compiled and tested
        automatically.
serve-cmd CONTEST-ID judge-suspended-runs SESSION-ID-FILE
	This command sends for compilation and testing all runs,
        that have the "Accepted for testing" (RUN_ACCEPTED)
        status.

These commands may be used for correct import of an external XML
run log file into the running contest. As it is mentioned below,
the `import-xml-runs' command does not work, when there are runs
in the compilation or testing stage. So, the algorithm of import
of an XML runlog into the working contest can be specified as
follows:
	serve-cmd CONTEST-ID suspend-testing SESSION-ID-FILE
	serve-cmd CONTEST-ID has-transient-runs SESSION-ID-FILE
	while [ "$?" = 2 ]
	do
                sleep 1
		serve-cmd CONTEST-ID has-transient-runs SESSION-ID-FILE
	done
        serve-cmd CONTEST-ID import-xml-runs SESSION-ID-FILE RUNLOG-FILE
        serve-cmd CONTEST-ID resume-testing SESSION-ID-FILE
        serve-cmd CONTEST-ID judge-suspended-runs SESSION-ID-FILE
Note, that there is no error checking code in this algorithm.

serve-cmd CONTEST-ID full-import-xml-runs SESSION-ID-FILE XML-FILE1 ...
	This command implements the full algorithm of import of
	external XML run log into the running contest, as
	described above. Several file paths may be specified as
	arguments of the command, and all these files will be
	imported. The command returns 0 exit code, when all the
	specified XML files are successfully imported, 1, when
	no files are imported due to some error, 2, when no
	files are imported due to user interrupt, 3, when some
	files are imported, and some files are not due to errors
	in these files. This command restores the state of the
	running contest correctly in case of user interrupt.

serve
-----
New features added to the filter expressions. The following new
primary expressions are supported:
userinvisible [ ( RUN-ID ) ]
	Evaluates to the boolean value of TRUE, if the run
        RUN-ID is submitted by a user, who has the "invisible"
        status in the current contest. Otherwise the expression
        evaluates to FALSE. If the RUN-ID is omitted, the
        current run is taken.
userbanned [ ( RUN-ID ) ]
	Evaluates to the boolean value of TRUE, if the run
        RUN-ID is submitted by a user, who has the "banned"
        status in the current contest. Otherwise the expression
        evaluates to FALSE. If the RUN-ID is omitted, the
        current run is taken.
userlocked [ ( RUN-ID ) ]
	Evaluates to the boolean value of TRUE, if the run
        RUN-ID is submitted by a user, who has the "locked"
        status in the current contest. Otherwise the expression
        evaluates to FALSE. If the RUN-ID is omitted, the
        current run is taken.
curuserinvisible
        Evaluates to the boolean value of TRUE, if the current
        run is submitted by a user, who has the "invisible"
        status in the current contest. Otherwise the expression
        evaluates to FALSE.
curuserbanned
        Evaluates to the boolean value of TRUE, if the current
        run is submitted by a user, who has the "banned" status
        in the current contest. Otherwise the expression
        evaluates to FALSE.
curuserlocked
        Evaluates to the boolean value of TRUE, if the current
        run is submitted by a user, who has the "locked" status
        in the current contest. Otherwise the expression
        evaluates to FALSE.
New primary expressions can be used with each other and with
other valid primary expressions, for example:
!userinvisible && !invisible
This filter expression evaluates to TRUE for all runs, which are
not "invisible" (hidden) and are not submitted by an "invisible"
user.

serve
-----
The contest participants' e-mail addresses are now shown at the
"View users" page of the `judge' and `master' CGI programs.

serve,run
---------
A new global configuration variable `html_report' is added. If
this variable is set to a non-zero value, the master testing
protocol will be generated by the `run' program in the HTML
format rather than in plain text. A HTML protocol has some
advantages to a plain text protocol including better formatting,
color support, and hyperlinks from the summary table to the
results for each test.

The same contest may have a mix of plain-text and HTML testing
protocols. In order to change the type of the protocol, it is
necessary to change the value of the `html_report' configuration
file in the `serve.cfg' configuration file and restart the
`serve' program. Restart of the `run' program is not necessary
in this case.

Version 2.1.34 (20050108)
=========================
This version fixes several severe bugs and adds a few
improvements to all the programs of the ejudge system. A several
new programs are implemented, in particular, a program for
controlling a contest from the command line `serve-cmd' is
implemented.

Work on porting the `compile' and the `run' programs to Win32
platform is started. The server part of the system (i.e.
userlist-server, serve and other programs) still work only on
Linux operating system. However, porting of the `compile' and
`run' programs will allow making available to participants all
programming systems and languages, which are available on the
Windows platform. A computer running the Windows operating
system will be necessary for compiling and testing
Windows-specific submissions, and one or more computers running
the Linux OS will be necessary to run the server part and for
compiling and testing Linux-specific submissions. The porting
effort is expected to be completed in the next release of the
ejudge system.

configure
---------
A new option `--enable-super-serve-socket' is added. This option
allows setting the default path to the command socket of the
`super-serve' program. From this version of the `ejudge' system
the `super-serve' program accepts control commands via this
socket like the `userlist-server' and the `serve' programs. The
current version of the `ejudge' system implements only a limited
set of control commands, and this feature is not recommended for
use. Complete support for this feature is expected in the next
version of the `ejudge' system.

ejudge-setup
------------
Editing of the path to the `super-serve' command socket is
supported (see the `--enable-super-serve-socket' of the
`configure' script above).

serve-cmd
---------
This new program allows controlling the contest server `serve'
from the command line. A limited set of control commands is
implemented in the current version, as compared to the complete
set of commands available using the `master' CGI program.

The `serve-cmd' program supports the following control commands:
serve-cmd CONTEST-ID login SESSION-ID-FILE LOGIN PASSWORD
          This command must be used to log into the contest
          server. The command must be performed before any other
          operation. CONTEST-ID is the contest identifier (an
          integer number). SESSION-ID-FILE is the name of the
          file to store the session identifier (cookie). The
          correct session identified file must be specified in
          all other commands, as described below.
          LOGIN - is the login of the user, PASSWORD - is the
          user password. The user must have MASTER_LOGIN or
          JUDGE_LOGIN capability bits set for the specified
          contest.
serve-cmd CONTEST-ID logout SESSION-ID-FILE
          This command ends the session. After this command the
          session identifier stored in the SESSION-ID-FILE file
          become invalid. A session identifier is valid for 24
          hours after the login time, the session identifier
          became invalid when expired.
serve-cmd CONTEST-ID write-xml-runs SESSION-ID-FILE
          This command outputs to the standard output the run
          log in the internal XML format. See the description of
          the "write XML runs" commands of the `master' CGI
          program for further details.
serve-cmd CONTEST-ID export-xml-runs SESSION-ID-FILE
          This command outputs to the standard output the run
          log in the external XML format. See the description of
          the "export XML runs" command of the `master' CGI
          program for further details.
serve-cmd CONTEST-ID dump-runs SESSION-ID-FILE
          This command outputs to the standard output the run
          log in the CSV format, i. e. each line of the output
          is one record, and the fields are separated with ';'
          (semicolon). See the description of the "dump XML
          runs" command of the `master' CGI program for further
          details.
serve-cmd CONTEST-ID soft-update-stand SESSION-ID-FILE
          This command updates the current standings table. The
          fog period (i. e. the specified period before and
          after the contest end) is supported. The command
          performs no operation during the fog period. This
          command should be used after importing new runs using
          the `import-xml-runs' command (see below).
serve-cmd CONTEST-ID import-xml-runs SESSION-ID-FILE XML-FILE
          This command imports new runs into the running
          contest. XML-FILE is the file name with run log in XML
          format (either external or internal). See the
          description of the "import XML runs" command of the
          `master' CGI program for further details. Note, that
          the `import-xml-runs' command fails if the running
          contest is having runs being compiled or tested.
serve-cmd CONTEST-ID dump-source SESSION-ID-FILE RUN-ID
          This command outputs to the standard output the source
          code for the specified run RUN-ID.
serve-cmd CONTEST-ID dump-report SESSION-ID-FILE RUN-ID
          This command outputs to the standard output the
          judge's protocol of testing the run RUN-ID.
serve-cmd CONTEST-ID dump-team-report SESSION-ID-FILE RUN-ID
          This command outputs to the standard output the team's
          protocol of testing the run RUN-ID.
serve-cmd CONTEST-ID dump-master-runs SESSION-ID-FILE FILTER-EXPR FIRST-RUN LAST-RUN
          This command outputs to the standard output the runs
          satisfying the specified filter expression as on the
          main page of the `master' or `judge' CGI program.
          FILTER-EXPR is a filter expression (described in the
          corresponding section of the documentation), FIRST-RUN
          is the number of the first run, LAST-RUN is the number
          of the last run. The runs satisfying the given filter
          expression are printed in the CSV format, i. e. each
          record occupies one line, and the record's fields are
          separated with '&'. This field is used because it is
          not allowed in all the field values. The output record
          has the following fields:
          [0]  run_id
          [1]  imported_flag
          [2]  hidden_flag
          [3]  read_only_flag
          [4]  absolute_time
          [5]  absolute_time_nsec
          [6]  time_from_start
          [7]  ip_address
          [8]  size
          [9]  hash_value
          [10] user_id
          [11] user_login
          [12] user_name
          [13] problem
          [14] variant
          [15] language
          [16] language_suffix
          [17] status_num
          [18] status_str
          [19] tests_passed/failed_test
          [20] score_gained
          [21] base_score
          [22] score_multiplier
          [23] attempt
          [24] run_penalty
          [25] date_penalty
          [26] score_adjustment

serve-control
-------------
A new CGI program for controlling the `super-serve' program.
The `serve-control' program uses the control socket of the
`super-serve' program for interaction like `master' program uses
the control socket of the contest server `serve'. The default
path to the `super-serve' control socket is specified using the
`--enable-super-serve-socket' option of the `configure' script.
In the current version of the `ejudge' system only limited
functionality is implemented in `super-serve' and
`serve-control', thus this program is not yet recommented for
use. Currently only viewing functions are (partially)
implemented.

A user must have MASTER_LOGIN or JUDGE_LOGIN capability bit set
in the `ejudge.xml' global configuration file in order to have
capability to use `serve-control' program.

slice-userlist
--------------
A new program, which builds a "slice" of the user database by
the specified set of contests. The program has usage as follows:
slice-userlist [ -i CONTEST-ID ]... [CONFIG-FILE]
CONFIG-FILE is the path to the `ejudge.xml' global configuration
file. If this path is the default path, as specified in the
`--enable-ejudge-xml' option of the `configure' script, the path
may be omitted. CONTEST-ID is the contest identifier. The `-i'
option may be specified several times. In the latter case the
"slice" of the user database will contain all the users
registered to any of the specified contests. The slice is
printed to the standard output stream. An example of use: 
slice-userlist -i 10 -i 12

Note, that the user database file is used for building of slice.
The user database file may be slightly out of date as compared
to the latest version of the database in the memory of the
`userlist-server' program.

run
---
A bug is fixed, which caused an abnormal termination of the
`run' program because of "out-of-memory" condition. This
happened if a program being tested generated huge output to the
standard output or standard error (the size of the redirected
output file must be 10 megabytes or more depending on the number
of tests and the virtual memory size). In the previous version
of the `ejudge' system all the output files were read into
memory and then written (or skipped) to the testing protocol
files. In the current version only files, which sizes do not
exceed the maximal file size as specified by the
`max_file_length' global configuration variable of the
`serve.cfg' contest configuration file, are read into memory.

serve
-----
When the scheduled contest start time is set, but the contest
server `serve' is down at the scheduled start time, the actual
contest start time is set to the scheduled start time anyway. In
the previous version the actual contest start time was set to
the time when the `serve' contest server was started for the
first time after the scheduled start time.

serve
-----
Multiple bugs in the runlog merging code (import XML logs
command) are fixed. In particular, a bug, which caused removal
of all the archive run sources is fixed. A bug is fixed, which
caused duplicating runs in the runlog.

serve,master,judge
------------------
A new run status RUN_DISQUALIFIED is added. This status may be
used, for example, for banning "cheating" submits. The
DISQUALIFIED status is similar to the IGNORED status, but during
score calculation DISQUALIFIED status is considered as
unsuccessfull submit and is penalized as any other unsuccessfull
submit (the run penalty is specified by the `run_penalty'
problem configuration variable of the `serve.cfg' contest
configuration file. The RUN_DISQUALIFIED status is denoted as
`DQ' in filter expressions, for example, all disqualified
submits may be listed by specifying the followin filter
expression: "status == DQ".

contest.xml
-----------
Three new elements are added to the `contest.xml' configuration
file format: <serve_control_access>, <run_user>, <run_group>.
New attribute "invisible" is added to the <contest> element.

The "invisible" attribute of the <contest> element may take
boolean values "yes" or "no". If the attribute value is "yes",
such contest is not displayed in the contest list of the
`serve-control' main page. The default value of the "invisible"
attribute is "no".

The <serve_control_access> element allows specifying limitation
on IP-addresses, which are allowed for the `serve-control'
program to manage this contest.

The <run_user> element allows specifying the system (Linux) used
id, under which the `run' program is run when the contest is
managed by the `super-serve' program. The <run_group> element
allows specifying the system (Linux) group id for the `run'
program. If <run_user> or <run_user> element is not specified,
the values of the corresponding <serve_user> or <serve_group>
elements is used. If the values of the latter elements are not
specified as well, the `run' program is started using the
current user and/or group id of the `super-serve' program.

serve
-----
A bug is fixed, which prevented comparing runs, which were
stored compressed in the archive directory. In the previous
version "Compare runs" operation failed with the "System call
failed" error.

userlist.xml
------------
A new attribute "privileged" is added to the <user> element of
the user description. The attribute may take boolean values
"yes" or "no". The default value is "no". If the attribute is
set to "yes", the corresponding user is a privileged user.
Special capability bits are required to perform operation with
privileged users. For example, in order to edit the registration
data of regular users the EDIT_USER capability bit is required,
but for editing the registration data of a privileged user the
PRIV_EDIT_USER capability bit is required.

edit-userlist
-------------
Editing of the "privileged" attribute value is supported (see
above). 

userlist-server
---------------
Editing of the "privileged" attribute value is supported. An
ordinary user (which has the "privileged" attribute not set)
cannot edit the "privileged" attribute. A privileged user may
only set the attribute value to "yes", but cannot reset the
value to "no".

ejudge.xml
----------
New elements are added to the global ejudge configuration file
`ejudge.xml'. The element <super_serve_socket> allows specifying
the path to the `super-serve' control socket (see above), the
<super_serve_user> allows specifying the system (Linux) user id
under which the `super-serve' program will be run,
<super_serve_group> allows specifying the system (Linux) group
id under which the `super-serve' program will be run, the
<userlist_user> element allows specifying the system (Linux)
user id for the `userlist-server' program, and the
<userlist_group> element allows specifying the system (Linux)
group id for the `userlist-server' program. In the current
version of the ejudge system changing of the user and group id
in the `super-serve' and `userlist-server' programs is not
supported, so the four latter elements are ignored.

serve,master,judge
------------------
New field `score_adj' is added to the run log. This field is
used in the contests in the KIROV or OLYMPIAD scoring systems.
The field stores additional adjustment to the score gained for
this run after automatic testing. The `score_adj' field may take
integer values in range from -128 to 127 (1 signed byte). For
example, if after automatic testing a run gained 50 points, and
the value of the `score_adj' field is equal to -20 points, the
run gains 30 points, this number of points is then penalized for
previous runs or time of submit.

If the value of `score_adj' is positive, and after adding it to
the testing score the resulting score is greater than the
maximal score for the problem as specified in the `full_score'
problem configuration variable, the resulting score is truncated
to the value of the `full_score' configuration variable.

A new problem configuration variable `score_multiplier' is added
to the `serve.cfg' contest configuration file. This variable
allows specifying the coefficient, on which the score stored in
the `score' field of the run record is multiplied. The default
value of the `score_multiplier' variable is 1.

Therefore, the overall score for a run in a KIROV or OLYMPIAD
contest is calculated using the following formula:
S = I * M - A * P + D + J
here `I' is the original score for the run as stored in the
`score' field of the runlog record (usually it is the score
gained after automatic testing of the submit). Note, that if the
run status is OK, and the `variable_full_score' problem
configuration variable is not set for the problem of the run the
`I' value is always taken as the value of the `full_score'
problem configuration variable, i.e. the value of the `score'
field is actually ignored. `M' is the score multiplier as
specified in the `score_multiplier' problem configuration
variable (default value is 1). `A' is the number of the previous
attempts for this problem by this user. `P' is the penalty for
one run as specified by the `run_penalty' problem configuration
variable. `D' is the date penalty as specified by the
`date_penalty' problem configuration variable. `J' is an
additional score adjustment as specified in the `score_adj'
field of the run record. The resulting value `S' cannot be
greater than the value of the `full_score' problem configuration
variable (in this case `S' is set to the value of the
`full_score' variable) or cannot be less than 0 (in this case
`S' is set to 0).

serve,master,judge,team
-----------------------
In the KIROV or OLYMPIAD scoring system in the "score" column of
the user submits table the formula which is used for calculation
of the overall score for the run is displayed. The formula is
displayed in one of the following two forms:
S
(i.e. just the score), if
M == 1 && (A == 0 || P == 0) && D == 0 && J == 0, i.e. when the
original score `I' is not modified. The second form is the full
form: 
S = I [ * M ] [ - A * P ] [ +/- D ] [ +/- J ]
if M == 1, the corresponding part of the formula is not
displayed, this rule also works when A * P == 0, D == 0, J == 0.

serve,master,judge
------------------
In order to support new features of participant management the
participant viewing page in `master' and `judge' CGI programs is
reworked. Instead of the three buttons "Ban", "Make Invisible",
etc. one link to the participant's detailed information is
generated.

On the participant's detailed information page the following
information is displayed: the participant's user identifier,
login, whether this participant is a privileged user, whether
this participant is invisible, the change visibility button (if
the current user, who views the participant details page has
enough privileges), whether this participant is banned, the
change ban status button (if the current user has enough
privileges), whether this participant is locked, the change lock
status button (if enough privileges), the number of runs
submitted, the total size of the submits, the number of
messages, the total size of the messages, the number of printed
pages, the auxiluary participant's status (see below), the
change participant's status button (if enough privileges), the
number of warnings (see below), all the warnings issued to this
user, the new warning form (if enough privileges).

A new feature of issuing warnings to participants is supported.
Warnings may be issued for contest rule violations, cheating,
etc).

In order for user to view the participant list of some contest,
he must have the capability bits MASTER_LOGIN or JUDGE_LOGIN and
LIST_CONTEST_USERS set in the contest.xml configuration file. In
order for user to view the detailed information about a user, he
must additionally have the capability bit GET_USER set. In order
to change the participant's parameters (visibility status,
warnings, auxiluary status) the EDIT_REG capability bit is
required.

serve
-----
A possibility for specifying the auxiluary status of
participants is implemented. The auxiluary status of a
participant is a string chosen from the defined in the serve.cfg
configuration file set. The auxiluary status may be changed on
the participant's detailed information page.

The total number of auxiluary status entries is defined by the
`contestant_status_num' global configuration file of the
`serve.cfg' configuration file. The valid status strings must be
defined using the `contestant_status_legend' global
configuration variable. The first status string gets the number
0, the second - 1, etc. Each participant has initial auxiluary
status 0, which can be later changed. An example of specifying
the set of status strings is shown below:
contestant_status_num = 3
contestant_status_legend = "Status 0"
contestant_status_legend = "Status 1"
contestant_status_legend = "Status 2"

Additionally, for a part of status strings or for all the status
strings HTML attributes may be specified. These attributes are
assigned to the participant's row in the contest standings. To
specify HTML attributes the `contestant_status_row_attr' global
configuration variable is used. The variable may be undefined in
the configuration file (in this case no HTML attributes are
specified to the rows). If the variable is defined in the
configuration file, the HTML attributes must be defined for all
the status strings. The HTML attributes are specified in the
same order as the status strings themselves. For example:
contestant_status_row_attr = ' bgcolor="#ff00ff"'
contestant_status_row_attr = ""
contestant_status_row_attr = ' bgcolor="#00ff00"'
sets the HTML row attribute ` bgcolor="#ff00ff"' for the
`Status 0' contestant status, the HTML row attribute
` bgcolor="#00ff00"' for the `Status 2' contestant status, and
the empty string (i.e. no HTML attribute) for the `Status 1'
contestant status. Note, that the additional "space" character
in the attribute values is necessary to separate the <tr> tag of
the HTML table from the attribute string.

Using the new global variable `stand_show_contestant_status' it
is possible to add a column with the auxiluary contestant
status strings to the current standings table. The new global
configuration variable `stand_contestant_status_attr' may be
used to specify additional HTML attributes of this column, for
example:
stand_show_contestant_status
stand_contestant_status_attr = ' width = "10%"'
Note, that the "space" character in the attribute value is
necessary to separate the <td> tag of the HTML table from the
attribute string.

serve,master,judge,team
-----------------------
Added possibility of issuing warnings to the participants of a
contest. Each warning is displayed to the user on its personal
participation page (`team' CGI program) in its beginning. The
participant may view the primary text of the warning and the
time of issuing.

If a user has enough privileges to view the detailed information
about the participant (i.e. the user has the capability bits
MASTER_LOGIN/JUDGE_LOGIN + LIST_CONTEST_USERS + GET_USER set for
the contest), on the detailed information page all the warnings
issued to this participant are displayed. For each warnings the
following information is displayed: 1) the time of issuing this
worning, 2) the name of a privileged user, who issued the
warning, 3) the IP address of the issuer, 4) the primary warning
text, 5) the auxiluary warning text, which is not available to
the participant, but is available to the privileged users.

If the user has the capability bit EDIT_REG set for this
contest, he can issue warnings. In order to issue a warning, the
user must specify the primary warning text and may specify the
auxiluary warning text. Then the "Issue Warning" button should
be pressed.

If the new global configuration variable
`stand_show_warn_number' (see below) is set in the `serve.cfg'
contest configuration file, the current standings table includes
a column containing the total number of warnings for each
participant.

serve
-----
The new global configuration variable `stand_show_warn_number'
is added. If this variable is set to non-zero value, in the
current standings table the column with the total number of the
warning for each participant is printed. The new global
configuration variable `stand_warn_number_attr' may be used to
specify additional HTML attributes of this column, for example:
stand_show_warn_number
stand_warn_number_attr = ' width = "5%"'
Note, that the "space" character in the attribute value is
necessary to separate the <td> HTML tag and the attribute
value.

serve
-----
The format of the additional participant information file is
changed to store the warnings and the status of the
participant. The format is upward compatible with the previous
versions of the ejudge system. The new elements <warnings>,
<warning>, <text>, <comment>, <status> and the new attribute
"ussuer_id", "issuer_ip", "date" for the <warning> element are
added.

serve
-----
When the table of the current standings of non-virtual contests
is generated the runs with the submit time greater then the
current time (the "future" runs) are ignored. The "future" runs
may appear after merging the run logs when the contest has
several sites and the start time of the contest differs
significantly from site to site.

serve
-----
If some file is absent in the archive directories (the source
code, the master protocol of testing or the user's protocol of
testing), the "File not found" error is reported instead of
"System call failed" upon viewing this file.

serve
-----
The new problem configuration variable `personal_deadline' of
the `serve.cfg' contest configuration file is added. This
variable allows specifying the deadline for the given problem
for the given participant. The variable may be used several time
in one problem definition section, thus setting the personal
deadlines for several users. The format of the configuration
variable is as follows:
LOGIN [DATE [TIME]]
here LOGIN is the login of the participant, for which the
deadline is being set, TIME is the optional time of day in the
HH:MM:SS format, DATE is the date in the YYYY/MM/DD format. If
the TIME is omitted, the 00:00:00 is used by default. When both
TIME and DATE are omitted, the deadline is set to 2038/01/19
00:00:00. The personal deadline has priority over the proble
deadline as specified in the `deadline' problem configuration
variable.

serve,master,judge,team
-----------------------
The date penalty is shown in the pull-down menu of choosing the
problem in the submit run dialog along with the deadline for
this problem.

master
------
The "Schedule start time" command now supports both reduced form
HH:MM as in the previous versions and the full form "YYYY/MM/DD
hh:mm:ss". Thus, the contest start time may now be not in the
current day.

serve
-----
The new command line option `-f' is added. If this option is
specified, the old file of the control socket is removed before
creating the control socket. This option is useful when the
ejudge system is restarted after crash or unclean computer
reboot.

The new command line option `-i' is added. If this option is
specified, all actions for the contest initialization (creation
of the necessary directories and files) are performed and the
`serve' exits instead of going into the serve loop.

A bug is fixed, due to which the `serve' program might "hang"
for some time for all the users, because it was blocked on
waiting for completing data transfer over a slow connection.

When a privileged command is received over a control socket, the
correct user identifier in the packet is no longer required,
because the user identifier is taken from the connection
information structure in the `serve' program.

userlist-server
---------------
The new command line option `-f' is added. If this option is
specified, the old file of the control socket is removed before
creating the control socket. This option is useful when the
ejudge system is restarted after crash or unclean computer
reboot.

A bug is fixed, due to which the `userlist-server' program might
"hang" for some time for all the users, because it was blocked
on waiting for completing data transfer over a slow connection.

The same cookie may be used for privileged login into different
contests, if a user has enough privileges. In the previous
version of the ejudge system each cookie was bound to only one
contest.

If the requiested privilege level during the privileged login is
higher, than the maximal privilege level for some user (for
example, the requested privilege level is ADMIN, but the user
has only JUDGE privilege level), the privilege level is
decreased to the maximal allowed. In the previous version of the
ejudge system this situation caused "Permission denied" error.

The contest identifier may be set to 0 during a privileged
login. Login to the `serve-control' program is assumed in this
case. The user capabilities are taken from the `ejudge.xml'
global configuration file.

Random passwords are not generated automatically for invisible,
banned, locked and privileged users.

run
---
A critical error is fixed. The path to the input file in the
test directory is given to the checker instead of the path to
the input file in the current (working) directory. This fixes a
critical error, because the program being tested may (under
certain conditions) modify the input file.

Version 2.1.33 (20041029)
=========================
Support for the Java JDK (JSE) compiler and runtime environment
is implemented (tested with Sun J2SE 1.4.2 and Sun JSE 1.5.0,
should work with other compatible implementations). The
configuration utility `configure' supports a new option
--with-javac, which may be used to specify the full path to the
`javac' compiler in the JDK. Note, that this must be the full
path to the program, for example, /usr/local/java/bin/javac.
If this option is not specified, the PATH environment variable
is used.

The `javac' ejudge compilation script is used for compilation of
Java programs, and `runjava' script is used for starting of the
compiled (bytecode) Java programs. The scripts may be found in
the ${prefix}/libexec/ejudge directory.

The `runjava' script name should be specified in the `start_cmd'
configuration variable of the Java tester in the serve.cfg, for
example: 
start_cmd = "runjava"
The `runjava' script requires setting of the EJUDGE_PREFIX_DIR
environment variable, unless the full path to the Java secirity
policy file is specified. So, the nessessary configuration
variables of the tester for Java programs look like the
following:
kill_signal = TERM
arch = java
start_env = "EJUDGE_PREFIX_DIR"
start_cmd = runjava

Also, the EJUDGE_JAVA_FLAGS environment variable may be used to
pass additional parameters for the Java machine. For example,
the following parameters set the maximum size of the heap and
stack:
start_env = "EJUDGE_JAVA_FLAGS=-Xmx64M -Xss8M"

By default the Java-programs are started with a strict security
policy, which allows nothing to the program, except reading from
the standard input and writing to the standard output. A less
strict security policy, which allows reading and writing files
in the current (testing) directory is also supported. This
security policy is activated by setting the EJUDGE_JAVA_POLICY
environment variable as follows: 
start_env = "EJUDGE_JAVA_POLICY=fileio.policy"

It is possible to specify arbitrary security policy using the
EJUDGE_JAVA_POLICY environment variable. Either the full path to
the policy file, or the file name of the policy file may be
specified. In the latter case the policy file must be located in
the ${prefix}/share/ejudge directory.

Complete disabling of any security policy is possible. To do so
the EJUDGE_JAVA_POLICY environment variable must be set to the
`none' value as follows:
start_env = "EJUDGE_JAVA_POLICY=none"

The Java programs must satisfy the following restrictions:
  1) they must contain the only class named `Main';
  2) nested classes are allowed;
  3) the `Main' class must contain the `main' method.

Fixed several bugs of invalid handling of astronomical time. Due
to incorrectly initialized timezone field the time may differ
one hour from the real time. For example, the bug manifests
itself when `start_time' or `deadline' were specified for a
problem.

A new field `languages' is added to the user database. This
field is for specifying programming languages and IDEs, which
are used by a team. The `languages' field may be made mandatory
or optional for filling during the registration for the contest
using the following elements of the contest.xml configuration
file:
<field="languages" mandatory="yes">
or
<field="languages" mandatory="no">

configure
---------
The `--with-javac' command line option is added (see above).

edit-userlist
-------------
Editing of the `languages' field is supported (see above).

ejudge-setup
------------
The Java JDK compiler and runtime environment are supported (see
above).

serve
-----
The statistics on submits for each problem is printed at the
bottom of the current standings table (both in the ACM and
KIROV/OLYMPIAD mode). The total number of submits, the number of
successful submits and the percentage of the successful submits
are displayed.

A new global configuration variable `stand_show_ok_time' and a
new problem configuration variable `stand_hide_time' are added
to the `serve.cfg' contest configuration file. The both
configuration variables are used only in the KIROV standings
mode. If the variable `stand_show_ok_time' is set to non-zero
value, the time of the first successful submit for each problem
and each user is printed in the standings table. This time may
be either relative from the contest start time or absolute
(astronomical) depending on the value of the `show_astr_time'
global configuration variable. The problem configuration
variable `stand_hide_time' disables printing of the success
time.

The date penalty is calculated correctly in the standings
table.

A new problem configuration variable `start_date' is added to
the `serve.cfg' contest configuration file. This variable allows
specifying of the astronomical time, when this problem become
available for submitting.

The date penalty specification may have one of the following
forms:
DATE TIME PENALTY               e.g.    2004/10/10 12:00 -10
or
DATE PENALTY                    e.g.    2004/10/12 -20
or
PENALTY                         e.g.    -30
In the latter case the date is assumed to be in the "distant"
future (2038/01/19 - the maximum allowed by the current width of
the `time_t' type).

A bug in handling of variant problems (introduced in the
previous ejudge release) is fixed. The variant problems are now
properly supported.

New format conversions are supported. For example, format
conversions are used in the `stand_extra_format' global
configuration variable. The following new format conversions are
supported:
%Mf       - the short name of the faculty of the participant
%MF       - the short name of the faculty in English
%Md       - the full name of the faculty of the participant
%MD       - the full name of the faculty in English
%Mp       - the printer name assigned for this participant

run
---
Special support for the environment variable specification
"EJUDGE_PREFIX_DIR" passing to the tested program is
implemented. In this case the `EJUDGE_PREFIX_DIR' variable is
added to the environment variables, and its value is set to the
value of the ejudge installation prefix (i.e. the value of the
--prefix option of the configure script during configuration of
the ejudge). An example of use:
[tester]
start_env = "EJUDGE_PREFIX_DIR"

The advanced sound generator (i. e. by default the speech
generator `festival') is supported in the KIROV standings mode.
To activate the speech generator the path to the `festival'
speech generator must be specified correctly during
configuration of the ejudge system (i.e. using the
--with-festival option of the `configure' script). Then the
following global configuration variables must be specified in
the serve.cfg configuration variables:
sound_player = "${script_dir}/festival"
extended_sound

A bug in parsing of the test information files (.inf) is fixed.
This bug manifested itself when quotes were used in the quoted
strings.

master
------
A bug in handling of "Rejudge displayed" command is fixed. This
bug caused abnormal termination of the master program after the
command was sent to the server.

userlist-server,master
----------------------
The table of randomly generated passwords now contains the
`location' column, where the value of the `location' field for
all the participants is printed.

register
--------
The `languages' field is supported (see above).

collect-emails
--------------
A new utility, which extracts the email addresses of all the
users registered for the specified contests.

Version 2.1.32 (20041001)
=========================
Implemented support for the version 4 of the reuse library. The
ejudge system may be compiled using both version 3 and version 4
of the reuse library. The new reuse version 4 is a major upgrade
of the library, which uses the GNU standard toolkit
autoconf/automake/libtool. Also, in the reuse 4 certain severe
bugs in the process support module (exec.[ch]) are fixed. These
bugs may result in non-detection of the "Time-limit exceeded"
error in certain cases.

Implemented an interface to the speech synthesizer programs. As
an example of such program the `festival' speech generator
program is supported by the ejudge. I. e. a user may specify the
--with-festival option in the configure's command and enable use
of the festival speech generator. By default this option is
disabled.

A new field `spelling' is added to the user database. The value
of this field is passed as the argument to the speech generator
instead of the user name. The value of this field may specify
pronunciation of the user name. The `spelling' field may be
edited only by an administrator user with the appropriate
privileges, but not by the user himself.

Added a possibility to route a printing request from a user to a
specified printer. To specify the name of the printer, a new
field `printer_name' is added to the user database. This field
contains the name of the printer, which will be passed as the
value of the `-P' option of the `lpr' command. The
`printer_name' field may only be edited by the administrator
user with the appropriate privileges.

configure
---------
The reuse library version 4 is supported. If the `reuse-config'
script is located in the directory, mentioned in the PATH
environment variable, all the necessary compiler options for use
of the reuse library will be detected automatically by the
`configure' program. In this case the `--with-reuse' configure
option is not necessary.

A new option `--with-festival=FEST_PATH' is added. This option
may be used to specify the directory, where the festival speech
synthesizer is installed. FEST_PATH must be specified so, that
the `festival' program is located in the ${FEST_PATH}/bin
directory. The current version of the configure does not check
the correctness of the FEST_PATH specification.

serve, compile, run
-------------------
Support for "conditional compilation" directives in the
serve.cfg configuration file is implemented. These conditional
compilation directives are similar to the ones of the C
preprocessor. The directives allow enabling or disabling the
fragments of the configuration file depending on the values of
the conditional variables. In the current version of the ejudge
only limited support for conditional compilation directives is
implemented. The full support will be implemented in the next
versions.

In the current version the relation operations ==, !=, >=, <=,
>, < are supported for numbers and strings. The logical
operations && and || are also supported. As primary expressions
decimal numbers, strings (in C syntax), and predefined variables
may be used. The 64-bit long long type is used to store the
integer values during evaluation of conditional expression. The
following predefined variables are supported:

name    | type      | desc
--------+-----------+------------------------------------------
host    | string    | The host name, where the program starts.
mode    | long long | The program code: 0 - `serve',
                    | 1 - `compile', 2 - `run'.
major   | long long | The major version number.
minor   | long long | The minor version number.
patch   | long long | The version patch number.
build   | long long | The version build number.
managed | long long | 1, if the program is started in the
        |           | managed mode (i. e. by the `super-serve'
        |           | program, and 0 otherwise.

The syntax of the conditional compilation directives is similar
to the syntax of the conditional compilation directives of the C
preprocessor. The conditional compilation directive in the
serve.cfg configuration file must start with '@' character,
which must be the first non-whitespace character in the line.
The following directives are supported: `@if,' `@elif', `@else',
`@endif'.  The syntax of each directive is shown below.
@if expression
@elif expression
@else
@endif

In the `serve.cfg' contest configuration file the numeric
suffixes are supported. The numeric suffixes may be used after
any numeric parameter. The suffixes are as follow: `K' means
multiplication by 1024, `M' means multiplication by 1024*1024.
For example, 
max_vm_size = 8M

serve, compile
--------------
The format of the compilation control packet is slightly
changed. The `0' number must present at the end of the packet
(after all the environment variables).

serve, run
----------
The format of the run control packet is changed. The new packet
format supports passing the string containing arbitrary
characters and of arbitrary length. Moreover, the `serve'
program passes to the `run' program the user identifier, the
user spelling name (the first of the assigned variables from the
list `spelling', `name', `login'), the problem spelling name
(the first of the assigned variables from the list `spelling',
`short_name' of the problem description section). All these new
parameters are then passed to the speech synthesizer program.

A new problem configuration parameter `spelling' is added to the
problem configuration section. The variable might be used to
specify the details of pronunciation of the problem name.

edit-userlist
-------------
Editing of the new `spelling' user info field is supported.

Editing of the new `printer_name' user info field is supported.

master
------
Error diagnostics is imroved in the case, when a user with all
necessary administrative privileges attempts to log into the
contest, and this user is not registered for this contest.

Error diagnostics is improved in the case, when a user attempts
to log into the contest, but the contest server is down.

run
---
The interface with speech synthesizer programs is implemented.
To the contest configuration file `serve.cfg' a new global
configuration variable `extended_sound' is added. If this
configuration variable is set to 1, additional parameters are
passed to the the sound player program. Note, that the sound
player program is specified in the `sound_player' global
configuration parameter of the `serve.cfg' configuration file.
The additional parameters are as follow: the run completion
status, the test number, the user spelling name, the problem
spelling name. The sound player program may use theses
parameters to generate the corresponding voice message. If the
`extended_sound' variable is set to 1, the global configuration
variables `accept_sound', etc, are not used.

Variable substitution is performed for the global configuration
variable `sound_player' in the `serve.cfg' configuration file.
Thus, the value of this variable may be set as follows:
sound_player = "${script_dir}/festival"

run
---
The implicit limit on maximal number of tests for one problem of
254 tests is removed. In the previous version this limit was not
checked, which resulted in program crash, when the number of
tests exceeded this number. In the current version the number of
tests is not limited, the memory for storing internal
information is extended automatically.

run
---
Reworked the rules of naming of test files, correct answer
files, etc. New configuration variables `test_pat', `corr_pat',
`info_pat', `tgz_pat' are added to the global configuration
section and to the problem configuration section of the
`serve.cfg' configuration file. The values of these variables
must be the format strings for the `sprintf' function, which is
used to generate the test file name. The sprintf function is
passed one parameter - the test number, which is an integer.
If the X_pat variable is specified, the corresponding X_sfx
variable is ignored.

For example, the default test file names are generated using the
followin format specifier:
test_pat = "%03d.dat"
Provided, that the variable value test_sfx=".dat".

serve
-----
In the ACM contest mode three modes of rounding are supported.
These modes determine, how the seconds elapsed from the contest
start to the problem submit are converted to the minutes during
penalty calculation. The rounding mode is selected by setting
the `rounding_mode' global configuration variable of the
`serve.cfg' configuration file. The configuration variable may
have the foollowing values:
  o ceil (default) - the resulting number of minutes is
    calculated as the minimal number of minutes, greater or
    equal to the elapsed time from the contest start to the
    problem submit.
  o floor - the resulting number of minutes is calculated as the
    maximal number of minutes, less or equal to the elapsed time
    from the contest start to the problem submit.
  o round - the resulting number of minutes is calculated by
    rounding of the seconds to minutes (i. e. if >= 30 seconds
    elapsed, the number of minutes is increased by 1).

team
----
Error diagnostics is improved in case, when a user attempts to
log into a contest, but the contest server is down.

userlist-server
---------------
The daemon mode is implemented. The daemon mode is activated by
specifying the `-D' option in the userlist-server's command
line. In the daemon mode the program puts itself into background
and disables the output to the standard output streams. The logs
are written to the log file. The path to the log file is
specified using the new <userlist_log> element of the ejudge.xml
configuration file. If this element is not specified,
`userlist-server' refuses to start in the daemon mode. In the
daemon mode the program produces in somewhat less verbose output
to the log file, as compared to the foreground mode.

The log format is changed rather seriously. The new format
contains less redundant information and is more rational. The
new format should be easier to parse by the log analyzing
tools.

master,serve
------------
A privileged user may add a new runs explicitly specifying many
run parameters. In the previous version, the privileged user had
to perform an ordinary run submit, and then edit the parameters
of the run. In order to add parametrized runs the user must have
SUBMIT_RUN and EDIT_RUN capability bits set for the current
contest. The run parameters form is available from the "Add new
run" link, which is located below regular submit run dialog on
the master's main page.

The new runs added using this new feature are not judged
automatically.

serve
-----
The hidden runs may be edited and rejudged before the start of
the contest.

users,register,master,judge,team
--------------------------------
Support for the IPv6 localhost address ::1 is implemented. This
address is converted automatically to 127.0.0.1.

run
---
Fixed a bug, when the name of the standard checking program (as
specified by the `standard_checker' problem configuration
variable) was not inherited to the tester specification for the
problem.

edit-userlist
-------------
A memory leak is fixed, which manifested itself when the list of
all the users in the database is viewed.

A memory leak during parsing of all XML-files is fixed. This
memory leak affects all the programs of the ejudge system.

serve
-----
Added support for execution of arbitrary program at the moment
of contest start. This program may, for example, change the file
permissions on the web server. To specify the path to the
program a new `contest_start_cmd' global configuration variable
is added to the `serve.cfg' contest configuration file. This
variable may be set to the name of the program to start. If the
absolute path is specified, that path is not changed. If the
relative path is specified, the absolute path is calculated
relative to the value of the `conf_dir' global configuration
variable.

If the value of one of the following global configuration variables
`stand_header_file', `stand_footer_file', `stand2_header_file',
`stand2_footer_file', `plog_header_file', `plog_footer_file' is
a relative path, the absolute path is calculated relative to the
value of the `conf_dir' global configuration variable.

contest.xml
-----------
If the value of the <root_dir> element is set, the value must be
the absolute path to a directory.

A new element <conf_dir> is added to the contest configuration
file contest.xml. The value of this element is the path to the
contest configuration files (for example, serve.cfg). If the
<root_dir> element is set, but <conf_dir> is not, the value of
<conf_dir> element is set to <root_dir>/conf.

If the values of any of the following elements
<register_header_file>, <register_footer_file>,
<users_header_file>, <users_footer_file>, <team_header_file>,
<team_footer_file> are relative paths, the absolute paths are
calculated relative to the value of the <conf_dir> element.

ejudge.xml
----------
A new <var_dir> element is added to the main ejudge
configuration file `ejudge.xml'. The value of this element is
the path to the log files of the `userlist-server',
`super-serve', and `compile' programs. The value of this element
is used, if the values of the <userlist_log>, <super_serve_log>,
or <compile_log> elements are not absolute paths.

New elements <super_serve_log>, <compile_log> are added to
specify the paths to the log files of the `super-serve' and
`compile' programs in the daemon mode. Note, however, that the
daemon mode of these programs is not yet implemented.

ejudge-setup
------------
Setup of the value of the <var_dir> element of the `ejudge.xml'
configuration file is supported.

Version 2.1.31 (20040620)
=========================
Support for different charset encodings is significantly
improved. All the explicit references to the "KOI8-R" charset
encoding are removed from the source code and replaced with the
encoding, specified in the --enable-charset option of the
configure script. If this option was not specified, the "UTF-8"
charset encoding is used.

The encoding specified in the --enable-charset option of the
configure script is used as the "internal" encoding, i. e. the
encoding which is used to store varous character strings in
memory. Thus the internal encoding must be compatible with the
string functions of the C Standard Library, i.e. the internal
encoding must not allow NUL ('\0') bytes in the middle of
character strings. For example, UTF-16 is not such an encoding,
whereas UTF-8 is.

During parsing of the XML configuration files and internal files
the external charset of the XML document (specified in the
document header) is converted into the internal charset. The
`iconv' function of the C Standard Library is used, so almost
all reasonable charset encodings are supported. All the
generated XML documents are also written in the internal
charset.

When a HTML file is generated by the ejudge programs, its
encoding is specified as defined in the corresponding
configuration files (by default it is the internal encoding).
However the current version of the ejudge system does not
support converting strings in the internal charset into the
charset of the HTML document, if they are different. The strings
are inserted into the HTML without conversion, which may result
in incorrect HTML documents. Thus, in the current version of the
ejudge system for correctness and safety the internal charset
and the output HTML document charset must be the same. So it is
not recommended to explicitly specify the charset encoding for
the generated HTML documents in the ejudge configuration files.

serve
-----
The `standings_charset' global configuration variable is no
longer supported. The implementation of its support was
incorrect and insecure in the previous versions. Is it possible,
that when charset conversion from the internal enconding to the
HTML document encoding will be supported, this configuration
variable will be restored.

ejudge-setup
------------
Several bugs in the generation of the ejudge setup script are
fixed.

Version 2.1.30 (20040619)
=========================
The compilation and installation procedure for the ejudge system
is completely reworked. The new installation procedure is closer
to the GNU standards. The configuration, compilation,
installation and setup procedure is described in detail in the
INSTALL file. To adjust settings of the ejudge according to the
current system the `configure' script is used, which is
generated using the `autoconf' utility. The `configure' utility
accepts large number of options, all of them are described in
the `INSTALL' file.

The compiled programs and the necessary files are installed to
their location using the `make install' command. The
installation directory is specified using the --prefix=PREFIX
option of the configure script. If this option is not given in
the configure's command line, the default directory
HOME/inst-ejudge is used, where HOME is the home directory of
the user executing the configure script. The structure of the
PREFIX directory is as follows:
        bin/            primary executable programs and scripts
        cgi-bin/        CGI programs
        include/        header files of the libchecker library
        lib/            object files of the libchecker library
        libexec/ejudge  various additional scripts and programs
        share/ejudge    source code of the testlib library (pascal)
        share/locale    message localization directory
Therefore, with exception of the cgi-bin directory, the
directory structure corresponds to the GNU standards.

configure
---------
During the configuration of the ejudge system using the
configure script it is possible to specify the default values
for the most important configuration parameters of the system,
for example, the path to the XML contest configuration
directory or the path to the user server socket, etc. If the
corresponding configuration variable is not set in the
configuration file, the ejudge programs will use `built-in'
(i.e. given during configuration stage) value. In case of CGI
programs `master', `judge', `team', `register', `users' this
makes configuration files not necessary, if all the necessary
configuration variables are defined during the configuration of
the system. Also, if the path to the main configuration file
(ejudge.xml) is specified correctly during the configuration
stage, it is possible to omit it in the arguments for programs
edit-userlist, userlist-server etc.

Use of configure script allows automatic adaptation to some
details of the Linux installation. For example, if the process
privilege lowering kernel patch is not installed, corresponding
ejudge utilities (capexec, libdropcaps.so) will not be
compiled. Also presence of localization tools (xgettext) is
detected automatically, and if the tools are absent, the
localization support will not be compiled. See the `INSTALL'
file for further documentation. Note, that no attempts were made
yet to make the ejudge system portable to other operating
systems.

The configure script tries to detect automatically a number of
compilers and interpreters for C, C++, Java, Pascal and other
languages. The compilation scripts are automaticaly adjusted for
the detected compilers, and they will be supported by the ejudge
compilation server. If a compiler or an interpreter is located
in a non-standard directory and the path to it is not included
into the PATH variable, its location may be specified explicitly
using the command-line options for the configure script.

ejudge-setup
------------
A new `ejudge-setup' utility is developed. The utility may be
used for initial setup of the ejudge system after its
complation. The utility provides console-based menu interface
for refinement of initial configuration settings of the ejudge
system. The utility is generates a "setup script", which should
be executed by the user. The setup script will create all the
necessary directories, copy all the necessary files to them,
etc. The `ejudge-setup' utility may be run under ordinary
(non-privileged) user, whereas for the setup script the
administrator (root) privileges may be required.

The generated ejudge setup script will create all the necessary
configuration files, create the user database with a single
administrator user with all the privileges for the ejudge
system. The parameters of the administrator user are defined
using the `ejudge-setup' utility. Also the ejudge setup script
creates the compilation server configuration files with support
for all the detected compilers and interpreters. The ejudge
script creates configuration files for the test contest (number
1) and copies the test files to the contest home directory. Also
the ejudge setup script creates the work disk for testing of the
programs and installs the symlinks to the CGI programs of the
ejudge system to the cgi-bin directory of the http server.

ejudge-config
-------------
This script may be used to obtain the information about the
parameters of the ejudge system (currently, about the libchecker
library). This information is necessary for compilation of
checking programs. The ejudge-config script accepts the
following command-line options:
        --cflags
                prints the standard output stream the C compiler
                flags, necessary for compilation of checking
                programs (for example, the path to the header
                directories)
        --ldflags
                prints the linker flags
        --libs
                prints the required libraries

Thus, in order to compile a checking program the following
command may be used:
gcc `ejudge-config --clags --ldflags` prog.c -o prog `ejudge-config --libs`
Assumed, that the ejudge-config script is located in a directory
from the PATH variable.

ejudge.xml
----------
In order to store the new configuration variable the new tags
are supported in the ejudge.xml file. The following new tags are
supported: charset, config_dir, contests_home_dir,
full_cgi_data_dir, compile_home_dir, testing_work_dir,
script_dir, serialization_key. In future, these tags may be used
in a ejudge configuration editor. A new attribute ejudge_user,
which is an alias fot the local_user attribute is also
introduced. The new name reflects the meaning of the attrobute
better.

run
---
The ejudge system now supports a number of "standard cheking
programs". The set of the standard checking programs includes,
for example, the program, which compares two files textually
(the first file is the participant's solution output and the
second file is the correct answer file), or the program, which
compares two integers (the first from the participant's solution
output and the second from the correct output file) being the
sole data in the two files. The set of checking programs is
compiled along with the main ejudge system programs and is
installed to the script directory (PREFIX/libexec/ejudge). In
order to specify, that solutions for the given problem to be
checked using a standard checker the `standard_checker'
configuration variable of the problem section of the serve.cfg
configuration file is used. This variable should be set to the
name of the standard checker required, for example
standard_checker = cmp_int
The set of the standard checkers allows in many cases avoiding
writing new checking programs. For the complete documentation
please refer to the Reference Manual.

The location of the standard checking programs may be specified
explicitly using the `ejudge_checkers_dir' global configuration
variable of the serve.cfg configuration file. Its default value
is exactly PREFIX/libexec/ejudge. The default value may be
changed from the configure's command line using the
--libexecdir=DIR option.

libchecker
----------
The libchecker library for writing checking programs is
significanly extended. The following new functions are added: 
normalize_spaces_in_file, read_corr_unsigned_int,
read_corr_unsigned_long_long, read_in_long_long, read_int,
read_in_unsigned_int, read_in_unsigned_long_long,
read_team_unsigned_int, read_team_unsigned_long_long,
read_unsigned_int, read_unsigned_long_long.

The libchecker header files may be used with a C++ program
(compiled using the GNU C++ compiler g++).

serve, compile
--------------
A new feature added allowing passing arbitrary environment
variables to the compilation server compile. The environment
variables are passed in the compile request packed, thus the
variables may be defined in the contest configuration file
rather than the compile server configuration file. These
environment variables are then passed to the compilation
script. In order to use this feature, the `compiler_env'
configuration variable from the [language] section of the
serve.cfg file is to be used. Each use of the `compiler_env'
variable (in the left-hand side) defines one environment
variable, but the `compiler_env' variable may appear in the same
language descrition section several times, each time adding a
new environment variable.

run
---
Arbitrary environment variables may be passed to the checking
program. To define the environment variables the `checker_env'
configuration variable of the serve.cfg file is used. This
variable may appear in the problem description section as well
as in the tester description section. Inheritance of the value
of this variable from abstract problems and abstract checkers is
supported. The environment variables obtained from all the
sources (problem description section, tester description
section, etc.) are merged together and passed to the testing
program. Each use of the `checker_env' configuration variable
allows setting of a single environment variable, but the
`checker_env' configuration variable may appear several times.

serve, compile, run
-------------------
Explicit user-defined substitutions of configuration variables
are supported. These substitutions are similar to variable
substitutions in languages like bash. For example, in order to
use the global configuration variable `script_dir' in the
definition of the global configuration variable `start_env', the
following definition of `start_env' may be used:
start_env = "LD_PRELOAD=${script_dir}/libdropcaps.so"

Currently, configuration variable substitutions are handled for
`compiler_env', `checker_env', `start_env' configuration
variables only. Currently, only names of the global
configuration variables may be used in substitutions.

The variable substitution mechanism duplicates in somewhat the
already existing format substitution mechanism. Is is probable,
that in future versions a new unified substitution mechanism,
which integrate the both cases, will be introduced.

serve
-----
Upon start the `serve' contest server may create the symbolic
links to the current standing files from the html documents
directory of the http server. In the prevous versions this step
had to be done manually.

In order to enable automatic creation of symbolic links, in the
contest server configuration file `serve.cfg' the `htdocs_dir'
global configuration variable must be set. This variable must
contain the path to the root of the html document directories of
the http server (often on the Linux systems this path equals to
/home/httpd/html). If the `htdocs_dir' variable is undefined,
the default value is used. The default value may be specified in
the configure's command line using the
--with-httpd-htdocs-dir=DIR option.

To specify the path, where the symlinks are to be created, the
global configuration variables `stand_symlink_dir',
`stand2_symlink_dir', `plog_symlink_dir' are used for the
primary standings file, secondary standings file, and the
submission log file. All the paths are interpreted as relative
to the value of `htdocs_dir' configuration variable. The names
of symlinks created in these directories are defined using
`standings_file_name', `stand2_file_name', `plog_file_name'
global configuration variables.

For example, if the `standings_file_name' variable equals to
"standings.shtml", the `htdocs_dir' variable equals to
"/home/httpd/html", and the `stand_symlink_dir' variable equals
to "/contests/1", then on the serve's startup in the
/home/httpd/html/contests/1 a symlink named standings.shtml will
be created pointing to the current standings file located in the
contest home directory. If the http server setup has no virtual
hosts, the current standings will be available using the URL
http://HOST/contests/1/standings.shtml.

In order to `serve' to install the necessary symlinks to the
html documents directory of the http server, it should have
enough privileges, i. e. a user running the serve program must
have write access to the corresponding directory.

Version 2.1.29 (20040420)
=========================
All the compile-time settings, which cannot be changed from
configuration files are moved into a separate file `settings.h'
in the ejudge source directory. This file contains the following
definition of constants:
MAX_CGI_VALUE_LEN
  The maximal size of data received in a single CGI-variable by
  a CGI-program from the client web-browsers. This constant
  defines the maximal size of file, which can be received from
  clients by the CGI-programs. This constant affects:
    o the maximal size of a user submit or a privileged user
      submit;
    o the maximal size of a message;
    o the maximal size of a judging protocol to upload to the
      server;
    o the maximal size of a runlog being imported to the server;
  Note, that certain global configuration variables of the
  `serve.cfg' contest configuration file, for example
  `max_run_size', may define additional limitations on the
  maximal data size.
  By default this constant equals to 1 Mbyte.
MAX_SERVE_PACKET_LEN
  The maximal size of a data packet, which can be received by
  the contest server `serve' program from the CGI programs.
  If a data packet size exceeds this maximal size, the protocol
  error is diagnosed. This constant affects all data transfer
  from the `master', `judge', and `team' CGI programs to the
  contest server `serve'. See also the list of size limitations
  imposed by this variable above.
  Note, that certain global configuration variables of the
  `serve.cfg' contest configuration file, for example
  `max_run_size', may define additional limitations on the
  maximal data size.
  By default this constant equals to 1 Mbyte.
MAX_USERLIST_PACKET_LEN
  The maximal size of a data packet, which can be received by
  the user database server `userlist-serve' from its clients.
  This variable has lesser impact, than the previous two, since
  the clients of `userlist-serve' never send to it large amount
  of data.
SERVE_PACKET_NAME_SIZE
  The size of a buffer, which is required to hold the file name,
  which contains the command from the `serve' program to the
  `compile' or `run' programs. The current value of the constant
  equals to 13, this the packet file name length is 12. The
  first character of the packet file name defines the priority
  of this packet (see below), and the remaining 11 are an unique
  packet name, constructed using the current time, the process
  identifier of the `serve' program, the run identifier, etc.
MAX_LANGUAGE
  The maximal number of programming languages supported in a
  single contest. Each programming language is assigned an
  unique language identifier: an integer number in the range
  from 1 to MAX_LANGUAGE. If there are more that MAX_LANGUAGE
  programming language definitions (i. e. [language] sections)
  in the contest configuration file `serve.cfg', the `serve'
  program fails to start.
  The current value of this constant is 31.
MAX_PROBLEM
  The maximal number of non-abstract problems supported in a
  single contest. Each non-abstract problem is assigned an
  unique problem identifier: an integer number in the range from
  1 to MAX_PROBLEM. Abstract problems do not have unique problem
  identifier, thus this constant does not affect the number of
  abstract problems, which could be arbitrary. If there are more
  that MAX_PROBLEM non-abstract problem definitions
  (i. e. [problem] sections) in the contest configuration file
  `serve.cfg', the `serve' program fails to start.
  The current value of this constant is 100.
MAX_TESTER
  The maximal number of non-abstract testers supported in a
  single contest. Each non-abstract tester is assigned an unique
  problem identifier: an integer number in the range from 1 to
  MAX_TESTER. Abstract testers do not have a unique numeric
  identifier. A default tester (i. e. a tester, which has the
  `any' configuration variable set to true) is assigned only one
  tester identifier regardless of the number of problems served.
  If there are more that MAX_TESTER non-abstract tester
  definitions (i. e. [tester] sections) in the contest
  configuration file `serve.cfg', the `serve' program fails to
  start.
  The current value of this constant is 100.

A new attribute "closed" of the <contest> element is added to a
contest description file `contest.xml'. The attribute "closed"
is a boolean attribute, i. e. it may be set either to "no", or
to "yes". If the attribute equals to "yes", then the current
contest is considered closed. No (unprivileged) user can
register to an already closed contest using the CGI-program
`register'. If the CGI program `team' is started for a closed
contest, the "Contest closed" diagnostic page is displayed, and
the `team' program terminates. The "closed" attribute may be set
for contest, if it is desirable to prevent various random
contest registration and participation.

New configuration variables `priority_adjustment',
`user_priority_adjustment' are added to the contest
configuration file `serve.cfg'. These variables allow setting of
the run checking priority. The run checking priority is an
integer number from -16 (the highest priority) to 15 (the
lowest priority). The run checking priority may be defined for
the contest globally, depending on the user identifier, problem,
language, or tester. The default priority is 0. The
configuration variables define priority changes (adjustments).
For example, priority_adjustment equal to -2 in the problem
description section means, that testing packet for this problem
gains -2 to its current value of priority. The overall priority
of testing is the sum of global contest priority, problem
priority, language priority and tester priority.

The `run' program selects testing requests according to the
priority of the request. A testing request (testing packet) with
higher priority is processed first. If a new testing request
comes during testing of the request with lesser priority,
testing of the current request is completed before processing
other requests. Note, that testing priority has no relation to
the Unix process priority (nice value) for the `run' program.

A new problem configuration variable `disable_language' is added
to the contest configuration file `serve.cfg'. This
configuration variable allows defining of languages, which are
disabled for this problem, i. e. which cannot be used in
submissions for this problem. Each time only one short name of
the language may be specified, but the `disable_language'
variable may be specified in the problem definition section
several times. For example,
disable_language = "gcc"
disable_language = "g++"
This disables use of languages with short name "gcc" and "g++"
for some problem.

register
--------
The `closed' attribute of the <contest> element of the
contest.xml configuration file is supported. If this attribute
is set to "yes", such a contest is not shown in the list of
contests, available for registration, or the link to the submit
page is not shown.

serve
-----
The run filter settings for the privileged CGI programs `master'
and `judge' are now stored with user id and session id (cookie)
as the keys. Thus, each browser window (with different session
id) showing the privileged pages using the same user id now have
independent filter settings.

serve,run
---------
The testing priority is supported, as described above.

team
----
The configuration variables `max_run_size' and `max_clar_size'
are removed. Checking of the corresponding limitation is
performed in the contest server `serve'.

The `closed' attribute of the <contest> element of the contest
configuration file `contest.xml' is supported. If this attribute
is set to "yes", the "Contest is closed" page is generated
instead of the normal operation (login prompt).

userlist-server
---------------
The `closed' attribute of the <contest> element of the contest
configuration file `contest.xml' is supported.

master,serve
------------
Support for rejudging of all the submissions currently displayed
according to the filter settings is implemented. To perform
rejudges one has to press "Rejudge displayed runs" button. Then
the confirmation page is displayed, which lists the run ids of
all the submissions to rejudge.

serve
-----
The `disable_language' problem configuration variable of the
contest description file `serve.cfg' is supported.

Version 2.1.28 (20040402)
========================
New global configuration variable `enable_report_upload' is
added. New problem configuration variable `date_penalty' is
added.

clean-users
-----------
Support for removal of inactive user logins is implemented.
A user login is considered as inactive, if this user did not
make any submit or did not submitted any clarification request.
A user login is never considered an inactive if this login is
privileged (i. e. mentioned in the <cap> element of the global
configuration file ejudge.xml) or has the `never_clean' flag set
to true.

To activate the removal mode the -r option is to be specified in
the clean-users command line. When the program finds an inactive
user login it prints a confirmation question on the standard
output. To confirm removal of the user login one has to answer
'y' or 'yes', and to deny removal one has to answer 'n' or 'no'
(answers are case insensitive). If an additional option -f is
specified in the command line, the confirmation questions are
not displayed and inactive users are removed automatically.

serve,master,judge
------------------
Privileged users may view both the judge's testing protocol and
the participant's testing protocol. On the "View source" page
and on the "View report" page a new link "View team report" is
added to the navigation links. Upon clicking on this link the
participant's protocol is displayed. As usually, in order for
the contest server to generate and store the participant's
judging protocols the `team_enable_rep_view' global
configuration variable must be set to true. In order to be
allowed to view reports the user must have the VIEW_REPORT
capability bit set for this contest.

serve,master,judge
------------------
A privileged user may upload to the server the testing protocols
(both the participant's and the judge's ones). The uploaded
protocols replace the protocols stored in the serve's submit
database and are shown by "View report" and "View team reports"
commands. To enable uploading feature the `enable_report_upload'
global configuration variable has to be set to true. The
uploading user must have the EDIT_RUN capability bit set for the
current contest. If the participant's judging protocols are
enabled by the global configuration variable
`team_enable_rep_view' the uploading user may choose between
uploading only the participant's protocol, the judge's protocol
and both.

serve
-----
Added support for penalizing a solution based on the submission
date of the solution for any problem. For example, if the
solution is submitted before April 5, 2004 no penalty is
applied. If the solution is submitted between April, 5 and April,
11, it gets 1 penalty point. If the solution is submitted after
April, 12 (including that day) is gets 2 penalty points. A new
problem configuration variable `date_penalty' is added to
specify submission date penalties. To implement the policy
described above the problem description section must contain the
following fragment:
date_penalty = "2004/04/05 0"
date_penalty = "2004/04/12 -1"
date_penalty = "2005/01/01 -2"
Each definition of the `date_penalty' configuration variable
works only in the current problem definition. The `date_penalty'
configuration variable is cumulative, i. e. it adds a new
penalty specification to already defined penalty
specifications. The `date_penalty' configuration variable is not
inherited from abstract problem specifications. The order of
specifications for each particular problem is significant: the
specifications are checked in exactly that order. Each penalty
specification has the form as follows:
DATE ADD-VALUE
where DATE is an astronomical date, given in the standard
ejudge's date format YYYY/MM/DD [hh[:mm[:ss]]]. ADD-VALUE is the
value added to score received by this submit during testing. The
resulting score cannot be less, that 0 (in this case it is set
to 0) or it cannot be greater that the full score for this
problem (in this case it is set to the full score).

The date-dependent problem penalizing only works in contest
conducted in the KIROV mode.

userlist-server
---------------
Arbitrary system (Unix) user and group identifiers are
supported, include negative ones.

Version 2.1.27 (20040327)
========================
The administrator interface of the contest now provides several
new possibilities (suspend/resume printing, download a run,
compare a run with another run). Implemented proper support for
submitting binary files (via "Submit run" interface). Added the
"Last success" information for the standings. New configuration
variables are added: diff_work_dir, diff_path,
stand_success_attr, binary.

The XML-representation of the run log is changed. The <run>
element now contains the `nsec' attribute, which contains the
nanosecond component of the submission time. As a consequence,
the `time' attribute now contains the time in seconds instead of
the time in milliseconds as in the previous versions.

master,judge,team,register,users
--------------------------------
The maximal size of data, accepted from the web-client is
increased to 1 Mbyte.

master,judge,team,serve
-----------------------
Binary files are allowed by the run submission command. A binary
file is a file, which contains \0 byte. The binary files are
passed to the server unchanged.

If the programming language chosen for a submit allows binary
submissions (i.e. the language configuration variable `binary'
in the serve.cfg configuration file is set to true), the
received file will be stored to the run database without
changes. If the `binary' variable is set to false (default
value), the file will be truncated at the first \0 byte and an
error will be reported.

master,judge,team,serve
-----------------------
The contest server status file format is updated. Its new size
is 128 bytes, and currently 77 bytes are not used. These
currently unused fields allow easy adding of new fields to the
server status file, in a manner, similar to the runlog database
format updates. The new version of the server status file format
is numbered 2, as opposed to the previous version numbered 1.
The magic constant in the beginning of the status file differs
for the versions 1 and 2. The CGI programs master, judge, team
supports the contest server status file of both versions for
backward compatibility.

master,serve
------------
The contest administrator may suspend participants' printing
requests. To do this he must have `CONTROL_CONTEST' capability
bit set for the current contest. To suspend printing the
"Suspend printing" button is used. The "Suspend printing" button
appears on the main page of the administrator interface if
printing is enabled in the current contest. To resume
participants' printing requests the administrator should press
the "Resume printing" button, which appears instead of "Suspend
printing" button when the printing is suspended. Suspended
printing affects only regular participants of the contests.
Privileged users may print as usually.

serve
-----
The contest server `serve' reads its previous state upon
startup. The server status flags (client suspending, judging
suspending, olympiad judging mode, printing suspending) are
restored from the status file.

serve
-----
A new field `nsec' is added to the run entry in the runlog
database. This field contain the nanosecond component of the
submission time. With this field all the submits, received by
one server will have unique submission time. This solves the
long standing problem of several submits received in the same
second.

The ejudge system already supports distributed contests, when
several independent contest servers run on the different sites
and from time to time exchange its runlog database in XML
format. Thus a contest server should be able to merge the runlog
from another server, and this foreign runlog may contain the
runlog entries that originally belonged to this contest server.
To make the runlog stable on all the contest server, the
submits, which have the same submission time are sorted by a
secondary criterion, but any reasonable secondary criteria may
result in reordering of the existing runs on the server. Also
due to secondary criterion of submission sorting it is possible,
that a newly received run should be inserted in the middle of
the runlog. But the problem is that the run_ids of a submission
cannot be changed, if the submission is in a transient state
(compiling or running), because this may result in compile or
serve packet loss and hanging of the run in "Compiling..." or
"Running..." state.

The problem is solved by adding nanosecond component to the
submission time. All the runs accepted by one contest server
will have unique timestamp, and with high probability all the
runs in the distributed contest will also have unique
timestamp.

The new runlog format is compatible with the previous runlog
format. If the contest server of the previous version reads the
new runlog format, the nsec field will be ignored. If the
contest server of the current version reads the old runlog
format, the `nsec' field value is set to 0.

userlist-server
---------------
A new `location' field is added to the user database. The
`location' field cannot be changed by a regular user. It should
be used by the contest administrator to specify the location
(room, computer number) of the participant. The team location is
printed on the banned page of the team listing.

edit-userlist
-------------
Editing of `location' field is supported.

serve
-----
The current standings table now contains the "Last success"
information. 

serve,master,judge
------------------
A new "Download run" feature is added to the "View source" page
of the administrator interface. By clicking on the "Download
run" link the run is loaded into the browser in the raw format
(text/plain or application/octet-stream). The "View source" page
already has the run source, but an explicit "Download run"
command is necessary because of the following reasons:
  1. The run source code may be directly stored to a file
     without use of clipboard buffer, thus avoiding possible
     data corruption in the clipboard.
  2. The binary submissions (i.e. the language of these
     submissions has `binary' flag set to true) are not shown in
     the "View source" page, and the "Download run" is the only
     possibility to get the source for the run.

serve,master,judge
------------------
The "View source" page of the administrator and judge interface
now contain "Compare runs" dialog, which allows comparing of the
current run with any specified run. To compare runs one must
enter the run_id of the second run and press the "Compare"
button. Runs compared with "diff -u" command. The path to the
`diff' utility may be specified by `diff_path' global
configuration variable.

The run_id field of the run compare dialog by default contains
the maximal number of run with the following properties:
  - this run_id is less, than the current run_id;
  - the user_id, language_id and problem_id of the both runs
    match. 

userlist-server
---------------
A new field `never_clean' is added to the user database. If for
some user this field is set to `true', the behavior of
`clean-users' utility is changed. The `clean-users' utility
scans all the runlog and clarlog databases for all the contests
in the system and marks users, which did not post any
clarifications or did not post any runs, as candidates for
removal. If the `never_clean' field is set to true, such user
will never be marked as candidate for removal.

edit-userlist
-------------
Editing of new `never_clean' field is supported.

clean-users
-----------
Multiple bugs fixed.
Contests with empty runlog are handled properly.
The `never_clean' flag is supported.
For each user information about virtual contests in which this
user participated is collected (by accounting VIRTUAL_START and
VIRTUAL_STOP events). If a user did not send any run or
clarification request, but have one or more VIRTUAL_START or
VIRTUAL_STOP events accounted for him, all the virtual contests
are printed in the "Virtual contests for start/stop only users"
after the main statistics table.

serve
-----
Several bugs in runlog merging code are fixed. Runlog merging
should now works correctly in all situations.

Version 2.1.26 (20040219)
=========================
Saving of certain parameters of the team client state is
implemented. A new configuration variable for explicit
specifying of the team client state saving directory is added.

Printing support is added. A privileged user may print a source
for a run using the contest server `serve' program. A regular
user may print a run on the server, if the global configuration
variable `enable_printing' is set to true.

A large number of bugs, which manifest themselves in the
OLYMPIAD contest mode is fixed.

An incompatible change is introduced to the `contest.xml'
configuration file format. This version of the ejudge system
will report an error trying to read unchanged configuration
files of the previous version. The configuration file change is
trivial, though. To fix the configuration file the capability
bit SUBMIT_RUNS should be renamed to SUBMIT_RUN.

serve
-----
A new field `pages' is added to the runlog database. This field
contains the number of pages used to print the source for the
run. The default value of the field is zero (the run source is
not printed). The field is set to positive value, when a regular
user request printing of the run source using the `team'
CGI-program. The `pages' field is used to eliminate multiple
printing of the same run and to count the total amount of
printed pages to check the participant's page quota.

serve,master
------------
Support for editing of `pages' field is added.

serve,master,judge,team
-----------------------
Support for printing of the run source is implemented.
Privileged users may use printing option from the "View source"
page of the `master' or `judge' CGI-program. In order to be
allowed to print a run a privileged user must have the
`PRINT_RUN' capability bit set for the current contest. A
privileged user may print the same source several times, and he
has no limits on the number of printed pages.

A regular contestant is allowed to print a run source, if the
global configuration variable `enable_printing' of the contest
server configuration file `serve.cfg' is set to true. The
maximal number of pages for a contestant (page quota) may be set
using the `team_page_quota' global configuration variable. The
default value is 50 (pages). A mandatory banned page is counted
in the quota.

The `a2ps' program is used to convert the source to PostScript
file. The path to this utility may be set using the `a2ps_path'
global configuration variable (the default value is
/usr/bin/a2ps). Additional arguments to the `a2ps' program may
be set using the `a2ps_args' global configuration variable (the
default value is "-1 -E").

To queue a generated PostScript file to a printer the `lpr'
program is used. The path to this utility may be set using the
`lpr_path' global configuration variable (the default value is
/usr/bin/lpr). Additional arguments to the `lpr' program may be
set using the `lpr_args' global configuration variable (the
default value is empty).

contest.xml
-----------
A new capability bit `PRINT_RUN' is added. The `SUBMIT_RUNS'
capability bit is renamed to `SUBMIT_RUN'. This is incompatible
change (as compared to the previous version of the system).

userlist-server
---------------
Random passwords do not use easily misunderstood characters:
'l', 'I', '1', 'O', '0'.

serve,run
---------
A new problem configuration variable `accept_partial' is added.
The variable is effective only for OLYMPIAD contest system. If
this variable is set to true, the participant's submits are
accepted even if the submit does not pass all the tests from the
problem statement. The `serve<->run' interaction protocol is
updated correspondingly.

serve
-----
A privileged user may actually submit runs before the start of
the contest and after the end of the contest. This feature has
been announced in the previous version but actually was
commented out. Privileged submits are performed using `master'
or `judge' CGI-program.

serve
-----
Since a new submit may be added to the middle of the runlog
database, the run archive must be updated (i.e. some files
should be renamed) accordingly. In the previous version
appending of a run into the middle of the runlog database might
cause loss of the submit. Note, this bug manifested only when
runlog entries were added to the database due to contest events
(virtual start/stop, submits), not due to runlog merging.

serve
-----
In the OLYMPIAD contest mode, the contest "Judging mode" may be
enabled before the end of the contest.

serve,master
------------
Support for `Set accepting mode' command is added. This command
switches the contest from the "Judging mode" to the "Accepting
mode". The command only works in OLYMPIAD contest mode.

run
---
Support for OLYMPIAD contest mode is significantly improved.
This contest mode is now almost always handled in the same way
as KIROV contest mode.

The run program responds better to user interrupt (Ctrl-C).

The tests with zero sum of scores are supported in all the
cases.

serve
-----
When an archive entry is rewritten (for example, after retesting
of a run), the previous file is removed. This fixes an error,
when the archive contains both compressed (.gz) and uncompressed
file corresponding to the same run.

serve
-----
Added support for saving the state of the team client to the
file. The state file has an XML-based syntax. Currently the only
state parameter which is saved is the status of viewing of the
messages. For each messages, which is addressed to all the
participant or to the particular participant, flag of whether
this participant has viewed the message, or not is saved to the
state file. The state is loaded from the file on demand, and is
created also on demand (first access). If the saveable state of
the client is changed during operation of the serve program, the
new state is saved to the file upon termination of the serve
program.

A new global configuration variable `team_extra_dir' is added.
The variable contains the path to the directory, where the saved
state files are stored. The default value of the configuration
variable is ${var_dir}/team_extra, where ${var_dir} is the value
of the `var_dir' global configuration variable. The saved state
files are stored in subdirectories of the team_extra_dir
directory. Each directory can contain no more, than 32
subdirectories or state files. The organization of the team
client state directory hierarchy is similar to the organization
of the run archive.

serve,team
----------
If a participant has unread messages, the message "You have X
unread message(s)" is displayed in the contest state section. In
the team client the messages, which are sent by this participant
to the judges, have status "U" until the messages are viewed by
some judge (note, that such messages in the judge or master
clients are shown with "N" status). Messages from the judges to
all the participant or to that particular participant has the
"N" status until are viewed by the participant. Already viewed
messages have no special status.

serve
-----
A new problem configuration variable `hidden' is added. If this
variable is set to true, the corresponding problem is not shown
in the current standings table, but the problem is available for
the teams to submit solutions.

master,judge
------------
If the URL does not contain the contest_id, and the CGI program
name is plain `master' or `judge', a login page is generated,
which contains login, password and contest_id fields.

userlist-server
---------------
Backup copies of the userlist-server database are now written in
the compressed GZIP format.

If saving of the current user database state is failed due to
write error (for example, if the file system is full), the
temporary file, which is created during save, is removed.

compile
-------
Handling of error conditions is significantly improved. The
compile program now does not terminate because of error (for
example, the file system is full), but instead sleeps for 5
seconds, and then tries to repeat the operation.

Version 2.1.25 (20031229)
=========================
The usability of the master and the judge interface is improved
in this version. A new field is added to the run database. A new
configuration variable added to the serve configuration file.

serve,master
------------
Editing of the number of the tests passed and the gained score
(in KIROV or OLYMPIAD contest mode) of any run is now
supported. This feature is available to the contest
administrator only (as runlog entry editing).

serve,master
------------
Shortcut from the source code view to the testing protocol view
and back is added.

userlist-server,register
------------------------
Strict checking of the number of the team members is implemented
upon insertion of a new member into the team.

serve
-----
A new `is_readonly' boolean field is added to the run database.
If this field is set to `true' for a run, any editing of this
run is prohibited. But changing of `is_readonly' field is
allowed. A run with `is_readonly' field set is never rejudged.

serve,master
------------
Added support for editing of the `is_readonly' field.

serve,run
---------
A new configuration variable `disable_testing' is added to the
serve configuration file serve.cfg. The variable is available at
the global level as well as at the problem level. If for a
problem this configuration variable is set to true, any testing
(automatic and manual) for this problem is disabled. When a
submit for such problem is received, it is immediately marked as
"Accepted for testing", which may be changed only manually
(rejudging for this problem is completely disabled). The run
program for such problems does not check existence of the tests,
their validness and existence of the checker. This configuration
variable is good, when a problem is checked manually, but it is
desirable to put the problem to the list of problems.

serve,master,judge
------------------
New primary expressions added to the filter expression language:
imported[(run_id)], curimported, hidden[(run_id)], curhidden,
readonly[(run_id)], curreadonly, variant[(run_id)], curvariant,
rawvariant[(run_id)], currawvariant. The difference between
rawvariant and variant is as follows: rawvariant always takes the
value of the `variant' field from the runlog entry, when variant
additionally checks, that the variant field is 0 (i.e. the
variant number from the variant map is used). In this case the
variant number from the variant map is returned.

serve,master,judge
------------------
Certain fields of a runlog entry are now marked as hyperlinks in
the "View source" page. Upon clicking on such links a filter
expression is automatically constructed, which selects runs with
value of the chosen field equal to the field value of the
current run. For example, after clicking on hyperlink on
IP-address, the following filter expression is constructed:
"ip == ip(run_id)", where run_id is replaced with the number of
the current run. This expression selects runs, with the
IP-address of the current run. The previous filter expression is
cleared.

serve
-----
A new problem configuration variable `variable_full_score' is
added. If this variable is set to `true', the rule of
calculation of score for a fully solved problem in OLYMPIAD or
KIROV scoring system is changed. In the regular mode a fully
solved problem (i.e. a run with the OK status) gains the score
specified by the `full_score' problem configuration variable
(penalty is calculated after this, etc). In the mode turned on
by the `variable_full_score' configuration variable an accepted
run (i.a. the run with the OK status) gains the score, specified
in the `score' field of this run. This configuration variable is
convenient, when the OK status is set manually (for example,
after manual testing), and all the fully solved problems should
have different score.

serve,master,judge
------------------
The list of contest participants, which is generated by the
"View teams" reference from the main page now has a possibility
of fast enabling a run filter for a particular participant. To
enable the filter just click on the hyperlink of the user
identifier. The current page then will be reloaded to the main
page and the user identifier filter will be enabled.

The current page is not switched to the main page, but instead
remains the source view page, when a runlog entry field is
changed in the source view page.

master,judge
------------
The session support dialog is removed from the login page.
Currently the master and judge CGI-programs support three
variants of session handling: 1) always pass the login and the
password in the hidden variables of forms, 2) generate a session
identifier and pass it in the hidden variables of forms,
3) generate a session identifier and pass it in URLs,
4) generate a session identifier and store it in cookie. The
variant 3) was the default. Now the session handling menu is
removed and the variant 3) is always chosen. It is planned to
remove support for other session handling methods from the
master, judge, and team programs.

Version 2.1.24 (20031208)
=========================
This version adds new features and slightly changes the format
of some configuration files. A most notable format change is the
change of the file with the internal contest server state. This
file is generated by the `serve' program and is used by the
`master', `judge', and `team' CGI-programs. This version of
these CGI-programs cannot read the server status file in the old
format, which result in fatal startup errors of the
CGI-programs. To eliminate the fatal startup error just start
the `serve' program manually in this contest directory once. The
`serve' program will regenerate the state file, and then all the
CGI-program will start normally. After the state file is
regenerated, the `serve' program may be stopped. The contest may
then be put under the super-serve's control, and the
`super-serve' program will start the `serve' program
automatically on demand.

All unused and obsoleted files are removed from the ejudge's
source archive. As a result the size of the archive is
noticeable decreased.

The `contest.xml' configuration file
------------------------------------
Support for <observer_access> XML element is completely
removed. This XML element was introduced for the `observer'
CGI-program, which was not implemented. The planed functionality
of the `observer' program is a restricted privileged user
interface (more restricted, that of `judge' CGI-program), but
this can be achieved by properly tuning capability bits.
Also the `OBSERVER_LOGIN' capability bit is removed.

A new capability bit `SUBMIT_RUNS' is introduced. If some user
has this capability set, this used is allowed to submit a run
using `master' or `judge' CGI-programs. Runs submitted from
privileged programs differ from the runs submitted by ordinary
users (see below). In order to be able to use `master' or
`judge' program the user must have the corresponding capability
bit (`MASTER_LOGIN' or `JUDGE_LOGIN') set.

serve
-----
The structure of the archive of submits and testing protocols is
optimized. Instead of keeping all the archive files in a single
directory (for example, all the testing protocols was located in
the `var/archive/reports' directory of the contest directory),
the archive files are structured in a directory hierarchy, so
that a directory on each nesting level contains no more, than 32
entries (without `.' and `..'). The maximal number of entries in
the archive is limited by approx. 1 million, thus to store up to
1 million files the nesting level of 3 is sufficient. For
example, the testing protocol for the submit 1905 will be stored
in the file `var/archive/reports/0/1/R/001905'.

Such optimization allows significant increase of access speed
for filesystems, which keep directory entries unordered (for
example ext2/ext3). To disable the new hierarchical form of
archive set the global configuration variable
`use_dir_hierarchy' to 0 with the following line:
use_dir_hierarchy = 0
The hiarchical directory structure of archive directories is
enabled by default.

The old and the new form of storing the archive files are
backward compatible. The new (current) version of the ejudge
system will correctly find archive entries created by the
previous versions. However, if the support for hiarchical files
storage is enabled, all new files will be stored in the
hiarchical directory structure and thus will be unavailable for
the ejudge system of the previous versions.

All the archive entries, which size exceed some limit (4KiB by
default) are compressed using the gzip algorithm. Such entries
are stored in the file with `.gz' suffix to distinguish them
from uncompressed files. The minimal size of archive entries
that need to be compressed may be tuned with `min_gzip_size'
global configuration variable of the `serve.cfg' configuration
file. The default size of 4 KiB (4096 bytes) equals to the
allocation unit size of the contemporary versions of ext2/ext3
file systems on ia32 architecture (and equals to the size of
virtual memory page). Compression for files of smaller size is
pointless, because compression takes processor time and do not
result in decrease of used disk space.

In order to completely disable compression of archive entries
set the `use_gzip' global configuration variable of the
`serve.cfg' configuration file to 0 with the following line:
use_gzip = 0

A new field `variant' to store the problem variant is added to
the run database. By default and for compatibility the variant
is equal to 0, i. e. the variant from the variant map file (set
by the `variant_map_file' global configuration variable) is
used. The variant may be changed explicitly by the contest
administrator, and a user with sufficient privilege level may
submit a run with explicitly specified variant of the problem.

A new field `is_hidden' is added to the run database to indicate
the special status of a run. The "hidden" runs are tested as
usually, but are now shown in the public run log, do not
influence score of the team. The "hidden" runs also may not be
exported to XML. See below a more detailed description of hidden
runs and their usage.

serve,master,judge
------------------
A privileged user may submit a run using `master' or `judge'
CGI-program, if the user has `SUBMIT_RUNS' capability bit set.
The corresponding form is added to HTML pages generated by the
`master' and `judge' CGI-programs. A run submitted from `master'
or `judge' is added to the run database with "hidden" flag set.
It means, that such run is tested as usually, but the run is not
counted when the current standings are calculated. The hidden
run is not shown in the public runlog. The hidden run is never
exported to XML.

A privileged user may submit a run for any problem (even for
problem with expired deadline), may specify any variant of the
problem (if the problem has variants), may use any programming
language (even disabled one). Submit time is not checked for
privileged runs, i. e. they may be sent before the start of the
contest or after the end of the contest. User quota are also not
checked for privileged runs.

serve,master
------------
Added support for editing of the new run database fields
`variant' and `is_hidden'.

judge
-----
Fixed a bug of invalid formatting of submission table for
VIRTUAL START and VIRTUAL END event and for EMPTY records.

run
---
Zero test score is allowed. In the previous versions of the
ejudge system test score 0 meant default test score (1). Tests
with zero score are handled correctly. Zero-scored tests are
useful for judging a problem using "accepted"/"not-accepted"
system in the `KIROV' contest score system.

serve,master
------------
Changing of the contest duration is allowed after the end of the
contest (by any reason: explicit "Stop contest" administrator
command and contest duration expiration). To allow changing of
the duration after the end of the contest, the global
configuration variable `enable_continue' of the contest
configuration file `serve.cfg' must be set to non-zero value.
The following line in the configuration file will do:
enable_continue

The contest administrator is allowed to decrease the contest
duration using the "Change duration" command (in the previous
versions the administrator may only increase the contest
duration). However, if the contest is in progress (already
started), decrease of the contest duration may not cause
immediate stop of the contest due to contest duration
expiration. Such contest duration changes are disallowed and
will cause a user error.

Decrease of duration of unlimited in duration contests is
disallowed. Increase of limited contest duration to unlimited is
also disallowed.

Almost any contest may be continued after stop if the
`enable_continue' global configuration variable is set to
non-zero value. It is possible to continue stopped contest of
limited duration, if the current time is before the time when
the contest would stop due to contest time expiration. The
contest, which is stopped due to contest time expiration may be
extended in two turns: first the contest duration is extended
with "Change duration" command, and then the contest is
continued using "Continue" command. Note again, that the
`enable_continue' configuration variable must be set to allow
continuation of already stopped contest.

serve
-----
The 0 value of the global configuration variable
`board_fog_time' means, that the standings are not frozen at
all. In the previous versions it was impossible to turn off
standings freeze (the only way was to set the freeze time 1
minute before the end of the contest).

New global configuration variables `stand_freeze_time' and
`stand_melt_time' are introduced. These variables are aliases
for the `board_fog_time' and `board_unfog_time' configuration
variables respectively. The new variable names better reflect
the variable usage. All names are supported.

serve,master,judge,team
-----------------------
If the standings freeze is enabled for the contest (i. e. the
contest has limited duration and the `board_fog_time' is
positive), the expected standings freeze time is shown to users
in the server state section of the generated html pages.

team
----
"Client time:" line is removed from the server state section of
the team-generated HTML page, because the name of the line does
not match its meaning. "Client time" always means the time when
the `team', `judge', or `master' CGI-program is invoked to
process the client's request.

serve,team
----------
A new global configuration variable `team_enable_ce_view' is
introduced in the contest configuration file `serve.cfg'. If
this configuration variable is set to non-zero value, the
compilation log is available to participants in case of compile
errors. The compilation log is available even if testing
protocols are not available to participants (i. e. if global
configuration variable `team_enable_rep_view' is set to 0).

A new global configuration variable `team_show_judge_report' is
introduced in the contest configuration file `serve.cfg'. If
this configuration variable is set to non-zero value, and
testing protocols are available to the participants (i. e. if
global configuration variable `team_enable_rep_view' is set to
non-zero value), the participants view the judge's testing
protocol, not the team's. The judge's testing protocol contains
complete information about testing of a run: input data (tests),
program output, program output to stderr, output of the checker,
etc. By default participants may only view limited (team's)
version of the testing protocol, which only contains the result
of running the program on tests, but not the tests themselves,
not the output of the program. The full protocol showing mode
may be enabled or disabled for each problem individually by
explicit specification of value of `team_show_judge_report'
configuration variable in the problem description.

serve
-----
Bug is fixed, when the `serve' program terminated due to
assertion failed, if no users were registered for a contest.

serve,master
------------
The contest administrator may suspend testing of incoming runs
using the "Suspend testing" command. In the suspended testing
mode all the participant's submits are accepted as usually, but
runs are not queued for compilation and subsequent execution,
but are stored into the run database with "Accepted for testing"
status. The runs will remain in this status until they will be
rejudged by the administrator explicitly or by "Judge suspended
runs" command. The "Suspend testing" command is useful to
decrease the server load at the end of the contest (when submit
stream is usually very intensive), especially, if the contest
server is simultaneously compilation server or testing server
for the contest. When testing is suspended, the "Resume testing"
command is available to the administrator to resume the normal
mode.

The contest administrator may judge all pending runs accepted
when testing was suspended using "Judge suspended runs"
command.

serve,master,judge
------------------
`status' and `curstatus' constructs are available in filter
expressions. These are aliases for `result' and `curresult'.

Version 2.1.23 (20031121)
=========================
A bugfix release. No new features. No new configuration variables.

An unofficial Russian translations of the GNU General Public License
and GNU Lesser General Public License is added to source distribution.

serve, compile, run
-------------------

Configuration file format now supports quotes inside parameters. The
standard syntax of ", ', and \ (see description of test.inf file
format) is supported. For example,
table_head_style = 'h2 style="common"'

serve/master
------------

XML export of standings properly escapes ", & and other problematic
HTML/XML characters.

team
----

Verbose error messages are displayed in case of non-registered users,
banned users.

run
---

Escaped `#' are correctly handled in test.inf file. 

userlist-server
---------------

XML save of userlist database now properly escapes ", & and other
problematic HTML/XML characters.

Hash table lookup is implemented for login lookup and session id lookup.
This drastically (100 times) decreases lookup time.

register
--------

Silent truncating of input fields on "Number" sign is fixed.

libchecker.a
------------

If NEED_TGZ checker flag is on, a checker has access to `dir_in_path'
and `dir_out_path' variables, which contain the path to input directory
(in the tests source directory) and to the working directory of program
being tested respectively. I.e., to open the input directory the
checker should use `opendir(dir_in_path)' function call. To open the
output directory of the program, the checker should use
`opendir(dir_out_path)' function call.

New functions are added to the library:
  checker_read_corr_double,
  checker_read_corr_long_long,
  checker_read_int,
  checker_read_in_long_double,
  checker_read_long_double,
  checker_read_long_long.

