Re: [ANN] LuaSrcDiet-0.12.1 (minor) release

[David Manura <dm.lua@...>]

On Sat, Apr 7, 2012 at 10:15 AM, Matthew Wild <mwild1@gmail.com> wrote:
> On 7 April 2012 07:44, KHMan <keinhong@gmail.com> wrote:
>> This would be relevant for lstrip and squish too.

When using squish, I found the module organization confusing and
wanted a published API to call from a Lua program (not command-line)
like this:

  package.path = 'squish-0.2.0/lua/?.lua;' .. package.path
  local SQ = require 'squish'
  local err; s, err = SQ.minify_string(s)

Instead, I ended up loading it via dofile [1].

My other impression was that squish forked/superseded LuaSrcDiet, so I
used squish.  However, I see some useful documentation in LuaSrcDiet
that is not in squish like TechNotes.html, so I'm unsure how these
relate.

The calls to getfenv() should also be removed in squish for 5.2 compat.

The feature I think these programs can benefit from the most is dead
code elimination (DCE).  Some of that is done in LuaInspect where AST
nodes for certain statements/blocks are marked as dead and AST nodes
of certain local variables (including local functions) are marked as
unused, and the same applies for corresponding tokens in the token
list.  One may want to extend this to inter-module DCE:

  -- foo.lua
  local M = {}
  function M.a() . . . end; function M.b() . . . end; function M.c() . . . end
  return M

You would, however, need to have the full list of modules that might
require 'foo' and then determine which functions in 'foo' are not used
by those other modules, probably skipping DCE in more complex cases
(e.g. metatables on M).  If you merge modules into a single source
file prior to minimization, then this is somewhat simplified.  This
was also mentioned in relation to soar [2,3] for the purpose of
merging modules into a single file, in which case the goal is not
necessarily to minimize/obfuscate--in fact, perhaps quite the
opposite.

>> so that the level of interest can be gauged and plans adjusted

Since minimized Lua source is considered in a way a type of byte code
that's portable, some have used this type of thing in LuaJit -prior-
to its addition of bytecode loading/saving support, and it may still
have applications like that.  The interesting thing about DCE is that
it will also reduce the native byte code size, particularly when
dealing with larger libraries like penlight, of which you might only
use a couple functions (so many people manually do copy/paste).
Perhaps merging+DCE is orthogonal and best done in a tool separate
LuaSrcDist but which could be interfaced to it in a pipeline.

[1] http://lua-users.org/lists/lua-l/2012-03/msg00722.html
[2] http://lua-users.org/lists/lua-l/2012-02/msg00609.html
[3] http://lua-users.org/lists/lua-l/2012-04/msg00151.html