$Id: NEWS,v 1.3 2003/12/29 06:56:37 cher Exp $

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.

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.

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 existance of the tests,
their validness and existance 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, varant[(run_id)], curvariant,
rawvariant[(run_id)], currawvariant. The difference between
rawvariant and varant 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.

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 whould 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 allready 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.

