Re: [tap] "ok 1 description" vs "ok 1 - description"

Steffen Schwigon <ss5@renormalist.net> Sat, 31 January 2009 22:25 UTC

Return-Path: <tap-bounces@ietf.org>
X-Original-To: tap-archive@ietf.org
Delivered-To: ietfarch-tap-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA963A6A30; Sat, 31 Jan 2009 14:25:26 -0800 (PST)
X-Original-To: tap@core3.amsl.com
Delivered-To: tap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F296E3A6A99 for <tap@core3.amsl.com>; Sat, 31 Jan 2009 14:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY3yYty+kL9d for <tap@core3.amsl.com>; Sat, 31 Jan 2009 14:25:10 -0800 (PST)
Received: from h132974.serverkompetenz.net (renormalist.net [81.169.141.46]) by core3.amsl.com (Postfix) with ESMTP id 352833A6A30 for <tap@ietf.org>; Sat, 31 Jan 2009 14:25:09 -0800 (PST)
Received: from ss5 by h132974.serverkompetenz.net with local (Exim 4.63) (envelope-from <ss5@renormalist.net>) id 1LTOGe-0005Ii-Bq for tap@ietf.org; Sat, 31 Jan 2009 23:24:48 +0100
To: tap@ietf.org
References: <497A77D0.8070500@pobox.com> <335014.20536.qm@web65715.mail.ac4.yahoo.com> <20090124115427.GC9114@pjcj.net> <87vds4podb.fsf@renormalist.net> <497B8530.4080903@pobox.com>
From: Steffen Schwigon <ss5@renormalist.net>
Date: Sat, 31 Jan 2009 23:24:48 +0100
Message-ID: <873aezxgen.fsf@renormalist.net>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Subject: Re: [tap] "ok 1 description" vs "ok 1 - description"
X-BeenThere: tap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Test Anything Protocol WG discussions <tap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tap>, <mailto:tap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tap>
List-Post: <mailto:tap@ietf.org>
List-Help: <mailto:tap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tap>, <mailto:tap-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tap-bounces@ietf.org
Errors-To: tap-bounces@ietf.org

Sorry for the late answer, I seem to be out of sync with the rest of
the world ...

Michael G Schwern <schwern@pobox.com> writes:
> Steffen Schwigon wrote:
>> IMHO when the TAP grammar changes things that were stable for
>> years it's near to the end of the world.
>>
>> I, for instance, evaluate test results via the description over
>> *lots* of archived TAP streams since nearly years. I don't want
>> to become an outlaw.
>
> Out of curiosity, what are you using to create these TAP streams
> and how do they format the description?

They are created within a heterogeneous environment with Perl
Test::More, Python PyTAP, and "echo/print" from Shell or C.

To process the TAP, however, we use the Perl toolchain around
TAP::Parser.


> Seeing as how Test::More is the widest producer of TAP, and it's
> being doing "ok 1 - description" for years now, and that the dash
> is optional so nothing is being made illegal, all of the above
> would seem to actually be an argument in favor of adding the
> optional dash to the grammar as it better describes reality.
>
> And it produces a nicer to read TAP moving forward, which is
> important, too.

I see that the dash was meant optional for TAP. Maybe the
optionality of the dash changed in TAP::Parser 3? Admittedly, I
didn't try.

Anyway, the only useful current processing tool is TAP::Parser and
that slurps the dash as part of the description.

So it's probably not the producers like Test::*, PyTAP and
"print" but the history of the *consumer*, i.e. TAP::Parser,
that I'm worrying about.

Someone(tm) (not me, I know, sorry) could try out what happens
around CPAN (as the largest reference test suite) if the grammar is
changed in TAP::Parser.


> As a point of reference, we are discussing the grammar exactly
> because we're trying to write down reality.

I see. But wasn't the original plan to write down what the only
existing consumer toolchain aka. TAP::Parser does, because else no
one in the world has a toolchain?


Kind regards,
Steffen
-- 
Steffen Schwigon <ss5@renormalist.net>
Dresden Perl Mongers <http://dresden-pm.org/>
German Perl-Workshop 2009 <http://www.perl-workshop.de/en/2009>
_______________________________________________
tap mailing list
tap@ietf.org
https://www.ietf.org/mailman/listinfo/tap