On 3/28/06, Tassilo von Parseval <tassilo.von.parseval@xxxxxxxxxxxxxx> wrote:
> On Tue, Mar 28, 2006 at 11:27:15AM +0100 Fergal Daly wrote:
> > That's why I said you prefix with a ".".
> >
> > This has the effect of making it not a number as far as TAP is
> > concernted, instead it becomes part of the name.
> >
> > Of course it would be better to allow "."s in the number, that way you
> > can check that they are increasing properly and allows you to have
> > sub-plans (so each fork/thread/block can have it's own plan) rather
> > than just having 1 single overall plan for the whole thing. Having 1
> > overall plan means that if one fork skips a test and the other does an
> > extra test you won't notice.
> >
> > Given that x.x.x.x currently causes an error for TAP, changing the
> > protocol to allow it would not break anything.
>
> But you see, it does make a change in (or an addition to) the protocol
> necessary afterall since it currently doesn't work as you said yourself.
No change is required in TAP to suport "numbers" that begin with a "."
because TAP interprets them as names not numbers. (TAP protocol says
that test numbers are optional).
Forget my comments about altering TAP, that was wishlist stuff and
should not be confused with my suggestion for the current problem.
> No matter what you do, you either have to change Test::Harness or the
> module generating the TAP output. Or even both as in your case.
No.
> I think
> any conceivable solution will have its ugly points. It's now a matter of
> finding a simple and robust approach and put it in.
Anything that attempts to synchronise across processes is harder to
make robust and less likely to be simple.
F
>
> Cheers,
> Tassilo
> --
> use bigint;
> $n=71423350343770280161397026330337371139054411854220053437565440;
> $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
>
>
|
