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

[Matthew Wild <mwild1@...>]

On 7 April 2012 18:53, David Manura <dm.lua@math2.org> wrote:
> 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].

Right, Squish is intended as a command-line utility, that just happens
to be written in Lua. Converting it to a module would be entirely
possible of course, I just never saw a use-case for that. I expected
Squish to be used as part of a build process, etc.

> 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.

Not at all the case. Squish at the highest level just combines
modules, scripts and resources into a single valid .lua file. As a
feature it has a variety of filters it can run the produced file
through. Minify is one of these filters, and the majority of that
filter's code comes from LuaSrcDiet. Similarly, the majority of the
gzip filter's code is your deflatelua library.

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

Noted, thanks. As I mentioned, none of my projects are 5.2-tested yet.

> 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:
>

I agree, dead-code elimination would be great. Actual effectiveness
would vary greatly depending on the kind of input, but you're right
that when depending on something like Penlight, it could be very
helpful.

>>> 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.

LuaJIT's bytecode loader still isn't compatible with Lua's as far as I
know, so the same problem still applies if you want to target both
with the same code.

> Perhaps merging+DCE is orthogonal and best done in a tool separate
> LuaSrcDist but which could be interfaced to it in a pipeline.

Sounds rather like Squish and its filters :)

Regards,
Matthew