Re: [code] [textadept] Future of LuaJIT Version

From: Martin \ <>
Date: Thu, 12 Feb 2015 02:35:11 +0100

On Tue, 13 Jan 2015 09:09:49 -0500 (EST)
Mitchell <> wrote:

> Hi,
> First, thanks to everyone for your responses. It is always good to know
> what others are using Textadept for.
> On Mon, 12 Jan 2015, Robert Gieseke wrote:
> > Hi,
> >
> > so, with 5.3 out, any decisions or plans for switching the nightly?
> Last night I was able to compile Lua 5.3 into Textadept with the "bit32"
> compatibility mode on and was also able to compile the new "utf8" library
> as a separate module for LuaJIT. Therefore, I think both versions can be
> supported at once with minimal work.
> However, Textadept will not be switching to Lua 5.3 right away -- there's
> still the 7.8 release to do. After that, I'll start on final 5.3
> integration (with LuaJIT support).
> Cheers,
> Mitchell


I am not real programmer and not very good coder, but I am using luajit for
"sysadmin" work. Where more "normal" sysadmins would normally use shell, perl
or python I use solely luajit. I am currently dealing with os x + linux for
endpoints and freebsd with lots of jails for few servers. I am self-taught so
maybe I did some crappy decisions, but whatever. I tend only to my own machines
and all my kludges are used at my sites only.

I am finally happy with my toolset made from luajit, luaposix and a bit of
nanomsg (still having some problems there). I am probably using maybe 1%
of actual lua features. Great thing about lua however is that it lends very
well for data description.

With lj one can compile deeply nested "data" tables into bytecode. Tagged
and nested directory trees, xmls, and other config primitves can be "cached"
like this to be loaded very quickly (even MBs of on disk data). I noticed most
people don't use lj bytecode at all. Bytecode chunks load several orders of
magnitude faster. Calculations with data from lj bytecode tables are naturally
fast as well. It beats any other solutions I experimented with making it very
suitable to get most out of your iron.

Compiling most often hit lj scripts, allows them to be registered with
linux kernel and recently freebsd kernel as well, so they behave like native
binaries. I did some ssh "vpn" dial-ins this way which then open firewalls
and forwardigns for users.

Interfacing with some better designed C runtimes (qdbm, nanomsg) through lj
ffi proved to be much easier than writing C stuff (for me - who has
very limited C capability).

In luaposix one can call native c tools with complex options much nicely than
from shell. At this point I am very happy in this environment.

Last thing I am missing is utf-8 and I am bit stressed by the fact lua mainline
is moving incredibly fast into such future while lj lags behind.

Finally I use Textadept to manage these kludges and I have it configured to
use same "runtime environment". If I could still keep same luajit runtime
between both TA and OS environment described, I would be very very (i
mean very) grateful.

However if this would mean dilution of your time and resources in such way that
maintaining lj TA build would be problematic - disregard this message.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Wed 11 Feb 2015 - 20:35:11 EST

This archive was generated by hypermail 2.2.0 : Thu 12 Feb 2015 - 06:47:42 EST