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

175 views
Skip to first unread message

Sewbacca

unread,
Jun 26, 2026, 8:55:01 PM (6 days ago) Jun 26
to lu...@googlegroups.com
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

unread,
Jun 26, 2026, 9:39:57 PM (6 days ago) Jun 26
to 'Sewbacca' via lua-l
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

unread,
Jun 27, 2026, 1:59:30 AM (6 days ago) Jun 27
to lu...@googlegroups.com

> 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

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

unread,
Jun 27, 2026, 2:52:18 AM (6 days ago) Jun 27
to lu...@googlegroups.com
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

unread,
Jun 27, 2026, 2:55:29 AM (6 days ago) Jun 27
to lu...@googlegroups.com
'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

unread,
Jun 27, 2026, 12:20:49 PM (6 days ago) Jun 27
to lu...@googlegroups.com
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

unread,
Jun 27, 2026, 1:20:50 PM (6 days ago) Jun 27
to lu...@googlegroups.com
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

unread,
Jun 27, 2026, 1:31:03 PM (6 days ago) Jun 27
to lu...@googlegroups.com
"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.

sur-behoffski

unread,
Jun 28, 2026, 4:42:43 AM (5 days ago) Jun 28
to lu...@googlegroups.com
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

unread,
Jun 29, 2026, 6:23:36 AM (4 days ago) Jun 29
to lu...@googlegroups.com
>
> 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

unread,
Jun 29, 2026, 4:05:16 PM (4 days ago) Jun 29
to lu...@googlegroups.com
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.

Thomas Jericke

unread,
Jul 2, 2026, 1:37:12 AM (yesterday) Jul 2
to lu...@googlegroups.com
--
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

Reply all
Reply to author
Forward
0 new messages