Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Flexible Lua distro — Gideros Forum

Flexible Lua distro

PaulRPaulR Member, Maintainer
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.

Tagged:

Comments

  • hgy29hgy29 Maintainer
    Actually Gideros base code should still support lua 5.1, it is a compile time switch
  • and then zerobrane studio debugging would work too i guess... which is a big pro.
  • PaulRPaulR Member, Maintainer
    @hgy29 : yes, it's good to see that Lua 5.1 is still an option to build. What I'd ideally like to see is Lua versions chosen at runtime with LuaJIT as an option with no requirement for customisation (so attempting to load shared library symbols at runtime instead of hard linking, for example).

    @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!

  • MoKaLuxMoKaLux Member
    edited September 7
    I am for rhe simplest gideros we can get, not overcomplicating this awesome engine it has become. Kuddos to the developers.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • PaulRPaulR Member, Maintainer
    Leaving everything default is always an option, that's on the UI/UX side of things which is separate from features or direction themselves. None of this is a criticism at all, it's just a chat about the future and trying to be as inclusive to as many potential users as possible.

  • hgy29hgy29 Maintainer
    I am totally in favor of switchable lua versions, but I am not sure how to best achieve that goal taking into account that:
    - 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
  • PaulRPaulR Member, Maintainer
    Yes, not having the download size balloon would be very important. Even without any extra Lua versions or changes, having templates and plugins separately, and individually, downloadable would massively reduce download size.

    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!
Sign In or Register to comment.