-*- mode: text; mode: auto-fill -*-
$Id: NEWS,v 1.14 2005/01/08 17:04:47 cher Exp $

Version 2.1.34 (20050108)
=========================
If no bugs are found in this release, the next release (which
will be identical or nearly identical to the current release)
will be numbered 2.2.0, so a new stable branch of the `ejudge'
system will be started. The 2.1 branch will be terminated. All
the support work will go to 2.2 branch, and all the new
development will go to the future development branch 2.3.

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.

