Re: Explicitly triggering the Garbage Collector

[Rici Lake <lua@...>]

On 7-Aug-05, at 12:18 PM, Uli Kusterer wrote:

>  In particular, how likely is the compiled file format to change 
> again? It would be rather handy if I could ship compiled scripts 
> because they wouldn't be as readable as plain text.

I would guess that the compiled file format is likely to change (at 
least a little bit) with every release. Backwards compatibility of 
bytecode is not a priority (nor should it be imho). The API is fairly 
stable, but minor changes do occur, so you are likely to need to 
recompile extensions for a new version anyway; adding a step to compile 
byte code for the new version is not much more difficult if you have a 
decent make tool.

Byte code is not completely platform-independent, in any event, and it 
has been suggested that it may become even less platform-independent in 
the future. One way to distribute Lua programs as part of an 
application is to simply include the Lua source code in a file:

/* This is *not* the 5.1 module style, but it works with 5.0.2 */
const char[] mylib =
 "mylib = {} \n"
 "function mylib.frobnicate(x) ... end \n"
 "function mylib.defrobnicate(x) ... end \n"
 "return mylib \n"
;

int luaopen_mylib (lua_State *L) {
  if (luaL_loadbuffer(L, prog, sizeof(mylib)-1, "mylib")
      || lua_pcall(L, 1, 0)) {
    // for debugging, use: lua_error(L, 1)
    fprintf(stderr, "Mysterious error at startup\n");
    exit(1);
  }
  return 1;
}

If you want to obscure the source code more than that, gzip it before 
inserting it into the C source, and use zlib to decompress it before 
calling luaL_loadbuffer, or write a little decompressing string loader 
and use lua_load. (I don't think this is a very good way of hiding your 
code; it is only effective against stupid people without smart friends 
:) But it does reduce executable size if the scripts are large.)