improve 'l2h' lua to c-header converter script about crow

[trentgill]

Closed in favour of #122 which i'd like to keep open as it will become necessary at some point if the libraries continue to grow in size.

[simonvanderveldt]

ed note: This whole process could likely be deprecated if some smart person figures out how we can upload lua bytecode to crow directly, rather than manually convert everything into C strings & load them at runtime. The key benefit here is that lua syntax errors will be caught by that process (using luac i guess), and perhaps smaller RAM footprint (because the C strings aren't loaded into memory at all).

Would that be something like this? https://github.com/nodemcu/nodemcu-firmware/blob/8d091c476edf6ae2977a5f2a74bf5824d07d6183/docs/compiling.md#compiling-lua-on-your-pc-for-uploading

[trentgill]

Yes, and specifically the LFS concept (https://github.com/nodemcu/nodemcu-firmware/blob/8d091c476edf6ae2977a5f2a74bf5824d07d6183/docs/lfs.md) is what we really need I think. The issue being that even if we can precompile the lua libraries, they will currently still be copied from flash into RAM, which saves us nothing but startup time.

After a quick read about LFS, it seems like this is a big endeavour, and likely something that requires another developer to make a reality.

The big benefit is that we would free up a huge amount of RAM (presently Lua takes up over 100kB at boot time, and we only have 256kB total, a good chunk of which is devoted to hardware buffers & runtime processing). In practice we only get access to about 50kB of RAM in the VM before crashes or memory errors occur. If someone takes this project on, it would more than double the free memory available to scripts. This would have the added benefit of enabling support for >8kB userscripts (currently limited by the RAM allocation that happens while uploading & compiling on chip).

[trentgill]

This conversation seems to belong at #122 rather than here, though even that issue is not quite clear about what needs to occur or what the motivation is. New issue altogether?

[simonvanderveldt]

Yeah, might be better in #122 or as a new issue, although I guess the question remains if anyone would have time to work on it. If we know upfront that won't happen then maybe it's not worth the effort of creating an issue for it.

The items remaining in this issue seem minor, especially since comments are already stripped.