Who is using modified Lua versions, what are they and why?

[Sewbacca]

Lua is small, readable and easily modifiable which are huge perks. However they only come in handy if you are in control of the application itself which is running Lua. If you rely on the default distributed Lua version, you can't just change the parser. Especially if you are writing modules, then you have very little control over the runtime.

So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?

~ Sewbacca

[sur-behoffski]

On 2026-06-27 10:24, 'Sewbacca' via lua-l wrote:
> Lua is small, readable and easily modifiable which are huge perks. However they only come in handy if you are in control of the application itself which is running Lua. If you rely on the default distributed Lua version, you can't just change the parser. Especially if you are writing modules, then you have very little control over the runtime.
>
> So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?

G'day,

Although no-one seems to be using lglicua, I included a mechanism
for explicitly patching a Lua version install. The main reason for
this was so that I could add David Sicilia's "continue" patch to
for loops, so that Lua loops can be written in a style closer to
that allowed by C. (I like continue because I abhor deep nesting,
and "continue" gives me more freedom to handle edge/non-mainstream
value cases without taking emphasis away from the main body.)

When installing Lua, lglicua always builds from source, regardless
of the package capabilities of the GNU/Linux OS. The user can use
"+feature" to request that a feature patch be applied before make,
and multiple features/patches can be specified (e.g. "+a+b+z").
However, there is no attempt to synchronise diff-style patch files
to cater for differences e.g. in line numbering and/or context
changes; perhaps an "+a+b" patch might be needed alongside "+a"
and "+b" patches (and perhaps deny any use of "+b+a"?).

```
BASE/install $ ./i lua-install 5.4+continue
BASE/install $ ./i lua-select 5.4
BASE/install $ lua -v
Lua 5.4.8 +continue Copyright (C) 1994-2025 Lua.org, PUC-Rio

BASE/install $ ./i lua-install 5.4+continue+another
BASE/install $ ./i lua-select 5.4
BASE/install $ lua -v
Lua 5.4.8 +continue+another Copyright (C) 1994-2025 Lua.org, PUC-Rio

```

Although I don't know of any users, this is at least one working
experiment in preparing customised versions.

[lglicua is available on SourceForge.]

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Bas Groothedde]

> On 27 Jun 2026, at 02:55, 'Sewbacca' via lua-l <lu...@googlegroups.com> wrote:
>
> So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?
>
> ~ Sewbacca

I have used many custom builds of Lua in my career, but the reasoning has always been different. Some cases;

- a custom build with lua_lock and lua_unlock implemented
- custom builds because the company I was working at simply didn’t know you could build Lua libraries, so they jammed everything into Lua
- a custom build because the company wanted to change the bytecode format, security by obscurity - it was client side code, so it had no benefit.
- many cases where Lua was used as an extension language, so Lua was built into an application and not shipped as a companion.

If you ask me, of all the modifications I encountered I only could understand the build with lock/unlock. In that specific case it replaced a prebuilt version on Windows for an application we did not maintain.

~b

[Родион Горковенко]

In my case it was very simple - I use Lua at my coding-puzzle-website for some small subset of problems (google "codeabbey space invaders" for example).

Lua was chosen as the language that supposedly everyone can easily pick up quickly (and which I can compile to javascript to make it work in webpage demo).

This worked, but after several puzzles some most devoted users expressed their frustration with very minor features of Lua syntax - unusual spelling for "not equals" operator, lack of "augmented assignment" seemingly were most frustrating for them.

What could I do? Just to keep assuring people that they should get used to it (given that they have no goal of full-time switching to Lua)? I preferred to try and amend Lua source code so these things will work at least partially / in general case. 

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/dbcab2ec-b0c0-46de-96de-68e7e7782044%40kolabnow.com.

[云风 Cloud Wu]

'Sewbacca' via lua-l <lu...@googlegroups.com> 于2026年6月27日周六 08:55写道：

>
> Lua is small, readable and easily modifiable which are huge perks. However they only come in handy if you are in control of the application itself which is running Lua. If you rely on the default distributed Lua version, you can't just change the parser. Especially if you are writing modules, then you have very little control over the runtime.
>
> So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?

I maintain a modified Lua version to share function prototypes and
constant tables among multiple Lua states.
https://github.com/cloudwu/skynet/tree/master/3rd/lua

Since the Skynet framework may creates thousands of Lua states in the
same process, sharing Lua function prototypes can significantly reduce
memory usage and improve startup performance when spawning new Lua
states.

Constant data stored in Lua tables can also be shared across multiple
Lua states, enhancing memory efficiency. Additionally, sharing
constant Lua tables can reduce garbage collection overhead and
accelerate the startup time of Lua states that require these data."

---
http://blog.codingnow.com

[Scott Condit]

Hello

> On 27 Jun 2026, at 01:54, 'Sewbacca' via lua-l <lu...@googlegroups.com> wrote:
> So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?

I’ve built a number of applications which use or used custom lua builds.

One was a large intraday and end-of-day trading application for a specific business line.
Lua was used as to express custom setup in various domain objects, held as part of domain
objects, and so both as part of our software deployment, and as four-eyes approved snippets
provided by users. This included:

-specify model parameters and selection for quantitative pricing
- individual product pricing, market data selection
- data manipulation: creating new columns functionally, filter specifying
- complete definition of individual report pipelines taking inputs (e.g. canned reports and live risk runs)
- layouts of OLAP views, live dashboards, formatting

It had custom syntax (string interpolation, shell syntax ($ to end of line). Some library functionality was
completely removed, and it also had VM instruction count budgeting (since the code could run on
desktop, server-side, or sandboxed depending on where the snippet originated).

The object model allowed introspection/reflection from the C++ to Lua side and vice versa, and naturally
allowed creation/passing any which way.

A second was a larger end-of-day system. Lua was used there for orchestration specifications, and as a
data manipulation DSL glue to isolate ourselves from the vendor-specific platforms in use.

I’ve done a few others over the years, and still have a custom Lua now for personal projects.

It’s super interesting to hear about the other use cases!

— Scott

[Francisco Olarte]

On Sat, 27 Jun 2026 at 08:52, Родион Горковенко <rodio...@gmail.com> wrote:
> This worked, but after several puzzles some most devoted users expressed their frustration with very minor features of Lua syntax - unusual spelling for "not equals" operator, lack of "augmented assignment" seemingly were most frustrating for them.

These ones, as well as the 1-indexing, on a language written in C
whose primary extension API is in C too hits me every day, and is why
after many years I still keep searching around to replace lua.

Francisco Olarte.

[David Sicilia]

"continue" patch to for loops

Were you able to port that to Lua 5.5?

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/083f8e71-7d56-4bbb-bc4c-96e86ba0ef88%40grouse.com.au.

[sur-behoffski]

On 2026-06-28 03:00, David Sicilia wrote:
>>
>> "continue" patch for loops

>
>
> Were you able to port that to Lua 5.5?

[...]>> BASE/install $ ./i lua-install 5.4+continue

>> BASE/install $ ./i lua-select 5.4
>> BASE/install $ lua -v

>> Lua 5.4.8 +continue Copyright (C) 1994-2025 Lua.org, PUC-Rio[...]

G'day David,

Thanks for the 5.[1-4].x patch. Sadly, I only tried in the most
naive way possible to see if it worked with 5.5, and, upon failure,
gave up, as patch couldn't fathom how to reconcile the "continue"
patch with the new sources.

(Two extra reasons why I dropped off quickly:

1. A number of Rocks under LuaRocks that I depend on
weren't compatible with everything in 5.5, but I only
did testing when 5.5 was freshly released, e.g.

require("std.strict")
require("posix")

and

2. Real Life is taking up most of my time at the moment,
and I'm mostly staying quietly with 5.1, which leaves a
chance of trying out LuaJIT at some point.)

Just checking now, I'm not even doing full management of the
LuaRocks package manager itself: It's 3.12.2 on one machine,
3.13.0 (current, released on 2026-Jan-29) on some others.

(I am staying away from the bleeding-edge LuaRocks Git sources
as always, as this may be incompatible with "lglicua"'s
expected usage.)

cheers,

s-b etc etc

[eugeny gladkih]

>
> So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?
>

why not :) I use short function definition, like that

<?(a) -> a+1 ?> == function(a) return a+1 end
<?bla bla bla?> == function() blah blah bla end

<? == function
?> == end (only in pair of <?)
-> == return

function parameter list is optional

--
Yours sincerely, Eugeny.

[Błażej Roszkowski]

I am using 5.1, building it myself, not using bundled in Makefile. I also took

change from 5.2 that reduces table memory a little (my blog post if anyone

wants to read some of it https://frex.github.io/lua/smallertable51.html ), and

consider making more changes, but keeping them all compatible with 5.1.

I appreciate Lua being just a pile of C that is compatible and easy to keep

and compile inside your projects forever, while for language like Python

I once needed to build 2.7 for something and couldn't due to all the deps.

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/3F7F1927-5897-4C7B-A04E-B4DC98998F7E%40drweb.com.

[Thomas Jericke]

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/dbcab2ec-b0c0-46de-96de-68e7e7782044%40kolabnow.com.

We use a modified Lua 5.2 that supports native breakpoints. That means when I add a breakpoint to Lua, a breakpoint instruction is set in the bytecode and when the breakpoint is hit, the interpreter calls the debug hook. On resume or step the original instruction is executed. When I remove the breakpoint the original instruction is swapped back in.

The reason for this is to have a way to debug a scripts and have zero runtime (performance) impact until you actually hit a breakpoint.

I am still planning to do this in Lua 5.5 as a standalone patch. My current implementation relies on additional C++ classes.

-- 

Thomas

[Guilherme Nemeth]

> So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?

We use a custom 5.4.6 that errors out on unknown globals at lua compile-time.

[Andrew]

On 27/06/2026 10:54, 'Sewbacca' via lua-l wrote:
> ...

> So out of curiosity: Who is using modified Lua versions, what are the
> modifications and why do you need them?

I use a patch to add an extra metamethod '__eqval', which is called when
only one of the operands to the compare-equal operator (==) is a table
or userdata; if both operands are tables or both are userdata then only
the '__eq' metamethod is called as usual. The overhead on 'normal'
equality comparisons is minimal or zero.

This allows a library which implements a higher level data type (let's
call it T) as a table or userdata to be used more naturally when
comparing directly with a number or a string. For example, if p is a
variable holding a value of type T, you can write 'p == 2' and the
__eqval metamethod will be called (unless p is just a number too).
Otherwise you would have to write 'p == convert-to-T(2)'. The same
applies when comparing two variables, one of which may contain a T and
the other a simple value (number, string or boolean).

I've used this metamethod in an infinite precision arithmetic library in
pure lua. It allows code written in other languages (eg a crypto package
written in C) to be imported into lua with minimal effort.

-a

[patch for 5.4 is on Lua Power Patches
<http://lua-users.org/wiki/LuaPowerPatches>. If anyone is interested I
will upload patches for later Lua versions]

>
> ~ Sewbacca
>
> --
> You received this message because you are subscribed to the Google
> Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to lua-l+un...@googlegroups.com <mailto:lua-
> l+unsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/

> dbcab2ec-b0c0-46de-96de-68e7e7782044%40kolabnow.com <https://
> groups.google.com/d/msgid/lua-l/dbcab2ec-
> b0c0-46de-96de-68e7e7782044%40kolabnow.com?
> utm_medium=email&utm_source=footer>.

[Frank Kastenholz]

> On Jul 4, 2026, at 8:18 AM, 'Andrew' via lua-l <lu...@googlegroups.com> wrote:
>
>
> On 27/06/2026 10:54, 'Sewbacca' via lua-l wrote:
>> ... So out of curiosity: Who is using modified Lua versions, what are the modifications and why do you need them?
>
> I use a patch to add an extra metamethod '__eqval', which is called when only one of the operands to the compare-equal operator (==) is a table or userdata; if both operands are tables or both are userdata then only the '__eq' metamethod is called as usual. The overhead on 'normal' equality comparisons is minimal or zero.
>
> This allows a library which implements a higher level data type (let's call it T) as a table or userdata to be used more naturally when comparing directly with a number or a string. For example, if p is a variable holding a value of type T, you can write 'p == 2' and the __eqval metamethod will be called (unless p is just a number too). Otherwise you would have to write 'p == convert-to-T(2)'. The same applies when comparing two variables, one of which may contain a T and the other a simple value (number, string or boolean).
>
> I've used this metamethod in an infinite precision arithmetic library in pure lua. It allows code written in other languages (eg a crypto package written in C) to be imported into lua with minimal effort.

Did something similar to a complex number library; you could say something like “if (complex_number == 10)” and it would convert the 10 to “10+0i”.

The bigger mod I led was a prototype system where we had to be able to A) suspend a running Lua application (including library calls) whenever the host system sent us a signal of some sort and B) be able to simultaneously run multiple Lua applications/ For various reasons coroutines were not useful in this project. Also, we could not use pthreads since the project was targeted for a large group of systems with a wide range of host operating systems (I use that term loosely!). We ended up turning the virtual machine main loop into a preemptive multitasking kernel where the “processes” where Lua states. For other security reasons we ended up replacing or removing a lot of the standard library calls - the new versions lived within these constraints (for example, the string rep function’s main loop was modified to do “only a few” passes at a time, before ceding control.

It seemed to work quite well. But it was a prototype, so there probably were lots of corner cases we had missed at the time. As far as I know, the prototype was never picked up.

And. No, patches are not available :-(

Frank Kastenholz

[Ką Mykolas]

Some time ago I've been developing an encryption and signing tool for compiled Lua chunks.

It involved a few slight changes in luac and lua:

 - swapping calls to "require" with different call to a different function with statically determined parameters during compile time

 - updating "lua_load()" (?, or some other loader related functions) with signature checks and loading from encrypted binary blob

The project this tool was being developed for was a proprietary one and killed in a few years,

also based on latest and greatest (back then) 5.1, so... I do not recall much of the details.

Will check some old back-ups, it may be interesting to doodle around.

Kind regards

--

You received this message because you are subscribed to the Google Groups "lua-l" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/dbcab2ec-b0c0-46de-96de-68e7e7782044%40kolabnow.com.

[Lourival Vieira Neto]

On Tue, Jul 7, 2026 at 8:51 AM Ką Mykolas <kam...@gmail.com> wrote:
>
> Some time ago I've been developing an encryption and signing tool for compiled Lua chunks.
>
> It involved a few slight changes in luac and lua:
> - swapping calls to "require" with different call to a different function with statically determined parameters during compile time
> - updating "lua_load()" (?, or some other loader related functions) with signature checks and loading from encrypted binary blob

interesting; we have developed a support like this for Lunatik without
modifying Lua [1, 2, 3, 4].

[1] https://luainkernel.github.io/lunatik/modules/darken.html
[2] https://luainkernel.github.io/lunatik/modules/lighten.html
[3] https://github.com/luainkernel/lunatik/blob/master/lib/luadarken.c
[4] https://github.com/luainkernel/lunatik/blob/master/lib/lighten.lua

Regards,
--
Lourival Vieira Neto

[Ką Mykolas]

Cool, thanks! I'll give it a read!

And yes, indeed, it's not necessary to modify the Lua interpreter/compiler for that. But a bigger goal was to obfuscate compiled bytecode even further.

Again, on the compiler level, messing up with OpCodes, etc. But the project did not come to that in the end. 

Kind regards

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/CALHoKCZ8FMgoxx0%2B-ghW1i4Lu49Ei-1UN6sG79-Kf%3DnG_aYEiQ%40mail.gmail.com.