When this was released I was super busy with the SRM 602 editorial to share it. But now I am not so busy (although I am making SRM 603's editorial as we speak). Let me take a break and talk about the final feature list for 2.0. No more features will be added to 2.0, the rc is only to detect bugs.
Flexible Templates
Greed 1.6 was cool and I liked it, but 2.0 is far more powerful because of what it did to the templates. In 1.6 you could only modify two templates : source (source code file), test (the tester put inside the source code file) and maybe unit tests for java and csharp. This made Greed just slightly more powerful that the other plugins. The new Greed though, can be programmed to create any custom file/sections of files for you using any template you add. Each template is a powerful script that makes it easy to build anything using information from the problem and contest. For example, Greed by default will make some templates:
- source: (same as before)
- filetest: New version of the tester, saves the test cases in an external file, so you can edit this external file to add new test cases.
- testcase: The text file that contains all the test cases .
- problem-desc: The problem statement in cool HTML format.
So by default Greed will already do pretty much anything you'd expect from a topcoder plugin. Will generate a source code file for you, with automated testing of the example cases and an ability to add new test cases. It will also generate and store in disk a version of the problem statement.
However, what's new is that you can modify / change all of this. You can add new files to test. You can replace the files that are created or the templates used for them. For example, by replacing the filetest template with the test template, it will use another kind of tester that doesn't use a text file to store the test cases and instead has them stored as code.... Or, you could use the [dualcolor templates]. Very advanced testers for c++ and python that I developed and do tons of amazing things...
Create makefiles, project files for IDEs, separate source code and tester, store the problem's memory limit in some file so you can tell your testing environment to enforce it. it is all up to your needs and creativity.
Template options
With the advent of custom templates, the need to configure them became very important. There is a difference between the plugin and the templates. So hardcoding configuration options for the templates in the plugin wouldn't work too well. Instead, we added a way to allow templates to declare configuration options and the configuration file can write them.
Basically , the template definition in config file has an .options {} section, each option is a String field that is read by the template, this enables the following features.
Multi-process tester in c++
All the 3 c++ testers available have the option to work in multiprocess. Which means that they will call a different instance of the program's process to test each example case. This makes testing more accurate if your program uses global variables. It also allows the testing to continue even after a runtime error in an early example. The runtime error is also reported.
Problem statement themes
The problem statement template is very useful and can be customized through template options. The most important customization is the color theme:
It is also possible to customize the CSS either by adding an extra file or by replacing the style completely. Of course, since the problem statement is a template, you can also change everything about it.
I personally use the Stylish firefox plugin
Hooks
You can now set a program to run automatically whenever a template is created. I currently have a trigger template that is created automatically whenever I open a problem. The trigger causes firefox to open the problem statement and jEdit to open the source code ^^
Aids to make folder organization better
I added something that allows the code to be placed in better-organized folders. I currently programmed my Greed to put all TCO problems in a folder, and split the SRMs in groups of 25. It is very useful and much better to me than having all problems in the same folder, or a single folder for each SRM.
Aware of time and memory limits
Greed is the only plugin I know of that actually knows of the per-problem memory and time limits. It uses them for the problem statement, but your custom templates can also make use of them. My tester uses the time limit, for example.
Modulo detection
This is so useful: http://vexorian.blogspot.com/2013/11/bragging-about-incoming-greed-features.html
How to get it
Greed 2.0 release candidate: in release page. It has a couple of minor HTML bugs ashawat just found, if you don't like those bugs, you can fetch the source code from git and compile. Speaking of which, I have a version of Greed in my github fork that sets up my prefered settings by default (The folder organization, the dark gray HTML template and my testers): https://github.com/vexorian/topcoder-greed
4 comments :
Nice! Don't know what they could possibly add in future versions of Greed :D
Ah!! I did not see that! Thanks!!
Probably a postprocessor for people that keep adding unused code to their programs.
If the O(d^2) solution is not possible, say n can be upto 10**18, can you think of any optimisations in this solution?
Post a Comment