RE: Detecting an "empty" script?

[virgil@... (Virgil Smith)]

1. Stub scripts seem a very silly idea.  Why have a default, empty script?
If you are worried about the memory consumption of all of those scripts then
just take 1 script that assigns functions into a table (or userdata,
whatever) wherein each function is the handler for the event specified.  Run
this script once, and any events the user didn't want to handle they won't
have specified functions for (and you can check if they are nil before
calling them).

2. For best directing people responding to you I think you should clarify
whether or not this detection must be done without running the script.  If
so then you are clearly into the realm of examining the byte code (and
possibly changes to the Lua State) that results from the load operation
itself.  If detecting the distinction on first run is acceptable (say for
instance if you don't load until first run anyway), then a completely
different set of approaches is feasible (and these are much more likely to
be familiar to lots of Lua Users).

3. A runtime detection of "doing something" probably can't do any better
than to hook the global table AND the parameters to the function and detect
any read/write to a global or a parameter.  If the script only twiddles its
self defined locals it hasn't done anything meaningful (everything with
noticeable side effects has to go through a global or one of the parameters
you passed to the script/script function).  Furthermore, if you don't
trigger on even simple reads of simple (number/string) parameters then you
stand the chance of incorrectly discounting a script as "doing nothing" just
because it "did nothing" in response to the particular parameter values
passed in that particular call (i.e. conditional issues).

4. While it might seem somewhat strange, you can remove the text "main" from
your example script.  A loaded chunk has a return value.  In the absence of
an explicit return statement, the return value is the value of the last
expression evaluated, so running a script that says....

function(x,y,z) end

will return a function that takes 3 parameters, and you can store off this
function and call it either immediately or later.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Ando Sonenblick
Sent: Thursday, August 21, 2003 1:31 PM
To: Lua list
Subject: Re: Detecting an "empty" script?


Thanks guys, especially for correcting me about "main" getting set.

Here is what I'm ultimately trying to accomplish:

I have a product where the user creates many (say, several hundred) widgets.
When instantiated each widget has about 10 lua stub scripts pre-assigned to
them.  For example:

"
-- Executes in response to the user moving the mouse.

-- self [entity object]: this entity
-- x [number]: the new mouse x window position
-- y [number]: the new mouse y window position
-- dx [number]: the horizontal change
-- dy [number]: the vertical change

function main(self, x, y, dx, dy)

end
"

So, if we have 300 widgets each with 10 scripts, that's 3000 scripts - quite
a bit of memory taken up by them.

So I want to detect if the scripts actually do anything or not - and in my
case it's ok if the global "main" is reset - because I want to release any
scripts that are considered "empty."

I expect that at most 1 in 20 scripts will actually get defined by the user
and so it'll be a huge savings to release the memory of the other 19.

I can't just compare the script text with the originally provided text as a
user could mod the text but still have it do nothing.

Same with a dirty flag.

So, I'm looking to definitively determine if a script does any work (again,
other than defining main, as that is intentionally shared between all
scripts, etc).

Thx,
ando

>> For example, this script does nothing:
>>
>> "function main(arg)
>>
>> end"
>>
>> While this one does:
>>
>> "x = 4"
>
> Basically both scripts re-define the values of global variables; whether
> they are set to 4 or an empty function is beside the point.
>