Re: [Gnash-dev] Dejagnu.swf loadable module

[Sandro Santilli]

News from the "Dejagnu.swf" shared library front, and
a question about correct interpretation of the IMPORT tag.

Current head branch does now use the shared library
for our actionscript.all testcases, and seems to
work fine. The shared library is only used when explicitly
running 'make <testname>.swf', and NOT when running 'make check'.

Use of the Dejagnu.swf library makes the '*.vswf' (visual SWF testcases)
obsolete, as Dejagnu.swf itself will provide 'visual' traces in a way
that is supported by Gnash (no use of the drawing api).

NOTE1: due to a bug in latest Ming release the "visual" traces
won't work. Anyway, the 'bare' traces would still be used as a fall-back.
If you install Ming from it's current repository you should be able
to see the 'visual' traces (but not all players will show you them)

NOTE2: a *possible* bug in Gnash makes use of the Dejagnu.swf module
       non-functional, even when the testcases are compiled with 
       the development version of Ming, see below.

About *possible* bug in Gnash interpretation of the IMPORT tag.

When an IMPORT tag is encountered, Gnash will load the movie from
it's url specification, and then will try to extract exported simbols
from it.

Now, since we load using a separate thread, the imported movie might
have been not yet parsed up to the EXPORT tag, which means that the
IMPORT tag executor will NOT find the exported symbol.
I'd assume that the IMPORT tag executor should wait for the imported
movie to be FULLY LOADED before proceeding, but I'm unsure about wheter
this would be the correct semantic for it. A 'stricter' way would be
to load it as much as an EXPORT tag is encountered, but again I'm not
sure if multiple EXPORT tags are allowed in a movie. So, my suggestion
is that we *fully* load imported movies before proceeding. Do you
think this is the correct way to go ?


--strk;

On Thu, Nov 16, 2006 at 08:49:11AM +0100, Sandro Santilli wrote:
> On Thu, Nov 16, 2006 at 12:35:33AM +0000, Sandro Santilli wrote:
> 
> > Log message:
> >             * testsuite/misc-ming.all: ming_utils.{c.h}: add
> >               a get_dejagnu_clip() function.
> >             * testsuite/misc-ming.all: Makefile.am, Dejagnu.c:
> >               initial version of a loadable Dejagnu module for SWF
> >               (needs more work)
> 
> A bit more information on this commit in head.
> I'm preparing a loadable "Dejagnu" module for use by self-contained
> testcases that do NOT use Ming as their generator (we have other
> free generators for SWF output...).
> So far the module can be "imported" (symbol name: "dejagnu") from
> your SWF and you can use the 'check', 'xcheck', 'check_equals',
> 'xcheck_equals' and 'totals' functions from your SWF.
> 
> Note that due to actions execution order the functions will only be
> available one-frame-after the frame including the IMPORT tag, so if
> needed you'll have to insert a "do-nothing" frame at start of your SWF.
> 
> My plan is to use this 'loadable module' when creating the 'visual' versions
> of our actionscript.all testcases. This is because the 'loadable module'
> has a couple of advantages over the current 'visual trace':
> 
>       1) current 'visual trace' uses the drawing api, which is
>          NOT implemented in gnash.
> 
>       2) current 'visual trace' uses the drawing api, which is
>          NOT available when target SWF is 5.
> 
>       3) using an external, loaded, module, will allow us to make
>          the module smarter in the future so to also report
>          test results to an online-database application.
> 
> Tests welcome :)
> 
> --strk;
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.