Rendered at 18:57:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Philpax 2 days ago [-]
This is of interest to me, but I have no idea why you'd set `height: 720px`. I had to turn that off to make it readable.
_samt_ 2 days ago [-]
Thanks for pointing that out, it might be diffu ule to read on some résolutions
2 days ago [-]
drdexebtjl 2 days ago [-]
> It also means that libraries written in C or C++ don't need to be translated into some special Lua-specific implementation. They can remain native libraries, with a thin clx binding layer exposing the functionality to Lua.
This is already true of upstream Lua implementations. It is very easy to write thin Lua binding layers to C libraries.
That is the entire point of Lua. It’s easy to call Lua from native code, and it’s easy to call native code back from Lua, so you can have call stacks that seamlessly interweave Lua and native code.
I’m very skeptical of the idea that this can unlock improvements in performance or size. We already have LuaJIT which is plenty fast, and PUC-Lua which is so small, it runs on MCUs.
_samt_ 2 days ago [-]
The primary goal of clx is not size or performance but to ship standalone executables without the need of the Lua VM with a native approach rather than the well known (and somewhat hacky) way to embed a script and the LuaVM inside an executable (and when using binary modules it can be quite tricky !)
drdexebtjl 2 days ago [-]
There’s nothing hacky about it, it is in fact the way the language was designed to be used, hence why the interpreter ships as a library, and why the module loader looks for package.preload[modname] before reaching for the file system (and can be trivially made to not touch files at all).
_samt_ 1 days ago [-]
Lua was designed primarily as an embeddable scripting language, and embedding the interpreter as a library is absolutely a valid way to use it :)
My point is about deploying standalone applications.
Tools like srlua, luastatic, and many others, package Lua scripts with the interpreter and required libraries. These bundled executables can sometimes trigger antivirus false positives, just like tools such as py2exe for Python.
They use packaging techniques that can resemble those used by malware, which is why I called this approach "hacky".
2 days ago [-]
gucci-on-fleek 1 days ago [-]
I wouldn't consider static linking + #embed to be hacky though, and that's all that it takes to deploy a standalone Lua program.
_samt_ 1 days ago [-]
It will be hacky if you need binary modules. Some platforms (Windows I see you !) don't permit to link binary modules to a static executable. Your only possibility is to embed the Lua dynamic library and the binary modules your need, extract them somewhere and so on...
gucci-on-fleek 1 days ago [-]
> Some platforms (Windows I see you !) don't permit to link binary modules to a static executable
If you have the source code for these modules, you can statically link to them too. I've done this myself for Windows a few times, and it works pretty well in my experience.
_samt_ 1 days ago [-]
Sure, but it becomes a pain when you have several dependencies. Take LuaSocket, for example: it has binary modules, Lua scripts, and folder-related requirements to deal with.
Static linking itself is not a problem for Lua.
If all you want is a tiny script that checks the weather or downloads a file, having to manually link or bundle all those pieces just to ship a standalone executable is a lot of work. That's one of the problems clx aims to solve.
drdexebtjl 1 days ago [-]
Windows can statically link libraries just fine. What problem are you running into?
_samt_ 1 days ago [-]
Windows can statically link libraries just fine. That's not the point :)
When your application depends on several Lua and binary modules, you may have to compile each binary module, embed the Lua scripts while preserving their expected module paths, link everything against the Lua VM, and write glue/loading code to make everything work together (see the comment below regarding LuaSocket)
Of course, it's possible. But it's a lot of manual work, especially for newcomers.
With clx, the goal is simple: compile your Lua program into a native executable. No stock Lua VM dependency, no glue code, no module-loading code to write.
gucci-on-fleek 13 hours ago [-]
> you may have to compile each binary module
Correct, but I'd argue that you need to do this anyways (well, I do this anyways), because I don't like the alternative of redistributing binaries compiled by random third parties from the internet.
> link everything against the Lua VM, and write glue/loading code to make everything work together (see the comment below regarding LuaSocket)
> Of course, it's possible. But it's a lot of manual work, especially for newcomers.
To be clear, I think that your project is great, but this really isn't that much work:
$ make && ./program
cc -o program main.c library.o -std=c23 -Wall -Wextra -Werror -O2 -flto -s -llua
Hello from C!
Hello from Lua!
drdexebtjl 1 days ago [-]
I don’t see your comment about LuaSocket. Is it in a different thread?
> no glue code, no module-loading code to write.
How does that look like in practice? Your write up only shows the case where you’re writing your own custom clx glue code to interface with a binary module, which is strictly worse.
_samt_ 1 days ago [-]
> I don’t see your comment about LuaSocket. Is it in a different thread?
Yes it's in another thread.
clx provides a simpler, stackless C++ API because it doesn't use the Lua VM.
The Lua C API compatibility layer lets you reuse existing binary modules without rewriting their source code. The wrapper is there for compatibility, not because modules must be written that way.
For new modules, you can use clx's native C++ API directly.
wiradikusuma 2 days ago [-]
If it has to go through compilation process to make it native, doesn't that defeat the purpose of Lua? I mean, why not just use the same language of the host application, in other words, just another function/module of that app.
PhilipRoman 2 days ago [-]
1) You can use interpreted version for rapid development and switch to compiled for release
2) You may like Lua as a language and want to use it for general purpose programming, not necessarily embedding into host program
I will say though that the performance aspect has to be taken with a grain of salt, "native compilation" is not a meaningful improvement if every source line translates to multiple branches or vtable lookups. From my experience plain conversion of Lua to C (assuming you faithfully follow the specification, including coroutines, metatables, etc.) produces equal or slower code with rare exceptions for numerical loops. If it wasn't all AI generated I'd maybe spend time understanding this project.
le-mark 2 days ago [-]
> From my experience plain conversion of Lua to C (assuming you faithfully follow the specification, including coroutines, metatables, etc.) produces equal or slower code with rare exceptions for numerical loops.
This has been a long known reality of compiling dynamically typed and functional languages to native code.
_samt_ 2 days ago [-]
Totally agree, and that's why clx static analysis and optimizer steps permits some performance gains
_samt_ 2 days ago [-]
Agreed, native compilation alone doesn't guarantee better performance. clx has its own optimizer and runtime, and the results depend on the workload. It doesn't beat LuaJIT on everything and that's not it's primary goal.
As for AI, I've spent months of my free time building clx. The design and implementation are mine. It's true that I use AI to help with documentation and to debug complex issues, but that doesn't make the project AI-generated.
_samt_ 5 days ago [-]
A technical write‑up about the difficulties of compiling Lua to native code, based on my experience developing clx
This is already true of upstream Lua implementations. It is very easy to write thin Lua binding layers to C libraries.
That is the entire point of Lua. It’s easy to call Lua from native code, and it’s easy to call native code back from Lua, so you can have call stacks that seamlessly interweave Lua and native code.
I’m very skeptical of the idea that this can unlock improvements in performance or size. We already have LuaJIT which is plenty fast, and PUC-Lua which is so small, it runs on MCUs.
My point is about deploying standalone applications.
Tools like srlua, luastatic, and many others, package Lua scripts with the interpreter and required libraries. These bundled executables can sometimes trigger antivirus false positives, just like tools such as py2exe for Python. They use packaging techniques that can resemble those used by malware, which is why I called this approach "hacky".
If you have the source code for these modules, you can statically link to them too. I've done this myself for Windows a few times, and it works pretty well in my experience.
Static linking itself is not a problem for Lua.
If all you want is a tiny script that checks the weather or downloads a file, having to manually link or bundle all those pieces just to ship a standalone executable is a lot of work. That's one of the problems clx aims to solve.
When your application depends on several Lua and binary modules, you may have to compile each binary module, embed the Lua scripts while preserving their expected module paths, link everything against the Lua VM, and write glue/loading code to make everything work together (see the comment below regarding LuaSocket)
Of course, it's possible. But it's a lot of manual work, especially for newcomers.
With clx, the goal is simple: compile your Lua program into a native executable. No stock Lua VM dependency, no glue code, no module-loading code to write.
Correct, but I'd argue that you need to do this anyways (well, I do this anyways), because I don't like the alternative of redistributing binaries compiled by random third parties from the internet.
> link everything against the Lua VM, and write glue/loading code to make everything work together (see the comment below regarding LuaSocket)
> Of course, it's possible. But it's a lot of manual work, especially for newcomers.
To be clear, I think that your project is great, but this really isn't that much work:
To run:> no glue code, no module-loading code to write.
How does that look like in practice? Your write up only shows the case where you’re writing your own custom clx glue code to interface with a binary module, which is strictly worse.
Yes it's in another thread.
clx provides a simpler, stackless C++ API because it doesn't use the Lua VM.
The Lua C API compatibility layer lets you reuse existing binary modules without rewriting their source code. The wrapper is there for compatibility, not because modules must be written that way.
For new modules, you can use clx's native C++ API directly.
2) You may like Lua as a language and want to use it for general purpose programming, not necessarily embedding into host program
I will say though that the performance aspect has to be taken with a grain of salt, "native compilation" is not a meaningful improvement if every source line translates to multiple branches or vtable lookups. From my experience plain conversion of Lua to C (assuming you faithfully follow the specification, including coroutines, metatables, etc.) produces equal or slower code with rare exceptions for numerical loops. If it wasn't all AI generated I'd maybe spend time understanding this project.
This has been a long known reality of compiling dynamically typed and functional languages to native code.
As for AI, I've spent months of my free time building clx. The design and implementation are mine. It's true that I use AI to help with documentation and to debug complex issues, but that doesn't make the project AI-generated.