Re: Using Lua to replace C

[Steve Litt <slitt@...>]

Hey guys,

Please tell me if you ever write a Vim clone in Lua.


On Friday 11 March 2011 06:08:41 Dimiter "malkia" Stanev wrote:
> Hi Reuben,
> 
> Very interresting project. Almost all written in lua.
> 
> I went a bit further in that direction, and rewrote the curses/posix
> bindings in LuaJIT FFI. Not full bindings, just the one needed by the
> current editor. I just wanted to see how one can go without the standard
> lua bindings.
> 
> So I've got it working 32-bit, 64-bit on my Mac OS X 10.6.6, with two
> little changes in the project to run with luajit.
> 
> http://github.com/malkia/luajit-zile
> 
> I'm not much familiar with autotools, automake, so I probably did
> somehing stupid by adding in my cloned depot the zile, zile.lua and
> loadlua.lua in the src folder, but this way would be easier for me to do
> the windows port.
> 
> For anyone else who wants to experiment,
> 
> git clone git://github.com/malkia/luajit-zile luajit-zile
> cd luajit-zile/src
> luajit zile.lua
> OR
> ./zile
> 
> There are still problems, something on the lower bar displays with
> ^@^@^@^@^@ - that would be the null character. I guess I'm either
> returning FFI strings with zero, or something else.
> 
> All in all it took me just few hours (this without ever used curses,
> although wanted to learn it from a long time).
> 
> Thanks,
> Dimiter "malkia" Stanev
> 
> On 2/24/11 7:42 AM, Reuben Thomas wrote:
> > Hi,
> > 
> > I've just removed the last C file from the "lua" branch of GNU Zile (a
> > cut-down Emacs clone).
> > 
> > https://savannah.gnu.org/projects/zile/
> > 
> > Converting Zile into Lua incrementally relied on my simple clue
> > framework:
> > 
> > http://luaforge.net/projects/clue
> > 
> > of which I will shortly make a new release which adds full backtraces
> > to Lua calls by stealing code from lua.c. (Of course, clue is not used
> > in the final, pure Lua, result, but it was essential to having a code
> > base that was functional and testable the whole time.)
> > 
> > Since Zile is written using only POSIX APIs, including curses, I used
> > luaposix (and in the process added some important functionality,
> > currently unreleased, including getopt and signals), and lcurses (of
> > which I have released a new version with the improvements I needed).
> > 
> > The standard lua.c Lua interpreter has two problems, one of which I
> > can live with (the way it puts command-line arguments on the stack,
> > thus limiting the number of arguments; being an interactive editor,
> > Zile is rarely used with very long command lines), and secondly, its
> > inability to force default settings for LUA_INIT, LUA_PATH and
> > LUA_CPATH on the command line. I can work around this with an extra
> > level of script, but it means that I can't easily start Zile from a
> > hash-bang script.
> > 
> > One could write something like:
> > 
> > #!/usr/bin/env lua -e "LUA_INIT,LUA_PATH,LUA_CPATH=nil"
> > 
> > but this could run into problems on some kernels with length limits on
> > the command-line for hash bang lines.
> > 
> > I attach a patch for 5.1.4 which adds a -t flag (I couldn't think of a
> > better letter, as one would expect -d to debug; I was thinking of t
> > for taint) which, since the reading of the environment variables
> > happens in loadlib.c, and since (un)setenv is not portable, simply
> > overwrites loadlib.path and loadlib.cpath with the default values.
> > 
> > This is, in my view, important to fix, as otherwise it's hard to write
> > reliable/secure portable single-file Lua programs. On the other hand,
> > it's the only major obstacle to replacing C with Lua for portable
> > POSIX programs (I mean, of course, programming obstacle, I'm not
> > talking about performance). Even in my naive translation, I've reduced
> > the code base by about 26%, and debugging is now much faster and
> > easier. Because of Lua's wonderful portability, portability of the
> > code is not, in principle, reduced at all, although in practice it is
> > somewhat for now, since luaposix is not built using gnulib, and thus
> > relies rather more on the underlying POSIX implementation. I aim to
> > fix this.