HNHacker News
TopNewBestAskShowJobs

_samt_

96 karma · joined April 5, 2021

Author of LuaRT, the open source Windows programming framework for Lua, and clx - a high performance AOT native compiler for Lua
submissionscomments
_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Good catch, thanks.

The release archive currently extracts directly into the working directory. I'll package future releases into a dedicated top-level directory to avoid cluttering the extraction location.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Yes that's it
_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Thank you!

I'd be very interested in your feedback once you've had a chance to explore the codebase. Multi-platform GUI support is definitely something I'd like to see emerge through Clx binary modules and the C++ API.

Feel free to reach out on GitHub when you're ready — additional platform expertise would be greatly appreciated.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Probably not today.

Love.js is already a mature solution for running Love2D games in the browser through WebAssembly. Clx currently focuses on ahead-of-time compilation to native executables rather than web deployment.

The idea I was referring to is more about native distribution: compiling Lua code into standalone executables without requiring a Lua runtime on the target machine.

That said, if Clx eventually gains a WebAssembly backend, it could become an interesting alternative path for Lua-to-web deployment.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
That's an interesting idea.

Loading precompiled CLX modules is a different problem though. In theory, a native module could be loaded and executed with a restricted environment, similar to how Lua modules receive a specific `_ENV`.

It's not something CLX supports today, but it's much closer to the project's goals than runtime compilation of Lua source code.

One challenge is that standard Lua does not provide a way to change a function's `_ENV` after compilation (unlike the old `setfenv/getfenv` mechanism from Lua 5.1).

I've been considering adding environment manipulation capabilities to the CLX C++ API (while keeping Lua compatibility intact). If that happens, loading CLX modules into custom environments could become relatively straightforward.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
That sounds like a very interesting use case!

This is exactly the kind of scenario where I think third-party clx modules make sense: keep the core runtime portable and let platform-specific bindings live outside of it.

A clx-objc (or metal-cpp or any gui backend) module would be an interesting experiment, and the same approach could apply to other platforms (Win32, GTK, etc.)

Clx is still a relatively young project, so please be a bit indulgent with bugs or missing features, but I'd definitely be interested in seeing/helping what you build!

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
That would be interesting!

Since clx generates portable C++, targeting WebAssembly through Emscripten is theoretically possible.

The challenge is that Love2D does not really expose its backend as a reusable library.

A more natural fit could be a game library like SFML or raylib, used as the base of a game engine provided as a third-party clx module.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Thanks!

That's an interesting idea, but I'd probably lean towards a third-party clx module rather than adding Objective-C runtime support directly to clx.

Since clx already exposes a C++ API and is able to link clx modules, projects like metal-cpp are a natural fit and don't require any changes to the runtime, or any FFI tricks.

That keeps the core runtime small while still allowing platform-specific integrations.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Thanks!

- clx compiles directly from Lua source code. It has its own parser and C++20 code generator; it does not use Lua bytecode

- The goal isn't necessarily to beat Lua, but some workloads benefit from the optimizations performed by modern C++ compilers.

As for tables, clx doesn't use a naive boxed-object model. Tables have a split array/hash layout: integer keys are stored in a contiguous array, while other keys use an open-addressed hash table. That keeps common accesses cache-friendly and avoids a lot of pointer chasing.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
loadfile() isn't implemented in clx, and neither are the other dynamic code-loading features. Supporting them would require runtime code interpretation, which doesn't fit clx's current AOT model.

Could that change one day? Maybe, but it's not a priority right now.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
My bad ! There wasn't a strong reason to target C++20 specifically. I simply choose the latest standard available at the time as started experiments.

In practice, the code generator doesn't rely heavily on C++20-only features, so targeting C++17 would likely be possible with some adjustments.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
I wasn't familiar with Shedskin, I'll take a look !

The optimization I'm most proud of is native type specialization when possible, allowing many values to stay as int64_t or double instead of generic slow Lua values.

As for eval, Clx is fully ahead-of-time compiled. Supporting it would require embedding an interpreter in the runtime and use an interface with Clx... making it significantly larger and going against the idea of compiling everything ahead of time.

For dynamic code execution, the Lua interpreter is probably the better tool.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Yes, game development is one of the use cases I had in mind. Since Clx is fully ahead-of-time compiled, it avoids the JIT restrictions present on iOS and relies on the platform's normal native toolchain.

But Clx currently only supports Linux, Windows and macOS, including Apple Silicon. I haven't tested it on iOS yet, so I can't claim iOS support at this stage.

_samt_··on Show HN: Clx – Compile Lua to Native Executables Through C++20
Yes, Clx generates C++20.

The main motivation wasn't a particular C++20 feature, but using GCC, Clang and MSVC as a portable optimization and code generation backend instead of LLVM or custom machine code generation.

As for coroutines, no. Clx doesn't use C++20 coroutines because Lua coroutines are stackful, so the runtime uses platform-specific context switching instead.

_samt_··on [dead]
I'm thrilled to announce the latest version of rtc, a standalone tool that compiles your Lua 5.4.8 scripts into native Windows .exe applications—no Makefile, no C compiler, and no Lua installation required.

But here’s the real game-changer: rtc supports full static compilation, meaning you can embed Lua binary modules directly into your executable—and they’ll load seamlessly via require() just like regular Lua files. This opens the door to packaging powerful native extensions without worrying about external dependencies.

Static Lua binary modules need just to be recompiled with the lua54-static.lib library from LuaRT distribution (rtc is coded using LuaRT).

Here are the main features :

- Standalone tool – No Makefile or external compiler needed

- Build Windows desktop or console apps

- Static or dynamic executables

- Embed any files – Lua modules, assets, configs

- Access embedded files directly from Lua

- Easy deployment – No Lua installation required

_samt_··on [dead]
LuaRT extends Lua 5.4 -a language valued for its beginner-friendly syntax and simplicity- to create console and desktop applications on Windows. It includes runtime modules and tools to make development accessible for newcomers while supporting complex tasks with minimal effort.

Key Features

- Beginner-Friendly: Lua’s straightforward syntax makes Luart approachable for novices, while still enabling complex tasks—like crafting GUIs or handling web requests—with concise code.

- Lightweight Runtime: The LuaRT runtime is compact and self-contained, relying on no external libraries, ensuring minimal overhead and easy deployment.

- Object-Oriented Programming: LuaRT enhances Lua with robust OOP support, including multilevel inheritance, mixins, constructors, destructors, properties, and more, for structured and reusable code.

- Asynchronous Programming: LuaRT includes a Task object for asynchronous operations, supporting async/await/after paradigms to simplify non-blocking code (e.g., running tasks in the background or scheduling delayed actions).

- Batteries Included: LuaRT contains lots of modules to cover most of today’s programming tasks, such as: json data parsing, audio playing and recording, clipboard access, Windows registry management, process control, compression, sqlite for database operations, C FFI module to call C functions from your Lua scripts, and more ...

- Enhanced ui Module with Windows light/dark themes, HighDPI support, WebView2 widget for displaying web content, and interact with it from Lua, Hardware-accelerated Direct2D rendering with the Canvas widget.

- Bundled Development Tools: LuaRT Studio IDE, RTBuilder a RAD designer, and rtc, the Lua to executable compiler.

- Documentation: A thorough guide (over 1,000 pages) covers modules, examples, and tutorials,...

_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
Maybe because Lua is an easy and interpreted programming language for beginners ?

Maybe such a big solution is not needed for tiny sized projects ?

Maybe we don't need fatty big executables for the ease of deployment ?

_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
I don't have tested this
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
Thank you :) A Grid widget is planned
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
Yes I have tested it several months ago, and it worked. Don't know now if it's still the case
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
LuaRT is open source, maybe someone will make a MacOS port
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
LuaRT will work on older versions. Latest UI feature (themes, HighDPI) won't work. But any feedback on older versions is welcome
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
Thank you :)
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
LuaRT encapsulates the Windows API around a think object oriented layer for Lua. All objects, properties and functions are organized with Lua modules
_samt_··on LuaRT: Lua programming environment for console, desktop applications for Windows
I'm the main author of LuaRT. Yes LuaRT can automate Office apps through COM
_samt_··on [dead]
Main features:

- Uses latest Lua 5.4.5 VM

- The runtime is lightweight and does not rely on any other libraries

- Desktop/console applications and x86/x64 binaries supported

- A number of built-in modules are available, including GUI, networking, compression, encryption, etc.

- Object-oriented programming with multilevel inheritance, mixins, constructors, destructors, properties...

- The development tools include a Lua script to executable compiler, LuaRT Studio IDE, and a REPL.

Since LuaRT 1.0, here are the main changes :

- New GUI widgets : a Webview2 widget, a Progressbar, and a Canvas to draw graphics

- New modules : json module to encode/decode JSON from/to Lua tables, audio module to play sounds and music with effects and spatialization

- New features : Seamless requiring of embedded Lua binary modules in compiled executables, string module now uses non-encoded strings by default as in standard Lua, Zip file entries removing, ...

- And a lot of bugfixes

_samt_··on [dead]
LuaRT is a Windows-optimized runtime library and programming environment for Lua, with integrated development tools. This project aims to facilitate Lua programming by better integrating Lua with Windows operating systems.

Main features : - One-click installer (made with LuaRT)

- Latest Lua 5.4.4 VM, with a powerful runtime that does not rely on any other libraries

- Create desktop/console applications for x86/x64 platforms

- A number of built-in modules are available, including GUI, networking, compression, encryption, etc.

- Object-oriented programming with multilevel inheritance, mixins, constructors, destructors, properties...

- Provides an easy script to executable compiler with embedded content and seamless access from your Lua scripts (even from embedded Lua binary modules)

-------------------------------

Main changes in LuaRT 1.3.0:

- Compiled Lua scripts can now require for embedded DLL binary modules without extraction (may not work for all binary modules)

- String module now uses non-encoded strings by default, as standard Lua (UTF8 functions are still available, but prefixed by "u")

_samt_··on LuaRT 1.1: open-source Windows programming framework for Lua
LuaRT contains a Windows-optimized runtime library for Lua, with integrated development tools. This project aims to facilitate Lua programming by better integrating Lua with Windows operating systems.

Main features : - One-click installer (made with LuaRT) - Latest Lua 5.4.4 VM, with a powerful runtime that does not rely on any other libraries - Create desktop/console applications for x86/x64 platforms - A number of built-in modules are available, including GUI, networking, compression, encryption, etc. - Object-oriented programming with multilevel inheritance, mixins, constructors, destructors, properties... - Provides an easy script to executable compiler with embedded content and seamless access from your Lua scripts

LuaRT 1.1 main changes : - Contains now all PUC Lua modules, including os, io and utf8. - Updated LuaRT C API to define new GUI widgets - New compression module with gzip/gunzip and ZIP archives management - Various bugfixes, improvements and new examples

_samt_··on LuaRT Studio, free and open-source Windows IDE for Lua
Hi everyone !

LuaRT Studio is a Windows IDE to develop Lua desktop or console applications, based on the LuaRT interpreter. LuaRT Studio can also be used to develop standard Lua applications based on latest Lua 5.4.4 VM seamlessly. Here is a list of the main features :

- Based on ZeroBrane Studio, from Paul Kulchenko

- Automatic switch between Lua console or desktop application based on file extension (.lua and .wlua respectively)

- Updated UI, using current Windows UI theme, icons for files, tabs, and panels.

- Rework of the "Outline" tab, now called "Symbols" (displays local and global variables, new icons, table expansion...)

- Icons for Watch panel, Stack panel and a new Symbol tab

- Support for using ttf font files

- LuaCheck updated to 0.26

- Updated mobdebug to support LuaRT objects.

- New project option to Show/Hide console window.

- Local console uses now the Lua 5.4.4 VM

_samt_··on LuaRT, a comprehensive framework for Windows to develop in Lua
LuaRT main goal is to facilitate access to the Windows operating system functionalities without the need for C interoperability (no need for binary modules or FFI layers), hence the choice for PUC Lua :)
Page 1 of 2Next →