From 796b9f42635d23470574ea69f6f8cb5be66d064f Mon Sep 17 00:00:00 2001 From: Petr Stefan Date: Tue, 3 Jan 2017 11:08:22 +0100 Subject: [PATCH] Add inner task type to a list --- Rewritten-docs.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 5dfdb83..ee0b6b9 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -545,17 +545,19 @@ on standard output) and should not fail on time or memory limits. This division is transparent for backend, each task is executed the same way. But frontend must know which tasks from whole job are important and what is their kind. It is reasonable, to keep this piece of information alongside the tasks in job -configuration, so each task can have a label about its purpose. There are three -categories of tasks: +configuration, so each task can have a label about its purpose. Unlabeled tasks +have an internal type _inner_. There are four categories of tasks: -- _initiation_ -- setting up the environment, compilling -code, etc.; for users failure means error in their sources which are not -compatible with running it with examination data +- _initiation_ -- setting up the environment, compilling code, etc.; for users + failure means error in their sources which are not compatible with running it + with examination data - _execution_ -- running the user code with examination data, must not exceed time and memory limits; for users failure means wrong design, slow data structures, etc. - _evaluation_ -- comparing user and examination outputs; for user failure means that the program does not compute the right results +- _inner_ -- no special meaning for frontend, technical tasks for fetching and + copying files, creating directories, etc. Each job is composed of multiple tasks of these types which are semanticaly grupped into tests. A test can represent one set of examination data for user