0% found this document useful (0 votes)
35 views4 pages

Polygon

This document summarizes the key features and functionality of the Polygon end-user documentation. It describes the user registration process, problem permissions for users, and how to create, edit, and manage problems. Key aspects include creating edit sessions to work on problems, uploading different file types, adding and running tests, and packaging problems into downloadable ZIP files. The documentation provides guidance on using the system to collaborate on programming problems.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as RTF, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
35 views4 pages

Polygon

This document summarizes the key features and functionality of the Polygon end-user documentation. It describes the user registration process, problem permissions for users, and how to create, edit, and manage problems. Key aspects include creating edit sessions to work on problems, uploading different file types, adding and running tests, and packaging problems into downloadable ZIP files. The documentation provides guidance on using the system to collaborate on programming problems.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as RTF, PDF, TXT or read online on Scribd
You are on page 1/ 4

Polygon End-User Documentation

Users
Registration

Only registered users can create and view problems. Use "Register" link on the index page
to do to the registration.

User roles and permissions


Each user has one out of three permissions for any problem. User can have "WRITE",
"READ" or "NONE" permissions.

 WRITE - If he has "WRITE" permission, he can edit problem and grant/modify other
users access to this problem.
 READ - If he has "READ" permission, he can start edit session, but it is impossible to
commit it. Also such user can't 
grant/modify access for the problem.
 NONE - user can't read problem and has no way to know if it exists.

By default problem creator has WRITE permission to the problem.

Problems
Name

Each problem has own name which is unique for problem creator. So it is possible that there
are name problems with name "a-plus-b", but the user jsmith
can create no more than one problem "a-plus-b". For sure, future versions of Polygon will
give you the way to resolve conflicts.

Edit sessions
Think about edit session as working copy placed on the server-side. You don't loose your
edit session if you close the browser or logout from the system. Users can edit problem
passing following steps:

 Create edit session


 Make changes in the edit session
 Commit the edit session.

If you doesn't commit the edit session no other user will see your changes.

Also the current version of Polygon doesn't take care about the conflicts. So if your working
copy has conflict with already commited you have only one option to destroy this session.
For now we can recommend you to have short time between commits.

Each time you open your session from the "Problem list" edit session updates to the latest
revision.

General info

 Input file - input file name or "stdin" in case of standard input

1
 Output file - output file name or "stdout" in case of standard output
 Time limit - time limit per test in milliseconds
 Memory limit - memory limit in megabytes

It is possible to change this settings any time you want.

Statements

Polygon supports multiply languages statements for problem. You can choose the language
and create the statement. 
We are thinking about special statement parameter "encoding" to specify encoding for
statement files in packages.

Currently the preferred statement format is LaTeX, but it is possible to use any format you
want. 
You can edit file "problem.tex" (we will change the file name soon) on the "Files" tab to
change the problem template.

Sample tests will be specified on the "Tests" tab.

Files
There are three types you can upload on the "Files" tab.

 Resources - Header files, library files and other files you need in process of
compilation of your sources. All resources will be copied to the 
compilation folder while compilation. Also some system files are resources. For
example, "problem.tex" (which will be renamed) is also resources.
You can change these files if you want to change some system behavior.

 Sources - Source files of generators, checkers (verifiers) and validator. As since you
can change resources and make your sources uncompilable, it is possible to that
sources are compilable with the button "Check sources for compilability". You can
use one of the prewritten checker (special program which checks that answer is
correct), so don't write your own if you really don't need it.

 Additional files - Any other files. It can be problem manual in Microsoft Word format,
some reports in Microsoft Excel or pictures. 
You can place here problem statement if you have non-standard statement format
(for example, Microsoft Word).

We do not recommend to have naming collision between files of different types and also to
have files with differs in extensions only.

Checker
Here you can select one of the prewritten checker or any of your sources to play checker
role. Checker is a special program which uses three command line parameters: "check.exe
input-file output-file answer-file". Checker should read and analyze these files and return
verdict.
It should return:

 Exit code 0 - If the answer is correct


 Exit code 1 - If the answer is incorrect
 Exit code 2 - If it can't parse output-file
 Exit code 3 - If some assertion failed (for example participant has found better
solution that jury expects).

2
Also it is good practice than checker prints some short message to stdout describing the
reason for the verdict. It is better to use
English for it.

The best way to prepare checker is to use testlib library from


the http://code.google.com/p/testlib/
Latest release of the testlib is placing in the resources by default to make easy testlib
usage.

Validator

Validator is a special program to validate that all the tests are satisfy the constraints from
the statement. It expects to get input file from the standard input. If it thinks that input is
incorrect, it should return non-zero exit code and prints short message to the stdout or
stderr.
It is highly recommended to use validator.
Validator will be transparently executed on each test usage (sample tests injecting into the
statement, solution invocation, test preview and so on).

Tests

Each problem has one or more testset. Many problems have only one testset and the typical
name for it is "tests". But there are some cases than you need several testsets (for official
testing and for internal testing).

Each testset contains 1-based enumerated tests. Polygon will check enumeration and write
warning message if enumeration is invalid.

You have three ways to add tests:

 Use "Add Test" form - it is good way to manual test.


 Use Script - script contains lines like "gen 45 | permute > 33" which will create test
33 using generators "gen" and "permute". 
You should have sources "gen" and "permute" on the files tab. First, the "gen"
executable will be invoked with the command line parameter "45". After it the output
will be redirected to "permute" executable. The standard output from the "permute"
execution will be used as test 33. You don't need "> test-index" part if you use script
line on the "Add Test" form.
 Use "Add tests from archive" feature - upload ZIP file with the tests. Polygon will use
all the files in the archive as test files. It will automatically set test indexes.

Each test has several setting such as:

 Use in statements - inject the test (with answer) input the statements;
 Description - just for information to describe the test specific;
 Output in statements - raw text which will be included into statements as answer
instead of solution generated.

Tests page also contains "Preview Tests" link. You should use it if you want to preview all
the tests (and answers) on the single page. It will use correct model solution to generate
test answers.

Solutions
On the "Solutions" tab you can upload solution source files. Each solution file has type (or
tag) associated with it:

3
 Main correct solution - it is the model solution to generate all answers;
 Correct solution - it is the correct solution, you will be notified if it returns verdict
different from OK;
 Incorrect - it is the incorrect solution, you will not be notified for any solution
behavior;
 Time limit exceeded - you will be notified if it runs with verdict different from OK and
TL;
 Wrong Answer - you will be notified if it runs with verdict different from OK and WA;
 Wrong answer - you will be notified if it runs with verdict different from OK and WA;
 Presentation error - you will be notified if it runs with verdict different from OK and
PE;
 Memory limit exceeded - you will be notified if it runs with verdict different from OK
and ML;
 Failed - you will be notified if it runs with verdict different from OK and RE (run-time-
error).

The setting Run on package is not used now.

Invocations

Select the solutions and tests you want to run. On this page you can see detailed reports
about invocations. Invocation rows in grid are highlighted if at least one solution got
unexpected verdict on at least one test.

Comments

You can discuss problem here. Comments are not a part of the edit session (working copy),
so your comments will be visible just after you sent them.

Packages

Packages are ZIP-files containing problem files in some special format. Typically packages
are used by Online Judges. Polygon supports flexible model
for packaging. In future versions you will be able to select the package format, but now we
are using popular format. 
Package contains compiled sources, but doesn't contain generated tests. To generate tests
in package run "doall.bat" inside the package.

You can't create package if you have changes in your edit session. Commit the changes
before package creation.

Manage access

Read about user permissions above.

You might also like