I have a few questions about this announcement. 1st question:
Lua scripts have their place under <texmf>/scripts/lua already, I thought the lua scripts in the cont-tmf.zip distribution are residing in <texmf>/scripts/context/lua/. Is this a change or are they different files?
2nd question: In many instances the system location to place lua libraries is somewhere like /usr/local/lib/lua/5.1/lpeg.so etc. for dynamic libraries /usr/local/share/lua/5.1/re.lu etc. for lua coded modules See the discussion on page 140 of the book Programming in Lua by Roberto Ierusalimschy. Will these locations be put on the searchpath too? Or will the environment variables LUA_PATH and LUA_CPATH, mentioned in the above, be included in the search? Finally a wish related to the build/make process, since that also seems to undergo a change. At present each compilation run also compiles ctangle. Often that program is already in the TeX distribution. Is it possible to use that instead and resort to compilation only when it cannot be found? Hans van der Meer On 4 jan 2009, at 15:10, Taco Hoekwater wrote:
Hi,
In one of the next releases I want to start distributing some lua files under <texmf>/luatex/lua/
The intentions is that lua modules that are part of the luatex lua distribution will go there, nothing else. These are files that can be reached via the Lua require() function using the default compile-time package.path. Lua scripts have their place under <texmf>/scripts/lua already, and macro package specific lua files should remain below <texmf>/tex/, to be found via kpse.find_file().
The immediate candidates for inclusion are:
from lpeg, currently not distributed at all
luatex/lua/re.lua
from luasocket, currently compiled into the executable:
luatex/lua/socket.lua luatex/lua/ltn12.lua luatex/lua/mime.lua luatex/lua/socket/http.lua luatex/lua/socket/url.lua luatex/lua/socket/tp.lua luatex/lua/socket/ftp.lua luatex/lua/socket/smtp.lua
Some others may soon arise form the luatex core itself, for example for the mapping of node (sub)type numbers to strings. These ids are static for any particular version of the executable, but they are never actually used inside the engine, so it makes sense to split them off into a lua module that can be loaded on demand.
One warning and one question.
First the warning, for Hans in particular: make sure you start using require() for all of the external lua modules that are embedded in luatex. As soon as this new subsystem is in place, you can no longer use functions like socket.bind() without require-ing the module first!
Second the question, and that is mostly for Martin: when luatex starts shipping more stuff than just a single executable, it begins to make sense to have an installation method. It could be nice to be able
$ ./configure; make; make install
at toplevel, instead of
$ ./build.sh ; cp <bunch of whatever to wherever> ; ...
To be able to that, the current build scripts have to be rewritten into a unified Makefile.in. The new, to-be-created configure script can be rather stupid and may not even have to be autoconf-generated.
The aim is to get a predictable user interface, not automating the whole big build process. For example, if "make clean" would delete the build tree (if there was one), then the "--make" commandline switch would no longer be needed. Targets like "make cross" and "make native" could replace ./build.sh.linux and ./build.sh.cross, etc.
Would you (or anyone else) be willing to work on that?
Best wishes, Taco
_______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex