zen0wu / topcoder-greed

greedy editor for topcoder arena
Apache License 2.0
229 stars 48 forks source link

Change the default value of testcase.overwrite to 'force' #142

Open mugenen opened 10 years ago

mugenen commented 10 years ago

Python raised ValueError while reading a sample input because int() cannot parse long integers with 'L' like '1L'.

Values are printed as-is in PythonLanguage#renderParamValue(). However, Java is selected first in topcoder arena. Therefore, long integers are printed with 'L' in JavaLanguage#renderParamValue(). Though I changed language to Python in arena, *.sample file was not updated.

To fix this issue, the default value of testcase.overwrite should be 'force'.

wookayin commented 10 years ago

I think the sample itself is improperly rendered. Sample input should be in a canonical form (e.g. no 'L' suffixes for long types).

mugenen commented 10 years ago

I don't know why Greed renders samples's long integers with the 'L' suffix for Java and C#, and the 'LL' suffix for C++. If the suffixes are not needed, I agree with your opinion that sample input should be in a canonical form.

zen0wu commented 10 years ago

Sorry I'm no expert in python. But I do think changing the default behaviour of testcase overwrite will not solve this. If the int() function cannot parse a string of integer suffixed with L, it's the fault of the L. We should remove the L since python doesn't differ long and int, am I right?

mugenen commented 10 years ago

We should remove the L since python doesn't differ long and int, am I right?

I'm afraid I don't understand what you meant. I think L suffix is alreadly removed from PythonLanguage#renderParamValue(). Thus, long integers are NOT suffixed with L for Python. However, long integers for the other languages are suffixed L or LL. Even though long integers are NOT suffixed for Python, int() cannot parse long integers because a string of long integers suffixed with L are generated for the other languages and not overwritten by the default behavior when I change language to Python. Though we can remove suffixes when reading input, the bahavior for some languages should not be affected by the behavior for the other languages..

zen0wu commented 10 years ago

Ohhh, I see what you meant. Sorry for the misunderstanding.

The point of the skip was that you may want to add your custom testcase, and setting it to force will overwrite your change, which may cause trouble. Another way is to adjust the int() parser to a more advanced one which can handle this situation, like using regex to extract the prefix of the string. What do you guys think?

mugenen commented 10 years ago

I see the benefit of the skip.

wookayin proposed above that "Sample input should be in a canonical form (e.g. no 'L' suffixes for long types)." If it is possible, the testcases for all languages are in the same format. Therefore, force or ad hoc parsing is not needed. What do you think of wookayin's proposal?

zen0wu commented 10 years ago

Yeah, that may be a good idea, but it means that the testcase template is specially treated when rendering, and greed may be lack of methods to do that (treat some template specially), I may take some time to look at this.

wookayin commented 10 years ago

An example of 'LL' suffixes in the test case: TCO2012 R1A EllysFractions (the test is not working properly)