Bug in -conservation_dirs argument parsing

[David Jakubec]

Hi,

I think that the "new" option -conservation_dirs parses its arguments incorrecly. Say my dataset definition file coach420.ds is in ./datasets/, specifying -conservation_dirs coach420/conservation/e5i1/scores/ results in [INFO] DatasetItemLoader - Conservation lookup dirs: [datasets/oach420/conservation/e5i1/scores]... in other words, the first character of the specified path is lost and the conservations are not loaded. One has to do a workaround, e.g., use the option with an extra character (X here), -conservation_dirs Xcoach420/conservation/e5i1/scores/ for the desired path to be used correctly.

This is especially unfortunate in combination with #36, as the user is informed in no way of the error (i.e., that no conservation files are actually being parsed) unless they check the logs specifically to verify this.

David

[rdk]

Fixed on develop branch and will be released in v2.3

Problem was that param value parser expected every list param value to start with '(' and end with ')'.

Workaround for earlier versions is to use parentheses, for example:
-conservation_dirs '(coach420/conservation/e5i1/scores/)'
or for 2 dirs: -conservation_dirs '(coach420/conservation/e5i1/scores/,coach420/conservation/e5i1/scores2/)'

[rdk]

@davidjakubec thanks for the report by the way. I agree that it was very unfortunate in combination with #36 .

To check if conservation is loaded properly it is a good idea to run it first in -fail_fast 1 mode.
Default behaviour is that the program does not fail when conservation score file is not found. The reason is that usually in any bigger dataset there are some chains on which calculation of the conservation fails.