#114: per-variable tolerances for Cactus testsuites --------------------------+------------------------------------------------- Reporter: knarf | Owner: tbode Type: enhancement | Status: review Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
I looked at the patches again. The very latest patch has an issue where it seems to pick the second matching (non-'.*') pattern instead of the first one. Another thing that I found confusing is that the order of the regex (ie. which is first, second etc) is determined by sorting the regular expressions alphabetically (not eg. the order in which the patterns appear in the file).
Tanja promised an updated patch for the first issue. For the second: this seems to be completely avoidable if we only allow a single (non-'.*') match which should not be too hard to construct. If one really ever needs something like: {{{ g[xyz][xyz]...asc 1e-9 g[xyz][xyz].d.asc 1e-8 }}} Then one can simply change the first pattern to {{{g[xyz][xyz].[xyz].asc}}}. This might yield a number of warnings if a new pattern is added that conflicts with existing ones but that seems preferable to having a new pattern silently overwriting existing ones. The uniqueness requirement means that it is sufficient to find the single matching pattern when creating new entries rather than having to understand all patterns to deduce their applicability. Implementing an order based on the order of which the patterns appear in test.ccl is annoyingly complicated (unless one uses a third party module Tie::IxHash which Tanja found) since hashes in Perl do not preserve the order in which entries were added. So for now I would suggest we go with Tanja's initial implementation that only allows a single match (beyond '.*') and then if and when we encounter a situation like then one Frank described in comment 8 someone can go back and add this option without breaking backwards compatibility. It would seem good to me to have some implementation ready well before the next release so that we have time to test it.
So: please apply (the patch looks good) with the second vs. first issue fixed and maybe even with the original uniqueness requirement.