Feature Request: File-based blade styles

[itsjohannawren]

I can hear the complaints about memory use and errors already, so hear me out.

Things that would need to be created:

• A blade style profile file format - Maybe just use the format from the blade style editor
• A blade style profile file name - blade.txt?

Things that would need to be added:

• A parser for the blade style profile file format - This would be the hardest part because your not just taking a value from a line, you'd be creating a data structure that mirrors the structure in a file. It would have to know what's valid where in addition to knowing how to parse all the different styles and keep track of where it is in the structure.
• A built-in error style to indicate a failure to parse a blade style profile file - Dirt-simple Blinking<Red,Black,500,500>

Things that would need to be modified:

• Style Search - Add an attempt to load a file-based blade style profile before searching for a built-in style while loading a font. It should gracefully fall through to looking for a built-in style if no blade style profile file is found in the font directory. If it does find one but there's an error in it, the built-in error style should be returned.
• Font Change - A loaded file-based blade style profile should be unloaded (freed) when a font change is initiated.

Most of this is within my ability, but the parser is most definitely not. I'm honestly not sure where to even begin, especially since I write C, not C++ ;-) Definitely willing to learn, but I'd still need pointers on where to start.

[profezzorn]

While doing this with a parser is indeed the straightforward option, it would take a TON of memory, because every style has to be available for use. In addition, the link between the styles has to be dynamic instead of static. (Think virtual functions) which makes it a fair amount slower than what the statically linked templates we use today.

Perhaps another way to do this though, would be to use something like dlopen() to load the styles.
Each style would then be a binary file which could be loaded from the SD card.
We would need a symbol table as well, so that we can resolve pointers in the loaded code to the fusor and other such things.

The binary files could be built, copied and shared. In fact, we might be able to make the style editor create them directly.
The drawback would be that we would need to load the code into RAM, which is more limited than flash memory. Not sure if we would have enough of it.....

[itsjohannawren]

I was thinking about this more, @profezzorn. Is something like Linux's execute in-place available? IIRC, it effectively mmap()'s the sections of the binary to let them execute without actually being loaded into RAM. Granted, this functionality is really limited to flash memory with the right filesystem (not FAT), but it could be an option.

What I need to do is really dive into the code to figure this out.

[profezzorn]

Short answer is no.
First of all, there is no mmu, so there is no mmap, or anything like it.
Second there is no real OS, so anything like this that we want to add, we have to write it ourselves.
It's not impossible to load code from SD and run it, but will have to be loaded into RAM, and it's not an easy thing to write.

[itsjohannawren]

So much for that shortcut ;-)