Skip Menu |
 

This queue is for tickets about the Log-Dispatch-File-Stamped CPAN distribution.

Report information
The Basics
Id: 111292
Status: resolved
Priority: 0/
Queue: Log-Dispatch-File-Stamped

People
Owner: ether [...] cpan.org
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.16



Subject: change in behaviour in close-after-write
Download (untitled) / with headers
text/plain 230b
I haven't yet looked into it, but Log-Dispatch-File-Stamped now fails tests, on Log::Dispatch 2.54 (they passed on 2.51). Here is a sample failure report: http://www.cpantesters.org/cpan/report/82ba61ec-bd34-11e5-b7c8-1f10d1f53b11
Download (untitled) / with headers
text/plain 586b
On Tue Jan 19 17:59:27 2016, ETHER wrote: Show quoted text
> I haven't yet looked into it, but Log-Dispatch-File-Stamped now fails > tests, on Log::Dispatch 2.54 (they passed on 2.51). Here is a sample > failure report: http://www.cpantesters.org/cpan/report/82ba61ec-bd34- > 11e5-b7c8-1f10d1f53b11
I took a look at the test in question. It's testing the object internals rather than testing the effects of a the close_after_write option. The internals in questions are entirely in the parent class, so this doesn't really seem justified. I think this should be fixed in LD::File::Stamped's test code.
Download (untitled) / with headers
text/plain 881b
On 2016-01-20 12:40:43, DROLSKY wrote: Show quoted text
> On Tue Jan 19 17:59:27 2016, ETHER wrote:
> > I haven't yet looked into it, but Log-Dispatch-File-Stamped now fails > > tests, on Log::Dispatch 2.54 (they passed on 2.51). Here is a sample > > failure report: http://www.cpantesters.org/cpan/report/82ba61ec-bd34- > > 11e5-b7c8-1f10d1f53b11
> > > I took a look at the test in question. It's testing the object > internals rather than testing the effects of a the close_after_write > option. The internals in questions are entirely in the parent class, > so this doesn't really seem justified. I think this should be fixed in > LD::File::Stamped's test code.
Ok. I'll look for a way of verifying that the handle changes when close_after_write is set. Since undef == undef, I should be able to just pass the test if the fh comes back as undefined (since it must be recreated in that case).
The tests are fixed in version 0.16.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.