On Mon Nov 28 02:23:04 2011, nicholas wrote: > On Thu Nov 24 07:04:45 2011, dk@tetsuo.karasik.eu.org wrote: > > ----------------------------------------------------------------- > > [Please describe your issue here] > > > > perl 5.14 shows behavior not present in 5.12. I've used that behavior > > for > > conditional debugging. > > > > $ cat a.pl > > use strict; > > use warnings; > > > > my $debug = 0; > > > > sub foo > > { > > my $bar = 0 if $debug; > > return sub { $bar++ if $debug }; > > } > > > > foo(); > > > > $ perl a.pl > > Variable "$bar" is not available at a.pl line 9. > > Assuming from your test program that your intent is to be able to > generate closures at runtime with optional debugging information, a > small variation of your test program shows that in the general case your > approach will *also* warn on 5.12: > > $ cat 104504.pl > use strict; > use warnings; > > my $debug; > > sub foo > { > warn "\$debug = $debug"; > my $bar = 0 if $debug; > return sub { $bar++ if $debug }; > } > > foreach (@ARGV) { > $debug = $_; > foo(); > } > > __END__ > > $ ~/Sandpit/5120/bin/perl 104504.pl 0 1 0 1 0 1 > $debug = 0 at 104504.pl line 8. > $debug = 1 at 104504.pl line 8. > $debug = 0 at 104504.pl line 8. > Variable "$bar" is not available at 104504.pl line 10. > $debug = 1 at 104504.pl line 8. > $debug = 0 at 104504.pl line 8. > Variable "$bar" is not available at 104504.pl line 10. > $debug = 1 at 104504.pl line 8. > $ ~/Sandpit/5140/bin/perl 104504.pl 0 1 0 1 0 1 > $debug = 0 at 104504.pl line 8. > Variable "$bar" is not available at 104504.pl line 10. > $debug = 1 at 104504.pl line 8. > $debug = 0 at 104504.pl line 8. > Variable "$bar" is not available at 104504.pl line 10. > $debug = 1 at 104504.pl line 8. > $debug = 0 at 104504.pl line 8. > Variable "$bar" is not available at 104504.pl line 10. > $debug = 1 at 104504.pl line 8. > > You only avoid seeing warnings on 5.12 if you only ever call your > routine with $debug unchanged as zero. > > Given that the general case version of your routine will warn, I assume > that this is what your are doing. > > In which case, change my $debug = 0; to use constant DEBUG => 0; which > won't want, and will actually generate better code. > > Alternatively, rewrite you routine as > > sub foo > { > my $bar = 0; > return sub { $bar++ if $debug }; > } > > > ie remove the trailing conditional from the my statement. > > > IIRC the change in visible behaviour for the *first* calls to a > subroutine is a side effect of an internal refactoring, intended to > reduce the amount of storage pre-allocated in pads. For the record: adf8f095c5881bcedf07b8e41072f8125e00b5a6 is the first bad commit commit adf8f095c5881bcedf07b8e41072f8125e00b5a6 Author: Nicholas Clark <nick@ccl4.org> Date: Fri Feb 26 09:18:44 2010 +0000 Set PADSTALE on all lexicals at the end of sub creation. The PADSTALEness of lexicals between the 0th and 1st call to a subroutine is now consistent with the state between the nth and (n + 1)th call. This permits a work around in Perl_padlist_dup() to avoid leaking active pad data into a new thread, whilst still correctly bodging the external references needed by the current ?{} implementation. Fix that, and this can be removed. :100644 100644 cc2ade250e1c91cac2d5cca8e3dfdfdc3fab4ca5 8015154bf3041f4288bc881c39ae98eecd93e568 M pad.c :040000 040000 7af0e765a69f9b8942f86515956ea59024d0fb5f 611c812667cce814b844658b5146a74523465066 M t bisect run success That took 343 seconds, believe it or not. -- Father ChrysostomosThread Previous | Thread Next