[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Proposal: smartlua
- From: steve donovan <steve.j.donovan@...>
- Date: Fri, 8 Mar 2013 12:17:16 +0200
On Fri, Mar 8, 2013 at 10:55 AM, Sean Conner <sean@conman.org> wrote:
> The former [monolithic exe] is *frighteningly" difficult to automate (having done a Kitchen
> Sink Lua by hand, I can't even begin to fathom the work required to have
> that done automatically), while the later [program-as-archive] appears graspable.
The former is possible, it's just hard - to automate something often
takes as long as it takes to do by hand, but the result is much more
configurable, _if_ you know in advance what is 'configurable' ;)
> Okay, in looking through an arbitrary script, you will need to look for
> the following functions:
> require()
> dofile()
> load()
> loadfile()
> loadstring()
Two approaches, as exemplified by Jay's soar:
- you monkey-patch the functions you are interested in tracing, and
run the program to find out what it needs
- do static analysis on luac output (less messing around with code parsing)
The filesystem 'virtualization' tricks look really ... tricky to get right.
> This also brings up addtional data files.
They can sit comfortably in the archive as 'resources', or get glued
to the end of the executable, as srlua already does with Lua code.
>> -download and install standard libraries if needed
That's a tough one. Spending more than 5 minutes thinking about this
you realize that you need the _functional_ equivalent of LR or LD.
And why complicate the universe by adding another? (The tricky word
here is 'standard')
> that are now incapable for downloading and installing "standard libraries"
> because they are older than twenty minutes and thus, horribly outdated and
> no longer supported
Sigh, this pursuit of the latest-and-greatest makes traditional
planned obsolescence look like building for eternity....totally at
odds with Lua philosophy.
steve d.