Skip Menu |

This queue is for tickets about the Test-Weaken CPAN distribution.

Report information
The Basics
Id: 43068
Status: resolved
Priority: 0/
Queue: Test-Weaken

People
Owner: jkegl [...] cpan.org
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.003_003



Subject: code refs in 1.003_001
Date: Fri, 06 Feb 2009 10:35:17 +1100
To: bug-Test-Weaken [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
In Test::Weaken 1.003_001 the program use strict; use warnings; use Test::Weaken; sub foo { } print scalar Test::Weaken::poof (sub { return [ \&foo ] }), "\n"; prints 1 ref unfreed, where in 1.002 it printed 0. Are code refs still unchecked, or meant to be? (It'd be no bad thing to check for unfreed anonymous subs, though global subs like this of course persist. I don't know if it's feasible to tell the difference.)
Subject: Re: [rt.cpan.org #43068] code refs in 1.003_001
Date: Fri, 06 Feb 2009 17:57:23 -0800
To: bug-Test-Weaken [...] rt.cpan.org
From: Jeffrey Kegler <jeffreykegler [...] mac.com>
Yes, as of 1.003_001 and 2.000000, Test::Weaken reports unfreed coderefs. As of 1.003_001 the documentation says otherwise. This is a documentation bug and will be fixed in 2.000000. Kevin Ryde via RT wrote: Show quoted text
> Are code refs still > unchecked, or meant to be? > > (It'd be no bad thing to check for unfreed anonymous subs, though global > subs like this of course persist. I don't know if it's feasible to tell > the difference.) > >
v-strings are also tracked now. I'm treating this as a documentation bug, and it's fixed as of the latest developer's release (1.003_002) and will be fixed in 2.000000. The documentation now has a section which spells out with care which objects are tracked and which are followed. I will probably leave this ticket open until I get 2.000000 out.
Subject: Re: [rt.cpan.org #43068] AutoReply: code refs in 1.003_001
Date: Wed, 11 Feb 2009 09:45:30 +1100
To: bug-Test-Weaken [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
You could look at making a way to filter out global funcs from the unfreed report. Or something in the tips section if there's already an easy way. In my case I've got a dialog object with a sub-object, and the dialog gives the sub-object some funcs to call-back to, those funcs being ordinary "sub foo { }" in the dialog class. You can imagine how when you're a couple of object levels deep any callback funcs become increasingly details of the implementation, ie. not something terribly easily known to the top object and its tests. I half remember something that walked all packages looking for names a coderef appeared under. Sounds a bit heavy-weight. Is there an easier way to ask if a coderef is an ordinary sub (and not redefined etc)?
On Tue Feb 10 17:46:49 2009, user42@zip.com.au wrote: Show quoted text
> You could look at making a way to filter out global funcs from the > unfreed report. Or something in the tips section if there's already an > easy way.
I suppose I could do something like look for the coderef in the symbol table, on the idea that anything is the symbol table is global. [That ignores the issue of coderefs declared with local() ]. This takes me a bit far afield, however, and I think I'll focus on providing a callback that allows the user to do his own filtering. I'm going to treat this as a "side conversation" as far as this bug goes.
I've released 1.003_003 which contains careful documentation of how various types of objects are handled by Test::Weaken. I haven't released an user's version with the improved documentation yet, but I've got another ticket to keep my feet to the fire on releasing 2.000000, so I will close this bug as resolved. Your input is contributing much to improving Test::Weaken. Thanks.
Resolved with documentation fix as of 1.003_003 and 2.000000.