Re: [Gnash-commit] gnash ChangeLog server/swf_function.cpp

[Sandro Santilli]

On Fri, Oct 12, 2007 at 04:10:46PM +0800, zou lunkai wrote:
> > I belive swf_function should *always* use the caller's environment.
> 
> what's definition of as_environment in Gnash? Apparently it's more
> than a VM stack.

Yes, it also contains the call stack, the global registers and the target
(original and current).

Using a global registers from within a function will fail in gnash
unless the function was defined in the same as_environment of its
caller (worth adding this test, Ming doesn't know how to use registers
easily, MTASC doesn't help with multiple as_environments...).

The same layout (defined in one environment, called in another) would
also change the target and the call stack during  a single execution
thread (more bugs). 

> Let's talk about the 'target' first.
> 
> (1) if the target in which the swf_function is defined is not
> destroyed, then it is the target of this swf_function.

I should verify the test you made for this.
Note that the target in which the swf_function is defined should
be stored in the swf_function "scope" member, which should be 
taken in consideration when calling that function.

> (2) if the target is destroyed, then the caller's target is used as
> this swf_function.

Maybe this could be because the swf_function "scope" was pushed on
the caller scope chain, and scope elements are skipped when unloaded ?

> That's what I intended to do with the commit, fixed a few focused
> local tests, but triggered some other failures in our
> testsuite(MovieClip.as).

The current architecture is incredibly working by luck :)

--strk;