Re: Testing print failures

2008-01-07 Thread Eric Wilhelm
# from Nicholas Clark # on Monday 07 January 2008 08:25: >I think that it's already been suggested that it can be done lexically > in 5.10 (and later) by inspecting $^H, and only croaking if it's void > context and and a user defined lexical pragma has enabled it. Yes, and that's the only way I w

Re: Testing print failures

2008-01-07 Thread Adrian Howard
On 7 Jan 2008, at 16:29, Nicholas Clark wrote: On Mon, Jan 07, 2008 at 03:59:18PM +, Adrian Howard wrote: Actually, I've had some nasty bugs in the past with prints failing with dodgy NFS mounts. Caused some important data to go away. Not my code fortunately :-) In these circumstances p

Re: Testing print failures

2008-01-07 Thread Nicholas Clark
On Mon, Jan 07, 2008 at 03:59:18PM +, Adrian Howard wrote: > Actually, I've had some nasty bugs in the past with prints failing > with dodgy NFS mounts. Caused some important data to go away. Not my > code fortunately :-) In these circumstances print failed but the close on the file did n

Re: Testing print failures

2008-01-07 Thread Nicholas Clark
On Mon, Jan 07, 2008 at 04:19:17PM +, David Cantrell wrote: > On Sat, Jan 05, 2008 at 10:24:47PM +, Nicholas Clark wrote: > > > Not tested, but, can you > > > > 1: grab the address of print's op from PL_ppaddr > > 2: store it somewhere useful > > 3: replace it in PL_ppaddr with your own f

Re: Testing print failures

2008-01-07 Thread David Cantrell
On Sat, Jan 05, 2008 at 10:24:47PM +, Nicholas Clark wrote: > Not tested, but, can you > > 1: grab the address of print's op from PL_ppaddr > 2: store it somewhere useful > 3: replace it in PL_ppaddr with your own function > > Your own function calls the original, and then before returning,

Re: Testing print failures

2008-01-07 Thread Adrian Howard
On 6 Jan 2008, at 11:10, Michael G Schwern wrote: [snip] But it gets down even further. All tests are not equal. Good tests are not about making perlcritic happy or achieving 100% test coverage or satisfying some conviction about testing first. [snip] Absolute 100% agreement from me. I'v

Re: Testing print failures

2008-01-06 Thread Chris Dolan
On Jan 6, 2008, at 5:10 AM, Michael G Schwern wrote: nadim khemir wrote: As for the layers of neurosis, the only anxiety is the one created by your own delusions. I see only a test like an other. If we had infinite time and attention, yes. But we don't. And time spent checking the retur

Re: Testing print failures

2008-01-06 Thread Michael G Schwern
nadim khemir wrote: > As for the layers of neurosis, the only anxiety is the one created by your > own > delusions. I see only a test like an other. If we had infinite time and attention, yes. But we don't. And time spent checking the return value of print and writing a complicated test for if

Re: Testing print failures

2008-01-05 Thread chromatic
On Saturday 05 January 2008 14:00:41 nadim khemir wrote: > Do you happend to know something about > replacing 'print' with XS code short of patching perl (which doesn't sound > like a good idea) Sure, swap the pp_print function pointer in the opcode array before you compile the code you wish to

Re: Testing print failures

2008-01-05 Thread Eric Wilhelm
# from Nicholas Clark # on Saturday 05 January 2008 14:24: >Not tested, but, can you > >1: grab the address of print's op from PL_ppaddr >2: store it somewhere useful >3: replace it in PL_ppaddr with your own function That would be cool. >Your own function calls the original, and then before ret

Re: Testing print failures

2008-01-05 Thread Nicholas Clark
On Sat, Jan 05, 2008 at 11:00:41PM +0100, nadim khemir wrote: > day an the answer was 'no'. Do you happend to know something about > replacing 'print' with XS code short of patching perl (which doesn't sound > like a good idea) Not tested, but, can you 1: grab the address of print's op from PL

Re: Testing print failures

2008-01-05 Thread nadim khemir
On Saturday 05 January 2008 20.21.59 Eric Wilhelm wrote: > Even if it weren't a system handle, in what situation does print() > return false? > > 1. Closed handle > 2. Unopened handle > 3. Disk full > > Unless I've missed one, you don't need to check the return value of > print. > > I will

Re: Testing print failures

2008-01-05 Thread nadim khemir
On Saturday 05 January 2008 15.08.55 Michael G Schwern wrote: > nadim khemir wrote: > > print 'hi' or carp q{can't print!} ; > > I'm not even going to wade into the layers of neurosis demonstrated in this > post, but if you want to throw an error use croak(). No more testing at 3 AM for me of cour

Re: Testing print failures

2008-01-05 Thread Eric Wilhelm
# from nadim khemir # on Saturday 05 January 2008 03:53: >print 'hello' ; > >triggers the wrath of InputOutput::RequireCheckedSyscalls with the >message "Return value of flagged function ignored". > >... > >There is no chance that P::C could know I'm writting on a system > handle that woul

Re: Testing print failures

2008-01-05 Thread Michael G Schwern
nadim khemir wrote: > print 'hi' or carp q{can't print!} ; I'm not even going to wade into the layers of neurosis demonstrated in this post, but if you want to throw an error use croak(). -- ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up a

Re: Testing print failures

2008-01-05 Thread Paul Johnson
On Sat, Jan 05, 2008 at 12:53:35PM +0100, nadim khemir wrote: > Next problem is coverage. Nothing upsets me more than a 99.8% coverage. I'd > almost prefere a 80% coverage to 99.8%. > > So I tried to test that case with > > { > use IO::File; > my $current_fh = select ; > >

Testing print failures

2008-01-05 Thread nadim khemir
With the advent of intensive coverage tests and zealous Perl::Critic policies, testing even simple things is getting messy. even a moundain: print 'hello' ; triggers the wrath of InputOutput::RequireCheckedSyscalls with the message "Return value of flagged function ignored". This is