Question about type remapping

[tstern-masten]

Hello,

I have been working lately on getting Rust executables integrated into the auto-yamcs process. I have been able to parse the information through juicer as expected with some tweaks; however, the conversion from the formatted SQLite database to XTCE winds up dropping information.

I am still working through why this is but my leading theory is a type error due to Rust's syntax. For instance a 32 bit unsigned int in rust is the symbol 'u32' where as it appears the tool expects 'uint32'.

My plan was to remap this type using the squeezer.py in standalone mode and was wondering if there is any documentation on how best to do that. My main questions are should it be performed prior to tlm_cmd_merger or after and is there a specific symbol list I should be referencing?

Additionally I noticed that the formatted database usually has multiple entries for a given type. For instance the uint32_t will show up as "uint32_t", "__uint32_t", and "uint32". This might be my unfamiliarity with dwarfs symbol structure, but I am unsure which of these is needed for the final XTCE conversion.

I really appreciate any and all help on this and plan on contributing back our findings with Rust.

Thank you, Tim

[lorenzo-gomez-windhover]

Hi there,

It's really cool to see people trying to use this with Rust. It does make sense that that it will fail if the symbol names are different, especially the XTCE tool. Essentially the only place I can think of in the code that will have to be updated is the following:

    def __is_base_type(self, type_name: str) -> tuple:
        """
        Checks if type_name is a base type as it appears in the database.
        :return: A tuple of the form (bool, str), where the bool is whether this is a basetype or not and what the
        base type maps to in our BaseType namespace. Please note that this function does not pre-append the BaseType
        namespace to the type, that is the responsibility of the caller. Please note that padding types are also
        considered base types. Padding types have the form of _padding[Number Of Bits] such as _padding8.

        NOTE:While strings are considered a base type, it should be noted that, as opposed to all of the other base types,
        they are created as needed. This is because we can't really predict their sizes, like we do
        ints, not even a range as a string could be of any size. Thus they are created on the fly.
        """
        out_base_type = (False, '')

        if type_name == 'int64' \
                or type_name == 'int32' \
                or type_name == 'int16' \
                or type_name == 'int8' \
                or type_name == 'int':
            out_base_type = (True, 'int')
        elif type_name == 'uint8' \
                or type_name == 'uint16' \
                or type_name == 'uint32' \
                or type_name == 'uint64':
            out_base_type = (True, 'uint')
        # FIXME: char types need to be handled properly
        elif type_name == 'char':
            out_base_type = (True, 'int')
        elif type_name == 'boolean':
            out_base_type = (True, 'boolean')
        elif type_name == 'float' or type_name == 'double':
            out_base_type = (True, 'float')
        elif type_name[:8] == '_padding':
            out_base_type = (True, '_padding')
        elif type_name == 'string':
            out_base_type = (True, 'string')

        return out_base_type

It does make an assumption about the names. This is an open source project so you are more than welcome to make a PR with this fix which it looks like(from the info you've provided) should be pretty straightforward. One thing I might have to double check with my team is figure out if we want to just add something in configuration that says "Rust" mode or do we just want to add another list of Rust symbols to this function. But that does seem kind of sloppy as it might not be very explicit to the reader why we are including so many symbol names in one function.

Another thing that would be extremely helpful(if at all possible) is if you could provide that database file that juicer outputs from Rust. But I would understand if this is not possible.

Hope this helps, Lorenzo

[tstern-masten]

Excellent! Thank you for the quick response! I was able to add some additional checks for the rust type and got my fields as expected.

The only part of my message structure that I am still having trouble with now is the header. For reference I have two structures:

struct Header
{
    int id;
    int length;
};

struct TestStruct
{
    Header hdr;
    string name;
    uint32_t id;
    bool active;
};

From there I define my config as the following:

commands:
      DUMMY_APP_CMD_MID:
        msgID: 0x0001
        commands:
          TestStruct:
            cc: 0
            struct: TestStruct

While I see my header in the database I do not see it in the XTCE. I would image this is because Header is not a known type to the conversion.

Would this be a use case for the header_mod utility or is there another part that I am missing?

Thank you, Tim