Byte Code and Backwards Compatibility (was Re: Explicitly triggering the Garbage Collector)

[Uli Kusterer <witness.of.teachtext@...>]

On Aug 7, 2005, at 19:43:10, Rici Lake wrote:
> 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).

Actually, for my uses it would really be an advantage. I'm not saying  
I want to be able to run code compiled by a newer Lua version in the  
older one, but the other way round would be handy: If I compile Lua  
Code with 5.0, I'd really like if I could feed that file into 5.1 and  
still have it work like before.

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

 The problem in my case is that the byte code wouldn't be part of my  
application. My app is simply an engine, which runs compiled Lua  
scripts and provides a runtime environment (certain object  
hierarchies and a GUI) for them. It would be a disadvantage for users  
of this app if they had to recompile the scripts for each new version  
of the engine.

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

 Hmmm... I was hoping to use compiled code as an advanced feature,  
but in this case, I guess it would be pretty useless for me. I guess  
I'll really have to find another way of packaging the scripts. Pity.

> One way to distribute Lua programs as part of an application is to  
> simply include the Lua source code in a file:

 Well, in my case, the programs would not necessarily be part of an  
application. There would be standalones, but there would also be a  
"runner" and separate script files.

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

 Yeah, just making them ZIP files wouldn't be very safe. I won't  
even try to deter anyone hell-bent on getting the data out of the  
file, but it's not really very desirable to make it as easy as just  
changing the suffix to .gz and suddenly the files unpack before your  
eyes...

Cheers,
-- M. Uli Kusterer
http://www.zathras.de