State of LuaRT

Samir

Hello everyone,

It has been several months now that LuaRT 2.1.0 has been released. It is now time to give you an update on the situation. Indeed, recent changes in my personal and professional life mean that the time dedicated to the development of LuaRT is limited.
Despite everything, I have many projects in mind to continue the development of LuaRT. But maintaining such a codebase alone becomes more and more complicated.

Also, any help would be welcome, especially for future developments:

Migrate LuaRT to Lua VM 5.5.0
Develop a LuaRT Debugger extension for Visual Studio Code
Make LuaRT multiplatform by further separating the LuaRT core from sys and console module
Continue the development of the module dedicated to WinUI3
Rework of network module (HTTP requests mainly)

I hope you still appreciate LuaRT. I am still convinced that LuaRT remains the simplest and fastest way to develop applications for Windows, and hopefully soon for Linux and MacOS, using a coherent ecosystem, object oriented and modular, powered by the Lua VM.

Sincerely,

Samir

steve64

Hi Samir, as you know I personally appreciate LuaRT a lot.
Its strongest selling point for me (besides being Lua-based of course) is the almost unique ability nowadays to generate compact standalone executables for applications including GUI, networking, database, ecc.
Unfortunately, I'm currently too busy to contribute directly on development, but I can at least support LuaRT in testing using my applications and providing some suggestions on priorities for next steps.
This is my view on the future areas you mentioned:

Migrate LuaRT to Lua VM 5.5.0: interesting but not urgent, I would say low priority (IMHO)
Develop a LuaRT Debugger extension for Visual Studio Code: I do not like VS Code but current LuaRT Studio IDE has some stability issues (unexpected crashes) and some solution is needed (fix Studio or invest in VSCode), I would say mid priority
Make LuaRT multiplatform by further separating the LuaRT core from sys and console module: this would be a dream, I'm targeting both Win and Mac and a cross-platfom LuaRT would fill a real requirement; I would say highest priority, but supporting the GUI part is expected to be hard, unless relying on a portable UI library (but a compact one); it could be also useful a cross-platform console-mode LuaRT w/o GUI but with network/database/json
Continue the development of the module dedicated to WinUI3: very appealing but having to choose I see as more strategic to invest on cross-platform
Rework of network module (HTTP requests mainly): I think current module is quite nice already, but of course any improvement is welcome, low/mid priority, HTTP/REST/API client is a primary target,

Finally, I would put integration with AI services as very high priority as well.

All the best to go on with your LuaRT!

Samir

Hi Steve,

Thank you for your support I do agree with your comments.
Concerning LuaRT Studio, the problem is architectural : it depends on Zerobrane Studio, which is a fork of an old Lua iDE, using a fat gui library (wxLua which is abandoned) and coded in Lua 5.1 (because of LuaJIT).... The codebase is horrible, fat, and very difficult to maintain. Lua 5.5 support will be a pain as dependencies are numerous, and most of the dependencies or old, and no more maintained

I do agree with you about multiplatform, it will be a high priority. Help will be needed to have good ui and networking modules for each of the next supported platforms (linux and macOS)

ruby

keep it simple manageable

steve64

Another comment: I see there are already some Lua plugins for VS Code, like language servers or even debuggers (while I have not tested them). How different is what you have in mind?

Samir

Language servers are working (there is a full library for LuaRT made for LuaLS that is working perfectly)

Standard Lua debuggers don't manage Tasks, and as the main script is running in a Task since LuaRT 2.0.0, Lua debuggers dont work at all with LuaRT)

esferatec

Hello Samir. I think it's good that you're providing an interim status update. Personally, I'm not in favor of making LuaRT bigger and bigger. What I love about Lua and LuaRT is that they are simple and clear. For me, LuaRT is sufficient for writing Windows programs and doesn't need to be ported to other platforms. I also don't need other tools such as RTBuilder and LuaRT-Studio. I would prefer to maintain the existing base and fix bugs. Maybe add a “table widget.” That's my opinion.

Samir

Hi esferatec,

Going multiplatform won't mean bigger LuaRT overall size, dont worry about that. I keep its main goal of a small footprint but still powerful.

One thing I have forgotten to mention is the use of the LuaRT package manager to manage modules, so you can download only the needed modules or build your own and publish them as needed.

So one LuaRT Core with a small foorprint, and a package manager to use modules as needed. Some modules will be multiplatform, others will be restricted to one (like the actual ui module for Windows)

seven

HI Samir, the project is great.

For multi-platform, it looks interesting. Actually, I used [Login to see the link] , it kind of works for me. And I found LuaRT when I tried to find a windows equivalent.

LuaRT is definitely more higher level than the macOS one, I'd love to see this happen on macOS and Linux for sure. But in the mean time, I haven't find a way to support C ffi threading and callbacks on windows, is it possible? Since most C functions are blocking so a new thread must be spawned to avoid blocking the whole coroutine? I definitely would like to help even I'm not a windows guy, at least for test and demos maybe.

Thanks again for the great work.

Samir

Hi Seven,

Thanks for the feedback! LuaRT does include a C FFI layer, but you're right — it currently has no callback support, which makes using blocking C functions in a non‑blocking way difficult. Adding safe callback handling and a way to run heavy C calls in background threads is something I might implement, but I'm focusing on multiplatform implementation for now.

Your experience with macOS Lua bindings would be very helpful, even just for testing or small demos. And I’m glad LuaRT feels like a higher‑level Windows equivalent — the goal is to bring that same experience to macOS and Linux too.

coutris

Hi Samir,

I’m very new in LuaRT and alittle bit less new with Lua.
I would like thank you for all the work and the thing I appreciate the most: possible to create standalone .exe simply. It is motivating me to migrate max of my tasks to use Lua and particularly LuaRT on Windows.

As I’m blind, I will not be able to contribute a lot because a lot of tools are graphical in nature and less accessible to blind developpers.

I will continue to improve my skills and will hopefully be helpful.

Best regards,

Emmanuel

Samir

Thank you Emmanuel for your feedback on LuaRT, any help is welcome, like a feedback or bug report is very helpful

seven

Hi Samir,

I love this more after I played more.

I actually figured out how to make a C module, which actually can handle callbacks so it can solve my problem. But in the long term I'd like to use pure Lua (add maybe with some ffi) so developers don't need to download 10G of compilers to build a simple Lua project.

In the mean time I have a few other questions/ideas.

I saw [Login to see the link] which is very interesting, what's the status of that?

WinUI looks very nice but also looks like a Windows only thing, when you are trying to go to cross platform, will that still an option to go?

I also used [Login to see the link] before, but it's incomplete and kind of dead. libui-ng and libui-dev trying to make some progress but not so active. It's interesting to see if libui can help this project.

Samir

Thank you Seven.

Winui3 module development is in pause for now, as I dont have too much time since last month due to new job.

For the multiplatform GUI, I dont know how to do it for linux and macOS, so I count on the community to build it, or using a third party library. The package manager will support platform specific modules too.

Samir

Hi Community,

Here is an update regarding the future of LuaRT :

Regarding the next version of LuaRT 2.2.0: It will be essentially a bug fixes version but you can expect some new features nonetheless. I am currently working to update the documentation. I hope to be able to propose a release in April.
Regarding LuaRT multiplatform, it will replace the current version of Windows LuaRT and will first focus on LuaRT core. Expect breaking changes and various improvements. In fact, I have a working version of the LuaRT interpreter on Linux and Windows (I don’t have access to a macOS computer at the moment to test it).

The LuaRT core repository will be released once LuaRT 2.2.0 is available. No binary release will be published as it will be alpha-code for now, this repository will make it easier for contributors to help on the project.

A lot of work will still be needed to make rtc work on several platforms.
And finally, a package manager will be needed to complete LuaRT core with the additional modules.

steve64

Bug fixing is already a thing for LuaRT 2.2.0. On my side the most urgent expected bug fix is the compilation to bytecode when using RTC. I need to deploy soon (April/May) a LuaRT-based application as EXE to 3rd parties and I can not afford to give them open access to my source code just by unzipping...

Samir

I have found a trick to use Lua 5.5 VM in LuaRT Studio so debugging will be possible seamlessly 👌🏼

For rtc, I have found a way to encrypt embedded content, doing some tests though.

Still writting the updated documentation and release should be available soon

steve64

Good news! Is the encryption an alternative or an additional way to deploy exes?
I mean, is bytecode delivery also still in the goals of rtc?

Samir

Yes, lua and wlua files will be compiled to bytecode, not only the main script, but all Lua files in sub directories too

Encrypting is very simple and will concern all embedded content. It's more obsfuscation than encrypting btw