fprime
fprime copied to clipboard
nasa
External enums have junk values in text log
| F´ Version | 2.0.0 |
| Affected Component | All |
Problem Description
When an external enum is an argument to an EVR, the value in the GUI log is correct (the name of the element), but the text log prints out a large number.
How to Reproduce
- Define an enum in EVR
- Emit the EVR
- Look at the text log of the same EVR
Expected Behavior
The text log should print the integer value of the enumeration.
Looking deeper, the old inline enums have had %d format specifiers, so that local text logs would print a decimal value to the screen. The GDS would detect this and switch the %d to %s for the python code to display it.
If you use %d with external enum classes, it prints the pointer value, since the autocoder passes the string from the enum class's toString() method.
toString() is meant to be an optional function which can get turned off and on by FW_SERIALIZABLE_TO_STRING. If a project wants to regain space by turning off FW_SERIALIZABLE_TO_STRING, the code will break. Instead, the format string should use %d and the e member of the enumeration class object for the text log value.
Could we have the autocoded enum provide a special version of toString that prints out the numeric value in the case that FW_SERIALIZABLE_TO_STRING is disabled?
No, this is not fixed yet. I think we need a general solution that will work for all serializable types. In general, any serializable type can go into an event argument. If FW_SERIALIZABLE_TO_STRING is turned off, it's not clear what we should do. We can special case enums to print out the value, but this won't work for other serializable types. Can we require that FW_SERIALIZABLE_TO_STRING is turned on if text logging is turned on? Otherwise I don't see how it can work in general. If we can't represent serializable types as strings, then how can we allow them as arguments to text logging?
I suppose we could selectively break text logging, e.g., print out some "unknown" value for types that don't have a text representation, and special-case enums to work since they are important. But this seems undesirable. Also, how would we handle structs and arrays as text log arguments? Print an unknown value?
I think the bottom line is that FW_SERIALIZABLE_TO_STRING = NO, FW_TEXT_LOG = YES really doesn't make sense, given the way F Prime works (i.e., that serializable types can appear as event args).
Actually we don't need to support all serializable types in text logs, just the ones that FPP represents: arrays, structs, enums. So we could provide text conversion just for those when FW_TEXT_LOG Is turned on, even if FW_SERIALIZABLE_TO_STRING is turned off in general. Is this an acceptable compromise?
After discussion, when FW_TEXT_LOG = YES and FW_SERIALIZABLE_TO_STRING = NO we will (a) print out each enum value as a string and (b) print out a constant placeholder string for struct, array, and enum values.