One thing I've thought about on and off for Gideros is having the ability to switch Lua versions. Luau performs better than Lua, which is great, and then LuaJIT with code written in a JITty style, making use of FFI, is in another league. On platforms that support it, so fallback to no-JIT LuaJIT, Lua or Luau for HTML/iOS would be necessary.
But whatever the pluses and minuses of any particular implementation, the concept of choosing a Lua version to use seems like a solid, future-proofing idea. Even if not for current implementation, developing Gideros in a style that doesn't more tightly couple to a specific version should be something to think about imo.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
@keszegh : yes, the functionality is there to build the Lua version at the moment so you could build it, but that's not really an end user thing to do. The point about ZBS debugging sums up the advantages of embracing different versions.
In a Not To Distant Future, Gideros Luau has multithreading with an API-compatible extension for standard Lua versions. People can get all of the advantages of each version and take advantage of the 100,000s of hours of time spent developing, integrating and battle testing the wider Lua ecosystem!
- LuaU C API is slightly different from Lua 5.1, so core lua bindings have to be compiled differently depending on lua version used
- Plugins also need to be recompiled depending on exposed lua api
- Having to manage different lua versions will complicate the maintainability and evolutions of Gideros
- Some platforms don't support LuaJIT (HTML and iOS)
- The easiest way to cope with the first two points of this list would to build two or more versions of Gideros, one for each lua, making compile time much longer and download sizes too
- Gideros LuaU is not really that different from standard lua, and mostly compatible code-wise, so the real benefit of getting the possibility to switch back to Lua 5.1 or Lua JIT is ZBS/Debug support for one, and speed for the other but point 4 is on the way
To test, I deleted those directories and zipped the latest Gideros and the 7z file is 110MB. Since few people will use all of the plugins or all of the templates, overall bandwidth should be reduced, even with extra individual size involved in providing multiple targets.
For compilation time, I think making use of branches and GitHub Actions would be a good idea so that the cloud takes the strain (and energy bills!!) of full rebuilding for all platforms for a release. Work on a dev branch and set Actions to trigger on merge to master.
Maintainability and evolution is something to seriously consider, there are no instant answers for that one!