Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin, On Monday 25 June 2007 23:31:25 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. Probably because my PCs CPU speed has gone from 2 to 2.2 Mhz in the last years, while the memory increased from 1 to 2 Gb, and this only because I thought 3 or 4 Gb are overkill when my system with basically everything I have open never takes more than 600 meg gig, anyway. I have plenty memory to burn, but no CPU. And the recent shrinking of structs by some Nicholas guy will also help with the memory consumption. For embedded systems using as little memory is of course always desirable, but in the only case I had this problem, I just considered replacing the 12 Megabyte consuming Perl script with 1 megabyte consuming C program - and not slimming down the Perl script until it only takes 10 megabyte. (because that would have probably even more work than just to rewrite it in C :) So, yes, it wasn't a problem I had energy to solve :) All the best, Tels - -- Signed on Mon Jun 25 23:35:11 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email. "helft den armen vögeln" -- gegen kleinschreibung -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBRoA2IncLPEOTuEwVAQKNOgf+OERJBMY3C9hDRfU3qDEpV/0xfyBWMRun aUWMQXwBKijAVUdl0ohQeBM+brDFJA2t0LAcBPVEsilbJHv2GhJQuJNcomq1OoFR Pi8KDycKmLAqCzjUHotvFqKnhTubzOlg0UwWYmMRglU8pjGGEJU6OXntFX1D6Ggc FPrvvmqgvPEvHfQRYDSluBT1aZa1gyoIaeAKvuqmZKyE0Y8eLaquD1aO0p2h1NR4 9pEf1dH2ZBemYFJJ10yqyxnXMvyrs5stsyec+K5p2lLl0j5/AcEehbN+gF7oPnzA vFF3j2jQeLx2cvgMD+5UOHHyBVMqn8V1eRm7i0aj8K79wPkEll6chA== =P+ch -END PGP SIGNATURE-
Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
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. Nicholas Clark
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 [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>From: Peter Scott [mailto:[EMAIL PROTECTED]
>Sent: 22 June 2007 13:25
>To: [EMAIL PROTECTED]; dbi-users@perl.org
>Subject: Re: perl pad.c Assertion !((sv)->sv_flags & 0x0001) 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 <[EMAIL PROTECTED]> 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
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 6/22/07, Peter Scott <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
cheers
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
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 <[EMAIL PROTECTED]> 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
On 21/06/07, Steve Hay <[EMAIL PROTECTED]> 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.
Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin, On Thursday 21 June 2007 18:59:31 Steve Hay wrote: > Tels wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Yes. But you patch just removes the "my" > > No it doesn't. Look again. Just ignore me *goes and grabs coffee* ... Tels - -- Signed on Thu Jun 21 19:00:52 2007 with key 0x93B84C15. Get one of my photo posters: http://bloodgate.com/posters PGP key on http://bloodgate.com/tels.asc or per email. "Obviously, Perl 5 has been aging, but there is no reason to bury it just yet. And we haven't. But Perl 5 will eventually succumb to the bitrot that overtakes all large projects, and we have to be ready for the transition to Perl 6 when it is time." -- Larry Wall in 'The State of the Onion' 2002 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBRnqu4ncLPEOTuEwVAQKXOQf9FAjvxxJz8R8u+o9rOETEAdynv2o+eE0S LLwB40zwaHK2i6gYz3p0bfa2cQUhLpJ3EnbG6scq0woDGRtzkS3fRVJylRYkIhdC MO9gnvM8IsX4XS0IuE//o3ijVehuxoUAfRzZ3Q0SsfqmSAl8A+FI79eeqn/L8Wx5 ym+KsMrIvDN91plrmw2lM5HUsnNxYxrpqym4m0dMvkh1Nnv/5n1uIsZ2lDo3Jhrh c99Mtdtq688E7/CwO6u93l9FWjCJY87wWdORKpjCyR1mR3BjTbggf4lxZoHEkclL uNbwAR4bMehXFhr7jaZRQdRw/FnhTOYf+4Ku++mDUM9cWBL0tagnAg== =eRNj -END PGP SIGNATURE-
Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
-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 & 0x0001) 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" 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/GNH8mmAq5 +zlzE35ueQRXgL5gQI07AehPS8HMBRQmkCe6NcgViygl37+nsm2Igu24k2cbXxqm iVt4iEITNLxig/naFAnm3HyxLqdonE3UNQ4F8FsSYvwHskN8JMRZDOO7hKu2o7oE yt3ORevWhtiZ5m6O6yY/tA6w2NccaGP4KtjaqjXlRa1RQNxBNo0GuMJRE/GMQaPU qSj/uEtMLJqTYU+TgGXXV3Uj7jKCru3GtlxqocoMDOpHutFEI/whtVs2dJIL7NKa /WrV2I1EwCGMHQThz2Rxeff8ZCghlw3gNvo/I2Lw5utwPGOzQ+IbAA== =Fxrs -END PGP SIGNATURE-
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, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote: > On 21/06/07, Steve Hay <[EMAIL PROTECTED]> 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
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 & 0x0001) 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/GNH8mmAq5 +zlzE35ueQRXgL5gQI07AehPS8HMBRQmkCe6NcgViygl37+nsm2Igu24k2cbXxqm iVt4iEITNLxig/naFAnm3HyxLqdonE3UNQ4F8FsSYvwHskN8JMRZDOO7hKu2o7oE yt3ORevWhtiZ5m6O6yY/tA6w2NccaGP4KtjaqjXlRa1RQNxBNo0GuMJRE/GMQaPU qSj/uEtMLJqTYU+TgGXXV3Uj7jKCru3GtlxqocoMDOpHutFEI/whtVs2dJIL7NKa /WrV2I1EwCGMHQThz2Rxeff8ZCghlw3gNvo/I2Lw5utwPGOzQ+IbAA== =Fxrs -END PGP SIGNATURE- --
Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
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 & 0x0001) 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?
--
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.0
+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) = @_;
