Re: [Gnash-commit] gnash/libgeometry Range2d.h

[Rob Savoye]

Martin Guy wrote:

> I run Date.as with makeswf and gnash, and all the tests give the
> expected results. That has been useful, but so far I am unable to

  Try running the output of  makeswf with gprocessor -v, and make sure
that gives consistent results before deciding the testing infrastructure
is totally broken. Use just trace() it you need to make sure it's working.

> Mind you, if the current "make check/dejagnu/expect/ming" stuff is so
> badly broken as to impede progress in this way, it might be worth
> ditching in favour of something simpler that works reliably, or maybe
> stop taking what it says seriously.

  No, if there are problems in the testing infrastructure we need to fix
them. Multi-platform testing is a difficult thing, and DejaGnu handles
that and embedded systems better than any other testing harness. That's
why we use it for all GCC/GDB testing. There are a variety of ways to
debug DejaGnu oriented test cases. I'm biased though, as I wrote
DejaGnu, and also haven't been having reliability issues on my systems.
In my experience with DejaGnu/Expect, reliability problems are usually
because the pattern being looked for sometimes gets multiple lines,
instead of correctly separating them. Varying pty implementations across
platforms effects the buffering of stdout/stdin. The --debug option to
runtest turns on the Expect debug output of it's internal buffers.

  Test suites like the one in Gnash are complicated, they often take as
much time to debug in the early development stages as the code itself.
I'll see if I can find some time to dig into the expect end of the
testing code, but it can't happen right away.

        - rob -