32-bit builds using the development headers work on the legacy 32-bit branch so I don't really see a reason to not support it..
sure, it sucks that I now won't be able to get rid of a pretty gnarly codepath, but /shrug
LuaDevice now works fully, without any weird bugs. Yay!
This took quite a bit of bugstomping to arrive to; some of which ended up discovering I'm not particularly proud of doing. Oops!
The LuaCpu implementation no longer has a UART implementation in C++ (which actually leaked everytime a LuaCpu was garbage collected... Yeesh) - instead the Lua entity code actually implements the UART! Pretty cool to see the fruits of my labor actually working!
The LuaHelpers macros are renamed slightly to make them less of a pain (and also because I think having `_IMPLEMENT` in a function implementation is a bit stupid.)
I have updated the ideas document to better reflect my plans for the project system.
now i can like, actually finish this thing
i will probably commonize all the stuff the luadevice class is doing right now into its own object, since I think that it would be very useful to have elsewhere. but for now it's not common :(
It now doesn't assume literally every device would map something to memory.
This should also fix some API orthogonality issues (ergo the CPU being treated specially)
I could have implemented a spdlog sink, however spdlog isn't setup for standard format header being a thing yet.
This also introduces a temporary executable target for my own testing of lucore utilities.
Lily Tsuru