Re: build_requires, the xt and build_prereq_matches_use

[David Golden]

On Fri, Feb 20, 2009 at 2:30 AM, Thomas Klausner  wrote:
> I agree partly (it can look, but should not add any
> dependencies), but I'm very unlikely to find some time to fix this in
> the next weeks (http://use.perl.org/~domm/journal/38260).

Understood.  :-)

> But of course, patches welcome (eg I'd like to use Alias' new
> Find::File::Rule::Perl or take a look at Davids App::CPAN::Mini::Visit)

FFRP may be more useful.  visitcpan is mostly just handy to iterate
though CPAN and execute arbitrary commands in each directory.

-- David

Re: Make TAP::Harness Output Failures Diagnostics?

[Andy Armstrong]

On 19 Feb 2009, at 20:01, Michael G Schwern wrote:

Andy Armstrong wrote:

On 18 Feb 2009, at 22:44, Michael G Schwern wrote:
The thing which most takes advantage of this is TODO tests.  They  
send

their
failure diagnostics to STDOUT so the user is not spammed with  
passing

test
information.


I didn't know that...

The current behaviour also means that prove's --merge switch hides
diagnostics:


Remember Ovid and I going at it like Godzilla and Rodan over merging  
STDOUT

and STDERR when TH3 was being put together?



No, I wasn't there - and those who are ignorant of history are  
condemned to repeat it :)


--
Andy Armstrong, Hexten

Re: Make TAP::Harness Output Failures Diagnostics?

[Andy Armstrong]

On 19 Feb 2009, at 21:16, Michael G Schwern wrote:

This makes me think that -1 should actually be "normal", from what
Schwern has said, and 0 should include the failures and diagnostics  
and

messages and whatnot (# stuff), as Andy seems to have expected in the
past. But I can't really figure out how to change this without  
breaking

compatibility. Can you?


What prove is referring to in -1 is suppressing its own messages  
about test

failure, not TAP comments.

What you want is a .5 (didn't we figure out in BASIC that you don't  
closely

space your numeric sequences?) which is "show TAP comments".


RENUMBER

The description for verbose should really be "show the raw TAP  
stream".



Patches / commits welcome - but I'm not going to have time to do  
anything more than review said patches / commits in the next week I'm  
afraid.


Schwern: I think you have commit? David: you're welcome to have a  
commit bit if you don't already.


--
Andy Armstrong, Hexten

Re: done_testing()

[Aristotle Pagaltzis]

* Michael G Schwern  [2009-02-19 21:15]:
> As TAP has no formal means to express that, and I'm not waiting
> for a TAP extension, any TAP reader will need extra logic to
> figure that out. So worrying about that seems moot.

If it takes a lot longer and TB offers subplans in the meantime,
people will want to be able to get the information back out of
their TAP streams before formal subplans become part of the
syntax. So worrying about how they will process the output of a
stream containing implicit subplans seems entirely appropriate.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Make TAP::Harness Output Failures Diagnostics?

[Ovid]

- Original Message 

> From: Ovid 

> > Remember Ovid and I going at it like Godzilla and Rodan over merging STDOUT
> > and STDERR when TH3 was being put together?
> 
> Yup.  This has bitten me today at work.  Badly :(
> 
> All the more reason why we need TB2 to be done today :)

You know, one quick fix which can help solve this issue is to disable --merge 
unless tests are being output verbosely.  Really people only want 'merge' when 
they're generating the full TAP stream for a test (or has this already been 
suggested and I missed it in the carnage?)

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: Make TAP::Harness Output Failures Diagnostics?

[David E. Wheeler]

On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:


RENUMBER


Won't that fuck up existing users of the library?

The description for verbose should really be "show the raw TAP  
stream".


Patches / commits welcome - but I'm not going to have time to do  
anything more than review said patches / commits in the next week  
I'm afraid.


Schwern: I think you have commit? David: you're welcome to have a  
commit bit if you don't already.


Lay it on me.

Best,

David

Re: Make TAP::Harness Output Failures Diagnostics?

[Andy Armstrong]

On 20 Feb 2009, at 16:52, David E. Wheeler wrote:

On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:


RENUMBER


Won't that fuck up existing users of the library?


Yeah, I was making a BASIC joke :)

The description for verbose should really be "show the raw TAP  
stream".


Patches / commits welcome - but I'm not going to have time to do  
anything more than review said patches / commits in the next week  
I'm afraid.


Schwern: I think you have commit? David: you're welcome to have a  
commit bit if you don't already.


Lay it on me.



Mail me the output of

htpasswd -nmb foo bar

and I'll make it so.

--
Andy Armstrong, Hexten

Re: Make TAP::Harness Output Failures Diagnostics?

[David E. Wheeler]

On Feb 20, 2009, at 10:20 AM, Andy Armstrong wrote:


On 20 Feb 2009, at 16:52, David E. Wheeler wrote:

On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:


RENUMBER


Won't that fuck up existing users of the library?


Yeah, I was making a BASIC joke :)

The description for verbose should really be "show the raw TAP  
stream".


Patches / commits welcome - but I'm not going to have time to do  
anything more than review said patches / commits in the next week  
I'm afraid.


Schwern: I think you have commit? David: you're welcome to have a  
commit bit if you don't already.


Lay it on me.



Mail me the output of

htpasswd -nmb foo bar

and I'll make it so.



Thanks. I started to poke around but found that this feature is  
actually already there! It's the `failures` parameter. I just pass it  
with a true value and suddenly I see my failure output.


Well, almost. I see which test failed, which is a big help, but not  
any diagnostics. So I think I'll add a `diagnostics` parameter. Make  
sense?


Thanks,

David

Re: Make TAP::Harness Output Failures Diagnostics?

[Andy Armstrong]

On 20 Feb 2009, at 20:25, David E. Wheeler wrote:
Well, almost. I see which test failed, which is a big help, but not  
any diagnostics. So I think I'll add a `diagnostics` parameter. Make  
sense?



Yeah, I think that's reasonable - although it would be nice at some  
point to do something about the option proliferation that seems to  
afflict us. That's not your fault of course :)


You you should probably subscribe to

  http://www.hexten.net/mailman/listinfo/tapx-dev

also.

--
Andy Armstrong, Hexten

Testing scripts with expected STDOUT and STDERR in external files

[Gabor Szabo]

Lately I need to test many small utilities written in various languages.

For the most simple cases I just need to run the utilities with a set of
input
and check if the output is the same as expected.

For this it is enough to run

system "path/to/utitlity < in.txt > out.txt 2> err.txt"

and then compare them to the expected.out and expected.err
To facilitate this I generate the input and the expected output files
and put them next to the utility:


path/to/utility
path/to/utility.out
path/to/utility.err
path/to/utility.in

In case I need to test the same utility with various inputs I keep

path/to/utility
path/to/utility.2.out
path/to/utility.2.err
path/to/utility.2.in 


Sometimes these utilities need to be executed with
some other tool that even needs parameters. In such cases I use:

system "pat/to/interpreter param param  path/to/utitlity < in.txt > out.txt
2> err.txt"

In most cases all the utilities in one package need to be executed the same
way.


I wonder if there are modules out there that already do this?
I could not find any that would fit my needs.


Gabor

Re: Testing scripts with expected STDOUT and STDERR in external files

[David E. Wheeler]

On Feb 20, 2009, at 1:23 PM, Gabor Szabo wrote:


I wonder if there are modules out there that already do this?
I could not find any that would fit my needs.


Test::Output?

  http://search.cpan.org/perldoc?Test::Output

If it doesn't capture output from other programs, have a look at  
Capture::Tiny.


Best,

David

Re: Testing scripts with expected STDOUT and STDERR in external files

[Eirik Berg Hanssen]

Gabor Szabo  writes:

> For this it is enough to run
>
> system "path/to/utitlity < in.txt > out.txt 2> err.txt"
>
> and then compare them to the expected.out and expected.err

  Not what you're asking for, but when I see testing stdout and stderr
from child processes, I cannot resist ...


use Test::More tests => 2;
use Test::Trap qw( :output(systemsafe) );

trap { system "path/to/utitlity < in.txt" };
$trap->stdout_like( qr/for real!/, 'Got a matching STDOUT' );
$trap->stderr_is( '', 'Got no STDERR' );


  :-)


  (Now, if I could just whip up some support for systemsafe input as
well ...)


Eirik
-- 
An honest newspaper publishes corrections on the front page.
There are no honest newspapers.
 - Dr. Newton, Dean of Journalism, NAU.

Re: Make TAP::Harness Output Failures Diagnostics?

[Michael G Schwern]

Andy Armstrong wrote:
> On 20 Feb 2009, at 16:52, David E. Wheeler wrote:
>> On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:
>>
>>> RENUMBER
>>
>> Won't that fuck up existing users of the library?
> 
> Yeah, I was making a BASIC joke :)

A very basic joke.


-- 
44. I am not the atheist chaplain.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: done_testing()

[Michael G Schwern]

Aristotle Pagaltzis wrote:
> * Michael G Schwern  [2009-02-19 21:15]:
>> As TAP has no formal means to express that, and I'm not waiting
>> for a TAP extension, any TAP reader will need extra logic to
>> figure that out. So worrying about that seems moot.
> 
> If it takes a lot longer and TB offers subplans in the meantime,
> people will want to be able to get the information back out of
> their TAP streams before formal subplans become part of the
> syntax. So worrying about how they will process the output of a
> stream containing implicit subplans seems entirely appropriate.

And we come back to the beginning: it's all going to be ad hoc anyway until
TAP formalizes it.  Fine for eyeballing.  If someone wants to scrape the
information out they can do it from the description (with the usual caveats
about scraping).

I have a feeling we're arguing about two different things.  Or we're arguing
about a plan that was already rejected.  Or it's gotten very meta and we're
arguing about concepts.

I plan on doing this:

use Test::More;

plan( add => 1 );
pass("First test");

plan( add => 2 );
pass("Second");
pass("Third");

done_testing(5);

to produce this:

ok 1 - First test
ok 2 - sub-plan at foo.t line 3
ok 3 - Second
ok 4 - Third
ok 5 - sub-plan at foo.t line 6
1..5

Hmm, maybe it should be subplan() instead of plan().  That lines up with the
output, and it allows a subplan description.

subplan(2, "frobnitzing the widget");
# ok 4 - subplan: frobnitzing the widget


-- 
164. There is no such thing as a were-virgin.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Make TAP::Harness Output Failures Diagnostics?

[David E. Wheeler]

On Feb 20, 2009, at 12:34 PM, Andy Armstrong wrote:

Yeah, I think that's reasonable - although it would be nice at some  
point to do something about the option proliferation that seems to  
afflict us. That's not your fault of course :)


Thanks.


You you should probably subscribe to

 http://www.hexten.net/mailman/listinfo/tapx-dev

also.


Done. Moving conversation over there.

Best,

David

Re: Make TAP::Harness Output Failures Diagnostics?

[David E. Wheeler]

On Feb 20, 2009, at 12:34 PM, Andy Armstrong wrote:

Yeah, I think that's reasonable - although it would be nice at some  
point to do something about the option proliferation that seems to  
afflict us. That's not your fault of course :)


Thanks.


You you should probably subscribe to

http://www.hexten.net/mailman/listinfo/tapx-dev

also.


Done. Moving conversation over there.

Best,

David

Re: done_testing()

[Aristotle Pagaltzis]

* Michael G Schwern  [2009-02-20 23:35]:
> And we come back to the beginning: it's all going to be ad hoc
> anyway until TAP formalizes it. Fine for eyeballing. If someone
> wants to scrape the information out they can do it from the
> description (with the usual caveats about scraping).

What I am saying is that just because they are… *wrinkles nose*
…scraping [yuck, I feel dirty] doesn’t mean we shouldn’t try to
make it as easy as possible.

Something about cow paths… so do we want those established by the
scraping plebes or not?

> I plan on doing this:

So you see no way of doing it as a test numbering scheme? I would
still prefer that…

Although, that solution is acceptable as a distant second choice.

Regards,
-- 
Aristotle Pagaltzis //