Re: Lua that generates executables?

["Ashwin Hirschi" <deery@...>]

It's nice to see that the Lua ARchive idea is actively being worked on!

My company has developed a near-identical concept to create packaged distributions for easy deployment. Our runtime can load both code & data directly (and indeed transparently) from an archive. It really is a very nice setup and works marvellously.

Previously deploying a product meant unzipping an archive containing the runtime as well as the compiled application and library scripts onto the clients' machine. To be honest, I find this more than acceptable when installing larger systems, like client-server applications, at a customer's site. Especially since someone's driving up there anyway, and you have the additional benefit of amusing your client by installing a heavy-duty client-server product in less than five minutes [and from a floppy disk no less! ;-)].

But since we also develop smaller tools for specialized markets [and don't always enjoy travelling] I started looking into ways to provide even cleaner installs. Our base system takes about 70 small (Lua) library scripts to handle things like the graphical user-interface, multi-threading, communication and the like. Everything's nicely organized into directories, but still... it's not something I'd like to provide to customers without an installer...

So, thinking about it, it was an easy step to take the initial approach of unzipping scripts during install to unzipping the scripts when the system actually needs them.

Our approach is not based on luazip, but it does use zziplib [that luazip relies on as well, I think]. This library seems to work as advertised and also provides interesting features to enable extra processing for de-shrouding and such. Having said that, we are actually in the process of exchanging it for something else, mainly to allow us to also create/update archives.

As far as benefits go, it's true compiled Lua scripts take very little space.

But, looking at our latest product, even small (non-trivial) applications *do* benefit from compression: the deployment set (library and application scripts as well as data files, like GUI definitions and things like colour schemes) takes about 260k. The archived version is only 112k. So, even counting the code to support the transparent unzipping of it all, you win.

Deployment is trivial: since the system is self-configuring [i.e. we create require's LUA_PATH based on - and relative to - the location of the executable], users can simply put the runtime and its archive anywhere they like. And it runs as is. This is somewhat similar to Jean-Claude Wippler's Starkit concept [that I was happy to see got a mention here on the list as well].

A benefit that hasn't been mentioned yet [or has only been hinted at?] is *updating* deployed systems.

Since our deployed software can basically be a small runtime (about 200k) and an archive to hold the actual logic and data, updating the system becomes a matter of swapping the old archive for the new, updated one. You don't, for example, run the danger of losing inter-script integrity: dependencies between the scripts within the archive are clear and contained. And, last but not least, those paranoid of mind can keep the old version by simply hanging on to the original application archive, knowing they can restore the old setup by a simple 1-file replace.

Lastly, somewhat to my initial surprise, there's no actual slow-down while the application starts (from an archive-based configuration). The time it takes to decompress the scripts and data must be offset by the fact there's a lot less file-IO going on, I guess. So no complaints here either!

Anyway, this turned out quite a bit longer than I anticipated... But I hope I managed to illustrate that a well-integrated Lua ARchive mechanism is definitely something that's nice to have. I'm pretty sure many people will enjoy it, once they experience the potential benefits.

Ashwin.
--
no signature is a signature.