[31823] in Perl-Users-Digest
Perl-Users Digest, Issue: 3086 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 19 21:09:23 2010
Date: Thu, 19 Aug 2010 18:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 19 Aug 2010 Volume: 11 Number: 3086
Today's topics:
[ANN]VTD-XML 2.9 <bchang2002@gmail.com>
Re: ActivePerl Migration Win 2003 Server to Win 2008 Se sln@netherlands.com
Re: Data::Alias <uri@StemSystems.com>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <uri@StemSystems.com>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <ben@morrow.me.uk>
parsing CSV files <monkey@joemoney.net>
Re: parsing CSV files <ben@morrow.me.uk>
Re: Perl array bug? <uri@StemSystems.com>
Re: Perl array bug? <smallpond@juno.com>
Re: Perl array bug? (Malcolm Hoar)
Re: Perl array bug? (Malcolm Hoar)
Re: Perl array bug? <uri@StemSystems.com>
Re: Perl array bug? (Malcolm Hoar)
Re: Perl array bug? <uri@StemSystems.com>
Re: Perl array bug? <nospam-abuse@ilyaz.org>
Re: Perl array bug? <nospam-abuse@ilyaz.org>
Re: Perl array bug? <nospam-abuse@ilyaz.org>
Re: Perl array bug? <ben@morrow.me.uk>
Re: Smaller docs vs organized docs <nospam-abuse@ilyaz.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 19 Aug 2010 17:42:41 -0700 (PDT)
From: dontcare <bchang2002@gmail.com>
Subject: [ANN]VTD-XML 2.9
Message-Id: <8feca6d1-ef1f-47da-a090-d79b9d512467@o7g2000prg.googlegroups.com>
VTD-XML 2.9, the next generation XML Processing API for SOA and Cloud
computing, has been released. Please visit https://sourceforge.net/projects/vtd-xml/files/
to download the latest version.
* Strict Conformance
# VTD-XML now fully conforms to XML namespace 1.0 spec
* Performance Improvement
# Significantly improved parsing performance for small XML files
* Expand Core VTD-XML API
# Adds getPrefixString(), and toNormalizedString2()
* Cutting/Splitting
# Adds getSiblingElementFragment()
* A number of bug fixes and code enhancement including:
# Fixes a bug for reading very large XML documents on some
platforms
# Fixes a bug in parsing processing instruction
# Fixes a bug in outputAndReparse()
------------------------------
Date: Thu, 19 Aug 2010 11:16:26 -0700
From: sln@netherlands.com
Subject: Re: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <hsrq66t3rc0r29rf772hsjjb121jjaqtq6@4ax.com>
On Thu, 19 Aug 2010 04:01:13 -0700 (PDT), Klaus <klaus03@gmail.com> wrote:
>- Do you recommend upgrading from perl 5.10 (x64) to the newer perl
>5.12 (x64) at the same time ?
I would say absolutely not do this at the same time.
It complicates the issue.
Certify the existing production code to 2008 with
the version 5.10 that is compatable with 2008
(if there is such a thing. Which for Perl, I don't think
there is that granularity at the OS level, only 32/64 bit,
which I think is the 2003 server sdk headers/libs).
-sln
------------------------------
Date: Thu, 19 Aug 2010 15:01:40 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Data::Alias
Message-Id: <87pqxetoiz.fsf@quad.sysarch.com>
>>>>> "R" == Ruud <rvtol+usenet@xs4all.nl> writes:
R> perl -Mstrict -MData::Alias -MBenchmark=cmpthese -wle'
R> my $h;
R> alias my %alias = %{ $h->{ foo } };
R> $alias{ test }= 0;
R> my $plain= $h->{ foo };
R> cmpthese( -1, {
R> plain => sub { $plain->{ test }= 1 },
R> alias => sub { $alias{ test }= 2 },
R> });
R> '
R> Rate plain alias
R> plain 3276800/s -- -28%
R> alias 4549606/s 39% --
how often would you need to do a single level hash lookup to save here?
if i needed it so often i would copy to a scalar or make a ref to
it. again, not often so it isn't a win unless you have very odd or bad
old code.
R> (just because dereferencing has runtime costs)
and this is doing a dereference under the hood. hash lookups are a
different matter. compare alias to $ref = \$plain->{test} and
${$ref}. those should be about the same.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 19 Aug 2010 21:10:49 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6d81b9$0$22939$e4fe514c@news.xs4all.nl>
Uri Guttman wrote:
> and this is doing a dereference under the hood. hash lookups are a
> different matter. compare alias to $ref = \$plain->{test} and
> ${$ref}. those should be about the same.
You really still don't get it. But I never get tired promoting
Data::Alias, so no problem here.
Data::Alias does many things at compile time, by changing the op-tree.
No "dereference under the hood"!
Another nice (memory saving) functionality of Data::Alias:
perl -Mstrict -MData::Alias -MDevel::Size=size,total_size
-MBenchmark=cmpthese -wle'
my ( %plain, %slice, %alias );
my @keys= "aaaa" .. "zzzz";
my $VALUE= "foo";
print "keys: ", scalar @keys;
cmpthese( -1, {
slice => sub { @slice{ @keys }= ($VALUE) x @keys },
plain => sub { $plain{ $_ }= $VALUE for @keys },
alias => sub { alias $alias{ $_ }= $VALUE for @keys },
});
print "";
for ( [ plain => \%plain ], [ slice => \%slice ], [ alias => \%alias
] ) {
print sprintf qq{%s k=%s, v=%s}, $_->[0], size( $_->[1] ),
total_size( $_->[1] ) - size( $_->[1] );
}
'
keys: 456976
Rate slice alias plain
slice 3.33/s -- -13% -19%
alias 3.81/s 14% -- -8%
plain 4.13/s 24% 8% --
plain k=13978588, v=12795328
slice k=13978588, v=12795328
alias k=13978588, v=28
Try also with slice initialised to (), then make the $VALUE undef.
You'll find that slice is twice as fast, but still uses (for no good
reason) quite some memory for all the undef-SVs.
This is a nice way to implement sets, where all you need is exists().
Or any other situation where the values come in packs.
Cheers!
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 15:40:39 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Data::Alias
Message-Id: <8739uatmq0.fsf@quad.sysarch.com>
>>>>> "R" == Ruud <rvtol+usenet@xs4all.nl> writes:
R> Uri Guttman wrote:
>> and this is doing a dereference under the hood. hash lookups are a
>> different matter. compare alias to $ref = \$plain->{test} and
>> ${$ref}. those should be about the same.
R> You really still don't get it. But I never get tired promoting
R> Data::Alias, so no problem here.
R> Data::Alias does many things at compile time, by changing the op-tree.
R> No "dereference under the hood"!
ok, i didn't know about its guts. but the fact that it messes with
perl's guts scares me too. as someone pointed out it broke under a newer
perl. that is not the kind of module i want to depend upon.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 19 Aug 2010 22:19:49 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6d91e5$0$22913$e4fe514c@news.xs4all.nl>
Uri Guttman wrote:
> <rvtol+usenet@xs4all.nl> writes:
>> Uri Guttman wrote:
>>> and this is doing a dereference under the hood. hash lookups are a
>>> different matter. compare alias to $ref = \$plain->{test} and
>>> ${$ref}. those should be about the same.
>>
>> You really still don't get it. But I never get tired promoting
>> Data::Alias, so no problem here.
>>
>> Data::Alias does many things at compile time, by changing the op-tree.
>> No "dereference under the hood"!
>
> ok, i didn't know about its guts. but the fact that it messes with
> perl's guts scares me too. as someone pointed out it broke under a newer
> perl. that is not the kind of module i want to depend upon.
Well, don't get too afraid of op-tree manipulations yet, because there
is a whole new set of tools coming to do just that, though in a better,
more controllable and sustainable way, and even in Perl (compare
Devel::Declare).
That is also more or less the way that Data::Alias should get fixed.
It needed to be fixed after multiple Perl releases, and because it isn't
in core, that is lagging.
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 23:43:35 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6da588$0$22913$e4fe514c@news.xs4all.nl>
Dr.Ruud wrote:
> Another nice (memory saving) functionality of Data::Alias:
>
> perl -Mstrict -MData::Alias -MDevel::Size=size,total_size
> -MBenchmark=cmpthese -wle'
> my ( %plain, %slice, %alias );
> my @keys= "aaaa" .. "zzzz";
> my $VALUE= "foo";
>
> print "keys: ", scalar @keys;
>
> cmpthese( -1, {
> slice => sub { @slice{ @keys }= ($VALUE) x @keys },
> plain => sub { $plain{ $_ }= $VALUE for @keys },
> alias => sub { alias $alias{ $_ }= $VALUE for @keys },
> });
>
> print "";
> for ( [ plain => \%plain ], [ slice => \%slice ], [ alias => \%alias ]
> ) {
> print sprintf qq{%s k=%s, v=%s}, $_->[0], size( $_->[1] ),
> total_size( $_->[1] ) - size( $_->[1] );
> }
> '
> keys: 456976
> Rate slice alias plain
> slice 3.33/s -- -13% -19%
> alias 3.81/s 14% -- -8%
> plain 4.13/s 24% 8% --
>
> plain k=13978588, v=12795328
> slice k=13978588, v=12795328
> alias k=13978588, v=28
>
> Try also with slice initialised to (), then make the $VALUE undef.
> You'll find that slice is twice as fast, but still uses (for no good
> reason) quite some memory for all the undef-SVs.
>
> This is a nice way to implement sets, where all you need is exists().
> Or any other situation where the values come in packs.
>
> Cheers!
You can do similar things with arrays:
perl -Mstrict -MData::Alias -MDevel::Size=size,total_size -wle'
my ( $MAX, $undef, @plain, @sparse, @alias )= ( 1234567 );
$plain[ $_ ]= $undef for 0 .. $MAX;
$sparse[ $MAX ]= $undef;
alias $alias[ $_ ]= $undef for 0 .. $MAX;
my %existing;
print "";
for ( [ plain => \@plain ],
[ spars => \@sparse ],
[ alias => \@alias ],
) {
my ( $k, $v ) = @$_;
$existing{ $k }= scalar grep exists $v->[ $_ ], 0 .. $#$v;
print sprintf qq{%s meta=%s B, data=%s B, k#=%s},
$k,
size( $v ),
total_size( $v ) - size( $v ),
$existing{ $k };
}
'
plain meta=8388740 B, data=14814816 B, k#=1234568
spars meta=4938420 B, data=12 B, k#=1
alias meta=8388740 B, data=12 B, k#=1234568
So use sparse arrays if not many slots will be occupied,
and use Data::Alias if you have a lot of equal values in the array.
But also look into the Vector modules, and into PDL,
and find out what is fittest in your context.
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 23:34:21 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Data::Alias
Message-Id: <d4o0k7-t811.ln1@osiris.mauzo.dyndns.org>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>
> Well, don't get too afraid of op-tree manipulations yet, because there
> is a whole new set of tools coming to do just that, though in a better,
> more controllable and sustainable way, and even in Perl (compare
> Devel::Declare).
D::D is also deeply scary. It relies on precise assumptions about the
interaction of the parser and the lexer that are not part of the core
API, and it uses PL_check which is an ugly evil hack just waiting to go
wrong.
We (FSVO) are working on the problem, but it's Hard, so don't expect
results any time soon.
> That is also more or less the way that Data::Alias should get fixed.
> It needed to be fixed after multiple Perl releases, and because it isn't
> in core, that is lagging.
My understanding was that there was some reason fixing it for 5.12 was
harder than before, and as a result there is a good chance it will never
be fixed. However, I haven't studied the code in detail, so I don't
know.
Ben
------------------------------
Date: Thu, 19 Aug 2010 19:34:55 -0400
From: monkeys paw <monkey@joemoney.net>
Subject: parsing CSV files
Message-Id: <08idnUF5yo48IvDRnZ2dnUVZ_vudnZ2d@insightbb.com>
FILE contains:
US,S,2009,Alexander L,R,"AGRICULTURE, NUTRITION AND FORESTRY."
US,S,2009,Alexander L,R,ARMED SERVICES.
If i parse the above lines with a split /,/ i will
correctly get field[5] = "ARMED SERVICES" on line 2,
but incorrectly field[5] = "AGRICULTURE," on line 1.
while ($line = <IN>) {
@field = split /,/, $line;
print "$field[5]\n";
}
Is there a way to modify the split to handle this file format?
------------------------------
Date: Fri, 20 Aug 2010 01:01:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: parsing CSV files
Message-Id: <17t0k7-7v11.ln1@osiris.mauzo.dyndns.org>
Quoth monkeys paw <monkey@joemoney.net>:
> FILE contains:
> US,S,2009,Alexander L,R,"AGRICULTURE, NUTRITION AND FORESTRY."
> US,S,2009,Alexander L,R,ARMED SERVICES.
>
> If i parse the above lines with a split /,/ i will
> correctly get field[5] = "ARMED SERVICES" on line 2,
> but incorrectly field[5] = "AGRICULTURE," on line 1.
>
> while ($line = <IN>) {
> @field = split /,/, $line;
> print "$field[5]\n";
> }
>
> Is there a way to modify the split to handle this file format?
No. Don't use split for parsing CSV. Use a module that parses CSV. I
would recommend Text::CSV_XS.
Ben
------------------------------
Date: Thu, 19 Aug 2010 15:05:59 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Perl array bug?
Message-Id: <87lj82tobs.fsf@quad.sysarch.com>
>>>>> "MH" == Malcolm Hoar <malch@malch.com> writes:
MH> $Big1[$index] = $value;
MH> However, the array contains many "holes" (undefined elements).
MH> So, this amounts to something like:
MH> $Big1[538] = 0;
MH> $Big1[53487] = 1;
MH> $Big1[35306] = 2;
MH> etc.
MH> Later, we interate over the array:
MH> foreach $key (@Big1) {
MH> $len = length ($key);
MH> if ($len) {
MH> if ($key eq '' && $len == 4) {print "You're kidding me!\n"; }
you are obviously not using warnings or you would get several
there. length and eq will warn on undef.
MH> Where we encounter a bizarre situation whereby an element
MH> is undefined but has a positive length.
i doubt it is a bug in perl. i doubt your logic is clean given the
warnings that should be emitted. maybe there is something else that is
going on we can't see.
MH> I have tried to create a small standalone program that
MH> demonstrates the problem but without any success.
that is important. you can't claim a bug unless you can isolate and show
it to others with code.
MH> I did try logging the values used to populate @Big1 and
MH> wrote a standalone that would fill an array with the
MH> same data. However, that did not exhibit the problem.
that means it isn't just an array with empty slots problem. it is likely
elsewhere in the code.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 19 Aug 2010 15:26:33 -0400
From: Steve C <smallpond@juno.com>
Subject: Re: Perl array bug?
Message-Id: <i4k0hi$lbl$1@news.eternal-september.org>
Malcolm Hoar wrote:
> I believe I may have found a bug in ActivePerl 5.12.1.1201 (64-bit).
>
> This problem does *not* arise with ActivePerl 5.10.1.1007 (64-bit).
>
Many people have claimed "This doesn't happen with X" as
proof that Y must somehow be at fault. Its a fallacy.
------------------------------
Date: Thu, 19 Aug 2010 19:30:14 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Perl array bug?
Message-Id: <i4k0o63q1t8002malch@news.sonic.net>
In article <87lj82tobs.fsf@quad.sysarch.com>, "Uri Guttman" <uri@StemSystems.com> wrote:
>you are obviously not using warnings or you would get several
>there. length and eq will warn on undef.
No, I'm not. This code is quite old. But it's also been
running on hundreds of systems for almost 10 years without
any problem!
> MH> Where we encounter a bizarre situation whereby an element
> MH> is undefined but has a positive length.
>
>i doubt it is a bug in perl. i doubt your logic is clean given the
>warnings that should be emitted. maybe there is something else that is
>going on we can't see.
Well, yeah, there's lots going on but not with these vars.
> MH> I have tried to create a small standalone program that
> MH> demonstrates the problem but without any success.
>
>that is important. you can't claim a bug unless you can isolate and show
>it to others with code.
I understand the need for a reproducible example. That
looks like it's going to be very tough. It may be
impossible if, as I suspect, the problem is deep down
with the malloc() calls.
This same code did reveal some other malloc() problems with
ActivePerl versions with build numbers around 600, I think.
But they were resolved a long time ago.
> MH> I did try logging the values used to populate @Big1 and
> MH> wrote a standalone that would fill an array with the
> MH> same data. However, that did not exhibit the problem.
>
>that means it isn't just an array with empty slots problem. it is likely
>elsewhere in the code.
That doesn't follow if the problem is with Perl's internal
memory management.
It looks like I can work around the problem with an
explicit check for undef versus relying upon the
returned length(). I will pursue this in order to
get my users up and running first. Then I will continue
trying to create a standalone demonstration of the
issue.
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Thu, 19 Aug 2010 19:34:30 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Perl array bug?
Message-Id: <i4k1063q1t8004malch@news.sonic.net>
In article <i4k0hi$lbl$1@news.eternal-september.org>, Steve C <smallpond@juno.com> wrote:
>Malcolm Hoar wrote:
>> I believe I may have found a bug in ActivePerl 5.12.1.1201 (64-bit).
>>
>> This problem does *not* arise with ActivePerl 5.10.1.1007 (64-bit).
>>
>
>Many people have claimed "This doesn't happen with X" as
>proof that Y must somehow be at fault. Its a fallacy.
I made no such claim. It's "relevant evidence". But it's
not proof, and I didn't claim it was.
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Thu, 19 Aug 2010 15:42:37 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Perl array bug?
Message-Id: <87y6c2s82a.fsf@quad.sysarch.com>
>>>>> "MH" == Malcolm Hoar <malch@malch.com> writes:
MH> It looks like I can work around the problem with an
MH> explicit check for undef versus relying upon the
MH> returned length(). I will pursue this in order to
MH> get my users up and running first. Then I will continue
MH> trying to create a standalone demonstration of the
MH> issue.
that was what i should have suggested. defined is a better test than
length as it makes more logical sense and won't be confused.
there are some subtle things with arrays and undefining entries. are you
doing that? i never like to see undef used like a function.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 19 Aug 2010 20:15:51 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Perl array bug?
Message-Id: <i4k3dn3u2de002malch@news.sonic.net>
In article <87y6c2s82a.fsf@quad.sysarch.com>, "Uri Guttman" <uri@StemSystems.com> wrote:
>that was what i should have suggested. defined is a better test than
>length as it makes more logical sense and won't be confused.
>
>there are some subtle things with arrays and undefining entries. are you
>doing that? i never like to see undef used like a function.
No. This array name is reused a lot (which helps memory usage).
But it's explicitly cleared at the start of the problem module:
@Big1 = ();
Elements are set, modified, and used but never deleted/undef'ed.
Before the module returns, the array is completely cleared
once again.
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Thu, 19 Aug 2010 16:23:48 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Perl array bug?
Message-Id: <8762z6s65n.fsf@quad.sysarch.com>
>>>>> "MH" == Malcolm Hoar <malch@malch.com> writes:
MH> In article <87y6c2s82a.fsf@quad.sysarch.com>, "Uri Guttman" <uri@StemSystems.com> wrote:
>> that was what i should have suggested. defined is a better test than
>> length as it makes more logical sense and won't be confused.
>>
>> there are some subtle things with arrays and undefining entries. are you
>> doing that? i never like to see undef used like a function.
MH> No. This array name is reused a lot (which helps memory usage).
MH> But it's explicitly cleared at the start of the problem module:
MH> @Big1 = ();
MH> Elements are set, modified, and used but never deleted/undef'ed.
MH> Before the module returns, the array is completely cleared once
MH> again.
maybe instead of clearing it, let it exit scope? or since it is sparse
as you claim, change it to a hash and you will save space. maybe the
problem will go away too. it may be as simple as changing all [] to {}
where the array is used plus some other things like keys for loops.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 19 Aug 2010 21:07:18 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Perl array bug?
Message-Id: <slrni6r786.p91.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-19, Uri Guttman <uri@StemSystems.com> wrote:
> that is important. you can't claim a bug unless you can isolate and show
> it to others with code.
BS.
Yours,
Ilya
------------------------------
Date: Thu, 19 Aug 2010 21:11:49 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Perl array bug?
Message-Id: <slrni6r7gl.p91.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-19, Uri Guttman <uri@StemSystems.com> wrote:
> MH> But it's explicitly cleared at the start of the problem module:
>
> MH> @Big1 = ();
>
> MH> Elements are set, modified, and used but never deleted/undef'ed.
>
> MH> Before the module returns, the array is completely cleared once
> MH> again.
>
> maybe instead of clearing it, let it exit scope?
AFACR, exiting the scope is equivalent to
undef @Big1;
(But maybe I'm mixing scalars and arrays; I worked on the code of
undef() so long ago, and did not look into it for some time.) Anyway,
this should be visible with Devel::Peek...
> problem will go away too.
The problem is a bug in Perl. It won't go away by changing a user's code.
Ilya
------------------------------
Date: Thu, 19 Aug 2010 21:15:27 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Perl array bug?
Message-Id: <slrni6r7nf.p91.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-19, Steve C <smallpond@juno.com> wrote:
> Malcolm Hoar wrote:
>> I believe I may have found a bug in ActivePerl 5.12.1.1201 (64-bit).
>> This problem does *not* arise with ActivePerl 5.10.1.1007 (64-bit).
> Many people have claimed "This doesn't happen with X" as
> proof that Y must somehow be at fault. Its a fallacy.
Do not be silly. For a piece of code
a) which uses constructs taught in the first hour of Perl tutorials;
b) which works differently between two versions of Perl
there must be a documented easy-findable explanation. If not, it is a
bug in Perl.
Yours,
Ilya
------------------------------
Date: Thu, 19 Aug 2010 23:43:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl array bug?
Message-Id: <dlo0k7-t811.ln1@osiris.mauzo.dyndns.org>
Quoth malch@malch.com (Malcolm Hoar):
>
> I believe I may have found a bug in ActivePerl 5.12.1.1201 (64-bit).
>
> This problem does *not* arise with ActivePerl 5.10.1.1007 (64-bit).
>
> Both running on Windows 7 64-bit with all current hot fixes.
>
> Unfortunately, I have not yet been able to isolate the problem
> code from a large and proprietary program.
>
> Howeber, in short, we clear a large array:
>
> @Big1 = ();
>
> The specific elements of the array are populated:
>
> $Big1[$index] = $value;
>
> However, the array contains many "holes" (undefined elements).
> So, this amounts to something like:
>
> $Big1[538] = 0;
> $Big1[53487] = 1;
> $Big1[35306] = 2;
> etc.
>
> Later, we interate over the array:
>
> foreach $key (@Big1) {
> $len = length ($key);
> if ($len) {
> if ($key eq '' && $len == 4) {print "You're kidding me!\n"; }
>
> Where we encounter a bizarre situation whereby an element
> is undefined but has a positive length.
If you can reproduce the problem at will, try inserting
use Devel::Peek ();
Devel::Peek::Dump $key;
at the point where you detect an apparently broken key. Post a couple of
examples of the results so we can see if there's anything obviously
wrong with those scalars.
If you can reproduce the problem with an array without too large a
maximum index, you could also try Dumping the whole array.
If you can build a DEBUGGING version of Perl and try your app on that,
that would be good. If we're lucky you'll get an assertion failure
somewhere closer to the actual cause. If there is a bug here, it's
probably a memory allocation bug, so you will likely find that building
with debugging changes the exact circumstances under which it manifests.
I don't know if there's any valgrind-alike for Win32, but if there is
you could try running your app under that just to see what it says.
Ben
------------------------------
Date: Thu, 19 Aug 2010 21:04:21 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Smaller docs vs organized docs
Message-Id: <slrni6r72l.p91.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-19, Ben Morrow <ben@morrow.me.uk> wrote:
> Maybe I'm being over-sensitive. '...the current state of Perl docs is
> abysmal' reads to me like a condemnation of p5p, for not having fixed
> them yet.
In fact, not "for not having fixed them", but for "bringing them to
this state". IMO, the situation was significantly better in 90s. Not
because there was better organization of the docs, but because the
sheer volume of the docs to navigate was closer to what is humanly
possible without a stringent organization.
> All of us here learned Perl from the standard docs perfectly
> well, so there must be something worth having in there.
I'm not sure that this is as easy to do today...
Yours,
Ilya
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3086
***************************************
