Re: Lua on SunPlus digital photo frames

[William Ahern <william@...>]

On Sat, Jan 11, 2020 at 05:54:25PM -0500, Sean Conner wrote:
> It was thus said that the Great Rena once stated:
> > 
> > I also didn't find the bytes 19 93 0D 0A 1A 0A which are present in
> > every compiled Lua bytecode file. (I checked raw flash and
> > uncompressed firmware.) So it really does seem like there's no more
> > trace of Lua itself left in here...
> 
>   Dosn't mean it's not there.  At work, I embed Lua in one of our programs
> and all the Lua scripts are compressed [1]---I have a custom loader that will do
> the decompression upon loading.  I go over the technique here:
> 
> 	http://boston.conman.org/2013/03/22.1
> 	http://boston.conman.org/2013/03/23.1
> 
>   -spc
> 
> [1]	They are also embedded into the executable.

I've done the same thing and, like you, transformed and compressed each Lua
file individually with a simple Makefile rule. However, especially with
precompiled bytecode chunks (which are larger than their text source), this
turned out to create larger executables if there are too many short Lua
source files (e.g. wrappers) and not enough long source files. In my case,
which I suspect isn't uncommon, if would be better to compress all the
source files together. But it makes the code more complex. I independently
wrote code very similar to yours, which I doubt is a coincidence as that's
the most obvious, elegant, and, in particular, transparent way to do it.

For now I just disable bytecode precompiling, and compression partly offsets
the cost of all the additional luaopen_ functions. I don't have enough long
Lua source files for compression to pay real dividends.

I guess it also matters that I *embed* an inflate implementation to avoid an
external dependency.

  https://github.com/madler/zlib/blob/master/contrib/puff/puff.c

It's small, but again I don't have any big Lua source files to offset the
cost.