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; _______________________________________________ Gnash-commit mailing list Gnash-commit@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-commit
