F Prime GDS Parsing Error on Bootstrap

[ianstein17]

When attempting to start up GDS on the local host using fprime-gds in the deployment directory, I get a parsing error dealing with Fw.String. The full terminal is shown below:

When a fellow student attempts to build with the same project/deployment/build/etc., albeit on a different machine, the error does not occur. I initially assumed this would be a project parsing error dealing with our use of Fw.String in a single component. However, after commenting out all the sections including said type, the error still occurs. Is there a possible F Prime explanation for this?
Note: I have also already tried re-cloning the entire project and re-generating.

[thomas-bc]

@ianstein17 Fw.String is an abstract type in FPP, I'm guessing it's not getting added to your dictionary for that reason, and therefore the GDS fails to parse the type when loading the dictionary. There might be ways to circumvent this... but I'm not aware of them.

Why not use the FPP string type? Or you could define your own string type for your project.

[ianstein17]

That fixed the issue. I am a little confused as to where we would define abstract types. Is the dictionary referencing the deployment of a project, or is it found somewhere else? Thanks for the timely response!`

[LeStarch]

Types defined in C++ are "abstract" in terms of the FPP model because no information can be inferred about them. Thus placing these types in Events, Telemetry, and Commands is disallowed. This is because the GDS would need to know information about these types to send and receive them and such information is not known outside of C++.

This is why the FPP string type is used. FPP knows string and thus can ensure that the dictionary generated for the GDS knows about string too. @bocchino please correct if I have gotten any details wrong.

[timcanham]

We should make it a FPP compiler error if abstract types are included in ground interfaces.

[bocchino]

This is on our to-do list. See nasa/fpp#236.