ANNOUNCE: DBI 1.57

file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
size: 490304 bytes
md5: fca667f59dff24058a8e0e8f09e2aad9

=head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007

Note: this release includes a change to the DBI::hash() function which will
now produce different values than before *if* your perl was built with 64-bit
'int' type (i.e. "perl -V:intsize" says intsize='4'). It's relatively rare
for perl to be configured that way, even on 64-bit systems.

Fixed XS versions of select*_*() methods to call execute()
fetch() etc., with inner handle instead of outer.
Fixed execute_for_fetch() to not cache errstr values
thanks to Bart Degryse.
Fixed unused var compiler warning thanks to JDHEDDEN.
Fixed t/86gofer_fail tests to be less likely to fail falsely.

Changed DBI::hash to return 'I32' type instead of 'int' so results are
portable/consistent regardless of size of the int type.
Corrected timeout example in docs thanks to Egmont Koblinger.
Changed t/01basic.t to warn instead of failing when it detects
a problem with Math::BigInt (some recent versions had problems).

Added support for !Time and !Time~N to DBI::Profile Path. See docs.
Added extra trace info to connect_cached thanks to Walery Studennikov.
Added non-random (deterministic) mode to DBI_GOFER_RANDOM mechanism.
Added DBIXS_REVISION macro that drivers can use.
Added more docs for private_attribute_info() method.

DBI::Profile changes:
dbi_profile() now returns ref to relevant leaf node.
Don't profile DESTROY during global destruction.
Added as_node_path_list() and as_text() methods.
DBI::ProfileDumper changes:
Don't write file if there's no profile data.
Uses full natural precision when saving data (was using %.6f)
Optimized flush_to_disk().
Locks the data file while writing.
Enabled filename to be a code ref for dynamic names.
DBI::ProfileDumper::Apache changes:
Added Quiet=>1 to avoid write to STDERR in flush_to_disk().
Added Dir=>... to specify a writable destination directory.
Enabled DBI_PROFILE_APACHE_LOG_DIR for mod_perl 1 as well as 2.
Added parent pid to default data file name.
DBI::ProfileData changes:
Added DeleteFiles option to rename & delete files once read.
Locks the data files while reading.
Added ability to sort by Path elements.
dbiprof changes:
Added --dumpnodes and --delete options.
Added/updated docs for both DBI::ProfileDumper && ::Apache.

=cut

You can see the primary focus of my recent developments for Shopzilla
have been around profiling. Specifically using the DBI's profiling
mechanisms to implement lightweight always-on application-level profiling.

Enjoy!

Tim.

p.s. I've a new module, called DashProfiler, that provides a simple,
flexible, efficient way to add performance monitoring to an application,
especially web applications. It's trivial to track the time spent inside
specific blocks of code, or the lifespan of specific objects.

(It happens to use DBI handles internally to store profile data but is
unrelated to databases. A working version, but with almost no docs, is
on CPAN. I'll announce the documented version when I release it but I
won't be using the dbi mailing lists for DashProfiler in future.)

Re: ANNOUNCE: DBI 1.57

On Tue, 19 Jun 2007 21:11:23 +0100, Tim Bunce wrote:

> file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
> size: 490304 bytes
> md5: fca667f59dff24058a8e0e8f09e2aad9
>
> =head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007
>
> Note: this release includes a change to the DBI::hash() function which will
> now produce different values than before *if* your perl was built with 64-bit
> 'int' type (i.e. "perl -V:intsize" says intsize='4'). It's relatively rare

Huh?

32bitall:

a5:/u/usr/merijn 101 > perl -V:intsize
intsize='4';
a5:/u/usr/merijn 102 > perl -V:use64bitint
use64bitint='undef';
a5:/u/usr/merijn 103 >

64bitint:

nb09:/home/merijn 101 > perl -V:intsize
intsize='4';
nb09:/home/merijn 102 > perl -V:use64bitint
use64bitint='define';
nb09:/home/merijn 103 >

64bitall:

x1:/u/usr/merijn 101 > perl -V:intsize
intsize='4';
x1:/u/usr/merijn 102 > perl -V:use64bitall
use64bitall='define';
x1:/u/usr/merijn 103 > perl -V:use64bitint
use64bitint='define';
x1:/u/usr/merijn 104 >

So, relatively rare sounds very weird to me.

> for perl to be configured that way, even on 64-bit systems.
>
> Fixed XS versions of select*_*() methods to call execute()
> fetch() etc., with inner handle instead of outer.
> Fixed execute_for_fetch() to not cache errstr values
> thanks to Bart Degryse.
> Fixed unused var compiler warning thanks to JDHEDDEN.
> Fixed t/86gofer_fail tests to be less likely to fail falsely.
>
> Changed DBI::hash to return 'I32' type instead of 'int' so results are
> portable/consistent regardless of size of the int type.

Shouldn't that be IV

> Corrected timeout example in docs thanks to Egmont Koblinger.
> Changed t/01basic.t to warn instead of failing when it detects
> a problem with Math::BigInt (some recent versions had problems).
>
> Added support for !Time and !Time~N to DBI::Profile Path. See docs.
> Added extra trace info to connect_cached thanks to Walery Studennikov.
> Added non-random (deterministic) mode to DBI_GOFER_RANDOM mechanism.
> Added DBIXS_REVISION macro that drivers can use.
> Added more docs for private_attribute_info() method.
>
> DBI::Profile changes:
> dbi_profile() now returns ref to relevant leaf node.
> Don't profile DESTROY during global destruction.
> Added as_node_path_list() and as_text() methods.
> DBI::ProfileDumper changes:
> Don't write file if there's no profile data.
> Uses full natural precision when saving data (was using %.6f)
> Optimized flush_to_disk().
> Locks the data file while writing.
> Enabled filename to be a code ref for dynamic names.
> DBI::ProfileDumper::Apache changes:
> Added Quiet=>1 to avoid write to STDERR in flush_to_disk().
> Added Dir=>... to specify a writable destination directory.
> Enabled DBI_PROFILE_APACHE_LOG_DIR for mod_perl 1 as well as 2.
> Added parent pid to default data file name.
> DBI::ProfileData changes:
> Added DeleteFiles option to rename & delete files once read.
> Locks the data files while reading.
> Added ability to sort by Path elements.
> dbiprof changes:
> Added --dumpnodes and --delete options.
> Added/updated docs for both DBI::ProfileDumper && ::Apache.
>
> =cut
>
> You can see the primary focus of my recent developments for Shopzilla
> have been around profiling. Specifically using the DBI's profiling
> mechanisms to implement lightweight always-on application-level profiling.
>
> Enjoy!
>
> Tim.
>
> p.s. I've a new module, called DashProfiler, that provides a simple,
> flexible, efficient way to add performance monitoring to an application,
> especially web applications. It's trivial to track the time spent inside
> specific blocks of code, or the lifespan of specific objects.
>
> (It happens to use DBI handles internally to store profile data but is
> unrelated to databases. A working version, but with almost no docs, is
> on CPAN. I'll announce the documented version when I release it but I
> won't be using the dbi mailing lists for DashProfiler in future.)
>


--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/

Re: ANNOUNCE: DBI 1.57

Tim Bunce wrote:
> file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
> size: 490304 bytes
> md5: fca667f59dff24058a8e0e8f09e2aad9
>
> =head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007
>
> Fixed t/86gofer_fail tests to be less likely to fail falsely.

t/86gofer_fail.t now fails with my build of bleadperl (patchlevel 31376)
with VC++ 6.0 on Win32 (perl -V below). This script was passing OK in
DBI-1.56 with the same perl.

C:\Temp\DBI-1.57>perl -Mblib t\86gofer_fail.t
ok 1 - should fail 100% of the time
ok 2 - $@ should be set
ok 3
ok 4 - errstr should be set
ok 5 - errstr should contain DBI_GOFER_RANDOM
ok 6 - go_response executed flag should be false
target approx 50% random failures, got 48.5%
ok 7 - should fail about 50% of the time, but at least between 10% and
90% (got 48.5)
ok 8 - should fail about 50% of the time, but at least between 10% and
90% (got 48.5)
target less than 20% effective random failures (ideally 0), got 0%
ok 9 - should fail < 20%
ok 10 - should fail < 1%
ok 11
ok 12 - should fail ~25% (ie 50% with one retry) (got 22)
ok 13 - should fail ~25% (ie 50% with one retry) (got 22)
ok 14 - transport request_retry_count should be around 50 (got 44)
ok 15 - transport request_retry_count should be around 50 (got 44)
ok 16
ok 17 - should fail ~50%, ie no retries (got 50)
ok 18 - should fail ~50%, ie no retries (got 50)
ok 19 - transport request_retry_count should be zero or undef
ok 20 - positive percentage should fail randomly
ok 21 - negative percentage should fail non-randomly
Testing random delay
ok 22
Unexpected failure: DBD::Gofer::db do failed: Assertion !((sv)->sv_flags
& 0x00010000) failed: file "..\pad.c", line 1505 at
C:\Temp\DBI-1.57\blib\lib/DBI/Gofer/Execute.pm line 624. at
t\86gofer_fail.t line 129.
1..22
# Looks like your test died just after 22.

C:\Temp\DBI-1.57>perl -V
Summary of my perl5 (revision 5 version 9 subversion 5) configuration:
Platform:
osname=MSWin32, osvers=5.1, archname=MSWin32-x86-perlio
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=undef, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_DEBUGGING_MSTATS
-DUSE_PERLIO -DPERL_MSVCRT_READFIX',
optimize='-Od -MD -Zi -DDEBUGGING',
cppflags='-DWIN32'
ccversion='12.00.8804', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug
-libpath:"C:\perl5\lib\CORE" -machine:x86'
libpth="C:\Program Files\Microsoft Visual Studio\VC98\lib"
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl59.lib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-libpath:"C:\perl5\lib\CORE" -machine:x86'


Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MYMALLOC PERL_DONT_CREATE_GVSV
PERL_MALLOC_WRAP USE_PERLIO
Locally applied patches:
DEVEL
Built under MSWin32
Compiled at Jun 14 2007 09:20:24
@INC:
C:/perl5/lib
C:/perl5/site/lib
.

--

Re: ANNOUNCE: DBI 1.57

On Wed, Jun 20, 2007 at 06:20:22AM +0000, H.Merijn Brand wrote:
> On Tue, 19 Jun 2007 21:11:23 +0100, Tim Bunce wrote:
>
> > file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
> > size: 490304 bytes
> > md5: fca667f59dff24058a8e0e8f09e2aad9
> >
> > =head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007
> >
> > Note: this release includes a change to the DBI::hash() function which will
> > now produce different values than before *if* your perl was built with 64-bit
> > 'int' type (i.e. "perl -V:intsize" says intsize='4'). It's relatively rare
>
> Huh?
>
> 32bitall:
>
> a5:/u/usr/merijn 101 > perl -V:intsize
> intsize='4';
> a5:/u/usr/merijn 102 > perl -V:use64bitint
> use64bitint='undef';
>
> 64bitint:
>
> nb09:/home/merijn 101 > perl -V:intsize
> intsize='4';
> nb09:/home/merijn 102 > perl -V:use64bitint
> use64bitint='define';
>
> 64bitall:
>
> x1:/u/usr/merijn 101 > perl -V:intsize
> intsize='4';
> x1:/u/usr/merijn 102 > perl -V:use64bitall
> use64bitall='define';
> x1:/u/usr/merijn 103 > perl -V:use64bitint
> use64bitint='define';
>
> So, relatively rare sounds very weird to me.

Sorry, I meant "i.e. "perl -V:intsize" says intsize='8'"
which none of those do[1].

I'll update the Changes file. Thanks!

> > Changed DBI::hash to return 'I32' type instead of 'int' so results are
> > portable/consistent regardless of size of the int type.
>
> Shouldn't that be IV

No, for the hash function I specifically want 32 bits to ensure the same
value is returned regardless of the size of the int or IV types.

Tim.

[1] http://search.cpan.org/~nwclark/perl-5.8.8/INSTALL#64_bit_su pport.

perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed (was: ANNOUNCE: DBI 1.57)

On Wed, Jun 20, 2007 at 08:47:53AM +0100, Steve Hay wrote:
> Tim Bunce wrote:
> > file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
> > size: 490304 bytes
> > md5: fca667f59dff24058a8e0e8f09e2aad9
> >
> >=head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007
> >
> > Fixed t/86gofer_fail tests to be less likely to fail falsely.
>
> t/86gofer_fail.t now fails with my build of bleadperl (patchlevel 31376)
> with VC++ 6.0 on Win32 (perl -V below). This script was passing OK in
> DBI-1.56 with the same perl.
>
> C:\Temp\DBI-1.57>perl -Mblib t\86gofer_fail.t
> ok 21 - negative percentage should fail non-randomly
> Testing random delay
> ok 22
> Unexpected failure: DBD::Gofer::db do failed: Assertion !((sv)->sv_flags & 0x00010000) failed: file "..\pad.c", line 1505 at
> C:\Temp\DBI-1.57\blib\lib/DBI/Gofer/Execute.pm line 624. at t\86gofer_fail.t line 129.

Execute.pm line 624 is returning a closure, but it doesn't seem
particularly magical.

Not sure when I'll be able to dig deeper. CC'd to perl5-porters in the
hope they can help narrow it down.

Tim.

> 1..22
> # Looks like your test died just after 22.
>
> C:\Temp\DBI-1.57>perl -V
> Summary of my perl5 (revision 5 version 9 subversion 5) configuration:
> Platform:
> osname=MSWin32, osvers=5.1, archname=MSWin32-x86-perlio
> uname=''
> config_args='undef'
> hint=recommended, useposix=true, d_sigaction=undef
> useithreads=undef, usemultiplicity=undef
> useperlio=define, d_sfio=undef, uselargefiles=undef, usesocks=undef
> use64bitint=undef, use64bitall=undef, uselongdouble=undef
> usemymalloc=y, bincompat5005=undef
> Compiler:
> cc='cl', ccflags ='-nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32
> -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_DEBUGGING_MSTATS
> -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
> optimize='-Od -MD -Zi -DDEBUGGING',
> cppflags='-DWIN32'
> ccversion='12.00.8804', gccversion='', gccosandvers=''
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=4
> alignbytes=8, prototype=define
> Linker and Libraries:
> ld='link', ldflags ='-nologo -nodefaultlib -debug
> -libpath:"C:\perl5\lib\CORE" -machine:x86'
> libpth="C:\Program Files\Microsoft Visual Studio\VC98\lib"
> libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
> comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
> netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
> odbc32.lib odbccp32.lib msvcrt.lib
> perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
> winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
> oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
> version.lib odbc32.lib odbccp32.lib msvcrt.lib
> libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl59.lib
> gnulibc_version=''
> Dynamic Linking:
> dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
> cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
> -libpath:"C:\perl5\lib\CORE" -machine:x86'
>
>
> Characteristics of this binary (from libperl):
> Compile-time options: DEBUGGING MYMALLOC PERL_DONT_CREATE_GVSV
> PERL_MALLOC_WRAP USE_PERLIO
> Locally applied patches:
> DEVEL
> Built under MSWin32
> Compiled at Jun 14 2007 09:20:24
> @INC:
> C:/perl5/lib
> C:/perl5/site/lib
> .
>
> --

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

--------------050300030505050901050504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tim Bunce wrote:
> On Wed, Jun 20, 2007 at 08:47:53AM +0100, Steve Hay wrote:
>> Tim Bunce wrote:
>>> file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
>>> size: 490304 bytes
>>> md5: fca667f59dff24058a8e0e8f09e2aad9
>>>
>>> =head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007
>>>
>>> Fixed t/86gofer_fail tests to be less likely to fail falsely.
>> t/86gofer_fail.t now fails with my build of bleadperl (patchlevel 31376)
>> with VC++ 6.0 on Win32 (perl -V below). This script was passing OK in
>> DBI-1.56 with the same perl.
>>
>> C:\Temp\DBI-1.57>perl -Mblib t\86gofer_fail.t
>> ok 21 - negative percentage should fail non-randomly
>> Testing random delay
>> ok 22
>> Unexpected failure: DBD::Gofer::db do failed: Assertion !((sv)->sv_flags & 0x00010000) failed: file "..\pad.c", line 1505 at
>> C:\Temp\DBI-1.57\blib\lib/DBI/Gofer/Execute.pm line 624. at t\86gofer_fail.t line 129.
>
> Execute.pm line 624 is returning a closure, but it doesn't seem
> particularly magical.
>
> Not sure when I'll be able to dig deeper. CC'd to perl5-porters in the
> hope they can help narrow it down.

With the attached patch I now have all tests successful.

I remember lots of discussion a while ago about constructions like "my
$x = 1 if $y;". I don't remember what the conclusion of it all was,
except that it's probably best avoided. Is that right?

--

--------------050300030505050901050504
Content-Type: text/plain;
name="dbi.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="dbi.patch"

diff -ruN DBI-1.57.orig/lib/DBI/Gofer/Execute.pm DBI-1.57/lib/DBI/Gofer/Execute.pm
--- DBI-1.57.orig/lib/DBI/Gofer/Execute.pm 2007-06-07 17:46:12.000000000 +0100
+++ DBI-1.57/lib/DBI/Gofer/Execute.pm 2007-06-21 17:36:24.722390400 +0100
@@ -596,8 +596,9 @@

sub _mk_rand_callback {
my ($self, $method, $fail_percent, $delay_percent, $delay_duration) = @_;
- $fail_percent ||= 0; my $fail_modrate = int(1/(-$fail_percent )*100) if $fail_percent;
- $delay_percent ||= 0; my $delay_modrate = int(1/(-$delay_percent)*100) if $delay_percent;
+ my ($fail_modrate, $delay_modrate);
+ $fail_percent ||= 0; $fail_modrate = int(1/(-$fail_percent )*100) if $fail_percent;
+ $delay_percent ||= 0; $delay_modrate = int(1/(-$delay_percent)*100) if $delay_percent;
# note that $method may be "*"
return sub {
my ($h) = @_;

--------------050300030505050901050504--

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

Tels wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Moin,
>
> On Thursday 21 June 2007 18:44:22 Steve Hay wrote:
>> Tim Bunce wrote:
>>> On Wed, Jun 20, 2007 at 08:47:53AM +0100, Steve Hay wrote:
>>>> Tim Bunce wrote:
>>>>> file: $CPAN/authors/id/T/TI/TIMB/DBI-1.57.tar.gz
>>>>> size: 490304 bytes
>>>>> md5: fca667f59dff24058a8e0e8f09e2aad9
>>>>>
>>>>> =head2 Changes in DBI 1.57 (svn rev 9639), 13th June 2007
>>>>>
>>>>> Fixed t/86gofer_fail tests to be less likely to fail falsely.
>>>> t/86gofer_fail.t now fails with my build of bleadperl (patchlevel
>>>> 31376) with VC++ 6.0 on Win32 (perl -V below). This script was passing
>>>> OK in DBI-1.56 with the same perl.
>>>>
>>>> C:\Temp\DBI-1.57>perl -Mblib t\86gofer_fail.t
>>>> ok 21 - negative percentage should fail non-randomly
>>>> Testing random delay
>>>> ok 22
>>>> Unexpected failure: DBD::Gofer::db do failed: Assertion
>>>> !((sv)->sv_flags & 0x00010000) failed: file "..\pad.c", line 1505 at
>>>> C:\Temp\DBI-1.57\blib\lib/DBI/Gofer/Execute.pm line 624. at
>>>> t\86gofer_fail.t line 129.
>>> Execute.pm line 624 is returning a closure, but it doesn't seem
>>> particularly magical.
>>>
>>> Not sure when I'll be able to dig deeper. CC'd to perl5-porters in the
>>> hope they can help narrow it down.
>> With the attached patch I now have all tests successful.
>>
>> I remember lots of discussion a while ago about constructions like "my
>> $x = 1 if $y;". I don't remember what the conclusion of it all was,
>> except that it's probably best avoided. Is that right?
>
> Yes. But you patch just removes the "my"

No it doesn't. Look again.


> which would cause problems under
> strict. It should be:
>
> my $foo; $foo = ... if ....;
>
> instead.
>
> All the best,
>
> Tels
>
>
> - --
> Signed on Thu Jun 21 18:49:21 2007 with key 0x93B84C15.
> View my photo gallery: http://bloodgate.com/photos
> PGP key on http://bloodgate.com/tels.asc or per email.
>
> "... [Apocalypse 12] ... With that, the design of Perl 6 can be said to
> be largely complete. We are now in the endgame, which is the name of
> this screensaver. Now that the Parrot engine is in such fine shape, it's
> time to concentrate on writing a fine Perl 6 compiler to target it."
>
> -- Larry Wall in 'The State of the Onion', August 19th, 2004
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iQEVAwUBRnqsSXcLPEOTuEwVAQIXQgf9EM6mqUqY1Bbab+OSwrte5f/GNH8m mAq5
> +zlzE35ueQRXgL5gQI07AehPS8HMBRQmkCe6NcgViygl37+nsm2Igu24k2cb Xxqm
> iVt4iEITNLxig/naFAnm3HyxLqdonE3UNQ4F8FsSYvwHskN8JMRZDOO7hKu2 o7oE
> yt3ORevWhtiZ5m6O6yY/tA6w2NccaGP4KtjaqjXlRa1RQNxBNo0GuMJRE/GM QaPU
> qSj/uEtMLJqTYU+TgGXXV3Uj7jKCru3GtlxqocoMDOpHutFEI/whtVs2dJIL 7NKa
> /WrV2I1EwCGMHQThz2Rxeff8ZCghlw3gNvo/I2Lw5utwPGOzQ+IbAA==
> =Fxrs
> -----END PGP SIGNATURE-----
>
>



--

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
> On 21/06/07, Steve Hay wrote:
> >With the attached patch I now have all tests successful.
> >
> >I remember lots of discussion a while ago about constructions like "my
> >$x = 1 if $y;". I don't remember what the conclusion of it all was,
> >except that it's probably best avoided. Is that right?
>
> Yes, that's right, because that could bypass initialisation of $x if
> $y is false, leaving the previous value in it, like in state vars.
>
> Note that in 5.10, you'll have a warning for a special case of this
> construct :
>
> $ bleadperl -we 'my $x if 0'
> Deprecated use of my() in false conditional at -e line 1.

I thought that issue only related to a "compile-time constant false"
(such as the one in your example) and not to a runtime expression that
happend to be false sometimes.

Looking at it another way, are you saying that (ignoring closures)
subroutine scoped lexicals are not cleared when the subroutine exits,
but persist (consuming memory) until the subroutine is reentered?

Tim.

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

On Thu, Jun 21, 2007 at 05:44:22PM +0100, Steve Hay wrote:
> Tim Bunce wrote:
> >
> >Not sure when I'll be able to dig deeper. CC'd to perl5-porters in the
> >hope they can help narrow it down.
>
> With the attached patch I now have all tests successful.

Applied. Thanks Steve!

Tim.

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
> On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
>> On 21/06/07, Steve Hay wrote:
>> >I remember lots of discussion a while ago about constructions like "my
>> >$x = 1 if $y;". I don't remember what the conclusion of it all was,
>> >except that it's probably best avoided. Is that right?
>>
>> Yes, that's right, because that could bypass initialisation of $x if
>> $y is false, leaving the previous value in it, like in state vars.
>
> I thought that issue only related to a "compile-time constant false"
> (such as the one in your example) and not to a runtime expression that
> happened to be false sometimes.
>
> Looking at it another way, are you saying that (ignoring closures)
> subroutine scoped lexicals are not cleared when the subroutine exits,
> but persist (consuming memory) until the subroutine is reentered?

$ ./perl -wle '$q = shift; sub foo { my $x if $q; print $x // $]; \
$x = 42 } foo; $q++; foo' 0
5.009005
42

It looks like it, no?

--
Peter Scott

RE: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

>From: Peter Scott [mailto:Peter@PSDT.com]=0D
>Sent: 22 June 2007 13:25
>To: perl5-porters@perl.org; dbi-users@perl.org
>Subject: Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
>
>On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
>> On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
>>> On 21/06/07, Steve Hay wrote:
>>> >I remember lots of discussion a while ago about constructions like
"my
>>> >$x =3D 1 if $y;". I don't remember what the conclusion of it all was,
>>> >except that it's probably best avoided. Is that right?
>>>=0D
>>> Yes, that's right, because that could bypass initialisation of $x if
>>> $y is false, leaving the previous value in it, like in state vars.
>>=0D
>> I thought that issue only related to a "compile-time constant false"
>> (such as the one in your example) and not to a runtime expression
that
>> happened to be false sometimes.
>>=0D
>> Looking at it another way, are you saying that (ignoring closures)
>> subroutine scoped lexicals are not cleared when the subroutine exits,
>> but persist (consuming memory) until the subroutine is reentered?
>
>$ ./perl -wle '$q =3D shift; sub foo { my $x if $q; print $x // $]; \
> $x =3D 42 } foo; $q++; foo' 0
>5.009005
>42
>
>It looks like it, no?
>
>--=0D
>Peter Scott

To be fair most of the programming languages I'm familiar with don't
guarantee the value of a variable before its first assignment so I guess
this is to be expected.
The value will likely not be held over between calls but the value will
be "unpredictable" on each invocation.

Ken.



************************************************************ ***************=
************************************************************ *************
This e-mail and any accompanying documents contain confidential information=
intended for a specific individual which is private and protected by law.
If you are not the intended recipient, any disclosure, copying,=
distribution or other use of this information is strictly prohibited.
You are also requested to advise us immediately if you receive information=
which is not addressed to you.
beCogent is Authorised and Regulated by the Financial Services=
Authority.beCogent Registered Office Address:
75 Aldwych
London
WC2B 4JF

Company Registration Number: 3742876

Place of Registration: London
************************************************************ ***************=
************************************************************ **************

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

On Fri, Jun 22, 2007 at 02:31:07PM +0200, demerphq wrote:
> On 6/22/07, Peter Scott wrote:
> >On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
> >> On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
> >>> On 21/06/07, Steve Hay wrote:
> >>> >I remember lots of discussion a while ago about constructions like "my
> >>> >$x = 1 if $y;". I don't remember what the conclusion of it all was,
> >>> >except that it's probably best avoided. Is that right?
> >>>
> >>> Yes, that's right, because that could bypass initialisation of $x if
> >>> $y is false, leaving the previous value in it, like in state vars.
> >>
> >> I thought that issue only related to a "compile-time constant false"
> >> (such as the one in your example) and not to a runtime expression that
> >> happened to be false sometimes.
> >>
> >> Looking at it another way, are you saying that (ignoring closures)
> >> subroutine scoped lexicals are not cleared when the subroutine exits,
> >> but persist (consuming memory) until the subroutine is reentered?
> >
> >$ ./perl -wle '$q = shift; sub foo { my $x if $q; print $x // $]; \
> > $x = 42 } foo; $q++; foo' 0
> >5.009005
> >42
> >
> >It looks like it, no?
>
> I didnt want to say anything right away in the hope that Dave Mitchell
> would answer it, and in the knowledge i might have something wrong,
> but I seem to recall Dave explaining once in the past that perl trys
> to optimise allocation of memory so that it doesnt have to reallocate
> buffers every time a sub is entered. So basically storage for SV's is
> preserved between invocations when possible. But i dont remember the
> details and I just might be totally ass-backwards wrong.

Once upon a time there was talk of implementing a "less" pragma
so you'd be able to say something like

use less qw(memory);

to indicate that cpu/memory balance should be shifted towards cpu.
Pity that never happened.

Tim.

Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed

On Mon, Jun 25, 2007 at 10:31:25PM +0100, Nicholas Clark wrote:
> On Mon, Jun 25, 2007 at 09:44:02PM +0100, Tim Bunce wrote:
>
> > Once upon a time there was talk of implementing a "less" pragma
> > so you'd be able to say something like
> >
> > use less qw(memory);
> >
> > to indicate that cpu/memory balance should be shifted towards cpu.
> > Pity that never happened.
>
> It's still on the todo list. It doesn't appear to have become a large enough
> itch for anyone to scratch it.

Perhaps in part because a) few people realise that a sub manipulating
large strings in lexical vars will continue to hold that memory,
and b) there's no easy way to measure the memory being held in this way.

Tim.

p.s. I've set Reply-To perl5-porters@perl.org