[31608] in Perl-Users-Digest
Perl-Users Digest, Issue: 2867 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 11 09:09:28 2010
Date: Thu, 11 Mar 2010 06:09:10 -0800 (PST)
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, 11 Mar 2010 Volume: 11 Number: 2867
Today's topics:
Re: Can you compile a perl executable? <bugbear@trim_papermule.co.uk_trim>
Re: Data::Dumper output the results in single quote. <news@lawshouse.org>
Earn Money Online at Home <nasiraparveen2010@gmail.com>
Re: Help on String to array ! <uri@StemSystems.com>
Re: Help on String to array ! <uri@StemSystems.com>
Re: Help on String to array ! <jismagic@gmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <tkpapp@gmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <timx@nospam.dev.null>
Re: to RG - Lisp lunacy and Perl psychosis <alessiostalla@gmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <timx@nospam.dev.null>
Re: to RG - Lisp lunacy and Perl psychosis <cartercc@gmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <ben@morrow.me.uk>
Well, that's the most obscure Perl bug I've ever seen <no-one@unknown.com>
Re: Well, that's the most obscure Perl bug I've ever se <matteo.corti@gmail.com>
Re: Well, that's the most obscure Perl bug I've ever se <no@ace.com>
Re: Well, that's the most obscure Perl bug I've ever se <devnull4711@web.de>
Re: Well, that's the most obscure Perl bug I've ever se <ben@morrow.me.uk>
Re: Well, that's the most obscure Perl bug I've ever se <no-one@unknown.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 11 Mar 2010 09:13:34 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Can you compile a perl executable?
Message-Id: <b4CdndNfc_aiKQXWnZ2dnUVZ8qRi4p2d@brightview.co.uk>
Peter J. Holzer wrote:
> On 2010-03-09 09:19, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>> Peter J. Holzer wrote:
>>> On 2010-03-03 09:00, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>>>> Jürgen Exner wrote:
>>>>> Steve <steve@staticg.com> wrote:
>>>>>> If I made an application, and wanted to make it portable, is it
>>>>>> possible to compile it into a single binary?
>>>>> See "perldoc -q compile":
>>>>> "How can I compile my Perl program into byte code or C?"
>>>>>
>>>> I note that this perldoc appears to be happy
>>>> that B::Bytecode is the way to do this,
>>> Not in the current version. That paragraph vanished sometime between
>>> 5.8.8 and 5.10.0
>> You mean the perldoc recommending B::Bytecode has
>> changed, or the warning in B::Bytecode?
>
> The former. See for yourself at
> http://perldoc.perl.org/perlfaq3.html#How-can-I-compile-my-Perl-program-into-byte-code-or-C?
Thanks. Although that's "not good" from my solution-oriented POV,
at least I won't waste time on a doomed solution.
BugBear
------------------------------
Date: Thu, 11 Mar 2010 08:47:25 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Data::Dumper output the results in single quote.
Message-Id: <ermdnXte9--AMwXWnZ2dnUVZ8q2dnZ2d@giganews.com>
John wrote:
> That is first time that I am using this Data::Dumper module to create
> an XML file. I don't know why that I am seeing single quote at the
> beginning and the end of output file. such as:
> "
The perldoc for Data::Dumper says "The return value can be evaled to get
back an identical copy of the original reference structure", and that
needs a quote of some kind. That's why they're there in Dumper's output.
> And here is part of my code to output that XML file:
> my $outData = $outXml->XMLout($inData, Rootname => "Properties",
> noattr=> 1, xmldecl=> '<?xml version="1.0"?>');
> open my $HR, ">", $file or die "can not open $file $!";
> print $HR Dumper($outData);
Why not simply do this:
print $HR "$outData\n";
Dumper is entirely unnecessary.
--
Henry Law Manchester, England
------------------------------
Date: Thu, 11 Mar 2010 05:22:26 -0800 (PST)
From: lucky <nasiraparveen2010@gmail.com>
Subject: Earn Money Online at Home
Message-Id: <b99804fb-ebe9-4eac-a725-e045e770f904@u5g2000prd.googlegroups.com>
Resources of how to make money online. find Money Making
Opportunities. Update of Latest Money Making Ideas, Latest E-Books and
tools helpful To make money online at Home.
For more details please visit: http://arf-earnmoney.blogspot.com
------------------------------
Date: Thu, 11 Mar 2010 00:47:09 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Help on String to array !
Message-Id: <87y6hzz9ya.fsf@quad.sysarch.com>
>>>>> "j" == jis <jismagic@gmail.com> writes:
j> Even I want to beleive it should take very less time.
j> I post the scripts I used for testing.
j> 1. #!/usr/bin/perl
j> # convert data to hex form
j> my $hex = unpack 'H*', $data;
j> my ($val, $offs, @arr) = ('',0);
j> #@arr = $hex =~ /[[:xdigit:]]{2}/g;
j> @arr = unpack("(C2)*",$hex);
j> my $data = <FILE>;
j> close FILE;
j> # convert data to hex form
j> my $hex = unpack 'H*', $data;
j> my $i=0;
j> my ($val, $offs, @arr) = ('',0);
j> while ($val=substr( $hex, $offs, 2)){
j> push @arr, $val;
j> $offs+=2;
j> }
j> print "bye";
j> print $arr[2]; This would take only 9 seconds.
j> I have used a stopwatch to calculate time.
a stopwatch? you need to learn how to use the Benchmark.pm module.
j> Appreciate your help in finding how it can be improved.
easy. let me do a proper benchmark.
and you should learn how to properly bottom post and not leave my entire
post in the message.
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, 11 Mar 2010 01:15:33 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Help on String to array !
Message-Id: <87pr3bz8my.fsf@quad.sysarch.com>
>>>>> "j" == jis <jismagic@gmail.com> writes:
j> if i uncommment regex protion and comment unpack it would take
j> 1minute 25 sec
j> print "bye";
j> print $arr[2]; This would take only 9 seconds.
j> I have used a stopwatch to calculate time.
as i said, that is a silly way to time programs. and there is no way it
would take minutes to do this unless you are on a severely slow cpu or
you are low on ram and are disk thrashing. here is my benchmarked
version which shows that unpacking (fixed to use A and not C) is the
fastest and regex (also fixed to do the simplest but correct thing which
is grab 2 chars) ties your code.
uncomment out those commented lines to see that this does the same and
correct thing in all cases.
here is the timing result run for 10 seconds each:
s/iter regex substring unpacking
regex 2.11 -- -0% -25%
substring 2.11 0% -- -25%
unpacking 1.58 33% 33% --
uri
use strict;
use warnings;
use File::Slurp ;
use Benchmark qw(:all) ;
my $duration = shift || -2 ;
my $file_name = '/boot/vmlinuz-2.6.28-15-generic' ;
my $data = read_file( $file_name, binary => 1 ) ;
#$data = "\x00\x10" ;
my $hex = unpack 'H*', $data;
# unpacking() ;
# regex() ;
# substring() ;
# exit ;
cmpthese( $duration, {
unpacking => \&unpacking,
regex => \®ex,
substring => \&substring,
} ) ;
sub unpacking {
my @arr = unpack( '(A2)*' , $hex) ;
# print "@arr\n"
}
sub regex {
my @arr = $hex =~ /(..{2})/g ;
# print "@arr\n"
}
sub substring {
my ($val, $offs, @arr) = ('',0);
while ($val=substr( $hex, $offs, 2)){
push @arr, $val;
$offs+=2;
}
# print "@arr\n"
}
--
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, 11 Mar 2010 04:43:45 -0800 (PST)
From: jis <jismagic@gmail.com>
Subject: Re: Help on String to array !
Message-Id: <39ee73a4-68b5-409d-95d2-c20e9a59eec6@l12g2000prg.googlegroups.com>
On Mar 11, 11:15=A0am, "Uri Guttman" <u...@StemSystems.com> wrote:
> >>>>> "j" =3D=3D jis =A0<jisma...@gmail.com> writes:
>
> =A0 j> if i uncommment =A0regex protion and comment unpack it would take
> =A0 j> 1minute 25 sec
>
> =A0 j> print "bye";
> =A0 j> print $arr[2]; =A0 =A0This would take only 9 seconds.
>
> =A0 j> I have used a stopwatch to calculate time.
>
> as i said, that is a silly way to time programs. and there is no way it
> would take minutes to do this unless you are on a severely slow cpu or
> you are low on ram and are disk thrashing. here is my benchmarked
> version which shows that unpacking (fixed to use A and not C) is the
> fastest and regex (also fixed to do the simplest but correct thing which
> is grab 2 chars) ties your code.
>
> uncomment out those commented lines to see that this does the same and
> correct thing in all cases.
>
> here is the timing result run for 10 seconds each:
>
> =A0 =A0 =A0 =A0 =A0 s/iter =A0 =A0 regex substring unpacking
> regex =A0 =A0 =A0 2.11 =A0 =A0 =A0 =A0-- =A0 =A0 =A0 -0% =A0 =A0 =A0-25%
> substring =A0 2.11 =A0 =A0 =A0 =A00% =A0 =A0 =A0 =A0-- =A0 =A0 =A0-25%
> unpacking =A0 1.58 =A0 =A0 =A0 33% =A0 =A0 =A0 33% =A0 =A0 =A0 =A0--
>
> uri
>
> use strict;
> use warnings;
>
> use File::Slurp ;
> use Benchmark qw(:all) ;
>
> my $duration =3D shift || -2 ;
>
> my $file_name =3D '/boot/vmlinuz-2.6.28-15-generic' ;
>
> my $data =3D read_file( $file_name, binary =3D> 1 ) ;
>
> #$data =3D "\x00\x10" ;
>
> my $hex =3D unpack 'H*', $data;
>
> # unpacking() ;
> # regex() ;
> # substring() ;
> # exit ;
>
> cmpthese( $duration, {
>
> =A0 =A0 =A0 =A0 unpacking =A0 =A0 =A0 =3D> \&unpacking,
> =A0 =A0 =A0 =A0 regex =A0 =A0 =A0 =A0 =A0 =3D> \®ex,
> =A0 =A0 =A0 =A0 substring =A0 =A0 =A0 =3D> \&substring,
>
> } ) ;
>
> sub unpacking {
> =A0 =A0 =A0 =A0 my @arr =3D unpack( '(A2)*' , $hex) ;
> # =A0 =A0 =A0 print "@arr\n"
>
> }
>
> sub regex {
> =A0 =A0 =A0 =A0 my @arr =3D $hex =3D~ /(..{2})/g ;
> # =A0 =A0 =A0 print "@arr\n"
>
> }
>
> sub substring {
>
> =A0 =A0 =A0 =A0 my ($val, $offs, @arr) =3D ('',0);
> =A0 =A0 =A0 =A0 while ($val=3Dsubstr( $hex, $offs, 2)){
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 push @arr, $val;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $offs+=3D2;
> =A0 =A0 =A0 =A0 }
>
> # =A0 =A0 =A0 print "@arr\n"
>
> }
>
> --
> Uri Guttman =A0------ =A0u...@stemsystems.com =A0-------- =A0http://www.s=
ysarch.com--
> ----- =A0Perl Code Review , Architecture, Development, Training, Support =
------
> --------- =A0Gourmet Hot Cocoa Mix =A0---- =A0http://bestfriendscocoa.com=
---------
Uri,
I have used the script you have posted with only change in input file
i get the following results.
(warning: too few iterations for a reliable count)
(warning: too few iterations for a reliable count)
(warning: too few iterations for a reliable count)
s/iter unpacking regex substring
unpacking 9.06 -- -27% -34%
regex 6.59 37% -- -9%
substring 6.01 51% 10% --
Unpacking still remains the longest to finish.
I use Windows XP professional with a 2Gb RAM. I also have got a 45GB
free space in my C drive.
DO you see something else different?
thanks,
jis
------------------------------
Date: 11 Mar 2010 07:28:02 GMT
From: Tamas K Papp <tkpapp@gmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <7vrkc1FjmeU1@mid.individual.net>
On Wed, 10 Mar 2010 19:09:16 -0800, ccc31807 wrote:
> On Mar 10, 7:19Â pm, Tamas K Papp <tkp...@gmail.com> wrote:
>
>> When you made a statement about "ignoring the horribleness and the
>> abominable in another language", I thought you meant Common Lisp. Â Did
>> you mean Perl?
>
> I didn't mean ANY particular language -- I meant the process of
> characterizing a language the way RG did based on reading a few chapters
> of an anonymous book. In the same way, I took it as fact that someone
That doesn't make sense. If somebody judges a language based on
insufficient information, they will be ignoring horribleness and
abominations in another one? Do I need some kind of hallucinogen to
understand this reasoning?
> Here's the point: Don't disparage a language before you know it, and
> don't rely on ignorant bias to disparage a language.
A truly deep point. I guess people didn't know this before.
I humbly offer the following pieces of advice, equally profound and
relevant to these newsgroups (but slightly more general):
It never rains but it pours.
A watched pot never boils.
Regards,
Tamas
------------------------------
Date: Thu, 11 Mar 2010 18:32:04 +1100
From: Tim X <timx@nospam.dev.null>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <877hpj9uvf.fsf@rapttech.com.au>
Tamas K Papp <tkpapp@gmail.com> writes:
> On Wed, 10 Mar 2010 07:01:14 -0800, ccc31807 wrote:
>
>
> Your post actually highlights some similarities between Perl and CL:
I thought that was part of his point. i.e. the differences are largely
just differences of syntactic sugar and that criticising one for being
'horrible' when you don't understand its type of refined sugar while
ignoring aspects of the sugar you are familiar with that could be just
as easily abused or confusing to the uninitiated was illlogical and
meaningless.
> both have various namespaces, once you see through the thin layer of
> syntax for accessing these. So your feeble attempt at starting a
> flamewar is pretty... funny.
>
Flamewar? I thought it was a reasonably thought out and argued response.
Unlike RG's original comments on perl, the gist I got from the post was
in fact anti-flamewar i.e. that the differences were really about
differences in familiarity and that claiming one is better than the
other is pretty pointless. If anything, it was the more rational and
balanced assessment compared to RG's original comment.
For the record, I find a lot about perl I don't like, especially with
respect to its syntax and somewhat inconsistent behavior in certain
areas. I much prefer CLs simpler and far more consistent approach. I
disagree with Perl's philosophy of allowing everyone to do it 'their
way' and anyone who has worked with perl on either a project with many
develoers or maintaining code written by many different authors will
know what I'm getting at. However, I've also frequently come across
problems that are much easier to solve with perl than they are with CL.
In fact, I ran into one just recently. I had to do some work with a
system that makes extensive use of Oracle and Oracle stored procedures.
I wanted to use CL for the task. However, after many many hours of
searching and trying out various CL interfaces to Oracle, I had to give
up because I could not find one single CL to Oracle library that would
allow you to work with stored procedures and ref cursors. Plenty, like clsql and Clisps
Oracle DB extension would allow you to do basic SQL queries, but none
would allow you to call a stored procedure and have access to all Oracle
parameter type (IN, OUT and IN OUT) or ref cursors (at least I couldn't
work it out from the docs or source code or experimentation).
After many many days of installing various libs, which in itself was
often painful, going through lots of docs, many of which were outdated,
incomplete or poorly written and even having compiled clisp extensions
etc, I had to give up.
I turned to perl. In less than half a day, I had things working via
Perl's DBI interface using the DBD::Oracle driver. Installation was
rediculously simple - essentially starting the perl CPAN shell and
asking it to install DBI and DBD::Oracle and it came with extensive and
well written comprehensive documentation. In half a day I had all the
tools working ans was able to concentrate on the problem I wanted to
work on rather than tyring to just get an environment that would let me
even start.
I'd prefer to be working with CL, but taht wasn't possible. Arguements
regarding which language is better or more powerful at a theoretical
level become pointless if you cannot use it to solve a real world
problem. This type of issue gets raised in this group frequently and the
general response is to attack the poster and become extremely defensive,
making all sorts of wild claims about CLs power and the ease at which
you can implement a library etc. However, the reality is that for many
problems, CL is not a good choice because it lacks the user base of
other languages such as perl and therefore lacks the extensive
repository of working useful libs that give the productive edge you need
to survive in the commercial world.
If, on the other hand, I want to experiment with some ideas or write
some software for pleasure or do something where I have the luxury of
time etc, I will likely use CL because it is one of the languages I
really enjoy programming in and which frustrates me less. It is
frequently the language I'll turn to if I want to try out something
unusual or a bit left of field where I don't want the preconceptions of
Larry, Gido or Matz getting in my way. However, if I want to get paid
for solving a problem and want to get a reasonable hourly rate, I'm
afraid CL will seldom be my first choice because I cannot rely on basic
library functionality being available and I don't ahve time to write
everyhting from scratch.
We probably need tobe a little less sensitive regarding criticisms of
CL. Sometimes, they are valid and we should listen and learn.
Tim
P.S. If anyone knows of a CL library that will allow me to interact with
an Oracle database AND allow me to call stored procedures, passing data
in both directions and access ref cursors, *PLEASE* let me know - I
would still prefer to use CL for these jobs over perl.
--
tcross (at) rapttech dot com dot au
------------------------------
Date: Thu, 11 Mar 2010 02:10:07 -0800 (PST)
From: Alessio Stalla <alessiostalla@gmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <8aaa14c8-19e6-49e6-8c9f-b856741cadfb@g10g2000yqh.googlegroups.com>
On Mar 11, 8:32=A0am, Tim X <t...@nospam.dev.null> wrote:
>
> P.S. If anyone knows of a CL library that will allow me to interact with
> an Oracle database AND allow me to call stored procedures, passing data
> in both directions and access ref cursors, *PLEASE* let me know - I
> would still prefer to use CL for these jobs over perl.
If it's a viable option for you, you could use ABCL on the JVM and use
Oracle's JDBC driver.
Alessio
------------------------------
Date: Thu, 11 Mar 2010 23:17:15 +1100
From: Tim X <timx@nospam.dev.null>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <87zl2f833o.fsf@rapttech.com.au>
Alessio Stalla <alessiostalla@gmail.com> writes:
> On Mar 11, 8:32Â am, Tim X <t...@nospam.dev.null> wrote:
>>
>> P.S. If anyone knows of a CL library that will allow me to interact with
>> an Oracle database AND allow me to call stored procedures, passing data
>> in both directions and access ref cursors, *PLEASE* let me know - I
>> would still prefer to use CL for these jobs over perl.
>
> If it's a viable option for you, you could use ABCL on the JVM and use
> Oracle's JDBC driver.
>
Yes, I was thinking about that as a possible option. Don't know anything
about ABCL and was hoping to stick with a familiar ANSI implementation
such as SBCL or even CLISP. Don't know anything about the
interface/mapping between ABCL and java libs and wsn't sure if I was
going that route whether I would be better off just jumping into clojure
as I've been thinking about finding some project to try it out.
Is there much that would take getting accustomed to in ABCL that may
feel 'foreign' and how ANSI compliant is it?
thanks,
Tim
thanks for the suggestion
Tim
--
tcross (at) rapttech dot com dot au
------------------------------
Date: Thu, 11 Mar 2010 04:39:30 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <5ff6154e-7187-4d75-b15e-76bbaa44a12e@33g2000yqj.googlegroups.com>
On Mar 10, 11:47=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > WRT Perl, I agree that it's an ugly, convoluted, write once read never
> > language,
>
> No. No No No. *Your* Perl may be, but don't tarnish the rest of us with
> the same brush. It's perfectly possible to write readable Perl; indeed,
> IMHO, it's wasier to write readable Perl (with a little effort) than
> most other languages.
Ben, I like Perl a lot, and I've developed enough proficiency in Perl
to do useful work and earn a living with it. I said this with my
tongue partly in my cheek, and without meaning to give reasons for
avoiding it. People can consider Perl ugly with all the punctuation
characters, just as Larry Wall can consider Lisp ugly with all the
parens (his remark about Lisp looking like oatmeal with finger nail
clippings.)
The OO and reference hacks are also convoluted, with arrays and hashes
only holding scalar values. This caused the convoluted assignment
statements which you objected to, i.e., $hash{$anotherhash{$k}{'key}}
('realkey'}. If you keep your data structures in mind, it's easy to
write these references without thinking, but hard to read them when
the data structures are out of mind.
In the thread on c.l.l. ("another frustrating learner question, CLOS")
I wrote a fairly extended defense of REs, which was the original point
of RG's complaint about Perl. REs are also ugly, convoluted, and write
once read never bits of code, but they can also be beautiful, elegant,
and perfectly lucid bits of code as well, and at the same time, too.
This is one of the mysteries of life which we might as well accept, as
we can do nothing to change it.
CC.
------------------------------
Date: Thu, 11 Mar 2010 13:54:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <499n67-f8j1.ln1@osiris.mauzo.dyndns.org>
[cll trimmed. Please start setting f'ups on your xposts. The Lispers
don't care about Perl style issues.]
Quoth ccc31807 <cartercc@gmail.com>:
> On Mar 10, 11:47 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > WRT Perl, I agree that it's an ugly, convoluted, write once read never
> > > language,
> >
> > No. No No No. *Your* Perl may be, but don't tarnish the rest of us with
> > the same brush. It's perfectly possible to write readable Perl; indeed,
> > IMHO, it's wasier to write readable Perl (with a little effort) than
> > most other languages.
>
> Ben, I like Perl a lot, and I've developed enough proficiency in Perl
> to do useful work and earn a living with it. I said this with my
> tongue partly in my cheek,
Please don't do that. There are already far too many people who think
the biggest and only problem with Perl is 'too much punctuation'; don't
encourage more.
> and without meaning to give reasons for
> avoiding it. People can consider Perl ugly with all the punctuation
> characters, just as Larry Wall can consider Lisp ugly with all the
> parens (his remark about Lisp looking like oatmeal with finger nail
> clippings.)
Both of these are *almost entirely irrelevant*. (Larry knows this, of
course, and was almost certainly actually talking about Lisp's lack of
syntactic clues, rather than the specific punctuation used.) Lisp is
beautiful in a way Perl is not at a level where the details of syntax
are unimportant.
> The OO and reference hacks are also convoluted, with arrays and hashes
> only holding scalar values. This caused the convoluted assignment
> statements which you objected to, i.e., $hash{$anotherhash{$k}{'key}}
> ('realkey'}. If you keep your data structures in mind, it's easy to
> write these references without thinking, but hard to read them when
> the data structures are out of mind.
No, nothing in Perl's reference model caused that bit of unreadable
code, only your unwillingness to understand DRY. If you take a language
like JavaScript with a much simpler model (everything is an object,
including arrays, so arrays can hold arrays 'directly'), you still end
up with
if (/\d/.test(sec[k].xlist) {
fac[sec[k].id1].location = sec[k].site;
}
else if (sec[k].xlist == sec[k].site) {
fac[sec[k].id1].location = sec[k].site;
}
else {
fac[sec[k].id1].location = sec[sec[k].xlist].site;
}
which, while it is a litle 'quieter' (though your original had too much
superflous punctuation for my taste) is no easier to read. The awkward
nested deref is still there, as is the repetition of sec[k].id1 and
sec[k].xlist and the .location and .site derefs. Factor those out, the
way I showed you, and suddenly the Perl is perfectly readable too. (I
realise at this point I made a mistake in my original correction. I
blame it on the appalling layout.)
> In the thread on c.l.l. ("another frustrating learner question, CLOS")
> I wrote a fairly extended defense of REs, which was the original point
> of RG's complaint about Perl. REs are also ugly, convoluted, and write
> once read never bits of code, but they can also be beautiful, elegant,
> and perfectly lucid bits of code as well, and at the same time, too.
No. Anything 'write once read never' is not 'perfectly lucid' by
definition. It's possible to write clear regexen--Perl's syntax is
better for this than most others--but it's also possible to make a
horrid mess trying to parse something you shoudl use a proper parser
for. The two do not overlap.
Ben
------------------------------
Date: Thu, 11 Mar 2010 13:03:58 GMT
From: pete <no-one@unknown.com>
Subject: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhphqhu.8qh.no-one@corv.local>
I was fixing a problem that "just appeared" in some otherwise working
code. There were no syntax errors and the program ran fine - it's just
that the result went from being correct to being uttterly and completely
wrong. A bit of lateral thinking and investigation solved the problem.
However, for your entertainment and education, here's a cut down version
that exhibts the same effect:
$
# set up a counter
$i = 0;
for($j = 0; $j < 10; $j++) {
print "j = $j\n";
$i++;
}
print "j = $j, i=$i\n";
which, when run produces:
root: perl bug.pl
j = 0
j = 1
j = 2
j = 3
j = 4
j = 5
j = 6
j = 7
j = 8
j = 9
j = 10, i=6308506
Yup, it's that solitary "$" all alone in the middle of nowhere.
it only took me about an hour and a half to spot - probably because
I was looking in entirely the wrong place as the real-life code had
a large block of comment lines between the "$" and "$i = 0;"
All I can say is aaaaaaaaaaaaaaaaaah!
------------------------------
Date: Thu, 11 Mar 2010 05:14:48 -0800 (PST)
From: Teo <matteo.corti@gmail.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <86886287-048b-497c-822f-143defe24102@15g2000yqi.googlegroups.com>
Dear Pete,
On Mar 11, 2:03=A0pm, pete <no-...@unknown.com> wrote:
> I was fixing a problem that "just appeared" in some otherwise working
> code. There were no syntax errors and the program ran fine - it's just
> that the result went from being correct to being uttterly and completely
> wrong. A bit of lateral thinking and investigation solved the problem.
> However, for your entertainment and education, here's a cut down version
> that exhibts the same effect:
>
> $
>
> # set up a counter
> $i =3D 0;
>
> for($j =3D 0; $j < 10; $j++) {
> =A0 print "j =3D $j\n";
> =A0 $i++;}
>
> print "j =3D $j, i=3D$i\n";
>
> which, when run produces:
>
> root: perl bug.pl
> j =3D 0
> j =3D 1
> j =3D 2
> j =3D 3
> j =3D 4
> j =3D 5
> j =3D 6
> j =3D 7
> j =3D 8
> j =3D 9
> j =3D 10, i=3D6308506
>
> Yup, it's that solitary "$" all alone in the middle of nowhere.
> it only took me about an hour and a half to spot - probably because
> I was looking in entirely the wrong place as the real-life code had
> a large block of comment lines between the "$" and "$i =3D 0;"
>
> All I can say is aaaaaaaaaaaaaaaaaah!
Following simple good style guidelines would have spared you a lot of
time:
use warnings;
use strict;
and then it produces:
Global symbol "$i" requires explicit package name at test.pl line 8.
Global symbol "$j" requires explicit package name at test.pl line 9.
Global symbol "$j" requires explicit package name at test.pl line 9.
Global symbol "$j" requires explicit package name at test.pl line 9.
Global symbol "$j" requires explicit package name at test.pl line
10.
Global symbol "$i" requires explicit package name at test.pl line
11.
Global symbol "$j" requires explicit package name at test.pl line
14.
Global symbol "$i" requires explicit package name at test.pl line
14.
Execution of test.pl aborted due to compilation errors.
Fixing the warnings with
my $i;
then causes the error to be discovered:
Scalar found where operator expected at test.pl line 8, near "$
# set up a counter
my $i"
(Missing operator before $i?)
Global symbol "$my" requires explicit package name at test.pl line
8.
syntax error at test.pl line 8, near "$
in any case, if I'm not wrong the program was interpreted as
$$i =3D 0
And BTW running the script as root is not the best idea :-)
Cheers,
Matteo
------------------------------
Date: Thu, 11 Mar 2010 14:19:26 +0100
From: ace <no@ace.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <hnaql1$r0k$1@ss408.t-com.hr>
pete wrote:
> j = 7
> j = 8
> j = 9
> j = 10, i=6308506
>
> Yup, it's that solitary "$" all alone in the middle of nowhere.
> it only took me about an hour and a half to spot - probably because
> I was looking in entirely the wrong place as the real-life code had
> a large block of comment lines between the "$" and "$i = 0;"
It's your own fault actually. Put use strict; on top of your program and
try to reproduce misbehavior.
------------------------------
Date: Thu, 11 Mar 2010 14:41:01 +0100
From: Frank Seitz <devnull4711@web.de>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <7vsa7dFco2U1@mid.individual.net>
pete wrote:
>
> $
>
> # set up a counter
> $i = 0;
$$i = 0;
This statement creates a scalar reference and assigns it to $i.
This mechanism is called autovivification.
A reference is basically an integer which you can increment:
$$i = 0;
print "$i\n";
$i++;
print "$i\n";
__END__
SCALAR(0x94a3168)
155857257
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
------------------------------
Date: Thu, 11 Mar 2010 13:58:33 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <9h9n67-f8j1.ln1@osiris.mauzo.dyndns.org>
Quoth Frank Seitz <devnull4711@web.de>:
> pete wrote:
> >
> > $
> >
> > # set up a counter
> > $i = 0;
>
> $$i = 0;
>
> This statement creates a scalar reference and assigns it to $i.
> This mechanism is called autovivification.
> A reference is basically an integer which you can increment:
No. A reference can be numified, and will be if you apply a numeric
operator like ++ to it. The result is not a reference, so you can't use
this to go grubbing around in arbitrary bits of memory. (You can use
unpack "P", of course, not to mention more than a few XS modules like
B::Generate.)
Ben
------------------------------
Date: Thu, 11 Mar 2010 14:04:50 GMT
From: pete <no-one@unknown.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhphu42.aq0.no-one@corv.local>
On Thu, 11 Mar 2010 14:19:26 +0100, ace wrote:
> pete wrote:
>> j = 7
>> j = 8
>> j = 9
>> j = 10, i=6308506
>>
>> Yup, it's that solitary "$" all alone in the middle of nowhere.
>> it only took me about an hour and a half to spot - probably because
>> I was looking in entirely the wrong place as the real-life code had
>> a large block of comment lines between the "$" and "$i = 0;"
>
> It's your own fault actually. Put use strict; on top of your program and
> try to reproduce misbehavior.
Not practical - it's not my original code, just my original bug :-(
------------------------------
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 2867
***************************************
