I doubt the serialisation / deserialisation code will ever be generic enough for inclusion in
libavr32, but if anyone knows of a parser combinator library for C that doesn’t heap allocate I’m all ears.
Rather we need to separate the serialisation code from the IO code, that way we can move it from
module where it’s incredible hard to test and debug to
src where we can write unit tests and use
(Does everyone know what I mean when I say
This is particularly important as we will need some sort of forward compatibility1 for presets, and maintaining that will be impossible without some sort of automated testing. And that in turn will give us the freedom and confidence to adjust the preset format for new features going forwards.
My suggestion is that we add 2 functions to
void tele_serialise_scene(tele_scene_t *scene, char[MAX_TEXT_SIZE] *output);
bool tele_deserialise_scene(char *input, tele_scene_t *scene, char[MAX_ERROR_SIZE] *error_text); // returns false on error
Neither function is allowed allocate or do any IO, that will be handled by the caller. AFAIK scene text files aren’t that big, we may choose to statically allocate some space for the buffer for the
module code rather than deal with
The error text can either be displayed to the user, or saved to an
error.log file on the USB stick (or both).
But most importantly it will allow us to build up a corpus of presets to test against. The easy path would be to just assert that they must parse. The harder route would be to assert that they parse and check the value. It’s possible that we could build some tools to turn a script into a C file with the structs in it so that we may quickly generate the data.
Anyway, that’s what I would do if I had the time. Alas, I don’t. So it isn’t for me to say whether you should go this way or not!
1 I suggest we do place some limitations on forward compatibility, e.g. we only support import presets saved under the previous X releases.