Message6566

Author silvan
Recipients jendrik, malte, silvan
Date 2017-10-19.15:44:39
Content
> I don't really understand the motivation in the first two paragraphs. If I
> understand correctly, you are saying that us following the universal convention
> of "0" for "everything succeeded" would be inconsistent. In what way?
The problem is the definition of "everything succeeded". Currently, we only
return 0 if a plan was found, and any other non-zero exit code (as given by the
search) otherwise, e.g. if the task is unsolvable or if we reached the imposed
time limit. Why is in an "error" if the task is unsolvable or the time limit was
reached? If I impose a limit of 10s then I am well aware that in many cases, no
plan will be found.

Maybe we can redefine "everything succeeded" to be those cases where no
"unexplained" error occurred, where unexplained errors are those where the
search returns "CRITICAL_ERROR", "INPUT_ERROR" "UNSUPPORTED_ERROR". This means
that fast-downward.py would return 0 for *all* instances if nothing went
*really* wrong.

> Having the driver output the individual exit codes of the components could be
> quite useful. 
Ok, outputting the individual exit codes and parsing them with lab seems like a
good way to go.

> But I think that doesn't imply that we shouldn't attempt to have
> it produce a meaningful exit code itself.
Well, what is a meaningful exit code? Passing on the search's exit code as we
currently do? As explained above, I don't think that this is "meaningful"
currently. Also because it doesn't return anything meaningful at all if the
search is not run.
History
Date User Action Args
2017-10-19 15:44:39silvansetmessageid: <1508420679.58.0.334196600121.issue739@unibas.ch>
2017-10-19 15:44:39silvansetrecipients: + silvan, malte, jendrik
2017-10-19 15:44:39silvanlinkissue739 messages
2017-10-19 15:44:39silvancreate