[31822] in Perl-Users-Digest
Perl-Users Digest, Issue: 3085 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 19 14:09:30 2010
Date: Thu, 19 Aug 2010 11:09:09 -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: 3085
Today's topics:
ActivePerl Migration Win 2003 Server to Win 2008 Server <klaus03@gmail.com>
Re: ActivePerl Migration Win 2003 Server to Win 2008 Se <ben@morrow.me.uk>
Re: ActivePerl Migration Win 2003 Server to Win 2008 Se <klaus03@gmail.com>
Re: combining hashes <NoSpamPleaseButThisIsValid3@gmx.net>
Re: combining hashes sln@netherlands.com
Re: combining hashes <m@rtij.nl.invlalid>
Re: combining hashes sln@netherlands.com
Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <ben@morrow.me.uk>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <jl_post@hotmail.com>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: Data::Alias <uri@StemSystems.com>
Re: Data::Alias <rvtol+usenet@xs4all.nl>
Re: FAQ 3.4 How do I find which modules are installed o <xemoth@gmail.com>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <nospam-abuse@ilyaz.org>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <nospam-abuse@ilyaz.org>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <ben@morrow.me.uk>
Perl array bug? (Malcolm Hoar)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 19 Aug 2010 04:01:13 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <a7b74a04-f6c9-4d92-8d4e-982d58359195@g17g2000yqe.googlegroups.com>
Hello,
I hope this post is not OT in c.l.p.m.
I have got a couple of medium-sized (1000+ lines of code) of Perl
programs (64 bits) running on Windows Server 2003, the perl version
is:
C:\>perl -v
This is perl, v5.10.1 built for MSWin32-x64-multi-thread
(with 2 registered patches, see perl -V for more detail)
Binary build 1007 [291969] provided by ActiveState http://www.ActiveState.com
Built Jan 27 2010 14:12:21
I am using ADODB to connect to MSAccess databases, I read
ActiveDirectory entries and I use StorageCentral to setup Storage
quotas for 1000+ directories.
Now I have to migrate Windows Server from 2003 to 2008.
Before I embark on this adventure, I would ask for the wisdom of the
perl user community:
- Does anybody have experience with migrating perl programs from
Windows Server 2003 to 2008 ?
- Are there any pitfalls I need to be aware of ?
- Do you recommend upgrading from perl 5.10 (x64) to the newer perl
5.12 (x64) at the same time ?
------------------------------
Date: Thu, 19 Aug 2010 12:46:35 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <r5ivj7-7hs.ln1@osiris.mauzo.dyndns.org>
Quoth Klaus <klaus03@gmail.com>:
>
> I hope this post is not OT in c.l.p.m.
Certainly not :).
> I have got a couple of medium-sized (1000+ lines of code) of Perl
> programs (64 bits) running on Windows Server 2003, the perl version
> is:
>
> C:\>perl -v
> This is perl, v5.10.1 built for MSWin32-x64-multi-thread
[...]
> Now I have to migrate Windows Server from 2003 to 2008.
>
> Before I embark on this adventure, I would ask for the wisdom of the
> perl user community:
>
> - Does anybody have experience with migrating perl programs from
> Windows Server 2003 to 2008 ?
Sorry, I don't.
> - Are there any pitfalls I need to be aware of ?
>
> - Do you recommend upgrading from perl 5.10 (x64) to the newer perl
> 5.12 (x64) at the same time ?
That depends on how you're doing the migration. If you've scheduled some
time now to do the migration, and you're planning to upgrade to 5.12
reasonably soon anyway, then it might be a good idea to do both jobs at
the same time. Otherwise, I would always recommend sticking with the
perl you know works until you have a good reason not to ('it's no longer
getting security fixes' is a good reason, which as of now applies to 5.8
but (AIUI) not 5.10).
While the upgrade *should* be painless, IME it isn't always and you
should make sure to test everything properly with the new perl before
putting it into production. For instance, I just upgraded to 5.12 and
found that Data::Alias no longer works and isn't likely to be fixed.
Since I was using it in a couple of places that was annoying. (I knew it
was implemented with some slightly dodgy techniques that relied too much
on the core internals, so I was consciously avoiding it in many places
and the damage wasn't as bad as it might have been.)
Ben
------------------------------
Date: Thu, 19 Aug 2010 05:19:30 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: ActivePerl Migration Win 2003 Server to Win 2008 Server
Message-Id: <ef0d0774-b053-4800-8ced-933a30004e9a@f6g2000yqa.googlegroups.com>
On 19 ao=FBt, 13:46, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Klaus <klau...@gmail.com>:
> > I hope this post is not OT in c.l.p.m.
>
> Certainly not :).
Thanks :-)
> > Now I have to migrate Windows Server from 2003 to 2008.
> While the upgrade *should* be painless, IME it isn't always and you
> should make sure to test everything properly with the new perl before
> putting it into production. For instance, I just upgraded to 5.12 and
> found that Data::Alias no longer works and isn't likely to be fixed.
I am not using Data::Alias, but I have a couple of in-house modules
that certainly push the limits of what is possible under Perl 5.10
(x64) and Windows Server 2003.
Your advice is very well taken, and I will test properly with Perl
5.12 (x64) and Windows Server 2008.
--
Klaus
------------------------------
Date: Wed, 18 Aug 2010 20:24:57 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: combining hashes
Message-Id: <4c6c257a$0$6975$9b4e6d93@newsspool4.arcor-online.net>
On 18.08.2010 15:35, ccc31807 wrote:
> To take a real life example, I have %retirement that contains key
> value pairs consisting of the employee ID and the employee's
> retirement system status, like this:
> 12345 => 'Member'
> 23456 => 'Non=Member'
> 34567 => 'Retired'
> 45678 => 'Inactive Member'
> I also have %employees which contain data relating to individual
> employees, but that does not contain the retirement system status. It
> looks like this:
> 56789 => { last => 'Doe', first => 'John', title => 'Mr.', ...}
> To produce the report, I have to 'merge' %retirement and %employee. I
> can easily do this like:
> foreach my $id {keys %employee)
> {
> $employee{$id}{retirement} = $retirement{$id} if exists
> $retirement{$id};
> $employee{$id}{retirement} = 'Unknown' unless exists
> $retirement{$id};
> }
Just a question: did you ever think about some OO approach?
Something like
my $e = Employee->new(...);
print "Employee ", $e->name(), " has ID ", $e->id();
Wolf
------------------------------
Date: Wed, 18 Aug 2010 12:38:24 -0700
From: sln@netherlands.com
Subject: Re: combining hashes
Message-Id: <pcdo66d9d1u7tr07c70qgh7o81h652ii84@4ax.com>
On Tue, 17 Aug 2010 12:01:55 +0800, "ela" <ela@yantai.org> wrote:
>Since this topic looks similar to my problem, I post my question as a follow
>up. Previously Jens Thoms Toerring, Tad McClellan and sln taught me much
>about the usage of hashing (grateful) and I would like to extend the
>application to has the following data (again, a very large one):
>
><snippet>
>180092|Africa|2002-07-30
>180092|Australia|2002-07-30
>180092|Caribbean|2002-07-30
>180092|Europe & Northern Asia (excluding China)|2002-07-30
>180092|Middle America|2002-07-30
>180092|North America|2002-07-30
>180092|Oceania|2002-07-30
>180092|South America|2002-07-30
>180092|Southern Asia|2002-07-30
><snippet>
>
>when ID 180092 is given, I want to get the locations quickly from the hash.
>Is that what this topic "combined hash" is talking about?
>
I guess you could thin out text overhead on the locations
with something like below. Its not as hard as it looks.
-sln
--------------------
use strict;
use warnings;
##
my %Loc2code;
my %Key;
my $code = 0;
##
while( defined (my $line = <DATA>))
{
my ($id, $place) = $line =~ /^ \s*(\d+)\s* \| \s* ((?:(?!\s*(?:[|\n])).)+) /x;
next if !defined $place;
if (! exists $Loc2code{ $place }) {
$Loc2code{ $place } = $code++;
}
push @{ $Key{ $id } }, $Loc2code{ $place };
}
##
my %Code2loc = reverse %Loc2code;
for my $testid ( '180092', '2701' ) {
if (exists $Key{ $testid })
{
print "\n$testid\n";
for( sort {$a cmp $b}
map {$Code2loc{$_}} @{ $Key{ $testid } })
{
print " $_\n";
}
}
}
__DATA__
<snippet>
180092|North America |2002-07-30
180092|Oceania|2002-07-30
180092|Africa|2002-07-30
2701 |Australia|2002-07-30
2701 |
180092|Australia|2002-07-30
180092|South America|2002-07-30
2701 |France|2002-07-30
180092|Caribbean|2002-07-30
180092|Europe & Northern Asia (excluding China)|2002-07-30
180092|Middle America|2002-07-30
2701 |Detroit|2002-07-30
180092|Southern Asia|2002-07-30
2701 |All of Asia|2002-07-30
<snippet>
=================================
The regular expression:
($id,$place) = $line =~ /^ \s*(\d+)\s* \| \s* ((?:(?!\s*(?:[|\n])).)+) /x;
is just a fancy way of trimming and validating data, all
at once.
It could have been done with split() or a simpler regex:
($id,$place) = $line =~ / (\d+) \s*\|\s* ([^|\n]+) /x;
$place =~ s/\s+$//;
================================
Output:
180092
Africa
Australia
Caribbean
Europe & Northern Asia (excluding China)
Middle America
North America
Oceania
South America
Southern Asia
2701
All of Asia
Australia
Detroit
France
------------------------------
Date: Wed, 18 Aug 2010 22:40:14 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: combining hashes
Message-Id: <e2ttj7-slo.ln1@news.rtij.nl>
On Wed, 18 Aug 2010 06:35:22 -0700, ccc31807 wrote:
> In practice, I never use 'order by' in my SQL, I always do it in the
> script.
Often the SQL server can sort much more efficiently. Especially if you
have an index on the field you're sorting on, it comes almost free
(however, having a key isn't free, it increases insertion and update
time).
M4
------------------------------
Date: Wed, 18 Aug 2010 14:24:00 -0700
From: sln@netherlands.com
Subject: Re: combining hashes
Message-Id: <1njo665slun9lscpqm6qimqg5kp6pq17c6@4ax.com>
On Wed, 18 Aug 2010 12:38:24 -0700, sln@netherlands.com wrote:
> my ($id, $place) = $line =~ /^ \s*(\d+)\s* \| \s* ((?:(?!\s*(?:[|\n])).)+) /x;
Should have taken out the extra grouping from old.
my ($id, $place) = $line =~ /^ \s*(\d+)\s* \| \s* ((?:(?!\s*[|\n]).)+) /x;
-sln
------------------------------
Date: Thu, 19 Aug 2010 14:18:15 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Data::Alias
Message-Id: <4c6d2108$0$22945$e4fe514c@news.xs4all.nl>
Ben Morrow wrote:
> For instance, I just upgraded to 5.12 and
> found that Data::Alias no longer works and isn't likely to be fixed.
I still have good hopes that it will be fixed. It is a real favorite
module of mine. When used well, it saves you quite some CPU-cycles and
memory.
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 15:14:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Data::Alias
Message-Id: <krqvj7-egt.ln1@osiris.mauzo.dyndns.org>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> Ben Morrow wrote:
>
> > For instance, I just upgraded to 5.12 and
> > found that Data::Alias no longer works and isn't likely to be fixed.
>
> I still have good hopes that it will be fixed. It is a real favorite
> module of mine. When used well, it saves you quite some CPU-cycles and
> memory.
I don't think so. It's only ever a syntactic convenience over using
references, it's just a really nice one.
Ben
------------------------------
Date: Thu, 19 Aug 2010 17:22:02 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6d4c1a$0$22938$e4fe514c@news.xs4all.nl>
Ben Morrow wrote:
> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>> Ben Morrow wrote:
>>> For instance, I just upgraded to 5.12 and
>>> found that Data::Alias no longer works and isn't likely to be fixed.
>> I still have good hopes that it will be fixed. It is a real favorite
>> module of mine. When used well, it saves you quite some CPU-cycles and
>> memory.
>
> I don't think so. It's only ever a syntactic convenience over using
> references, it's just a really nice one.
That's a lie! :)
Data::Dumper does many things at compile time (so no ENTER/LEAVE
overhead that other aliassing solutions need (like Lexical::Alias).
And you can make all (or many) values of a (huge) hash be a single SV
(undef, for example).
It is/was a great module. It should be resurrected.
Though the new ':=' operator is promising too.
Data::Alias gives things like
alias my %bar = %{ $foo->{ bar } };
which will also set $foo->{ bar } to {} if it was undef.
Etc.
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 18:05:53 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6d5662$0$22943$e4fe514c@news.xs4all.nl>
Dr.Ruud wrote:
> Ben Morrow wrote:
>> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>>> Ben Morrow wrote:
>
>>>> For instance, I just upgraded to 5.12 and
>>>> found that Data::Alias no longer works and isn't likely to be fixed.
>>> I still have good hopes that it will be fixed. It is a real favorite
>>> module of mine. When used well, it saves you quite some CPU-cycles
>>> and memory.
>>
>> I don't think so. It's only ever a syntactic convenience over using
>> references, it's just a really nice one.
>
> That's a lie! :)
>
> Data::Dumper does many things at compile time (so no ENTER/LEAVE
> overhead that other aliassing solutions need (like Lexical::Alias).
>
> And you can make all (or many) values of a (huge) hash be a single SV
> (undef, for example).
>
> It is/was a great module. It should be resurrected.
>
> Though the new ':=' operator is promising too.
>
> Data::Alias gives things like
>
> alias my %bar = %{ $foo->{ bar } };
>
> which will also set $foo->{ bar } to {} if it was undef.
> Etc.
An example of the Etc.
perl -Mstrict -MData::Alias -wle '
#alias
my $s = "foo,bar,baz";
my @s;
for my $i ( 0 .. 2 ) {
alias $s[ $i ] = substr( $s, $i * 4, 3 );
}
eval { $s[ 1 ] = "xyz"; 1 } or warn "w: ", $@;
print $s;
print "@s";
'
foo,xyz,baz
foo xyz baz
Also try the above with the '#' removed from line 2.
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 09:24:19 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Data::Alias
Message-Id: <6bdaff81-f66f-42cd-b75a-0b0e6c6352ca@j18g2000yqd.googlegroups.com>
On Aug 19, 9:22=A0am, "Dr.Ruud" <rvtol+use...@xs4all.nl> wrote:
>
> It is/was a great module. It should be resurrected.
Data::Alias certainly is a great module. I've loved it ever since
Ben Morrow introduced me to it. When used correctly, it makes code
much more readable (and comprehensible to those who struggle with
references).
Programmers new to Perl often discover that @arrays and %hashes
aren't passed in and out of functions in quite the same way that
scalars are. As a result, they're more likely to declare many of
their @arrays and %hashes as global variables (or to avoid
declarations and "use strict" altogether) than to deal with passing in
references and correctly dereferencing them with $ref->{...} and $ref-
>[...] syntax (which is tricky to get right when not familiar with
them).
For this reason I think that Data::Alias should be made a core
module of Perl. Perl programmers (and Perl programs) as a whole will
be better off once they all have access to the Data::Alias module.
But that's just my opinion. ;)
-- Jean-Luc
------------------------------
Date: Thu, 19 Aug 2010 19:26:32 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6d6948$0$22943$e4fe514c@news.xs4all.nl>
jl_post@hotmail.com wrote:
> On Aug 19, 9:22 am, "Dr.Ruud" <rvtol+use...@xs4all.nl> wrote:
>> It is/was a great module. It should be resurrected.
>
>
> Data::Alias certainly is a great module. I've loved it ever since
> Ben Morrow introduced me to it. When used correctly, it makes code
> much more readable (and comprehensible to those who struggle with
> references).
>
> Programmers new to Perl often discover that @arrays and %hashes
> aren't passed in and out of functions in quite the same way that
> scalars are. As a result, they're more likely to declare many of
> their @arrays and %hashes as global variables (or to avoid
> declarations and "use strict" altogether) than to deal with passing in
> references and correctly dereferencing them with $ref->{...} and $ref-
>> [...] syntax (which is tricky to get right when not familiar with
> them).
>
> For this reason I think that Data::Alias should be made a core
> module of Perl. Perl programmers (and Perl programs) as a whole will
> be better off once they all have access to the Data::Alias module.
>
> But that's just my opinion. ;)
I agree to the "core module" part, but not to the syntax parts.
I would never recommend Data::Alias for such a reason. To me it
is mainly a module that brings better performance.
alias my %foo = %{ $table->{ foo } };
allows one to write
$foo{ key }
in stead of
$table->{ foo }{ key }
and that performs better.
perl -Mstrict -MData::Dumper -MData::Alias -MBenchmark=cmpthese -wle'
my $href;
alias my %foo = %{ $href->{ foo } };
$foo{ test }= 0;
#print "\n", Dumper( $href );
cmpthese( -1, {
plain => sub { $href->{ foo }{ test }= 1 },
alias => sub { $foo{ test }= 2 },
});
#print "\n", Dumper( $href );
'
Rate plain alias
plain 2194985/s -- -54%
alias 4812084/s 119% --
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 13:38:52 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Data::Alias
Message-Id: <877hjmwlhv.fsf@quad.sysarch.com>
>>>>> "R" == Ruud <rvtol+usenet@xs4all.nl> writes:
R> I agree to the "core module" part, but not to the syntax parts.
R> I would never recommend Data::Alias for such a reason. To me it
R> is mainly a module that brings better performance.
it is still just syntax sugar.
R> $foo{ key }
R> in stead of
R> $table->{ foo }{ key }
i never write deep hashes like that more than one time. i take refs to
the deeper level and use that. so the speed savings can be done without
this module. it may be nice and cute but it isn't any major win in speed
or syntax. you can't use it to hide from refs all the time. and it makes
the code maintainer learn all its tricks before he can work on 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 20:02:42 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Data::Alias
Message-Id: <4c6d71c2$0$22916$e4fe514c@news.xs4all.nl>
Uri Guttman wrote:
>> <rvtol+usenet@xs4all.nl> writes:
>> I agree to the "core module" part, but not to the syntax parts.
>> I would never recommend Data::Alias for such a reason. To me it
>> is mainly a module that brings better performance.
>
> it is still just syntax sugar.
Or you are just wrong.
>> $foo{ key }
>>
>> in stead of
>>
>> $table->{ foo }{ key }
>
> i never write deep hashes like that more than one time. i take refs to
> the deeper level and use that. so the speed savings can be done without
> this module.
perl -Mstrict -MData::Alias -MBenchmark=cmpthese -wle'
my $h;
alias my %alias = %{ $h->{ foo } };
$alias{ test }= 0;
my $plain= $h->{ foo };
cmpthese( -1, {
plain => sub { $plain->{ test }= 1 },
alias => sub { $alias{ test }= 2 },
});
'
Rate plain alias
plain 3276800/s -- -28%
alias 4549606/s 39% --
(just because dereferencing has runtime costs)
> it may be nice and cute but it isn't any major win in speed
> or syntax. you can't use it to hide from refs all the time. and it makes
> the code maintainer learn all its tricks before he can work on the code.
What a loss of cycles that you just never found out how much more it is.
--
Ruud
------------------------------
Date: Thu, 19 Aug 2010 03:21:28 -0700 (PDT)
From: Owen <xemoth@gmail.com>
Subject: Re: FAQ 3.4 How do I find which modules are installed on my system?
Message-Id: <3bddb610-d23f-4090-9a93-c36fe0829a99@x20g2000pro.googlegroups.com>
On Aug 19, 8:00=A0am, PerlFAQ Server <br...@theperlreview.com> wrote:
> This is an excerpt from the latest version perlfaq3.pod, which
> comes with the standard Perl distribution. These postings aim to
> reduce the number of repeated questions as well as allow the community
> to review and update the answers. The latest version of the complete
> perlfaq is athttp://faq.perl.org.
>
> --------------------------------------------------------------------
>
> 3.4: How do I find which modules are installed on my system?
>
> =A0 =A0 From the command line, you can use the "cpan" command's "-l" swit=
ch:
>
> =A0 =A0 =A0 =A0 =A0 =A0 $ cpan -l
Well just tried this and "it didn't work".
owen@owen-desktop:~$ cpan -l
Unknown option: l
Nothing to install!
Que?
Owen
------------------------------
Date: Wed, 18 Aug 2010 20:41:23 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <slrni6ohbj.l9v.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-18, Ben Morrow <ben@morrow.me.uk> wrote:
>> [*] Unfortunately (and I do not need to repeat it) the current state
>> of Perl docs is abysmal. One of (many) major problems is that
>> there is no separation of "user's guide" and "reference guide"
>> parts. (Only the FAQ is clearly standing alone.)
>>
>> It might be that one can break man/pod-pages into these two
>> categories (although I doubt this). But even if this is true,
>> there is no indication (I know of) of this separation.
> Well, the *tut pods are intended as tutorials, and the *ref as
> reference guides :)... Being rude about it doesn't help anyone.
I'm really puzzled. It looks like you consider my remark rude. How
comes? I'm really listening...
Yours,
Ilya
------------------------------
Date: Wed, 18 Aug 2010 20:48:24 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <slrni6ohoo.l9v.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-18, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Tue, 17 Aug 2010 22:59:50 -0500 "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net> wrote:
> IZ> The moment "a book in a marketplace" enters a discussion of the docs,
> IZ> I plunk. Books have their place. Just not in this discussion.
>
> Of course, we can ignore books in a discussion about the FAQ. I simply
> didn't know your rules about our discussion.
;-) Point taken. However, now you know - and you might have
contributed on why the existence of books matter (which, apparently,
is your point).
> Your other points about how you would like the Perl docs to be in a
> perfect world are not very convincing to me, either. I think we've
> clearly established that neither of us is easily convinced :)
Com'on, I'm a teacher (at least in spirit), so I do not care about
teaching anybody anything - or convincing anybody. Having the point
heard is quite enough. (Those having ears would listen.)
Ilya
------------------------------
Date: Thu, 19 Aug 2010 02:56:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <oifuj7-54l.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-08-18, Ben Morrow <ben@morrow.me.uk> wrote:
> >> [*] Unfortunately (and I do not need to repeat it) the current state
> >> of Perl docs is abysmal. One of (many) major problems is that
> >> there is no separation of "user's guide" and "reference guide"
> >> parts. (Only the FAQ is clearly standing alone.)
> >>
> >> It might be that one can break man/pod-pages into these two
> >> categories (although I doubt this). But even if this is true,
> >> there is no indication (I know of) of this separation.
>
> > Well, the *tut pods are intended as tutorials, and the *ref as
> > reference guides :)... Being rude about it doesn't help anyone.
>
> I'm really puzzled. It looks like you consider my remark rude. How
> comes? I'm really listening...
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. The docs aren't 'abysmal', they're simply not as good as they
might be. All of us here learned Perl from the standard docs perfectly
well, so there must be something worth having in there.
Ben
------------------------------
Date: Thu, 19 Aug 2010 18:08:04 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Perl array bug?
Message-Id: <i4jru46q1rc002malch@news.sonic.net>
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.
I have tried to create a small standalone program that
demonstrates the problem but without any success.
I did try logging the values used to populate @Big1 and
wrote a standalone that would fill an array with the
same data. However, that did not exhibit the problem.
Is anyone aware of any similar issues or have any
suggestions that might help me create a standalone
program to demonstrate the problem?
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
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 3085
***************************************
