chermehdi / egor

A Command line tool for automating testing and task generation for competitive programmers

Egor

Description

• as most Competitive programmers don't have the luxuary of using IDE's such as intellij to benifit from the CHelper tool (maybe because they don't like the added overhead of IDE's or the prefere eclipse or, as most of the people i know, they use C++, parsing tasks can become tedious, and here where egor can help, by providing a simple cli for parsing and running your tasks.

Installation

• To install you should have python3 installed, if that's the case you just need to run pip install egor.
• If you have multiple versions of python you need to explicitly run python3 -m pip install egor to be sure that python3 is used.

Usage

• Just install egor by doing pip install egor
• You should also install (if you don't already have it) Competitive companion
• And voila, you can start using it as any other command line app, just type egor to see the help, and there is help for every subcommand provided by egor

• Open a codeforces or a spoj problem, run egor task parse and press the plus button of Competitive companion, a new directory with the name of task will be generated, with the input and output files, and a sample source file.
• When you write the solution for your problem you can type egor task test to test your solution against the provided sample input.
• You can run egor task copy to copy the source code of your solution to the clipboard
• The location of the configuration file to configure some default values is ${home_dir}/.egor/configuration and it's in the reStructuredText format,This is sample fo a configuration file:

    [egor]
    egor_port = 6174
    egor_default_lang=cpp
    
    [core]
    first_run = yes

• in doubt you can always run egor task -h to see the help of commands.

Developer guide

• You should have pip installed
• Clone the current repository, and run pip install -e . to have a version of 'egor' installed in your machine so you can test it
• Unit testing is important, any added feature should be associated with a unit/integration test
• At least one reviewer should see your code before merging to master.

Contribution

• You can contribute to the project by raising issues, writing tests, suggesting features, and making pull requests.

egor's Issues

Add custom test cases

User must be able to add custom test cases, and he can specify the output file as well as no output file at all if he only wishes to run a case which he don't have the correct output.

Custom templates

Add the ability to use templates from templates with some good features:

• Ability to specify these templates in ~/.egor as EGOR_JAVA_TEMPLATE, or as an env variable
• Inject metadata about the task into the template so that people can use them in comments or in logging. {TASK_NAME}, {TASK_LINK}.

Time/Memory/Output limit

We can't just run the code without any time/memory/output limit.

Also I suggest adding a ProcessManager which manages calling out os processes and getting out the output/error streams, manage limits, exceptions, etc...

Code linter

Add a code linter library to:

• Avoid multiple collaborators adding different code styles
• Enforce writing module/class/methods comments

Watch mode

Add watcher mode that watches the main file of each task in the contest and recompile/run the code if necessary. The watcher should be able to:

• Watch files for any modification (Including changing current tests or adding new tests)
• Add a file called ".task_metadata.json" in each task folder to keep track of tests and template link, etc.
• Hash files before running + keep track of old runs = Don't rerun if it's the same test/code
• Log all of these compiling/running to the user. If passed just show "PASSED" in green, if not print "FAILED:" and print the two outputs failing. (Limit the output to 1000 lines if necessary)

Add wiki to the project

Add wiki description to act as a manuel to the application for new users.

Exact libraries version in requirement.txt

I don't see why it's needed to have an exact version of a plugin/library in requirement.txt (using ==)
I think using a range based restriction would be a better idea.
The priority of this is very low for now, but let's keep that in mind.