Basic Usage

This page covers the basic usage and provided functionalities and templates of Greed.

Configuration

Again, everything in greed is configurable.

Here's a simple list of configuration keys for basic usage.

• greed.codeRoot specify the root directory for Greed to generate your code in.
  It's a relative path to your workspace, whose default value is ., meaning the root of your workspace.
• greed.language specify all the language template definitions and details
  • templateDef is a map, whose key is the name of template, and the value is the definition of the template.
  • cutBegin and cutEnd are special one line comment which marks the code to be removed when submitting.
    Usually it's different between languages.
  • templates is a sequence of templates to be generated.
    Default value is [ filetest, source, testcase, problem-desc ]. (See below for these templates)
  • submitTemplate is the name of template to be submitted, default set to source.

The templateDef which specify template definition is usually for advanced users and documented in the full configuration page.

Special keys

There's a special key for C++ language, greed.language.cpp.longIntTypeName, which can specify an alias for the type long long when rendering the template. This is because people define all kinds of aliases for long long, like LL, int64, long and so on.

Default stuff

Greed provides rich default stuffs, all kinds of templates, especially test templates. Here's a list.

Default folder structure

For each contest, Greed generates the code in the folder <YOUR WORKSPACE>/${Contest.Name}. You can change this, especially by applying some string transformers to normalize the contest name, described in the named renderers section in the template engine page.

Template preliminaries

Template output

Templates can output to a model key (which is used further by other templates), or files, or even nothing (implicit generated and bound before who are dependent).

Template options

Each template have some predefined option keys, to enable tweaking the template directly from config, without modifying the template itself. Bitchen feature brought up by @vexorian.

Template overwrite options

Template has an overwrite option, available values are force, skip, or backup. Note these options only work on templates with file output.

• force will overwrite the file directly
• backup will first backup the original file (if any), then overwrite
• skip will drop the output if there's already one

Note that, the Regenerate code on the arena panel, will upgrade skip to backup, to enable faster debugging for user custom templates.

Template dependencies

Templates are dependent, like in a workflow. A template can only be generated after all its dependencies got generated first. The sections below only describes the given templates, and concrete template features are beyond this page.

To read more about this, please refer to Template definition in full configuration page.

Provided templates

Template name	Dependencies	Overwrite	Output
Testcase	None	skip	.sample
Problem description	Styles and Themes	force	.html
Source code	key(TestCode) or Unit test	skip	source code file
File test	Testcase	N/A	TestCode key
Legacy test	None	N/A	TestCode key
Unit test	None	skip	UT code file
Dualcolor test	None	N/A	TestCode key

Testcase

The testcase template generate a file containing all the samples, usually called ${Problem.Name}.sample. The format is as follows:

• Each testcase is identified by a labeling line which starts with --
• Each line represents a parameter or the output.
• If the data itself is an array, there should be multiple lines. Leading with a line with its length, and following by several lines with each of its content.
• The input and output are separated by an empty line. Actually, this line is ignored no matter what's in it.

Problem statement

Now greed also generates problem statement into a HTML file ${Problem.Name}.html, in the folder. The problem statement template is called problem-desc, it has a number of options documented in the full configuration page.

But one thing we can tell you here, which is, the template is bundled with some themes, in order for easy UI tweaking.

To set them, use template options:

  greed.[shared/language].templateDef.problem-desc.options.theme = light/blue/dark/low-contrast

Source code

The source code template contains both class and method signature, and testing code (if any test template is used). Generated file is ${Problem.Name}.??, in which ?? is the default extension for different language. The testing part is described in the following section.

It's possible to split most of the test code with the source signature, by making use of the powerful template mechanism of Greed and different module features in each language. Although this is not implemented by now, it would be in the future, since Greed is now powerful enough to do this. Any contribution on this is greatly welcome.

File test

This is the default templates for all languages in 2.0. It depends on the testcase-template generated file, whose format is described in the previous section.

The generated code will read data from the file, and perform testing. Available for all languages and no specific settings are needed.

Legacy test

Greed 1.x generates test code including the test data, which makes your test code very messy. But what can I say, maybe many users like this way, because that's what the old Topcoder plugins like TZTester did.

So in 2.0 we still leave this template here, to use it, put the following in greed.conf.

greed.language.<lang>.templates = [test, source, problem-desc]

This kind of template is available for all 4 languages.

Unit test

This is brought to you by @tomtung, amazing idea and also available for 1.x! Greed generate unit test code, for famous unit test framework like junit. Each sample data forms a unit test case and you can use your favorite IDE to test your code, which really keeps your source code clean!

To use it,

greed.language.<lang>.templates = [source, unittest, problem-desc]

By default, the generated UT code is suffixed by a Test after the problem name, which is the default name for the source code.

Only available for java (junit) and c# (nunit).

"Dual color" test

Beautiful test template for c++ and python, created by @vexorian.

A different kind of tester for c++ (Cutting edge (gcc 4.8.1) c++11 is required) and Python. Output is colored so that things are highlighted. They use different code file for problem-specific source code and the tester. The example testing has many features such as allowing custom test cases with unknown value and disabling some test cases.

See this link: https://github.com/shivawu/topcoder-greed/tree/master/src/main/resources/templates/dualcolor for more info.

C++ tester using multiple processes

The c++ versions of the file test, legacy test and dualcolor-test templates supports running each test case in a different process. This feature is disabled by default but if enabled allows the tester to detect runtime errors and to simulate a clean global state for the start of each test cases.

[shared/language].templateDef.filetest.options.runMultipleProcesses =  true
[shared/language].templateDef.test.options.runMultipleProcesses =  true

Read the full configuration page for more info.