lua-users home
lua-l archive

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

Rici Lake wrote:

>So if you have an application which, for example, exchanges Lua
>executables (possibly as data descriptions) across a slow network, you
>are probably better off stripping comments and compressing the source
>code; you could decompress and compile at the receiving end,

Just a note that it's pretty easy to use lua_load to load compressed files
(and for that matter to use lua_dump to save compressed files). I've written
a version of etc/min.c to test this that I attach below.

>possibly stripping debugging information to save storage (see luac.c
>for how to do this; it is one of the few things luac.c actually does,
>see below.)

Actually, it's even easier to change ldump.c to simply avoid saving this
information in the first place. But yes, luac.c is doing less and less each
time; now that ldump.c is part of the core, luac essentially simply combines
several chunks into one and provides listings. And this is a good thing.

>luac does practically nothing you could not do in a few lines
>with the standard api.

Or even in Lua, for that matter. See test/luac.lua.

>It is worth looking at luac.c as an example of how
>to integrate Lua in an application.

Yes. From the start, luac was developed in "client mode". See
just before "International Exposure". Search for "client".