lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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:// luajit-zile
cd luajit-zile/src
luajit zile.lua

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).

Dimiter "malkia" Stanev

On 2/24/11 7:42 AM, Reuben Thomas wrote:

I've just removed the last C file from the "lua" branch of GNU Zile (a
cut-down Emacs clone).

Converting Zile into Lua incrementally relied on my simple clue framework:

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.