On 20 Apr 2006, at 16:55, Michael Peters wrote:
[snip]
I'm not sure I agree that there is a difference between them. They are
both comments output by the tests. Just because one comes from the
testing routine used by the test and the other from the test itself
doesn't mean they aren't both just
(Oops. Accidentally sent this to Michael directly rather than to the
list.)
--- Michael Peters <[EMAIL PROTECTED]> wrote:
> I'm not sure I agree that there is a difference between them. They
> are
> both comments output by the tests. Just because one comes from the
> testing routine used by the t
Ovid wrote:
> --- Adrian Howard <[EMAIL PROTECTED]> wrote:
>> I've thought in the past about about using /^## / for non-test
>> related diagnostics
>>
>> ## Start the fribble tests
>> ok 1 - fribble foo
>> not ok 2 - fribble bar
>> # Failed test 'fribble bar'
>> # in untitled text 2 at line
--- Adrian Howard <[EMAIL PROTECTED]> wrote:
> I've thought in the past about about using /^## / for non-test
> related diagnostics
>
> ## Start the fribble tests
> ok 1 - fribble foo
> not ok 2 - fribble bar
> # Failed test 'fribble bar'
> # in untitled text 2 at line 5.
> # got: '
On 19 Apr 2006, at 09:02, Ovid wrote:
[snip]
From a parser standpoint, there's no clean way of distinguishing that
from what the test functions are going to output. As a result, I
really think that "diag" and normal test failure information should be
marked differently (instead of the /^# / tha
I can't remember the exact list off the top of my head.
At the time, I did the cascade tracing by hand using the CPANTS webpage,
it took for-bloody-ever. The only reason I kept doing as deep as I did
was that I kept being astonished at what was getting caught in the web.
There's been somethin
* Fergal Daly <[EMAIL PROTECTED]> [2006-04-19T15:24:51]
> On 4/19/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> >
> > There are other things that test test output, like Test::Tester. Will they
> > break? To find out, I downloaded a pristene copy of the latest Test-Simple
> > and Test-Tester and
On 4/19/06, David Wheeler <[EMAIL PROTECTED]> wrote:
> On Apr 19, 2006, at 12:14, Fergal Daly wrote:
>
> > One other reason (that I didn't see mentioned) is that objects imply
> > that the harness and tests are in the same process which means that
> > the tests can corrupt the harness and that the
On Apr 19, 2006, at 12:14, Fergal Daly wrote:
One other reason (that I didn't see mentioned) is that objects imply
that the harness and tests are in the same process which means that
the tests can corrupt the harness and that the harness can fail to
report if the test process dies,
Well, the h
On 4/19/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> * Ovid <[EMAIL PROTECTED]> [2006-04-19T04:02:31]
> > From a parser standpoint, there's no clean way of distinguishing that
> > from what the test functions are going to output. As a result, I
> > really think that "diag" and normal test failu
On 4/18/06, Ovid <[EMAIL PROTECTED]> wrote:
> --- David Wheeler <[EMAIL PROTECTED]> wrote:
> > Test.Simple—JavaScript. It looks and acts just like tap, although in
> > reality it's tracking test results in an object rather than scraping
> > them from a print buffer.
> >
> >http://openjsan.org/d
On 4/18/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> The aformentioned change to Test::Builder broke 3 different Test-Testing
> modules that relied on it.
3? I only know of 2 - Test::Builder::Tester (which scrapes and broke)
and Test::Tester (which doesn't scrape and didn't break). Is there
anoth
* A. Pagaltzis <[EMAIL PROTECTED]> [2006-04-19 19:10]:
> Use JSON. It’s cross-language, can fit data structures on a
> single line, is reasonably widely supported, and can even be
> read by a YAML parser.
Oh, and I forgot: in contrast to YAML, the spec is so simple
that it’s trivial to cook an imp
* Ovid <[EMAIL PROTECTED]> [2006-04-19 10:05]:
> --- demerphq <[EMAIL PROTECTED]> wrote:
> > I should think that youd have a much easier time using
> > Data::Dumper and its ->Pad and ->Indent(0) method than you
> > ever would with YAML.
>
> That fails when we have PHP, C, or Java producing the
> i
* Ovid <[EMAIL PROTECTED]> [2006-04-19T04:02:31]
> From a parser standpoint, there's no clean way of distinguishing that
> from what the test functions are going to output. As a result, I
> really think that "diag" and normal test failure information should be
> marked differently (instead of the
--- Ovid <[EMAIL PROTECTED]> wrote:
> > If you mean you want pluck YAML test results from a noisy input
> > stream I'd say youd probably be wrong.
Naturally, I forgot to include the most compelling argument. The
"noisy input stream" is noisy only because we've never tamed it. If it
becomes well-
--- demerphq <[EMAIL PROTECTED]> wrote:
> On 4/19/06, Ovid <[EMAIL PROTECTED]> wrote:
> > to handle got/expected failure information in Java or C? There are
> > pretty rich data structures we could put out there and YAML might
> help.
> > That would also likely simplify a parser.
>
> If you mea
On 4/19/06, Ovid <[EMAIL PROTECTED]> wrote:
> to handle got/expected failure information in Java or C? There are
> pretty rich data structures we could put out there and YAML might help.
> That would also likely simplify a parser.
If you mean you want pluck YAML test results from a noisy input s
* Ovid <[EMAIL PROTECTED]> [2006-04-19 07:20]:
> What if someone wants more diagnostic information or more
> complete failure information? We might find things useful
> enough that that we feel compelled to update TAP. If so, TAP
> needs to be versioned and we need to figure out how to
> accomoda
--- Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > While I agree that this caused problems, those modules were relying
> on a
> > format that was not spec'ed out or documented.
>
> That is irrelevant. You put something into CPAN, get massive numbers
> of
> people using it, and leave it alone and ha
Geoffrey Young wrote:
Adam Kennedy wrote:
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not spec
Geoffrey Young writes:
> Adam Kennedy wrote:
>
> > That is irrelevant. You put something into CPAN, get massive numbers
> > of people using it, and leave it alone and have it remain stable for
> > 4 years, it becomes an API whether you wanted it to be or not :)
>
> really?
I'm with Adam on this
Adam Kennedy wrote:
>
>>> Schwern made one small change in the STDERR format, and the recursive
>>> cascade of failing test-testing modules hit something like 3000 CPAN
>>> distributions.
>>
>>
>> While I agree that this caused problems, those modules were relying on a
>> format that was not spe
chromatic wrote:
> On Monday 17 April 2006 18:50, Ovid wrote:
>
>
>>The only problem I see with that is the occasional buffering errors I
>>see on my Mac where the STDERR and STDOUT don't line up.
>
>
> Agreed. Is it too late to send everything to STDOUT where it belongs?
just for everyone'
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not spec'ed out or documented.
That is irrelevant
Adam Kennedy wrote:
> chromatic wrote:
>> On Monday 17 April 2006 18:50, Ovid wrote:
>>
>>> The only problem I see with that is the occasional buffering errors I
>>> see on my Mac where the STDERR and STDOUT don't line up.
>>
>> Agreed. Is it too late to send everything to STDOUT where it belong
* Adam Kennedy <[EMAIL PROTECTED]> [2006-04-18 09:30]:
> especially out there in the darkpan.
What about the deadpan?
SCNR,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
On Tuesday 18 April 2006 00:20, Ovid wrote:
> As a language-independent tool, an API is silly and
> I'm a fool for shooting my keyboard off for thinking only about the
> implementation problems as opposed to its benefits.
I'm sure you're not the only person who has thought "Hey, screen scraping t
chromatic wrote:
On Monday 17 April 2006 18:50, Ovid wrote:
The only problem I see with that is the occasional buffering errors I
see on my Mac where the STDERR and STDOUT don't line up.
Agreed. Is it too late to send everything to STDOUT where it belongs?
Unfortunately, it probably is too
--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> If that were universally true, we wouldnât have plaintext network
> protocols, would we? And I think making TAP a protocol instead of
> an API was the right choice.
As already noted, I freely admit I was wrong. If TAP was a "Perl only"
thing, I mi
Ovid wrote:
--- David Wheeler <[EMAIL PROTECTED]> wrote:
Test.Simple—JavaScript. It looks and acts just like tap, although in
reality it's tracking test results in an object rather than scraping
them from a print buffer.
http://openjsan.org/doc/t/th/theory/Test/Simple/
Tracking the resul
* Ovid <[EMAIL PROTECTED]> [2006-04-18 03:15]:
> Tracking the results in an object is a better choice than
> scraping from a print buffer.
If that were universally true, we wouldn’t have plaintext network
protocols, would we? And I think making TAP a protocol instead of
an API was the right choice
On Monday 17 April 2006 18:50, Ovid wrote:
> The only problem I see with that is the occasional buffering errors I
> see on my Mac where the STDERR and STDOUT don't line up.
Agreed. Is it too late to send everything to STDOUT where it belongs?
-- c
--- chromatic <[EMAIL PROTECTED]> wrote:
> There are a lot of reasons why having separate testing and analysis
> processes are very good and there are a lot of reasons why having
> file-based communication is very, very good.
OK, you raise some good points. Then by relying on the output and
scra
On Monday 17 April 2006 18:09, Ovid wrote:
> Tracking the results in an object is a better choice than scraping from
> a print buffer. One of the frustrating issues with Perl's testing
> tools is the limited flexibility we have due to reading the output from
> STDOUT.
... an object of which TAP-
Ovid <[EMAIL PROTECTED]> wrote:
> Tracking the results in an object is a better choice than scraping from
> a print buffer. One of the frustrating issues with Perl's testing
> tools is the limited flexibility we have due to reading the output from
> STDOUT.
I like that aspect about TAP...
--- Andy Lester <[EMAIL PROTECTED]> wrote:
> > Since it looks like we're going to stick with reading information
> from
> > a print buffer, we should at least publish an EBNF grammar for the
> > output.
>
> Patches welcome!
OK, I've a bunch of TPF stuff I'm wrapping up, but if I have some tuits
Since it looks like we're going to stick with reading information from
a print buffer, we should at least publish an EBNF grammar for the
output.
Patches welcome!
(Interestingly, if we did that, we could potentially
incorporate that into Test::Harness and allow folks to provide their
own gram
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> Test.SimpleJavaScript. It looks and acts just like tap, although in
> reality it's tracking test results in an object rather than scraping
> them from a print buffer.
>
>http://openjsan.org/doc/t/th/theory/Test/Simple/
Tracking the results in
On Apr 17, 2006, at 06:03, Andy Lester wrote:
Can you please give me a short couple of sentences on it for
someone who has no idea how/why you'd use TAP outside of Perl?
It's a direct port of Test::Builder, ::Simple, and ::More, along with
a harness for showing test results in a browser. Wh
Andy Lester wrote:
>
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
all the big PHP players now produce TAP
o phpt (outputs TAP by default as
Test.Simple—JavaScript. It looks and acts just like tap, although
in reality it's tracking test results in an object rather than
scraping them from a print buffer.
http://openjsan.org/doc/t/th/theory/Test/Simple/
Can you please give me a short couple of sentences on it for someone
who h
How non-Perl do you want? Does the Perl 6 version of Test.pm or
Test::Builder/Test::More count? How about the Parrot versions?
Sure, lemme have 'em.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Sunday 16 April 2006 20:08, Andy Lester wrote:
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
How non-Perl do you want? Does the Perl 6 version o
On Apr 16, 2006, at 20:08, Andy Lester wrote:
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/
TAP.pod
If you know of one, please send me some text to add.
Test.Simple—JavaScript. It looks and acts just like tap, a
* Ricardo SIGNES <[EMAIL PROTECTED]> [2006-04-16T23:33:19]
> It's not really ready to be publicized, and I haven't touched it in a little
> while, but I'll mention PyTap: http://svn.codesimply.com/projects/pytap
I got a request, off-list, for more info, so here is some:
PyTap will, when it's done
* Andy Lester <[EMAIL PROTECTED]> [2006-04-16T23:08:26]
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
It's not really ready to be publicized, and I
I'm adding a section to Test::Harness::TAP on non-Perl TAP.
http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
If you know of one, please send me some text to add.
Thanks,
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
48 matches
Mail list logo
