[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Byte Code and Backwards Compatibility (was Re: Explicitly triggering the Garbage Collector)
- From: Uli Kusterer <witness.of.teachtext@...>
- Date: Sun, 7 Aug 2005 20:42:26 +0200
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