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
- [tap] "ok 1 description" vs "ok 1 - description" Michael G Schwern
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Ovid
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… H.Merijn Brand
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Paul Johnson
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Steffen Schwigon
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Michael G Schwern
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… David E. Wheeler
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Steffen Schwigon
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Michael G Schwern
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Steffen Schwigon
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Michael G Schwern
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Steffen Schwigon
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Michael G Schwern
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… H.Merijn Brand
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Michael Peters
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Leon Timmermans
- Re: [tap] "ok 1 description" vs "ok 1 - descripti… Steffen Schwigon