Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Flexible Lua distro — Gideros Forum
  • Home
    • ›

    Flexible Lua distro

    PaulRPaulR Member, Maintainer
    in Roadmap
    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:
    +1 -1Share on Facebook

    Comments

    • hgy29hgy29 Maintainer
      Actually Gideros base code should still support lua 5.1, it is a compile time switch
      +1 -1Share on Facebook
    • keszeghkeszegh Member
      and then zerobrane studio debugging would work too i guess... which is a big pro.
      Longtitle Productions, creator of
      Fragmenter - animated loop machine and IKONOMIKON - the memory game
      +1 -1Share on Facebook
    • 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!

      +1 -1Share on Facebook
    • MoKaLuxMoKaLux Member
      edited September 2022
      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
      +1 -1Share on Facebook
    • 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.

      +1 -1Share on Facebook
    • 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
      +1 -1Share on Facebook
    • 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!
      +1 -1Share on Facebook
    Sign In or Register to comment.