Re: Locking Table Member Additions

[Paige DePol <lual@...>]

On Jun 18, 2014, at 7:21 AM, Thomas Jericke <tjericke@indel.ch> wrote:

>> On 06/18/2014 02:02 PM, Paige DePol wrote:
>> Okay, again, good point! :)
>> 
>> While compiled binary scripts can be larger than the original source, I still think it would be an uncommon case overall, especially if the binary file was also stripped of debugging information. Now I want to go grab a bunch of random Lua scripts and compile them! ;)
>> 
>> For the situation that originated this discussion, the use of Lua on restricted hardware, I think the use of compiled (and stripped) scripts and the removal of the parser from the Lua core could be beneficial overall.
>> 
>> ~pmd
> 
> Well I am very interested in any insight. I dodged the question for our system as I let the user decide what he wants to do by an option (text, code, code stripped) to the downloader.
> 
> Other than space, I also think runtime is an important issue. If I download bytecode, the embedded target doesn't have to parse, which takes some time for applications where you download Lua scripts a lot.
> --
> Thomas

From what I have seen there is no one-solution-for-everyone type situation for Lua. Given that Lua is designed for use on anything from embedded hardware to software gaming engines the ways that it is used can vary significantly.

For my own example, I intend to remove the parser from the Lua core for projects that do not require the ability to compile scripts. However, during debugging I would leave the parser intact so scripts could be dynamically reloaded during development. For release the parser could be removed and the scripts all pre-compiled.

~pmd