[16854] in Perl-Users-Digest
Perl-Users Digest, Issue: 4266 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 8 18:15:45 2000
Date: Fri, 8 Sep 2000 15:15:30 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <968451330-v9-i4266@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 8 Sep 2000 Volume: 9 Number: 4266
Today's topics:
Re: The Heartbreak of Inscrutable Perl Code <tim@ipac.caltech.edu>
Re: The Heartbreak of Inscrutable Perl Code <christopher_j@uswest.net>
Re: The Heartbreak of Inscrutable Perl Code <christopher_j@uswest.net>
Re: use strict: why? <godzilla@stomp.stomp.tokyo>
Re: use strict: why? <godzilla@stomp.stomp.tokyo>
Re: use strict: why? <brian+usenet@smithrenaud.com>
Re: use strict: why? <brian+usenet@smithrenaud.com>
Re: use strict: why? <russ_jones@rac.ray.com>
Re: Using localtime(time) Function nobull@mail.com
Re: Using localtime(time) Function <lr@hpl.hp.com>
Win32::OLE, Excel, and cell borders (Mark Haskamp)
Re: xml parsing <vmurphy@Cisco.Com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 08 Sep 2000 11:57:55 -0700
From: Tim Conrow <tim@ipac.caltech.edu>
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <39B936B3.B047CDA5@ipac.caltech.edu>
avast wrote:
[ ... bunch o' stuff excised ... ]
> Even more inscrutable to me is the following:
>
> /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
> @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
>
> It'll probably take a good hour or so for me to puzzle this one out.
> Again, is this type of compactness something to strive for or is it
> merely a personal preference on the part of the author? Are there
> useful lessons hidden here?
Sure there are lessons, lots of them, but don't learn the wrong ones. As you've
heard from others in this thread, terse coding is pursued for a variety of
reasons; aiding readability is not always one of them. As a personal choice, I
would not solve this problem quite as Larry did there (even though I can read it
fine) because I would want to emphasize/deephasize different things.
Read the above and understand it, but decide for yourself whether you care to
code that way or not. Don't blindly imitate even a guru.
(There's no vailed criticism of Larry here; his code is fine in every way, it's
just not how I'd do it.)
> This kind of stuff is extremely depressing to me in that what I think
> I know about perl and how to use it seems horribly trivial and
> mundane. My ultimate goal is to be able to write stuff like the
> above code without even thinking about it. I want it to be second
> nature. My problem right now is I'm not sure how to get there. Any
> advice would be greatly appreciated.
Knowing how to code as above is fine. Making it second nature is fine (I'm still
trying to get there). Being depressed that you can't is not fine. TMTOWTDI. Do
it your way and learn as you go. As you get better you'll develop your own
opinions about where terseness serves readability and where it fights it.
I read this group both to help where I can and to learn. I recommend you do
likewise. Larry, Abigail, et al spin out mind bending perl all the time. It's
great fun! The fact that I couldn't have done it isn't depressing to me; it just
points the way down the road I have to travel.
--
-- Tim Conrow tim@ipac.caltech.edu |
------------------------------
Date: Fri, 8 Sep 2000 14:17:12 -0700
From: "Christopher M. Jones" <christopher_j@uswest.net>
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <gHcu5.1141$QB6.218275@news.uswest.net>
"avast" <avast@hortonsbay.com> wrote:
> As a perl (or is it Perl?) novice I find it extremely instructive to
> analyze the code of highly experienced pratitioners. Larry's above
> example is a good one. Coming from C and COBOL (please don't laugh),
> however, I continue to have some difficulty with perl idioms. Some of
> these idioms (e.g., foreach my $thingy (@somearray) ) are clearly
> superior to C's more clunky "for (x=0;x<something;x++)" both in
> readability and expressiveness. Others, unfortunately, still seem
> overly obtuse and inscrutable to me. For example the line:
>
> my @fields = split /,\s+/ => $fields;
Quite simple actually. First, you need to realize that => is
nothing special. It's just a dressed up , (comma) and nothing
more.
Basically, what's going on here, is a standard split on
a comma followed by whitespace. So, for example, if
$fields was "somefield, someotherfield, lastfield"
you would end up with ("somefield", "someotherfield",
"lastfield") in your array.
> can be re-written as:
>
> $fields =~ s/ +//g;
> @fields = split /,/,$fields;
Close, but not quite. First, that should be \s instead of ' '.
Second, what about the case of "field name1, field name2, ..."?
You would end up with "fieldname1" instead of "field name1".
It _could_ be rewritten as:
@fields = split (/,\s/, $fields); # split on , and one whitespace char.
foreach (@fields)
{ $_ = s/^\s+//; } # remove leading whitespace
> Even more inscrutable to me is the following:
>
> /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
> @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
Take it one step at a time. It looks for a string with no commas
then a comma, then as much whitespace as possible, then more
non-commas, then a comma, then more whitespace, then a double quote,
then not the @. And, it searches for this in $_, which will be a line
from the DATA filehandle's file (notice the trailing while). If this
doesn't match, then it skips to the next while (since a logical AND
is false if any of its arguments are false the second part only needs
to be run if the first part is true). Then, it does some nifty
array acrobatics. In more verbose form:
while (<DATA>)
{
my $line = $_;
if ($line =~ /([^,]+),\s+([^,]+),\s+"([^@]+)/)
{
$users{$1}{$fields[1]} = $2;
$users{$1}{$fields[2]} = $3;
}
}
Or, (the super pedantic version)
while (<DATA>)
{
my $line = $_;
my ($name, $f1, $f2) = split(/,\s+/, $line); # look familiar?
if ($name and $f1 and $f2)
{
$users{$name}{$fields[1]} = $f1;
$users{$name}{$fields[2]} = $f2;
}
}
So, what's happening?
The first line of of the file for the DATA filehandle contains
a list of fieldnames. After that, the file contains three
"columns" of data. The first value seems to be the username
or usernumber or somesuch. The second and third values are
arbitrary data that gets stores in a hash based on the field
names.
So, say we have
-----
name, age, humanoid
fred, 35, yes
billy, 20, yes
zgorniklon, 1207, no
-----
You end up with
$users{'fred'}{'age'} = 35;
$users{'fred'}{'humanoid'} = "yes";
...
$users{'zgorniklon'}{'age'} = 1207;
$users{'zgorniklon'}{'humanoid'} = "no";
> Most inscruatble of all is:
>
> {
> local ($,, $\) = ("\t", "\n");
> print @fields, "\n";
> print $_, @{$users{$_}{@fields[1, 2]}} for sort keys %users;
> }
First, the standalone block of code with no control structure.
This is so that you can set values for global variables temporarily
using local and not have it affect everything else. Especially, as
in this case, special variables, which is an _excellent_ trick and
well worth learning.
The special variables here are '$,' and '$\'.
$, is the "output field separator" for "print" which is usually
nothing.
$\ is the "output record separator" for the print operator,
which is also normally nothing.
What this does is force print to output a tab between each
"parameter" printed and a newline after each print statement.
So, without modifying the special variables, this would be:
print join("\t", @fields), "\t\n\n";
foreach (sort keys %users)
{ print $_, "\t", join( "\t", @{$users{$_}{@fields[1, 2]}} ), "\n"; }
And, by using a bare block and local, after the printing with the
special format, the variables (and thus the print format) revert
back to normal.
> The use of the seemingly bare curly braces is something I've not see
> before. Additionally, the use of "local" instead of "my" here seems
> significant but I have no idea why it's used in this case. I know
> that "local" saves the values of it's arguments on a run time stack
> and puts them back when the script leaves the "block" containing
> "local". In the above case I don't see the significance in doing
> this. I'm sure that there's a good reason but my noviceness is
> keeping the scales firmly attached to my eyeballs at this point. I'm
> not even sure where to go to look for the answer (not _what_ local
> is but _when_ to use it).
local sets a local global variable. Anything that uses a global
variable will be affected if you use "local" to assign a new value
to that global variable. With a bare block, this allows you to
dink around with the global settings without specifically having to
store the original values (since perl does that for you seamlessly).
Another use of a bare block is in slurping an entire file:
open (FILE, "<file.ext");
{
local $/ = ''; # change input record sep. from "\n" to nothing
$file = <FILE>; # slurped, since with _no_ record sep. it's all one
line
}
close (FILE);
> This kind of stuff is extremely depressing to me in that what I think
> I know about perl and how to use it seems horribly trivial and
> mundane. My ultimate goal is to be able to write stuff like the
> above code without even thinking about it. I want it to be second
> nature. My problem right now is I'm not sure how to get there. Any
> advice would be greatly appreciated.
Nah, it's easy and you learn fast (or you should). You just need
to be pointed in the right direction. It can be a bit rough though
because what in other languages is Deep JuJu is run of the mill and
actually comprehensible in perl.
------------------------------
Date: Fri, 8 Sep 2000 14:29:08 -0700
From: "Christopher M. Jones" <christopher_j@uswest.net>
Subject: Re: The Heartbreak of Inscrutable Perl Code
Message-Id: <yScu5.1154$QB6.222104@news.uswest.net>
"Christopher M. Jones" <christopher_j@uswest.net> wrote:
> > /([^,]+),\s+([^,]+),\s+"([^@]+)/ and
> > @{$users{$1}{@fields[1, 2]}} = ($2, $3) while <DATA>;
> So, say we have
>
> -----
> name, age, humanoid
> fred, 35, yes
> billy, 20, yes
> zgorniklon, 1207, no
> -----
Ooops, I made a minor goof. I left out the part about the " and
the not @.
The file would more likely look like
-----
name, major, login
billy bob, und., "bbob@server.uni.edu"
zippy smith, CS, "zippys@server.uni.edu"
-----
Which will give you
$users{'billy bob'}{'major'} = "und.";
$users{'billy bob'}{'login'} = "bbob";
$users{'zippy smith'}{'major'} = "CS";
$users{'zippy smith'}{'login'} = "zippys";
The original code looks like it would get the "name" (or
identifier or whatever), the second parameter (which I
chose to be the major for a student but could be anything),
and then it extracts what looks like the login name from
their email address contained inside double quotes.
------------------------------
Date: Fri, 08 Sep 2000 11:22:40 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: use strict: why?
Message-Id: <39B92E70.93DE5144@stomp.stomp.tokyo>
"Randal L. Schwartz" wrote:
> Godzilla! wrote:
(snipped discussion, global, local, my)
I have another analogy for you Randal, to compliment
my other article response. This analogy pertains to
invoking additional processes and effect upon speed.
Pulling data sets into a script takes place in three
basic ways. Data can be included within a script,
data can included by file open and, data can be
included by socket, or commonly, use of LWP.
Data included in a script, such as arrays or a
typical DATA type inclusion, clearly is the
fastest method for script speed. Next in speed,
is a file open; a bit of time is used for this
file open process. Slowest, but not to imply
slow, is LWP to obtain data elsewhere; LWP
invokes a lot of external processes.
A programmer needs to make informed decisions
to strike a balance on which method or which
blend of methods, is best, in an overall sense
of script efficiency.
Using this as an analogy, use of global and
local variables invoke less processes than
would use of my variables to maintain global
type data. There is a distinct line you cross
over by using a lot of my variables where you
could use a global and some locals.
Real life analogy, you can eat ten ice cream
bars, one at time, slowly or, you can eat
all ten ice cream bars at once in a hurry,
by shoving 'em all in your mouth together.
Ten ice cream bars at once, sure does leave
a bottleneck lump in your throat.
* gulps*
Personally, I would rather sit in front of
my computer, eating a gallon of ice cream,
a spoonful at a time while wiling Geeksters.
However, I pay a big price for this; big butt.
So, a script can eat one global/local at a
time or, a script can eat ten my variables
all at once.
Slow eaters are usually healthy and not fat.
Fast eaters are usually unhealthy and fat.
I listened well, a rare event, during high
school when our Health Ed teacher kept saying,
"You MUST masticate slowly for good health."
Godzilla!
--
Clear Concise Communication.
http://la.znet.com/~callgirl/clarity.cgi
------------------------------
Date: Fri, 08 Sep 2000 11:33:40 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: use strict: why?
Message-Id: <39B93104.601BA667@stomp.stomp.tokyo>
"Christopher M. Jones" wrote:
> Godzilla! wrote:
> > Ok, your thoughts do make sense. Claiming a local variable
> > is a global variable as this other person did, certainly does
> > not make a lick of sense.
> They are exactly the same as global variables, the only
> difference is that the value will change once executation
> exits the block the local variable was declared in (to
> the value of the local/global variable in the "parent"
> block).
"...exactly the same ... only difference is...."
Yeah, ok, sure, whatever toots your Tootsie Roll.
So, declare a local variable within a sub routine and
try to use it later as a global. They are not 'exactly'
the same, actually quite different, yes?
* toots her Oscar Myer Weenie Whistle *
So cute! Have you ever thought about this symbology
of Oscar Myer riding, straddled upon top his
huge Weenie Mobile, during a public parade?
(snipped)
> Global variables and my variables can co-exist you
> know?
Which is precisely, paraphrased, what I have been
saying for nearly a year now and, subjected to
childish insult for doing so. Why don't these
people yell at you for saying what I say?
Rancid hypocrisy is clearly at play here,
along with repugnant bigotry.
Godzilla!
--
Gypsy Wildrose Pawnee - Fortune Teller
http://la.znet.com/~callgirl/fortune.cgi
------------------------------
Date: Fri, 08 Sep 2000 15:06:12 -0400
From: brian d foy <brian+usenet@smithrenaud.com>
Subject: Re: use strict: why?
Message-Id: <brian+usenet-086660.15061208092000@news.panix.com>
In article <39B92E70.93DE5144@stomp.stomp.tokyo>, "Godzilla!"
<godzilla@stomp.stomp.tokyo> wrote:
> "Randal L. Schwartz" wrote:
>
> > Godzilla! wrote:
>
> (snipped discussion, global, local, my)
> Pulling data sets into a script takes place in three
> basic ways. Data can be included within a script,
> data can included by file open and, data can be
> included by socket, or commonly, use of LWP.
you've left out several because you don't know what you
are doing:
* environment variables
* standard input
* command line arguments
* the many versions of freeze/thaw
* interprocess communication
* the special __DATA__ filehandle
* shared memory
and so on.
> slow, is LWP to obtain data elsewhere; LWP
> invokes a lot of external processes.
can you name one of those?
> Using this as an analogy, use of global and
> local variables invoke less processes than
> would use of my variables to maintain global
> type data.
there is no analogy.
there is no difference in the number of processes.
there is no clue in your head.
--
brian d foy
------------------------------
Date: Fri, 08 Sep 2000 15:08:14 -0400
From: brian d foy <brian+usenet@smithrenaud.com>
Subject: Re: use strict: why?
Message-Id: <brian+usenet-492C37.15081408092000@news.panix.com>
In article <39B9226D.9CEE755D@stomp.stomp.tokyo>, "Godzilla!"
<godzilla@stomp.stomp.tokyo> wrote:
> My contention, which seems to becoming slowly twisted into something
> it is not by others, is all three basic types of variables, global,
> local and my, all are very important.
there are two variable types, as Tom C. has already pointed out.
there are package variables and lexical variables. that is it.
as usual, you are wrong.
--
brian d foy
------------------------------
Date: Fri, 08 Sep 2000 14:16:25 -0500
From: Russ Jones <russ_jones@rac.ray.com>
Subject: Re: use strict: why?
Message-Id: <39B93B09.59555805@rac.ray.com>
"Godzilla!" wrote:
>
> My ego is healthy. I have no need to pretend to
> be a thousand different people. I like myself.
>
(Gets out HP RPN calculator) "That makes, hmmm, one?"
--
Russ Jones - HP OpenView IT/Operatons support
Raytheon Aircraft Company, Wichita KS
russ_jones@rac.ray.com 316-676-0747
Quae narravi, nullo modo negabo. - Catullus
------------------------------
Date: 08 Sep 2000 19:03:02 +0100
From: nobull@mail.com
Subject: Re: Using localtime(time) Function
Message-Id: <u9lmx2iwx5.fsf@wcl-l.bham.ac.uk>
"John Plaxton" <19wlr@globalnet.co.uk> writes:
> Subject: Using localtime(time) Function
Your problem has nothing to do with localtime() as you eloquently
demonstrate by showing that you code works outside a subroutine and
fails when you put it inside a subroutine.
This being the case you should conclude that you've got a problem with
writing subroutines not a problem calling localtime().
> Hi there can anyone spot the bug please
Your Godzilla-esque refusal to use my() distracts our attension away
from what you are asking so much that it's nigh on impossible to
concentrate long enough to help.
Please insert my() in all places where it is stupid not to have it.
> $datesstr = &createdatestr(time);
>
> sub createdatestr{
> @now = localtime($_);
The argument list of a subroutine is passed in @_
The first element of @_ is $_[0]
$_ is a different, unrelated variable.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Fri, 8 Sep 2000 11:40:27 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Using localtime(time) Function
Message-Id: <MPG.1422d27996f37cc398ad44@nntp.hpl.hp.com>
In article <8pb51j$okv$1@gxsn.com> on Fri, 8 Sep 2000 17:42:19 +0100,
John Plaxton <19wlr@globalnet.co.uk> says...
...
> However, the next code produces 1 may 1970 - 8 May 1970
>
> $datesstr = &createdatestr(time);
> print" This is the doggy String $datesstr\n\n";
>
> sub createdatestr{
Get into the habit of declaring variables within a subroutine by using
'my'.
> @now = localtime($_);
> ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = @now;
One step too many. Also, omit the trailing variables you aren't using.
> $year = ($year + 1900);
Perl (and C) have operators like += to make that cleaner.
> $str = "$mday $months[$wday] $year - ";
> @next_week = localtime($_ + (7*86400));
> ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)= @next_week;
> $year = ($year + 1900);
> $str .= "$mday $months[$wday] $year";
> return ($str);
> }
>
> Where's the bug? Am I passing in the value of 'time' correctly or do dates
> start from 1st May 1970?
You are using $_ instead of $_[0] to access the argument passed to the
subroutine.
> If I keep on adding (7*86400) to 'time' do I keep on adding on I week, or is
> the value of 'time' some strange incomprehensible beast?
What does `perldoc -f time` say about this?
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Fri, 08 Sep 2000 18:12:42 GMT
From: Mark.Haskamp@lexis-nexis.com (Mark Haskamp)
Subject: Win32::OLE, Excel, and cell borders
Message-Id: <39b928a3.94499803@newshost>
Using perl 5.6.0 and Win32::OLE, I can't seem to create borders in my
Excel spreadsheets.
Here's some sample code:
use Win32::OLE qw(with);
use Win32::OLE::Variant;
use Win32::OLE::Const 'Microsoft Excel';
...
...
# the following line doesn't work when the program is run stand alone
# you'll have to take my word for it that $range is correctly defined.
I'm using it with success throughout the program.
$range->Borders(xlEdgeTop)->Weight} = xlMedium
There are two items of frustration for me.
1) If I run the code through the debugger and manually execute the
last line of code above, it works. However, if I don's use the "-d"
command line option, the line doesn't work and generates the following
error:
Win32::OLE(0.13) error 0x80020005: "Type mismatch"
in METHOD/PROPERTYGET "Borders" argument 1 at
D:/aaa/apollo/bin/EXCEL_FMT.pm line 71
The general question is 'how can I create borders around cells?' and a
specific question is 'how come it works when I'm debugging but not
otherwise?'
2) The overall lack of documentation for how to execute Excel commands
via perl and Win32::OLE. Is there a good source of documentation for
this? Dave Roth's book, 'Windows NT. Win32 Perl Programming: The
StandardExtensions', has a useful example in chapter 5 that I've been
able to cannibalize, but it doesn't touch on everything and I'm making
progress largely through experimentation.
Thanks for any help.
------------------------------
Date: 08 Sep 2000 15:14:19 -0400
From: Vinny Murphy <vmurphy@Cisco.Com>
Subject: Re: xml parsing
Message-Id: <uzoliu25w.fsf@Cisco.Com>
>>>>> "Jaap" == Jaap <jaap@stack.nl> writes:
Jaap> Hi, XML parsers like XML::Parser are quite unsatisfying
Jaap> imho. So, i tried to do it myself.
Jaap> ... some code to get the xml file in a single string ($xml),
Jaap> spaces removed ...
Jaap> if ($xml =~ /<(.*?)>(.*?)<\/\1>/) { $xml{$1} = $2; }
Jaap> I want to make a nested hash %xml that contains ALL the
Jaap> data. (nevermind attributes at this time) Example:
Jaap> $xml{'parent'}->{'child'}->{'subchild'} = 'value';
Jaap> PROBLEM: I don't know how deep the xml goes, so there's no
Jaap> limit to the nesting...
Jaap> How do i do this? Thx in advance for ANY help.
You may want to use XML::Simple. The xml file can be set as a single
string, and then you can do what you want.
#!perl -w
use strict;
use XML::Simple;
use Data::Dumper;
my $xml =<<"XML_EXAMPLE";
<config logdir="/var/log/foo/" debugfile="/tmp/foo.debug">
<server name="sahara" osname="solaris" osversion="2.6">
<address>10.0.0.101</address>
<address>10.0.1.101</address>
</server>
<server name="gobi" osname="irix" osversion="6.5">
<address>10.0.0.102</address>
</server>
<server name="kalahari" osname="linux" osversion="2.0.34">
<address>10.0.0.103</address>
<address>10.0.1.103</address>
</server>
</config>
XML_EXAMPLE
;
print $xml;
my $config = XMLin("$xml");
# dump the xml code out.
print Dumper $config;
## You could also look at individual values.
print $config->{server}->{sahara}->{osversion}, "\n";
see perldoc XML::Simple for more details.
-vjm
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V9 Issue 4266
**************************************
