You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently gr1c uses exit codes both to indicate errors (including unhandled signals, e.g., segmentation faults) and to report some results, e.g., realizability. This can cause confusion when other programs are interpreting exit codes, especially in situations where negative exit codes are converted to positive integers.
To address this, gr1c should give output in a machine-readable form for all operations (not only synthesis) and outcomes. Thus, other programs would only need to consider nonzero exit codes as errors and can otherwise only attempt to parse gr1c output. Consider keeping some or all of the current usage of exit codes from gr1c to facilitate shell scripting.
Currently gr1c uses exit codes both to indicate errors (including unhandled signals, e.g., segmentation faults) and to report some results, e.g., realizability. This can cause confusion when other programs are interpreting exit codes, especially in situations where negative exit codes are converted to positive integers.
To address this, gr1c should give output in a machine-readable form for all operations (not only synthesis) and outcomes. Thus, other programs would only need to consider nonzero exit codes as errors and can otherwise only attempt to parse gr1c output. Consider keeping some or all of the current usage of exit codes from gr1c to facilitate shell scripting.
This feature request is motivated by a comment in tulip-control/tulip-control#152.
The text was updated successfully, but these errors were encountered: